明らかに、商業的に成功するためには、新しいバージョンは前のバージョンよりも「優れている」必要があります。 一方、実践では、開発者とユーザーにとって「より良い」という用語が常に同じことを意味するわけではないことが示されています。
開発者とプロジェクトマネージャーの仕事を組み合わせるのは「幸運」でした。 言い換えれば、私はコードを書くだけでなく、何を変更/追加/削除する必要があるかを決定します。 さらに、後者の繊細さは「外出中」を学ばなければならず、同僚の成功と失敗を分析しました。 実際、これらの観察に記事を捧げたいと思います。
プロジェクトの新しいバージョンは、次の2つの要件を満たせば成功するという結論に達しました。
- ユーザーは、その中に期待する変更を見つけます
- ユーザーは、予期しない変更をその中に見つけません。
ユーザーが期待する変更
これらは2つのタイプに分類できます。
- バグ修正
- 新機能
すべてがシンプルに思えます。 しかし、期限に問題があり、「残りのエラーを修正するか、新しい機能を追加しますか？」という質問が発生すると、この単純性は崩れます。 明確な答えを出すことはできません。 もちろん、完璧主義者は間違いを訂正する必要があると言うでしょう。 しかし、市場では、人々は新機能にお金を払うと言っています。 最も悪いのは、最初に重大なエラーを修正してから、新しいエラーを追加せずに新しい関数を追加することです。 他のすべてはホットフィックスとパッチで修正できますが、これは「美しく」はありません。 私の場合、この特定の戦略を選択すると、最良の結果が得られました。
ユーザーが予期しない変更
残念ながら、開発者はこのアイテムを誤って（または意図的に）忘れることがあります。 この理由は、彼らが新しいユーザーを引き付けようとしているためかもしれません。 ただし、新しいバージョンのソフトウェアの成功は、以前のバージョンのユーザーが購入したかどうかにも依存することを忘れないでください。 そして、彼らだけのために、そのような変更は重要です。
このような変更のタイプのリストは非常に大きくなる可能性がありますが、2つに焦点を当てます。
- 下位互換性
- 設計変更
下位互換性は非常に重要です。 あなたの製品を何年も使用している人は（なぜそうではないのでしょうか）、新しいバージョンがプロジェクトで動作できないことを知った後、非常に「失望」します。 したがって、あなたはそれらを失ったと言うことができます。
しかし、設計の変更により、すべてがそれほど単純ではありません。 一方では、変更する必要があります。 時間が経つにつれて、テクノロジーは変化し、「1999年からのハロー」デザインはもはや一般的ではありません。 一方、実践では、多くのユーザーが非常に保守的であることが示されています。 「隅にあるボタンがない」ことや、配色の変更のために、彼らは非常に苦痛を感じることができます。 したがって、非常に良い解決策は、「古いスタイル」のチェックマークを設定のどこかに追加することです。
おわりに
もちろん、実際にはさらに多くの問題があります。 私は自分が出会ったそれらを説明しようとしました。 おそらくもっと深刻な問題や信頼できる解決策があれば、私はそれらについて聞きたいです。
アクションのガイドとして、次を追加します。 あなたがスティーブ・ジョブズでないなら、あなたはユーザー単純化を考慮すべきではありません。 個人的には、「ユーザーは自分の欲しいものを知っているが、それを説明できない」というアプローチを選んだ。 現時点では、私と当局はこのアプローチの結果に満足しています。