私は金融会社の小規模な社内 IT 部門で開発者として兼務しており、プロジェクト管理がほとんど、またはまったく行われていない多数の中小規模のプロジェクトに携わってきました。これは常にスコープクリープを引き起こし、締め切りに間に合わず、短期間でユーザー/マネージャーを満足させるために優れた設計/コードを犠牲にしなければならないようです.
ユーザー/マネージャーの要求と期待を考慮して、コードを記述する前にユーザーの要件を明確にし、変更要求が適切に管理されるようにするために、開発者として何ができるでしょうか。
ありがとう。
このような状況では、スコープ クリープはほぼ避けられず、利害関係者は前もって分析を手伝う時間がなく、正式な契約もありません。目標と期待を常に調整できるアジャイルな方法論を選ぶことをお勧めします。スクラムのようなもの。短いサイクルは、利害関係者が問題をよりよく理解して早期に結果を確認し、要件を調整するのに役立ちます。また、スプリント サイクルによってこれらの変化に適応できるため、彼らはあなたを正気から遠ざけてくれます。
コーディングを開始する前に、完全な機能を備えた仕様を用意することは事実上不可能です。特に小さな会社では。アジャイルなアプローチはうまく機能しますが、これがプロジェクトの完成を妨げてはなりません。
できること:
基本的に、あなたがしなければならないことは、あなたが何をしているかを皆が知っていることを確認することです. これは必ずしもプロジェクトを時間内に終了させるわけではありませんが、マネージャーにとってはミラーとして機能するため、マネージャーは決定の結果がどうなるかを確認できます。
しかし、全体として、コミュニケーション、コミュニケーション、コミュニケーション、そして一種のミニプロジェクトリーダーになります。
追加機能が要求されたときにプッシュバックするマネージャーがいない場合は、自分で行う必要があります。リリース スケジュールを公開し、プロジェクトの将来のフェーズに追加機能を追加して、これらの追加機能のためにプロジェクト全体が遅れないようにします。これらの追加機能がプロジェクトに追加されるのにどれくらいの時間がかかり、いつ表示されるかを人々に知らせてください。
最も難しい部分は、人々にノーと言う方法を学ぶことですが、それはあなたが学ぶ必要があるものです.
スコープ クリープには 2 つのタイプがあります。1つは、事前に適切な要件を取得していないことに起因します。これにより、期待されるものを提供するために予期しないタスクが発生します。これが問題である場合は、事前に要件を収集するのにより多くの時間を取り、各期間に期待されることを厳密に文書化することをお勧めします。これができたら、いくつかの低レベルのタスクと時間の見積もりを作成できます。時間超過がある場合は、少なくとも事前に知ることができます。
2 番目のタイプは、開発サイクルの途中で追加された小さな機能に起因します。これは、ノーと言う方法を学ばなければならないところです。いつでもノーとは言えませんが、戦いを選ばなければなりません。そして覚えておいてほしいのは、この種のスコープ クリープは、1 つの大きなことから生じるものではないということです。それはたくさんの小さなことから来ています。それは千の切り紙による死です。
残念ながら、基本的にはプロジェクト管理を自分で行う必要があり、変更管理について少し学ぶ必要があります。アクセス可能なプロジェクト管理の本 (PMBOK ではない) を手に取り、変更管理に関するセクションを読んでおくとよいでしょう。
私が取り組んできたプロジェクトでは、
残念ながら、私の経験では変更管理は決して楽しいものではありません。私が聞いた中で最も一般的なのは、見積もりの精度に対する非現実的な期待と、利害関係者からの不当な要求です (自分が説明した変更の影響を単純に拒否する、または「とにかくやり遂げろ」などの要求でプロセスを無視する)。
重要なのは、文書化と可視性です。要件の作成者が機能リクエストを入れるために使用する、使いやすい問題追跡システムがあります。彼らはそうすることを思いとどまらせることは決してありませんが、コーディングの見積もりを盗んだ後、会議はリクエストのレビューに費やされます. 時間が限られている場合、リクエスタは、コーディングが完了することを期待するだけでなく、互いにコーディング時間を競わなければなりません。私たちコーダーは、クリープが互いにどのように影響するかについて話し合う必要があるため、クリープから保護されます。
あなたとクライアントが要件に慣れたら、署名済みの要件ドキュメントで要件を確定します。それ以降は、より多くの費用がかかる変更要求です。
クライアントがサインオフしたくない場合、これは機能しません。「ソフト要求期限」や「ハード要求期限」など、契約に合理的な期限を設定できるかどうかを確認してください。
明らかに、ある程度の余裕はあるはずであり、事後に何をきしみ、何をきしむべきではないかを判断するための厳格な方法は決してありませんが、厳しい締め切りとより多くのコストの脅威を追加することで、一般に、大量の req が存在し、特定の時点まで不変であるため、ある程度の正気を保つことができます。
「NO」と言うのを恐れないでください。もちろん、丁寧に、そして専門的に。何にもコミットしないでください。すぐに始めることは不可能です。確信が持てないことにすぐにコミットしないでください。
また、プロジェクト管理の本を手に取り、読んで、適用することを恐れないでください。
私は何年も同じ状況にありました。しかし、私の経験は少し異なっていました。もともと私の会社では、私は一匹狼でした。要件会議はすべて私が主導しました。要件を収集した後、アプリを作成しましたが、見よ、それはユーザーが望んでいたものではありませんでした。再構築時間、110 億回の変更。なんて恐ろしいプロセスでしょう。私のマネージャーから私、ユーザーまで、誰もがそれについて怒っていました。
残念ながら、ソフトウェアを欲しがっている人々は、解決策を探しているビジネス上の問題を解決するソリューションを設計するのに時間を割きたくないことがよくあります。彼らは一貫して漠然としていて、何にもコミットしたくありません。
私たちが成長するにつれて、ソフトウェア開発プロジェクトを管理したことがなく、技術的な経験がほとんどまたはまったくないにもかかわらず、何人かの人々を即席のプロジェクト マネージャーとして雇いました。これにより、開発者である私以外の全員が同意した「具体的な」仕様が得られました。
もちろん、結果は元の状況とほぼ同じくらい悪いものでしたが、少なくとも、仕様を実施することについて経営陣の賛同を得ました。残念ながら、これらの具体的な仕様は、ばかげた、そしてしばしば本当に不可能な欲求でいっぱいでした.
アプリケーションの正気を求めて戦った後、ビルドされます。10 分の 9 の割合で、ユーザーは依然として動揺していました。なぜなら、ユーザーは常に、プロジェクト マネージャーと一緒に、うまくいかないばかげたソリューションを設計したからです。
再び、再建地獄が続いた。
これで完全に一周しました。すべてのプロジェクト マネージャーがいなくなり、かなりの数のレイオフが発生したため、私は再びサイクル全体の責任を負っています。幸いなことに、私たちは過ちから学びました。経営陣は、契約を履行するために必要なことを行うことに今でも専念しています。また、ユーザーにアプリを提供する方法も少し変更しました。
多くの場合、私たちは彼らに小さなチャンクを与え、それらをテストするように要求し、そのセクションが彼らが望んでいて必要としているものであることを承認します. そうでない場合、必要な変更はプロジェクトの最後に追加され、スケジュールがどのように変更されるかが全員に通知されます。ささいな変更や気まぐれは、最終的な収益に明らかに影響を与えると、すぐに消えます。
誰もが相互に同意できない機能を変更したり、深めたりしないでください。あなたが選ぶ必要があるならば、何か他のものを落としてください。決定は自分で行う必要があります。
Scope Creep は未承認の変更がすべてです。質問を読むと、答えを知っているように見えます。要件、変更要求、および承認が必要です。
BA と PM があり、残りのすべての管理ミドルウェアがあれば、要件ステートメント、変更要求フォーム、変更レビュー ボードなどを使いこなすことができます。しかし、これはあなたが望むものではないと思います。
これらすべてを簡単に行うことができます。最初に、プロジェクトのスポンサーが誰であるかを決定します。誰がそれを開始し、誰が所有しているのか。これは、プロジェクトの予算とスケジュールを承認する 1 人である必要があります。双方が同意できる以下のようなプロセスを考え出す必要があります。
次に、Excel で要件登録用のシートを作成します。すべての要件をリストします。それぞれに簡単な説明を付け、必要に応じて長い説明の列を残します。また、誰が要件を要求したか、ソリューションが設計された時期と設計されたかどうか、およびソリューションが提供されたかどうかについての列も含まれています。スポンサーと話し合い、これがベースラインであることに同意します。
次に、変更登録シートを作成します。これには、簡単な説明用の列、詳細な説明用の列、日付、影響の列、承認日と承認者用の列が必要です。影響列が最も重要です。誰かが変更を要求するたびに、その変更が範囲、予算、またはスケジュールにどのように影響するかを検討する必要があります。追加機能により、5 日と $5,000 が追加される場合があります。クリスマスまでに配達する必要がある場合は、要件項目 1、2、3 を削除する必要があります。
変更と影響を伝えるための要件と方法を手に入れたら、最も難しいのは、スポンサーの承認なしに変更を実施できないことです。この承認は、電子メールでも何でもかまいません。ただし、「変更番号 12 を承認します」と明示する必要があります。明示的な承認手順がなければ、気にする必要はありません。
これは、回避できる最小限のドキュメント/プロセスに関するものです。主な目標は、各変更の影響が完全に伝達され、適切な担当者によって受け入れられたり拒否されたりすることを確認することです。この人はあなたではなく、通常、変更要求を行う人ではありません。
現在の要件が何であるかを追跡します。顧客が来て、新しい機能を要求した場合、新しい機能を追加すると次のいずれかが発生することを顧客が知っていることを確認してください。
ボブ・キングがコメントで言ったように、専門的な問題で「ノー」と言うのは悪いことではありません。
スクラムに関する本を読み、オフィスで実践してください。それは効果的に経営陣の立場を逆転させ、達成したいことを優先させます。多くの場合、私たち開発者は膨大な要件リストと短いタイム ラインを提示されます。スクラムを使用すると、これらの要件をタスクに分割し、特定の時間に何時間働くことができるかを決定し、その割り当てられた時間の最初に、この「スプリント」の優先順位を決定するためのミーティングを行います。他にもたくさんありますが、本当の天才は、マネージャーを管理することを除けば、優先順位がアプリケーションの真の肉になる傾向があるため、「キュート」な要件を取り除くことです。組織に実装して以来、開発者としての私の生活はずっと楽しくなりました。
受け取った各要件をマネージャーに承認してもらいます。プロジェクトを自分である程度管理できますが、実装する前に他の人に変更を承認してもらいます。次に、サインオフをレバレッジとして使用して、ノーと言うことができます。
自分でプロジェクト管理を行う必要があります。アジャイル プロジェクト管理について学びます。
http://agilesoftwaredevelopment.com/blog/artem/scrum-under-10-minutes-video
バックログを作成し、変更や機能に対してイエス/ノーと言う代わりに、優先度順に並べ替えます。物事を完璧にするための「素晴らしい」ものは、常に後のバージョンまで延期することができ、これが計画であることを明確にします。機能的な製品を最初に入手するために、最低限のことに集中してください。