開発者主導の製品は良いことですか？

私は、CEOが製品チームを管理している会社で働いています。CEOは、機能をモックアップし、開発者のラップをドロップして、その機能を実装します。もちろんいくつかの反復がありますが、開発者の意見は尊重されます。しかし、このプロセスはどれほど効果があるのだろうか。

ジェイソン・カラカニスは次のように書いた。

Zuckerberg Doctrine：開発者は、製品マネージャーや設計者と比較して速度と機能が大幅に向上した製品を設計し、潜在的な間違いや欠点を上回ります。

...

それから私は本当に衝撃を受けました：開発者主導のスタートアップは常に製品をより速く生産します。

これは理にかなっています。技術者ではない人々が議論や議論をしており、Zuckerbergが次の機能をコーディングしています。これが、誰もFacebookに追いつくことができなかった理由です！

MySpacersは自社の製品を反復する方法について議論していましたが、Facebookは単に試してみました。

これは実際には実際にうまく機能しますか？

製品は顧客主導でなければなりません。

あなたの顧客がソフトウェア開発者であり、あなたがあなた自身の製品を使用しているなら（どんな場合でもそうすべきです）、私はあなたがあなた自身の最高の顧客になれると思います。

しかし、開発者としてのあなたの視点は、内部で起こることによってすでに妥協されています。ユーザーは、ユーザーインターフェイスまたはアプリケーションワークフローで何をしているのかがおかしく、意味をなさないことを顧客に伝える必要があります。

開発者は、自分の経験と彼らの望みを組み合わせて可能な限り最高の製品を生産できるように、利害関係者に尋ねる正しい質問を知る必要があります。

開発者として、私たちはマネージャーやデザイナーよりも良い仕事をしていると思いたいです。しかし、一般化できるとは思いません。

開発者が設計を行う際の問題の1つは、エンドユーザーのニーズに対応できず、適切な人々に適切な質問をするのが得意ではない可能性があることです。マネージャー、特に優れたデザイナーは、これを理解するのに優れているかもしれません。

しかし、私は、より説得力のあることは人々ではなく、彼らが問題にアプローチする方法だと思います。効果的なアプローチは、無限の会議を行って木を切り倒して「理想的な」デザインを考え出すのではなく、物事を降りて実装することです。再検討されたアジャイル対ウォーターフォールです。

（Facebookが物事をやらない方法の例であることは明らかです。例えば、プライバシーの問題に対する彼らの無頓着なアプローチは、Facebookを法的な問題に巻き込み始めています...）

私見、私はあなたが部分的に正しいと言うでしょう。理にかなっています。ただし、これはすべての製品/ソフトウェアに適用されるわけではありません。だから、私はこのようにそれを置きます。デザイナーは、それだけではなく、十分な量の開発経験を持つ人でなければなりません。それは、デザインだけでなく、コーディングを行うべきです。

簡単な答え：時々。

ロングアンサー：顧客が誰であるかを知っていて、顧客が何を望んでいるかを知っている場合、顧客ドライブ開発は機能します。

開発者主導の開発は、まだ有用だと気づいていない人にとってメリットがあります。つまり、顧客は自分が何を望んでいるのかを常に把握できない場合があります。新しい要件は、既存の製品がどのように不十分であるかという既存の経験から生まれます。Facebookの顧客はいなかったため、Zuckerbergは質問の前に答えを出す製品を作成しました。設立されたFacebookは顧客の影響を受けていますが、作成前および作成中は、開発者主導のアイデアでした。

顧客主導の開発は、確立された、おそらく成熟した製品がお金を稼ぐ、または同じ市場で製品の新しい反復を行うのに理想的です。

開発者主導の開発は、Googleの20％の領域に収まるプロトタイピングアクティビティであり、開発者は作業時間の20％を自分のプロジェクトに費やします。

優れた製品を設計するには、問題領域に関する多くの知識が必要です。facebookのような一般公開製品は、開発者が抱える問題も解決するため、開発者が駆動することができます。友人とのつながりや連絡方法など。ソフトウェア開発者向けの製品についても同じことが言えます。 IDEが行うべきこととその方法。

しかし、他の多くの問題領域では、開発者はしばしば十分な知識を持っていません。一般的な洞察とある程度の経験があっても、クールな機能や簡単に実装できる機能を実装する傾向がありますが、顧客に大きな価値を与えず、製品をより複雑にします。これらは、ドメインの専門家が製品を推進する必要がある場合です。

これは明らかに開発者向けの製品（AWSやVisual Studioなど）への最善のアプローチだと思いますが、それが明らかに一般的に優れたアプローチであるかどうかはわかりません。つまり、私は通常、逆のことが起こっているのを見ます。開発者は、非技術系の人々が迅速に決定を下しながら、最善のアプローチを主張します。個人的には、正解は中間のどこかにあると言いたいです。開発者が実装する幅広い方向性を設定できるプロダクトマネージャーが必要です。

ほとんどの場合、開発者主導のソフトウェアは、マネージャー主導のソフトウェアよりも優れている場合があります。マネージャーは、広告で見栄えの良い、またはスピーチで使用できる機能（ほとんどが流行語の機能）で最も価値があると考えています。開発者は、パフォーマンス、バグの軽減、無駄のないデザイン、保守性など、さまざまな価値観を認識しています。それは、ほとんどより良いソフトウェアにつながります。

しかし、最良の方法はユーザー主導のソフトウェアです。ユーザーは、必要なもの、実際の仕事をするのに役立つものを本当に知っています。それが理想です。

誰も使いたくない製品をより早く生産したらどうでしょうか？

単一の属性（機能、市場投入までの時間、価格、品質など）に焦点を合わせると、特定の時点で意味があります。たとえば、AppleはiPhoneとiPadを急いで追い出しました。品質は少し低下しましたが、最初にすることが非常に重要でした。

長い目で見れば、ある側面に焦点を合わせると、あなたを傷つけると思います。

いいえ、現実世界の問題を解決しない限り

• プログラマーは通常、問題を解決することを好みますが、まだ存在しない問題を解決することもあります。
• プログラマは通常、ひどいGUIを作成します。
• ほとんどのユーザーの問題は、プログラマーの問題と同じではありません。
• したがって、プログラマー主導の製品は通常、他のプログラマーには適していますが、ユーザーにはあまり適していません。

また、フェイスブックに関する注意：

フェイスブックの成功は、その技術的なメリットとはまったく関係がありません。Face-bookなどは、「Google Blue Moon」で1回だけ発生します。

しかしながら：

• プログラマーに本当の「ユーザー」問題がある場合、それはプログラマーの問題ではありません。その後、その非常に良いことである可能性が高いです。利害関係者はまた、開発者である場合という問題に関連して優れた製品・ソリューションのための理想的な状況です。

（おっと...どこで「素晴らしいアイデアを手に入れました！必要なのは開発者だけです。」と読んだのは1週間以内でした。とにかく...）

素晴らしいアイデアは数十ドルです。問題を実装することが重要です。開発者が素晴らしいアイデアを持っている場合、それを実装するだけです。