ソフトウェア開発プロジェクトの人件費の評価：ウクライナの現実の実践

エントリー

少し前に完了したこのプロジェクトは、私にこの記事を書くように促しました。 他のプロジェクトと同様に、エラー（評価中も含む）、問題とそれらに対する興味深い解決策、そしてすべてにもかかわらず、チームの士気、プロジェクトを時間通りに提出したいという願望、および処理が含まれていましたプロジェクトの期日内の配信、および待望の休暇。 これはすべて別の記事に値します。 しかし、主なことは、この記事の作成に基づいた貴重な経験でした。

多くの場合、プロジェクトを評価し、非常に間違っています。 そして、それはプロジェクトの過程で現れる小さなもののためですが、実際には事前に検出して考慮することができます。

この記事には、シンプルであると同時に有用な推奨事項とプロジェクトの人件費見積もりの​​計算方法が含まれており、プロジェクトマネージャー、アーキテクト、システムアナリスト、ITソリューション販売者、および固定価格プロジェクトの作業の評価に関与するすべての人にとって興味深いものです。

この記事では、プロジェクトで作業する人件費の評価のみを扱いますが、実装期間と費用の評価はまったく別の話です。

この記事では、プロジェクトの評価における私の個人的な経験を説明し、

もちろん、あなたは他の状況とあなたの方法を持つことができます

評価の推奨事項。

記事の本質、意味、および「精神」をよりよく理解するために、最初に確認することをお勧めします。

• Sergey Martynenkoによるプレゼンテーション「テスト要件の形式としてのテストの記述」 [1]。これについては、この記事の中で頻繁に参照します。 正しく定式化された目標と要件は、プロジェクトの成功にとって大きく重要なステップであることを理解することが重要です。
  
  
• セルゲイ・ベレズノイによるプレゼンテーション
  
  「私の物語：残業の道」 [2]。 概して、このプレゼンテーションには記事のトピックは含まれていませんが、人件費の誤った見積もりに関連しています。
  
  

この記事には次のセクションが含まれています。

• プロジェクトの実施におけるウクライナの現実
• 問題と解決策
• 評価の準備
• 評価のための作品リスト
• コード記述評価
• 練習からの数字と係数
• 計算例

プロジェクトの実施におけるウクライナの現実

国内市場では固定価格プロジェクトが優先されます（契約の締結時に、予算と時間が事前に計画されている場合）。 プロジェクトを評価する際、チームは標準的なリスクと問題に加えて、組み合わせたい顧客の「現代的で効果的な」アプローチを考慮する必要があります。

• 一方では、ToRを作成する前に予算と条件の正確な推定値を取得し、それらを契約に含めてから、プロジェクトを実施するときに、この予算と条件を厳密に制御します。
• 2番目-開発チームの柔軟性、プロジェクト中に表示されるすべての顧客要件の実装（顧客はしばしばプロジェクトの途中まで自分が望むものを知らないため）。
• 第三に、何をどのように実装すべきかについての誤解にもかかわらず、彼らはチームがまだ実行しなければならない機能を含めて、プロジェクト計画のタスクを容赦なく「削減」します。

プロジェクト管理が失敗した場合（チームが顧客の要求に従っている場合）、チームは時間と予算を簡単に超過します。 契約が締結され、予算が合意されると、損失が発生します。

顧客だけを非難するのは間違いです。 プロジェクトの評価は、要件を十分に分析せずに実行されることが多いこと、タスクが適切かつ誤って記述されていないこと、非常に多くの場合、評価に含まれるのはプログラミングだけであり、テストと管理が不十分な量であることを理解する必要があります。 契約が締結されると、売り手は顧客に向かって価格を引き下げます。プロジェクト中、チームは自分の立場をしっかりと擁護しません（プロジェクトマネージャーは何よりも重要ですが、この場合はすべての参加者が結果に集中し、参加者が問題を見た/予想した場合、彼は頭に報告されなければなりません）。

さらに、別の要因があります-プロジェクト、システム、および技術の多様性、および資格のある専門家の不足。 これは、プロジェクトを計画する際に、アーキテクトまたはプロジェクトマネージャーが、以前にそのようなタスクを実行したことがないチームのスペシャリストまたは資格が不十分なスペシャリストを取得することを考慮しない可能性があることを意味します。 この場合、パフォーマンスが予想よりも低くなることは明らかです。

この状況で何ができますか？ 推定人件費が十分に正確になるようにプロジェクトを評価する方法は？

