Les délais en eux-mêmes ne sont pas une mauvaise chose, je dirais même, quelque part bien. Personnellement, mon travail s'avère plus productif si je me concentre mentalement sur un certain laps de temps, et lorsqu'un projet n'a pas de calendrier du tout, cela peut finalement le nuire. L'essentiel ici est de penser de manière réaliste et de maintenir un équilibre.
Le délai doit être justifié. «Parce que parce que» n'est pas une justification. Il s'agit d'une mauvaise pratique de fixation du temps qui affecte à la fois les entreprises et les développeurs. J'ai eu la chance que la plupart des entreprises pour lesquelles je travaillais n'aient pas l'habitude de fixer des délais. Mais il y a eu des exceptions. Je veux parler d'une situation de ce genre à titre d'exemple dans cet article.
Je travaillais dans une startup à l'époque; Notre équipe front-end était composée de trois personnes, et il y avait aussi une équipe back-end de la même taille. Nous travaillions sur une version mise à jour de l'application mobile et devions respecter la version avant un jour clairement marqué. Un problème: ce jour a été arbitrairement choisi soit par un simple réalisateur, soit par un technicien sans aucune raison pour une telle décision.
Eh bien, ce n'est pas entièrement sans justification - lors du choix d'un jour, la durée approximative du travail déclarée par les développeurs a été prise en compte. Si vous travaillez avec du code ou avec les personnes qui l'écrivent, vous comprenez probablement déjà quel est le problème. Les dates approximatives sont toujours approximatives, c'est-à-dire qu'elles sont très différentes de ce qui sort réellement. Et il ne s'agit pas de l'incompétence des développeurs, il est simplement incroyablement difficile d'estimer la quantité de travail sur un projet entier. Il y a beaucoup de choses qui peuvent changer les délais et qui sont impossibles à prévoir.
D'une manière ou d'une autre, notre estimation grossière est le résultat de deux jours de réunions: d'abord, un aperçu général des nouvelles fonctions, puis une analyse détaillée de chacune séparément, puis une analyse encore plus détaillée ... Enfin, pour chaque étape de travail , nous avons estimé le nombre d'heures, revérifié, corrélé avec la conception UX et UI, ils ont tout mis ensemble, jeté quelques heures en plus - et c'était la date limite pour le travail.
Vous pensez probablement maintenant: eh bien, puisque leurs conceptions UX et UI sont déjà prêtes et que encore plus d'heures sont réservées, alors, probablement, tout devrait bien se passer? Dans la plupart des cas, les conditions sont pires lors de la fixation des dates. Eh bien, en général, non. Rien ne s'est bien passé.
La durée du travail a été fixée à trois à quatre semaines - pas trop de temps si nous parlons de la sortie d'un nouveau produit avec une petite équipe. Bien sûr, après les deux premières semaines, nous étions déjà en retard. Non pas parce qu'ils ont travaillé lentement ou ont passé quelques heures sur le projet, mais parce que tout va toujours mal.
Le backend se penchait sur la mise en œuvre de l'API pour l'application, quand il s'est soudainement avéré que le système ne pouvait pas interagir normalement avec un simple module complémentaire, ce qui signifie qu'il était nécessaire de réécrire le fragment d'API déjà préparé en tenant compte de cette circonstance. Compte. Il a fallu deux jours imprévus pour finaliser le point de terminaison.
En raison de ce petit changement, l'API a commencé à fonctionner un peu différemment de ce qu'il était prévu au stade de la discussion, ce qui a conduit à la nécessité de réécrire des parties individuelles de l'application - un travail de plusieurs heures. Une telle réécriture est courante dans les applications mobiles de toutes tailles et ne devrait surprendre personne. Mais nous avons un délai serré. Et maintenant, nous ne pouvons pas nous adapter.
Alors que peux-tu faire? Le lendemain, on nous a dit que nous devions travailler quatre heures supplémentaires pour reprendre de l'avance. Quatre heures en plus d'une journée de travail typique de huit heures. Eh bien, oui, nous avons été nourris, bien sûr, mais il n'y a rien d'utile pour le cerveau dans de tels quarts de douze heures et ne peut pas l'être. Néanmoins, nous avons réussi à nous rattraper et à suivre le calendrier.
Une semaine plus tard, l'application a été publiée. Nous étions heureux, quelqu'un a apporté des petits gâteaux pour célébrer, et cinq minutes plus tard, tout le monde était déjà assis devant les moniteurs et prétendait que rien ne s'était passé.
Il n'y avait rien d'aussi important dans la mise à jour qui motiverait la nécessité d'une sortie à cette date particulière et pas un jour plus tard. Aucun des utilisateurs ne savait qu'une nouvelle version était en cours de préparation, personne (ni les clients ni les investisseurs) n'a fait de plans basés sur une date. Oui, les fonctionnalités sont utiles, mais est-ce que quelqu'un se sentirait plus mal si elles étaient publiées un jour plus tard? Cela affecterait-il n'importe qui?
Mais les développeurs ont affecté. Ici et là, les gens se répandaient leur mécontentement; la relation entre l'équipe et la direction était clairement gâtée. Et ce n'est pas un cas isolé, cela s'est produit souvent pendant que je travaillais là-bas - avec une fréquence d'environ une fois tous les plusieurs mois.
Et quelle est la conclusion de tout cela? Abandonner complètement à tout moment? Eh bien, bien sûr que non. Comme mentionné au début de l'article, les délais sont en fait utiles, et je trouve moi-même plus facile de travailler avec eux. Mais ils doivent être considérés comme des lignes directrices et non comme des engagements rigides. Si le produit sort quelques jours plus tard, il ne devrait pas être considéré comme la fin du monde. Quel est l'intérêt de mettre une pression inutile sur les développeurs? Ou pensez-vous que la qualité du code ne souffre pas de telles marches?
Lorsque nous avons travaillé des heures supplémentaires après une journée de travail tard dans la soirée sous la bannière de la force majeure, l'ambiance générale était: "Donc, nous devons terminer le plus tôt possible." Souvent, toutes sortes de solutions de béquilles ont été introduites qui fonctionneraient pendant un certain temps, puis nécessiteraient une refactorisation. Dans certains cas, le refactoring correspondant a été immédiatement programmé, dans d'autres, il a été oublié en toute sécurité. Et il est arrivé que les développeurs eux-mêmes ne se rendaient pas vraiment compte qu'ils faisaient quelque chose de béquille, car ils étaient fatigués et voulaient rentrer chez eux.
Quand il s'agit de refactoring (d'où cela vient), il s'agit probablement plus d'une ressource que de la force majeure elle-même. Des bogues ont commencé à apparaître dans des morceaux de code écrits à la hâte. Depuis que l'application était déjà sortie, tout le monde était particulièrement nerveux.
D'après mes estimations (je n'ai pas collecté de statistiques, donc je ne peux pas me porter garant), ce traitement n'a été utile qu'à court terme. Eh bien, oui, nous avons publié l'application à temps. Et la prochaine version devait déjà être retardée, car beaucoup de choses étaient en cours de réécriture. Les développeurs étaient mécontents (et, vous l'avez deviné, ils quittaient activement), l'atmosphère dans l'équipe est devenue tendue. Et nous ne prenons toujours pas en compte les conséquences des bugs rencontrés par les utilisateurs après la sortie.
Comment en avez-vous besoin?
Si vous voulez que tout soit fait efficacement, n'ayez pas de fièvre, écoutez les développeurs et assurez-vous de suivre les progrès. Si l'équipe ne rentre pas et qu'il n'y a aucune raison d'urgence, déplacez la date limite! Pas arbitrairement, mais pour le moment, cela ne suffit pas au stade actuel. Encouragez les développeurs à communiquer les causes potentielles des retards et des risques. Si quelqu'un voit quelque chose qui ne rentre manifestement pas dans le calendrier général, cela vaut la peine d'attirer l'attention de la personne qui planifie, afin qu'elle ait la possibilité de corriger les dates estimées.
Avez-vous tout fait à l'avance? Eh bien, dans une telle situation, tout le monde ne fait que gagner. Et les tests peuvent être effectués correctement et donner aux développeurs la possibilité d'améliorer quelque chose dans la base de code. Si vous êtes développeur ou si vous communiquez avec des développeurs pour le travail, vous le savez vous-même: il y a toujours des endroits dans le code que vous aimeriez resserrer. Parfois, cela ne prend qu'une heure et parfois plusieurs jours. Il vaut mieux ne pas perdre de temps à rendre le code meilleur et plus précis - comme nous pouvons tous le confirmer, il y a suffisamment de lacunes dans les applications qu'aucun des utilisateurs n'appréciera.