Qu'est-ce qu'un chef de projet technique ?

Qu'est-ce qu'un chef de projet technique (TPM) ? La réponse dépend de la personne à qui vous posez la question, déclare Andi Blackwell, consultant informatique chevronné et expert en opérations commerciales. En tant que directeur principal de la gestion de projets et de produits chez Toptal, Blackwell dirige l'équipe chargée de mettre en relation des chefs de projet hautement qualifiés du réseau indépendant de Toptal avec des organisations à la recherche de meilleurs talents pour des initiatives spécifiques. Ces dernières années, elle a constaté une augmentation de la demande de TPM.

"Il y a certainement un débat dans l'industrie technologique sur la signification réelle de ce terme", déclare Blackwell. "Beaucoup de gens se disent chefs de projet technique parce qu'ils ont travaillé en étroite collaboration avec une équipe d'ingénieurs ou ont dirigé une équipe technique du point de vue de la gestion de projet, mais ce n'est pas ce que nous recherchons."

La définition de Toptal est plus précise. Tous les chefs de projet du réseau Toptal sont des experts dans les compétences traditionnelles de gestion de projet telles que la portée, la budgétisation et la gestion des délais, ainsi que dans les pratiques de développement logiciel Agile liées à la livraison itérative et à l'amélioration continue. Ils ont invariablement travaillé en étroite collaboration avec des ingénieurs et pourraient, s'ils étaient appelés, coacher et guider une équipe Scrum.

Cependant, pour être qualifiés de TPM, ils doivent avoir une couche d'expérience supplémentaire au-delà de la gestion des processus Agile et de la collaboration avec les développeurs : ils doivent avoir été eux-mêmes développeurs.

Une combinaison prisée

Les organisations, grandes et petites, s'intéressent de plus en plus à cette combinaison particulière de compétences. "La plupart des startups ne peuvent pas embaucher une personne qui ne peut faire qu'une seule chose", explique Blackwell, et les grandes entreprises veulent voir "développeur" ou "architecte" dans le profil d'un candidat si elles embauchent pour un projet d'ingénierie.

Même dans les cas où un client n'a pas spécifiquement besoin d'un chef de projet avec une formation technique, le fait de cocher la case « développeur » est un argument de vente majeur. Quelqu'un qui peut planifier et exécuter un projet logiciel, mettre en œuvre et optimiser des processus Agile et coder ? C'est une énorme aubaine.

En réalité, cependant, on ne s'attend pas à ce que les TPM codent - beaucoup n'ont pas codé depuis des années. Pourquoi, alors, le besoin d'expérience en programmation ?

Les TPM sont nécessaires pour prendre des décisions techniques, déclare Blackwell : "Si vous n'avez pas au moins une expérience pratique relativement récente avec une pile technologique moderne, un SDK (kit de développement logiciel), une architecture ou une plate-forme d'automatisation des tests, alors vous' re ne va potentiellement pas prendre les bonnes décisions. Vous n'aurez pas de crédibilité auprès du client parce que vous n'avez jamais utilisé ces choses auparavant.

Travailler avec des équipes

Démontrer sa crédibilité à un client potentiel est un facteur important pour obtenir des engagements, mais ce n'est que le premier obstacle. Une fois affecté à un projet, un TPM doit gagner rapidement la confiance et le respect d'une équipe technique.

Michael Poythress a commencé la programmation à l'adolescence. À 16 ans, il a créé un site Web commercial pour une entreprise de publicité immobilière qu'il a créée avec son père. Il a été PDG et fondateur de plusieurs startups depuis. En 2018, il rejoint le réseau Toptal en tant que TPM et travaille désormais en étroite collaboration avec les équipes d'ingénierie. "Si je n'avais aucune expérience du codage, les programmeurs s'en empareraient", dit-il. «Ils ne tireraient pas directement avec moi. Mais si je les mets au défi et leur parle en tant que pair, il y a du respect et un rapport.

Et c'est l'expérience technologique qui compte plus que le titre, déclare Allen Takatsuka, un TPM Toptal basé dans le comté d'Orange, en Californie : « D'après ce que j'ai vu, le « T » dans TPM n'a pas vraiment de poids pour les ingénieurs. Ils pensent que c'est juste un autre chef de projet qui va organiser leurs réunions et leur demander de remplir des feuilles de calcul. »

Cependant, une fois qu'un terrain d'entente est établi, « la saveur de l'interaction est très différente. Il s'agit davantage d'un partenariat avec l'ingénierie », dit-il.

Takatsuka a passé des décennies à diriger des équipes d'ingénierie plus tôt dans sa vie professionnelle. Il attribue cette expérience pour avoir amélioré ses compétences générales. « C'est une compétence d'empathie un peu différente », dit-il. « Vous devez montrer que vous pouvez parler la langue. Vous êtes en mesure de dire : "Je vois pourquoi vous avez ces défis basés sur les choses techniques qui se passent."

