製品開発のアイデアをどのように選択するか: ベンダーはそれを聞くことができなければなりません…

この記事では、製品の機能開発のためのアイデアを選択する際の私の経験を共有し、主な開発ベクトルを維持する方法について説明します。

私たちは自動決済システム (ACS) - 請求書の開発を行っています。 学期
当社の製品の寿命は14年です。 この間、システムは産業用評価器の最初のバージョンから、相互に補完する 18 の製品で構成されるモジュール複合体へと移行しました。 プログラムを長持ちさせるための最も重要な側面の XNUMX つは、継続的な開発です。 そして開発にはアイデアが必要です。

アイデア

ソース

ソースは 5 つあります。

1. 企業情報システム開発者の主な友人は、 顧客。 そしてクライアントとは、意思決定者、プロジェクトのスポンサー、プロセスの所有者と実行者、社内の IT スペシャリスト、一般のユーザー、およびさまざまな程度に関心を持つ多数の人々の集合的なイメージです。 私たちにとって、クライアントの代表者それぞれが潜在的にアイデアの供給者であることが重要です。 最悪の場合、システムの問題に関する否定的なフィードバックしか得られません。 せいぜい、クライアント側に、改善のためのアイデアを常に提供し、クライアントのニーズに関する構造化された情報を提供する人がいる程度です。
2. Наши 販売者とアカウントマネージャー 改善のためのアイデアの XNUMX 番目に重要な情報源です。 彼らは業界代表者と頻繁かつ積極的にコミュニケーションを取り、潜在的な顧客から請求機能に関する直接のリクエストを受け取ります。 販売者とアカウントは、機能のすべての重要な変更と競合他社の最新のソフトウェア更新を認識し、さまざまなソリューションの長所と短所を正当化できる必要があります。 一部の課金機能が事実上の標準になるかどうかを最初に感じるのは、これらの従業員です。これがなければソフトウェアは完成したとは言えません。
3. プロダクトオーナー 当社のトップマネージャーまたは非常に経験豊富なプロジェクトマネージャーの一人。 会社の戦略目標を念頭に置き、それに応じて製品開発計画を調整します。
4. 建築家、選択/使用される技術ソリューションの可能性と限界、および製品開発への影響を理解している人。
   開発チームとテストチーム。 製品開発に直接関わる人たち。

ヒットの分類

私たちは、手紙、チケット、口頭でのリクエストなどの情報源から生データを受け取ります。 全て
控訴は次のように分類されます。

• 協議 「どうやってやるの？」「どうやってうまくいくの？」「なぜうまくいかないの？」「わかりません…」という意味です。 このタイプの電話はレベル 1 サポート ラインに送られます。 相談を他の種類の異議申し立てに再訓練することは可能です。
• 事件 「動作しない」「エラー」という意味です。 2、3サポートラインで対応。 パッチを迅速に修正してリリースする必要がある場合は、サポートから開発に直接転送できます。 変更リクエストに再分類してバックログに送信することが可能です。
• 変更および開発のリクエスト。 サポート ラインを回避して、製品バックログにアクセスします。 ただし、それらの場合は別の処理手順が必要です。

ヒット数にはそのような統計があります。リリース直後、ヒット数は短期間で 10 ～ 15% 増加します。 また、多数のユーザーを抱える新しいクライアントが当社のクラウド サービスにアクセスしたときに、通話が集中することもあります。 人々は新しいソフトウェア機能の使い方を学んでいるので、アドバイスが必要です。 小規模なクライアントでも、システムでの作業を開始すると、月に簡単に 100 時間以上のコンサルティングを費やすことになります。 そのため、新規のお客様をお繋ぎする際には、必ず初回相談の時間を確保しております。 特定の専門家を指名することもよくあります。 もちろん、家賃だけでは人件費を賄うことはできませんが、時間の経過とともに状況は横ばいになります。 適応期間は原則として1～3か月かかり、その後はカウンセリングの必要性が大幅に軽減されます。

以前は、通話を保存するために独自に作成したソリューションを使用していました。 しかし、徐々にアトラシアン製品に切り替えました。 まずアジャイルに取り組みやすくするために開発が移管され、次にサポートが移管されました。 現在、すべての重要なプロセスは Jira SD に存在しており、さらに Jira と Confluence のさまざまなプラグインが提供されています。 自社で作成したソリューションは、企業活動にとって重要ではないプロセスにのみ残っていました。 私たちのタスクはエンドツーエンドになり、あるシステムから別のシステムに移動することなく、サポートと開発の間でタスクを転送できることがわかりました。

