Lancer un projet

Partons de zéro pour devenir un héros en examinant les éléments nécessaires pour un projet qui devient un produit et devient quelque chose d’utile.

Vous allez construire un excellent produit, mais j’ai une nouvelle pour vous. Tout commence par un projet. C’est normal. Nous pouvons l’appeler Produit, MVP (Minimum Viable Product) ou ce que nous voulons, mais il va commencer comme un projet.

De nombreuses entreprises discutent du pourquoi et des avantages que cette activité particulière apporterait. Consultez le budget pour obtenir des informations sur les calculs de valeur actualisée nette (NPV - quelle est sa valeur actuelle ?) —calculs et Build ou Buy (construire ou acheter).

Il existe de nombreuses méthodologies de gestion de projet qui peuvent vous aider à démarrer, planifier, mettre en œuvre, tester, lancer et clôturer votre projet. Il existe également certaines méthodologies qui gèrent ce processus en itérations, c’est-à-dire des répétitions courtes, plutôt que des phases plus longues.

Ce que cela signifie pour les projets a de grandes implications sur la façon dont vous l’organisez, comment vous le menez et comment il est livré.

Pour l’exhaustivité de ce petit livre, je vais rapidement expliquer la gestion de projet classique, également appelée « Waterfall ». Imaginez une rivière. C’est votre processus de projet. Vous avancez toujours le long de la rivière et vous ne revenez pas en arrière pour modifier les choses au fur et à mesure, tout est fixé et définitif.

Ainsi, vous avancez plus loin et entrez dans différentes phases, comme la phase de mise en œuvre où tout le code doit être codé, puis la phase de test lorsque celui-ci doit être testé. Tout est basé sur des spécifications préalables qui ont été rédigées avant que vous ne commenciez le projet.

Vous saviez exactement ce que vous vouliez construire, jusqu’au dernier bouton. Ainsi, vous avez passé des mois à le mettre dans un document, puis vos développeurs seniors ou architectes vous ont aidé à rédiger les fonctions dans le document de spécifications fonctionnelles. Ensuite, dans la phase de mise en œuvre, vous construisez exactement ce qui était dans cette spécification. Ensuite, vous testez que tout fonctionne comme spécifié.

Cela n’a jamais fonctionné dans aucun projet technique. Les meilleures livraisons de ce type de projets ont produit une application qui a fait exactement ce qu’elle était censée faire, mais n’a pas pris en compte les découvertes ou les idées trouvées au cours du développement.

De plus, le temps a passé pendant la durée du projet et vous avez perdu certaines chances de le montrer à un client potentiel et d’obtenir des retours précieux. Vous avez maintenant construit quelque chose que vous n’avez pas testé avec de vrais utilisateurs. Je vais prendre le risque ici et dire que cela ne sera probablement pas ce que vous vouliez.

Lisez-en plus dans «Le Playbook du CTO» disponible sur Amazon/Kindle.