Ceci est la troisième partie d’une trilogie d’articles abordant le décalage entre le pitch deck et le produit utilisable auquel toutes les startups sont confrontées.
Si vous les avez manqués, voici la première et la deuxième partie.
Bienvenue à nouveau. On dirait que vous êtes sérieux à ce sujet. Cet article est pour des bâtisseurs comme vous. Quelles parties du deuxième épisode de cet article avez-vous mises en œuvre ?
La dernière fois, nous avons discuté de la manière dont on pouvait exploiter le modèle « Diviser pour régner » pour des problèmes apparemment insondables en les découpant en blocs résilients, réutilisables et autonomes de tailles variées.
Aujourd’hui, nous parlerons des cas où il est plutôt logique de découper en morceaux homogènes d’une taille approximativement équivalente, car il n’y a pas de point évident où la coupure serait la plus appropriée.
Iconographie du système de design
La mise en place et le renforcement des systèmes de design relèveraient généralement de ma responsabilité dans la plupart des startups en phase initiale. Bien que de nombreuses activités liées aux systèmes de design respectent le paradigme CDD (Component-Driven Development), comme discuté dans la deuxième partie, toute une catégorie de sous-tâches nécessite l’exécution de mouvements répétitifs qui ne peuvent pas être entièrement automatisés. Dans ces cas, il est judicieux de diviser le travail en morceaux de taille équivalente ou similaire et de parcourir la liste entière tranche par tranche.
Exemple d’iconographie. Source : storybook.js.orgUn exemple flagrant d’une telle sous-tâche est l’iconographie. Lorsque le designer doit ajuster le décalage entre des ensembles d’icônes qui sont « presque là » mais pas tout à fait, il doit passer les icônes une par une dans son moulin, en ajustant les tailles, les tons, l’épaisseur des traits, les formats, etc. C’est là qu’il est essentiel de trouver une bonne playlist qui fera passer le temps plus vite.
Conversion de l’infrastructure existante en IaC
Décrire votre infrastructure cloud sous forme de code est quelque chose que je recommande de commencer dès que vous commencez à la mettre en place. Cependant, l’expérience personnelle montre que, dans la plupart des cas, vous commencerez à travailler avec une configuration existante.
// Intégrer les ressources existantes et les remplacer progressivement par
// de nouvelles.
this.vpc = Vpc.fromLookup(this, 'ExistingVPC', { vpcId: 'legacy-vpc-id' });
Vous pouvez diviser les services que vous devez importer en lots de n. Ensuite, vous pouvez les traiter un par un. Cela ralentira le processus, mais il est nécessaire de faire une transition progressive des anciens systèmes vers ceux créés via IaC (Infrastructure as Code). Ces migrations seront quasi instantanées pour les éléments sans état comme les configurations réseau ou les fonctions Lambda. Cependant, elles seront significatives pour les éléments avec état, tels que les bases de données ou les pools d’utilisateurs. N’hésitez pas à me contacter si vous avez besoin d’un interlocuteur.
Fichiers Storybook
Maintenant que votre Storybook est configuré, chaque composant web aura un fichier dédié contenant des stories. Si vous commencez de zéro, suivez la Definition of Done (DoD) et créez un fichier avec au moins une story basique. Si vous avez hérité d’une base de code existante, vous pouvez consacrer du temps à itérer et enrichir les composants existants avec de tels fichiers.
Un fichier de composant Storybook de base
L’histoire interactive obtenueAu fur et à mesure de votre progression, je recommande de structurer la hiérarchie de tous vos composants et pages dans la bibliothèque sous forme d’un arbre qui imite la structure des dossiers du code. Vous voulez que vos composants soient aussi hauts que nécessaire dans cette hiérarchie, mais pas plus. Documenter les composants avec Storybook peut fournir une aide visuelle pour déterminer si vous devez descendre quelque chose ou le remonter plus haut dans la hiérarchie.
Fichiers de test
Puisque le framework de test a été mis en place et configuré dans le cadre de l’équipement avec les outils de développement indépendants du contexte nécessaires, vous pouvez maintenant vous attaquer à des tâches simples par lots de x.
La première partie de l’article mentionne les tests smoke et snapshot.
...
// Smoke test
it('renders without crashing', () => {
const container = document.createElement('div');
const root = createRoot(container);
root.render(<Hint text={'Hint'} />);
});
// Snapshot test
it('renders correctly', () => {
const view = render(<Hint text={'Hint'} />);
expect(view).toMatchSnapshot();
});
Ces tests sont répétitifs à écrire et ne nécessitent pas de réflexion approfondie. Tout ce que vous avez à faire est d’augmenter chaque composant, qu’il s’agisse d’un package, d’un bouton React ou d’une construction Amazon Web Services (AWS) CDK, avec un fichier supplémentaire comme décrit dans votre document DoD (Definition of Done). Vous aurez autant de ces fichiers que de composants autonomes testables. Parcourez-les tous de manière itérative et ajoutez ces quelques lignes de code.
Suivi des événements analytiques
Meta est connue pour suivre environ 50 000 points de données vous concernant. Votre startup n’a probablement pas besoin de suivre autant, mais vous voulez collecter des analyses des événements importants. Vous ne voulez pas implémenter 50 000 événements aléatoires dès le premier jour. Ce niveau de sophistication vient avec la maturité.
// Une analyse stéréotypée du panier utilisateur.
await analyticsAddToCart({
currency,
items: products.map(({ id }) => id),
webappUserId: user.username,
value: numberOfItems,
})
Ce que je constate souvent, c’est que les développeurs chargés d’implémenter le suivi des événements analytiques s’attendent à ce que les marketeurs sachent exactement quels événements ils veulent suivre. « Donnez-nous une liste de ce que vous voulez, et nous la prioriserons », entends-je souvent. À moins qu’il ne s’agisse de spécialistes chevronnés qui ont déjà fait cela avec le même type de produit, ce n’est généralement pas le cas.
Cependant, si une telle liste est établie, vous pouvez la découper en portions gérables et livrer chaque portion chaque jour ou sprint.
Lorsque vous couvrez votre base de code avec le suivi des événements, je recommande de ne pas trop réfléchir et d’y aller du grossier au fin. Limitez-vous à des événements simples, comme les vues de pages et les scrolls au-delà du pli. Ensuite, ajoutez les termes de requête de recherche et la durée des sessions. Plus tard, vous pouvez devenir plus granulaire et collecter les articles du panier d’achat et comment ils se rapportent aux recommandations que votre système a produites en fonction de leurs intentions de recherche.
Modélisation des entités commerciales
J’espère que la deuxième partie de l’article vous a convaincu d’investir de l’énergie dans la modélisation de votre entreprise via UML (Unified Modeling Language) ou un équivalent. Si vous avez fait ce choix judicieux, vous devrez maintenant peupler votre modèle avec des entités commerciales utilisées régulièrement dans toute l’entreprise. Il existe une liste d’entités couramment utilisées, telles que les utilisateurs, les requêtes, les messages de chat, etc. Mais il y a sans aucun doute aussi des entités spécifiques à votre entreprise.
Un diagramme de cas d’utilisation UML de baseMa recommandation est de commencer par la création d’un ERD, ou diagramme de relation d’entités (Entity Relationship Diagram). Chaque entité commerciale pertinente doit être représentée avec les attributs que vous souhaitez conserver. Reliez-les en utilisant la notation en patte de poulet (chicken leg notation).
Un produit peut faire partie de zéro ou plusieurs paniers. Un panier peut contenir zéro ou plusieurs produits.Adoptez une perspective conceptuelle de haut niveau plutôt qu’une pensée de bas niveau, type table de base de données. Bien que les attributs soient représentés comme faisant partie d’une entité particulière, ils ne doivent pas nécessairement être implémentés dans la même base de données. Cela est particulièrement vrai pour les systèmes distribués, qui constituent la majorité des plateformes modernes. Vous pouvez également utiliser les conventions d’ontologie RDF ou OWL, mais c’est un sujet pour une autre fois.
Il y a peu de logiciels de modélisation indépendants du système d’exploitation qui méritent réellement votre attention et votre argent. Je recommande toujours StarUML, car c’est le logiciel d’analyse qui me semble le plus pertinent sans coûter une fortune.
Conclusion
Cet article a été initialement écrit pour éviter les répétitions.
En effet, toutes les entreprises dans lesquelles j’ai travaillé, sans exception, s’éparpillaient en essayant de tout construire simultanément ou en se concentrant davantage sur des choses secondaires que sur l’essentiel, sacrifiant l’efficacité et brûlant de l’argent de manière sous-optimale.
Je ne pointe pas du doigt — nous ne voyons tous pas la forêt à cause des arbres. J’en suis certainement coupable aussi. L’astuce est de le remarquer suffisamment tôt ou de se placer dans un cadre où la probabilité que cela arrive est faible. C’est pourquoi nous utilisons des frameworks. Ils cadrent notre travail en éliminant le facteur humain. « Diviser pour régner » en est un exemple.
Si ce que vous avez lu vous paraît du bon sens, c’est parce que ça l’est. La plupart des choses qui fonctionnent sont ridiculement simples. Je n’ai rien inventé. Personne ne le fait. Il s’agit d’un modèle éprouvé emprunté à d’autres disciplines où ces méthodes sont des standards pour mener à bien les choses. Je suis sûr qu’elles fonctionneront aussi pour vous.
Remerciements spéciaux
Cette série d’articles n’aurait pas été possible sans les contributions inestimables de Lilian T. , Farouq Aldori, Teppo Hudsson, Jarek Owczarek, Nickolay Tsybulyanko, et Jason Collins.