こんにちは、habrachelovek！
偶然にも、栄光のハブレの住民の多くが何らかの形で開発に関係していたことがありました 。 開発とは、ここではプログラムを書くよりも少し広くて抽象的な用語を意味します。 開発は、主に創造的なアクション、創造的なプロセスです。 このプロセスの入力にはアイデアが考えられ、出力には開発者の発案である具体的な製品があります。 最終製品は、Webサイト、デザイン、プログラム、スマートデバイス、スマートホームなど、何でもかまいません。
意思決定を軽視するのではなく、行動のある程度の独立に慣れているため、私はしばしば自分自身の
エンジニアの標準的な状況を想像してください- アイデアが脳に現れました。 彼女は自分で生まれ、同情的な仲間に投げられたり、別の
タスクに対処する必要があります。 だから学校で教えました。 しかし、単一の手がかりなしにこの滑らかな女性に取り組む方法は？ 私たちは、タスクを解決するために正確に何をする必要があるのかを知らないことに起因する混乱を感じます。 だから
以下のアルゴリズムを提案します。 私はここで独創的なふりをしていないとすぐに言います。おそらく同じような旅行がすでに他のどこかで説明されていますが、私はそれを見たことがありません。
出発点は、問題の言葉遣いです（「誰にとっても幸せをどこかで得る」）。 生産のためのプロジェクトに取り組んでいると仮定します。 あなたはそれを完了するために最初に何をする必要がありますか？ まず、顧客がどのようにプロジェクトを提示するかを定式化する必要があります（この特定の例では、人類全体、一般的な場合、雇用主または私たち自身である場合もあります）。 つまり、プロジェクトの外部要件を特定します 。 私たちの場合、すべてがシンプルです-世界中のすべての住民が幸せになるはずです。 一般的な場合、このステップの結果は 、最終目標に関する最も一般的な情報を含む数ページのテキストになります。 結果を一般的なフレーズで説明するのが難しい場合、エンドユーザーによる使用方法を使用して、目的の説明に頼ることができます（ユーザーは、「まだ幸せ」と「隣人と幸せを共有する」という2つのボタンが表示されます。ボタン1をクリックすると... ）
作業の半分が完了したので、すでに良いです-私たちは仕事を始めました！ 次は？ 次に、作業する必要のあるサブジェクト領域を学習する必要があります。 この段階の目的は、特定のサブジェクトエリアのエンティティを操作する方法をメモリで認識または更新し、解決する問題の観点から話したり考えたりすることを学ぶことです。 第2段階の最終結果は、 ステップ1で取得した一般的な要件を明確なサブタスクに変換して、これらの要件を達成することです。 私たちの場合、それは次のようになります。「幸福...それは何で、何と一緒に食べますか？ 幸福とは、特定の個人に影響を及ぼす外部要因と内部要因の好ましい組み合わせによって達成される心の状態です。 アイスクリームは幸せな子供、恋人、キス、政治家、権力、システム管理者、バックアップを作ります。 したがって、次のことが必要です。子供たちにアイスクリームを提供するために、電力の生産のための工場を建設する... "
さて、これでプロジェクトを完了するために何をする必要があるかが正確にわかりました。 しかし、プロジェクトが長時間遅れるリスクがある場合はどうでしょうか？ または、チーム全体として作業する場合はどうなりますか？ 3番目のステップでは、前の段階で収集した情報の山に物事を整理し、定式化されたサブタスクを指定します （はい、書き留めてください！）。 そのため、サブタスクを最大限に分解し、アクションのシーケンスを選択して、コンポーネントに分解できなくなった最小タスクを解決します（「...私たちは幸福の生産のために工場が必要です。これには労働者が必要です。労働者を訓練する必要があります。 ：20人の有望な高校生と...） サブタスクの仕様は、深刻で、難しく、部分的に退屈な仕事です。 しかし、同時にいくつかの利点があります。まず、暗黙的な設計です。 あなたがやろうとしていることを書くとき（そしてすぐにキーボードでコードにすぐに突入しないで）、最初の近似として見逃されたいくつかの微妙さが明らかにされ、有用なアーキテクチャ上の決定が行われ、さらなる開発を簡素化する調整が行われることがしばしば起こります。 そして、いくつかのタスクは完全に放棄されなければなりません。 =）第二に、計画の実施に必要な人件費をより正確に評価できるようになります。作業量が少なく見積もられるほど、将来の実施のための正しい用語を命名する可能性が高くなるためです。 そして第三に、承認された仕様がある場合、既存の機能を際限なく改善し、新しい機能を追加する誘惑を避け、プロジェクトの開始時間を遅らせたり遅らせたりするのは簡単です。 実際、ユーザーが必要とするものや、製品の人気をさらに決定する機会を正確に事前に決定することは困難です。 最初に、実行可能性を保証する最小限のセットから始めてから、ユーザーの実際のニーズに基づいて新しい機能を追加する必要があります。 このステップの結果は 、サブタスクの説明とそれらを解決する方法を含むドキュメントです。
最後に、私たちは最も愛されている人、つまり実際の実装にこれまで以上に近づいています。 ただし、急いでいるわけではありません。まず、各サブタスクを個別に完了するのにかかる時間を評価する必要があります。 この瞬間までに、仕様を作成することで、すでに生活を可能な限り簡素化しました。数字を書き留めるだけです（「オーストラリアの幸せな居住者-48時間、アルバニア-32時間、アメリカ-72時間...」）。 この段階の主な目標は、各サブタスクを特定の時間枠内に収めることです。 実際、人件費を計画および推定するための膨大な数の方法が存在しているにもかかわらず、この段階は現実から非常に抽象的であり、時計ではなくオウムを数字の隣に置く方がより正確ですが、ある程度の近似は依然として得られます。 そして、この近似は、後続の各反復でより正確になります（これについてはまだ語っていません）。 結果 -プロジェクトの作業スケジュール 。
さて、ここであなたが手で作業する必要がある甘い瞬間が来ました。 キーボード、ハンマー、はんだごて、その他の道具を手に取って、考えて記述したことを実践してください。 実装段階です。 結果は、コード、マイクロサーキット、デバイスなど何でもありますが、 試用版のみです。 分岐点はここにあります-私たちの頭脳は、私たちが長い間ステージ1で話してきたことを満足していますか？ もしそうなら、自由に要約して成人期に送ってください。 しかし、この質問に「はい」と答えようとする最初の試みは非常にまれです。 ほとんどの場合、上記のすべての手順の後、結果として達成したいこと、アイデアを実現して目標を達成するために何をする必要があるかをよりよく理解できるようになっただけです。 実装フェーズの実際の結果として何が得られますか？ 戦闘で生まれた、より明確で、情報に基づいた、フィールドでテストされた要件 ！ さて、あなたはすでに推測しましたか？ ステップ1までお気軽に！ 最初のイテレーションは成功しました、おめでとう、同僚！
おわりに
説明されている方法は、混乱の段階を最小限に抑え、技術的な問題を解決するための統一されたアプローチを可能にするツールの本質です。 反復性と各反復内の段階への分割により、各タスクに最大限の集中力が与えられます。 そして、集中は品質と成功の鍵です。 確かに、最高のものは善の敵であるということを忘れてはならないので、過度の完璧主義は依然として避けなければなりません。
お友達、頑張ってください！
UPD：ユーザーiasonovは、TRIZ :: ARIZの方向に目を向けることを提案しました。そこには、このような興味深いスキームがあります。 私たちはみんな一緒に踏みつけて勉強します。