Outsourcing Vs codage Construire une équipe interne

Il ya quelques années j'étais à Bali pour un camp d'entraînement de fitness. TV tout en regardant un soir tard, je suis tombé sur un documentaire sur la construction d'un système de métro à Amsterdam. Je me souviens très bien l'un des ingénieurs interviewés en disant "c'est impossible, mais nous allons le faire quand même". Quand je pense à certains aspects de l'externalisation, je me souviens de cette déclaration, car il ya certainement quelques défis difficiles à obtenir sous-traitance pour le travail, mais je crois que cela peut être fait.

Je dois commencer par dire que en aucun cas je suis une autorité en matière de travail avec des programmeurs sous-traitance, en fait, je ne l'ai fait pendant quelques mois au total. Ma brève expérience de l'externalisation a révélé à la fois les aspects positifs et négatifs de l'approche, mais plus important encore, il m'a ouvert l'esprit sur les possibilités. J'ai remarqué que certaines personnes semblent être contre l'externalisation pour des raisons personnelles, et c'est sûrement leur prérogative.

À certains égards, cet article est une réplique à une pièce sur l'externalisation J'ai lu récemment. L'article en question est par Michael Bean et est intitulé Les pièges de l'externalisation de programmation. Il est l'une des œuvres sélectionnées se sont réunis dans le livre Le Meilleur Logiciel Écriture I - & choisies et apportées par Joel Spolsky.

Suis-je attaquer ce que l'auteur avait à dire dans l'article? Pas du tout, c'est très bien écrit et plein d'informations perspicaces. Une certaine connaissance de ce que l'article est est sur le point nécessaire pour comprendre mon point de vue sur la question. Je ne veux pas ré-écrire l'article, je me contenterai donc de couvrir les principaux points très rapidement.

Michael Bean discute les idées suivantes:

Il ya eu une ruée vers ces dernières années pour les entreprises des États-Unis d'envoyer des tâches de développement en Inde, en Chine, et Europe de l'Est.

Développement de logiciels de conception est non pas la fabrication. Par conséquent, en vertu de sa nature créatrice, ce n'est pas quelque chose qui doit être envoyé off-shore.

Les gens paient pour «valeur ajoutée» des services ou produits. Si tous les aspects de l'offre d'une entreprise (de la production au service du client) sont sous-traités, ils ne peuvent pas donner aux clients ce qu'ils désirent vraiment.

Externalisation service à la clientèle qui revient à dire que vous n'êtes pas intéressés à entendre ce que vous avez à dire clientèle.

La motivation derrière la création d'un massif de travail informatique vigueur outre-mer va comme ceci: «Si Nike peut le faire avec des chaussures, nous pouvons le faire avec le code".

Le "mais vous enlèvent les emplois des Américains" argument est fallacieux, au mieux, les gens en Inde ou partout où ont tout autant le droit de travailler comme tout le monde. Nous vivons dans une économie mondiale, après tout.

Quand une entreprise externalise la tâche en matière d'innovation, ils donner leur avantage concurrentiel. Au fil du temps, une entreprise vont perdre leur capacité à innover.

Innovation souffre quand les gens sont répartis dans différents pays, car ils ne peuvent pas communiquer efficacement.

les programmeurs ne sont pas externalisés dans le long terme. Ils ont tendance à disparaître après la fin du projet, emportant avec eux toute connaissances spécialisées qu'ils ont acquises.

Entièrement sous-traitance tous vos développement est une mauvaise idée (à savoir la conception et de codage du logiciel).

La différence entre les Etats-Unis et les fuseaux horaires indienne signifie qu'il n'y a pas de chevauchement entre leurs heures de travail. Cela rend la communication encore plus difficile.

Création de logiciel est plus sur la conception, puis ensemble. La capacité de conception est également considérée comme une compétence rare.

C'est essentiellement le point crucial de l'article Michael Bean. J'ai fait de mon mieux pour garder ses idées fondamentales, mais évidemment il ya le risque de mauvaise interprétation.

Je suis d'accord qu'il n'est pas souhaitable de tout sous-traiter (par exemple la conception et de codage). Dans l'article de Michael Bean, il ne va pas vraiment dans ce qu'il entend par design. Pour moi, la conception, la spécification fonctionnelle (ie comment le logiciel fonctionne du point de vue utilisateur).

Aurais-je faire confiance à un donneur d'ordre pour écrire une spécification fonctionnelle? Non, ce n'est pas conçue comme une attaque sur la compétence des programmeurs d'outre-mer, c'est tout simplement déraisonnable de penser que vous pourriez obtenir une spécification précise à distance sans rencontrer un visage client-à-face. Je ferais confiance aux programmeurs sous-traitance pour créer des logiciels basés sur un de mes specs? Oui, certainement.

L'autre aspect problématique de l'article de Michael Bean est qu'il ne mentionne pas explicitement une division entre shrink-développement de logiciels emballés et des projets de logiciels personnalisés. Ceci est une considération majeure. Si vous essayez de réduire au minimum les coûts de production, les programmeurs, puis sous-traitance sont très bien adaptés au développement personnalisé (et oui, la maintenance est un gros problème, mais c'est un gros problème avec les compagnies normal de toute façon). Réduire les coûts opérationnels peuvent être une préoccupation très réelle si votre entreprise a des investisseurs ou de capital-risque.

Il existe des stratégies pour avoir sous-traitance le travail des programmeurs sur le logiciel shrink-enveloppé, par exemple, certaines entreprises indiennes offrent des équipes dédiées qui fonctionnent uniquement sur votre logiciel, ils viennent même avec leur chef de projet dédié.

C'est vrai, vous êtes la communication en prendra un coup, cela est inévitable. Mais vous n'avez pas quelque chose pour rien. Si vous voulez produire des logiciels pour 50% du coût normal, puis être prêt à mettre en place avec une certaine gêne.

Heureusement, en Australie, nous ne souffrent pas des mêmes problèmes de fuseau horaire de nos amis américains ont à supporter. Dans mon expérience avec les programmeurs indiens, je trouve qu'ils ont commencé à s'activer à environ 12 heures, c'est très bien pour autant que je suis concerné.

Outils de communication et de gestion de projet sont très importants pour travailler avec succès avec les programmeurs sous-traitance. MSN ou autre logiciel de messagerie instantanée est la clé. Je me souviens avoir trois logiciels différents GI en cours d'exécution sur mon ordinateur à un moment donné, afin de rester en contact avec tout le monde sur mes projets. Un outil de gestion de projet comme Basecamp est également très utile. Un bug tracking system est une autre bonne idée, et un calendrier en ligne qui peuvent être consultés par tout le monde va rendre la vie beaucoup plus facile.

C'est peut-être un peu simpliste, mais il semble se résumer à ceci: l'externalisation des résultats dans le développement de logiciels moins chers, mais les équipes en interne produire de meilleurs logiciels de qualité.

cet article est traduisé en francais
l'origine de cet article (en anglai): http://ezinearticles.com/?Outsourcing-Coding-Vs-Building-an-In-House-Team&id=1843685