タグ

仕事とプロジェクト管理に関するshichiminのブックマーク (6)

  • 仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた

    仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基が全部わかる」の著者に聞いてみた 「プロジェクトマネジメントの基が全部わかる」を執筆し、ご自身もプロジェクトマネージャーやプロダクトマネージャーとして23年経験を積んできた橋将功さん。 橋さんは、セミナーや著書でプロジェクトマネジメントについての知見を発信されていますが、今回 Agend であえてお聞きするのは「専門のプロジェクトマネージャーがいないグダグダになっている職場で、どう仕事を回していくか」。 「うちの会社は仕事を回すのが下手」と感じている方にこそ読んでいただければと思います。

    仕事の進め方がグダグダの会社はどうすればいいのか、「プロジェクトマネジメントの基本が全部わかる本」の著者に聞いてみた
  • 要求の品質

    BABOKの最重要ポイントは、要求の品質にある。 そもそも論をぶちあげて責任韜晦するなら、まだ賢いほう。ふつうの顧客は、「要求部門が違うと言うから」「書いてないことはこっちのフリーハンド」などと逆ネジをい込ませてくる。要するに、仕様書には無いが無償(ただ)で対応しろ、という圧力だ。テストフェーズ後半か、シミュレータでもエミュレータでもなく「当に使う人」「当に接続するシステム」が使い出す頃に出てくる。いわゆる、宴もたけなわの頃だ。不備、誤読、漏れ抜け、ほころび、い違いを、堂堂と「バグ」と読んではばからない。昔は殺意が湧いたが、これでかなり丸くなった[怒らないこと](とはいえ、ここでは仏教ではなくBABOKからのアプローチを続ける)。 しかしながら、反論が困難なことも事実。「仕様書に無い」「要件定義に書いてない」「そもそも要求すらない」という反論ができるほどトレーサビリティが無いのだ。

    要求の品質
  • なぜ糞システムができあがるか

    納期が、予算が、バグフィックスが、性能、デザイン、インタフェース、使い勝手、保守が、可用性が、移行にマイグレーション、稼働率が、糞だ。そもそも要求を満たしとらんまともに動かない糞システムが、なぜ莫大な銭金かけてできあがってしまうのは、なぜか? アナリスト、コンサルPM、SE、プログラマ、テスタ、ヘルプデスク、メンテ、ユーザー、そして経営者と、それぞれの立場から言いたいことは山ほどある。それぞれの立場から「これぞ真の原因!」と叫びたいのも分かる。経営者を除き、全てのキャリアをやってきたから。だから、自信をもって断言する。糞システムができあがる、最も根っこの原因はこれだ。 一つ前の仕事をしている それぞれの立場で「やるべきこと」は分かっている。だからこそ、そのインプットが体を成していないことが明白なのだ。仕方がないので、自分で「インプット」相当を作るハメになる。 例えばプログラマ、プログラミ

    なぜ糞システムができあがるか
  • cpainvestor.com | 超長時間労働を厭わない組織風土をいかにして変えていくべきか

    現役会計士が語るビジネス・会計・投資コラム このWebサイトに記載された事項は執筆者の私見であり、執筆者の所属ないし関係する機関・組織の見解ではないことをお断りしておきます。 1年半ほど前、今の主だったメンバーと仕事をするようになって、心に誓ったことが一つあります。「どんなにつらい状況に追い込まれたとしても、絶対に徹夜だけはするまい!」という信念です。 私が来る前の今のメンバーの組織は、「クライアントの期待に応える報告をするためには、何日か連続の徹夜も辞さない!」という方々が集まっていました。というか、そういう方しか残れない組織になっていました。「いくら日程的にタイトな状況に追い込まれることが多いM&A関連業務とはいえ、この状況は酷すぎる。体力的、精神的につらいからと言って反発して逃げるのではなく、自分が絶対にこの組織風土を変えてやる!」そう固く誓って、今のメンバーに合流しました。 それか

  • プロジェクトをデザインする: DESIGN IT! w/LOVE

    不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 どんなプロジェクトでも、最初にプロジェクトを定義・計画しないと、決められた時間内・リソース内で成果を出すことってできないんじゃないかと思います。 そうじゃなくても、必ずしもプロジェクトで成果を出すのはむずかしいわけですから、せめて最初の定義と計画はきちんとしないとね。 プロジェクトのデザイン大なり小なりプロジェクトを行う上では、ざっと下記のリストのようなことを検討する必要があるでしょう(リストはできるだけいろんなプロジェクトに対応するよう一般化してみました)。 最初の「定義」の部分で、タスクと役割とスケジュール、その他リソースが紐づいた状態でプロジェクトをデザインしておかないといけないと思います。 定義ミッションとヴィジョンの明確化目的と測定可能なゴールの設定ターゲットの明

  • Web2.0ナビ: 意外と使われていない「個人用trac」活用のすすめ

    いいね! 6 ツイート B! はてブ 738 Pocket 138 tracをご存知ですか?tracは主にシステム開発系プロジェクトにおいて、バグ管理・バージョン管理・ドキュメント共有に使われる超便利ツールです。これがないと開発なんて出来ないよ!という開発者も多いはず。 そんなtracですが、個人用や家庭用でもカナリ使えるツールなんです。開発をしなくても、「脳をすっきりさせたり」「自分タスクを整理したり」「アイデアを貯めたり」「旅行計画を家族と共有したり」、日常生活という自分プロジェクトの管理ツールとして活用することができます。 tracとは 前述の通り、tracは主にシステム開発で使うプロジェクト管理ツールで、無償ソフトとして配布されているので、誰でも自由にダウンロードして使うことができます。 主に利用できる機能が4つあって ■ wiki 誰でもいつでも編集できるwiki機能があります。

  • 1