開発する3つの方法

ガベージ作成を目的とした設計

一部の大企業における開発プロセスの一般的な方法は、開発、ガベージ作成を目的とした開発、または略してRNSSです。 RNSMは、お金を受け取るのに必要なのは良いアイデアだけだという信念に基づいています。 明らかなナンセンスですが、それは想像力に欠ける人々のためのサポートです。 この理論は、アイデアは稀で価値があり、ユニークなものであり、全体のトリックはそれをキャッチすることであると言います。



RNSMの主な製品は、そのような「貴重な」アイデアに書かれた無意味です。コンセプト、グラフ、デザインの説明、および1つの目的のために作成された他の製品-バスケットに入れられます。



次のように機能します。

• Creative Guysには、「製品で実行できる機能AおよびB」の長いリストが付属しています。 これと、私たちの将来の素晴らしい製品が何をするかについての信じられないほど詳細なリスト。 彼らはこれらすべてを思いついたのです。 さて、作業の主な（創造的な）部分はすでに行われているので、技術的な実装の問題だけが残っていますが、これは難しくありません！
• マネージャーとコンサルタントは、膨大な仕様を作成するデザイナーや建築家に素晴らしいアイデアを伝えます。 この段階で、12の基本的なアイデアが数百の詳細な要件に変わります。 世界を変える製品のために。
• 仕様は、開発者に渡されます。開発者は、多少驚いていますが、慎重に尋ねますが、誰が... ...こういったことに気づきましたか？ 彼らは、なぜ何かをするのが難しいのか、そして一般に何かが不可能なのかを説明し始めますが、...列車はすでに出発しています。 アーキテクチャは最上位で承認されており、実際、Creative Guysと彼らの高給コンサルタントと議論する開発者は誰ですか？
• 開発者は仕事に戻り、屈辱的で運命づけられ、巨大な「創造的でエレガントな」ゴミの山を築きます。 上記の理論家は実際の実装のニュアンスを絶対に考えなかったので、この仕事は脳をひっくり返します。 「基本」および「マイナー」変更には数週間かかる場合があります。 プロジェクトは遅れ始め、マネージャーは開発者をクリックし、無料の夜と週末は消えます。
• 最終的には、何らかの形で実際の製品をシミュレートするものがリリースされます。 それは厄介で壊れやすく、複雑でいです。 Creative Guysは開発者を無能な平凡と呼び、この豚に弓を取り付けるためにコンサルタントにさらに多くのお金を支払います。そして、外見上は少し良くなっているようです。
• この時までに、管理者はこのすべての恐怖を売ろうとし始め、突然（サプライズ-サプライズ！）300年の間誰もそれを必要としません。 この場所で最も重要なことは、泥の中に顔を落とすことではなく、広告会社に100万ドルを投じることです！ この製品を使用するように人々を説得するには、ほとんど追加料金を支払う必要があります。 ああ、この馬鹿げた、後ろ向きで恩知らずの市場！
• 集中的なマーケティングの一年後、製品はまだ不採算です。 さらに、彼は今年中、壊滅的な失敗と報道機関の否定的なレビューに悩まされていました。 会社はそれを投票箱に静かに降ろし、コンサルタントを解雇し、近くのガレージに住んでいるスタートアップ企業から競争力のある製品を購入し、「バージョン2.0」としてリリースします。 数億ドルがバスケットに投入されます。

一方、トップマネジメントの別のビジョナリーは、マーケティングの人と一緒に余分なグラスを飲んでいて、ブリリアントアイデアが頭に浮かびます...



ガベージを作成するためのデザインは、人生でそれほど頻繁に発生していなければ似顔絵になる可能性があります。 大企業が販売している20の製品のうち19のようなものは失敗です（はい、統計の87％は天井から来ています）。 20のうちの残りの1つは、非常に貧弱な競合製品や新しい市場など、完全にランダムな理由で成功しています。



