ソフトウェアプロジェクトのオフショアリング—競合の解決[終了]

私は、一部のウクライナの開発者に外部委託されたプロジェクトの管理を任されていました。

同社は、を介してそれらを雇ったElanceをで固定価格。その時点で、上司はそれらを処理し、仕事を成し遂げるために私を一人にしました。行う必要がある完全なものの詳細な仕様を作成しました。

このプロジェクトには、XMPP、RabbitMQ、データベースなどの処理が含まれていました。彼らとの最初の会議（常にIM）で、彼らが何をする必要があるかを徹底的に説明しました。彼らはそれを理解しているようでした-そして彼らはそれが簡単に行われると非常に確信していました。

ここまでは順調ですね。しかし、1週間後、私たちが再会したとき、彼らは何をすべきかについての誤解に満ちていました。開発者の1人にXMPPを知っているかどうか尋ねたとき、彼はXMPPを初めて使用していると言いました。最初の会議で、プロジェクトの複雑さと関連する技術について具体的に言及しました。加えて、私は彼らに彼らがそれを行う正確な方法の機能仕様を書くように繰り返し求めました。しかし、彼らはノーと言い、むしろコードを書きたいと主張しました。私はオーケーと言った。

プロジェクトは3週間後に完了し、必要なものを提供しました。その時点で、コードのレビューを開始しました。大部分は大丈夫でしたが、いくつかの重要な問題がありました。

• 彼らは設定ファイルに分離する必要があるもののいくつかをハードコーディングしました
• 1つに統合する必要がある複数の構成ファイルがありました
• 彼らはまったくドキュメントを書いていません
• その他の小さな変更

これらの変更を行うように依頼しました（ドキュメントを除く）-そして、議論がありました。

彼らは、価格が修正されたので、私は彼らが作業コードを完成したら変更を加えるように頼むことにおいて不公平であったと言った。彼らがプロジェクトに不合理な時間を費やし、今では何かを求めるのは完全に間違っていました。

最後に、彼らは変更を加え、プロジェクトは終了しました。しかし、それは私の心にいくつかの質問を残します...

• 彼らは必要なことをしましたが、私はそれを適切に行う必要がありました。私は本当に不公平でしたか？

• 機能仕様がなくてもコードを許可することに同意したのはなぜですか？

• 彼らがすべてを初めて理解したことを確認しなかったのはなぜですか？

誰もが同じ立場にいますか？外部委託プロジェクトを管理するより良い方法があると思いますか？

-更新-

すべての意見をありがとう-全体の経験を反映した後、私は結論づけることができます...

• 私は自分の側から仕様を曖昧にしたわけではありませんでしたが、私は確かにそれらを示唆されたように鉄で覆いませんでした。したがって、テイクアウェイは次のとおりです：常にできるだけ具体的にしてください-スペックもその観点から読んで、何かを見逃していないかどうかを確認してください。少なくとも3回繰り返します。

• コードが何をすべきかを指定するだけでは不十分です。コードの外観を指定する必要があります。ディレクトリ構造は何ですか。可能であればファイル名も。これにより、後で多くの迷惑からあなたを救います。コーディングガイドライン、変数の命名規則、内部ドキュメント形式などを厳密に指定します。それらのガイドラインに従っていることを確認し、そうでない場合は悲鳴を上げます。

• 彼らの側から機能仕様を要求します-それはコードの前に書かれることを主張します。これにより、多くの混乱と誤解がなくなります。

• 開発中のコードを確認し、異常を早期に特定して修正できるようにします。1日おきに少なくとも1回は話しかけます。

• 最後に、彼らと良い関係を築こうとする。彼らの仕事に感謝していると感じさせます。ガイドラインに合わせて誇張してプッシュしないでください。代わりに、そうするように要求し、プロジェクトが完了したらコードのメンテナンスが非常に簡単になることを伝えてください。

まず、これはオフショアリングの問題ではなく、ベンダー管理の問題です

はい、あなたは多くの間違いを犯しました…

彼らは必要なことをしましたが、私はそれを適切に行う必要があったので、変更しました。私は本当に不公平でしたか？