このバンドルから、すべてのタスク、計画および実際の人件費に関するデータを取得し、クライアント向けにさまざまな請求オプションを使用し、社内ニーズの文書とクライアントへのレポートを生成できます。

変更リクエストの処理

通常、これらのリクエストは機能要件の形式で送信されます。 当社のアナリストがリクエストを調査し、仕様とトップレベルの TOR を生成します。 この承認リクエストを送信した人に仕様書と TOR を転送します。お客様と同じ言語で話していることを確認する必要があります。

お互いを正しく理解しているという顧客からの確認を受け取ったアナリストは、そのリクエストを製品バックログに入力します。

製品機能の管理

バックログには、受け取った変更と開発のリクエストが蓄積されます。 半年に一度、取締役、保守、開発、営業の責任者、システムアーキテクトから構成される技術会議が開催されます。 ディスカッション形式では、評議会はバックログからのアプリケーションを分析して優先順位を付け、次のリリースで実装するための 5 つの開発タスクについて合意します。

実際、技術評議会は、アプリケーションに記録されたニーズを考慮して、業界および市場の要件に対応します。 関連性の低いものはすべてバックログに残り、開発に至りません。

変更リクエストと財務の分類

開発には費用がかかります。 したがって、変更リクエストが従業員ではなくクライアントから来た場合にどのような選択肢があるかをすぐに説明します。

変更リクエストは次のように分類されます: 業界固有のニーズまたは企業の個別の特性。 大量の新機能または小さな修正。 小さな修正や個別のリクエストは、余分な手間をかけずに処理されます。 個々のリクエストは、特定のクライアントとのプロジェクト作業の一環として計算され、実装されます。

これが業界の大規模なニーズではなく、機能の量が多い場合は、主要な機能に加えて販売される新しい別個のモジュールを開発する決定を下すことができます。 クライアントからそのようなリクエストがあった場合、当社はモジュールの開発コストを負担し、クライアントにモジュールを無償または一部有償で提供し、モジュールをパブリックドメインにして販売することができます。 このような状況では、クライアントは方法論的な負担の一部を引き受け、実際にモジュールのパイロット実装を実施します。

これが業界の大規模なニーズである場合は、基本製品に新しい機能を組み込む決定を下すことができます。 この場合の費用は全額当社が負担し、新機能は現在のバージョンのプログラムに組み込まれます。
古い顧客にはアップデートが提供されます。

また、複数の顧客が同様のニーズを持っている可能性もありますが、それは大量の製品を引き付けるものではありません。 この場合、これらの顧客に仕様を送信し、開発コストを顧客間で分担することを申し出ることができます。 その結果、全員が得をします。顧客は低コストで機能を実装でき、私たちは製品を充実させ、しばらくすると他の市場参加者も機能を入手して使用できるようになります。

DevOps

開発では、年に 5 つのメジャー リリースを準備しています。 各リリースでは、技術評議会から受け取った XNUMX つのタスクの実装のために時間が確保されています。 このように、売上高の裏側では製品の開発を忘れることはありません。

各リリースでは、適切なテストとドキュメントのセットが行われます。 さらに、このリリースは対応する顧客のテスト環境にインストールされ、顧客はすべてを綿密にチェックし、その後初めてリリースが運用環境に移行されます。

リリース システムに加えて、顧客が XNUMX か月間エラーに悩まされないように、迅速なバグ修正の形式もあります。 この中間形式により、最優先のインシデントに迅速に対応し、規定された SLA を満たすことができます。

上記はすべて、主に企業部門とオンプレミス ソリューションに当てはまります。 SMB セグメントに焦点を当てたクラウド サービスでは、これほど顧客が製品開発に参加できる幅広い機会はありません。 SMB のリース形式では、これが推奨されていません。 企業側からの明確な要件の形での変更リクエストの代わりに、サービスに対する通常のフィードバックと要望だけが存在します。 私たちは耳を傾けようと努めますが、製品は大規模であり、古い歴史的なシステムから馴染みのあるものを導入したいというあるクライアントの要望は、システム全体の開発戦略と矛盾する可能性があります。

出所： habr.com