Comment tenir tête lorsque des collègues négligent le processus?

Le problème auquel je suis confronté:

1. Les membres de mon équipe commencent à travailler sur des projets sans que les documents fonctionnels / techniques soient prêts - même si le processus de notre entreprise exige qu'ils soient là avant de commencer.
2. Les membres de mon équipe acceptent des solutions bon marché et non structurées et implémenteront de très mauvais hacks dans les logiciels sans réfléchir à deux fois lorsque la direction du projet note qu'ils ont «un temps limité».
3. Les membres de mon équipe commencent à travailler sur des projets qui fonctionnent avec un projet inachevé d'une autre équipe - qui n'a pas été testé et n'est pas terminé. (provoquant beaucoup de travail supplémentaire).
4. Les améliorations et les phases entières du logiciel ne sont pas correctement planifiées et entraînent souvent un front-end / la conception n'est pas terminée lorsque le développeur back-end doit commencer à travailler.

Ces problèmes ont été débattus à plusieurs reprises depuis que j'ai commencé à travailler ici. Tout le monde était d'accord et l'essentiel était que nous devons appliquer le processus, cela signifie que le développeur principal ne démarrera pas tant que tout ne sera pas pris en charge.

Ces problèmes continuent de se produire - et je suis vraiment démotivé au point que je suis vraiment ennuyé par le travail lui-même et certains de mes collègues.

Les membres de mon équipe se plaignent beaucoup - mais seulement l'un envers l'autre. They keep on going - whatever the situation is. Le résultat?

1. Je deviens précaire, c'est peut-être moi?
2. Est-ce juste ainsi que les choses sont censées se passer?

Ma question? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

C'est sans ressembler à un développeur ennuyeux qui cherche tout le temps quelque chose à chier.

Tout le monde était-il vraiment d' accord?

J'ai eu une fois une situation où nous voulions améliorer les processus. Nous avons proposé un processus différent et tout le monde semblait d'accord.

Mais ensuite, chaque fois que je voulais suivre ce processus, il y avait une exception, en raison de «questions plus importantes», qui semblait toujours raisonnable à première vue. Donc, en effet, le processus n'a jamais été suivi de facto, mais tout le monde pensait «en principe, nous suivons le processus».

Le problème était: si vous proposez une amélioration, il n'y a personne qui n'est pas d'accord (qui n'aime pas les améliorations?). Mais si vous présentez les coûts, il y a généralement beaucoup de désaccords. Et perdre la façon pratique de faire les choses est un coût énorme pour la plupart des gens.

Pour démontrer cela, j'ai formulé la question différemment: `` Veuillez hiérarchiser toutes les choses que je suis censé faire (implémentation de fonctionnalités, suppression de bogues, suivi du processus amélioré, nettoyage du bureau, arrivée à l'heure) ''.

Après le processus, je me suis retrouvé derrière le nettoyage du bureau et je n'étais pas en retard de 5 minutes. Donc, fondamentalement, ils ont accepté quelque chose de complètement différent de ce que j'ai proposé.

Le problème peut être qu'ils ne veulent pas payer les coûts de la qualité. Cela peut les amener à rationaliser votre critique comme une plainte, mais d'après mon expérience, ce n'est pas le cas. La dette technique n'est peut-être pas si visible, et il est facile de l'attribuer aux circonstances, mais finalement, la réalité s'ensuit.

Avec un peu de chance, jusque-là, ils l'ont réalisé, ou vous avez changé d'emploi.

C'est peut-être toi

Vous semblez privilégier une méthode de codage très structurée et organisée, vos coéquipiers semblent avoir une approche plus "concrète". Maintenant, vous mentionnez que cela conduit à beaucoup de «temps perdu», alors peut-être qu'une certaine structure est en ordre et il n'y a aucune excuse pour un travail bâclé. Cependant, les projets logiciels ont tendance à être fluides et appliquer trop de structure entraînera également beaucoup de frais généraux organisationnels.

Vous devriez peut-être tous vous rencontrer au milieu et essayer une approche plus agile et interactive, mais structurée.

Qui est responsable de ces personnes? Quelqu'un les a embauchés et quelqu'un peut les licencier / les tenir responsables.

