価値を提供する方法は？
私がコンサルタントになる前は、私が気にかけていたのは、高度なスキルを持つプログラマーになることだけでした。今、私のクライアントが必要としているのは、優れたハッカー、コーダー、アーキテクトなどではないと信じています。私は毎日、もっと価値のあるものがあると確信しています。
どこへ行っても、私は絶望して目を転がしていた習慣を発見します。ピンクのメガネをかけたソフトウェア業界を見て、気分に応じて笑ったり泣いたりしました。私はすべてがもっと良くできるととても確信していました。
今、私のクライアントが切実に必要としているのは、優れたエンジニアリング手法と必死のプロジェクト実行のバランスを見つけることだと私は信じています。優れた設計は、プロジェクトを何年にもわたって維持するために安価にすることができますが、通常、プロジェクトが成功するかどうかを確認するために、迅速かつ安価に作成することがより重要です。それ以前は、設計の維持費が安いかどうかはそれほど重要ではありませんが、その後は、物事を改善するには遅すぎるかもしれません。
彼らは、マネージャーの承認/同意/知識なしにプロジェクトに秘密の改善を行う、関与する人々を必要としています...彼らは私たち全員が重要であると知っているいくつかのタスクのための時間を決して与えられないからです。すべての良いことができるわけではありません。それらのいくつかは自由意志から生まれなければならず、いくつかは同僚、マネージャー、クライアント、そして私たち自身を教育するために話し合われなければなりません。
今私の大きな質問はです。ソフトウェアプロジェクトの経済的な成功に真の価値を提供できる優れたコーディング以外のスキルと実践は正確には何ですか？ （ソフトウェアアーキテクチャだけではありません）
アジャイル手法は、ビジネス価値を可能な限り迅速に提供するものだけを提供することに成功しているため、非常に人気があります。いかに気の利いた、滑らかな、かっこいい、または賢いものであっても、ビジネス価値を提供しないことはすべてお金の無駄です。
重要なことに焦点を当てる
開発者はビジネスマンではないため、ビジネス価値には関心がありません。もし彼らがCSの学位ではなく、MBAを取得していれば。たとえば、SCRUMのようなアジャイル手法は、開発者が開発プロセスの方法部分を制御できるようにしながら、ビジネスにとって重要なことについて開発者に透明性、優先順位、方向性を提供します。これにより、多くの開発者が「ハッキング」や「もしもクールだ」というコーディングのためだけに、やり直しを無駄にすることがなくなります。
ライフサイクルのエンジニア
アジャイルプロジェクトのメンテナンスは、ウォーターフォールプロジェクトよりもはるかに低コストです。これは、メンテナンスが 技術的負債 の概念を通じてプロセスに組み込まれているため、理想的ではないかもしれないが適切なものが文書化され、ポテンシャルバックログの後半で行われる作業。すべて追跡され、優先順位が付けられ、考慮されます。不必要な時期尚早の最適化、および製品所有者によって要求されない機能のコードの記述は、ビジネス価値を追加せず、使用されないか、「設計」のために複雑さを追加し、他の何よりも恐ろしいメンテナンスの問題を引き起こします。素晴らしいことは、最初に十分に正しく後で行う必要のあるメンテナンスがそれほど多くない場合です。
レガシーとしての付加価値
プロセスと文化を改善することは、あなたが「置き去りにする」ことができる唯一のことであり、それは永続的な価値があります。デザインのパラゴンである「クリーンコード」は、ジュニアメンテナンス開発者、またはほとんどの場合シニア開発者との最初の接触を乗り切ることはできません。自明でないサイズのすべてのコードベースは、最終的にエントロピーを介して 大きな泥だんご に進化します。これは避けられません。しかし、考え方の変化とプロセスはプロジェクトごとに続きます。
あなたの質問を完全に理解できるかどうかはわかりませんが（少し複雑に表現されています）、最も重要なのは顧客志向の態度だと思います。それは、優れた技術的知識やコーディングスキルよりもさらに重要かもしれません。顧客志向のない優れたプログラマーは、技術的に驚くべきパフォーマンスの高い堅実なアプリを簡単に組み合わせることができます。これは、クライアントが本当に望んでいたこととはまったく異なることをするだけです。
プログラミングとは、基本的に、あいまいで不明瞭な人間の願いやアイデアを、機械が理解できる、つまり必然的に厳密で制約のある形式に変換することです。このプロセスの大部分には、コミュニケーション、共感、紛争管理などの人的スキルが必要です。必ずしもすべての開発者がこれらのスキルを必要とするわけではありませんが、それだけ優れています。
これは、明らかな理由でコンサルタントからはめったに見られないものです。価値を付加する最良の方法は、正当な理由で自分自身を消耗品にすることです。例えば彼らの仕事を理解できるようにする。共同開発者を常に把握してください。共同開発者に適切なテクニックなどを教える...
まず、クライアントは、実際の価値を実現するために、アイデアに完全に投資する必要があります。開発者として、私たちはクライアントが直面している問題を解決すること、またはクライアントが行うことを強化する方法を見つけることを検討する必要があります。私の見解では、平均的なユーザーはデータの収集に多くの時間を費やしていますが、実際の仕事はデータを収集するのではなく、そのデータを使用または分析する必要があります。
クライアントに投資してもらう際の問題は、「夢のフィールド」効果です。多くの場合、クライアントは何かが彼らのために構築されるまで、彼らが本当に欲しいものを知りません。そのため、事後に多くの要件変更が行われることがよくあります。クライアントは、理解できる具体的な何かを見るまで、何が可能かを把握しません。
優れた開発者は、これを理解し、クライアントのニーズを理解し、クライアントがまだ想定していない価値をもたらす機能を予測しようとします。
私の仕事では、コードを作成する場合（機能を実際に組み込む必要があるため）と、コードを変更しないことを正当化する場合（リスクが大きくない場合）があります。
あなたに起こったことは、あなたがプログラマーからエンジニアに変わったということのように私には聞こえます。エンジニアはコードモンキーではありません。エンジニアは自分の行動の影響を認識し、行動する前にそれらを考慮に入れます。私は「良い」エンジニアと言うべきだと思います。
「秘密」の機能/作業について。確かに、これを修正するために何かを行う必要があることを知っている時（および労働文化）があり、意思決定者にこの作業が必要であるという賛同を得るために多くの努力を費やしてきました。最初にあなたの話を聞いた後（またはとにかく聞いたふりをした後）、彼らはあなたの視点を見ることに同意しますが、あなたがやりたかったことの費用とリスクを正当化することはできません。
その後、とにかく行ってそれを行います。プロトタイプを作成して80％機能させると、同僚、マネージャー、意思決定者に公開します。同僚、マネージャー、意思決定者は、「ほとんど完了し、わずかな調整が必要」と考えて、先に進んで終了するように指示します。通常、この種のことは時間外に行われ、物事が通常改善される唯一の方法についてです。
「...速くて安く生産することがより重要です...」
プログラミング業界についての単なる発言ではなく、あなたは私たちの現代社会のマントラをかなり釘付けにしたと思います。
領域知識
ソフトウェアを作成しているドメインの実用的な知識は、大きなビジネス価値をもたらすのに役立ちます。
- 航空宇宙工学のバックグラウンドを持つNASAの開発者。
ソフトウェアの取り組みに付加価値を与える最も重要な方法は、コードではなく、コミュニケーションです。
文章のコミニュケーション
- プロジェクトにはwikiがありますか？ウィキの最初のページは良いもので、概要はわかりやすいですか？
- 誰かが実際のユーザーと話し、彼らが言ったことの要約を書き留めたことがありますか？
言葉によるコミュニケーション
- 製品のテクニカルセールスエンジニアとして、セールスチームに同行して技術的な質問に答えることができますか？
注：他の人が例を追加できるように、これをコミュニティWikiとしてマークします。