Délocalisation d'un projet logiciel - Résolution des conflits [clôturé]

J'avais été chargé de gérer un projet qui était sous-traité à certains développeurs ukrainiens.

L'entreprise les a embauchés via Elance à un prix fixe . À ce moment-là, mon patron m'a laissé seul pour les gérer et faire le travail. J'ai créé une spécification détaillée de la chose complète qui devait être faite.

Le projet consistait à traiter des choses telles que XMPP, RabbitMQ et Database. Lors de ma première rencontre avec eux (toujours IM), j'ai expliqué à fond ce qu'ils devaient faire. Ils semblaient le comprendre - et ils étaient convaincus que cela se ferait facilement.

Jusqu'ici tout va bien. Mais après une semaine, lorsque nous nous sommes revus, ils étaient pleins de malentendus sur ce qui devait être fait. Lorsque j'ai demandé à l'un des développeurs s'il connaissait XMPP, il m'a répondu qu'il y travaillait pour la première fois. Lors de notre première rencontre, j'avais mentionné très précisément la complexité du projet et les technologies impliquées. De plus, je leur avais demandé à plusieurs reprises d'écrire une spécification fonctionnelle exactement COMMENT ils le feraient. Mais ils ont dit NON et ont insisté pour qu'ils préfèrent écrire le code. J'ai dit OK.

Le projet s'est terminé après 3 semaines et ils ont livré ce qui était nécessaire. À ce stade, j'ai commencé à revoir le code. C'était correct pour la plupart, mais il y avait des problèmes importants:

• ils ont codé en dur certaines des choses qui devaient être séparées dans un fichier de configuration
• il y avait plusieurs fichiers de configuration que je devais consolider en un
• ils ont écrit absolument AUCUNE documentation
• quelques autres changements mineurs

Je leur ai demandé de faire ces changements (sauf la documentation) - Et nous avons eu un argument.

Ils ont dit, puisque le prix était fixe, j'étais injuste en leur demandant d'apporter des modifications une fois qu'ils avaient terminé le code de travail. Qu'ils avaient travaillé pendant un temps déraisonnable sur le projet et maintenant c'était complètement faux de demander quoi que ce soit.

Enfin, ils ont maintenant fait les changements et le projet est terminé. Mais cela laisse quelques questions dans mon esprit ...

• Ils ont fait ce qu'il fallait mais j'avais besoin que cela soit fait correctement , et donc les changements. étais-je vraiment injuste?

• Pourquoi ai-je accepté de leur laisser du code sans avoir de spécification fonctionnelle?

• Pourquoi ne m'étais-je pas assuré qu'ils avaient tout compris la première fois?

Quelqu'un se retrouve-t-il dans la même position? Pensez-vous qu'il existe une meilleure façon de gérer les projets externalisés?

-- METTRE À JOUR --

Merci pour toutes les opinions - après avoir réfléchi à toute l'expérience, je peux conclure ...

• Bien que je ne sois pas vague dans les spécifications de mon côté, je ne les ai certainement pas rendues étanches comme suggéré. Le point à retenir est donc: soyez toujours aussi précis que possible - lisez également vos spécifications de leur point de vue et voyez si vous avez oublié quelque chose. Répétez-le au moins trois fois.

• Il ne suffit pas de spécifier ce que le code devrait faire. Vous devez spécifier à quoi le code est censé ressembler. Quelle sera la structure du répertoire; même les noms de fichiers si possible. Cela vous évitera bien des ennuis plus tard. Spécifiez strictement les directives de codage, les conventions de dénomination des variables, le format de documentation interne, etc. Veillez à ce qu'elles respectent ces directives, et sinon, criez.

• Exigez une spécification fonctionnelle de leur part - insistez pour qu'elle soit écrite avant tout code. Cela éliminera beaucoup de confusions et de malentendus.

• Examinez le code au fur et à mesure de son développement afin d'identifier les anomalies plus tôt et de les corriger. Parlez-leur au moins une fois tous les deux jours.

• Enfin, essayez de nouer de bonnes relations avec eux. Faites-leur sentir que vous appréciez leur travail. Ne les poussez pas exagérément pour correspondre à vos directives - demandez-leur plutôt de le faire et dites-leur que cela rendrait le maintien du code beaucoup plus facile pour vous une fois le projet terminé.

Tout d'abord, ce n'est pas un problème de délocalisation, c'est un problème de gestion des fournisseurs

Oui, vous avez fait BEAUCOUP d'erreurs…

Ils ont fait ce qui était nécessaire mais j'avais besoin que cela soit fait correctement, et donc les changements. étais-je vraiment injuste?

