Dans la partie 1 de cette série , nous avons exploré des méthodologies et des cadres que je trouve utiles pour créer et développer des startups logicielles. Le but de cet article est d'illustrer comment vous pouvez appliquer ces techniques pour minimiser les efforts inutiles et comment la planification de votre entreprise de logiciels se traduit par votre infrastructure cloud.

Prérequis pour avancer

• Vous avez lu la partie 1 de la série
• Vous connaissez les frameworks/méthodologies que nous explorons ci-dessous en regardant les liens vidéo partagés dans la partie 1

Le diagramme ci-dessus illustre les concepts clés des méthodologies susmentionnées. Pour cet article, nous allons nous amuser à inventer une startup fictive de rencontres en ligne, et à la "faire évoluer". Nous illustrerons l'application de ces principes et la relation entre la stratégie de l'entreprise, les produits et les besoins de croissance, et comment ils informent la conception de notre infrastructure cloud.

Identifier le problème que nous résolvons et pour qui

Supposons que vous et les autres en ayez marre d'être seuls et que les solutions existantes ne suffisent pas. Vous avez été à des mariages, trop en fait, et vous avez été dans des bars, et même essayé des applications populaires, mais vous avez toujours l'impression qu'il manque quelque chose. Vous êtes passionné par ce problème et croyez que vous êtes l'équipe qui aide à résoudre la solitude des gens, y compris la vôtre. Analysons d'abord les stratégies potentielles d'autres solutions.

Clause de non-responsabilité

Je n'ai jamais utilisé d'application de rencontres en ligne, je ne fais donc que "deviner" quelles caractéristiques et fonctionnalités elles incluent. En utilisant ce qui est à la télévision ou dans les gros titres sur diverses applications populaires, nous pouvons prétendre créer un concurrent. Si mes hypothèses sont loin, ou si nous n'explorons pas chaque type de relation, je vous demande de suspendre l'incrédulité pour illustrer ces concepts .

eHarmony

Ce service avait une théorie selon laquelle en appariant sur la base d'un profil de personnalité scientifique, les gens se sentiraient moins intimidés. Leur stratégie consiste à faire de la personnalité le facteur principal, ils attireront des personnes moins confiantes dans leur apparence qui se sentent encore seules, en capitalisant sur un marché inexploité.

tinder

Ce service avait une théorie selon laquelle de nombreuses personnes étaient seules, mais ne recherchaient pas de relations à long terme. Leur stratégie était de remplacer les connexions occasionnelles et de capturer cette partie du marché.

Bourdon

Ce service avait une théorie selon laquelle les femmes se sentiraient plus à l'aise sur une plateforme si elles pouvaient choisir avec qui elles s'engagent. Leur stratégie consistait à laisser les femmes décider d'envoyer ou non le premier message après un match.

eTumble — NOUVEAU !

Notre hypothèse est que les gens sont seuls et que les solutions sur le marché n'ont pas encore résolu la solitude à l'échelle mondiale . Nous croyons que la solution gagnante est une combinaison des trois ci-dessus. Nous soupçonnons qu'au fond, les personnes à la recherche de rencontres occasionnelles préféreraient avoir une chance d'établir une connexion personnelle plus profonde via une correspondance de personnalité initiale, mais les femmes font le choix d'interagir ou non.

Les pratiques Lean Startup conseillent de fonctionner comme une « grande expérience », de faire des hypothèses audacieuses , puis d' observer (et non de demander) les comportements des utilisateurs, tout en itérant rapidement. Nous débusquons souvent des idées à l'aide d'un canevas "Lean" , mais nous supposerons que notre équipe l'a déjà fait ci-dessus. Commençons!

Commencer par une vision et une stratégie

Analyse SWOT

En reconnaissant à la fois les forces internes (forces, faiblesses) et externes (opportunités, menaces), vous pouvez tirer parti d'une analyse SWOT pour mieux identifier ce qui doit se produire pour réussir.

Cette analyse éclaire la conception de votre produit lorsque vous testez des hypothèses sur la résolution des hauts et des bas inévitables. Par exemple, si le taux de désabonnement élevé des utilisateurs est une menace, vous pouvez donner la priorité aux fonctionnalités qui incitent les gens à revenir sur votre plate-forme. Étant donné qu'une faiblesse était un manque d'expérience en psychologie dans l'équipe, vous savez, lors de l'embauche ou de l'attraction de conseillers, qui cibler. Si l'équipe a une expérience limitée avec les applications concurrentes, vous savez qu'une tâche consiste à les utiliser et à organiser des rendez-vous - une victoire, une victoire.

Définir le plan stratégique initial à l'aide d'OGSM

À un stade précoce, votre objectif sera de lancer rapidement un produit minimum viable (MVP) pour commencer à observer le comportement des utilisateurs et à tester des hypothèses de manière itérative. Dans le monde du logiciel, nous plaisantons souvent en disant que les prototypes deviennent toujours de la production, malgré nos meilleures intentions. Investir quelques jours pour réfléchir avec votre équipe afin de documenter les stratégies et les mesures peut réduire les reprises et accélérer la conception et le développement de votre produit. Voyons comment ci-dessous.

