L'externalisation du code est-elle plus coûteuse à long terme? Cela nuit-il à la qualité du code? [fermé]

Je connais une entreprise qui détient la propriété intellectuelle d'un produit logiciel décent et tire un excellent revenu de licences par an. Cependant, le directeur (non technique) se plaint du coût de maintenance de l'équipe de développement, car elle ronge considérablement les marges bénéficiaires, et envisage d'externaliser le développement de modules spécifiques vers d'autres pays qui facturent à un taux inférieur.

Personnellement, je ne pense pas que ce sera une solution plus rentable à long terme. Cela peut entraîner des pannes de communication en cas de problème, de plus, les spécifications devront être étanches, ce qui peut prendre plus de temps de toute façon. À mon avis, lorsque la communication en équipe est essentielle - ou existe-t-il un moyen efficace de faire en sorte que cela fonctionne?

Je suis sûr que quelqu'un a un exemple de ce fonctionnement, mais je ne l'ai pas vu.

J'ai travaillé dans une entreprise Fortune 500 pendant de nombreuses années où ils ont externalisé beaucoup de développement. Je n'ai pas un seul exemple dans ces années d'un projet externalisé qui coûte moins cher que si nous l'avions fait nous-mêmes (en interne).

Alors que leurs taux de programmation étaient inférieurs aux nôtres, nous avons passé 3 fois plus de temps à gérer l'équipe externalisée que nous le faisons pour les équipes internes. Cela s'ajoute au temps supplémentaire nécessaire pour que les exigences soient plus détaillées que celles requises par notre équipe interne et au temps supplémentaire nécessaire en QA, car le code n'a jamais été près d'être correct.

Vous pouvez l'avoir rapidement, vous pouvez l'avoir à moindre coût ou bien le faire. Vous ne pouvez pas avoir les trois, et je dirais que même deux sur trois peuvent être un tronçon.

Pour une société de logiciels, c'est tout simplement stupide. Le plus proche qu'ils pourraient obtenir d'une décision raisonnablement intelligente serait de déplacer l'entreprise vers un autre endroit qui a des talents moins chers.

Une société de logiciels externalisant son développement logiciel n'est plus une société de logiciels. Je dirais que tout gain gagné sera de courte durée, car vous créez votre propre concurrence. Une fois qu'ils réalisent qu'ils connaissent mieux le produit que vous, ils réalisent également qu'ils n'ont plus besoin de vous.

Ma seule expérience d'externalisation vers une entreprise dans un autre pays sera ma dernière. L'entreprise embauchée n'a pas terminé son travail à temps ou n'a même pas répondu aux spécifications à distance, ce qui nous a obligés à refaire tout le lot à l'interne.

Cependant, si vous pouvez trouver une entreprise fiable à laquelle vous pouvez faire confiance (c'est-à-dire que vous avez vu / entendu de bonnes choses à leur sujet de la part d'autres personnes), cela vaut peut-être la peine.

Le directeur veut remplacer certains de ses développeurs locaux expérimentés par des gens dans un pays lointain dont il n'est pas compétent pour juger l'expertise, qui n'ont aucune expérience du code et qui ne peuvent être directement supervisés ou encadrés par quiconque le sait le code.

J'ai vécu ça deux fois. Dans les deux cas, les entreprises étrangères bon marché n'ont pas réussi à livrer à temps avec une qualité adéquate. Lorsque les développeurs locaux ont appris que le travail se dirigeait vers l'étranger, ils ont trouvé d'autres emplois plutôt que d'attendre d'être licenciés. Alors que l'hémorragie se poursuivait, les horaires ont glissé, les bogues critiques n'ont pas été corrigés, les clients se sont fâchés et sont passés à la concurrence, et finalement les deux sociétés se sont repliées.

Il y avait aussi d'étranges problèmes de communication, d'attentes et de culture. Par exemple, une équipe étrangère ne vérifiait pas beaucoup de code ou ne répondait pas rapidement aux e-mails. Il s'est avéré que le responsable informatique local avait obtenu un bonus pour la réduction des coûts, il avait donc tout le bureau sur une connexion Internet à bas débit. Une autre fois, les testeurs QA du tiers-monde ont régulièrement mis plusieurs bogues extrêmement différents dans le même rapport de bogue; leur manager avait peur de manquer de numéros de bogues.

Certaines équipes dans des endroits bon marché sont très bien. D'après ce que j'entends, Red Hat semble avoir une équipe très compétente à Pékin. Mais ils avaient déjà des années d'expérience avec des personnes travaillant dans le monde entier via le télétravail avant de commencer à le faire, et les gens de Pékin sont des employés de Red Hat, pas une entreprise d'externalisation.

Oui, vous en avez pour votre argent.

D'après mon expérience, à moins que vos besoins de marché et de développement ne soient si simples, ils peuvent facilement être expliqués par e-mail à tout développeur avec une barrière linguistique possible, et si simple que même un développeur qui n'est pas vraiment investi dans l'entreprise peut toujours réussir à créer un produit de qualité, alors oui votre produit en souffrira .

