1.プロセスを忘れて、結果のために働く
製品を開発するとき、企業は多くの場合、すべての注意とリソースを作成と生産のプロセスに捧げます。 作業の各段階が「厳密に技術に従って」実行されたとしても、結果は当初のようにバラ色ではないかもしれません。
事例紹介
3か月前、 ルーキーチームは洗練されたシステム分析プロセスを導入しました。 アナリストは、マーケティング調査の要求と収集、ソリューションオプションの準備、財務計算の要求、アルゴリズムの設計、UXのタスクの設定、ビジネス要件の定義、意思決定の保護、レイアウト後の結果の追跡、運用への移行などを行う必要がありました。 1人のアナリストの負荷は、1日あたり15タスクに達する可能性があります。 物理的には、専門家は1日に非常に多くの多様なタスクを見逃すことはできません。 そのような量で、アナリストの仕事が一般的な問題を解決する上で狭い首だったのは驚くことではありません。 効率を上げるために、多くのことが回ってきました。 その結果、同社はこのような複雑なプロセスを放棄し、根本的に簡素化し、さまざまな専門家に責任を分散させました。 効率が向上し、分析プロセスの高速化が始まりました。
避ける方法
製品開発プロセスが複雑すぎて、結果が期待を満たしていない場合、現在のプロセスを確認し、作業の各段階での変更により柔軟に対応する必要があります。
2.高レベルのコマンド同期を維持する
チームで働く能力は、誰もが持っているわけではない重要なスキルです。 実際には、1つのタスクの実装に複数の専門家を一度に関与させる必要がある場合に、状況がしばしば発生します。
たとえば、プロモーションコードをシステムに導入するタスクは、フロントエンド開発者とバックエンドの両方の作業を意味します。 これらの人々が互いに同意できない場合、さまざまな問題が発生する可能性があります。 たとえば、ビジュアルの観点からは、タスクは実行されますが、プロモーションコードの仕組みを開発するためのアルゴリズムがなければ、このタスクは何の価値も与えません。
事例紹介
いくつかの異なる製品がサービスに登場したとき、各製品の開発チームは独自のチームでした。 1人のユーザー、1つのアカウント、および製品とチームは異なります。 どういうわけか、クライアントから電話があり、私たちは彼をスパムしたと言った。 注意が必要な状況が発生したときに、すべてのチームが彼に手紙を送ったことが判明しました（たとえば、残高がゼロに近づいていて、サービスが中断される可能性があります）。 その結果、ユーザーはサービスから週に約40通の手紙を受け取りました。 メールニュースレターの分析が行われました。 いくつかの文字を組み合わせた。 現在、すべての欠点を最終的に修正する電子メール戦略に取り組んでいます。
避ける方法
タスク間の同期を実現するには、同じ製品で作業しているチームのアクションを調整します。 たとえば、設計と開発の一般的な「デモ」を実行し、他のチームに新機能を通知します。 タスクトラッカーのタスクへのリンクを追加して、何、いつ、どのチームが行われたかを明確に説明するリリース履歴を含む公開ドキュメントを作成します。
3.ユーザーの必要に応じて製品のアップグレードを避けます。
新製品は、動作中に問題を特定しています。 サポートサービスに連絡したユーザーによってプロジェクトの改善が開始されたことは秘密ではありません。 誰も主張しません。製品を改善する必要がありますが、「穴を埋める」ために急ぐ前に、問題の根本原因を探す必要があります。
避ける方法
十分な時間、ユーザーリクエストを収集します。 サポートサービスの呼び出し回数に応じて、この期間は1週間または1か月以上になります。 問題を分析し、繰り返し発生する問題を特定し、ユーザーが最もよく不満を感じる問題を解決します。 問題が本質的にブロックしている場合、つまり、システム内のユーザーの正しい操作に影響する場合は、すぐに解決します。
4.開発者を招いて、プロジェクトと設計タスクについて話し合う
多くの場合、顧客のビジネス要件を受け取った設計者は、タスクのロジックの説明に進みます。 システムの技術的特徴を考慮に入れない場合、3か月の開発につながるソリューションが得られる場合があります。
事例紹介
ルーキーで状況が発生すると 。 製品の1つでプロジェクトを作成するためのウィザードが存在するインターフェイスを作成しました。最初のステップでは、ユーザーは別のサービスにログインして情報を取得し（Yandex.Directで）、2番目のステップでは、作業用のパラメーターのリストを選択します パラメーターは、最初のステップで指定されたトークンの要求を実行することにより取得されました。
インターフェースは顧客に示され、同意され、開発者に送られました。 開発者はこれを見て、次のように言いました。「ここで映画を見せなければなりません。ユーザーが大量のデータを持っている場合、非常に長い時間待つことができるからです。 さらに、このフロントエンドソリューションはユーザーフレンドリーではありません。」
その結果、プログラマーからのフィードバックを考慮して、すべてをやり直す必要がありました。
避ける方法
開発者をプロジェクトの議論に参加させ、要件を作成し、設計に関与させます。 開発者を初期段階で作業に組み込むことにより、プロジェクトの作成にかかる時間を大幅に短縮し、不要な手直しコストを回避し、時間の遅れによる余分な白髪なしに行うことができます。
5.簡素化。 素晴らしい、効果的
定期的に、新しい製品を作成したり、古い製品を完成させたりする際に、商業の専門家は素晴らしいアイデアを思いつきます。 残念ながら、すべての独創的な人が需要と実行可能性があるわけではありません。
事例紹介
売り上げを伸ばすために、多くの場合、著作権メール戦略を使用します。 それらを実装するには多くの方法があります：送信イベントのセットアップ、サービスのシグナルで電子メールを送信するサードパーティの電子メールニュースレターサービス、サービスの側で統一されたトリガーロジックを実装し、メール送信に標準またはユニバーサルテンプレートを使用するなど。
時々、企業は自分の道を進むことを決め、他のみんなを好きではない。 チームのユーザーに最初の手紙を書くとき、彼らはそれが最後になると思った。 そして、彼らは別の最後の手紙を送りました。 その他...多くの手紙があったとき、チームはテンプレートを作成するためのサービスを実装しました。 それは2か月間行われ、既存の専門サービスほど良くありませんでした。 その結果、企業は最適なソリューションに到達しました-サードパーティのメールサービスを統合しました。
避ける方法
イノベーションの実装が複雑すぎると思われる場合は、破棄してください。
既存のサービスに明らかに失われるサービスを作成する時間を無駄にしないでください。 あなたの質問に答えてください、あなたは本当にあなた自身のものではなく、維持するのが難しいツールが必要ですか？
6.要件の曖昧な解釈を避ける
あいまいなタスクは誤解を生み、望ましくない結果を招く可能性があります。 たとえば、アナリストは「登録フィールドの横に5頭のゾウを追加してください」と尋ねることがあります。 チームのさまざまなメンバーにとって、当然のことながら、この「次へ」のさまざまなバージョンがあります。右、左、上、下です。
避ける方法
要件が完全に理解されていない場合は、明確な質問をする必要があります。 チームのメンバーは、混乱と思考を避けるために、各タスクの詳細を最大化する方法を学ぶ必要があります。 要件の詳細レベルは、チーム内で交渉されます。 また、すべての人に適したTKテンプレートを開発し、タスクの目的、ロジック、およびユーザーインターフェイスを可能な限り詳細に書き留めることもできます。
7.ターゲットオーディエンスを思い出します。
奇妙なことに、信じる人がいます。できるだけ多くのユーザーを引き付ける方が良いし、その中には確かに製品の対象読者がいるでしょう。 そうではありません。 消費者が特定のユーザーセグメントである特定の製品がある場合があります。
事例紹介
製品のターゲットオーディエンスは主婦ですが、プロジェクトでは大量のトラフィックを獲得したいと考えていました。 かなりの量の広告を費やした後、同社は、大規模なビジネスポータルにあいまいなバナーを公開し始め、溶剤の顧客を呼び込みました。 トラフィックは劇的に増加しましたが、売上は増加していません。 ユーザーがサイトにアクセスして何も買わない理由に関する調査を実施したところ、ほとんどのユーザーは単に対象ユーザーではないことがわかりました。 提案された製品は、単に彼らに興味がなかった。 広告キャンペーンに変更が加えられ、しばらくして問題は解決しました。
避ける方法
最初は、サイトの訪問者が潜在的な顧客でない場合は、ターゲットを絞ったトラフィックの誘引に焦点を合わせ、広告キャンペーンとポジショニングを調整することをお勧めします。
8.仮説をテストするとき、分割テストの交差を避けます
このような問題は、仮説の計画が不十分な場合、またはアナリストの資格が不十分な場合に発生する可能性があります。
事例紹介
同社はランディングページで登録フォームの2つのバージョンのテストを開始しました（ユーザーの50％が1つのバージョンを、50％がもう1つのバージョンを見る）。 その後、支払いエリアで別の仮説をテストする必要が生じ、別のテストが開始されました。 ユーザーの最終アクションに対する変更の影響を評価するような方法でコホートを分割するのに長い時間がかかったため、これはアナリストの作業を複雑にしました。 データを収集するのに、テストを次々に実施するときに必要とされるよりもはるかに長い時間がかかりました。
避ける方法
A / Bテストを実施する場合、スプリットが交差しないようにしてください。 1人のユーザーが1つの実験のみに参加するように、ユーザーを分離してください。 突然2つのテストを一度に実行した場合、4つのグループを評価します。
- 着陸の最初のバージョン+支払いエリアの最初のオプション。
- 着陸の最初のバージョン+支払いエリアの2番目のオプション。
- 支払いゾーンの2番目の着陸オプション+最初のオプション。
- 2番目の着陸オプション+支払いゾーンの2番目のオプション。
9.自分の意見をユーザーの意見と混同しないでください。
よくある間違いの1つは、自分の意見をユーザーの意見として受け入れることです。 製品、そのデザイン、使いやすさが好きなら、ユーザーがあなたの熱意を共有するという事実ではなく、製品との対話方法を理解します。
避ける方法
インターフェイスの各ゾーンを開発するときは、サービス全体の視覚的要素を考慮してください。 ユーザーのことを考えないでください。 彼に（たとえば、フォーカスグループメソッドを使用して）彼が新製品に期待するものよりも快適で、より親しみやすく、どのように優れているかを尋ねます。 製品を発売する前に、Yandexは対面式のテストを実施します。ユーザーと会い、彼らの反応を見て、彼の仮説について不快な質問をします。
開発に関するユーザーの意見を事前に知っていれば、将来多くの問題を回避できます。
10.イベントを最大まで記録する
システムモジュールの動作で物議を醸すような状況が発生した場合、最も迅速かつ簡単な方法は、イベントログを参照することです。 もちろん、そうでない限り。 怠け者でイベントをログに記録しなかった場合、問題が発生したときに問題の主な原因を見つけるために一生懸命働く必要があります。
避ける方法
イベントを最大まで記録します。 これは、マウスを使用したユーザーの動きなど、あらゆる詳細を記録する必要があるという意味ではありませんが、オブジェクトで発生する基本情報を記録する必要があります。
おわりに
どの製品も、新製品の開発時に問題が発生する可能性があります。 主なものは、間違いを認め、結論を導き、将来再発しないように対策を講じることです。
そして、あなたの開発プラクティスでは、障害が発生し、どのように対処しましたか？ コメントであなたの経験を教えてください。
投稿者Ekaterina Hindikainen、リードシステムアナリスト、 ルーキーサービス