Startups & PME : 4 conseils pour monter et animer son équipe de dev !

“Pour votre business, choisissez un dev qui ne dev pas”. Vous trouvez cette phrase contre intuitive ? Et pourtant ! Si vous deviez construire une maison, vous faites d’abord appel à un architecte, pas à un peintre. Eh bien, pour mener à bien un projet digital, la logique de remonter de l’exécution à la gestion est la même.

Lorsque vous êtes une startup ou une PME, vous êtes pris entre deux impératifs :

1. la génération de leads, nécessaire au bon développement de votre entreprise (pas d’entreprise sans revenus !).
2. la structuration/gestion de l’équipe – dont les développeurs, entre autres – que vous avez engagée pour développer votre entreprise et ses projets, notamment digitaux. 

Que vous en soyez au stade de la réalisation de votre MVP, de votre MAP, ou que vous vous soyez en plein développement d’un projet digital, vous êtes en questionnement permanent. Votre premier réflexe est de vous référer à un/votre dev ou encore à un CTO. 

On vous l’avait déjà expliqué dans notre article dédié aux 5 outils gratuits pour une transformation digitale facile : dans bien des cas, développer une solution tech en propre n’est pas nécessaire. Dans 90% des cas, des solutions prêtes à l’emploi existent déjà.

Vous êtes dans la tranche des 10% des cas pour lesquels il vous faut créer votre propre module ? Pour ce faire, vous vous tournez vers un dev. Mais est-ce vraiment ce dont vous avez besoin ? Nos conseils avant de vous lancer.

Le bon développeur, c’est celui qui va comprendre la finalité de votre demande. Pour bien développer le produit, il doit comprendre l’enjeu dudit produit pour l’entreprise, et donc donc avoir toutes les infos en amont pour comprendre les attentes en termes de business.  

C’est donc aussi le dev qui doit attendre de vous d’avoir les infos sur le contexte afin de développer dans la bonne direction, conformément à votre vision et aux enjeux techniques. C’est la philosophie de la méthode SCRUM et de l’agilité, qui insiste sur l’implication des développeurs, dès la phase de conception du produit, afin que la vision de celui-ci soit partagée par tous.

Si vous êtes à une étape où votre équipe technique est réduite à 1 ou 2 développeurs, alors votre priorité est certainement d’aller vers un produit “testable et utilisable”.  Soyez alors réaliste sur la dette technique, sujet que nous abordons d’ailleurs dans notre étude de cas sur Cyconia.

Ceci étant posé, vous devez avoir une idée du type de profil qu’il vous faut. C’est là qu’intervient notre 2ème conseil !

Comme dans tout recrutement, la définition de la mission est primordiale pour éviter tout malentendu, autant pour vous que pour votre nouvel interlocuteur. Il est indispensable de prendre le temps de bien poser à plat les travaux attendus.

• • Agence studio dev ou freelance ?
    Bien souvent c’est l’une des première questions qui s’impose. Engager un freelance est la solution la moins coûteuse. Optez pour celle-ci si vous avez les compétences techniques suffisantes pour gérer ce type de profil et que vous savez exactement ce que vous voulez. Attention aux freelances qui peuvent quitter le navire du jour au lendemain !
    Privilégiez plutôt une équipe si votre projet requiert des compétences pluridisciplinaires et un temps long.

• • Se fonder sur les compétences ET le feeling !
    Construire une bonne relation honnête et transparente est primordial. La qualité des échanges est aussi importante que les compétences, car bien traduire ses besoins, c’est prendre les bonnes décisions techniques.
    Ses aptitudes à communiquer : car il y a une distance entre exprimer son besoin “fonctionnel” versus comment un développeur l’entend, le voit, l’interprète pour le produire.
    Son organisation pour gérer tous les échanges : car sinon il peut facilement se faire “noyer” dans la masse des infos et devenir improductif.
    Sa capacité à créer des limites : pour protéger sa capacité de production.