はい、それは公平です、あなたがそれを特定の方法でやりたいなら、あなたは価格が合意される前に言ったはずだったので、彼らはそれに応じて入札することができます。

機能仕様がなくてもコードを許可することに同意したのはなぜですか？スペックの支払いを 望まなかったからです！ドキュメンテーションは時間と費用がかかりますが、無料でやるべきですか？

彼らがすべてを初めて理解したことを確認しなかったのはなぜですか？

彼らは理解しました。しかし、契約が署名された（そして固定価格が合意された）後の最初のミーティングでは、あなたがそれを検証しました！だから、できる限りコスト（時間）を削減する必要がありました。基本的には、週に1回だけ会議を開催することで、混乱のオプションを提供しません。

次にこれを行う方法を示します…2つのフェーズで…

フェーズ1：要件を収集し、システム分析を実行し、技術設計および/または機能仕様を記述します（または自分で記述します）。このフェーズの価格に同意します。必ず開発フェーズを提供するというコミットメントがないことを説明してください。必ず会議の時間を価格に含めてください。

フェーズ2：彼ら（およびあなた）が持っている仕様に基づいて開発されたものに入札してもらい、その努力が実際に関係していることを知ってもらいます。再度、価格に会議の時間を含めるようにしてください。変更のための小さなオプションの予算を含めるため。

編集：追加のポイントを追加したい。.ベンダーにも問題があります。プロジェクト管理の手引きとして、仕事の一部が役に立たず、プロセスの不足箇所をお知らせします。

私はそれを適切に行う必要がありました

その後、外部委託しないでください。そうする場合は、プロジェクトチームで作業し、その時点でコードレビューに参加することを確認してください。

プロジェクトは3週間後に完了し、必要なものを提供しました。その時点で、コードのレビューを開始しました。

繰り返しますが、プロジェクトの後ではなく、プロジェクト中にコードをレビューする必要がありました。

彼らは、価格が修正されたので、私は彼らが作業コードを完成したら変更を加えるように頼むことにおいて不公平であったと言った。

作業コードの固定価格を支払いました。おっとっと。それは彼らのせいではなく、あなたのせいです。あなたがコントロールするスプリントに参加するために彼らの時間を払ってください。そうすれば、この問題に遭遇することはありません。コードではなく、時間と受け入れられたユーザーストーリーに対して料金を支払う必要があります。

彼らとの最初の会議（常にIM）では、彼らが何をする必要があるかを徹底的に説明しました。彼らはそれを理解しているようでした-そして彼らはそれが簡単に行われると非常に確信していました。

完全に外部委託されたプロジェクトを扱うときは、仕様が厳格であることを確認する必要があります。数文よりも時間がかかるものを説明する必要がある場合、仕様は完全ではありません。これが仕様から逸脱した理由です。

開発者の1人にXMPPを知っているかどうか尋ねたとき、彼はXMPPを初めて使用していると言いました。

一般的な低コストのオフショアリング国へのアウトソーシングでは、開発者が履歴書やスキルを過度に膨らませて仕事を得ることが一般的です。彼らは多くの場合、実際に快適な生活賃金を支払うギグを上陸させるために建物を再開するため、上陸するまで能力について心配しません。

機能仕様がなくてもコードを許可することに同意したのはなぜですか？

あなただけが自分でこれに答えることができますが、次回の学習体験としてそれを取る。

会社は固定価格でElanceを通じて彼らを雇いました。その時点で、上司はそれらを処理し、仕事を成し遂げるために私を一人にしました。行う必要がある完全なものの詳細な仕様を作成しました。

それで、あなたの二人は最初に契約を結び、それから彼らはあなたにスペックを書かせて、彼らはあなたの契約の一部になるためにそのスペックを受け入れましたか？それがそうだったなら、それはあなたのせいではありません、それはあなたの請負業者のせいです。3週間ではなく3か月の作業をすべて同じ価格で提供する仕様を簡単に作成できます。

大部分は大丈夫でしたが、いくつかの重要な問題がありました。