RNSMの使用から得られる主な結論は簡単ですが、受け入れるのは困難です。アイデアには何の価値もありません。 例外なし。 「素晴らしいアイデア」はありません。 「ああ、これができる！」と感嘆して議論を開始するすべての人は、ドアでエホバの証人のために大事にした情熱とエネルギーをすべて身につけて周りの人々にbeatられなければなりません。 「素晴らしいアイデア」を持つこれらのクリエイティブガイはすべて、山のふもとのカフェに座って、ホットチョコレートをすすりながら他の人に説明する男のように見えます。 そして上にコテージを建てましょう！ 2つのサウナ付き！ そして庭！ ソーラーパネルに接続できます！ おい、かっこいい！ どの色で塗りますか？ 緑！ 青なし！ だから、それを作りに行って、私はこのカフェにとどまり、私たちのプロジェクトのためにいくつかのスケジュールを描きます！」



優れた製品の出発点は、実際の人々が抱えている実際の問題を収集することです。 2番目のステップは、これらの問題を一般的に解決することが妥当かどうかを計算することです。 実際の問題に対する優れたソリューション-これは成功した製品です。 特に「良い」は「安い」という意味で、「シンプル」という意味です。



そして今、完全に不適切なドラゴンを倒した後、複雑さのデーモンを攻撃します。

複雑さの創出を目的とした開発

優秀なエンジニアと中小企業は、理論的にまともな製品を作成することができます。 しかし、製品の大部分は依然として複雑すぎて、成功する可能性が低くなっています。 これは、スペシャリストのチームが頑固に開発プロセスを実装しているためです。これを開発と呼び、複雑さの創造（RNSS）を目指しています。



次のように機能します。

• マネージャーは、問題を解決することの実際の経済的効果とともに、興味深く重要な問題を正しく見つけます。 この段階では、前の段落からRNSMを実施している企業の一歩先を行っています。
• 開発チームは熱心にプロトタイプシステムの構築を開始し、次に主要製品の基本機能を構築します。 すべては計画通りに進んでおり、仕事は議論されており、物事は論理的でエレガントになっています。
• この時点で、経営陣はさらに興味深い重要な問題を抱えています。 はい、それらは解決するのがより困難です（何かを完全に変更する必要があります）が、これを行うと、競争の2段階先になりますよね？
• 開発者は開発者がすべきことを行います-開発します。 再び開発、開発、開発、開発します。 マネージャーは、興味深く重要なタスクを何度も繰り返します。 そして、開発者は何度も何度も開発しています。 結果として、完璧でしっかりした、巨大な、巨大な難易度を得るために。
• 製品は市場に参入し、市場はカブをひっかいて、「これは本当に本当に難しいのですか？」と尋ねます。 人々はどうにかして製品を使用し始め、想像を絶する複雑さを解決するために時間とお金を費やしますが、代替手段がない場合はどうでしょうか？
• 経営陣は主要な顧客から肯定的なフィードバックを受け取ります。経営陣は、すべてが非常に複雑で、トレーニングと使用に多くの時間を費やす必要がある場合、これは間違いなく良い製品だと考えています（？！）。

RNSSの特徴は、99％のユーザーが必要としないプライベートタスクを必死に、そして熱狂的に解決する人々のチームです。 RNSS製品はかさばり、野心的で、複雑で人気がありません。 多くのオープンソース製品は、複雑なソリューションしか存在しないシンプルなソリューションを手に入れるために生まれました。 一部のエンジニアにとって、「他の誰かがこれを必要とする場合に備えて」、製品の機能を拡張しようとするのを止めることは非常に困難です。 彼らはそれが必要かどうか、そしてこれらの人々が世界のどこにでも存在するかどうかを考えずに人々に良いことをしたいのです。



