Tout le monde sait ce qu'est un délai, mais tout le monde ne sait pas le définir correctement. Pour parler de briser la date limite du projet, vous pouvez choisir de nombreuses belles métaphores. Yubitsume en est un. Il s'agit d'une coupe rituelle de la phalange des doigts au Japon. En particulier, ils recourent à yubitsume pour s'excuser auprès du chef ou du propriétaire pour une erreur. Si vous avez regardé des films sur les yakuzas, vous avez compris de quoi il s'agissait.
Le rituel venait de la communauté des joueurs de Bakuto et était considéré comme un substitut adéquat au paiement de la dette. Le débiteur a permis à la petite phalange d'être consommée, ce qui a compliqué sa vie future: il ne pouvait plus tenir son épée en sécurité et au combat était plus dépendant de ses compagnons, y compris le propriétaire.
Peu importe l'heure et le lieu où vous vivez et ce que vous faites - les relations d'équipe doivent être solides et les délais doivent être respectés. Les gestionnaires de
Live Typing Studio, bien qu'ils ne se coupent pas les doigts, sont toujours responsables du mot donné au client. L'expérience m'a permis de formuler six erreurs, ce qui fait que vous risquez certainement de perdre le travail à temps et que faire pour respecter les délais. Ayant cessé de faire ces erreurs, vous remarquerez comment la qualité de vos projets augmentera, combien de temps sera libéré pour le repos et comment les relations entre les membres de l'équipe et avec le client s'amélioreront.
Vous ne savez pas avec qui vous travaillez
Chaque membre de l'équipe de développement est comme un personnage dans un jeu de rôle: quelqu'un a une grande capacité à s'impliquer dans le projet, mais manque de persévérance et de concentration, et quelqu'un apprécie le temps que prendra la tâche. À partir de ce dernier, des timlids sont obtenus, qui sont généralement bons en tout.
Avec tout cela, si différent, les gens doivent travailler dans un style différent. Certains ont besoin d'incitation, que ce soit un contrôle strict ou des mots encourageants; d'autres s'attendent à ce que vous leur parliez des antécédents du client, de ses idéaux et de sa vision de la vie, de ce qu'il attend de l'équipe et de la façon dont il en dépend; d'autres encore fonctionnent. Si vous ne tenez pas compte du caractère d'un membre de votre équipe, il sera laissé à lui-même et à ses pires habitudes, et le délai sera probablement perturbé.
L'expérience d'un spécialiste n'est pas moins importante. Répartissez les tâches en fonction de leurs capacités et de leur coefficient de productivité, sinon le mois de juin ou du milieu échouera à une tâche qu’elles ne peuvent pas faire initialement.
Vous n'avez pas compris les objectifs du projet
Le travail sur un site Web ou une application commence par
la phase de conception . Il s'agit d'une étape sérieuse: il reste à voir qui utilisera le produit, quels objectifs il est censé atteindre et comment il rapportera de l'argent à son propriétaire. Les résultats de cette étape sont enregistrés dans la tâche fonctionnelle, et la
tâche fonctionnelle sert de base à la formulation de tâches pour les concepteurs et les développeurs.
La fonctionnalité de l'application doit avoir un objectif clair. Si le gestionnaire ne l'a pas compris, cela signifie que la conception est mal faite et que la tâche ne sera pas définie correctement pour l'entrepreneur. Le résultat est imprévisible, car le développeur peut commencer à réfléchir au rôle de la fonctionnalité, à la gonfler, et finalement à passer beaucoup de temps à écrire et réécrire du code.
Pour éviter cela, nous effectuons une revue de conception: toute l'équipe examine attentivement et de manière itérative le prototype ou la conception qui en résulte et trouve autant d'espaces, d'erreurs et d'écrans manquants que possible. L'exécution de haute qualité d'une revue de conception affecte considérablement le timing.
Plus la documentation est précise et complète, moins les développeurs auront de malentendus et de bugs pendant le développement, ce qui garantit le respect des délais.
Les membres de votre équipe ont incorrectement évalué les tâches
Une note incorrecte est la cause de la plupart des délais brûlés. Chaque cas d'une évaluation incorrecte doit être discuté rétrospectivement, trouver les raisons et développer des tactiques pour y remédier à l'avenir.
Certains juniors et intermédiaires ont tendance à surestimer leurs forces. Avec l'expérience, un bon manager commence à comprendre cela et fait des ajustements: par exemple, après avoir entendu une estimation de 10 heures, il la multiplie par 2 et obtient un résultat qui s'avère plus tard plus vrai.
Un développeur senior n'est pas celui qui est plus âgé que les autres, mais qui sait que cela peut prendre plus de temps pour terminer une tâche que prévu, et l'admet hardiment à lui-même et au manager. Un développeur senior est conscient des risques et vous devriez le faire. L'erreur suivante est consacrée à cela.
Vous et votre client n'ĂŞtes pas conscients des risques
Les risques sont tout ce que vous n'aviez pas prévu et qui ralentiront le travail sur les tâches. Ils sont externes et internes. La déconnexion d'Internet, un ouragan ou une inondation, un changement dans les exigences d'un produit - ce sont des raisons externes que les artistes ne peuvent influencer en aucune façon. Une longue recherche de solution à un problème, une dépression nerveuse chez le développeur - ce sont des causes internes et elles peuvent être maîtrisées.
Vous pouvez réduire la probabilité de risques dus à la décomposition ou diviser une grande tâche en petites. 40 heures, ce n'est pas toujours quatre tâches de 10 heures chacune; lors de la décomposition, il peut s'avérer que pour l'intégration d'un système de paiement douloureusement familier dans un projet inconnu, les solutions de box prêtes à l'emploi ne suffiront pas, et vous devrez écrire les vôtres. La décomposition aidera à évaluer correctement les délais et à simplifier le contrôle de leur respect.
Certaines des causes externes peuvent également être influencées, surtout lorsqu'elles se trouvent chez le client. Plus tôt le client donne accès aux textes, logo, documentation, API (dans le cas où le côté serveur exécute la commande côté client), mieux c'est. Et ce sera encore mieux si vous collectez ensemble les risques associés au client et les incluez dans le contrat. Ce sera un grand rappel au client qu'il fait également partie du projet.
Si le client est en bonne forme, le projet se déroulera facilement. Informez-le de l'état des tâches, parlez de tout ce qui peut mal tourner et qui entraînera un retard, parlez de ce que vous essayez de résoudre le problème. Premièrement, vous pourriez être surpris de voir comment cela vous rapproche et vous encourage à engager le dialogue le plus constructif possible. Deuxièmement, une éventuelle sortie du terme et sa réaffectation ne seront plus une surprise pour le client. Une bonne communication est la
clé du succès .
Vous n'avez pas de plan B
Un bon manager, comme un joueur d'échecs, calcule à l'avance les options pour les événements. Mais si un joueur d'échecs ne regarde dans l'avenir que pendant quelques minutes, alors le manager - pendant quelques mois avant la date limite, c'est sûr. Pendant ce temps, tous les risques devraient apparaître.
Dans un tel cas, pour un certain nombre de tâches particulièrement complexes, il est nécessaire de choisir une version plus budgétaire de leur solution, dont l'expérience utilisateur ne souffrira pas, et le résultat global restera adéquat. C'est ce qu'on appelle le flex. Option
Flex -
abandonner la conception personnalisée . Mais utilisez toujours les directives d'Apple et de Google. N'oubliez pas d'expliquer au client que c'est maintenant la meilleure option pour respecter le délai.
Vous ne pouvez pas ajouter de la valeur au client aux yeux du client.
Pourtant, commencer par des excuses est normal, c'est la politesse de base. Une autre chose est que les excuses doivent être appuyées par quelque chose d’appliqué. Ce sera génial si vous:
- analyser le problème lors de la réunion avec l'équipe, tirer des conclusions et promettre au client que cela ne se reproduira plus;
- justifier que la date limite avait un sens pour le projet à l'avenir. Pendant ces 16 heures supplémentaires, vous avez probablement scrupuleusement testé l'application et corrigé des bugs qui ruineraient irrémédiablement le produit et l'image du client s'il tombait entre les mains de l'utilisateur.
Si vous ne voulez pas vous sentir coupable et faire un dysfonctionnement dans le rythme mesuré de votre vie, ne faites aucune de ces erreurs. J'ai énuméré les plus élémentaires et nous pensons que les spécificités de votre travail entraînent d'autres erreurs. Ce sera génial si vous en parlez dans les commentaires.