Remarquez que dans l'exemple OGSM ci-dessus, nous commençons déjà à identifier notre future équipe, nos produits, nos métriques et nos besoins en infrastructure. Nous aurons besoin d'une expertise dans les applications mobiles, l'apprentissage automatique et le développement d'API. Nous aurons également besoin de traduction linguistique, d'obscurcissement du texte et des images et de l'acceptation des paiements en ligne. Pour un public mondial, nous devons respecter les exigences réglementaires et de confidentialité, en particulier dans l'Union européenne.

UX allégée

Lean UX est mieux connu des équipes produit, c'est là que l'auteur Jeff Gothelf a fait ses modestes débuts. Je pense que l'efficacité de la communication d'idées via des énoncés d'hypothèses justifie une prise de conscience dans toute l'organisation et pas seulement dans les équipes de produits. Je pense que Lean UX appartient à la stratégie et à la vision et est utilisé partout.

Chaque stratégie, et par la suite tactique (fonctionnalité), dans le plan OGSM ci-dessus est essentiellement une hypothèse. Plus nous formulons nos idées dans cette structure, plus elles deviennent exploitables et ciblées. Par exemple, la stratégie selon laquelle nous atteindrons nos objectifs en "fournissant un lieu d'interaction plus sûr" pourrait être formulée comme suit :

"Nous pensons que [des millions d'utilisateurs] rejoindront notre service si [les femmes] [se sentent plus en sécurité pour interagir] avec [seules elles choisissent d'engager une conversation après les matchs]."

Cela se traduit en gros par "Nous pensons que [le résultat commercial] sera atteint si [l'utilisateur] atteint [l'avantage] avec [la fonctionnalité]". comme décrit dans le canevas Lean UX. J'intervertis parfois ce format avec un autre défini dans les principes agiles de « Product Discovery », mais le principe est le même : une communication structurée .

Vous pouvez voir la nature itérative de ces méthodologies lorsque vous les combinez. Si vous ne l'avez pas déjà fait, je vous encourage à revoir les vidéos sur Lean UX dans la partie 1 de cette série .

La conception des produits

En ce qui concerne les principes «Lean», une fois que vous avez des hypothèses ou des hypothèses audacieuses sur le problème que vous résolvez, pour qui vous le résolvez et comment vous avez l'intention de le résoudre, vous devez rapidement les itérer et les tester.

Plutôt que de demander aux utilisateurs, il est toujours préférable d' observer leur comportement pour valider vos hypothèses, c'est pourquoi il est recommandé de lancer un MVP. Dans un produit en direct, vous pouvez également tirer parti des outils de test A/B ou proposer des indicateurs/bascules.

Nous n'avons pas besoin de toutes les fonctionnalités éludées dans notre OGSM immédiatement pour tester nos théories, mais nous avons maintenant une compréhension globale de la direction que nous prenons. Ensuite, nous donnons la priorité à ce que notre MVP doit offrir pour maximiser la valeur utilisateur au fur et à mesure que nous itérons rapidement par la suite. Pour cela, nous allons tirer parti de User Story Mapping .

Cartographie des histoires d'utilisateurs

Ce que vous voyez ci-dessus est déjà la version six ! En partant d'une vue holistique, j'ai rapidement cartographié le parcours utilisateur global. J'ai ensuite mélangé les boîtes et repriorisé les histoires d'utilisateurs pour identifier la plus petite quantité que nous pouvions fournir pour tester les résultats souhaités pour le public cible.

Au fur et à mesure que vous testez des hypothèses, vous appliquez vos découvertes et continuez à éditer ces «documents vivants» de manière agile, plutôt que de perdre du temps sur des spécifications détaillées stagnantes.

Architecture du modèle C4

Nous disposons désormais d'informations pour nous aider à définir notre architecture logicielle et système, mais le faire de manière standardisée est souvent négligé. Assurez-vous d'avoir un plan (ou un plan) de ce que vous construisez pour communiquer efficacement avec les autres parties prenantes. Bien qu'UML reste une norme de longue date, le modèle C4 plus léger est ce que je recommande aujourd'hui.

Pour la brièveté de cet article, nous allons illustrer un exemple partiel de notre architecture pour eTumble. Bien qu'il y ait 4 niveaux à C 4 , la pratique standard est d'illustrer seulement aussi profondément que nécessaire; le niveau « Code », qui serait effectivement la notation UML, est généralement ignoré.

Comme indiqué dans mon avertissement ci-dessus, il s'agit d'une application fictive et je n'ai jamais utilisé de service de rencontres en ligne. Ce sont donc des suppositions éclairées pour illustrer le processus.

Souvent, je commence à esquisser des idées sur papier pour réfléchir à la conception. Une fois qu'il y a une idée générale de ce qui est nécessaire, je liste les éléments de l'architecture pour débusquer les détails. Par exemple, nous savons que nous aurons besoin d'une base de données, mais notre stratégie implique un jeu global. Nous devons décider si nous pouvons commencer avec Postgres ou MySQL pour le lancement, et à quel point il peut être difficile de migrer vers un système distribué comme Cockroach DB ou Cloud Spanner de GCP.