• • Regarder ses réalisations précédentes et le rôle qu’il y a tenu.
    Par exemple sur une app : il y a du front, du back, des fonctionnalités plus ou moins spécifiques (géolocalisation, stockage interne de l’app,…), il faut que ses travaux correspondent aux besoins de votre produit.
  • Sa capacité à être en perpétuelle veille technique

Savez-vous que vérifier l’ensemble des points précédents est précisément le rôle du Chef de produit digital ? Pensez-y si vous vous retrouvez dans une des situations suivantes :

• • “J’ai besoin d’un interlocuteur qui comprenne ma problématique métier, et de m’aider à réaliser la solution technique”
    
  • “Je ne comprends rien au dev, j’ai besoin de recul et d’un maître d’ouvrage pour rester objectif dans le développement de mon produit”
  • “Je veux pouvoir parler business et métier à mes interlocuteurs, sans comprendre les aspects techniques : il me faut un traducteur !”
  • “J’ai besoin de clarifier la solution technique souhaitée, et organiser les développements”

Vous avez le profil qu’il vous faut ? Il est temps de vous conseiller sur la façon de poser le cadre de travail : la vision.

Reprenons nos analogies 😉 Que serait une équipe de foot sans capitaine ? Une armée sans colonel ?

Vous l’aurez compris : vous aurez beau avoir les meilleurs développeurs dans votre équipe, ils ne pourront pas l’exprimer s’ils ne sont pas guidés correctement.

En ce sens, il est primordial d’avoir un guide capable de parler leur langage – le langage technique – pour coordonner le travail des devs, étape par étape, de façon agile.

Décider quelle fonctionnalité sera développée prioritairement, laquelle génèrera des revenus, laquelle sera la plus utile pour vos clients ; comme, inversement, celle qui n’a pas vraiment d’intérêt, doit être le fruit du dialogue entre vos dev et l’équipe business au contact de vos utilisateurs et clients. 

Pour gérer ce dialogue, ce n’est pas d’un développeur dont vous avez besoin, mais des compétences d’un maître d’ouvrage. 

Il y a 2 postures dans la maîtrise d’ouvrage : 

• • N°1 : la posture de l’exécutant.
    Sans feedback, ni dialogue, étant donné que les demandes de développement émanent la plupart du temps de l’équipe business, qui maîtrise peu, ou pas, les enjeux techniques. Si le développeur “exécute” la demande sans questionner, sans proposer des alternatives, vous allez au devant de difficultés… Eh oui, on vient de le dire : les enjeux techniques n’auront pas été challengés ! 
  • N°2 : la posture du challenger.
    Il conçoit la maîtrise d’ouvrage comme dans le secteur du BTP. Le maître d’ouvrage apporte de la distance critique, il connaît “l’état de l’art”. Il propose des alternatives et sait partager ses enjeux techniques.

Ce que vous devez accepter, c’est que même le plus brillant des CEO doit savoir être challengé par un développeur qui n’est pas un pur exécutant mais qui adopte les approches d’un maître d’ouvrage, sachant développer une posture critique au service du business.

Dans la conduite d’un projet digital, il peut s’avérer difficile de maintenir l’équipe de développement et l’équipe business alignées sur un même objectif. C’est pourquoi il est nécessaire d’associer à la fois les développeurs et l’équipe business à la conception du produit. Pour cela, rien de tel qu’une vision produit claire, dès le départ. À ce titre, notre cahier de vision,que nous mettons à votre disposition, peut vous être très utile !

L’objectif ? Définir les priorités de développement de votre produit, ce qui constitue une des clés du succès d’une entreprise aujourd’hui. 

Ces priorités sont établies comme suit : 

Hypothèses de produit / Fonctionnalités -> Mise en place -> Mesure -> Apprentissage & réaction / ajustement.  

C’est en partant de ces informations que vous pourrez prendre les bonnes décisions, fort de la compréhension fine de vos utilisateurs et de votre marché cible. 

Si vos développeurs comprennent pourquoi et pour qui ils développent un projet : bravo ! Votre équipe sera plus efficace car chaque ligne de code sera mieux réfléchie.