Vous avez besoin d'un héros : le chef de projet

Cet article est pour vous, l'entrepreneur courageux avec une idée d'application dans le cœur et un peu d'argent à la banque. Les schémas que vous avez griffonnés sur des serviettes à cocktail vont bouleverser le monde entier, et des camions à benne remplis d'argent ont déjà été dépêchés chez vous. Pour vous assurer qu'ils arrivent à temps, voici quelques conseils simples pour assurer le bon déroulement de votre cycle de production.

Pourquoi avez-vous besoin d'un chef de projet en premier lieu

"Les programmes informatiques sont les choses les plus complexes que les humains fabriquent", déclare Douglas Crockford. Vous n'avez peut-être jamais entendu ce nom auparavant, mais il est assez célèbre pour un programmeur. Il est actuellement architecte logiciel senior chez PayPal, et il a été le pionnier de toutes sortes de technologies intéressantes qui dépassent le cadre de cet article. C'est quelqu'un qui sait très bien travailler sur de grands projets.

Pour ma part, je fais de la programmation depuis 13 ans, et même maintenant, à un moment donné, chaque projet m'emmène en territoire inconnu. Il existe tellement de technologies différentes et de nouvelles techniques sont conçues à un rythme si alarmant que je n'ai jamais l'impression d'être complètement au courant de ce qui se passe. Bien que chaque projet ait ses défis uniques, il existe certaines constantes :

• Le projet a une pression de temps.
• Le budget est plus petit que je ne le souhaiterais.
• Je suis plus cher que le client ne le souhaiterait.
• Je n'écoute pas aussi parfaitement que le client le souhaiterait.
• Le client n'explique pas les choses aussi parfaitement que je le voudrais.

De toute évidence, nous avons besoin d'une baby-sitter. Quelqu'un doit intervenir pour établir les règles de base, garder tout le monde honnête et s'assurer que nous n'oublions rien d'important. Quelqu'un doit faciliter la communication entre toutes les parties.

Ce quelqu'un, ce héros, c'est le chef de projet.

Toptal n'offrait pas de contrats avec des chefs de projet lorsque j'ai commencé à écrire cet article, mais ils le font maintenant. Synergie! Je ne peux qu'imaginer que les pouvoirs en place ont lu les conseils suivants et ont réalisé qu'ils manquaient une belle opportunité.

Pourquoi un programmeur ne fait pas un bon chef de projet

À part la certification du Project Management Institute, la chose la plus importante qu'un chef de projet puisse apporter à la table est l'expérience. En conséquence, de nombreux programmeurs feraient des chefs de projet assez décents ; nous avons plus d'expérience dans les projets techniques que quiconque et nos esprits analytiques sont aptes à cataloguer les informations et à fixer des objectifs concrets.

Dieu sait que vous nous payez suffisamment, il semble donc raisonnable de s'attendre à ce que nous puissions nous débrouiller plutôt que de vous forcer à payer également pour le temps de quelqu'un d'autre, n'est-ce pas ?

Eh bien, pour commencer, vous nous payez pour coder.

Lorsque nous sortons de notre étourdissement de programmation pour prendre des décisions sur ce qu'il faut prioriser, ou pour discuter de ce qui va réellement être fait cette semaine, le code n'est pas écrit. Il faut ensuite au moins 10 minutes pour revenir dans "la zone", surtout si nous sommes stressés par la conversation que nous venons d'avoir, ce qui est probable si nous discutons de la priorité des fonctionnalités. Boo hoo, je sais, mais il s'agit d'utiliser au mieux des ressources coûteuses.

Plus important encore, nous ne pouvons vraiment pas voir la forêt pour les arbres. Si vous ne retirez rien d'autre de cet article, veuillez comprendre ceci : lorsque je passe toute la journée à regarder quelques bogues spécifiques, mon cerveau perd la vue d'ensemble.

Mon cerveau me récompense lorsque je corrige ces bugs, et je suppose que j'ai fait de grandes choses et que je peux jouer à des jeux vidéo maintenant. Quand quelqu'un me rappelle que la page d'accueil est toujours cassée, c'est une surprise totale parce que j'ai passé la journée à remplir mon cerveau d'une connaissance très détaillée d'un très petit morceau du projet global et j'ai en quelque sorte oublié le reste. C'est comme ça que mon cerveau fonctionne, et beaucoup d'autres programmeurs ont une constitution psychologique similaire.

