Le contrat à l'extérieur ne marche pas forcément, mais tout internaliser a aussi ses propres problèmes, au moins quand la taille du projet est trop petite (ou ses finances) pour avoir plus d'un seul développeur. Avec un prestataire extérieur, si tu as la chance de trouver des gens compétents (oui, ça existe), tu peux espérer avoir plusieurs personnes qui travaillent sur le projet à temps partiel, ou au moins un seul développeur qui a beaucoup d'expérience de travail en équipe.
(Bien) travailler à plusieurs et (bien) travailler tout seul c'est très différent, le premier est un peu moins efficace sur le court terme (coûts de communication, conventions à adopter, mécompréhensions etc.), mais il incite beaucoup plus à avoir de la documentation écrite, des processus de développement/bugfix/release/etc. explicités, et se prête donc plus naturellement à un passage de bâton (partiel ou total) à d'autres développeurs ensuite.
Quand on travaille tout seul (même quand on est compétent et qu'on fait attention), c'est facile de s'enfermer sans s'en rendre compte dans un projet où on a tout en tête mais peu de choses écrites pour d'autres, dans des choix d'architectures non-standards qui rendent le projet plus difficile à comprendre pour d'autres, et au final avec quelque chose qui, si on doit se faire remplacer pour une raison quelconque, est beaucoup plus difficile à prendre en main pour les suivants.
Idéalement je pense que si j'étais demandeur d'une prestation informatique, j'essaierais de trouver un compromis entre "la boîte de prestation opaque" et "le développeur tout seul en interne". Soit une petite boîte avec un petit nombre de personnes en local avec qui j'ai de bons rapports, soit essayer de gérer les responsabilités en interne pour avoir plus d'une personne sur le backend (par exemple, au lieu d'avoir un développeur et un webmaster, chercher deux personnes polyvalentes qui se partagent les tâches sur les deux fronts).
[^] # Re: Vécu
Posté par gasche . En réponse au journal Optimisez votre code !. Évalué à 6.
Le contrat à l'extérieur ne marche pas forcément, mais tout internaliser a aussi ses propres problèmes, au moins quand la taille du projet est trop petite (ou ses finances) pour avoir plus d'un seul développeur. Avec un prestataire extérieur, si tu as la chance de trouver des gens compétents (oui, ça existe), tu peux espérer avoir plusieurs personnes qui travaillent sur le projet à temps partiel, ou au moins un seul développeur qui a beaucoup d'expérience de travail en équipe.
(Bien) travailler à plusieurs et (bien) travailler tout seul c'est très différent, le premier est un peu moins efficace sur le court terme (coûts de communication, conventions à adopter, mécompréhensions etc.), mais il incite beaucoup plus à avoir de la documentation écrite, des processus de développement/bugfix/release/etc. explicités, et se prête donc plus naturellement à un passage de bâton (partiel ou total) à d'autres développeurs ensuite.
Quand on travaille tout seul (même quand on est compétent et qu'on fait attention), c'est facile de s'enfermer sans s'en rendre compte dans un projet où on a tout en tête mais peu de choses écrites pour d'autres, dans des choix d'architectures non-standards qui rendent le projet plus difficile à comprendre pour d'autres, et au final avec quelque chose qui, si on doit se faire remplacer pour une raison quelconque, est beaucoup plus difficile à prendre en main pour les suivants.
Idéalement je pense que si j'étais demandeur d'une prestation informatique, j'essaierais de trouver un compromis entre "la boîte de prestation opaque" et "le développeur tout seul en interne". Soit une petite boîte avec un petit nombre de personnes en local avec qui j'ai de bons rapports, soit essayer de gérer les responsabilités en interne pour avoir plus d'une personne sur le backend (par exemple, au lieu d'avoir un développeur et un webmaster, chercher deux personnes polyvalentes qui se partagent les tâches sur les deux fronts).