Dan Allen, un consultant en technologie de Vienne, en Virginie, décrit sa progression de carrière en tant que "programmeur de gars dans le compartiment à responsable technique à architecte, directeur, vice-président, directeur technique, directeur informatique". Depuis qu'il a rejoint le réseau Toptal en tant que TPM en 2019, il a été occupé, ayant travaillé sur 14 engagements clients.

« Je lis rarement du code. Je n'écris presque jamais de code », dit-il. "Mais il y a eu des situations où un développeur est resté bloqué. Ils peuvent me guider à travers l'architecture et je peux voir exactement ce qu'ils essaient de faire et la logique. »

Il trouve la dynamique utile non seulement dans les cas extrêmes, mais plus largement. « Votre équipe sait qu'elle peut venir vous parler et vous comprenez vraiment ce qu'elle dit », dit-il. « Vous pouvez les aider à prendre en compte toutes les complexités au cas où ils auraient manqué quelque chose. Vous pouvez être une caisse de résonance et fournir des commentaires.

L'effet multiplicateur

Ce genre de commentaires et de perspicacité est important pour plus que l'établissement de relations. Les TPM offrent une proposition de valeur différente à une organisation. Ils servent moins de canaux d'information que de sources de connaissances. Oui, ils planifient, coordonnent et communiquent, mais ils aident également les clients et les équipes à prendre des décisions technologiques complexes.

"Vous avez la capacité d'avoir une opinion technique", déclare Takatsuka. "Et cela ajoute de la valeur à l'organisation parce que maintenant vous avez plus d'effet multiplicateur, par opposition à une simple organisation et collaboration."

Takatsuka note que les TPM doivent franchir moins d'obstacles pour résoudre les problèmes. Dans les grandes organisations en particulier, un responsable de programme ou de projet non technique peut aborder un défi technique en identifiant les acteurs et parties prenantes concernés, en offrant un contexte, en regroupant des informations, puis en passant au crible les résultats pour prendre une décision. Les TPM peuvent apporter leurs propres connaissances.

"Vous pouvez gérer les risques de manière beaucoup plus efficace", déclare Oana Ciherean, TPM basée à Tokyo. « Et ces risques peuvent provenir de tant d'endroits. Ils peuvent provenir d'estimations erronées de l'équipe. Vous êtes donc capable de dire : "D'accord, je suis sûr que ce morceau de code ne prendra pas une semaine pour être écrit" parce que c'est vraiment deux jours. Ainsi, vous pouvez réellement débloquer des personnes. Parce que vous avez compris qu'ils sont coincés et c'est pourquoi cela leur prend cinq jours. Tu le sais parce que tu as été là et que tu as été coincé toi-même.

Trouver l'équilibre

Ciherean a commencé sa carrière en tant que développeur, mais est rapidement passée à la gestion de projet par désir d'être impliquée dans une vision plus large. Dans ces rôles, cependant, elle a découvert qu'elle manquait de codage. Elle dit que la gestion de projet technique offre le meilleur des deux mondes : "Cela me permet d'être vraiment pratique dans la technologie mais aussi de haut niveau avec la compréhension de l'entreprise et des clients et de ce qu'ils veulent en termes de fonctionnalités."

Poythress, elle aussi, a le sentiment d'avoir trouvé son bonheur. « Je suis un traducteur ou un agent de liaison entre les visionnaires qui ont une idée et le talent technique qui sait comment la construire et la concrétiser », dit-il. « Je parle couramment les deux langues. Je parle « personne normale » et je parle « jargon technique ».

Le Mini CTO