"Mon entreprise exige ..." n'a pas de sens sans application.

Vous ne pouvez pas faire des demandes de temps qui ne permettent pas le processus de production.

On dirait que ce manque de contrôle et des attentes irréalistes sont les raisons de la mauvaise qualité.

Vous pouvez soit partir, devenir le développeur principal, ne rien faire ou commencer à travailler avec ceux qui ressentent ce que vous faites. Assurez-vous que tout le monde sait que vous allez suivre les procédures correctes jusqu'à ce que quelqu'un trouve un meilleur moyen et les change. Cela ressemble à "The Cider House Rules".

Il semble que vous ne vouliez pas que vos collègues suivent un processus complètement différent, vous voulez juste qu'ils prennent des décisions différentes. Bien sûr, il existe des règles (directives?) Sur ce qu'ils doivent faire, et ils les ignorent. Mais le problème que vous décrivez est qu'ils doivent prendre une décision (commencer à travailler sur le projet ou rejeter une spécification) et ils décident de continuer. Cette décision ne changera pas si vous continuez à leur rappeler les règles; ils ne se soucient pas autant des règles que vous . Ils veulent se sentir utiles, et dire non ne les fait pas se sentir utiles .

Si vous voulez que leur comportement change, alors leur rappeler continuellement les règles n'est probablement pas très efficace; il est plus susceptible de les conduire à vous ignorer. Essayez de trouver un moyen de changer le processus pour les rendre plus utiles tout en suivant le processus. Pouvez-vous implémenter une sorte de révision de code, en vérifiant le code de chacun et en apprenant les uns des autres pour empêcher les hacks d'atteindre le code de production? Pouvez-vous changer la façon dont les spécifications (docs / interfaces externes / front-end) sont traitées, d'une décision finie / non terminée en noir et blanc à un processus plus coopératif, où vers la fin de la spécification un développeur est invité à aider à terminer? (Et, vous devez accepter que les exigences vont changer)

Surtout ce n'est pas vous, ce n'est pas eux, c'est le processus. Si vous (et votre PM) pouvez trouver un moyen d'organiser des choses où les gens n'ont pas tellement à aller contre leur personnage, le processus sera suivi beaucoup plus rapidement.

C'est à peu près le moment où j'arriverais à une séance à huis clos avec mon chef d'équipe. J'espère que vous avez une relation de travail suffisamment bonne avec le responsable pour que vous puissiez la rendre très informelle.

Le but de la réunion est de comprendre pourquoi l'équipe fait les choses comme elle les fait. Si tout le monde s'est réuni, a hoché la tête, a souri et a accepté un nouveau processus, alors pourquoi ne change-t-il toujours pas? Il y a de fortes chances que cela soit beaucoup plus profond que la simple négligence ou l'incompétence. Il est probable que des conducteurs au travail ne soient pas visibles à l'œil nu.

Commencez la réunion en supposant que vos collègues, s'ils le pouvaient, suivraient un processus qui conduirait à moins de panique, moins de dettes techniques et une meilleure qualité des produits - après tout, qui ne veut pas cela? Alors, quelle est la force invisible?

Il semble qu'il y ait beaucoup d'implémentation / intégration avant le travail initial de conception et de prototype d'interface utilisateur. L'entreprise manque-t-elle de personnes capables de faire ce travail initial? Vous pourriez peut-être faire du bénévolat. Y a-t-il un problème pour parvenir à un consensus avec les parties prenantes? Peut-être que votre équipe peut trouver une nouvelle façon de communiquer avec eux ou adopter une nouvelle approche pour documenter les hypothèses.

Si vous commencez en tête-à-tête où vous demandez à votre responsable pourquoi, vous pouvez ouvrir la porte à une discussion qui évite la défensive et se concentre sur les problèmes et les solutions.

Une autre astuce pourrait être de demander si vous pouvez lancer une nouvelle façon de faire les choses. Obtenez le soutien de votre chef d'équipe pour forcer un peu le problème et vous laisser adopter l'approche que vous préconisez. Mais si vous vous avérez plus productif et sans stress, vous fournissez un bon argument pour changer la façon de faire et vous êtes susceptible de gagner des avocats.