経験と知識は評価の基礎です

私は記事「 なぜプログラマーは期限を見積もるのに間違っているのですか？」を読みました。 「、それは私にいくつかのinりを引き起こしました。 残念ながら、コメントを残すことができないため、サンドボックスに記事を書くことにしました。



実際、「 なぜ...期限を見積もるのに間違っているのか？」という質問 »あらゆる生産活動に適用可能。 そして、省略記号の代わりに、誰でも指定できます（プログラマー、配管工、大工、錠前屋、菓子屋など）。 この質問は、顧客と請負業者の間の相互作用の問題の一部です。 この問題は、主に次の2つの質問で発生します。 「そして」 どのくらいの速さでそれをしますか？ 「。 これらの問題は知的生活そのものとして古く、非常に長い間関連しています。

これらの質問に対する答えの最も重要な特徴は、最小の時間と価格ではなく正確性です。 プロジェクトの成功（作業、順序など）を決定します。

著者はエラーの原因のリストを提供しますが、このリストは特別な場合にすぎません。 慎重に考えれば、さらに多くの理由を見つけることができます。 しかし、それらのすべては、複雑さを評価するために必要な経験および/または方法の不足の結果です。



これをサポートするために、著者が示した理由（および評価の精度を改善する方法に関する結論）を検討することを提案します。



1. 時間はきれいで汚れています。 他の業界と同様に、開発時間は、準備および最終イベントに費やした時間+直接作業時間+さまざまな損失の時間として定義されます。 準備最終時間は統計を使用して推定できますが、ほとんどの場合、どの作業でもほぼ同じです（10-15％の偏差）。しかし実際、ここではすべてがシンプルです。 この時間は、主な作業の時間と完全に相関していますが、組織ごとにこの依存関係は異なります。 組織の組織レベルおよび技術レベルに基づいて決定されます。 したがって、総時間の見積もりの​​精度を高めるために、準備最終時間の一連の調査を実施し、会社の組織レベルおよび技術レベルを決定する必要があります。 結論：標準化技術の知識が必要です。



2. パフォーマンス 。 議論することはまったくありません。生産性は一定でなければなりません。リーダーの主なタスクはこれを監視することです。 生産性が急上昇する場合、これは頭への重大なシグナルであり、おそらく従業員の潜在能力が高すぎて、彼ら（プログラマー）は必要なレベルを満たしていません。 ところで、それがさまざまな資格が企業に導入されている理由です（たとえば、第3レベルのターナー）。従業員の能力と生産性を示しています。 生産性は最も生産性の高い従業員によって決定され、他のすべての従業員に適用されることがよくありますが、これは常に正しいとは限りません。 結論：資格を明確に定義する必要がありますが、ここでは良い経験がなければできません。



3. 研究 。 この理由は、経験不足または知識不足が原因でのみ発生します。 そして、このような理由の出現は、設計段階がないことを示しているため、設計上の決定を下し、コーディングプロセスを調査する必要があります。当然、これにより開発時間が長くなります。 そして、設計段階の欠如は、開発者との経験の欠如を裏付けています。 結論：経験と資格を向上させます。



4. 複雑なシステム 。 これはまさに、専門家や労働投入を評価する方法が必要な場所です。 すべては専門家には明らかですが、方法論を選択する必要があります（おそらく独自の方法を開発する）。 たとえば、COCOMO / COCOMO IIまたはファンクションポイントメソッドを使用できますが、いずれにしても、それらを使用する機能が必要です。 独自の観察-システムが複雑になるほど、専門家の評価の精度は低下し、評価方法はより効果的かつ正確になります。 小さくて複雑でないシステムでは、評価手法は過大な誤差を与えます。 結論：専門家と評価方法が必要です。



5. エラーの修正 。 コーディングプロセスのエラーは、設計段階での欠陥です。 有能な設計能力は、経験を積むか、優れた教育機関で取得できます。 結論：デザインの経験または優れた教育が必要です。



6. 複合タスクと非標準タスク 。 著者は、そのようなタスクの評価はプログラマーの自信に基づいていると言います。 これは評価の重大なエラーです。 タスクにアプローチし、労力を正確に評価する方法がわからない-詐欺をせず、感情や直感に頼らないでください。彼らは間違いなくここで助けにはなりません。 このような状況のために、評価方法が開発されました。 結論：評価方法の知識が必要です。



7. 圧力下での評価 。 しかし、これはプログラマーの問題ではありません。 そして、ここで必要なのは開発経験ではなく、交渉経験ですが、まだ必要です。 結論：交渉の経験を積むことが必要です。



したがって、最初の質問「 プログラマーが期限を推定するのはなぜ間違っているのか？」に対する答えは 「とてもシンプル。 プログラマーは、必要な開発経験がないか、開発の複雑さを評価する方法を使用できないため、誤解されています。 そして、他のすべてはこれらの理由の結果です。

一般的に、この記事はウェブ業界の現在の状況を完全に説明しています。 新しいWebプログラマーは、雨の後はキノコのように見えます。 そのような開発者の経験は最小限であり、知識は限定的であり、野心と自信過剰です。 これらはすべて、用語の見積もりに間違い（労力）を強いることになりますが、残念なことに、それらの間違いはプログラマーのコミュニティ（そしてウェブだけでなく）の評判を台無しにします。 したがって、初心者の間違いを業界全体の問題として認識することは価値がないと思います。 プログラマーにタイミングについて質問する前に、彼の経験と知識を判断する必要があります。 そして、これは全く異なる話です。



PS 私はすべての私の推論の絶対的な真実であるふりをしません。 しかし、すでに述べたように、複雑さを評価する問題は、生産活動のすべての分野にあります。 科学学校「 複雑な技術システムのモデリング 」でほぼ20年間、労働集約性の分野でさまざまな問題に取り組んできました。その一部は、労働集約性評価に関連し、構造的および技術的複雑性の理論に基づいています。 残念ながら、私たちの仕事はすべて機械工学に焦点を当てていますが、ソフトウェア業界でも労働強度評価の状況はまったく同じであることを保証します。 2年前、私はソフトウェアプロジェクトの複雑さを評価する問題に取り組みましたが、まだ結果はありませんが、現在の状況を分析および研究するプロセスは進行中です。 現在、ソフトウェア製品の製造の複雑さを評価する際に、既存の方法の有効性を決定する問題と、構造的および技術的複雑さの理論の要素（複雑さの理論と呼ぶ）を使用する可能性を解決しています。

複雑性理論の本質は、オブジェクトの複雑性を定量化する指標を決定することです。 次に、企業の組織および技術レベルに基づいて、特定の生産条件で労働集約度が決定されます。 私はこれ以上説明しません、なぜなら それは完全に異なる地域からです。