Timlid dans une startup - à la fois, et Elon Musk et Frankenstein. Le matin, il construit des vaisseaux spatiaux et le soir, il lance au projet un cri: «Vivez! Tu ne dois pas mourir! - et rit malsain. Et tout cela en compagnie de trois juniors.
Alexander Polomodov dirige le développement de la gestion des attractions à Tinkoff.ru; Il était auparavant directeur technique / directeur du développement pour les petites entreprises. Nous avons demandé à Alexander de se souvenir du passé et de dire quels pièges on peut attendre d'un chef d'équipe venant dans une startup.
Under the cut - réponses à des questions importantes:
- comment survivre dans des conditions où les processus d'interaction ne sont pas établis (ou n'existent pas du tout);
- comment constituer une équipe sympa lorsque la masse salariale est limitée;
- comment comprendre que vous devez vous échapper du projet.
1. Plein d'idées, personne à faire
Vous venez teamlide dans une startup. Attente: commencez immédiatement à travailler sur de nouvelles fonctionnalités. Réalité: Hunt développeurs, car une équipe solide est nécessaire hier, et personne ne s'est soucié de l'assembler.
Deux options sont possibles ici - plus lourdes et plus légères. Une option douloureuse: il y a peu d'argent dans la PHOT. L'une des meilleures décisions dans cette situation est de prendre les stagiaires avec une tête propre et brillante, et de mettre toutes les connaissances et compétences nécessaires dans cette tête: dessiner pour chaque individu un plan de développement individuel, décrire étape par étape quelles connaissances il devra acquérir, quelles compétences dans quel ordre se développer. C'est un excellent moyen, mais, malheureusement, ce n'est pas le vôtre: c'est un long jeu, et les startups qui doivent afficher rapidement des résultats ne le font presque jamais.
Une phrase caractéristique: «Nous avons besoin des meilleurs spécialistes en angulaire. Nous payons en dessous du marché. "
L'option la plus simple: il y a de l'argent et vous êtes prêt à offrir de bonnes conditions de marché.
Un cas typique. Dans ce cas, une pratique courante dans les sociétés informatiques consiste à exposer l'exigence de base pour qu'un candidat connaisse une pile technologique spécifique. Il y a quelques années, dans les descriptions de poste, «nous recherchons un ninja jQuery» apparaissait constamment. Le problème est que beaucoup de ces ninjas semblent avoir quitté le lit de Procrustean - ils ne peuvent écrire qu'en jQuery (n'est-ce pas dans le nouveau projet? Eh bien, je suis désolé). Et si une personne connaît non seulement parfaitement la pile spécifique, mais a également une bonne base, alors une entreprise tuera probablement votre offre de salaire.
Solution. Lorsqu'il y a de l'argent pour des salaires adéquats, vous devez rechercher des personnes, en vous concentrant sur la présence de connaissances fondamentales et de compétences durement acquises comme la pensée systémique. Même si une personne n'est pas familière avec un langage ou une technologie spécifique, elle maîtrisera toutes les principales choses du trimestre si elle le souhaite.
Lorsque vous ne pouvez pas concourir pour les meilleurs spécialistes en termes de salaire, il vaut la peine d'embaucher des gens avec une tête brillante qui ont en vain choisi une sphère. Un homme a conçu des microcircuits et a maintenant décidé de changer la zone en une zone plus monétaire? Nous le prenons.
2. PDG de Narnia
La deuxième difficulté qu'un chef d'équipe peut rencontrer dans une startup est les lunettes roses PDG. Les plans qui ont déjà été soumis aux clients ou aux investisseurs ne correspondent pas à la réalité. L'équipe est pressée en fonction des délais, elle doit afficher rapidement MVP, ajouter des fonctionnalités, tout en fixant constamment des délais irréalistes. De nouvelles et nouvelles couches du code béquille se développent, la dette technique s'accumule et le créateur de la startup est sûr que tout est en ordre - les développeurs sont des prévisions pessimistes paresseuses ou exprimées.
Cette situation se produit souvent avec le directeur des ventes. Il avait déjà vendu le château dans les airs - et comment construire ce château maintenant, il ne s'en soucie pas vraiment.
La phrase caractéristique: «J'ai vendu ces fonctionnalités, elles devraient apparaître d'ici la fin de la semaine, du mois, de l'année» (souligner si nécessaire).
Un cas typique. Le PDG veut une version dans trois jours, le développeur évalue la tâche et dit au chef d'équipe ce qu'il peut faire en cinq. Explique: «L'API avec laquelle vous devez travailler a longtemps été intégrée. Si l'API fonctionne comme promis par le partenaire, je l'obtiendrai dans trois jours. Mais, d'après mon expérience, l'API de ce partenaire ne tient souvent pas ses promesses, donc - cinq jours. " Le PDG répond: «Le partenaire promet que tout ira bien. Vous avez trois jours », déclare le CTO après la réunion:« Je ne comprends rien au développement, mais j'ai presque divisé par deux l'évaluation de la tâche. »
Le développeur de cette affaire a essayé et terminé la tâche en quatre jours. Quoi qu'il en soit, le fakap s'est produit, mais même s'il avait respecté les délais, il ne pouvait pas durer longtemps, c'est l'étape finale de l'incompréhension du fonctionnement d'une équipe normale et saine.
Solution. Il est normal de discuter du calendrier, mais cela devrait être une discussion raisonnée. Le style de Tony Robbins répond: "Une semaine, c'est trop long!" et "Vous devez essayer plus fort!" - indicateur de verres roses. Les supprimer est un test sérieux des compétences en communication du chef d'équipe.
Il ne s'agit pas de faire baisser le prix en négociant, comme dans un bazar où il y a un coût et une marge inférieurs qui sont distribués dans un jeu à somme nulle entre le vendeur et l'acheteur. Il présente une solution d'ingénierie que vous souhaitez évaluer, en tenant compte de facteurs supplémentaires. Le développeur ne négocie pas pour lui-même cinq jours de travail, mais donne une évaluation basée sur ses connaissances. Si la pression est bonne, cela réduira le temps, mais très probablement, cela réduira tous les risques. Et quand quelque chose se passe mal, les plans iront certainement. C'est ce qui est important à transmettre au PDG, et si vous ne voulez pas comprendre, fuyez, idiots.
3. Dette technique à intérêt de microcrédit
L'histoire de la création d'OS / 360, décrite dans le livre «Mythical Man-Month» de Frederick Brooks, est très révélatrice. C'était censé être le système d'exploitation le plus cool de l'époque. IBM a attiré des milliers de personnes dans le cadre du projet et est toujours absent sur tous les plans: calendrier, fonctionnalités et capacités d'assistance.
D'après le livre de Brooks, il est clair qu'alors les développeurs ont marché sur tous les râteaux possibles, et cela malgré le fait qu'ils utilisaient Waterfall et représentaient clairement les étapes de développement. Et aujourd'hui, avec la diffusion généralisée d'Agile, l'équipe et le plan architectural à long terme ne l'ont souvent pas - seulement un backlog composé de tâches métier et d'un sprint d'une à deux semaines. L'architecture en sort donc correspondante.
Phrase caractéristique: «Repeindre ce bouton en bleu? Cela prendra une semaine
Conditionnellement, si la construction de trois appartements est prévue au premier sprint, alors au second sprint une cabane ou une cabane est en cours de construction à proximité. Vient ensuite une nouvelle tâche - les recouvrir d'un toit commun, et s'il s'agit d'un toit installé, il s'avère qu'il y aura un autre étage au-dessus et ainsi de suite.
Lorsqu'une vraie maison se serait effondrée depuis longtemps sous le poids des erreurs du designer, une dette technique se forme dans le développement. Et si au début le travail sur le projet se déroule comme prévu et que personne ne voit les béquilles déployées, il se trouve qu'à un moment donné, une fonctionnalité simple, qui coûtait au départ la journée du développeur, prend désormais deux fois plus. Et comme vous devez faire le tour des béquilles encore et encore et en ajouter de nouvelles, dans un quart, la fonctionnalité coûtera cinq fois plus.
Solution. Un leader normal prend des décisions basées sur des faits et des chiffres. Venez avec les calculs: montrez combien coûtera la dette technique ouverte en un mois, en un trimestre, en un an. Ainsi, vous aurez la possibilité d'ajuster les plans, y compris dans les sprints non seulement de nouvelles fonctionnalités, mais aussi un "paiement des dettes" par étapes.
Bien sûr, ce n'est pas une liste exhaustive des problèmes que rencontrent les teamlids dans les startups, mais ces trois sont les plus aigus et les plus difficiles à résoudre.
Alexander Polomodov - conservateur du
Teamlead Weekend intensif dans le district binaire; le prochain cours aura lieu du 15 au 16 décembre.