Pourquoi un client ne fait pas un bon chef de projet

Eh bien, si nous, les programmeurs, ne voulons pas prendre la responsabilité de faire avancer les choses en matière de gestion de projet, cela doit vous incomber, le client. C'est votre argent. C'est votre vision. Vous êtes finalement responsable de tout, de toute façon.

Cependant, vous avez aussi beaucoup à faire.

De nombreux clients sont de simples mortels avec des emplois de jour comme le reste d'entre nous, et certains sont même connus pour souffrir de procrastination ou d'oubli. Bien que cela ne vous décrive pas nécessairement, veuillez entretenir l'idée d'avoir un mémorialiste professionnel autour de vous afin que vous puissiez reprendre le travail important qui consiste à maintenir l'ensemble du projet en vie.

Si vous avez travaillé sur ou supervisé un projet technique d'envergure similaire, vous pouvez en effet faire un bon gestionnaire pour votre projet. Si ce n'est pas le cas, ne sous-estimez pas la valeur de quelqu'un qui peut prédire les problèmes qui pourraient survenir. Les estimations de temps ne sont toujours que des estimations, et les bogues ont tendance à apparaître aux moments les moins opportuns. Cela vaut le coût d'un autre employé (si ce n'est qu'à temps partiel) d'avoir quelqu'un autour qui sait quelles parties du processus nécessitent, ou sont susceptibles de nécessiter, le plus d'attention.

Prenez l'assurance qualité (AQ), par exemple. Une bonne assurance qualité est essentielle pour obtenir ce que vous voulez de n'importe quel projet, et elle n'obtient jamais l'attention qu'elle mérite. Un bon chef de projet tirera le meilleur parti des ressources d'AQ limitées et assurera également la qualité de vos programmeurs pour vous. Parfois, nous sortons de notre profondeur, et parfois nous faisons des erreurs. Vous avez besoin d'une personne techniquement compétente dans un rôle de supervision pour déterminer si votre programmeur a juste un jour de congé ou s'il est, en fait, un mauvais candidat pour le projet. Endiguer tôt les problèmes de personnel pourrait signifier la différence entre la vie et la mort pour votre projet.

Enfin, même vous, le client, avez parfois besoin d'un petit contrôle et/ou d'un équilibre. C'est difficile pour moi d'écrire puisque nous, les programmeurs informatiques, ne sommes pas bien connus pour notre franc-parler. Qu'il suffise de dire que j'ai travaillé sur de nombreux projets où le client était catégorique sur le fait que tout était la priorité absolue et qu'absolument tout devait être fait. Bien que je ne doute pas que cela était absolument vrai, ces clients, malheureusement, n'avaient aucun contrôle sur le nombre d'heures dans une journée. Ils n'ont pas obtenu le résultat positif qu'ils souhaitaient et/ou méritaient, et je pense que ce résultat aurait pu être évité si le client avait confié à un chef de projet le pouvoir d'évaluer la charge de travail et de garder les choses sous contrôle avec tact, mais fermement. . Il est difficile de porter le jugement impartial que nécessitent la plupart des projets techniques lorsque c'est votre idée et votre argent qui sont en jeu et que l'ordinateur ne se soucie pas que vous ou moi pleurions et criions dessus. (Je sais que c'est vrai parce que je l'ai essayé plusieurs fois.)

Une liste incomplète de techniques pour gérer un projet technique

Que vous ayez décidé d'ignorer les quelque 1 000 mots précédents et de gérer votre projet vous-même, ou que vous alliez embaucher quelqu'un mais que vous souhaitiez en savoir plus sur le processus, cette liste vous aidera. Je n'ai jamais (officiellement) été chef de projet, donc je ne peux pas dire quels outils un chef de projet donné utiliserait, mais j'ai eu beaucoup de succès avec toutes ces techniques :

Jalons

Lors du démarrage d'un nouveau projet, la plupart des gens savent intuitivement qu'il est important de diviser le projet en morceaux légèrement plus gérables, chaque morceau allant de quelques semaines à quelques mois de travail. Au début du projet, il est bon d'avoir une réunion de lancement pour établir ces jalons. Il est normal d'être un peu vague sur la façon dont vous allez les atteindre, le plus important est de continuer à vérifier après chaque jalon afin de bénéficier de la meilleure compréhension du projet par chacun et de s'assurer que les jalons du projet sont toujours ( à peu près) la même taille qu'on le croyait initialement.