Les TPM travaillant pour les startups et les petites entreprises occupent une place particulièrement importante à l'intersection des affaires et de la technologie. Lors de ces missions, un TPM est souvent le premier employé à se joindre au début d'un projet. Il ou elle est ensuite responsable d'évaluer la viabilité du produit, de définir la portée et les exigences techniques, et d'aider le client (parfois un seul fondateur avec un germe d'idée) à sélectionner une pile technologique, à évaluer les fournisseurs pour la prestation de services, à mettre en œuvre les meilleures pratiques DevOps, et rassemblez la bonne équipe.

Takatsuka considère ces engagements comme des rôles de "mini CTO", dans lesquels le TPM fait le pont entre les domaines commerciaux et techniques pour faire décoller les choses. Certains clients ne connaissent presque rien au développement de logiciels, dit-il : « Comment puis-je m'installer ? J'ai lu sur Agile. Comment je fais ça?"

Poythress voit les deux rôles comme se chevauchant, voire indiscernables l'un de l'autre dans certains cas. « Il y a beaucoup de pollinisation croisée », dit-il. "Un CTO pour une petite organisation pourrait très facilement évoluer vers un poste de PM technique senior dans une grande organisation et se sentir comme chez lui."

Permettre l'agilité

Alors que les mécanismes d'Agile sont dans la timonerie de pratiquement n'importe quel chef de projet ayant une expérience en développement de logiciels, quelqu'un avec des aptitudes techniques peut apporter une perspective plus nuancée à la gestion des processus.

Ciherean constate que les méthodologies Agiles ne sont jamais mises en œuvre strictement par le livre ; ils doivent être personnalisés, mélangés et adaptés aux besoins spécifiques d'une équipe et d'un projet.

« Vous devez vous assurer que ce que vous concevez en tant que processus n'interfère pas avec le travail des développeurs et le rend réellement plus efficace ou productif », dit-elle. "Parfois, cela signifie approfondir le flux de travail GitHub, par exemple, pour voir comment ils font leurs commits, voir comment ils créent des branches pour leur code et voir si votre processus s'intègre dans leur flux de travail. Et ensuite, soit vous corrigez votre processus, soit vous corrigez leur flux de travail.

L'expertise d'un TPM peut également éclairer des artefacts et des pratiques Agiles spécifiques, comme le backlog de produit et les estimations de taille relative.

"Si vous comprenez la technique, vous connaissez la complexité approximative des choses dans un backlog", explique Takatsuka. "Sinon, tout ce que vous avez est cette liste et il vous serait difficile de savoir si le numéro un est un T-shirt de taille Large par rapport au numéro deux. Vous pourriez avoir une idée que l'on est plus difficile, mais vous ne savez pas vraiment ce qu'il y a dans les coulisses. Un TPM "extrême", dit-il, "pourrait mesurer les choses lui-même, avec la mise en garde que lorsque l'équipe embarquera, elle aura sa propre vitesse".

Poythress utilise sa compréhension de l'estimation de la taille comme jauge pour évaluer les responsables techniques et les ingénieurs qu'il considère pour un projet. S'il s'attend à ce que quelque chose soit une petite tâche mais que quelqu'un d'autre la considère comme un géant, c'est un signal d'alarme : "Je vais les écouter pour voir s'il y a des complexités que je ne connais pas, mais si cela ne tient pas la route, Je me dis, 'D'accord, eh bien, ce n'est pas un bon choix.' Nous avons besoin de quelqu'un qui comprend très bien cela et qui n'est pas intimidé par ce qui devrait être une fonctionnalité simple.

Les TPM aident également à éduquer les clients sur les exigences non fonctionnelles. Comment gérez-vous la haute disponibilité ? Comment gérez-vous la reprise après sinistre ? "Sans la compréhension technique, je ne sais pas comment vous avez cette discussion", dit Takatsuka. « Vous allez probablement vous arrêter au niveau des exigences Scrum et vous arrêter jusqu'à ce que les techniciens arrivent. Eh bien, alors vous avez cet énorme gouffre.

Rester à jour

Bien que le temps qu'ils passent devant un clavier joue un rôle fondamental dans ce qu'ils font aujourd'hui, les TPM ne peuvent pas se fier à leur expérience passée pour rester pertinents. Étant donné la vitesse à laquelle la technologie change et se développe, il est facile de prendre du retard.

Poythress l'a appris à ses dépens, au cours d'une période de cinq ans avant de rejoindre Toptal, alors qu'il se concentrait exclusivement sur la gestion de sa propre entreprise. "Je suis définitivement devenu stagnant", dit-il. "Beaucoup de langues différentes sont arrivées et ont résolu des problèmes pendant cette période dont je ne savais rien parce que nous avions notre pile technologique et c'était tout ce dont nous avions besoin."

Aujourd'hui, il passe jusqu'à 10 % de son temps à lire de la documentation, à regarder YouTube et à faire du sandbox "pour en savoir plus sur les nouveautés les plus importantes".

« Je suis presque toujours en train de m'essayer à un nouveau langage ou à une nouvelle technologie, juste pour rester à jour », dit-il. « Parce que si je ne le fais pas, l'industrie va continuer. Ça m'est déjà arrivé. Et c'est beaucoup plus difficile de caser que de rester à jour.

Takatsuka est également proactif pour combler ses lacunes dans les connaissances : "Google est génial ces jours-ci. YouTube est génial. Vous devez faire vos devoirs. Mais ce travail se construit sur lui-même.

Il s'appuie également sur un large réseau de collègues consultants pour le soutien et le partage des connaissances. "J'ai été dans des situations où le client voulait utiliser Google, mais je connais mieux la plate-forme AWS", dit-il. "Je peux appeler des amis et leur dire : 'Hé, nous allons utiliser Firebase. Avez-vous eu des clients qui font cela? Qu'en est-il de l'évolutivité ? »

Même après plus de 30 ans dans l'entreprise et de multiples postes de direction, Dan Allen n'a pas peur de se salir les mains. Au cours des trois dernières années, il a appris à se déployer seul sur Amazon et Google Cloud. « Je l'ai fait pour comprendre et aider un client de Toptal », dit-il. « Ils n'avaient pas d'équipe technologique. Tout ce qu'ils avaient, c'était moi. Je suis donc allé à l'université YouTube et j'ai réussi. »

Tant de choses ont changé depuis qu'Allen a commencé comme développeur en 1985. Mais il savoure les défis qui accompagnent chaque nouvelle opportunité. « Cela fait partie de ce que j'aime dans ce travail », dit-il. « Il y a toujours quelque chose que vous n'avez pas fait, quelque chose de nouveau. Et vous repartez toujours avec une plume supplémentaire dans votre casquette que vous pouvez exploiter lors du prochain engagement.