開発チームのストレスと機能障害の典型的な原因-はい、実際、どのチームでも-は目標と制限の混乱です。
多くの場合、チームは目標の限界を間違えます。 典型的な例：チームはその目的のために製品要件を採用し、これらの要件を最初に生成した実際のニーズを見失います。
要件、アーキテクチャ、アプリケーション設計は制限事項です。 原則として、1つの問題を無数の方法で解決できますが、特定の1つを選択しただけです。 これは、定義上、制限です。
どうやって、なぜ、なぜ彼らがやったのかを見失って、お金を引き出すことに専念し、現在の状況を維持するためだけに必要な多くの技術系スタートアップを見ました。 これは非常に一般的です。 明確な目標（比較的言えば「猫を救う」）から始まったこれらすべての慈善財団について考えてみてください。しかし、数年後、彼らの努力のほとんどは、すべてではないにしても、お金を見つけることだけを目的としています。全員に給料を支払い、「慈善」を続けます。
もちろん、お金を稼ぐことはビジネスの仕事であり、このお金はビジネスがユーザーのタスクを解決する価格であることに反対することができます。 レストランの目標はお金を稼ぐことです。 夕食の目的は食べることです。 お金を差し上げます。 あなたは私の空腹を満足させます。
したがって、組織の存在の本質が収益を上げることである場合、クライアントの目標とニーズを十分に深く理解することが重要です。
このビジネスの考え方は、19世紀にまでさかのぼります。 しかしそれでも、利益を上げる以上の目標を設定する進歩的な産業家がいました。 最高の状態で、会社は従業員に意味と目的を作成し、彼らの生活とコミュニティの生活を豊かにし、周囲の風景に魅力を加えることができます。
しかし、気が散りました。 どこに泊まりましたか？ そうそう。 目標と制限。
ロサンゼルスの自宅からサンフランシスコへの旅行を計画しているとします。 あなたの目標はフリスコを訪れることです。 制限は、あなたがあなたの車を運転したいという事実であるかもしれません、そして、あなたは全体の旅行のために十分なガスを持っていません。
あなたはガソリン代を集めることにしました。 これを行うには、レモネードを作成し、自宅の近くのキオスクで販売します。 物事は順調に進んでいます。 あなたのレモネードが好きな人、そしてあなたの家の良い場所のおかげで、渇きを癒す必要のある通行人が常にたくさんいます。 すぐに、ガスのお金で十分です。 しかし、レモネードの販売はとても活発なので、サンフランシスコについてではなく、それについての考えだけに夢中になっています。 絞りたてのオレンジジュースとスムージーを品揃えに追加する予定です。 大きなテーブルを購入します。 単にあなたがすべてを自分でする時間がないという理由だけで、あなたはアシスタントを雇います。 同じ通りに、より大きく、より広い庭のある新しい家を購入します。 それから、地元のレストランが自分のレストランに足りないときに飲み物を届け始めます。 10年後、あなたはレモネードの屋台の独自のネットワークを街中に立ち上げます。
一方、あなたはサンフランシスコに行ったことがありません。 そして今、あなたは忙しすぎるので、そこに行く時間を見つけることはまずありません。
今、あなたが焦げた資本家なら、あなたは異議を唱えることができます：「そう何？」 あなたのレモネード事業は逃した旅行の価値ある補償ですか？
たぶんはい、そうでないかもしれません。 私は年をとるにつれて、「なぜ私はこれをしているのか」という質問を自問自答し始めています。 「成功」に気を取られすぎて、一度も旅行したことがなく、この経験を積んだことも、ホームレコーディングスタジオを作成したことも、外国語を学んだこともありませんでした。 。
私たちの多くにとって、そして人々や組織にとって、資金を調達する必要性は、私たちが決して取り除くことができないことです。 これは、目標の達成を支援または妨げる可能性がある制限です。
同様に、チームワークでは、細部に目を向けて、最初に行ったのと同じ方法でプログラムとシステムを作成する理由に注意を払うのは非常に簡単です。
したがって、バランスをとる必要があると思います。 目標を達成しようとすると、既存の制限に注意を払う必要がありますが、制限だけを考えて目標を忘れると、すべての努力が無駄になります。
制限に厳しすぎると、目標を達成する可能性が低くなります。
制限が制限されます。 それが彼らの本質です。 たとえば、ロサンゼルスからサンフランシスコまでの特定のルートに限定し、途中で道路が遮断されていることが判明した場合、目的地に到達するために他の方法を探す必要があります。
私はよく、チームが壁に頭をぶつけて、何らかの理由で満たすことができない要件を実現しようとするのを見てきました。 「他の方法はありますか？」と自問するために、一歩下がって、達成したい目標を思い出すのは難しすぎました。 私は、他の誰も見なかったために何百万ドルものプロジェクトが失敗するのを見ました。 Oracleでなければなりません。 Javaでなければなりません。 Webサービスである必要があります。
いや すべきではない。 私たちが直面している制約の大部分は、実際には他の誰かの選択であり、おそらく私たち自身が選んだ選択でさえありますが、それが選択であることを忘れていました。
もちろん、それが機能するようにしてください。 ただし、選択と目標を混同しないでください。
翻訳者のメモ：プログラマーが製品要件にどのように関係すべきかについての同僚との古い議論を思い出したので、このテキストに夢中になりました。 同僚は、要件が不完全または最適ではない場合でも、要件を逐語的に実装する必要があると主張しました。 そのような正式なアプローチの誤りを証明しようとしました。 おそらく、この記事が私の論点に別のブリックを追加すると思った。
しかし、翻訳プロセスでは、著者がより複雑な問題に触れていることが明らかになりました。 多くの場合、思考の慣性により、代替案を考えずに古い決定を何度も繰り返すことになります。 使用するテクノロジー。 プロセスを構築する方法。 誰が何に対して責任を負いますか。 何も変更せずに、以前と同じようにすべてを続けます。 慣性は時には電力を節約するのに役立ちますが、長時間にわたって痛みや不快感を引き起こすこともあります。
著者の主張にはいつでも反論することができますが、アドバイスの1つは非常に価値があると思います。見上げることを忘れずに、「なぜ私はこれをしているのですか？なぜこのようにしているのですか？」