Comment convaincre l'équipe d'autres parties du développement logiciel sont importantes?

Question

Parfois, quand je présente une partie du processus de développement de logiciels à certaines personnes, par exemple le superviseur ou le gestionnaire qu'ils n'ont pas d'expérience dire

1. tests unitaires automatisés et des tests d'intégration par rapport aux leurs tests fonctionnels manuel . Utilisation de générateurs de code et de scripts pour les tâches répétitives.

J'ai parfois rencontré une résistance. Certaines des raisons sont les suivantes:

1. Ils disent que c'est comme ça que nous faisons les choses ici. Notre système fonctionne et il n'y a pas besoin d'ajouter dans notre processus.
2. Ils sont occupés à être occupés. Ils disent que leur travail consiste à nous trouver des projets et que notre travail consiste à les livrer à leur satisfaction. Ils sont satisfaits quand il s'agit d'un système manuel, répétitif mais à temps.
3. Ils sont très conservateurs sur les générateurs de code. Je leur ai dit qu'il fallait beaucoup de temps pour que le premier projet utilise cette méthode et le temps nécessaire pour former mes coéquipiers, car cette approche est relativement nouvelle pour eux. Les frais généraux pour le premier projet à eux éclipse le bénéfice à long terme, mais j'ai expliqué la commodité pour nous les développeurs, mais ils sont toujours coincés à faire les choses à l'ancienne.

Quelle serait votre stratégie pour cela?

Answer 1

Attendez qu'un problème apparaisse puis faites déplacer.

Answer 2

"Vous pouvez obtenir beaucoup plus loin avec un sourire et une arme à feu que vous pouvez avec juste un sourire."
- Al Capone

Just kidding, mais ce la première chose qui traverse mon esprit :)

Le pistolet est une métaphore (duh), comme pour un bug que quelqu'un a passé des jours déterminer que, avec un bon processus, il passe bien d'une manière plus amusante.

Answer 3

Je pense que le seul moyen de convaincre quelqu'un de quelque chose est de révéler les avantages qu'il procure.

Answer 4

Il est plus facile de demander pardon que d'obtenir la permission.

Il n'y a pas de mesure objective du style de retour sur investissement pour «améliorer» un processus de développement logiciel. Le développement de logiciels est intrinsèquement difficile - c'est la capture de connaissances - il doit y avoir des inconnues. Si tout était connu, vous auriez déjà le logiciel en main. Par conséquent, vous ne pouvez jamais convaincre un gestionnaire de quoi que ce soit d'emblée.

Vous pouvez seulement démontrer que vous êtes capable de faire quelque chose de mieux, de moins cher ou plus rapidement. Lorsqu'ils vous demandent quel est le secret de votre productivité, vous pouvez leur montrer vos outils, votre méthode ou votre approche. Jusqu'à ce qu'ils demandent, vous n'avez pas vraiment assez de preuves pour changer l'esprit de quelqu'un. Quand ils demandent enfin, alors vous n'avez pas besoin de changer d'avis, vous devez leur montrer votre solution.Comme ils ne veulent pas faire dérailler leur programme «tout faire à la main» pour investir dans vos outils, vous devez construire vos outils par étapes, un projet à la fois.

Answer 5

Vous devez être un vendeur, à la fin de la journée. Vous devez dire aux gens pourquoi vos propositions vont faire leurs vies plus facile.

Si vous pouvez sauvegarder vos revendications avec une sorte de données de temps/temps économisés, vous êtes sur un gagnant. Une autre chose est de vous faire une réputation progressivement, en acceptant que les changements soient mis en œuvre par étapes. Implémentez un changement simple sur une petite partie du projet et prouvez que cela a fait une différence pour eux. Puis rouler un peu plus, et passer à la prochaine chose comme les tests unitaires ou la génération de code. Avec le temps ça va s'arranger. Je ne crois pas que vous ne pouvez pas forcer les gens à lire des livres, ils vont les mettre à l'écart et penser que vous êtes odieux. La meilleure chose est d'obtenir de petits résultats, et d'utiliser ceux-ci comme des tremplins pour être autorisé à viser des objectifs plus élevés que les gens réalisent que peut-être il ya de meilleures façons de faire les choses après tout. Si vous êtes vraiment passionné, vous pouvez toujours investir un peu de votre temps, et préparer une courte démo (30 mins tops) qui leur montre à quelle vitesse vous pouvez créer une petite application sans code gen, puis la même application avec un couple de bits code-genned. La preuve du pudding est dans l'alimentation.