ソフトウェアプロジェクトのオフショアリング-競合の解決
私は一部のウクライナの開発者に外部委託したプロジェクトの管理を任されていました。
会社は Elance を介して固定価格で雇用しました。その時点で、上司は私にaloneを残してそれらを処理し、作業を完了させました。実行する必要がある完全なものの詳細な仕様を作成しました。
このプロジェクトには、XMPP、RabbitMQ、データベースなどの処理が含まれていました。彼らとの最初のミーティング（常にIM）で、私は彼らが何をする必要があるかを徹底的に説明しました。彼らはそれを理解しているようでした-そして、彼らはそれが簡単に行われるであろうと非常に確信していました。
ここまでは順調ですね。しかし、1週間後、私たちが再び会ったとき、彼らは何をする必要があるかについての誤解に満ちていました。開発者の1人にXMPPを知っているかどうか尋ねたところ、彼はXMPPを初めて使用していると述べました。最初の会議では、プロジェクトの複雑さと関連するテクノロジーについて非常に具体的に言及しました。加えて、私は繰り返し、彼らに 機能仕様 を書く方法を彼らにどのように書いてほしいかを繰り返し求めていました。しかし、彼らはノーと言って、むしろコードを書くことを主張しました。私はオーケーと言いました。
プロジェクトは3週間後に完了し、必要なものが提供されました。その時点で、コードのレビューを開始しました。大部分は問題ありませんでしたが、いくつかの重要な問題があります。
- 彼らは、構成ファイルに分離する必要があるもののいくつかをハードコーディングしました
- 1つに統合する必要がある複数の構成ファイルがあった
- 彼らは全く文書を書きませんでした
- その他いくつかのマイナーな変更
私は彼らにこれらの変更を加えるように頼みました（ドキュメントを除く）-そして、私たちは議論をしました。
彼らは、価格が固定されていたので、彼らが作業コードを完成させたら変更を依頼するのは不公平だったと述べました。彼らがプロジェクトに不当な時間を費やしていたが、今は何かを求めるのはまったく間違っていた。
ついに彼らは変更を行い、プロジェクトは終わりました。しかし、それは私の心にいくつかの質問を残します...
彼らは必要なことをしましたが、私はそれを必要とし正しく行われました、それゆえ変更点。私は本当に不公平だったのですか？
機能仕様なしにコードを記述させることに同意したのはなぜですか？
なぜ彼らがすべてを最初に理解したことを確認しなかったのですか？
誰もが同じ立場にいますか？外部委託プロジェクトを管理するより良い方法があると思いますか？
-更新-
すべての意見に感謝します-全体の経験を振り返って、結論を出すことができます...
私は自分の側から仕様を漠然としていませんでしたが、提案されているようにironcladを作成しなかったことは確かです。したがって、重要な点は、常に可能な限り具体的なものにすることです。仕様もその観点から読み、何かを見落としていないか確認してください。少なくとも3回繰り返します。
コードが何をすべきかを指定するだけでは不十分です。コードの外観を指定する必要があります。ディレクトリ構造はどうなるか。可能であればファイル名も。これにより、後で煩わしさから解放されます。コーディングのガイドライン、変数の命名規則、内部のドキュメント形式などを厳密に指定してください。ガイドラインに準拠していることを確認し、準拠していない場合は悲鳴を上げてください。
彼らの側から機能仕様を要求してください-それはどんなコードよりも前に書かれるべきだと主張してください。これにより、混乱や誤解が多くなります。
開発中のコードを確認して、異常を早期に特定し、修正してください。少なくとも一日おきに彼らと話してください。
最後に、彼らと良い関係を築くようにしてください。彼らにあなたが彼らの仕事に感謝していると感じさせる。ガイドラインに合わせるために誇張してプッシュしないでください。代わりに、そうするように依頼して、プロジェクトが完了したらコードの保守が非常に簡単になることを伝えます。
はじめにこれはオフショアリングの問題ではなく、ベンダー管理の問題です
はい、あなたは[〜＃〜] alot [〜＃〜]間違いをしました…
彼らは必要なことを行いましたが、私はそれを適切に行う必要があり、それゆえ変更がありました。私は本当に不公平だったのですか？
はい、それは公平です。あなたがそれを特定の方法で実行したい場合は、価格が合意される前に、彼らがそれに応じて入札できるように言うべきでした。
機能仕様なしでコードを記述させることに同意したのはなぜですか？[〜＃〜] pay [ 〜＃〜]仕様に！ドキュメンテーションは時間と費用がかかりますが、無料でやればいいですか？
なぜ彼らがすべてを最初に理解したことを確認しなかったのですか？
彼らは理解しました。しかし、あなたの最初の会議契約が署名された後（および合意された固定価格）は、あなたがそれを実行したときです！だから、できる限りコスト（時間）を削減する必要がありました。基本的には、週に1回だけ会議を開催することで、論争のオプションを与えません。
これを次に行う方法です... 2つのフェーズで...
フェーズ1：要件を収集し、システム分析を実行して、技術設計および/または機能仕様を記述します（または自分で記述します）。このフェーズの価格について合意します。開発段階を提供するというあなたの側の責任がないことを説明するようにしてください。価格には会議の時間を含めるようにしてください。
フェーズ2：彼ら（およびあなた）が現在持っているスペックに基づいて開発されたものに入札してもらい、努力が実際に関与していることを本当に知ってもらいます。もう一度、価格に会議の時間を含めるようにしてください。変更のための小さなオプション予算を含めるため。
編集：もう1つポイントを追加したいと思います。ここでもベンダーに欠陥があります。その仕事の一部は、プロジェクト管理の手助けにもなり、プロセスのどこが足りないかを知らせます。
私はそれを適切に行う必要がありました
次に、それをアウトソーシングしないでください。そうする場合は、それらがプロジェクトチームで機能し、そのときにコードレビューに参加していることを確認してください。
プロジェクトは3週間後に完了し、必要なものが提供されました。その時点で、コードのレビューを開始しました。
繰り返しになりますが、プロジェクトの後ではなく、プロジェクト中にコードをレビューする必要がありました。
彼らは、価格が固定されていたので、彼らが作業コードを完成させたら変更を依頼するのは不公平だったと述べました。
動作するコードに対して固定価格を支払いました。おっとっと。それはあなたのせいではありません。あなたがコントロールするスプリントに参加する彼らの時間を払えば、あなたはこの問題にぶつかることはありません。コードではなく、時間と受け入れられたユーザーストーリーに対してそれらを支払う必要があります。
彼らとの最初のミーティング（常にIM）で、彼らが何をする必要があるかを徹底的に説明しました。彼らはそれを理解しているようでした-そして、彼らはそれが簡単に行われるであろうと非常に確信していました。
完全に外部委託されたプロジェクトを扱う場合、仕様が厳格であることを確認する必要があります。数文よりも長くかかることを説明する必要がある場合、仕様は完全ではありません。これが、仕様から逸脱した理由です。
開発者の1人にXMPPを知っているかどうか尋ねたところ、彼はXMPPを初めて使用していると述べました。
仕事を着陸させるためだけに、開発者が履歴書とスキルを過剰に膨らませるために、人気のある低コストのオフショアリング国にアウトソーシングするとき、それは一般的です。彼らが着陸するまで、彼らは能力について心配しないことがよくあります。彼らの多くは、実際に快適な生活費を支払うギグを着陸させるために建物を再開するだけだからです。
機能仕様なしにコードを記述させることに同意したのはなぜですか？
あなただけが自分でこれに答えることができますが、次回の学習体験として取り入れてください。
同社はElanceを通じて固定価格でそれらを雇った。その時点で、上司は私を一人にしてそれらを処理し、仕事を終わらせました。実行する必要がある完全なものの詳細な仕様を作成しました。
それで、あなたのふたりfirstは契約を結び、そしてthenはあなたが仕様を書けるようにしました、そして彼らはあなたの契約の一部になるためにその仕様を受け入れましたか？それがそうだった場合、それはあなたのせいではなく、それはあなたの請負業者のせいです。同じ価格で、3週間ではなく3か月の作業時間を与える仕様を簡単に作成できます。
大部分は問題ありませんでしたが、いくつかの重要な問題があります。
- 彼らは、構成ファイルに分離する必要があるもののいくつかをハードコーディングしました
- 1つに統合する必要がある複数の構成ファイルがあった
- 彼らは全く文書を書きませんでした
- その他いくつかのマイナーな変更
これらはあなたの仕様の一部でしたか？もしそうなら、それは彼らのせいです。そうでない場合、それはあなたのものです。これらが仕様に含まれているかどうかが本当に明確でない場合は、ドキュメントを作成したため、それもあなたの責任です。次回はもっと良いスペックを書いてみてください。
先ほどオフショアリングについてプレゼンテーションをしました。それは「グローバルアウトソーシング、あなたのビジネスに力を与える10のヒント」と呼ばれていました。以下は10のヒントの要約です（これは最大400の外部委託プロジェクトからのものです）：
A。選択
最低入札者と最高入札者を避けます。これは明らかです。入札者が低くてもリスクを冒したくないので、入札者の最高額は中央値よりも価値が低い（値/価格）傾向があります。
評価（または参照）を確認。私は常に参考文献と評価をチェックしています。
動機を優先する。同じ価格で、やる気のある入札を選びます。たとえば、入札者にあなたのプロジェクトについて正しく話させることは非常に良い兆候です。
B。監督
知的財産の保護。これは最大の間違いの1つです。通常、使用するプラットフォーム（vworkerやelanceなど）によって処理されます。
カスタムフレームワークを拒否。または、あなたはそれ、またはより具体的にはそれを書いた開発者に縛られる危険があります;）
インポーズ基準。前のヒントに関連しています。標準を使用すると、より多くの開発者が理解できるように、ソースコードの価値が高まります。
早期レビュー、頻繁なレビュー。最初の1週間後または作業後にソースコードを確認すると、ほとんどの問題は「調整」できます。
C。戦略
小規模プロジェクトのテストプロバイダー。プロバイダーに大きなプロジェクトを渡す前に、1つまたは2つの小さなプロジェクトでテストします。
リスクを減らすために複数の入札者を受け入れる。重要なプロジェクトの場合は、2人または3人の入札者を選択し、最適な実装を採用します。小さなプロジェクト（$ 5000未満）で最適に動作します。
コンポーネントの組み立て。別の戦略は、後で組み立てるコンポーネントを外部委託することです。 1つの利点は、プロバイダー間を簡単に切り替えることができ、実際には全体にアクセスできない（知的財産のリスクを軽減する）ことです。
Maple_shaftの答えに完全に同意します。
あなたはコードを受け入れ、私はチェックを書いて、コードをレビューしたと思います。
機能仕様なしにコードを記述させることに同意したのはなぜですか？
契約書に書いていないからです。あなたは仕事をやりたいと思ったので、あなたは彼らの理由を受け入れました。
なぜ彼らがすべてを最初に理解したことを確認しなかったのですか？
あなたは彼らがあなたがうまくいくと感じたデザインを彼らに提供するべきでした。そして、彼らが完全に理解していなくても、それは本当に問題ではありません。私はあなたが彼らにそれをするために彼らに払わなかったので誰がそれをするつもりですか？このコードは、ドキュメントや設計の仕様なしでどのように維持されますか。おそらくその答えはされないです。
彼らは、価格が固定されていたので、彼らが作業コードを完成させたら変更を依頼するのは不公平だったと述べました。
あなたは彼らがあなたが望む変更を加えたのは幸運です。彼らは言うことができた：頑張って
誰もが同じ立場にいますか？外部委託プロジェクトを管理するより良い方法があると思いますか？
もちろん、他の人はあなたの立場にいます。そうでなければ、「アウトソーシング」業界全体が害を及ぼすことはなく、多くの企業はそれを行うために支払う（または待つ）必要があることに気づき始めています。 。
少なくとも自分で行うことで、プロジェクトのステータスを毎日確認できます。背後にいる場合、少なくとも理論的には、損傷を制御するためにできることがいくつかあります。