まず、問題を検討し、解決策を見つけてください。

問題と解決策

1.顧客は、契約に署名する前に、プロジェクトのコストと条件の正確な数値を知りたい

解決策：

1.1。 受け入れ基準を特定して策定します。 どうやってやるの？ [1]を参照してください。 一番下の行は、顧客が適切な質問をする必要があるということです：「プロジェクトが成功したことをどのように知っていますか？」そして「誰が、誰に、どのようにシステムを引き継ぐか？」、そして質問に対する答えを得ることに決める人にプロジェクトを承認する ''

1.2。 プロジェクトの要件と最も重要な制限をできるだけ多く特定します（つまり、機能的な要件だけでなく、機能的な要件も特定しません）

1.3。 要件をテストします。 簡単に言えば、文書化された要件が現実的で一貫性があり、定式化されていることを検証して、ソリューションがそれらに一致するかどうかを明確に検証できるようにする必要があります。 繰り返しますが、私は[1]を見ることをお勧めします

1.4。 これに基づいて、可能な限り詳細なタスクのリストをペイントします（記事の詳細を参照）

2.顧客は、プロジェクトのコストを調整するときに、最初の機会に最も不適切な方法で削減する、多少詳細な作業リストを表示したい

解決策：

作業面では、「目に見える」タスクだけでなく、すべてのタスクを強調することが重要です

たとえば、特定のデータを表示するためのユーザー要件があります。 チームは、どのタスクを実装する必要があるかを特定し、56時間で総作業量を推定し、次のように分類しました。

• すべてのレコードを表示する機能-8時間
  
  
• フィールド1〜8時間によるフィルタリングの可能性
  
  
• フィールド2〜8時間によるフィルタリングの可能性
  
  
• フィールド1〜8時間で並べ替え
  
  
• フィールド2〜8時間で並べ替え
  
  
• フィールド1〜8時間でグループ化
  
  
• フィールド2〜8時間でグループ化
  
  

しかし実際には、これらのタスクの下には、データベース内のテーブルの作成、選択用のストアドプロシージャまたはビューの作成、ビジネスオブジェクトの作成、セキュリティモジュールへの接続、ロギングモジュールへの接続、構成などの基本的な機能があります。

お客様から「いいえ、長すぎます」と言われたらどうなりますか。 グループ化と並べ替えのタスクを減らして削除しましょう（マイナス32時間）。 同時に、プロジェクトの作業を議論している売り手は「カバーするものがありません」。 一方、24時間では、原則としてボリューム全体に時間がありません。

したがって、タスク全体を削除することによってのみ削除できる基本機能を強調表示することをお勧めします。 この例では、このタスク「データベースからのデータの取得」には、たとえば28時間かかり、残りのタスクにはそれぞれ4時間かかります。

これにより、売り手は同じチームを代用することなく、入札中により正確に行動することができます。 不要な機能を削除しても、開発に十分な時間が残っています。

3.契約の署名後に、要件の詳細な分析、技術仕様の作成、およびプロジェクトに関する作業の多かれ少なかれ明確な領域が発生します。

解決策：

3.1。 システムに実装する必要があるプロジェクトの要件と制限をできるだけ多く特定し、各要件をどのように正しく策定および検証するかを確認します[1]。

3.2。 非常に頻繁に、顧客が削除したアイテムがポップアップして実行する必要があることが判明しているため、プロジェクト計画に加えて、あなた自身を保護するために、プロジェクトの範囲を制限するアイテムも追加する必要があります。 これには、顧客が提案された計画から削除したすべてのアイテム、およびチームがプロジェクトの範囲外であると明確に認識および検討するその他のアイテムが含まれている必要があります。 すべてのソフトウェア開発方法論はこれに焦点を合わせています。 実際、これは契約の付属書として、または技術的な割り当ての一部として正式化できます。

3.3。 顧客が行うべき作業を決定することは非常に重要です。 また、これは期限内に契約で修正する必要があります（契約の付属書、参照条件）

4.プロジェクトのほぼ半ばまで、顧客自身は自分が何を望んでいるかを知りません（要件を収集する段階は言うまでもありません）

解決策：

4.1。 変更の可能性のある時間枠を含めます（つまり、原則として、変更のどの段階で可能か）

4.2。 定期的なデモンストレーションをスケジュールします（たとえば、要件の収集と計画の段階-週に1回、開発段階-2週間に1回）;それらを準備および実施するための人件費を考慮します

