ソフトウェア開発の委託;ユーザーストーリーやビジネス要件を提供しますか？
私は私が主任開発者である小さな会社であり、良い機会のために潜在的な利害関係者と何度もミーティングを行っています。この利害関係者は、他の利害関係者のグループに対して、彼らが強く必要としているソフトウェアの提案をまとめるのを直接支援しています。うまくいけば、私たちが提案（非常に高レベルの機能と一般的な成果物で構成される）でそれらを販売すると、彼らはプロジェクトを後援し、そこから全国のユーザーに有機的に成長し、それがどれほど役立つかがわかります。
問題は、開発者としての私たちが、以前のプロジェクト、既存の本番システムの保守、およびバックログでひどく必要とされている機能と同様に、ひどく行き詰まっていることです。現状では、このプロジェクトは非常に儲かる可能性があり、深刻な競争相手がいないため、経営陣は迅速に行動し、最も基本的な機能をできるだけ早く実現したいと考えていますコストに関係なく。
チームを成長させなければ、これは現実的ではありませんが、時間がかかりすぎます。彼らは開発作業を請け負うことを考えていますが、私がビジネスアナリストになり、プロジェクトでアーキテクチャの発言権を持ってほしいと思っています。彼らが主要な機能開発を終えると、彼らは私のチームが保守を担当することを期待しているので、成果物を保守可能にしたいので、明らかにアーキテクチャの制御が重要です。
私はこの役割で大丈夫ですが、それに慣れていません。社内では通常、正式な要件ドキュメントを使用せず、代わりにユーザーストーリー、ユースケース、ワークフロー、および顧客契約から要件を収集します。私たちはユーザーストーリーの作成に慣れていますが、外部の契約会社にユーザーストーリーを配信することは意味がありません。彼らは、自分たちのやり方で物事をやりたいと思うかもしれない独自のプロジェクト管理を持っている可能性が高いからです。彼らがそれを異質であると見つけて、それが彼らを遅くするならば、私は彼らに私たちのなじみのないプロジェクト管理プロセスを課したくありません。
高品質のソフトウェアを作成するために必要なガイドラインを確実に持ってもらいたいので、非常に詳細な正式なビジネス要件が整っていると思いますが、これが私だけでどのような努力をするのかわかりません。いつ始めればいいのかもわかりません。まだ公式なものはありませんが、私は利害関係者から必要だと感じる情報の90％を持っています。契約が締結されたことを経営陣から通知されたくはありません。6か月以内に納品し、週末までにすべての要件文書を入手する必要があります。
ここで少し頭を悩ませていますが、ユーザーストーリーやビジネス要件を策定しますか？他に役立つ提案はありますか？
請負業者として、私が思うことは次のとおりです。
まず、請負業者を知る。彼と少し話して、あなたのリード開発者と話してもらいましょう。彼らは彼のスキルレベルと直感のレベルを評価する必要があります。すべての請負業者に要件やストーリーなど、持っているものをすべて渡すことができると想定することはできません。あなたは彼らが彼ら自身で何ができるか、そして彼らができないことを理解しなければなりません。
一度に多くの仕事を与えないでください。請負業者はあなたの会社に精通していないので、作業が正しい方向に進んでいることを確認するために、可能な限り隔週または毎週チェックする必要があります。
これがゼロからのプロジェクトである場合、次のようになります。
最初の会議の後、請負業者にあなたが期待するものの非常に最小限のプロトタイプを開発するように依頼してください。彼にビジネス要件を与え、彼をあまり縛らないでください。あなたは請負業者が自分でどれだけうまくできるかを見たいと思っています。そうすれば、彼にさらに指示を与えるときに、彼がすでに知っていることを彼に伝えたり、時間を無駄にしたりすることはありません。指示を実行する必要のある個人に合わせて指示を調整します。
プロジェクトが変更が必要な既存のプロジェクトである場合：
ビジネスの観点からプロジェクトを説明します。彼にプロジェクトを送って、彼に物事を準備させてください。彼にそれを1日か2日与えて、会議を設定します。質問し、説明し、コミュニケーションし、快適になり、信頼関係を築きます。
Rapportは、プロジェクト要件のどのセットよりもはるかに重要になります。結局のところ、あなたの関係は、その請負業者にプロジェクトを急いで修正するようにさせるか、それが素晴らしいことを確認するために余分な努力をすることになるでしょう。要件のコールドセットはあなたにそれを与えません。
初期段階を終えたら、会社への連絡係となる開発者の主任連絡先に請負業者を接続します。彼が質問をするならば、彼は彼にそれを解雇することができます。彼らは毎週会うべきです。 Citrix Go-To Meetingがこれに最適なソリューションであり、画面共有は必須です。
これで通信が確立されたので、アジャイルを実装したり、必要な機能の箇条書きリストを配布したりする場合は、それほど重要ではありません。人間が必要とし、期待する基本的なものに取って代わる方法論やシステムはありません。
私たちは最初に人間であり、次に開発者です。
ただし、これはドキュメントを送信しないという意味ではありません。集めることができる最高のドキュメントとプロジェクト要件を送信することをお勧めします。この男は真新しいです、そして彼は今泳がなければなりません。必ず救命具を投げてください。
アジャイルに移行することにした場合は、 ピボットトラッカー をお勧めします。
要件をどのように提示するかを決定するのではなく、最初に、できれば組織が許容できるコストとスケジュールの範囲内で、システムを構築する人を見つけることに焦点を合わせます。プロセスは、プロジェクトの目標、背景と動機、高レベルの要件を概説し、範囲内と範囲外の内容、および必要な成果物を正確に指定する高レベルの概要の作成から開始する必要があります。これが発生すると同時に、知的財産の所有権、NDA、下請け業者が必要とするあらゆる種類の規制順守などを決定するために法務も関与します。両方のドキュメントは、スケジュール、予算、リソース、さらにはいくつかのリスクに対処する提案を作成するために必要な情報を提供するために、潜在的な請負業者が利用できるようになります。
この時点で、それは交渉になります。期待に沿わない一連のコストやスケジュールが発生する可能性があります。その時点で、投資する意思があるものを再検討するか、プロジェクトのサイズと範囲を縮小する必要があります。情報を提供するために彼らが答えられる必要がある潜在的な請負業者からの他の質問があるかもしれません。プロジェクトを実行するために必要な詳細のいくつかを解決するために、ここで前後の期間があります。交渉に参加したことがない場合は、本を強くお勧めします ハーバード流交渉術：譲歩せずに合意を交渉する および ハーバード流交渉術：困難な状況で交渉する 。
あなたの基準に基づいて、あなたが請負業者を選択したら、関与のレベルは交渉されるものに依存します。私は個人的に、請負業者が要件を受け取り、定期的に、要求されたアーティファクトと成果物をドアの外に出荷する請負業者から、常にまたは定期的に現場にいる顧客と一緒にガラスの箱である請負業者まで、すべてを見てきました。開発プロセスに積極的に関与します。そして、真ん中には灰色の色合いがたくさんあり、顧客と請負業者の間でさまざまなレベルの関与があります。最終的に、それは顧客（あなたの組織）と請負業者の間の契約と合意に依存します。
あなたの組織が製品を受け取り、その製品の保守と開発を継続するとおっしゃっていたので、私は潜在的な請負業者の開発プロセスと品質保証の実践を精査するために余分な時間を費やします。また、契約期間中、プロセスと製品の可視性を最大化して、潜在的な問題を早期に発見し、是正措置を講じることができるように努めます。したがって、契約会社と協力して、プロジェクトに対する自分の役割と責任、および組織に対する責任の概要を説明する必要があります。しかし、私が言ったように、それは交渉なので、あなたが望むすべてのものを100％得ることができないかもしれません。
別のオプションは、あなたが彼らが働くためのリソースを持っていると仮定して、一時的な社内請負業者を雇うことです。彼らには、ある種のリード（私はあなただと思います）、コンピューター、ビルドサーバー、会議またはコラボレーション環境、デスクスペースなどが必要になります。あなたの組織はまた、候補者と面接し、おそらくあなたの組織内で一緒にうまく働く人々を見つけることに時間を費やさなければならないでしょう。ただし、将来的には正社員になる可能性もあります。
この状況では、開発プロセスを指示し、物事がどのように行われるかを細かく制御できます。ただし、対処する人やインフラストラクチャを追加するなどのコストもかかります。費用対効果が高い場合とそうでない場合がありますが、特にプロジェクトの過程で、またはプロジェクトの終了時に会社の拡大を検討している場合は、検討する必要があるかもしれません。将来の従業員が数人一緒に働いています。
自分のやり方で物事をやりたいと思うかもしれない独自のプロジェクト管理を持っている可能性が高いため、外部の契約会社にユーザーストーリーを配信することは意味がありません
あなたはクライアントであり、あなたは彼らに支払うことになります...彼らが何を得るかを彼らに伝えてください。また、要件がどの形式で提供されるかは特に重要ではないと思います。適切な開発者であれば、どちらでも作業できるはずです。
個人的には、大規模なコンサルタントではなく、数人の個別の請負業者/フリーランサーを雇うことを考えています。あなたはコンサルタントが雇ったであろうまさにその人々を雇うことになるかもしれません、それはただ安くなり、あなたは開発者とより緊密な関係を持つでしょう。