Les startups logicielles ont aujourd'hui un avantage significatif sur celles d'il y a cinq à dix ans, en partie à cause de la prolifération de fournisseurs d'hébergement cloud hyperscale comme Google Cloud Platform (GCP), Amazon Web Services (AWS) et Microsoft Azure. Avec une pléthore de services gérés disponibles en un clic, ils peuvent rapidement prototyper leur solution et la commercialiser en un temps record et à une échelle presque infinie. Bien que cela puisse sembler plus simple aujourd'hui, la préparation d'une startup pour la mise à l'échelle sur le cloud demande toujours une attention particulière.

J'ai la chance d'avoir fait partie de diverses organisations technologiques pendant plus de vingt ans, des start-ups amorcées, aux sociétés financées par du capital-risque et du capital-investissement, et même des conglomérats mondiaux avec des introductions en bourse. En apprenant de tant de personnes talentueuses et de mentors en cours de route, je « sélectionne » les leçons apprises, les outils, les techniques et les processus à mettre en œuvre.

Dans un effort pour « donner au suivant », j'aimerais partager quelques leçons apprises. Ce premier article de la série présentera des concepts et des ressources que je trouve utiles pour créer et faire évoluer des startups logicielles. Dans le deuxième article , nous allons concevoir une startup fictive de rencontres en ligne pour illustrer comment ces pièces s'emboîtent. Dans le troisième article , nous illustrons comment ils informent finalement votre architecture cloud à l'aide de GCP.

• Partie 1 : contexte et introduction à la méthodologie
• Partie 2 : mise en place de méthodologies avec startup fictive
• Partie 3 : concevoir et faire évoluer l'infrastructure cloud

Début 2020, j'ai décidé d'essayer quelque chose de nouveau; Au lieu de créer et de développer des startups de logiciels, j'ai commencé à les conseiller et à les soutenir en rejoignant un partenaire cloud avec des racines en Israël nommé DoiT International . Notre entreprise est entièrement distante et est depuis passée d'environ 50 personnes à près de 500 dans le monde en un peu plus de deux ans, supportant plus d'un milliard de dollars de consommation annuelle de cloud. Je suis constamment émerveillé par la façon dont nous avons préservé notre culture grâce à une croissance aussi rapide tout en attirant et en retenant autant de personnes talentueuses.

Des milliers d'organisations choisissent DoiT comme partenaire de services cloud. Ils bénéficient de conseils et d'une assistance gratuits, ainsi que d'outils logiciels de pointe conçus pour tenir la promesse initiale du cloud : concentrez-vous sur votre produit et vos clients, et ne vous souciez pas du reste. Bien que nous aimerions penser que c'est aussi simple, cela est généralement précédé par nos clients disposant d'équipes techniques hautement qualifiées.

Une tendance que j'ai récemment remarquée est la croissance des startups logicielles à un stade précoce adoptant la technologie cloud qui peuvent ne pas avoir de grandes équipes ou une expertise cloud profonde. En tant qu'entrepreneur en logiciels moi-même, j'espère que le partage des leçons apprises à la fois de ma «vie passée» et de DoiT rendra votre voyage encore plus réussi.

Les premiers jours

En nous éloignant de la technologie, explorons d'abord le cheminement depuis l'identification d'un problème jusqu'à la création d'une entreprise dédiée à sa résolution, et au-delà. Il existe des méthodologies et des cadres populaires au-delà des meilleures pratiques cloud que vous apprécierez peut-être à mesure que votre organisation mûrit.

Chaque technique illustrée ci-dessus est elle-même itérative , mais comme nous le verrons dans le prochain article de cette série, la sortie de chacune informe les autres.

TL ; DR ; Ressources en ligne utiles

Plutôt que d'expliquer les techniques et les concepts ci-dessus, je recommande de regarder ces vidéos pour combler les blancs et nous servir d'amorce pour les mettre en action.

