計画を正確な科学に変える
製品開発のベクトルを決定し、その有用性と革新性を組み合わせる方法は？ 私たちの新しい開発が「目標を達成」する可能性を高めるために、綿密な調査を実施し、その結果に基づいて新しいバージョンを計画することが決定されました。 Macroscopの開発戦略は会社のプロダクトマネージャーによって決定されます。彼が取り組んだアルゴリズムは次のとおりです。
1.すべてのアイデアを特定します。 たくさんあるかもしれません
新機能、改善、改善のためのすべてのオプションを見つけるために、Macroscop製品マネージャー：
•製品の実際のユーザーと通信します。 これらは、会議やスカイプでの何十人もの人々との個人的な会話であり、その間に現在のニーズ、アイデア、問題が議論されました。
•展示会、フォーラム、会議で業界のテクノロジーリーダーとコミュニケーションをとる。
•ユーザーの問題の分析に基づいて必要な変更と改善のビジョンを理解するために、テクニカルサポートと会社の品質グループとコミュニケーションをとりました。
•開発者の年間目標を分析しました（会社の各従業員は、年の初めに個人的な目標を策定します）。
•Macroscopデモをテストした人からの約1万の評価とコメントを分析しました。
•どのビデオ分析モジュールがより頻繁に購入されるかを分析しました。
•大規模な顧客からのソフトウェア改善の要求を分析した。
•セールスマネージャー、プレセールエンジニア、パートナートレーニングスペシャリストに、活動分野の一部としてのパートナーとのコミュニケーションに基づいて、必要な改善と開発のビジョンを作成するよう依頼しました。
アイデアの収集と処理の全体として、ユーザーの提案に意味のないことはないと考えて、何も除外または変更しませんでした。 結果は約250ポイントでした。 何も破棄または削除せずに、すべての重複を単に除外したため、130の予備的なアイデアが残っていました。
2.すべてのアイデアを比較検討する
リソースに限りがない場合、130のアイデアすべてを実現します。 しかし、特定のタスクを選択する必要がありました。 これを行うために、10個のパラメーターで各アイデアを比較検討しました。 詳細を説明しないと、すべてが2つのパラメーターになります-革新とユーザーの必要性です。
さまざまな影響力を持つスケールのセット全体が、ユーザーの直接的な希望、マネージャーの希望、開発者の希望などのニーズに責任を負っていました。 2番目の評価である革新性の評価は投機的に行われました。私たちは座って、このアイデアがどれほど革新的であるかを考えました。
3.分布を視覚化する
次に、このようなスケジュールを作成しました。1つの軸ではイノベーションを延期し、2番目ではユーザーのニーズを今すぐに延期しました。 各アイデアは、座標（イノベーションの重み、必要性の重み）とともに、このグラフのポイントの1つに変わりました。
明らかに、次のバージョンでは130のタスクすべてを実装することはできませんが、エリアに近いタスク（+∞; +∞）を選択する必要があります。 つまり、理想的なタスクは非常に革新的であり、今すぐユーザーに必要なものであり、ユーザーは今日お金を払ってそれを使用する準備ができています。
チャートを3つのゾーンに分割しました。
1ゾーン（赤い線より上）-これらは必ず実装する必要があるアイデアです。 高度な技術革新と高度なニーズの両方を備えています。
ゾーン2（赤と緑の線の間）-これらの問題は可能な限り解決します。
ゾーン3（緑色の線の下）-革新的で不要なタスク（ちなみに、これら130のアイデアのほとんどがそこに到達しました）。 そして、私たちはそれらをしません
その結果、ユーザーが必要とする優先機能と改善点のリストを受け取りましたが、同時に市場で私たちを区別し、リーダーシップの地位を強化する可能性が非常に高いです。
アイデアを目標に変換する
式があります：目標=夢+締め切り。 そして、明確な期限がなければ、私たちの計画はすべて目標ではありませんでした。 状況は、多くの開発者と同様に、自分たちがインストールしたバージョンの内部リリース日を遅らせることで、時々罪を犯したという事実によって複雑になりました。
そのため、リストに従って、新しい機能の実装と改善のための現実的で野心的な期限を検討する必要がありました。
Pavel Durovは、毎月一定数の改善をリリースする必要があると述べました。 彼のブログで、彼は毎月7つのVKontakteの改善を説明しました：11月7日の改善、12月7日の改善など。
私たちは「あなたがやりたいことをするが、月に7回更新をリリースし、リズミカルに製品を開発する」という立場を強く考え、それをMacroscopに適用することを決めました（私たちの仕様に自然に適応します）。
会社のプロダクトマネージャーは新しい戦略と1か月の期間について開発者と話し合い、建設的な議論について長い議論を重ねた後、1.5か月ごとに新しいバージョンをリリースすることに同意しました。
製品の新しいバージョンのテストを担当するテクニカルディレクターが約1.5か月の期間を見つけたとき、彼はこれが不可能であると言いました。 開発者は新しい機能と改善点のみを追加し、新製品だけでなく全機能をゼロからテストするためです。 開発者から提供されたバージョンは、彼らがチェックアップおよびダウンする必要があるブラックボックスです。
その結果、建設的な議論の定期的な議論の後、1.5か月ごとに新しいバージョンをリリースすることを決定しましたが、2番目のバージョンはすべて内部にあります。 つまり、私たちはそれを行い、多くの改善を実装しますが、テストをあきらめません。 その後、次のバージョンを作成し、品質グループがテストに使用します。
合計すると、1.5か月ごとにバージョンがリリースされますが、ユーザーはテストされたバージョンを毎秒残します。 1.5か月ごとにリリースする改善点の数を理解するために、開発の以前の速度を分析し、同じ図7を取得しました。この場合、次のとおりです。1完了したイノベーションステップ（新しいビデオ分析モジュール、またはモジュール）+ユーザーにとって重要な2つの機能または大幅な改善+ 4つのその他の機能または改善。
ユーザーは主な専門家です
製品の品質を改善するために導入したもう1つの重要な側面は、開発者とユーザーの直接的なコミュニケーションです。 以前は、ユーザーからフィードバックを受け取るチェーンは非常に長く、ユーザーがマネージャーに何かを言った-マネージャーがそれをプロダクトマネージャーに言った-プロダクトマネージャーがそれを開発者に伝え、最後に開発した。 その結果、開発者がしたこととユーザーが最初に必要としていたこととがまったく一致しないことが判明したことがありました。 そして、それは特定の人のせいではなく、単にチェーン内に多くのリンクがあり、そのような各リンクの情報の一部が失われたために判明しました。
実行する必要があるものの明確なリストができたので、できる限りそれを実行する方法を理解する必要があります。 このため、Macroscop開発者はユーザーとコミュニケーションを取ります。ユーザーはオブジェクトを呼び出したり、オブジェクトにアクセスして理解し、どのように表示するかを理解します。 そして、そのような仮説の検証の過程で、私たちは気付いていなかった多くのことを見つけることに注意してください。
2.5か月前にこれらの技術革新をすべて開発し、導入しました。 どれだけ正確に焦点を合わせたか、そして開発プロセスが正しく構築されたかどうかを理解するためには、もっと多くの時間が経過する必要があります。 しかし、計画によると、9月末に1つの新しい内部バージョンをリリースし、7つの計画的な改善を実現しました。