Donc, en quoi consistait le cours, en quoi consistaient ses 24 leçons et pourquoi il est utile pour le développeur, et pas seulement pour le futur produit.
Leçon 1. Produit
Était: L'essence du produit. Cycle de la vie. Tâches du chef de produit. Produit vs projet.
Utile:Il est extrêmement important pour un développeur de connaître le produit qu'il fabrique. Pour cela, ils paient plus bêtement. Bien sûr, vous pouvez vous faire passer pour une théière. Suivez strictement les savoirs traditionnels et ne faites rien au-delà de ce qui est écrit dans la spécification. Récapitulez tous les souhaits supplémentaires du client et ne commencez pas à travailler tant que le responsable technique n'a pas écrit tous les détails dans le ticket, jusqu'à la largeur des retraits sur l'interface utilisateur. Mais, surprise-surprise, avec cette approche, vous ne dépasserez jamais le niveau de développeur intermédiaire. Il y a des programmeurs qui sont fiers de leur incapacité à communiquer avec l'équipe et le client. Il y a, bien sûr, des exceptions. Mais si vous n'êtes pas Sheldon Cooper en informatique, il est préférable de faire preuve d'empathie et de comprendre comment le produit fonctionne, qui y participe, ce qu'ils font, ce qui est important pour eux et pourquoi. Dans l'un des projets, un client a commencé à écrire avec de l'eau bouillante avec bonheur, quand, sur la liste des fonctionnalités à faire, j'ai posé des questions sur les priorités.Et puis il a proposé de les changer, tk. certaines tâches ont été bloquées par d'autres. Et certains étaient mal formulés, ce qui entraînerait des erreurs dans le processus commercial. Et le plus gros échec que j'ai fait a été lorsque j'ai fait un gros refactoring sans l'approbation du client, car nos clients PM et PM étaient en vacances. Le client a refusé de payer, car il n'a pas apporté de valeur commerciale au produit.
Leçon 2. Hypothèses
Was: Définition d'une hypothèse. Fixer des objectifs pour SMART. Cycles HADI.
Utile: "Qui ne sait pas vers quel port naviguer, pour cela il n'y a pas de vent arrière" - a déclaré Lucius Annei Seneca, le mentor de Nero, mais on ne l'aime pas du tout pour ça. Les hypothèses concernent les priorités. Que faire en premier, que faire plus tard et quoi jamais. Les priorités affectent la vitesse du projet. Vitesse - pour atteindre la date limite. Les salaires, primes et autres avantages dépendent de la date limite du projet. C'est comme Tetris. Il y a 20 figurines qui doivent être placées dans un verre en une minute. Les chiffres sont tous différents. Leur superficie (le nombre de carrés dans chacun) est connue. Nous résumons la zone - ils devraient facilement s'intégrer les uns aux autres, même l'endroit reste. Mais ... ils ne correspondent pas. Parce que, surprise, ils iront si vous les mettez dans le bon ordre. Par conséquent, un développeur expérimenté effectue les tâches dans un tel ordre afin de ne pas ralentir le plus possible le travail de ses collègues. Si vous avez besoin de créer une API Web, commencez par convenir de l'interface et créez des stubs de méthode afin que les développeurs frontaux puissent appeler l'API,puis modifie le corps des méthodes. S'il est engagé dans une base de données, il démarre les tables dès que possible afin qu'elles puissent être utilisées sur le back-end, et effectue des vues, des index et d'autres liaisons plus tard. S'il écrit un document, il télécharge un brouillon pour révision ASAP, et ne le publie pas 5 minutes avant la didline, comme il lui semble, un document 100% parfait.
Leçon 3. Gestion d'équipe
Était: Team building. Agile. Kanban.
Utile: Ceux-ci doivent avoir des compétences pour les programmeurs et pas seulement. Les produits informatiques modernes sont fabriqués par des équipes. Si vous ne savez pas comment travailler dans une équipe - bienvenue à la
Leçon 4. Examiner les tâches et la sélection des projets
Était: examen des problèmes réels du produit. Présentations de cas des participants.
Utile: il semblerait. Pourquoi un programmeur saurait-il comment il a résolu le problème de la faible conversion publicitaire, de l'augmentation du contrôle moyen ou de la viralité de l'acquisition de clients? Réponse simple. Compétences en résolution de problèmes - compétences en résolution de problèmes. C'est ce pour quoi les recruteurs ont prié au cours des 10 dernières années et ce que l'on trouve dans chaque deuxième poste vacant aux États-Unis / dans l'UE. L'expérience de quelqu'un d'autre n'est jamais superflue. Après avoir exprimé le problème, le conférencier a suggéré de discuter de la manière dont les participants au cours allaient le résoudre. Il n'est jamais superflu d'utiliser son cerveau et d'apprendre de l'expérience des autres.
Leçon 5. Évaluation du produit
Était: Évaluation du marché et analyse des concurrents.
Utile:Connaissance pas évidente pour le programmeur. Tableaux de liste des fonctionnalités, analyse SWOT, tailles du marché TAM / PAM - pourquoi? Oui, cela ne semble pas nécessaire tant que vous ne décidez pas du choix d'une pile technologique dans le projet. Ou vous pensez que vous devez immédiatement passer aux dernières versions des bibliothèques dès leur sortie (non). Ou décidez dans quelle université aller. Ou dans quelle langue rédiger vos premiers projets. Bref, vous prenez une décision stratégique qui déterminera votre destin pour les années à venir. C # ou Java? Angulaire ou React? MSSQL ou Oracle? App store ou Google Play? Mobapps natifs ou QT / Xamarin? Visual Studio, WebStorm ou Visual Studio Code? J'ai toujours honte de l'affaire avec un client. Il recherchait des entrepreneurs pour développer un grand système ERP à partir de zéro. Notre société lui a proposé une équipe et un stack - Silverlight. Pour une.Pendant 5 ans, nous avons fabriqué un produit puis Microsoft a annoncé qu'il ne supportait plus Silverlight. Fatalité! Le système fini et débogué peut être jeté à la poubelle. Le client a passé 10 personnes * 18 mois * sur le seul développement * paiement mensuel moyen, taxes comprises, disons 3 000 $ = 540 000 $. Un demi-chien dans la queue! Et si l'on ajoute la perte de profit, compte tenu du développement d'un nouveau système (l'entreprise gagne ~ 10 milliards d'euros par an), imaginez les dégâts de la décision. Le problème ne concerne pas uniquement l’informatique. Blondes ou brunes? Acheter un appartement ou louer? Vous habitez en ville ou en banlieue? Dois-je voter ou aller à la maison de campagne? Pour quelle entreprise travailler? Déménager dans la capitale ou rester dans votre ville natale?Le client a passé 10 personnes * 18 mois * sur le seul développement * paiement mensuel moyen, taxes comprises, disons 3 000 $ = 540 000 $. Un demi-chien dans la queue! Et si l'on ajoute la perte de profit, compte tenu du développement d'un nouveau système (l'entreprise gagne ~ 10 milliards d'euros par an), imaginez les dégâts de la décision. Le problème ne concerne pas uniquement l’informatique. Blondes ou brunes? Acheter un appartement ou louer? Vous habitez en ville ou en banlieue? Dois-je voter ou aller à la maison de campagne? Pour quelle entreprise travailler? Déménager dans la capitale ou rester dans votre ville natale?Le client a passé 10 personnes * 18 mois * sur le seul développement * paiement mensuel moyen, taxes comprises, disons 3 000 $ = 540 000 $. Un demi-chien dans la queue! Et si l'on ajoute la perte de profit, compte tenu du développement d'un nouveau système (l'entreprise gagne ~ 10 milliards d'euros par an), imaginez les dégâts de la décision. Le problème ne concerne pas uniquement l’informatique. Blondes ou brunes? Acheter un appartement ou louer? Vous habitez en ville ou en banlieue? Dois-je voter ou aller à la maison de campagne? Pour quelle entreprise travailler? Déménager dans la capitale ou rester dans votre ville natale?Blondes ou brunes? Acheter un appartement ou louer? Vous habitez en ville ou en banlieue? Dois-je voter ou aller à la maison de campagne? Pour quelle entreprise travailler? Déménager dans la capitale ou rester dans votre ville natale?Blondes ou brunes? Acheter un appartement ou louer? Vous habitez en ville ou en banlieue? Dois-je voter ou aller à la maison de campagne? Pour quelle entreprise travailler? Déménager dans la capitale ou rester dans votre ville natale?
Leçon 6. Public cible
Was: MĂ©thodes de description du public cible. Segmentation.
Utile: je vais révéler un terrible secret. Pas un seul client au monde ne paie un programmeur juste pour le regarder taper sur le clavier, google stackoverflows, boire du café, discuter des principes du polymorphisme avec des collègues et donner des signaux intelligents lors de conférences téléphoniques. Le client paie pour résoudre ses problèmes. Par conséquent, il vaut la peine de connaître et de respecter votre client au moins pour le fait qu'il vous paie de l'argent. Sans client, vous écrivez simplement des applications amusantes gratuitement. Un passe-temps si mignon à la maison comme collectionner des timbres ou brûler du bois.
Session 7. Recherche de clients
Était: Développement client (recherche client via des entretiens de problèmes).
Utile: comme la leçon précédente portait sur le client. Pourquoi un autre? Vous devez Fedya, vous devez! Ici, nous parlons d'une interview. Vous devez parler au client. Et peu de gens savent comment faire cela. N'insistez pas avec vos opinions, ne suggérez pas de réponses, posez des questions sur le passé, pas sur l'avenir, découvrez des chiffres précis, pas des souhaits, clarifiez les incertitudes, ayez un plan de conversation et fixez des accords, écoutez plus, parlez moins. Rien de mieux que le livre de Rob Fitzpatrick "Ask Mom" ​​n'a encore été écrit. Et j'en ai même une critique . Du coup, parler au format castedev n'est pas seulement possible avec le client, mais aussi avec des collègues.
Session 8. Entretien pratique
Était: Recherche de répondants. Formulation de questions. Développement client en pratique.
Utile:Pour devenir un bon intervieweur, vous devez malheureusement également mener des entretiens. Je parle parfaitement l'anglais, avec tous les gérondifs, je peux reconnaître l'argot et imiter n'importe quel accent, je plaisante de façon incendiaire et comprends les nuances les plus subtiles de la langue. Mais c'est dans ma tête. En pratique, cela ressemble à ceci: «Ixcuzmi. Veriz eeee niarest shop? Acheter des produits de visa? Chip note, sacrément cher, mais, bien sûr, cher! ". La théorie ne fonctionne pas sans pratique. Une expérience très traumatisante pour la psyché de tout programmeur suçon est de trouver des interviewés. Sortez du bâtiment et d'autres choses. Il est physiquement difficile de se forcer à appeler une entreprise inconnue et à demander un entretien ou à offrir un service. Ou demandez quelque chose dans la rue. Mais ce qui ne tue pas nous rend plus forts. Un coup de téléphone ne vous tuera pas. L'essentiel est de ne pas appeler sous la pluie et de ne pas se cacher sous les arbres.
Session 9. Recherche qualitative et quantitative
Il y avait: des entretiens, des sondages, des groupes de discussion, des experts, un conseiller Web, un client mystère, des tests A / B.
Utile: vous avez besoin d'arguments pour prendre une décision. Les arguments ont besoin de faits. Les faits sont basés sur des chiffres. Les chiffres proviennent de la recherche. Différents types de recherche sur la même chose donnent une image plus réaliste. Pourquoi un développeur en a-t-il besoin? Nous vivons dans un monde très cruel. Il n'est plus possible, comme dans les années 70, d'aller chez le patron et de demander 152 milliards de dollarspour atterrir sur la lune, regardez proprement, bien que tout soit parfaitement visible à travers un télescope. Si vous proposez un refactoring, il vaut mieux en montrer les bénéfices en chiffres. Par exemple, accélérer les requêtes de base de données par X-times, réduire la duplication de code et accélérer les modifications ou les correctifs par Y-times. L'achat d'un resharper se justifie par une accélération du codage d'un facteur Z. Pizza gratuite le vendredi - 100 500+ fois meilleur esprit d'équipe.
Leçon 10. Générer des idées
Était: Chapeaux Méthode 6, Walt Disney, vache stupide, génération inverse, objets focaux, TRIZ.
Utile: Mon passe-temps préféré. Comme l'a dit un homme intelligent, «la programmation est une invention à la demande». Il n'y a nulle part en IT sans cela. Combien de fois ai-je été confronté à un problème apparemment insoluble, et après cet aperçu, j'ai trouvé une solution élégante. En fait, les gens ont trouvé un tas de moyens pour stimuler la créativité. Une méthode de travail consiste à expliquer le problème à un collègue, à demander des conseils et à trouver quelques alternatives pendant la discussion. Vous devez communiquer davantage. Il est bon de «dormir» avec la pensée et le matin, le subconscient trouve une solution ou de s'engager dans une activité physique (nage) et dans le processus de réfléchir à l'idée.
Leçon 11. Proposition de valeur
Était: Compilation du CPU. Toile maigre, toile de proposition de valeur.
Utile: Encore une fois, ceux qui sont purement techniques seront déçus. Tous les noms de fonctions, bibliothèques et syntaxe du langage de programmation. Rien de tout cela, bien sûr, ne s'est produit. Et il y avait l'analyse, la formulation de questions et l'obtention de réponses, la recherche d'informations, l'élaboration de tableaux et la structuration des données. Tout sans quoi il est impossible d'imaginer un bon informaticien.
Leçon 12. Modèles commerciaux
Était: Types et construction de modèles commerciaux. Business Model Canvas. Monétisation des produits.
Utile: similaire à la leçon précédente sur le processeur. Des cerveaux qui bougent à toute vitesse. Un sujet utile sur les types de monétisation, car il est toujours préférable d'imaginer exactement comment votre produit rapporte de l'argent.
Leçon 13. Feuille de route du produit
Était: Feuille de route. Diagramme de Gantt. Stratégie. Plan de libération. Backlog de produit. Backlog de développement.
Utile: celui-ci est plus destiné à un responsable technique et à un chef de projet. Fonctionnalité de lancement, didlines et jalons, risques, comptabilité des ressources disponibles, chargement de personnes et plans de conquête du monde.
Leçon 14. Concevoir un MVP
Était: Types de MVP (Minimum Viable Product). AIDA et 4U lors de la création d'une landing page.
Utile: pour la gestion des produits, MVP consiste à créer un prototype de produit pour tester la demande rapidement et à moindre coût. Quel est le lien avec le développement? Le fait est que des tâches sont assignées aux programmeurs, mais souvent, on ne précise pas exactement comment ces tâches doivent être résolues. Par conséquent, un bon développeur essaie d'économiser des ressources et d'effectuer la tâche avec un minimum d'effort, car les priorités peuvent changer et personne n'a annulé la didline. S'il est dit de créer un tableau de données modifiable, vous ne devez pas créer de contrôle capable d'afficher tous les types de données, y compris le mode pivot, la fonctionnalité Excel et l'exportation de données dans tous les formats. Les principes de YAGNI , KISS etle péché de l'optimisation prématurée est à ce sujet. Et jamais, entendez-vous, ne faites jamais une tâche et un gros refactoring en un seul billet! (pleurs).
Leçon 15. Table des matières
Était: Théorie des contraintes. Endroits étroits.
Utile: Ceci est direct TOP lors de l'optimisation de la vitesse du programme. Pour les produits, il s'agissait d'optimiser la partie la plus étroite de l'entonnoir. Pour un informaticien, il est souvent nécessaire d'augmenter la vitesse de réponse - chargement de page, génération de rapport, téléchargement de fichier. SQL a un plan de requête, une mise en cache et d'autres techniques d'optimisation. Il vaut toujours la peine d'améliorer le goulot d'étranglement dans le système. Et pour cela, vous devez mesurer les étapes du processus, enregistrer le timing et prendre des décisions basées sur des chiffres, et non sur des sentiments comme "Je vais réécrire de LINQ au stockage, cela semble aider."
Leçon 16: Histoires d'utilisateurs et scénarios
Était: Création et utilisation de la carte du parcours client.
Utile: je l'avoue. La programmation est amusante, la rédaction de documentation est ennuyeuse. Au milieu se trouve la conception des interfaces (UX, à ne pas confondre avec UI). C'est plus amusant qu'ennuyeux. Esquissez des interfaces dans Visio, réfléchissez à des scénarios d'utilisation, écrivez des règles métier. Si vous souhaitez passer du statut de développeur à celui de lead, PM, analyste, produit ou architecte, mieux vaut maîtriser cette technique. Je ne dis même pas que les exigences pour les logiciels sont souvent définies de manière plutôt vague, voire même sans dispositions d'interface utilisateur. Par conséquent, concevoir vous-même une interface décente tout de suite, résoudre les incohérences logiques dans la logique métier en temps opportun vous fera gagner beaucoup de temps et affectera votre satisfaction à l'égard de votre travail.
Leçon 17. UX
Était: Scripts. Bases de l'UX. Page de destination. CJM.
Utile: il y avait de la pratique UX ici. Il s'avère que je suis en retard. Les gens créent des pages Web depuis longtemps à Tilda , Figma et, Dieu me pardonne, Tinkoff . Et les diagrammes et les prototypes UX ne sont pas créés dans Visio, mais dans Google Drawings , Draw.io et LucidChart . Pour les bases d'une conception appropriée (rembourrage, blocs visuels, polices, accents), j'ai aimé le livre de Vlad V. Golovach "Conception de l'interface utilisateur: l'art de laver un éléphant" . Le lien est la deuxième version, j'ai lu la première, c'est mieux.
Leçon 18. Métriques
Était: métriques clés, personnalisation, collecte.
Utile: prendre des décisions basées sur des données est utile. Les données sont le nouveau processus décisionnel noir, basé sur les données et tout cela. Dans les entreprises informatiques cool, les développeurs s'habituent à mesurer et à fonctionner avec un tas de données - les résultats de l'exécution des tests, du déploiement sur le serveur, des contrôles de qualité du code, de la progression de la fermeture des tâches dans Jira, etc.
Session 19. Économie de l'unité
C'était: En fait, l'unité-économie.
Utile: thème super utile pour les produits. Vous devez gagner plus (3 fois et plus) sur la vente d'une unité de marchandises que vous n'en dépensez pour la production de la même unité. Quel est l'analogue pour les développeurs? Je ne sais pas. Après tout, le programmeur est chargé de créer la fonctionnalité dans le carré de la qualité-temps-argent-qualité. Combien d'argent telle ou telle fonctionnalité rapportera-t-elle par rapport au coût de sa production est déterminée par le produit et les priorités qu'il fixe.
Leçon 20. Analyse d'un cas réel de lancement de produit
Était: méthodologie de lancement de produit. Génération d'améliorations de produits.
Utile: l' expérience est toujours utile, et l'expérience dans une entreprise sanglante est doublement utile. Il existe une opinion selon laquelle les pigistes n'aiment pas beaucoup employer des entreprises, en particulier pour les systèmes hérités très chargés. Il ne s'agit même pas de la NDA, de l'incapacité de travailler en équipe, des inconvénients de la communication à distance et des autres problèmes typiques d'externalisation. C'est juste qu'il y a des nuances dans un système vivant auxquelles un pigiste peut même ne pas penser. De la bureaucratie à l'interopérabilité des intégrations et une fenêtre de temps pratique pour le déploiement. Sans parler du problème de la mise à jour de la base de données en temps réel, du versionnage des API, etc.
Leçon 21. Pratique de l'évaluation des solutions produits
Était: Mécanique d'évaluation des solutions produits.
Utile:C'était une continuation de la leçon précédente. Uniquement en mettant l'accent sur la pratique intensive, la génération d'hypothèses, l'attribution des tâches et le suivi des résultats. En bref, le système d'exploitation. Il serait utile pour un bon développeur ici de comprendre que le travail ne s'enfuira pas. Les tâches à accomplir hier se décomposent en quelques morceaux par jour. L'un d'eux apparaîtra au moment où vous quitterez le travail et vérifierez enfin votre courrier. Cet équilibre entre vie professionnelle et vie privée est important. Qu'il y a des moments où vous avez juste besoin de le prendre et de le faire quelle que soit l'heure de la journée. Mais il est tout aussi important de ne pas s'enliser dans une routine et de ne pas s'épuiser dans quelques mois. Que vous pouvez rester au travail pendant 4 à 6 heures au-dessus de la norme, mais cela signifie que le jour suivant, la productivité du travail sera au mieux de 50 à 70%, donc des heures supplémentaires constantes sont inutiles.
Leçon 22. Hiérarchisation des tâches produit
Était: Méthodes MVP - priorisation, ICE / RICE, binaire - priorisation, période de récupération.
Utile:Bon sujet car les développeurs doivent constamment donner des estimations de la complexité des tâches. Ce n'est pas aussi simple qu'il y paraît. Peu à peu, vous pouvez vous réveiller pour faire des estimations plus ou moins adéquates afin de ne pas bousiller de plus de 20%. Mais généralement, le PMU n'aime pas ces chiffres. C'est difficile car il y a des tâches interdépendantes, le facteur de familiarité avec une section spécifique du code et / ou de la technologie, pressant le PM pour réduire le temps, car "Il était développeur et se souvient que c'est simple", spéculation vague (j'adore quand l'analyste ajoute de nouveaux points au cours du processus de développement), l'opinion subjective "L'interface utilisateur semble correcte ou doit être améliorée", le désir de ne pas paraître stupide par rapport aux autres et donc dur réduire votre appréciation, la pression des collègues, une recommandation issue d'en haut «nous avons déjà signé un accord avec le client pour le montant exact et les conditions», etc.
Leçon 23. Préparation à la défense du travail
Était: Types de présentations. Conseils pour parler. Tester les séries de rapports.
Utile: encore une fois. Si vous ne prévoyez pas de dépasser le développeur intermédiaire, ignorez ce point. Pour le reste, et pour leur propre développement, il ne sera pas superflu d'apprendre à préparer un rapport, enflammer le public, ne pas tomber avec des questions délicates, discuter de manière constructive du sujet et défendre leur point de vue ou le changer sans aller aux extrêmes du Code pénal de la Fédération de Russie sous la forme d'infliger des lésions corporelles graves à des opposants idéologiques ...
Leçon 24. Défense des travaux de session
C'Ă©tait: Une performance de combat devant un public.
Utile: en fait, une performance en direct. Vous pouvez vous préparer longtemps, lécher la preza, prendre des cours de prise de parole en public et de théâtre. Mais après le premier coup à la mâchoire (monter sur scène), tout cela m'est sorti de la tête. Je ne sais pas pourquoi dans les grandes entreprises informatiques, ils prennent la parole lors de conférences ou au moins rédigent des articles pour des publications spécialisées, au moins pour quelques personnes. Malgré le fait que cela améliore considérablement la capacité à formuler des pensées, la marque personnelle de l'orateur, développe la communauté informatique et permet aux entreprises d'économiser sur les coûts de relations publiques et de ressources humaines.
Sinon, comment un développeur peut-il cesser d'être juste un codeur de formulaires d'interface utilisateur pour accéder à une base de données et s'imprégner de la réflexion sur les produits?
Premièrement, il y a une nouvelle tendance pour les organisations turquoises . Il existe un excellent essai sur le sujet sur habr . Bien sûr, beaucoup de choses semblent un peu utopiques. Donner des responsabilités sans pouvoir réel ni engagement financier peut être très risqué. Et qui est facile maintenant?
Deuxièmement, ou peut-être est-ce le manifeste du premier point - « Funky business ». Certaines citations du livre peuvent être lues ici. Ce que j'aime dans ces paroles, c'est qu'elles sont écrites comme une révélation religieuse. Aussi flou que possible, accessible, pour tous bons, contre tous mauvais. Ce n'est pas un inconvénient, mais au contraire, une dignité. Tous ceux qui liront réfléchiront et tireront leurs propres conclusions.
Enfin, il y a la tendance récente à l'innovation des entreprises . Hackathons, pilotes de démarrage, développement de l'entrepreneuriat interne, stratégie de transformation numérique, Lean, développement client et Design Thinking. Il existe un excellent schéma sur le sujet de Disruptive.vc :
Conclusion
Je suis sûr que je n'ai révélé aucun secret. Plus vous en savez, mieux c'est. Même s'il y a beaucoup de connaissances, il y a beaucoup de chagrins. Dans un team building de restaurant avec un client britannique, notre responsable technique a montré une boîte de trucs d'allumettes. Il le posa sur le bord de la table, le frappa d'en bas et le lança en l'air et de la même main alluma une allumette contre lui. Le client a été tellement impressionné qu'il a payé la facture pour toute l'équipe, de la bière à la liane. Et l'un des PM a si bien plaisanté que les stand-ups et le rétro se sont transformés en clubs de comédie dans les meilleures années. On peut même dire que les compétences d'un chef de produit ne seront pas seulement superflues pour le développeur, mais que toutes les compétences en général jouent un rôle positif dans le travail, le point est uniquement dans leur application correcte . Par conséquent, apprenons, continuons à nous développer et apprécions notre travail!