• Dois-je créer une startup (14 min)— Michael Seibel, Y Combinator
• Stratégie vs planification (9 min) - HBR [utilisez un plan d'une page comme OGSM]
• Résumé Lean Startup (13 min)— Eric Ries
• Valider son idée d'entreprise (9 min)— Eric Ries
• Lean UX (60 min)— Jeff Gothelf
• Utilisation du canevas Lean UX (15 min)— Jeff Gothelf
• Produit de construction (59 min)— Michael Seibel, Y Combinator
• Comment planifier un MVP (13 min)— Michael Seibel, Y Combinator
• Cartographie des histoires d'utilisateurs (50 min)— Jeff Patton
• Guide ultime de la cartographie des histoires d'utilisateurs — Nick Muldoon, Easy Agile
• Architecture logicielle avec le modèle C4 (35 min)— Simon Brown
• Construire une culture d'expérimentation chez Spotify (47 min)— Ben Dressler
• DevOps contre SRE (44 min)— Seth Vargo, Google

Une fois que vous avez identifié un problème que vous vous sentez obligé de résoudre, il est utile de brosser un tableau de l'endroit où vous vous dirigez et de certains indicateurs clés que vous êtes sur la bonne voie pour apporter de la valeur. Ceci est similaire à la façon dont Amazon a demandé aux équipes de rédiger le communiqué de presse décrivant ce qu'elles construisaient à l'avenir, avant qu'elles ne soient approuvées pour le construire.

Il y a environ 10 ans, lors d'une session de planification d'une journée, un mentor qui avait introduit son entreprise en bourse, puis l'avait vendue à Oracle pour près de 2 milliards de dollars, m'a présenté le cadre OGSM . Il représente les objectifs, les buts, les stratégies et les mesures. Cela vous oblige à brosser un tableau concis de l'endroit où vous serez dans 3 à 5 ans, des objectifs mesurables en cours de route, tout en approfondissant les stratégies et les tactiques à court terme pour les atteindre.

Vous vous retrouvez avec un plan d'affaires d'une seule page, un document vivant que vous revisitez et affinez, autour duquel toute l'équipe peut se rallier et aligner l'orientation de toutes les activités. Par exemple, si une activité ne correspond pas à une stratégie définie pour atteindre un objectif, vous vous demandez si cela en vaut vraiment la peine ou si vous mettez à jour votre stratégie.

Certains peuvent se demander quelle est la différence par rapport à un autre cadre populaire Objectifs et résultats clés (OKR). OGSM envisage des années dans le futur, tandis que OKR se concentre principalement sur des objectifs à court terme. Selon le stade de votre entreprise, l'introduction d'OKR peut avoir du sens, mais souvent une seule vision à plus long terme derrière laquelle tout le monde peut se rallier est celle nécessaire "North Star".

Il existe de nombreuses autres techniques telles que l'analyse SWOT, les 5 forces de Porter, le tableau de bord équilibré ou les 3 horizons de McKinsey, qui peuvent alimenter votre plan stratégique global, mais OGSM reste mon outil personnel de référence pour réduire l'attention d'une équipe sur ce qui compte et partager le plus grande vision.

Idéation

Les principes directeurs et les processus au début de votre parcours peuvent aider à aligner les équipes au fur et à mesure de votre croissance. Je crois qu'une culture axée sur les données et un état d'esprit de tout mesurer doivent faire partie de votre culture et venir du plus haut niveau, et se manifester dans chaque interaction.

Quelques-unes de mes ressources préférées qui renforcent cette culture expérimentale incluent Lean Startup (et le Lean Canvas) d'Eric Ries et Lean UX de Jeff Gothelf. Presque tous les conseillers et incubateurs de startups conseillent aux fondateurs de tout mesurer, d'itérer rapidement et de créer un produit minimum viable (MVP) pour tester leur idée par rapport au marché. Tout cela résonne avec les principes « Lean ».

Jeff Gothelf prend les principes "Lean" dans une direction que j'aime parce qu'il s'applique à chaque équipe, département et idée dans les organisations de toutes tailles. La prémisse est "nous ne savons rien" et afin d'apprendre [ce que les clients veulent], et ce qui résout vraiment un problème, nous appliquons la méthode scientifique - formons une hypothèse, testons-la tout en mesurant, analysons les résultats et corrigeons le cours si nécessaire . La valeur de cette approche est de minimiser les efforts inutiles et de valider que vous résolvez les bons problèmes plus rapidement.

Concevoir

Lorsque je vois des gens négliger de documenter leurs systèmes et leur architecture logicielle, cela me rappelle quelqu'un essayant de construire une maison avec un tas de bois. Bien sûr, vous pouvez éventuellement le comprendre, mais vous seriez beaucoup plus rapide avec moins d'erreurs si vous aviez un plan. Deux de mes techniques préférées pour la conception de produits incluent la cartographie des histoires d'utilisateurs et le modèle C4 .

En écrivant les choses, vous assurez une compréhension partagée et tenez chacun responsable de la livraison de ce qui a été convenu.

Il y a quelques années, j'ai été invité en tant que conférencier au sommet annuel CTO pour la société de capital-investissement (PE), Francisco Partners . J'ai assisté à d'autres sessions et l'une des plus intrigantes était l'un des partenaires conseillant d'autres CTO et cadres du portefeuille sur le suivi des mesures dans leurs organisations de produits. L'une des mesures qui m'a surpris, mais qui a maintenant tout à fait du sens, consiste à mesurer la quantité de retravail pour évaluer l'efficacité des chefs de produit. Depuis, j'ai demandé à d'autres leaders de l'ingénierie s'ils mesuraient les retouches, et la plupart l'apprécient mais ne le font pas encore.

La refonte est une mesure clé sur laquelle vous pouvez avoir un impact en prenant le temps de comprendre le client et de lui donner la priorité en lui offrant la valeur la plus immédiate. C'est exactement ce que l'exercice de cartographie des histoires d'utilisateurs aide à faciliter tout en forçant la collaboration entre les différentes parties prenantes. Mon argument en faveur de cela, à n'importe quelle étape de l'entreprise, est qu'il est beaucoup moins cher et plus rapide de déplacer quelques cases sur un tableau blanc partagé que de lancer des cycles de développement qui entraînent plus tard des retouches.

Je suis le premier à admettre que j'ai eu des diagrammes d'architecture laids dans ma journée; J'en ai été témoin encore plus. Il est important de prendre le temps d'écrire votre architecture et sa relation avec d'autres systèmes. Le modèle C4 est l'un des meilleurs moyens de le faire de manière standard sans nécessiter de connaissances UML. Comme décrit dans les liens vidéo ci-dessus, la pratique standard consiste à concevoir jusqu'à 3 niveaux de profondeur (vue des composants). Il existe des produits tels que IcePanel qui facilitent cela, ou divers plugins ou outils sur d'autres plates-formes. C'est plus rapide que vous ne le pensez, et nous l'illustrons dans le prochain article de cette série.

Construire

Supposons que votre équipe maîtrise bien cette phase. Au fur et à mesure de votre croissance, l'adoption d'un cadre bien défini pour mettre en œuvre les idéologies Agiles peut vous aider à évoluer. Si vous suivez les principes « Lean » et modifiez vos priorités en fonction de l'apprentissage, vous êtes déjà sur la bonne voie. Alors que l'organisation passe de la vitesse et de l'innovation à la croissance et à la stabilité, soyez conscient des points d'inflexion et de la composition de l'équipe en cours de route.

Opérationnaliser

En plus de faire mûrir vos pratiques de développement de produits, vous souhaiterez également maintenir une culture de responsabilité partagée. C'est là que les principes DevOps entrent en jeu. Google a partagé sa mise en œuvre de DevOps appelée Site Reliability Engineering (SRE), et de nombreuses organisations ont adopté ces pratiques.

Bien qu'il ne soit pas nécessaire d'avoir une équipe ou une fonction distincte, la dotation minimale d'équipes avec des ingénieurs qui ont une propension aux opérations, à la surveillance et à l'automatisation sera payante. Nous explorerons ces concepts plus en détail lorsque nous approfondirons l'exemple de startup et définirons son architecture et son infrastructure cloud.

Planification de la croissance

À mesure qu'une startup grandit au-delà de la petite équipe fondatrice, la complexité de la communication et de la gouvernance augmente également, comme illustré ci-dessous.

Les entreprises ont résolu ces défis de mise à l'échelle en reconnaissant les points d'inflexion de leur activité et en formant des équipes dédiées, pour la plupart autonomes, pour relever des défis spécifiques.

Une excellente ressource sur la mise à l'échelle de votre équipe logicielle, par exemple, est cet article de blog de Seth Blank , que je recommande vivement de lire. Blank avertit que les processus, et dans certains cas même les personnes, qui ont contribué au démarrage de l'entreprise peuvent à un moment donné devenir un obstacle à sa croissance et à son évolutivité futures, ou sont mieux orientés vers "la prochaine chose". C'est là que les 3 horizons de McKinsey deviennent pertinents pour la planification stratégique future. À l'inverse, un autre Blank, Steve Blank, explique pourquoi il n'est plus valable aujourd'hui .

Il existe une autre ressource appelée « Topologies d'équipe » qui fournit un modèle adaptatif pratique, étape par étape, pour la conception d'organisation et l'interaction d'équipe. L'accent est mis sur la rationalisation de l'organisation et de la plate-forme, avec ce qu'ils appellent la plate-forme viable la plus mince (TVP).

Un autre concept que je trouve utile pour faire évoluer une organisation ou un produit est AKF Partners Scale Cube . J'ai appris cela pour la première fois il y a de nombreuses années lorsqu'il a été référencé dans un livre intitulé « L'art de l'évolutivité » que j'ai acheté pour mes chefs d'équipe lors d'un démarrage antérieur - c'est aussi une autre référence utile à tout moment, sautant aux chapitres pertinents si nécessaire.

Presque tout le monde peut être d'accord, cependant, à mesure que votre entreprise continue de croître et forme des équipes dédiées, la nécessité d'une gouvernance et de processus bien définis, de documentation, de mentorat et de formation grandit avec elle. J'ai vu récemment de nombreuses organisations à ce stade chercher également des conseils sur la meilleure façon de structurer leur infrastructure cloud pour accueillir efficacement leurs multiples équipes. Nous en parlerons plus tard dans cette série.

Dans la partie 2 de cette série , nous explorons l'assemblage de ces pièces pour concevoir, construire et faire évoluer une startup fictive de logiciel de rencontres en ligne.

Merci d'avoir lu jusqu'ici, et j'espère que vous apprécierez la partie 2 .