アイデアを正しく生成する
製品を改善および改善するためのアイデアが常に頭に浮かびます-ウェブサイトのコンバージョンを増やす方法、部門の仕事をスピードアップする方法、ビジネスプロセスを改善する方法、いくつかの機能を自動化する方法など。 主要な市場プレーヤーに登場する新しい機能の監視を担当する特別なポストや部門もあります。 アイデアのもう1つの素晴らしい情報源は、顧客からのフィードバックです。 データ、意見、提案のこの配列はすべて蓄積され、常にソート、評価、優先順位付けが必要です。
新しいアイデアは製品を前進させ、競争上の優位性を生み出しますが、すべての従業員がすぐに新しいアイデアで開発者に来た場合、開発者は単に仕事をする時間がありません。 彼らは、この瞬間またはその瞬間をどのように実装するのが最善かについての一連の終わりのない議論に参加しなければならず、その後、開発は非常にゆっくりと進みます。 またはその逆に、新しい機能や機能をできるだけ早く導入しようとすると、「クランチ」でコーディングし、他の機能を見ずに変更を追加する必要があります。
最初に対処する必要がある最も重要な問題は、アイデアを生成するプロセスです。
リテールロケットでは、チームのどのメンバーでもアイデアを生成でき、Trelloの特定のボードに配置されます。 私たちの仕事では、かんばんのイデオロギーを使用し、社内のプロセスごと、部門ごとに取締役会があります。 製品のアイデアは特定の列に記録されますが、これを行うには、マネージャー（または従業員）が簡単な説明を作成する必要があります。 つまり、「レビューの文字数を制限する」または「クイックオーダーボタンを追加する」だけでなく、新しい機能が必要な理由とその有用性が明確になる明確な説明です。
つまり、アイデアを持っている人はすぐに開発部門に行かず、プロダクトマネージャーにも行かず、まずアイデアを言葉にまとめようとします。 これにより、新しい機能をさらに開発および実装する際の多くの問題や質問を回避できます。
したがって、最初のルール：タスクは、人が簡単な説明を作成する準備ができている場合にのみ、アイデアに導入できます。
できるだけ詳細にタスクを説明する
その後、プロダクトマネージャーが関与します。これは、プロダクト管理を扱う別の役割です。 この役割の目的は、要件を収集し、これらの要件を開発への移行のために準備することです。 つまり、アイデアのディレクターは開発と直接通信しません。
プロダクトマネージャーは、開発者がこの特定のアイデアを実装し、タスクのタイミングを評価する方法について決定するための説明に従って、説明を書く必要があります。
したがって、2番目のルール：プロダクトマネージャーの最初の機能は、すべての開発の問題を取り除くような方法でタスクを提示し、記述することです。
たとえば、リコールの文字数を制限するタスクの場合、リコールが指定された値よりも長い場合、キャラクターカウンターがある場合、カウンターがゼロに近づくかエラーメッセージが表示されるときにCSSスタイルが変更される場合などに何が起こるかを記述する必要があります。 開発者がプロセスの詳細を明確にする必要がないように、これらすべての質問に答える必要があります。
3番目のルール：製品マネージャーは、機能をテストし、その有効性を判断する人のリストを作成する必要があります。
これは、まず、IT部門を離れた後の検証を担当する人のリストが定義されるまで、アイデアを開発に移せないことを意味します。 次に、有効性の基準が明確に定義されるまで。
つまり、新しい機能を注文する従業員は、「これらの特定の人々がテストされ、そのようなイベントが発生した場合、テストは成功したと見なされます」と言う必要があります。
各タスクを評価する
この段階で発生する最も重要なポイントは、お金でタスクの見積もりを取得することです。 これは、開発に与えられたタスクは、そのディレクター、つまり 従業員は、これでビジネスが獲得する金額を計算する必要があります。 多くの人にとって、与えられたタスクの遂行がどれだけのお金をもたらすかを評価することは不可能であるように思えますが、そうではありません。 はい、それは難しい場合がありますが、ほとんどのタスクでこれが非常に現実的であることが経験上示されています。 できない場合、ビジネスで必要とされないのはまさにこれらのタスクです。 タスクがどれだけもたらすかわからない場合、本当に時間を費やす必要がありますか？
4番目のルール：すべてのタスクはお金で評価されるべきです
例を挙げます。 トリガーシナリオがあります-「放棄されたバスケット」に関する手紙。オンラインストアは、バスケットに商品を追加したが注文はしなかったユーザーに送信します。 バスケット内の商品の価格が下がった場合、クライアントの1人が繰り返し手紙を送るように依頼しました。 このタスクのコストを計算するために、製品マネージャーはアナリストにリクエストを出し、価格が週に5％以上引き下げられる製品の数を計算するよう求めました。 アナリストは、ファッションセグメントのバスケットに残っている商品の約10％が週に5％以上価格を引き下げると見積もっています。 つまり、放棄されたバスケットについて送信されるメールの数を10％増やすことができ、それに応じて10％以上の注文を受け取ることができます。 したがって、1週間で金銭問題の評価を受けました。
そして、これらのプロセスはすべて、開発者の参加なしに行われています。 現在のタスクからそれらを削除しません。
タスクの優先順位付け
お金でタスクを評価した後、時間内にタスクの完了の評価を取得する必要があります-この段階で、開発部門が接続されます。
プロダクトマネージャーの説明によると、開発者はタスクの完了方法と所要時間について話し合います。 評価には、 Planning Pokerを使用します。
バックログ内のすべてのタスクを評価した後、それらに優先順位を付けることができます。 どのタスクをできるだけ早く完了でき、どれが最大の経済的利益をもたらすかを理解します。 彼らは最初に取られる必要があります。
第5のルール：最も経済的な利益をもたらし、最小限の時間コストしか必要としないタスクが最初に仕事に行くべきです。
現在、タスクに関するITチームの作業が開始されています。
最初にMVPを作成
開発に関しては、できるだけ早く仮説をテストするために、機能の最初のバージョンをできるだけ安価で簡単に製造できるようにすることが重要です。 つまり、MVP（Minimal Viable Product）を作成します。 この段階では、タスクを説明するときに特定されたパフォーマンス基準を確認することが重要です。
バスケット内の商品の値下げを通知するタスクの例では、インターフェース、マーケティング資料などをすぐに作成する必要はありません。 ほぼ手動で動作するコードを書くだけです。テスト用に複数のストアを提供して、これが販売にどのように影響するかを確認し、実際にアナリストの計算を確認します。 手動モードでテストを実施し、結果を測定します。 そして、結果に応じて仮説が機能したという証拠を受け取った後にのみ、完全な機能を開発するかどうかを決定します（インターフェイスの開発、デザインの作成、レイアウトの作成など）。
6番目のルール：MVPを介して有効性を確認した後、機能のフルバージョンを開発する
開発チームの生産性を向上
プロダクトマネージャーと、場合によってはCEO以外の誰も、開発者と通信するべきではありません。 彼らは別の部屋にいるべきであり、誰も彼らに行くべきではありません。 これにより、IT部門の効率が向上する場合があります。 人は、単純なタスクに集中するために、実装を開始するためだけに15〜20分を費やす必要があるためです。 そして、15分後に誰かが質問で彼に近づいた場合（そしてこれは常に起こり、会社が大きくなるほど頻繁になります）、その人は集中状態を離れます。 だから、彼は再びダイビングに15-20分を必要とします。 すなわち 少なくとも30〜40分がすでに無駄になっています。 また、1日に5〜7人が質問で開発者に近づいた場合、日中は何もしなかったと想定できます。
7番目のルール：開発者と通信する人のサークルを最小限に制限します。 理想的には、これはプロダクトマネージャーのみであり、場合によってはゼネラルマネージャーでなければなりません。
この問題は、他のすべての従業員が立ち入ることを禁じられているIT用の別の部屋を割り当てることで解決しました。 別のロックがドアに掛かっています。エンジニア自身と社内の他の数人だけがキーカードを持っています。
もう1つの重要なポイント：IT部門の周りに「保護ドーム」を構築する必要があります。 あらゆる問題から保護し、すべての問題を解決し、インフラストラクチャを提供して、コード生成のみを行うようにします。 YandexやGoogleなどの企業では、人がほとんど家に帰れないようにオフィスが完備されているのは偶然ではありません。 従業員がマウス用の紅茶、コーヒー、または電池を検索する場合、彼は当面の仕事に費やす時間がはるかに少なくなります。 不適切な行動に時間を費やすよりも、高価で資格のある専門家に必要なものをすべて提供する方がはるかに安価です。
8番目のルール：インフラストラクチャを編成し、開発者に必要なすべてを提供します
優れた開発者は実際にはほとんどいないので、これも重要です。価格でのみ競争するのは無意味です。 したがって、より快適な条件を作成できるほど、開発チームの生産性は向上し、従業員はより忠実になります。
あなたのものに
開発者とより効果的にコミュニケーションをとる別のシンプルだが非常に効果的な方法は、彼らの言語を話すことを学ぶことです。 HTML、CSS（codecademy.comなど）、すなわち 将来、ITチームをよりよく理解するために、10〜20時間費やします。
そして、どのようにITチームとの相互作用を構築しますか？ コメントであなたのアプローチを共有してください！