開発現場でいるいるこんな人に対処する方法
概要
- ブロガーであるニール・グリーンさんが書かれた、How to Deal with Difficult People on Software Projectsというブログがとても面白かったので記事にしてみました。
- 内容が、開発現場でいるいるこんな人〜〜！とそんな人に出会した時の対処法をまとめられています。
内容
内容なのですが、下記のようにまとめられています。
ちょっと面白かったものだけ抜粋しようと思います。
- [プロダクトマネージャー]
- [デザイナー]
- [プロジェクトマネージャー]
- [開発マネージャー]
- [開発者]
- [テスター]
プロダクトマネージャー
スコープクリーパー
納期を同じに保ちながらプロジェクトの範囲を拡大するプロダクトマネージャー
[特性]
追加したスコープを構築するための時間をプロジェクトに与えない。
[理由]
スコープが拡大する理由
- 顧客機能が満たされない場合、収益の損失につながる
- 利害関係者が望んでいた要件が、プロダクトマネージャーによって文書化されない
- 製品の機能に、より多くの要求を課す競争圧力
プロダクトマネージャが背負うプレッシャー
- 利害関係者の信頼を維持する
- プロジェクトを予算内に保つ
- 収益目標の達成
- 契約上の義務の履行
上記に挟まれるとスコープクリーパーが生まれてしまうようです。
[解決策]
- スコープを縮小するか、リリース日を移動するアクションを実行する
独裁者
開発者からのアイデアを拒否するプロダクトマネージャー
[特性]
- 開発者はソフトウェアのみを作成する必要があり、要件の定義はプロダクトマネージャーが行う必要があると考える。
[理由]
独裁者は、開発者とコラボレーションすることの利点を認識していないか、コラボレーションを行う価値がないと判断してしまっている。
[解決策]
- 独裁者より上の管理職の人に訴えると迅速に解決される
デザイナー
ノートテイカー
他の人のアイデアを文書化する以外に何もしないことに追いやられているデザイナー
[特性]
UIについて模索する中で、独自のデザインの方向性を提供するのではなく、グループのアイデアのみをキャプチャすることに集中する。
[理由]
スタッフにデザイナーがいない為です。
[解決策]
- メモを取ることが必要ある場合、デザイナーの役割を果たすために誰か他の人を見つける必要がある
プロフェッサー
ユーザーインターフェイスデザインの科学と理論に熱心に取り組んでいるデザイナーであるため、利害関係者からのUI要件を無視する
[特性]
要件の詳細を単に無視することで応答し、代わりに、要件をプロダクトマネージャーによって拒否されるUIに変換して、プロジェクトを停止します。
[理由]
研究分野であるヒューマンコンピューターインタラクション（HCI）に沿って考える人の為、役割をHCI標準を実施するものと見なしている。
その為、HCIベースの分析に関しては「正しい」ので、UIの変更を拒否します。
[解決策]
- すべてのUIの制御については放棄して、プロフェッサーの有能な手に委ねるように説得する(いいのだろうか？w)
プロジェクトマネージャー
暴君
プロジェクトメンバーをもっと一生懸命働くように動機付けるという名目で軽蔑して扱うプロジェクトマネージャー
[特性]
プロジェクトの成功を確実にするために、プロジェクトメンバーに対して権限を乱用する。
[理由]
プロジェクトの利害関係者は、特にプロジェクトが現在予定より遅れている場合は、プロジェクトを成功させるために必要なのは「しっかりした手」であると考える。
そのため、多くのプロジェクトマネージャーがこの性格を採用してしまう。
[解決策]
- 暴君の行動がプロジェクトに悪影響を及ぼしていることを自己認識させる必要がある。
- プロジェクト管理スタイルを反映した定量的データを提示する。
例
貴重な従業員が何人残っているか
提供されている機能の数
生成されているバグの数
締め切りに間に合わなかった数
妄想
ロジェクトマネージャーは、プロジェクトの現実にあまり触れていないため、利害関係者に虚偽を示す
[特性]
プロジェクトマネージャーの中心的な役割としては、プロジェクトのステータスを報告することです。
プロジェクトのステータスは、プロジェクトの成功を測る尺度です。
優れたプロジェクトマネージャーは、定量的データと定性的データの組み合わせ、および彼ら自身の専門的な経験を通じて、利害関係者にプロジェクトの成功を測る尺度を設定します。
しかし、妄想プロジェクトマネージャーは、本能だけに基づいてそれを行います。
[理由]
自身の本能だけに基づいて、完全に現実と一致していない成功または失敗に関する意見を形成してしまう為。
[解決策]
- 妄想プロジェクトマネージャーの本能と矛盾する定量的および定性的なデータを示すように促す。
開発マネージャー
技術者になりたいマネージャー
コーディングの人生に戻りたいと願う開発マネージャー
[特性]
ソフトウェア開発者は、キャリアアップのために2つの選択肢しかない。
[理由]
開発マネージャーがマネージャーの人生を十分に過ごしたことに気づき、ソフトウェア開発者に戻りたいと思ったとき、技術開発マネージャーはコーディングの役割に戻る機会を探します。
ただ、最高の開発マネージャーもコーディングを行うことを考えると、コーディングから大分離れているために、以前のキャリアパスを再開するにはスキルが不十分であることがよくある。
[解決策]
- 開発マネージャーとしての職務に集中し続ける
- 業務外の時間でソフトウェア開発者になるために必要な技術スキルを習得し、開発者に戻れるか判断する。
開発者
理想主義者
アーキテクチャの優雅さとコードの完成度を達成することに夢中になっている
[特性]
ビジネス価値を追加するという目標を完全に無視し、代わりに優れたソフトウェアの作成に専念しています。
[理由]
自分たちが構築しているシステムが会社の将来にとって最善であると心から信じてしまう。
なぜならば、ビジネス価値を付加したい（そして報酬を得たい）という願望と素晴らしいソフトウェアを書きたい（そして誇りに思う）という願望があるためです。
[解決策]
- 「会社にとって最良」とは何か、そしてそれをどのように達成できるかについて議論する。
- ビジネスの観点と会社の問題、優先順位を基に話し合う。
ロックスター
非常に才能があり、生産性が高く、非常に重要な開発者であるため、彼らが去った場合、プロジェクト全体が崩壊する
[特性]
一度採用されると、彼らはプロジェクトに不可欠になる
[理由]
- 迅速に解決できない問題はない
- 締め切りを守るために夜中ずっと働いている
- 実質的にバグがないか、バグがあればすぐに解決される
- 彼らはプロジェクトの最も難しい部分を引き受ける
- 彼らは一般的に仲間に好かれる。
[解決策]
- 「解決策」はない。
テクノロジーに夢中
新しいテクノロジーを試すことに興奮している開発者で、適切かどうかに関係なく、プロジェクトに導入する
[特性]
新しいテクノロジーで遊ぶのが好き
[理由]
すべての開発者は、ある程度までテクノロジーに夢中になっている。
ただし、開発者が適切な技術的選択を行う場合、新しいことを学びたいという個人的な欲求と混同してしまい、ビジネス上の問題を解決するための最適解と一致しないテクノロジースタックになってしまう可能性がある
[解決策]
- 会社が標準的なテクノロジースタックを確立しており、開発者がそのスタックから逸脱したときに開発者を修正する。
テスター
消化ホース
非常に多くのバグレポートで開発者を氾濫させるテスターであるため、開発チームは、作業を完了できないバグのバックログで圧倒される
[特性]
バグが見つかった場合は、正確に報告してから、適切な開発者に迅速に割り当てて修正することが重要だが、バグを見つけて報告するため、開発チームがバグを修正する能力を超えて、閉じることのできないバグのリストが増え続けてしまう。
[理由]
- バグレポートはあまり詳細ではないため、より多くのバグをより迅速に報告してしまう
- 多くのバグは、単一の根本原因のバリエーションにすぎないため、他のバグと重複している
- バグレポートを生成するために必要なのはバグを1回確認するだけなので、バグの再現に時間を費やす
[解決策]
- 開発者がシステムの問題を見つけるのを支援する
ランダムクリッカー
好きなものをクリックするだけでバグを探すテスター
[特性]
ユーザーが行う可能性のあることをエミュレートしようとして、アプリケーションをランダムに蛇行する
[理由]
- テスト計画の作成は面倒であり、製品がテストの準備ができるまでに、要件の変更でテスト計画が適切であるという保証はない。
- これは、QAテスターがテスト計画を完全に放棄し、代わりにバグをキャッチすることを期待してアプリと対話するだけの効果をもたらす可能性がある。
[解決策]
- アプリケーションのテスト方法について指導を受けていない可能性があるので、必要な指導を行う。
まとめ
一部の内容を抜粋し翻訳してみましたが、ああいるいるとなるものと、なるほどなぁとなるもの耳が痛いものがあり面白かったです！
Discussion