RNSSの良い例はBluetoothです。 これは、ユーザーが嫌う複雑で脆弱なプロトコルのセットです。 侵害しないことは不可能な膨大な特許パッケージのおかげで存在し続け、代替案を生み出しています。 Bluetoothは完全に安全です。これは、このような短距離のプロトコルにとってはほとんど意味がありません。 同時に、彼は開発者向けの標準APIが不足しているため、誰もが自分のアプリケーションで互換性のない自転車を発明することを余儀なくされています。



#Zeromq Wintreは、何年も前にXMMS 2オーディオプレーヤーに優れたプラグインシステムがあるが音楽を再生できないことを発見したとき、彼が激怒したことをIRCチャンネルで書いたことがあります。



RNSSは、開発者と建築家が自分の力で煮詰め、自分の問題を思いつき、それらを英雄的に解決する沼地です。これが想像上の世界の境界を越えて一般的にどれだけ需要があるかについてはまったく心配していません。



RNSSからの主な結論は、ここでも簡単に描くことができますが、受け入れるのは困難です。

• 今必要のない製品を作成するのは無意味です。 誰も要求していない人にナンセンスをしているなら、あなたがどれほど賢くて才能があっても関係ありません。
• 問題はあらゆる規模で発生します。 それらのいくつかは単純ですが、他のものはそうではありません。 奇妙ですが、多くの場合、単純で些細な問題の解決策は、人々が必要とするものです。 一方で、開発者はプラティチュードやささいなことには興味がなく、チャレンジ、問題を与えます。 開発が偶然に任されている場合、開発者は彼らにとってまったく興味深いタスクに取り組みますが、タスクがユーザーにとって有用であるという事実には取り組みません。
• エンジニアやアーキテクトはあらゆる種類のアーキテクチャ、パターンを愛し、ここで何かを一般化し、ここで最適化してハックを披露します-そして、これらすべては容赦なく複雑さの増加につながります。 そのようなことを活用することが重要です。 たとえば、ハードな締め切りであり、開発者は、決して完成することのない華麗で一般的なソリューションの代わりに、「今ここで」機能する小規模でシンプルなソリューションを作成する必要があります。

シンプルなデザイン

そして最後に、私たちは珍しい、しかしもっと価値のある働き方に到達しました-シンプルさ、つまりRNSPの作成を目的とした開発。 それは簡単なことから始まります。あなたが私たちがそれを始める前に、私たちが何を構築したいかを知らないことを認識する必要があります。 数千台のサーバーへの柔軟なスケーリングのブリリアントアイデアと計画から始めることは無意味であるだけでなく、きちんとした基本アーキテクチャに対する直接的な障害ですらあります。 実際の問題は霧の中に隠されており、霧を払拭する唯一の方法は、動き始めて、コンピューターゲームで隠されたマップを探索する方法を探ることです。 最初の段階では、あなたは速く、モバイルで、一言で動く必要があります-そして、今のところどこでそれはそれほど重要ではありません。 特定のエリアを探索した後にのみ、次に進むべき場所が明確になります。



RNSPは次のよ​​うに機能します。

