すべての職務記述のレビューの一環として、私の会社は以下を主要な出力として含めることにしました。

ウェブサイトの開発は仕様どおりに、エラーフリーで時間通りに完了しました

仕様が定期的に変更されることを考えると、正式な変更管理プロセスはなく、環境は少し予測不可能ですが、このKPIはどれほど現実的で妥当ですか？

「エラーフリー」はあまりにも主観的です。一人の男の「満たされていない機能要求」は別の男の「エラー」です。「実質的に設計仕様を満たすべき」のようなものがより適切でしょう。あなたが仕事の説明で何を説明しているのか、私は実際に見たことがありません。契約作業では見ましたが、従業員では見ていません。

私はほとんどの答えに反対の立場をとり、それは絶対に合理的かつ現実的であると言います。

すべての開発は予定どおりに完了しますか？もちろん、そうとは限りません。

すべての開発は仕様の範囲内で完了しますか？あなたはそう望んでいますが、時にはそれが単に不可能であり、不可能または自己矛盾する仕様からの逸脱を報告しなければならないことがあります。

そして、すべての開発にエラーはありませんか？決して。

しかし、それがKPIの目的です。これは測定可能であり、パフォーマンスと進行状況を追跡できます。

仕様が定期的に変更される場合、正式な変更管理プロセスはなく、環境は予測できません。この数値を「エラーなし」に近づけるのは困難です。しかし、その課題はあなたの仕事であり、会社独自のカオスの特定のフレーバーを管理するための練習が増えるにつれて、うまくいけばかなりうまくいくでしょう。

反問：プログラマーにどんなKPI を提案しますか？難しいです。私たちの活動の多くは測定が困難です。

それが仕事の説明であれば、エラーのないコードに向けて取り組むことは典型的なプログラマーの仕事の一部であるため（私たちがそれを達成できなくても）、私はそれについてあまり心配しません。

ただし、KPIとしては到達範囲が広すぎますが、プログラマーでない場合は、それを提案した人物を責めないでください。その声明が組織にとって望ましくないかもしれない目標を設定していることを説明してください。つまり、「エラーなし」は、ソフトウェアを実際に配信するにはかなりの費用がかかる非常に高い基準です。適切に稼働するソフトウェアプロジェクトでは、各欠陥が開発者の貴重な時間を費やす価値があるかどうかについて決定を下す必要があることを説明します。

ここでポイントをうまく説明する例を示します。
プログラマーは、私たちのソフトウェアに「3000年」のバグがあり、2999年12月31日をもって機能しなくなることを発見しました。問題の修正には6〜8か月かかります。KPIに基づいて、会社に真の価値がないにもかかわらず、このプロジェクトに取り組むことをお勧めします。

わかりましたので、その例は少し極端ですが、どのソフトウェアプロジェクトでも、文字通り何十もの小さな欠陥が発見され、同様にそれらを修正するために必要なROIを生成しません。代わりに、KPIがプログラマーが欠陥を最初から導入しないことを暗示することを意図していた場合、従業員が自分の仕事のパフォーマンスを決して失敗しないという基準に拘束されることは理にかなっていますか？

番号

それは適切ではないだけでなく、滑稽です

テストではエラーの存在のみを証明でき、エラーがないことを証明できるため、この契約の下で作成されたすべてのプログラムには、正確性の厳密な証明と 100％のテストカバレッジを含める必要があります。

「上のコードのバグに注意してください。私はそれが正しいことを証明しただけで、試したわけではありません。」-D.クヌース

もちろん、エラーのないコードを書くことは、すべてのプログラマの仕事と責任です。それは完全に合理的な期待です。機能しないコードをリリースした場合、どのようにしてプロのプログラマーになれますか？どのようにあなたはあなたがいないことをコードリリースする場合は、自分自身がプロのプログラマーであることを考慮することができます知っている作品？

あなたが画家を雇うなら、彼は彼の仕事をうまくやることを期待します。あなたは彼の仕事の結果に誤りがないと期待しています。エラーがある場合、あなたは彼がそれらのエラーに責任を持ち、無料でそれらを修正することを期待します。その上、エラーがあなたにお金を要するならば、あなたは彼があなたに返済することを期待します。なぜあなたはこれらの期待を持っていますか？画家はプロだから。

プログラマーはエラーを他のすべての人のせいにするのが大好きです。「要件、スケジュール、または月が8番目の家にあるため、私のプログラムにはバグがあります」しかし、他に責任のある人はいません。プログラムにエラーがある場合は、そこに配置します。

私たちの職業は、プログラマーがお金でやめることを理解するまで職業にはなりません。その彼らは自分たちのプログラムの品質を担当しています。

企業がソフトウェアQA部門を作成した理由を知っていますか？プログラマーが仕事をしていないからです！プログラマーはあまりにもがらくたをリリースしていたので、企業はそれらをチェックするためにまったく新しい部門を形成しなければなりませんでした。

バグリストはどれくらいの長さですか？バグデータベースに何千ものバグを登録するのは専門家ですか？明らかにそうではありません。これは、悪い振る舞い、規律の悪さ、そして率直に言って、不名誉の反映です。

QAで何も見つからないことを確認するのが私たちの仕事であることがわかるまで、私たちは職業にはなりません。

悲しいことに、これは彼らが「すべての基盤をカバーする」方法のように聞こえ、明らかに推奨されておらず、開発者に幻滅を引き起こすだけの可能性があります。

とは言っても、レビュー期間中に彼らがそのテキストで何をしているかを見て初めて、これは本当に重要になります。そのため、過度に反応しすぎないようにしてください。トンネルの終わりにまだ正気がある可能性があります。

「完全？」のように「エラーなし」「人間ではなく、神と天使たちによって書かれた」のように。（ここでは、プログラムロジックエラーとハードウェアロジックエラーについて説明しています）

1行のコードについても、エラーがないとは言えません。私たち人間が否定的な仮説を立てることができないからです。

エラーの可能性は0から1の間の数値であると言えるでしょう。私は、ソフトウェアの開発とテストの原則を明確に、または十分に定義しておらず、十分に理解していないために、その数値に到達しています。問題のソースソフトウェア行の数。私の候補者である貧しいmuttが、これらのコード行を生成する際にこれらの原則をどれだけうまく適用するか、または十分に理解していないかを理解します。もっと。

そしてその理解は確率としてしか表現できません。したがって、「論理エラーなし」という用語は、ほとんど何もないことを意味します。

「エラーのない」コードを作成したソフトウェアエンジニアの広告を見た場合、すぐに適用するか、すぐに実行します。会社は、ソフトウェアの開発、テスト、および配信の方法についてあまり考えていません。 。ですから、それは素晴らしい機会になるか、無限の悪夢になるでしょう。

ただし、どのソフトウェアでも、私は簡単に（そして必ず）言っておく必要があります。コードには、面倒で曖昧で論理的な要素以外のエラーはありません。エラーや警告なしにコンパイルしてリンクするコード。それは「有効なhtml」または「有効なcss」です。説明されていないエラーメッセージやブラウザの障害を生成しないJavaScript（たとえば）。その部分を直接測定して、グラフ上に白黒でマークを付けることができます。

その部分はパイのように簡単です。誰もが行うことができますように。

ねえ、検索で頑張ってください:-)

私は愚かですか、それとも「エラー」は「コンパイル不可能なコードに相当する致命的なコンパイラメッセージ」を意味していませんか？

その定義では、それは非常に合理的な要件です...