ビデオ監視製品の開発におけるCustdev

ビデオ分析モジュールの開発に関与するほとんどすべての企業は、独自のエンジニアリングアイデアの外挿に基づいてこれを行います。 同社は、「たとえば、放棄されたアイテムを検出したり、火災を検出したり、興行店で人を数えたりする機能を開発できるようになる」と考えています。 そしてそれを行います。 どのモジュールを作成するかは、ほとんどの場合、開発者の能力と会社のリソースに基づいて決定されます。 その結果、多くの場合、取得されるモジュールは一種の技術実験になります。 そして、顧客がそれらを購入し、既存のビデオ監視システムに実装し、それらを実践し始めると、それらは実際には役に立たないことがわかります。



痛みを伴う問題を解決するためではなく、開発のために開発が行われます。 そして、これは間違っており、採算が取れません。 実際、関数の開発はその作成で終わるわけではありません。 この機能は、それぞれ絶えず更新されるソフトウェア製品の一部であり、絶えずサポートされ、変更され、新しいバージョンに並ぶ必要があります。 そして、これには開発者のリソースと時間が必要です。 機能の新しい反復は製品テスト段階で確認する必要があり、これらは品質グループのリソースと時間です。



これに加えて、不要な、役に立たない、要求されていない実際の機能の製品のヒープは、その一般的な混乱と複雑さをもたらします(記事「単純化への道:開発者に与えられる難しさ」を参照)。



これは、実際に多くの人々が実際に有用で適用できるもののみを開発するよう努力する必要があることを意味します。 しかし、そのような関数を見つける方法は?



これは恐ろしい言葉ですcustdev



この問題に対処するために、私たちは顧客の開発に頼ってきました。 定義上、custdevは潜在的な消費者向けに将来の製品のアイデアやプロトタイプをテストしています。

この方法では、目的の機能がどうあるべきかについてのアイデアや仮説を生成できると想定しています(能力や想像力に基づいています-それは重要ではありません)が、検証する必要があります。



今日のビデオ分析の分野におけるほとんどすべての開発は、未検証、未検証の仮説の実装の結果です。 開発者は、関数を発明した誰かが必要とすることを提案します。 それがそのように行われれば有益であり、そうでなければ有益であると信じられています。 しかし、custdevのグローバルな経験は、ほとんどの仮説が間違っていることを示しています。



私たちはアイデアを生み出し始めました。 これを行うために、私たちは自分で急いで、ビデオシステムの現在および潜在的なユーザーに不足しているものを尋ね、展示会、セミナーなどの参加者から遭遇し、聞いたことを思い出しました その結果、115の仮説がありました。 これらは、ビデオ分析モジュールを介してユーザーに伝達できる価値のあるアイデアです。





これは、検証のための仮説を持つワークシートの1つです。



さらに仮説を検証する必要がありました。 これを行うために、ビデオ監視システムを使用するさまざまな実際のオブジェクトに実際のユーザーを行き来し、「問題のある」インタビューを実施しました。 過去のユーザーエクスペリエンスについて質問し、彼らが先月どのような問題を抱えていたかを調べました。これは何らかのビデオ分析モジュールを使用して解決できる可能性があります。 そして、彼らがこの問題を解決するために特定の価格で機能を購入する準備ができていますか?



この段階で、私たちは124のそのようなインタビューを実施し、私たちの仮説の115のうち5だけがそのようなテストに合格したことを発見して驚きました。 わずか4%! これはすでに非常に示唆的なものになっています。



開発者を選択した後、これを行う方法を理解する必要がありました。 各モジュールについて、実装オプションをコンパイルし、同じユーザーに、それを見たいかどうかという質問を繰り返しました。



そして、ほとんどの場合、私たちの仮定は再び間違っていました。 同じ関数を作成する開発者とそれを操作するユーザーにとって同じ機能を使用することの利便性は、まったく異なって見えます。 したがって、custdevメソッドを使用して、「what」だけでなく「how」も検索しました。 選択した機能がどのように機能するかについてのいくつかの仮定のみが、ユーザーの言葉によって確認されました。



言葉から開発へ



2017年の秋に見つかった5つのアイデアの1つを実装しました。 これは、生産現場や建設現場での安全上の注意事項の順守を監視できるモジュールです。人の頭にヘルメットがないことを検出します。



ユーザーは、機能の選択と実装の形態だけでなく、その開発にも直接関与しました。 ディープラーニングアプローチを使用して、モジュールを作成するプロセスの開発者は、建設現場、工業企業、発電所などの実際のオブジェクトからの実際のビデオで検出器をトレーニングしました。 ユーザーから送られたもの。 私たちは自分たちで何かを手に入れ、施設まで車で行きました 建設プロジェクトや修理ゾーンに出会ったときに何かを撮影した。 何かはオンライン・オンライン放送の無料ソースから取られました。



それは勝利ですか? それほど速くない...



ユーザーによると、ユーザーが必要とする機能と、購入して実際に使用する機能は必ずしも同じではないことを十分に認識しています。 ヘルメット不在検出器の最初の1.5か月の販売で、5か国で購入されました。この結果をよく評価します。 しかし、将来的には、モジュールの関連性と実際の有用性を評価し続ける必要があります。すでに使用を開始した人からの検出器の繰り返し取得を追跡するため。 ビデオシステムの構造における関数の実装から特定の結果を見つけます。 モジュールの操作などのテクニカルサポートコールがあるかどうかを追跡します。 そして、実際にモジュールの必要性と実際の使用が確認されない場合は、さよならを言う勇気があります。 かつてインタラクティブ検索モジュールで行ったように( 「私たち自身の力での開発、またはユーザーが必要とすることを行っていないことがわかった」という記事を参照)



顧客開発手法を使用した開発方法は、それだけではありません。 しかし、私たちの意見では、ビデオ分析モジュールをエンジニアリング開発ではなく、実際の人々に本当のメリットをもたらす機能を作成することができます。



All Articles