J'ai travaillé dans une entreprise où nous avions une grande équipe de développement local, et notre produit a souffert simplement parce que l'équipe de direction a investi plus d'argent et d'efforts dans les ventes. Parce que tant d'efforts ont été consacrés aux ventes, il semblait que nous allions "bien" - mais pour gagner des revenus, nous devions continuer à verser de l'argent et des ressources dans le processus de vente.

Nous avions une équipe à distance mais nous les avons pleinement intégrés dans l'entreprise et ils ont participé au même niveau que nos équipes locales. C'est la seule façon dont cela peut fonctionner . J'étais le chef d'équipe local pour eux et nous nous rendions régulièrement sur place pour travailler avec eux. Nous leur avons donné des chemises et des vestes d'entreprise, tout comme les équipes locales. Après tout, cela nous a peut-être permis d'économiser 20 à 30%. Si vous créez un système qui tente de réduire les coûts de plus que cela, votre produit en souffrira en conséquence.

Si vous travaillez avec une équipe d'externalisation de qualité et que la direction est prête à communiquer et à appliquer les critères d'acceptation.

Le coût sera alors à peu près le même que celui d'un produit développé en interne.

Vous pouvez également obtenir la même qualité si vous avez de la chance.

Je suis peut-être un peu biaisé parce que mon entreprise conserve une équipe de développement interne et n'a externalisé aucun développement de produit. Je soupçonne que les expériences que nous avons eues avec des partenaires d'intégration qui ont externalisé le développement avaient quelque chose à voir avec cette décision.

D'après mon expérience, l'externalisation d'un projet n'est pas la meilleure solution lorsque vous essayez d'obtenir de meilleures marges.

Au travail, nous avions quelque chose comme ça et bien, comme d'autres l'ont également dit, nous avons fini par refaire le trou et maintenir ce qui était sur un serveur de production. Conclusion en la matière, cela a coûté deux fois plus cher.

Mon opinion à ce sujet est que si vous songez à essayer de faire une différence dans les développements de l'externalisation des marges, vous risquez de perdre votre investissement. Si vous y réfléchissez, le succès du produit est une question de fonctionnement comme prévu, donc si vous changez d'équipe de développement, les choses pourraient mal tourner.

Un logiciel open source bien planifié / fait pourrait être votre réponse, car il peut être très rentable et la maintenance est quelque peu déléguée à une communauté, mais il n'y a pas de recette pour réussir. Le meilleur conseil que je puisse donner est de recommander plusieurs discussions sur ce qu'est vraiment l'open source et ses manigances:

• "Comment démarrer un projet Open Source" par Jeremy Ruston (BT) http://vimeo.com/856110
• "L'open source est magique" par Chris DiBona (Google) http://www.youtube.com/watch?v=hmZyyBVbkOQ
• "Les moteurs de la communauté" par Jono Bacon (Canonical) http://www.youtube.com/watch?v=zKOrWubmzAY
• "Projets open source et personnes vénéneuses" Ben Collins-Sussman & Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZSFDm3UYkeE
• "Qu'y a-t-il pour moi? Les avantages du code Open Source" Ben Collins-Sussman & Brian Fitzpatric (Google) http://www.youtube.com/watch?v=ZtYJoatnHb8&feature=related

Et peut-être aussi:

• "Comment choisir un modèle d'entreprise" par Roan Lavery (FreeAgent) http://vimeo.com/5588154

L'open source, à mon avis, est de créer quelque chose de valeur et d'intérêt non seulement pour vous mais pour tous, le pouvoir de l'open source réside au sein des communautés.

De plus, si votre patron / entreprise hésite à ouvrir le logiciel, isolez simplement les spécificités de votre propre logique et savoir-faire métier. Alors, que feriez-vous:

1. Incuber un projet open source avec vos ressources
2. Développez une communauté
3. ???
4. Bénéfice =)

Ouais, je suis sérieux et "???" implique toutes les stratégies que vous souhaitez poursuivre après avoir recueilli suffisamment d'intérêt. Avec les outils d'aujourd'hui tels que Github et Twitter, vous pouvez passer le mot plus facilement, mais sachez que votre première impression devrait être suffisamment intéressante.

Si vous ne voulez pas réellement l'open source ( que vous devez comprendre comme un business model avant de l'implémenter, si vous voulez réussir ), vous pouvez toujours le lancer en tant que service, pour cela vérifiez la vidéo Carsonified, mais cela implique un tout beaucoup d'autres choses pour votre entreprise.

Au final, être open source ou le lancer en tant que service sont des moyens de pérenniser le projet sur le long terme.

Je ne me souviens pas de l'auteur de cette citation, mais elle frappe le clou.

"Des équipes faiblement couplées travaillant ensemble sur des composants étroitement couplés échouent. Inévitablement "

Externalisation = équipes faiblement couplées.

Essayer de réduire les coûts en répartissant géographiquement le travail sur les composants interdépendants échoue toujours.

D'un autre côté, d'après mon expérience, le déplacement d'une partie entière du portefeuille de logiciels peut fonctionner, ce qui signifie qu'il peut être développé de bonne qualité à des coûts réduits.