専門的に何かをすることで、私たちは常に決定を下します。 大小、重要であり、あまりそうではありません。 すべての活動が成功するかどうかは、どれだけ正しく活動を受け入れるかにかかっています。
ソフトウェア開発またはスタートアップ開発に関しては、プロジェクトの商業的成功とチームの幸福、効率、および士気の両方が、主要な従業員の決定に依存しています。 エラーはすぐには検出されず、非常に高価です。
私は最近、ChipとDan Hizovによる素晴らしい本、Thinking Trapsを読みました。 彼女はまったくITについてではありません。 むしろ、反対。 彼女は毎日の考え方についてです。 設計やプログラミングに関する言葉はありません。 しかし、その中で、IT企業の意思決定プロセスを改善する方法について多くのアドバイスを見つけました。 私自身の観察で味付けされたこれらのヒントは、あなたと共有するつもりです。
目に見えない問題
製品開発チームで意思決定を行う際の通常の質問は、機能を追加するかどうか、別のプログラマーを受け入れるかどうか、VKontakteまたはFacebookだけをサポートするか、アダプティブレイアウトを行うかどうかです。このような質問は個別にまたは投票によって解決されます。 答えとして、「はい」または「いいえ」を取得します。 通常、どちらの回答もチームに100％適合しません。 そして、決定プロセスで何が導かれるかは完全には明らかではありません。 多くの場合、決断を下すには、長い苦痛、反省、計量が伴います。 結果として、それは受け入れられ、チームはそれと共に生きます。
実験のために、同じ質問を異なる角度から見てみましょう-より広く：
| 機能を追加するかしないか | 現在最も高い優先順位は何ですか？ どのタスクがより多くのお金/顧客/フィードバックをもたらすか...短期間で/見通しは？ |
| 別のプログラマーを受け入れるかどうか？ | Nルーブルの無料予算を最大限に活用するにはどうすればよいですか？ 他の優先タスクを解決するために、さらにMルーブルを割り当てることができますか？
|
| VKontakteまたは単にFacebookをサポートしますか？ | 私たちのターゲットオーディエンスは誰ですか？ソーシャルネットワーク、フォーラム、ウェビナーなど、最も活発に行動する場所はどこですか？ 彼女との対話を引き付ける/保持する/構築することができる手段は...最も安いですか？ 現在どのようなマーケティングツールが私たちに効果をもたらし、どのツールが将来のために働くことができるでしょうか？
|
| アダプティブレイアウトを行うかしないか | モバイルユーザーの何％がサイトにアクセスしますか？ 私たちはそれらを失いましたか？ 失う準備ができているユーザーの割合はどれですか？
|
注目の焦点を少しずらし、質問をより広く見ると、それを解決する方法がより明確になることがわかります。 ソリューションにはさらに多くのオプションがあり、そのうちの1つをより合理的に選択できます。
決定を下す際に発生する典型的な問題は「狭いフレームワーク」と呼ばれ、可能なオプションの全範囲を見ることができません。 狭いフレームワークの陰湿性は、ほとんどの場合、自分が自分の中にいることを知らないという事実にあります。 製品開発における狭いフレームワークの現れの例を見てみましょう。
デザインフレーム
多くの場合、特定のバリアントに固執していることに気付きました。 嫌いですが、修正方法がわかりません。 私は座って線を1ピクセル左に移動します-1ピクセル右に移動するか、少しだけ色の色相を変更します。 通常、これは行き止まりになったことを示す信号です。 リラックスしたり、モニターから離れたり、誰かにアドバイスを求めたり、インスピレーションを与える例を見てください（私にとってこれは奇妙なことに、apple.comです）。または、タスクをもう一度読んでください。
ところで、問題の1つは、問題の説明と正確に関連しています。 多くの場合、フレームは設定時に作成されます。 問題を定式化して解決する方法を探す代わりに、人々はすぐに話し合い始め、思いついた最初の解決策を作成し、それによって選択肢を制限しました。
たとえば、旅行代理店のWebサイトを作成する必要があります。 クライアントは、「私はその競合他社のサイトが好きです。 私も欲しいです。 メインのボタンには美しいツイストがあり、ボタンはオレンジ色です。 そしてそれだけです！ デザイナーは、ひねりとオレンジ色のボタンの作り方しか考えられませんが、競合他社のサイトのようには見えません。 つまり 彼は、訪問者にとってそれをより便利にする方法については考えておらず、バウチャーを選択する際に人々が他に何が役立つかについても考えていません。 彼は完全に異なる問題を解決するのに苦労しています。
プログラミングのフレームワーク
科学者に次いで、プログラマは最も頭がよく、しばしば自分の脳の人々を使用します。 しかし、それらもフレームワークに陥ることがあります。 彼らは1つの問題の解決策に背を向け、明白な解決策を見つけず、エラーを置きます。 私の観察によれば、これは、彼らが疲れているか、誰かが常にそれらを引っ張り、集中することを許可しないか、時間を使い果たしているか、またはすべてこれが同時にあるときに起こります。 もちろん、プログラマーは十分な読み書きができず、彼の狭い瞬間的な問題に基づいて決定を下し、一般的な問題を考慮に入れないことが起こります。 しかし、私たちはそのようなことについては話しません:)
マーケティングの枠組み
私は、マーケティング担当者が教科書（もちろん、すべてではなく、多く）に従って厳密に行動するという事実に何度も会いました。 ブログ、SEO、サブスクリプションフォーム、レターヒーティング。 さらに、ブログの更新が公開されているソーシャルネットワークには、一般大衆からの投稿が散在しています。 さらに、もちろん、コンテキスト広告。 絶対にすべてのプロジェクトに。 コンクリート工場であれ、医療センターであれ、ハイテク新興企業であれ、それは問題ではありません。 このような狭いフレームワークの理由は何ですか、私は知りません。 作品は創造的であるように思われ、絶え間ない実験で構成されるべきです。 恐らく、広告予算を払わないために介入するのではないかと恐れています。
フレームの見方は？
奇妙なことに、フレームワーク内にいる人は、これに気づくことはほとんどありません。 しかし、彼は明確な答えを見つけることができません。なぜなら、彼は単に自分の方向を見ないからです。 エレガントなソリューションを目の当たりにして私たちが叫ぶ機会がなかったのは誰ですか：
「神、これは明らかです！ 私自身も推測していなかったので？」
美しくて正しい解決策を見つけるのに天才である必要はありません。 すべてできます。 そして、これには方法があります。
手順1.問題を検出します。 選択肢がたった2つのオプション（これを実行するか、または実行する）か、さらに悪いことに1つのオプション（存在するかしないか）に下がった場合は、フレーム内にいます。 フレームワーク内でそれを実現しました-すばらしい！ 勝利への第一歩が踏み出されました。
ステップ2.他のソリューションを意識的に探します。 秘Theは、解決策を明示的かつ意識的に探し、頭に浮かんだ最初のものから選択しないことです。 いくつかのトリック：
- オプションの消失。 利用可能なオプションを受け入れられないと想像してください。 ここではできません。それだけです。 私たちは「cの発明の必要性」という民俗の知恵を思い起こし、脳を活性化させ、新しい何かを発明します。
- ORではなく、I。2つの利用可能なオプションから選択する代わりに、それらを組み合わせてみましょう。 それぞれに長所と短所があります。 両方のオプションの利点を残して、欠点を平準化するために状況を変えようとします。
- 他の人のように。 確かに、他の人々はすでに同様の問題に直面しています。 たとえば、競合他社。 それで、私たち自身の利益のためにそれを使用しましょう。 競合他社からの利益があるはずです:)
経験則の1つは、少なくとも2回恋に落ちるまでオプションを探し続けることです。 （チップヒースとダンヒース）
ステップ3.目的のソリューションを選択します。 そのため、いくつかの優れたオプションが見つかりました。いずれかを選択する必要があります。 この段階では、他の陰湿な敵が私たちを待っています-私たちの感情。 たとえば、プロジェクトを終了する時が来たことを心が示唆し、それでもまだ成果を上げることができることを心から叫んでおり、私たちが多くの投資をしているのでそれを投げるのは残念です。 ここでは、努力して、質問から自分を遠ざける必要があります。 彼を横から見てみてください。 自問してみて、もしこの状況に私の友人がいたら、私は彼に何をアドバイスしますか？ そして、Steve Jobsにアドバイスを求めた場合、彼は何を教えてくれますか？ 質問のこの定式化では、非常に頻繁に、完全に明白な答えが即座に生じます。
ステップ4.チェック。 誰もイベントがどのように展開し、あなたが下す決定が何につながるかを予測することはできません。 たとえ結果に確信があるとしても、私たちは膨大な経験を持ち、専門家であり、議論中の分野で直観と博士号を取得しています。 ソリューションが機能するという仮説は、単なる仮定です。 認めてください。
自分を素晴らしいスペシャリスト（「私はこれを直感的に知っている」）と考える傾向は、私たち（チップヒースとダンヒース）の中にあります。
良いニュースは、ほとんどの場合、現実に近い条件の下で仮定を検証できることです。 新しい機能を導入する必要があると判断しました-ダミーボタンを作成し、クリックする頻度を確認します。 別のプログラマを採用すると開発が20％スピードアップすると思います-プログラマがコーディングに費やす時間とチーム内での対話に費やす時間を数日間測定します。 参加者が多いほど、参加者間の相互作用が多くなり、依存関係は線形にはほど遠いことに注意してください。
仮定を検証するために、計算で十分な場合もあれば、モデリング、3番目の場合-実験または現実に近いプロトタイプで十分です。 しかし、いずれにせよ、フィールドテストは決定を冷静に見るのに役立ちます。 そして重要なことは、検証を研究として扱うことで、起こりうるエラーとその後の進路変更に精神的に備えます。
何がありますか
意思決定の必要性は私たちの仕事の重要な部分であり、それをうまく行う能力は成功の重要な部分です。 適切な決定を下すことを学ぶことはまったく難しくありません。 誰でもこれを行うことができ、これには中等学校の証明書さえ必要ありません。 コツは、脳をより頻繁にオンにして、自分の行動を分析することです。 そして、狭い枠組みの問題を認識したので、意思決定を意識的で合理的なプロセスに変えてください。
あなたのための正しい決定！