大型のベトナムオフショアプロジェクトを進める際の5つの注意点
多くの要因がベトナムオフショアプロジェクトの品質に影響を与えるため、プロジェクトマネージャーやプロダクトオーナーは、スムーズなプロセスと最高のアウトプットを確保するために注意を払う必要があります。
プロジェクトを成功させるために重要な要素は何でしょうか？人材ですか？それが本当ならば、優秀なエンジニアが多いベトナムオフショアチームが、高品質な製品を作ってくれるはずです。実際には、多くの要因がベトナムオフショアプロジェクトの品質に影響を与えるため、プロジェクトマネージャーやプロダクトオーナーは、スムーズなプロセスと最高のアウトプットを確保するために注意を払う必要があります。
1. ベトナムオフショアプロジェクトの要件変更の管理
多くのベトナムオフショア企業は、製品開発にアジャイルモデルを適用し、このモデルは開発プロセス中のあらゆる変更を歓迎します。
要件変更の管理は、ベトナムオフショアプロジェクトの成功を決定する非常に重要な要素です。要件の変更は製品のアウトプットを左右するため、プロジェクトオーナーは顧客の要求に沿った製品を作るために、すべての要件を管理しなければなりません。また、プロジェクトオーナーは変更の優先順位を決定し、その変更を今回のスプリントで行うか、次のスプリントで行うかを決めます。これは、ベトナムオフショアエンジニアが最高のパフォーマンスで仕事ができるようにするために非常に重要なことです。
すべての変更を歓迎しますが、すべての変更を行う必要があるわけではありません。製品にとって不必要な要求もあるので、プロダクトオーナーは、要求に対して顧客にアドバイスをします。
ベトナムオフショアプロジェクトの要件変更に直面したときにすべきことは3つあります。
– ベトナムオフショアプロジェクトの要件変更のためのすべてのチケットを大きなチケットの下に集め、全体を把握し、時間を見積もるための簡単な統計を取る。
– すべての要求を慎重に分析し、その要求の重要性と実行すべきかどうかを判断し、お客様と交渉する。
– 絶対に急いでやってはいけない。たとえ合理的な変更であっても、優先順位を考えてから実行するかどうかを決める。
2. プロセスの構築
特に、多様な人的構成や複雑な仕様のプロジェクトでは、プロセスが欠かせません。
計画段階では、プロセスは見落とされがちで、それ自体が後に計り知れない結果を引き起こす。ベトナムオフショアチームは、ただひたすら作業に集中し、できるだけ早く実行しますが、経営者の視点、特に大規模なシステムの管理のもとでは、新しいプロセスの構築が本当に重要です。早い作業は時に早い手直しにつながりますが、良いプロセスは人的リスクを抑えるのに役立ちます。そのため、ベトナムオフショアチームは常に仕様書を更新し、仕様書が常に最新の状態で、誰もがそれに従うことができるようにしています。
3. OTなし
ベトナムオフショアチームが最高のパフォーマンスを発揮するためには、持続可能で快適な職場環境で働く必要があります。残業をすると、ストレスを感じながら仕事をすることになり、多くの悪い結果を引き起こし、健康や精神に影響を与え、パフォーマンスを低下させてしまいます。
すべての残業が良いわけではありません。人間が1日8時間の仕事をして休むのに苦労したことを思い出してください。仕事が多すぎると、時間がかかった分だけ効果がないことが多いのです。
4. ダッシュボードでデータベースを管理する
これは非常に技術的な問題で、経営者レベルで話すときには言及されないことが多いです。
プロジェクトが小規模で、ベトナムオフショアエンジニアが2、3人参加する程度であれば、ダッシュボードはシンプルで簡単に管理できるでしょう。しかし、3-4チームが管理する数百のテーブルからなるデータベースでは、プロジェクトに参加するベトナムオフショアエンジニアの数は50人にものぼり、彼らは自分が行う機能にしか関心がなく、他の人が行うことには関心がありません。任意のテーブルのネーミングは一貫性を欠いていたり、現場では理解しにくいため、後々の開発が困難になります。
したがって、プロジェクト全体の仕様を理解し、プロジェクト全体のダッシュボードを管理するプロジェクトオーナーが一人いるべきです。
5. 人の管理
人の管理は非常に難しい問題で、特に多くのエンジニアを抱えるベトナムオフショアチームでは尚更です。もっと心配なのは、たとえ良いプロセスを構築しようとしても、そこにいる人たちが本当に「幸せ」でなければ、あなたもそうなるということです。葛藤は、開発者とQAの間でよく起こります。QAと開発者が共通の声を持っていないとき、プロジェクトは緊張状態にあります。ほとんどの人は経験がないので、やり取りが少し厳しすぎたり、無礼だったりします。
開発者は、QAが自分のミスを粗探しをしていると思っていたり、QAは、開発者が自分たちの仕事を尊重していないと思っていたりと、共通の声を見つけられないとストレスが続きます。
プロジェクトを経験した者の仕事は、和解し、善悪を明確にすることです。しかし、柔軟性と警戒心が必要なので、最後の見極めは仕様、バグの問題を解決することであって、他人のミスを掘り起こすことではありません。
