製品を開発するとき、チームはプロジェクトの現在の状態と格闘するのをやめ、今度は「正しく」「科学的に」すべてを書き直したいという欲求をしばしば持っています。 通常、そのような衝動は承認されませんが、今回はHugoBaraúnaによる投稿の翻訳を読みたいと思います。
優れたリファクタリングと同様に、製品の書き換えは簡単なことではありません。 長年にわたり、書き換えプロセスを計画および実装する際に考慮すべきことを示すのに十分な経験を積んできました。
両方のプラットフォームが同時に存在しますか？
本番環境で古いバージョンと新しいバージョンをサポートする予定はありますか？ もしそうなら、どのくらいの間？ 運用コストのため、長時間にわたって2つのバージョンの実稼働環境を提供することは避けてください。
誰が書き直し、誰が古いバージョンをサポートしますか？
開発者は、有望なプロジェクト（グリーンフィールドプロジェクト）に取り組むことを好みます。 誰が古いバージョンをサポートし、誰が新しいバージョンで作業するかを決定するときは、このことに留意する必要があります。
すべてを一度にコピーしても意味がありません
古いバージョンと新しいバージョンを1対1でマッピングするのは合理的ではありません。 言い換えると、正確にどの機能を書き直す必要がありますか？
機能の少ない顧客がどのように影響するかを検討してください。
書き換えにより、古いバージョンの新機能の導入が遅くなったり、停止したりします
おそらく、古いバージョンを書き換える過程で新しい機能を導入しないでしょう。 エンドユーザーだけでなく、内部顧客（商業部門および製品部門）も新しい機会を得ることができません。 社内の顧客と株主は、新しい機会をあなたに求めます。
文字起こしの前後に相互作用が確立され、すべての関係者が最終目標に同意することを確認してください。
秘密にするか公開しますか？
あなたがソフトウェア製品の潜在的なクライアントであると想像してください。 あなたはそれを購入することを計画していますが、あなたは完全に新しいバージョンが3ヶ月で提示されることを発見しました。 古いバージョンを購入しますか、それとも3か月待ちますか？ これに数十または数百の潜在的なバイヤーを掛けます。 サプライヤーは大量のお金を失う可能性があります。
したがって、製品のサプライヤである場合、根本的に新しいバージョンに関する情報をいつどのように公開するかを慎重に検討する必要があります。
データ移行
書き換えとは、単に機会を開発することではありません。 データの移行も計画する必要があります。 人々は通常、古いバージョンから新しいバージョンにデータを移行するために必要な複雑さとコストを過小評価しています。 このアクティビティは、リストの「データ移行」という見出しの1つのタスクだけではありません。
たとえば、ユーザーアカウントを移行する必要があるとします。 レガシーバージョンがサードパーティによって管理されている場合、暗号化されたユーザーパスワードにアクセスできない可能性が高いため、それらを転送することはできません。 新しいバージョンでパスワードをリセットするには、各ユーザーに個別に尋ねる必要があります。 これもデータ移行プロセスの一部です。
コンバージョンの減少の可能性に備えてください
新しい機能を備えた新しいバージョンを起動します。 変換が同じままであることを誰が保証できますか？ eコマースなどの一部の領域では、変換が不可欠です。
理想的には、変換の低下が強すぎる場合に備えて、新しいバージョンと古いバージョンの両方をしばらく保持できるようにする必要があります。
時間をかけて社内ユーザーをトレーニングする
これもしばしば見落とされます。 書き換え計画には、新製品を実稼働環境にリリースする前に、内部ユーザーを教育することに専念するフェーズが必要です。 これも過小評価できません。 内部ユーザーが変更の必要性についてフィードバックを提供できるようになるまでに時間がかかる場合があります。
内部ユーザーは、カスタマーサポートや販売など、さまざまな分野で見つけることができます。
あなたはどうですか？ 製品を書き換える際に何を心配するかについてのヒントはありますか？ 私たちと共有してください！