Oui, c'est juste, si vous vouliez que cela se fasse d'une certaine manière, vous auriez dû le dire avant que le prix ne soit convenu, afin qu'ils puissent enchérir en conséquence.

Pourquoi ai-je accepté de leur laisser du code sans avoir de spécification fonctionnelle? Parce que vous ne vouliez pas payer pour la spécification! La documentation prend du temps et coûte cher, devrait-elle le faire gratuitement?

Pourquoi ne m'étais-je pas assuré qu'ils avaient tout compris la première fois?

Ils ont compris. Mais lors de votre première réunion APRÈS que le contrat a été signé (et le prix fixe convenu), c'est lorsque vous l'avez EXPRIMÉ! Il fallait donc réduire les coûts (heures) là où ils pouvaient. Fondamentalement, en ne tenant qu'une réunion par semaine, sans donner d'options de confutation.

Voici comment procéder la prochaine fois… en deux phases…

Phase 1: Demandez-leur de rassembler les exigences, d'effectuer l'analyse des systèmes et de rédiger la conception technique et / ou la spécification fonctionnelle (ou de l'écrire vous-même). Convenez d'un prix pour cette phase. Assurez-vous d'expliquer qu'il n'y a aucun engagement de votre part pour leur donner la phase de développement. Assurez-vous d'inclure du temps pour la réunion dans le prix.

Phase 2: Demandez-leur de soumissionner sur le produit développé en fonction des spécifications maintenant qu'ils (et vous) avez, et sachez vraiment que l'effort est impliqué. Assurez-vous à nouveau d'inclure du temps pour les réunions dans le prix. Parce que pour inclure un petit budget optionnel pour les changements.

Edit: je veux ajouter un point supplémentaire .. Le vendeur est également en faute ici, une partie de son travail est aussi trop utile pour vous guider dans la gestion de projet et vous faire savoir où il y a des lacunes dans le processus.

J'en avais besoin bien fait

Alors ne l'externalisez pas, ou si vous le faites, assurez-vous qu'ils travaillent dans votre équipe de projet et que vous participez à des révisions de code à ce moment-là.

Le projet s'est terminé après 3 semaines et ils ont livré ce qui était nécessaire. À ce stade, j'ai commencé à revoir le code.

Encore une fois, vous auriez dû revoir le code pendant le projet, pas après.

Ils ont dit, puisque le prix était fixe, j'étais injuste en leur demandant d'apporter des modifications une fois qu'ils avaient terminé le code de travail.

Vous leur avez payé un prix fixe pour le code de travail. Oups. Ce n'est pas de leur faute, c'est la vôtre. Payez leur temps pour participer aux sprints que vous contrôlez et vous ne rencontrerez pas ce problème. Vous devez les payer pour le temps et les user stories acceptées, pas pour le code.

Lors de ma première rencontre avec eux (toujours IM), j'ai expliqué à fond ce qu'ils devaient faire. Ils semblaient le comprendre - et ils étaient convaincus que cela se ferait facilement.

Lorsque vous traitez un projet complètement externalisé, vous devez vous assurer que vos spécifications sont à toute épreuve. Si vous devez expliquer quelque chose qui prend plus de temps que quelques phrases, votre spécification n'est pas terminée. C'est pourquoi ils ont dévié de la spécification.

Lorsque j'ai demandé à l'un des développeurs s'il connaissait XMPP, il m'a répondu qu'il y travaillait pour la première fois.

Il est courant lors de l'externalisation vers des pays de délocalisation à faible coût populaires pour les développeurs de sur-gonfler leurs curriculum vitae et compétences juste pour décrocher le poste. Souvent, ils ne s'inquiètent pas de leurs capacités jusqu'à ce qu'ils l'atterrissent, car beaucoup d'entre eux ne font que reprendre la construction pour décrocher le concert qui paie réellement un salaire de subsistance confortable.

Pourquoi ai-je accepté de leur laisser du code sans avoir de spécification fonctionnelle?

Vous seul pouvez y répondre par vous-même, mais prenez-le comme une expérience d'apprentissage pour la prochaine fois.

L'entreprise les a embauchés via Elance à un prix fixe. À ce stade, mon patron m'a laissé seul pour les gérer et faire le travail. J'ai créé une spécification détaillée de la chose complète qui devait être faite.

Donc, vous deux avez d' abord signé un contrat, puis ils vous ont laissé écrire une spécification, et ils ont accepté cette spécification pour faire partie de votre contrat? Si c'est comme ça, alors ce n'est pas votre faute, c'est la faute de votre entrepreneur. Vous auriez pu facilement rédiger une spécification leur donnant 3 mois de travail au lieu de 3 semaines - le tout pour le même prix.

C'était correct pour la plupart, mais il y avait des problèmes importants:

• ils ont codé en dur certaines des choses qui devaient être séparées dans un fichier de configuration
• il y avait plusieurs fichiers de configuration que je devais consolider en un
• ils ont écrit absolument AUCUNE documentation
• quelques autres changements mineurs

Ces choses faisaient-elles partie de vos spécifications? S'ils l'étaient, c'est leur faute. Sinon, c'est à vous. S'il n'était pas vraiment clair si ces choses sont contenues dans la spécification, c'est aussi votre faute, puisque vous avez écrit le document. Essayez d'écrire une meilleure spécification la prochaine fois.

Il y a quelque temps, j'ai fait une présentation sur la délocalisation. Cela s'appelait "Global Outsourcing, 10 conseils pour renforcer votre entreprise". Voici un résumé des 10 conseils (cela provient de jusqu'à 400 projets externalisés):

Un choix

1. Évitez les soumissionnaires les plus bas et les plus hauts . Ceci est tout simplement évident, vous ne voulez pas prendre de risques avec les soumissionnaires inférieurs et les soumissionnaires les plus élevés ont tendance à avoir moins de valeur (valeur / prix) que la médiane.

2. Vérifiez les cotes (ou références) . Je vérifie toujours les références et les notes.

3. Priorisez la motivation . À prix égal, je choisis l'offre qui était motivée. Par exemple, demander au soumissionnaire de parler de votre projet est un très bon signe.

Supervision

1. Protégez votre propriété intellectuelle . C'est l'une des plus grosses erreurs. Habituellement géré par la plateforme que vous utilisez (comme vworker ou elance).

2. Refusez les cadres personnalisés . Ou vous risquez d'y être lié, ou plus précisément au développeur qui l'a écrit;)

3. Imposer des normes . Lié à l'astuce précédente. L'utilisation de la norme augmente la valeur de votre code source car il est compréhensible par un plus grand nombre de développeurs.

4. Revoyez tôt, revoyez fréquemment . La plupart des problèmes peuvent être «ajustés» si vous passez en revue le code source après la première semaine ou le travail.

C. Stratégie

1. Testez les fournisseurs avec de petits projets . Avant de donner un gros projet à un fournisseur, je le teste avec un ou deux petits projets.

2. Acceptez plusieurs soumissionnaires pour réduire les risques . Pour les projets critiques, je sélectionne deux ou trois soumissionnaires puis je choisis la meilleure implémentation. Fonctionne mieux avec de petits projets (moins de 5000 $).

3. Assemblez les composants . Une autre stratégie consiste à sous-traiter les composants que vous assemblez plus tard. Un avantage est que vous pouvez facilement basculer entre les fournisseurs et qu'aucun n'a vraiment accès à l'ensemble (réduire les risques de propriété intellectuelle).

Je suis entièrement d'accord avec la réponse de maple_shaft.

Vous avez accepté le code et je suppose que vous avez écrit le chèque, puis revu le code, vous avez en quelque sorte tout fait à l'envers.

Pourquoi ai-je accepté de leur laisser du code sans avoir de spécification fonctionnelle?

Parce que vous ne l'avez pas écrit dans le contrat. Puisque vous vouliez que le travail soit fait, vous avez accepté leurs raisons, même si c'est la chose même qui vous a causé des ennuis.

Pourquoi ne m'étais-je pas assuré qu'ils avaient tout compris la première fois?

Vous auriez dû leur fournir un design qui, selon vous, aurait fonctionné. Ensuite, cela n'aurait pas vraiment d'importance s'ils ne comprenaient pas complètement. Je veux dire que vous ne les avez pas payés pour le faire, alors qui va le faire? Comment ce code va-t-il être maintenu sans aucune documentation ni spécification de conception? La réponse ne sera probablement pas .

Ils ont dit, puisque le prix était fixe, j'étais injuste en leur demandant d'apporter des modifications une fois qu'ils avaient terminé le code de travail.

Vous avez de la chance qu'ils aient fait les changements que vous vouliez. Ils auraient pu dire: bonne chance

Quelqu'un se retrouve-t-il dans la même position? Pensez-vous qu'il existe une meilleure façon de gérer les projets externalisés?

Bien sûr, d'autres personnes sont à votre place sinon, l'ensemble de l'industrie de la «sous-traitance» ne souffrirait pas, de nombreuses entreprises commencent à réaliser que devoir payer (ou attendre) pour le faire 3 et 4 fois est plus cher que de le faire correctement une fois .

Au moins en le faisant vous-même, vous pouvez vérifier quotidiennement l'état du projet. Si vous êtes derrière, vous pouvez faire des choses pour contrôler les dégâts, du moins en théorie.