確かに、そんな経験あるある、という内容が多く、膝を打つ場面もあり、とても読みやすい物でした。SEを3,4年やっている人にはうってつけかも。
特に、「成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない」という部分はとても共感します。自分も、これまでの業務経験の中で、そういうPMを
...続きを読む複数見てきたので。
また、当然の事ではあるけど、「顧客に提供するのは、システムではなく、システムを使った結果のサービスである。」という意識は大切だと思う。
究極のところ、顧客の立場にたつって事だけど。
□SE/PMとは
使う側と作る側のコミュニケーションの橋渡しがSE/PM。
SE/PMの仕事は、コミュニケーションが全て。
PMは、成果物と、プロジェクトの２つを作らないといけない。
プロジェクトを作る=プロジェクトを成功させる。
成果物だけ立派でも、メンバーの体や心を壊したりしていては、PMではない。
プロジェクトの成功=プロジェクトのステークホルダ全員が「よかった」と思える状態。
□顧客とは
顧客に提供するのは、システムではなく、システムを使った結果のサービスである。
プロジェクト憲章の時点では、「システム」という単語を使わず、システムを使い続ける事に
よって顧客が得られる「利益」を定義する。
そしてその利益は、費用対効果が無いといけない。
□プロジェクトに失敗する原因
目標達成のために必要な情報を、知らないままor伝えないままにする。
→その原因は、
・知らないと言えない
・知らない事をばかにする、怒る
・説明を面倒臭がる
→その解決策は、
相互に理解した事を確認する。
自分や相手のポジション、知らない事、知っている事を把握する。
□仕様の策定方法
細かい所は、後から問題になってきて、しかもユーザーの不満をうみやすい。
細かいだけに、後から直しずらい。
→最初から詳細な仕様を作る。
(それが無駄にならない事が確認できた時点で)
委託契約の場合、手間がかからないほど利益が多いので、なぁなぁにしてしまいがち。
□コミュニケーションの基本
明るく話す！！
詳細に話す
事前に練習/レビューする。
□会議の実践術
・ホワイトボード活用法
→収集がつかなくなった時に、ホワイトボードに向かい、意見のありそうな人に、何を書きましょうか、と聞く！
すると、自然と話しが進んで行く。
・議事録
その場で作成し、声に出して読み上げる。
会議=プレゼンである。
最初に目的があって、その目的の方向へ引っ張っていく事。
□プロジェクト初期段階の工夫
最初のコンタクト時に、質問シートを渡そう！
・案件の目的
・最も求められている事
・別案件での苦い経験
・心配事
・組織構成
・現場見学の可否
・資料提供の可否
業務内容を、顧客よりも深く理解する事！
顧客業務分析
設計書の前段階の文書。要件確認よりも前。
最も重要な工程。徹底的に確認する。
→できれば、業務の現場を見る。実際に作業を行う。
顧客の放つ、用語の意味する内容を、詳細に理解する。
業務分析結果を、顧客にレビューしてもらう。
業務内の、今回の要求のスコープを明確にする。
顧客には、夢も含めて全てを話してもらい、実現可否は要相談とする。
プロトタイプを作る目的
・見せた時のリアクションを見る！
・開発側の理解を深める
スケジューリングのコツ
スケジュール最適化を行うタイミングをスケジュールする。
変更管理方針を、はじめから確定しておく。
□プロジェクト運営中の問題
責任追及が始まったら、プロジェクトは破綻する。
実作業者が、正しい行動ではなく、「怒られない」ための行動をしてしまうのは、より上位の人間の責任。
皆が同じ程度に悪い状況だから、自分の状況も許される、という意識がプロジェクト内に芽生えると、最悪の信号。 