Estimations de temps

Nous, les programmeurs, détestons absolument les estimations parce que nous savons qu'elles seront fausses et nous savons qu'elles seront utilisées contre nous. C'est normal qu'ils se trompent car, par définition, ils sont basés sur une poignée d'inconnues. C'est aussi OK qu'ils soient utilisés contre nous parce que nos emplois sont plutôt pépères et ça ne fait pas de mal d'avoir le fouet claqué de temps en temps.

N'hésitez donc pas à demander des estimations chaque fois que le travail commence sur une nouvelle étape. Vous devez vous attendre à une ligne ou deux pour chaque fonctionnalité majeure ainsi qu'à une estimation approximative de la durée de cette fonctionnalité. Je fais généralement une estimation optimiste, puis je la double. Le plus souvent, ce temps supplémentaire représente des pièges invisibles.

Histoires d'utilisateurs

Les user stories sont de brèves descriptions d'une seule fonctionnalité de l'application. Ils sont utiles comme enregistrement des caractéristiques importantes et doivent être de la taille d'une bouchée, pouvoir tenir sur une fiche et souvent accompagnés d'un petit dessin. Plus important encore, ils servent de pont entre ce que veut le client et ce que le programmeur doit dire à l'ordinateur. Ils sont assez simples pour que vous, le client, les assommiez en quelques minutes, mais suffisamment détaillés pour que nous, les programmeurs, les mâchions.

Pour quelques informations rapides sur les histoires d'utilisateurs, j'ai trouvé ces tutoriels de Mountain Goat Software et Roman Pichler de haute qualité et succincts. Pour plus d'informations sur toute la philosophie de la gestion de projet agile, essayez cet article de blog Toptal L'introduction ultime à la gestion de projet agile par Paul Barnes.

Compositions (Maquettes)

Ce n'est pas un article sur la raison pour laquelle vous avez besoin d'un concepteur parce que j'ai l'impression que la plupart des clients le comprennent déjà, mais cela mérite d'être répété parce que vous verrez d'énormes gains de productivité si vous présentez une conception concrète et bien pensée devant vos programmeurs. Chaque fois que nous devons prendre une décision de conception, nous devons quitter «la zone», et chaque fois que nous devons revenir en arrière et changer quelque chose parce que nous n'avons pas reçu le projet final, eh bien, vous faites le calcul… Je ' Je ne me plains pas, car le design est amusant, mais d'après mon expérience, c'est la première source d'heures évitables et facturables supplémentaires.

La plupart des concepteurs proposent des compositions, également appelées compositions, dans Adobe Photoshop, Adobe Illustrator ou Sketch. Si vous le faites vous-même, vous pouvez utiliser l'un des innombrables outils en ligne tels que Balsamiq ou InVision. La composition n'a pas besoin d'avoir les mêmes couleurs et styles que le produit fini (car ceux-ci peuvent être facilement modifiés ultérieurement), mais veuillez prendre plus de temps pour vous assurer que tous les éléments de l'interface utilisateur sont présents et pris en compte.

Réunions debout

De longues réunions sont parfois inévitables, mais vous ne voulez vraiment pas surcharger vos programmeurs ou leur prendre plus de temps que nécessaire. J'ai eu des clients qui semblaient s'attendre à ce que je me souvienne de tout ce qui s'était dit lors d'une réunion de deux heures et demie; ils ont été profondément déçus. Une réunion debout est généralement limitée à 15 minutes et il est d'usage de rester debout pendant toute la durée. L'aspect permanent est censé s'assurer que tout le monde participe, ainsi que pour que la réunion soit courte.

Pendant les stand-ups, tout le monde tourne en cercle pour fournir un bref rapport d'état, tenant tous les membres de l'équipe au courant des progrès de chacun. Vous pouvez en savoir plus sur les stand-ups sur ExtremeProgramming.Org. Si vous travaillez tous à distance et que vous ne voulez pas que tout le monde soit sur Skype tous les jours, vous pouvez essayer un outil amusant tel que 15Five comme alternative aux stand-ups. 15Five permet aux membres de l'équipe de donner leur avis quand cela leur convient, et il leur proposera des questions d'enquête pour obtenir des réponses plus approfondies.