デモンストレーションは、ビジネス顧客だけでなく、プロジェクトに潜在的に関与する他の顧客部門の従業員（システム管理者、キーユーザー、セキュリティなど）に対しても開催する必要があります。

これにより、初期段階でコメントを受け取り、問題を話し合い、ユーザーがインターフェイスと機能に慣れることができます。

5.顧客は、チームが希望（変更、追加）に柔軟にアプローチし、プロジェクトのフレームワーク内でそれらを実装し、その後の改善の一部としてではなく、プロジェクト予算の変更についてまったく聞きたくない

解決策：

5.1。 プロジェクトプランに変更の可能性がある時間を明示的に含め（リスクから時間と予算にバッファーを置きます）、顧客の要求に応じて、必要な変更と改善に費やします。 これにより、第1に、プロジェクトのフレームワーク内で変更に取り組むことが可能になり、第2に、顧客が変更要求を慎重に検討するように強制されます。 このリソースはすでに明確に制限されています

5.2。 開発への反復アプローチの可能性を考慮し、これらの反復を計画します。 会議、配達、デモンストレーションなどの回数を考慮してください。

5.3。 上記のように、契約には（契約の付属書として、または参照条件として）、プロジェクトの範囲を超え、顧客が明らかに拒否したすべてを記述する条項が含まれています。

6.顧客は、システムに関する多くのドキュメントを見たいと考えています。

解決策：

プロジェクトのコストの計算には、ドキュメント作成のコストが含まれます（以下で説明するように、金額は相当な額になることがあります）

7.プロジェクトチームが再編成された場合、スペシャリストの資格が予想よりも低くなるリスクがあります。

解決策

実装のタスクと時間を計画するとき、プロジェクトに関与すると予想されるよりも低いレベルの専門家に焦点を合わせる必要があります。

8. ITテクノロジーとタスクはますます難しくなり、プロジェクトの初期段階で選択されたテクノロジーの落とし穴を特定することがますます難しくなっています。

解決策：

8.1。 リスクのために一定の時間を計画に組み込む必要があり、チームはその裁量でそれを使用できます



8.2。 できるだけ早く、危険な技術に関連するタスクを実行します

どこから始めるか

1. 前に書いたように、プロジェクトの目標を達成するために何をする必要があるかを理解し、合格します[1]
2. プロジェクトの要件と制限をできるだけ多く特定します。 次の要件を必ず確認してください。
   
   a。 ドキュメンテーション ソフトウェアに関するドキュメントの種類がわからない場合は、たとえば、GOST（ESPD）19.101-77「プログラムの種類とプログラムドキュメント」[3]または他の方法論の仕様を参照し、これに基づいて顧客にリストを提供できます。権利を選択できるようになります
   
   b。 非機能要件[4]。たとえば、ローカリゼーション、バックアップ、監視、ロギング、セキュリティ、データ移行、初期データのアップロード、インストール要件、構成要件など。
   
   この情報は、カスタマーサポートおよびセキュリティITサービスから取得できます。
3. 受け取った要件をテストする[1]
4. 各タスクにかなりの期限が設定されるように、タスクのリストをできるだけ詳細に説明してください。 たとえば、プロジェクト評価の段階で、タスクを1日まで分解して評価できます。
5. 評価には、プロジェクトマネージャー、開発者、テストエンジニア、展開および実装のスペシャリスト、使いやすさのスペシャリスト、製品管理のスペシャリスト（製品マネージャー、同じアナリスト）のさまざまな分野のスペシャリストが参加する必要があります。

評価のための作品リスト

特定の数値と係数に進む前に、タスクのリストに含める必要があるタスクを検討してください

分析のフェーズと要件の収集

• インタビューを行い、結果を報告するための顧客との会議
  
  
• 要件ドキュメントの作成
  
  
• 要件テスト
  
  
• プロジェクトを開始する契約書およびその他の文書の作成と承認
  
  

ソリューション設計

• TKライティング
• ソリューションアーキテクチャの記述
• TKおよびソリューションアーキテクチャのテスト
• サブジェクトドメイントレーニング
• 開発環境とテスト環境をインストールする
• テスト計画とシステムテストオプションの作成
• 顧客との打ち合わせ

開発および内部テスト

• 毎週の開発者会議
• プログラミング
• コード改善
• デモンストレーション（準備と実施）
• テスト環境でのソリューションの最初のインストール
• テストケースに合格

顧客テスト