• 彼らは設定ファイルに分離する必要があるもののいくつかをハードコーディングしました
• 1つに統合する必要がある複数の構成ファイルがありました
• 彼らはまったくドキュメントを書いていません
• その他の小さな変更

これらは仕様の一部でしたか？もしそうなら、それは彼らのせいです。そうでない場合、それはあなたのものです。これらが仕様に含まれているかどうかが明確でない場合は、ドキュメントを作成したため、それもあなたの責任です。次回はより良い仕様を書いてみてください。

少し前にオフショアリングについてプレゼンテーションをしました。「グローバルアウトソーシング、ビジネスを強化するための10のヒント」と呼ばれていました。10のヒントの要約を以下に示します（これは、最大400の外部委託プロジェクトから得られます）。

選択

1. 最低入札者と最高入札者を避けてください。これは明らかです。低い入札者でリスクを取りたくないので、最高入札者は中央値よりも価値（価格）が低い傾向があります。

2. 評価（または参照）を確認します。私は常に参照と評価を確認します。

3. モチベーションを優先します。同じ価格で、動機付けられた入札を選択します。たとえば、入札者にあなたのプロジェクトについて正しく話してもらうことは非常に良い兆候です。

B.監督

1. 知的財産を保護します。これは最大の間違いの1つです。通常、使用するプラットフォーム（vworkerやelanceなど）によって処理されます。

2. カスタムフレームワークを拒否します。または、あなたはそれに縛られるリスク、より具体的にはそれを書いた開発者に縛られるリスクがあります;）

3. 標準を課す。前のヒントに関連。標準を使用すると、より多くの開発者が理解できるため、ソースコードの価値が高まります。

4. 早期にレビューし、頻繁にレビューします。最初の週または作業後にソースコードを確認する場合、ほとんどの問題は「調整」できます。

C.戦略

1. 小規模プロジェクトのテストプロバイダー。プロバイダーに大きなプロジェクトを提供する前に、1つまたは2つの小さなプロジェクトでテストします。

2. リスクを軽減するために複数の入札者を受け入れます。重要なプロジェクトの場合、2つまたは3つの入札者を選択し、最適な実装を行います。小さなプロジェクト（5000ドル未満）で最適に動作します。

3. コンポーネントを組み立てます。別の戦略は、後で組み立てるコンポーネントを外部委託することです。利点の1つは、プロバイダーを簡単に切り替えることができ、実際にすべてのものにアクセスできない（知的財産のリスクを減らす）ことです。

maple_shaftの答えに完全に同意します。

あなたはコードを受け入れ、チェックを書いてからコードをレビューしたと思います。

機能仕様がなくてもコードを許可することに同意したのはなぜですか？

契約書に書いていないからです。あなたは仕事をやりたいと思ったので、それがあなたをトラブルに巻き込んだまさにそのことであるにもかかわらず、あなたは彼らの理由を受け入れました。

彼らがすべてを初めて理解したことを確認しなかったのはなぜですか？

あなたは彼らにあなたがうまくいくと思ったデザインを提供すべきだった。そうすれば、彼らが完全に理解していなくても大した問題にはなりません。あなたはそれをするために彼らにお金を払わなかったので、誰がそれをするつもりですか？このコードは、ドキュメントや設計仕様なしでどのように維持されますか。答えはそうではないでしょう。

彼らは、価格が修正されたので、私は彼らが作業コードを完成したら変更を加えるように頼むことにおいて不公平であったと言った。

彼らはあなたが望む変更を行ったのは幸運です。彼らは言うことができた：タフな運

誰もが同じ立場にいますか？外部委託プロジェクトを管理するより良い方法があると思いますか？

もちろん、そうでなければ、他の人があなたの立場にいます。「アウトソーシング」業界全体が傷つくことはありません。多くの企業は、それを行うために3回または4回支払う必要があることに気付き始めています。 。

少なくとも自分で実行することで、プロジェクトのステータスを毎日確認できます。背後にいる場合、少なくとも理論的には、損傷を制御するためにできることがあります。