Connaissant parfois le "blocage de l'écrivain" en regardant des cases et des lignes sur un écran, je trouve que l'utilisation d'une feuille de calcul comme ci-dessous facilite le déplacement d'éléments ou l'insertion de lignes lorsque je pense à plus de choses, avant de créer des diagrammes.

Dans certaines applications, vous pouvez simplement copier/coller comme dans IcePanel , illustré ci-dessous. Il existe un support pour Markdown, qui est encore plus rapide une fois que vous êtes familiarisé.

J'espère que cela montre à quelle vitesse vous pouvez transférer ce que vous avez écrit dans un outil de création de diagrammes - en prenant moins d'une heure pour produire de beaux diagrammes. Imaginez que vous vous engagez avec des concepteurs et des ingénieurs avec les conceptions ci-dessus, et à quel point elles seraient plus rapides (et moins chères).

Faire évoluer les choses

Les allusions antérieures selon lesquelles nous allions « le mettre à l'échelle » signifiaient que nous anticipions nos besoins futurs en fonction de notre plan stratégique et de notre vue d'ensemble illustrée dans la carte de l'histoire. J'ai mentionné précédemment l' AKF Scale Cube et, en appliquant ses principes d'axes xyz, j'ai conclu que notre échelle mondiale et des dizaines de millions d'utilisateurs auront besoin d'une conception sans état, d'un système piloté par les événements, d'une architecture de microservices et éventuellement de plusieurs équipes, avec un hébergement couvrant plusieurs régions géographiques sur une plate-forme de cloud public.

• Notre axe des x ( duplication et évolutivité horizontale ) est pris en charge par les applications conteneurisées sans état et l'hébergement dans le cloud public.
• Notre axe y ( spécialiser ) est pris en charge par des microservices spécialement conçus, déclenchés soit par HTTP/RPC, soit par des messages Pub/Sub. Ceux-ci aident également à définir comment vous développerez probablement vos équipes, permettant à l'autonomie et au couplage lâche de posséder une valeur clé dans le système ; cela s'aligne souvent sur l'UX de base illustrée dans la Story Map.
• Notre axe z ( répartir les choses similaires ) est pris en charge par la régionalisation. Nous n'abordons pas cela entièrement dans notre exemple fictif. Supposons, compte tenu de la stratégie mondiale, que les contraintes juridictionnelles sur les systèmes et la souveraineté des données, les devises étrangères, les langues et les futures stratégies de mise sur le marché des ventes par canaux (GTM) puissent toutes influencer la façon dont nous étendons cet axe. Cela pourrait même être basé sur l'endroit où nous trouvons/offrons des talents pour notre équipe, ou même, comme le décrit "Team Topologies", la charge cognitive de l'équipe.

Ce que nous avons appris et construit jusqu'à présent :

Temps passé jusqu'à présent à concevoir eTumble, notre startup fictive de rencontres en ligne :

• Lean [Démarrage | UX] canevas - nous ne l'avons pas illustré, mais normalement c'est le point où vous commencez à écrire quel problème vous résolvez, pour qui vous résolvez et les avantages/valeurs que vous offrez. Vous pouvez valider votre idée avec un « MVP smokescreen » et une page de destination, par exemple. Regardez les vidéos de la partie 1 pour en savoir plus.
• Analyse SWOT - nous avons identifié les points positifs que nous voulions exploiter et les points négatifs que nous devons résoudre, informant notre plan OGSM. (30 min; prévoir plusieurs heures)
• Plan OGSM — nous avons identifié les fonctionnalités clés, les technologies, les mesures et l'équipe dont nous aurons besoin pour mettre en œuvre notre stratégie, en informant notre story map. (1 h ; prévoir 1 à 2 jours)
• Carte des histoires - nous avons organisé et hiérarchisé les histoires d'utilisateurs, identifié notre candidat MVP, informant notrearchitecture holistique comme illustré ci-dessus. (3 h ; prévoir 1 à 2 jours)
• Architecture du modèle C4 - nous avons identifié les systèmes, les bases de données et les composants nécessaires, informant notre infrastructure requise. (3 h ; prévoir 2 à 5 jours)

Alimentés par ces « documents vivants », notre équipe et nos parties prenantes ont désormais une compréhension commune de la raison pour laquelle nous faisons ce que nous faisons, de la manière dont nous prévoyons de gagner (ou du moins des théories à tester) et de ce que nous allons construire pour résoudre le problème global.

Investir ce temps pour collaborer et écrire des choses simplifie également le processus de conception de l'infrastructure cloud, des référentiels de code source et de la surveillance / des mesures dont nous aurons besoin pour éventuellement prendre en charge eTumble. Nous allons explorer cela et plus encore dans la partie 3 de cette série .

Merci d'avoir lu jusqu'ici, et j'espère que vous apprécierez une plongée plus technique dans la partie 3 .