• 顧客テスト環境での最初のインストール
• ベータ版配信
• 故障の確定と修正

実装

• 実稼働サーバーへのインストール
• ユーザートレーニング
• 指示を書く

オプショナル

• リスクの時
• 変化の時
• プロジェクト管理

最初のステップは、ソリューションのプログラミングの期間を評価することです。その後、プロジェクトの全期間を計算するために追加の要因と仮定を適用できます。

コード記述評価

開発作業を評価するには、次のルールに従うことをお勧めします。



*プロジェクトの目標を達成するには、ユーザーアクションに分割します。ユーザーアクションはタスクに分割され、タスクはサブタスクなどになります。 など、各タスクがジュニア開発者レベルの人に理解可能になり、その実装を検証する方法について明確な基準を持つまで



*除外できない基本的なタスクを強調することを忘れないでください

次のタスクを考慮することを忘れないでください。

• インストールユーティリティの作成
• 構成ユーティリティの作成（初期セットアップ、システム設定、セキュリティ設定のいくつかがあります）
  
  
• プライマリデータ入力ユーティリティと、場合によっては新しいバージョンへの移行ユーティリティの作成
  
  
• 診断ユーティリティの作成（すべてが正しくインストールされているかどうかを確認し、誤動作を特定するのに役立つユーティリティ）
  
  
• ロギングモジュールの作成。 顧客がそれを必要としない場合でも、エラーや欠点を特定するのに非常に役立ちます。
  
  
• セキュリティモジュールの作成

練習からの数字と係数

• プロジェクトに新しい人を紹介し、彼の開発環境をインストールするには、少なくとも40時間（1週間）を計画します
• 毎週の開発者ミーティング-開発者ごとに毎週4時間
• テストサーバーへのソリューションの初期インストール-80時間（2週間）を計画する
• 各デモンストレーションの準備-8時間（アーキテクトがデモンストレーションの前にモジュールをビルドおよびテストするのにかかる時間;プロジェクトに3人の開発者がいる場合、さらに開発者がいる場合は8時間）
• 顧客とのミーティング（デモ）-各ミーティングは4時間（私の経験では、プロジェクトマネージャー、アーキテクト、アナリスト、またはテストスペシャリストの3人のミーティングに行く方が良いです）
• 顧客のテスト環境での最初のインストール-40時間
• 顧客の作業環境への最初のインストール-40時間
• 各配信の準備と発送-8時間（これには、コンパイル、パッケージ化、インストールプロセスの記述、インストール支援が含まれます）
• 不具合のファイナライズと修正（リファクタリング）-開発の25％
• 開発に費やされた時間の30〜50％をテストするためのタスク（要件ドキュメントの開発、技術仕様、機能などの開発）
• リスクの時間-合計時間の少なくとも10％
• 変更時間-合計時間の少なくとも10％
• プロジェクト管理-総プロジェクト時間の15％
• 不具合の確定と修正-開発時間の25％
• アナリストは、1日に平均3ページの承認済みドキュメントを作成します

計算例

評価の結果、いくつかの数値が得られたと仮定します

• 開発タスク（設計を含む）を分析した結果、1,200の工数が得られました。
  
  3人の開発者が開発作業を行うことにします。 その後、開発作業には10週間かかります。
• 要件、参照条件、ソリューションアーキテクチャ、ユーザーの指示などを含む多くのドキュメントを作成および調整する必要があります。 総正味出力量-400ページ
• アプリケーションには複雑なビジネスロジックがあるため、多くのテストがあります（したがって、開発の40％を要します）
• 顧客との5回のミーティングを計画して、要件を特定します
• お客様との3回のミーティングを計画して、ビジョンと決定案を調整します
• 開発段階で4つの製品デモを顧客に計画します
• お客様のテスト環境への10回の配送を計画しています

これに基づいて、この評価では次のチーム構成に焦点を当てることにします。

• 3人の開発者
• 1人のテストエンジニア
• 1名のビジネスアナリスト
• 1人のシステムアナリスト（建築家、インフラストラクチャタスクも実行します）
• 1人のプロジェクトマネージャー

次に、タスクと完了するまでの時間について説明します。 同時に、ドキュメントの作成とそのテストに関連するタスクのセルは空です。テーブルの下部には、400ページのドキュメントの作成に基づいた概要情報を含む単一のフィールドがあります。