• 特定のエリアで多くの興味深い問題を収集し、単純なものから複雑なものへと昇順で並べ、共通のパターンを見つけようとします。
• 最も単純で基本的な問題を取り上げて解決しますが、これを最もコストのかからない方法で行う「パッチ」です。 各パッチは、1つの問題を解決し、1つの問題を最小限のコストで解決します。
• パッチの品質に関する1つのメトリックを紹介します。「この問題を解決しながら、これをさらに簡単に行うことができますか？」 パッチを使用するためにユーザーが学習（または推測）しなければならない情報量の難易度を測定できます。 少ないほど良い。 理想的なパッチは、ユーザーの知識やスキルを必要とせずに問題を解決します。
• 当社の開発プロセスは、「概念実証が必要」問題を解決するパッチから始まり、相互に補完および修正する数百または数千のパッチで構成される強力な製品に開発されます。
• パッチではないことは何もしません。 私たちは開発プロセスのルールを構築し、この問題を解決する1つのパッチで各問題が解決されるようにします。
• ユーザーが問題を追加し、開発者がそれらを解決するタスクの「サプライチェーン」を構築しています。 このチェーンには優れた「停止メカニズム」があり、開発者が想像力を駆使して空から遠く離れた場所に飛ぶのを防ぎますが、問題の迅速な解決を待っている特定の生きている人がいるときに実行してみてください。
• 開発者には、あらゆるプロジェクトに取り組み、あらゆるコンポーネントにパッチを提供する権利があります。 誰もプロジェクトを所有していません-パッチを受け取るための正式な基準を備えた「メイン」リポジトリがありますが、誰かがそれらを気に入らなければ、誰でもフォークできます。 同じプロジェクトが競合するフォークを持つ可能性があり、それぞれがより良い開発を奨励します。
• このプロジェクトは、ドキュメント化された特定のインターフェイスセットを提供し、他のコンポーネント（クライアント、プラグイン）がそれらを使用できるようにします。 優れたAPIを作成することは、多くのサテライト製品を入手し、エコシステムを構築し、市場を征服する方法です。
• 外部ユーザーおよび顧客へのタスクのサプライチェーンを撤回し、頻繁なリリースのサイクルを提供します。これにより、ユーザーの問題が外部から寄せられ、分析、評価、修正がわずか数時間で可能になります。
• 最初のパッチから始まるすべての瞬間に、当社の製品は配信の準備ができています。 これは重要です。パッチの大部分（10〜30％）が正しくなく、ユーザーに製品へのアクセス権を与えるだけで、何が問題で修正が必要かを理解できるからです。

RNSPは、未知の主題分野で最も重大な問題に対する最適な解決策を見つけるための信頼できる方法です。 RNSPを適用するのに天才である必要はありません。霧の中を無目的にさまようことと、この霧を払拭する活動との違いを見れば、本当に重要な問題の概要が表示されます。



そのようなアルゴリズムには欠点があると指摘する人もいます。 小さなステップで歩くと、「ローカルピーク」で立ち往生し、理想の頂点にジャンプする機会を逃します。 しかし、それにもかかわらず、これは実際の生活ですべてがどのように起こるかです。私たちはあちこちで小さな一歩を踏み出します。 「人生の合理的な計画」はありません。 検討中の問題を幅広くカバーすることで、ローカルピークで立ち往生するリスクを軽減します。 理論によれば、これがイノベーションの出現方法であるため、運を期待したり、何らかの魔法ですべての問題を解決したりするよりも、この多かれ少なかれ科学的なアプローチを使用する方が良いとされています。



このアプローチの力、集合的思考の力、製品改善のすばらしい無限性を理解するとすぐに、なぜいくつかの企業や製品が悲惨な展望の沼地で立ち往生しているのかがわかります。 彼らは、未知の主題分野と市場を正しく探求するためのさまざまな思考、アプローチ、集合知能、空想を持っていないだけです。 ノキアがそのオープンソースプロジェクトを殺したとき、ノキアは自分自身にその喉を切った。



優れたチームを持つ優れたアーキテクトは、RNSPを使用して世界クラスの製品を構築できます。 最大のメリットを得るには、一貫性のない問題のために開発者から香りを開発し、毎日RNSPを常に使用する必要があります。 あらゆる種類の軽微な矛盾を見落とすことがよくありますが、優れたアーキテクトはそれらを認識し、製品を改善するチャンスと見なすことができます。 このタイプのソフトウェア構築の本質は、製品を使用する際の理想にノンストップ（大きくはありませんが、一定）で近似しています。



オープンソースの世界では、これらすべての作業を一目で行います。 「まあ、コードを開いてみよう」という瞬間はありません。 ある段階でのみコードを開くことを決定した製品は、最初からエキサイティングな歴史全体をたどる機会をユーザーから奪い、その製品の誕生の瞬間からコミュニティを作成します。