Voici sept des dangers de l'externalisation du développement de votre logiciel. Ils deviennent mortelles si votre carrière ou l'ensemble de l'entreprise dépend de la libération rapide de votre logiciel.
Danger # 1 - ignorant externalisation
Il peut sembler plus sûr d'ignorer l'externalisation et de s'en tenir à ce qui a fonctionné dans le passé--embaucher des programmeurs de l'employé et travailler avec eux directement pour obtenir votre logiciel mis au point. Il y a des situations où préoccupations au sujet de la propriété intellectuelle ou à la sécurité ce faire le seul choix. Mais si vous ne disposez pas de ces contraintes, puis vous gaspillez temps et argent en embauchant vos propres programmeurs.
Danger # 2 - embauche à l'équipe de mauvais
C'est une erreur commune à rechercher un fournisseur de sous-traitance seulement à vos proches du cercle d'amis et de connaissances. Tenant compte uniquement du colocataire votre ami frère à Bangalore, ou son cousin à Kiev, il est peu probable que vous fournir le vendeur de sous-traitance qui correspond le mieux à vos besoins de développement de logiciel.
Ne pas embaucher un vendeur d'externalisation qui va être distrait par le développement de leurs propres produits. Les meilleures équipes sont dédiés à offrir des services de développement de logiciels pour leurs clients et ont déjà plusieurs clients heureuses aux Etats-Unis.
Danger # 3 - ne pas protéger votre propriété intellectuelle
Les dangers de ne protéger votre propriété intellectuelle (pi) sont multipliés lorsque vous travaillez avec l'externalisation. Vous utilisez les trois types de protection de la propriété intellectuelle - physique, électronique et juridique ?
Assurez-vous que votre fournisseur de sous-traitance a une installation sécuritaire et utilise des ordinateurs sans support amovible pour réduire les risques d'accès non autorisé à votre IP. Utilisez des pare-feu, VPN et cryptage pour protéger votre propriété intellectuelle lorsqu'en transit sur Internet. Utilisez des protections juridiques appropriées y compris des accords écrits et nda qui est exécutoires dans les Etats-Unis. Un contrat clairement permet d'éviter les désaccords plus tard et vous empêche des frais de contentieux.
Danger # 4 - ne pas savoir ce que votre logiciel doit faire
Avoir de bonnes conditions et spécifications sont essentiels au développement de logiciels avec succès et surtout pour l'externalisation. Heureusement, externalisation peut réussie avec une spécification de haut niveau et une équipe de sous-traitance qui peut collaborer et communiquer avec vous afin de déterminer les détails.
Gestion de l'ingénierie maigre danger # 5-
Malheureusement, vous ne peut s'appuyer complètement sur une large équipe pour gérer le développement de votre logiciel. Ils feront de leur mieux pour respecter les engagements d'horaires et d'un haut niveau de qualité. Vous pouvez externaliser la programmation mais pas toute la responsabilité pour la création de grand logiciel.
Danger # 6 - méthodologie de développement logiciel médiocre
Comment allez-vous faire pour le processus de développement logiciel ? Vous créez un spec extraordinairement détaillé et puis microgérer ? Accumuler les fonctionnalités pour une version majeure prodigieuse unique ? Et vous assurez-vous que l'équipe offshore doit entasser toutes ces fonctionnalités dans le logiciel par mardi prochain ? Si oui, vous avez une méthodologie de développement logiciel médiocre.
Assumer « Aucune News est bonne nouvelle », si vous n'avez pas entendu parler de votre équipe offshore ? Avez-vous pas un logiciel standard communiqué de procédure ou source code système de contrôle ? Si oui, vous avez une méthodologie de développement logiciel médiocre.
Qualité de danger # 7 - un peu plus tard
QA est une partie essentielle du processus de développement logiciel. C'est également une préoccupation majeure lorsque vous confier aux programmeurs qui sont loin. Vous ne peut pas attendre de commencer essais jusqu'à ce que juste avant de vous libérer de votre logiciel et précipitez une version inacceptable en usage. Avoir vos utilisateurs à trouver les bugs, c'est une mauvaise stratégie.
No comments:
Post a Comment