Système de billetterie

Bien que n'importe qui puisse maintenir un système de notes autocollantes et de Google Docs (avec les tâches de chacun mises en évidence dans différentes couleurs), ce n'est vraiment pas nécessaire ; beaucoup de gens ont essayé de résoudre ce problème pour vous. Basecamp et Trello sont réputés pour leur facilité d'utilisation, tandis que Pivotal essaie d'encapsuler toute la philosophie "agile" dans un package très astucieux. Quel que soit votre choix, un bon système de billetterie vous permettra, au minimum, de :

• Créer des tâches
• Attribuer une priorité et une date d'échéance
• Lier les tâches et les sous-tâches
• Attribuez différentes résolutions telles que "test terminé" ou "test échoué"
• Afficher toutes les tâches attribuées à un certain utilisateur

Lorsqu'un chef de projet vous montre 40 tickets prioritaires rouge vif, tous dus le même jour, vous comprendrez vraiment la valeur de cette vue d'ensemble du projet.

Contrôle des sources

Vous ne regarderez peut-être même jamais le code dans le système de contrôle de version de votre projet, mais le contrôle de source (ou versioning) est l'un des outils les plus importants à notre disposition, le meilleur système de sauvegarde imaginable.

La plupart des projets modernes utilisent Git, bien que parfois vous rencontriez Subversion (SVN) lorsque vous travaillez sur des projets qui existent depuis un certain temps. Github vous permet d'héberger gratuitement un nombre illimité de référentiels publics (en plus, il contient la plupart des projets open source du monde), tandis que Bitbucket vous permet d'héberger un nombre illimité de référentiels privés et est donc le choix privilégié pour les projets commerciaux.

Quel que soit le système de contrôle de version que vous choisissiez, il stocke notre code à distance au cas où quelque chose se passerait, et suit chaque fois que nous lui «commitons» du code tout en nous obligeant à écrire un petit message décrivant ce sur quoi nous travaillions. Cela empêche différents développeurs d'écraser le code de l'autre, cela nous permet de voir toutes les modifications apportées au cours d'une période donnée et cela nous permet de créer de nouvelles branches de code pour stocker les fonctionnalités qui ne sont pas mises en ligne immédiatement. Il a même une commande appelée "blame" qui montre qui était responsable d'une ligne de code donnée et quand elle a été validée.

Le contrôle de la source est le plus grand.

Développement piloté par les tests

Il s'agit d'une pratique relativement coûteuse, ce qui signifie qu'elle n'est pas fréquemment utilisée dans des projets où le budget est limité à quelques pigistes. Donc, en tant qu'entrepreneur en démarrage, vous ne devriez pas vous sentir trop mal de ne pas le faire, mais je dois suspendre l'idée devant vous car elle offre la défense ultime contre les bugs. Fondamentalement, vos programmeurs passent de précieuses heures supplémentaires à écrire des tests (petits blocs de code) qui garantissent que certaines parties de l'application se comportent de manière spécifique, prévisible et reproductible. Par exemple, je pourrais écrire un test affirmant que lorsque le bouton "Connexion" est cliqué, une fenêtre contextuelle s'ouvre avec un champ de nom d'utilisateur.

La beauté des tests est qu'une fois que je les ai écrits, je peux tous les exécuter avec une seule commande. Si j'ai écrit 200 tests, je peux les exécuter après avoir publié une nouvelle version de l'application pour m'assurer qu'aucun bogue n'a été introduit dans l'une de ces 200 fonctionnalités. Ce n'est pas parfait, mais c'est aussi proche que possible de garantir des applications sans bug (bug-lite, au moins).

Emballer

C'est à peu près tout ce que je sais sur la gestion de projet. Je ne sais pas quelle part de tout cela passerait au Project Management Institute, mais c'est tout ce que j'ai appris en travaillant sur des projets Web au cours de la dernière décennie. Bien sûr, je vous recommande d'embaucher quelqu'un afin de profiter de son expérience, mais j'espère que vous trouverez ces informations utiles même si ce n'est pas quelque chose que vous êtes capable de faire. Vous serez l'autorité ultime sur ce projet, donc plus vous comprendrez son fonctionnement interne, plus vous aurez de chances de le mener à la victoire.