タスク	役割	人数	時間	合計
分析のフェーズと要件の収集
インタビューを行い、結果を報告するための顧客との会議	ヘッド、アナリスト、アーキテクト	3	5回×4時間	60
要件ドキュメントの作成	アナリスト、アーキテクト
要件テスト	テストエンジニア
プロジェクトを開始する契約書およびその他の文書の作成と承認	プロジェクトマネージャー	1
ソリューション設計
TKライティング	アナリスト、アーキテクト
ソリューションアーキテクチャの記述	建築家	1	40	40
TKおよびソリューションアーキテクチャのテスト	テストエンジニア
サブジェクトドメイントレーニング	全部	7	40	280
開発環境をインストールする	建築家、開発者	4	16	64
テスト環境のセットアップ	テストエンジニアまたはアーキテクト	1	40	40
テスト計画とシステムテストオプションの作成	テストエンジニア
顧客との打ち合わせ	ヘッド、アナリスト、アーキテクト	3	3回×4時間	36
開発および内部テスト
毎週の開発者会議	建築家、開発者	4	4時間の会議10回	160
プログラミング	開発者	3	400	1200
コード改善	建築家	1	3 x 100	300
デモ準備	建築家	1	8時間の4つのデモンストレーション	32
デモを開催する	アーキテクト、プロジェクトマネージャー、アナリスト	3	3×4	36
テストエンジニアのタスク（テストケースに合格）、開発の40％	テストエンジニア	1		480
テスト環境でのソリューションの最初のインストール	テストの専門家または建築家	1	80	80
顧客テスト
顧客テスト環境での最初のインストール	建築家	1		40
ベータ版配信	建築家	1	8時間で10回の配達	80
不具合の確定と修正（開発の25％）	開発者	2		300
実装
実稼働サーバーへのインストール	建築家			40
ユーザートレーニング（各4時間のトレーニングを3回行ってみましょう）	アナリスト	1	3×4	12
指示を書く	アナリスト
ドキュメントを書く	パートアナリスト、パートアーキテクト		135日、3ページ	1080
ドキュメントのテスト	テストエンジニア		彼女の文章の30％	320
合計				4680
オプショナル
リスクの時間			開発の10％	120
変化の時			開発の10％	120
プロジェクト管理	プロジェクトマネージャー		プロジェクトの15％	700
合計		約5620時間

得られたデータに基づくと、開発タスク自体の評価（1200時間）は、総人件費よりもはるかに少ない（4回以上）。



コードのテストと最適化、ドキュメントの作成、プロジェクトへの専門家の紹介（作業環境の設定を含む）、プロジェクトの管理に多大な時間が費やされます。

おわりに

これらの計算は、労働強度の定義に関する私の実践であり、観察であると繰り返します（記事ではプロジェクトの期間と予算の推定については説明していません）。したがって、作業の複雑さを評価するための独自の経験と方法と推奨事項があります

この手法を改善するための重要なレビューとコメントを聞いてうれしく思います。



この記事が、プロジェクトを合理的かつ明確に評価し、プロジェクトの人件費に影響を与える可能性のある「些細なこと」をできるだけ多く考慮に入れることを願っています。



このトピックについてもっと知ることができますか？ リンクのセクションをご覧ください。

参照資料

1. Sergey Martynenko「テスト要件の形式としてのテストの作成」 http://vimeo.com/13803733



2.セルゲイ・ベレズノイ「私の物語：「残業の道」



3. GOST（ESPD）19.101-77「プログラムとプログラムドキュメントの種類」 http://www.rugost.com/index.php?option=com_content&task=view&id=48&Itemid=50



4.ナタリア・ゼルノバ。 機能しないソフトウェア要件：それらを決定する方法と番号を取得する場所

akiselev87.wordpress.com/2011/07/14/natalia-zhelnova- non-functional-mp

5. S. Arkhipenkov「ソフトウェア開発の複雑さとタイミングの評価」 http://www.arkhipenkov.ru/resources/sw_project_estimation.pdf



6.ソフトウェア開発の複雑さを評価する際の10の大罪http://leopard.in.ua/2010/03/22/desyat-smertnyx-grexov-v-ocenke-trudoyomkosti-razrabotki-programmnogo-obespecheniya/



7.ミハイル・オストロゴルスキー「技術文書作成のタイミングを評価するアプローチ」 http://www.philosoft.ru/metrics-idea.zhtml



8. Sergey Povolyashko「テスト中の労働と計画」 http://qaclub.com.ua/wp-content/uploads/d/qaclub6_19-02-10/QAClub_TestEffortsPlanning.pdf