ソフトウェア開発タスクの見積もりが定期的に2〜3倍ずれているのはなぜですか？
これはQuoraの質問に対する答えです：なぜ見積もりが正確でないのですか？
これにはいくつかの要因があります。 ここにいくつかの一般的なものがあります：
1）クライアントは技術的ではなく、「すべてが簡単」だと感じています
ソフトウェアの開発は見た目ほど簡単ではありません。
簡単に見えますが、特定のタスクを省略した方がよい場合があります。
- 例えれば、次のようになります。
巨大な丘があり、線路を建設する必要があります。 開発者は次のようにアドバイスします。「丘を避け、丘の周りにトラックを構築することをお勧めします。このようにして、5か月の追加作業を節約できます。」
ここでは、丘を通り抜けるトンネルを掘削するのにはるかに時間がかかり、クライアントが「回避策」に同意することは明らかです。
- それでは、ソフトウェア開発を見てみましょう。
開発者は次のように述べています。「1つの画面サイズのモバイルバージョンと1つの画面サイズのデスクトップバージョンを1つだけ持つ方がよいでしょう。モバイルアプリを使用しないようにする必要があります。また、完全にレスポンシブデザインを使用することも避けてください。
ここで、クライアントはおそらく次のように言うでしょう。他のWebサイトも応答性が高く、すべての画面サイズに変更できます。簡単な作業です。」
しかし：開発者がこれを提案した理由はいくつかあります。 レスポンシブデザインは見栄えが悪く、プロフェッショナルではないかもしれません。 特に一部のボタンは簡単に悪性化する可能性があります。
だから今何が起こるかというと、開発者は 1）レスポンシブなページを作成し、 2）時間が増加します。
- 時間の増加については、クライアントは受け入れません。簡単ですよね？」
- タスクが完了すると、クライアントは自分の携帯電話でWebサイトを見て、次のように言います。「携帯電話でサイトを確認すると、すべてがずれています。どうして？私はもっと多くを支払いました、そして今これ？」
クライアントが以前の方法（応答なし、バージョンが2つしかない）に同意した場合、Webサイトはより安価になり（時間も短縮され）、ほぼすべてのモバイル画面とデスクトップブラウザーで問題なく動作します。
ここでの主な問題も次のとおりです。誰かと議論するのは良くありません。 特にクライアントと議論するのは良い考えではありません。 したがって、開発者/サービスプロバイダーは常に「はい、その通りです。そのようにしましょう」と言います。
そして、クライアントが本当に満足していない場合、開発者は再び責任を負う必要があります（ただし、それが自分のせいではないことはわかっていますが、要件はそのような方法でした）。
2）正確に見積もるのに時間がかかることはありません
現実の世界では、ソフトウェア会社は毎日または毎週ソフトウェアアプリケーションの要求を受け取ります。
すべてのリクエストが正確に見積もられる場合、開発者は正確な見積もりを作成する以外に何もする必要はありません。 これらの正確な見積もりを作成するには非常に時間がかかるため、実際のプロジェクトに取り組むことはできません。
つまり、実際に何が起こるかというと、彼らはプロジェクトを見て、必要な時間を「見積もり」ます。 それが正確ではないので、それが「見積もり」と呼ばれる理由です。
また、クライアント自体は、要件を指定するために1週間以上待つことに関心がありません。 最大5ページのドキュメントが作成され、それが開発の基礎になります。
3）プロジェクト中にすべての要件が変更されます
私は引用するのが好きですアンドリューローズこの記事の冒頭からのQuoraスレッド/リンクから：
「プロジェクトがどんなに大きくても小さくても、プロジェクトを開始した後は常に何かが浮かび上がります。多くの可能性がありますが、多くのことが起こります。それはただの獣の性質です。プロダクトマネージャーとしてのあなたの仕事は、顧客と協力して、顧客が必要とし、喜んでお金を払うものを考え出すことです。また、開発者の助けを借りて合理的に提供できるものを考え出す必要があります。これらの目標を達成するために作業するとき、範囲の変更、不正確な時間の見積もり、そして場合によっては、プロジェクトを完了するために働いている人々の変更に遭遇します。」
プロジェクト中に多くのことが変わります。 アンドリューが述べたように、要件が変わるだけではありません。 人々でさえ、現在のプロジェクトが完了する前に他のプロジェクトに入る可能性があります。
ここに例え：
100メートルのスプリンターは10年間トレーニングを行い、10秒未満で100メートルを走ります。
スプリントの日に、クライアントは、途中で5つのハードルも必要だと言います。
次に、スプリンターは「しかし、10秒未満で実行することはできません」と言い、クライアントは「過去10年間に何をトレーニングしたのか、親切に10秒未満で実行してください」と言います。
これはソフトウェアプロジェクトでも同じです。 クライアントとプロジェクトマネージャーは、「ああ、この非常に重要な機能を忘れてしまったので、新しい要件を持ち込むでしょう。ソフトウェアに含まれている必要があります。含まれていないと、役に立ちません。」
これらの要件の変更は、通常、プロジェクト全体で行われます。 それは、スプリンターの邪魔になる池、壁、はしごなどを追加するようなもので、彼/彼女がまだ10秒以内にそれを行うことを期待しています。
4）アーキテクチャが適切にチェックされていない
特に、物事が最初から行われず、サードパーティのツール（WordPress、TYPO3、Drupal、Magento、Shopwareなど）が使用されている場合は、それらをカスタマイズして、特定のことを実行する必要があります。間違った見積もり。
これらのサードパーティツールでは、必要なものすべてを変更することはできません。 URL構造などの単純なものに従う必要があります。
このテキストのポイント1）のように、すべてを簡単に実装できるわけではありません。 サードパーティシステムの現在のアーキテクチャが特定の機能をサポートしていないことが判明したら、その特定の機能を避け、同じ仕事をするが既存のアーキテクチャを使用する回避策を使用することをお勧めします。
注：この問題/問題は、プロジェクトがPHP、ASP.NET、Laravel、Zend、Symfony、Java、Ruby on Rails、Node.Jsなどのツールを使用してゼロから実行され、いくつかの初期の誤った仮定がある場合にも発生します。システムのアーキテクチャについて作成されました。
5）「一文」または「一言」ショーストッパー
クライアントから提供される5ページのドキュメントの例についてはすでに説明しました。 開発がほぼ終了するか進行中になると、クライアントは次のように言います。「重要な機能が不足しています。 3ページの22行目には、レポートツールが必要であると記載されています。」
ただし、このレポートツールの作成は、ドキュメントで簡単に説明されていますが、それ自体がプロジェクト全体と同じ量を要します。 また、ドキュメントには「レポートツール」が記載されているため、クライアントはもちろんその実装を主張します。
6）プロジェクトに勝つ
多くの企業が同じプロジェクトに入札していると感じているとしましょう。 今、あなたは間違いなく最高の時間を請求する提案になりたくありません。 あなたは最も少ない時間数を示す人になりたいです。 クライアントが100時間から500時間の間で選択できる場合、間違いなく誰もが100時間を選択します。
実際には、理想的な世界では、誰もが同じ時間数を必要とします。 したがって、100時間と見積もられたとしても、最終的には500時間になります。
7）不明/待機時間
ソフトウェアプロジェクトにはいくつかの未知数があります。
- a）テクノロジーの変更：開発ツールの1つ（Androidなど）がメジャーアップデートを取得した場合、それらのテクノロジーの変更を組み込むために、さらに作業を行う必要があります。
- b）チームメンバーの経験：シニア開発者がプロジェクトに取り組んでいる場合、それはより短い時間で済み、ジュニア開発者である場合、それはおそらくより多くの時間を要します。
- c）フィードバックが遅れる：クライアントは通常、プロジェクトにあまり興味がなく、素晴らしい結果を望んでいます。 そのため、プロジェクト中にクライアントに連絡があった場合、クライアントは1時間以内に返信することをいとわない可能性があります。 数日かかる場合があります。 その間、プロジェクトはアイドル状態になり、応答の遅延のために開発者がアイドル状態になっている場合、サービスプロバイダーはその時間中に何時間も請求する可能性があります。
8）プロジェクトが大きすぎて正しく見積もることができない
タスクが1つであり、数か月の期間にわたって複数の開発者が必要であると仮定しましょう。
正しい見積もりを得るために、このような小さな作業の塊にタスクを分割することはほとんど不可能です。
もちろん、この記事で言及されている他のことも役割を果たします。
結論
最善のアプローチは次のとおりです。
- おおよその見積もりをする
- プロジェクトに時間がかかりすぎて時間がかかる場合は、機能を減らすのが最善であることに言及します（たとえば、機能の優先リストを作成し、最も重要なものだけを実行します）
- 開発と請求にアジャイル手法を使用する
正確な価格/時間を必要とする場合、それは通常、数週間続く小規模なプロジェクトでのみ可能です。
トピックに関するその他の興味深い記事：
ソフトウェア開発プロジェクトを工数で現実的に見積もる方法
ソフトウェア開発時間の見積もりが機能しない理由と代替アプローチ
画像ソース：Flickr.com/ Michael Kappel / Judit Klein / Markus Spiske
著者：Sascha Thattilは、YUHIROグループの一員であるSoftware-Developer-India.comで働いています。 YUHIROは、IT企業、代理店、IT部門にプログラマーを提供するドイツとインドの企業です。
コメントを残す