Les managers sans formation technique pensent souvent que l'essentiel est de rédiger des termes de référence détaillés pour les développeurs, et après cela, il ne reste plus qu'à leur demander de respecter strictement les délais. Oui, c'est important.
En plus de la description des fonctionnalités, les termes de référence doivent inclure les maquettes d'écrans avec un design entièrement fini et les textes de tous les messages affichés à l'utilisateur car c'est une mauvaise idée de laisser la conception et la rédaction au développement logiciel .
Mais pire que tout, après avoir discuté des fonctionnalités avec les développeurs, prendre du recul et attendre tranquillement le résultat. Le développement logiciel est un processus continu, et vous devez clairement comprendre sur quoi vous travaillez en ce moment et ce qu'il reste à faire. Plus vous approfondissez le processus, plus il est probable que vous remarquiez quand quelque chose ne va pas.
Focus sur les fonctions principales
Comment ce type d'immersion peut-il aider? L'une des causes les plus courantes de dépassement des délais est des difficultés inattendues dans la mise en œuvre de fonctionnalités petites et pas si importantes. Les bons développeurs s'efforcent de créer de bons produits, ce qui signifie mettre en œuvre tous les éléments spécifiés dans la spécification. En tant qu'idéologue du produit, vous pouvez et devez supprimer toutes les fonctionnalités mineures du plan si elles commencent à prendre trop de temps, c'est-à-dire plus de quelques jours.
N'ajoutez pas de nouvelles tâches pendant le développement du logiciel
Une fois que vous vous serez immergé dans le processus de développement et que vous aurez eu la chance de voir des résultats intermédiaires, vous aurez un fort désir d'ajouter et de modifier des fonctionnalités à la volée. Ne fais jamais ça ! L'ajout et la modification d'exigences en direct est le plus gros frein au calendrier de développement ; les fonctionnalités partiellement implémentées sont beaucoup plus difficiles à modifier.
Dans 95% des cas, il vaut mieux rester dans le plan d'origine et tester une nouvelle fonctionnalité conçue sur des utilisateurs en direct. Et puis apportez des modifications en fonction des commentaires.
Contrôlez les efforts des développeurs
Au fil du temps, vous estimerez la durée d'une tâche, et elle sera plus précise que la équipe de développement logicielles résultats. Par exemple, de nouvelles fonctionnalités sont ajoutées relativement rapidement, tandis que la refonte d'anciennes fonctionnalités lors de la conversion de données utilisateur existantes est toujours lente et atroce. Apprendre à présenter des délais plus ou moins réalistes n'est pas si difficile ; il est plus difficile de les influencer.
Le perfectionnisme est une qualité psychologique qui distingue les bons développeurs des mauvais. Cela s'applique non seulement aux écrans et boutons de résultats visibles, mais également à l'implémentation interne du produit, c'est-à-dire au code.
Par exemple, vous devez ajouter un mécanisme d'action bonus sur la page de paiement. Un bon développeur serait capable de mettre en place en une semaine un mécanisme prenant en charge toute action administrée depuis le panneau d'administration, avec des conditions personnalisables, un timing, etc.
Mais vous avez besoin d'une solution rapide pour lancer la promotion demain et jeter ce code pour toujours une semaine plus tard. Vous devez comprendre quels composants resteront longtemps dans votre produit et lesquels peuvent être implémentés à des fins jetables et le communiquer clairement à l'équipe de développement logiciel.
Triez les tâches et ne les définissez pas toutes en même temps
Les tâches de l'équipe de développement logiciel sont divisées en grandes (créer une nouvelle fonctionnalité) et en petites (réparer le formulaire d'inscription). La règle générale est de ne jamais distraire un développeur d'une tâche énorme pour en résoudre une petite, même urgente.
Certains professionnels uniques peuvent travailler efficacement dans un tel mode, mais la plupart des développeurs réduisent considérablement la productivité en raison du basculement constant entre les tâches. Par conséquent, il est logique d'avoir une alternance - d'abord une mission énorme, puis une semaine de petites tâches. Enregistrez les petites tâches telles qu'elles apparaissent, mais confiez-les au développement de logiciels pour les inclure dans une liste lorsque la prochaine itération ou version est prévue.
Chaque développeur est différent
La différence de performances entre les développeurs individuels peut être énorme. Par exemple, dans certaines études, la version des meilleurs et des pires programmeurs ayant à peu près la même expérience différait d'un facteur dix.
Vous devez comprendre qu'une même personne peut afficher une excellente vitesse sur les tâches d'un plan (par exemple, les extensions d'interface) et une vitesse catastrophique sur d'autres tâches (tâches côté serveur à grande échelle). Donc, chacun devrait se voir confier des tâches avec lesquelles il est à l'aise de travailler. Sinon, la productivité chutera.
Être un assistant des développeurs
Une chose importante vous aidera à parler le même langage que les développeurs. La plupart des techniciens ont un cerveau très organisé et rationnel ; ils s'inscrivent dans un schéma logique. Mais ce schéma ne sera pas toujours pratique pour vos utilisateurs.
En tant que personne non technique, vous avez un avantage : il vous est plus facile d'aller au-delà du cadre suggéré par l'implémentation et de communiquer aux développeurs la bonne vision. Mais rappelez-vous : pour faire comprendre votre point de vue à l'équipe de développement logiciel, vous devrez prouver que vos idées sont justes avec des arguments logiques.
Prévoyez du temps pour les changements internes
Vous devez vous rappeler qu'il y a des tâches chronophages que vous ne pouvez pas voir de l'extérieur dans n'importe quel projet, mais vous devez les faire. C'est ce qu'on appelle la dette technique. Comment s'est-il formé ? Tout en ajoutant de nouvelles fonctionnalités, le projet se dote de béquilles et d'accessoires.
De nombreuses tâches sont résolues rapidement mais de manière peu fiable. Par exemple, si vous ne mettez pas régulièrement votre code en ordre (ce processus s'appelle refactoring) et ne développez pas l'architecture du projet, vous augmenterez constamment les erreurs après un certain temps.
Ils peuvent survenir lors de l'ajout de nouvelles fonctionnalités ou même lors de la correction d'anciens bogues. Si vous ne passez pas de temps à développer l'architecture du projet, vous ne pourrez pas faire face tôt ou tard au nombre croissant d'utilisateurs.
Les tâches liées à la dette technique doivent être planifiées et exécutées, mais comment trouver le bon équilibre entre elles et le développement de produits ? Naturellement, votre attention en tant que bailleur de fonds et personne non technique se déplacera vers de nouvelles fonctionnalités. Mais d'un autre côté, les développeurs ont tendance à améliorer sans cesse le code existant et sont moins enthousiasmés par les nouvelles fonctionnalités.
Par conséquent, vous devez toujours, au moins à un niveau de base, comprendre la technologie et la structure de votre produit pour trouver un équilibre dans les discussions avec les développeurs. Les tâches techniques doivent occuper environ 20% des heures de travail de l'équipe de développement logiciel et accompagner le développement de nouvelles fonctionnalités et la correction de bogues.
En savoir plus sur la technologie
Pour développer un produit, vous devez étudier sa structure et la technologie en général, au moins à un niveau de base. C'est vital car la technologie est peut-être encore vivante mais pas tout à fait adaptée à vos tâches. Et il est souvent impossible de le savoir avant de lancer le système en mode bataille — avec de vrais utilisateurs et sous de lourdes charges.
Pour résumer, vous ne pouvez toujours pas vous passer d'une immersion dans la technologie et le développement de logiciels en tant que bailleur de fonds. De plus, ces connaissances vous permettront de mieux comprendre l'évolution de votre projet.