Voyez comment le client RS21 et les propres équipes d'ingénierie de Guru utilisent Guru pour pérenniser leur documentation de développement, y compris les processus et les modèles.
Toutes les équipes d'ingénierie s'appuient sur un outil de documentation pour communiquer des informations importantes sur le produit à leurs collègues. Pour les petites équipes qui commencent à peine, cela peut être aussi simple qu'un Google Doc, et pour les équipes plus grandes avec des produits complexes, cela peut être un wiki hiérarchique. En fonction de la structure de leur entreprise, d'autres équipes (comme les RH ou le marketing) peuvent également utiliser ce wiki, ou avoir d'autres domaines où elles stockent les informations de leur équipe.
Lorsqu'une nouvelle équipe d'ingénierie rejoint (qu'elle soit interne ou externe), le processus d'intégration est crucial pour déterminer à quelle vitesse un nouveau membre se sent prêt à contribuer. De la configuration de leur environnement de codage à l'examen de la documentation des fonctionnalités, il y a beaucoup à faire pour se mettre à jour et être prêt à assumer de nouvelles responsabilités.
Pour de nombreuses équipes d'ingénierie, le processus d'intégration se révèle être laborieux pour un autre membre de l'équipe, qui est désigné comme le « buddy » du nouvel employé et qui les guiderait à travers ces informations en temps réel. Mais en fournissant à leur équipe des Cartes vérifiées par des experts et à jour dans Guru, les dirigeants d'ingénierie de RS21 permettent aux nouvelles recrues de s'intégrer à leur propre rythme. Cela leur permet de gagner du temps avec leur « buddy » pour établir des relations interpersonnelles ou poser des questions en suspens.
Lorsqu'un nouvel ingénieur rejoint l'équipe de RS21, il se connecte à Guru pour commencer à travailler sur ses matériaux d'intégration. Il examinera un tableau des « informations sur l'équipe » où il pourra apprendre un peu sur ses coéquipiers, utiliser des Cartes d'infrastructure pour configurer correctement ses environnements et lire les normes de codage de son équipe pour comprendre comment collaborer au mieux avec ses nouveaux collègues.
De même, chez Guru, lorsqu'un ingénieur rejoint ou passe à une nouvelle équipe, son intégration se fait dans Guru. Ils utiliseront les Cartes d'historique de vie pour apprendre à connaître leurs coéquipiers, consulter des guides sur comment ils devraient s'attendre à travailler ensemble, et parcourir la Collection de leur nouvelle équipe dans Guru pour se familiariser avec les fonctionnalités du produit et les domaines dont ils sont désormais responsables.
Meilleures pratiques et normes de l'équipe
Une fois que toute l'équipe est intégrée, les ressources continues, telles que les normes de codage et les meilleures pratiques de documentation, ont également leur place dans Guru. Lorsqu'elles sont documentées de manière à être accessibles dans leurs workflows, cela facilite la collaboration productive des ingénieurs avec le reste de leur équipe et le reste de l'entreprise. Cela empêche également de devoir mémoriser des politiques ou procédures, ou pire, de marquer et de compter sur des documents obsolètes.
La Collection d'ingénierie de RS21 dans Guru comprend un tableau dédié aux directives de processus, y compris des Cartes avec des instructions pour fusionner le code, créer un script bash, demander une révision de code, et plus encore. Ils ont également des tableaux dédiés au style de syntaxe de codage convenu par leur équipe, aux instructions de configuration AWS, aux informations sur l'administration système, et plus encore. Ils ont même des extraits de code fréquemment utilisés disponibles pour un copier-coller facile dans les Cartes Guru.
En dehors de ces Cartes spécifiques à l'ingénierie, Guru est également un excellent endroit pour que les ingénieurs accèdent aux meilleures pratiques et directives interfonctionnelles pour les processus entre équipes. Par exemple, l'équipe de RS21 mène des discussions asynchrones en utilisant Guru pour donner aux membres de l'équipe plus de temps pour répondre de manière réfléchie, et pour offrir à chacun une plateforme égale et juste pour contribuer. Les instructions sur la façon de configurer et de surveiller ces discussions sont conservées dans un modèle Guru, afin que tout le monde puisse en créer un facilement au besoin.
Chez Guru, nous sollicitons des équipes extérieures à notre organisation de développement de produits pour nous aider dans notre processus d'assurance qualité (AQ). Avec des opinions plus diverses, nous sommes mieux en mesure d'identifier des bugs, d'explorer les défis potentiels des clients et de nous en protéger avant la sortie. Mais un processus aussi technique que l'AQ nécessite des instructions et des procédures documentées lorsqu'il implique des équipes interfonctionnelles. Avant de commencer l'AQ pour une nouvelle fonctionnalité, un responsable d'équipe d'ingénierie utilisera notre modèle de processus AQ pour créer un guichet unique pour tout ce dont notre équipe et les parties prenantes auront besoin pour l'AQ de bout en bout. Lorsque nous sommes prêts à commencer l'AQ, ils l'enverront comme une annonce à l'équipe et aux parties prenantes, et incluront les dates d'AQ actives dans le message.
Planification de projet et documentation de développement
Chaque fois qu'un nouveau projet de développement démarre, une quantité importante de documentation suit pour s'assurer que chacun possède tout le contexte dont il a besoin pour jouer son rôle. Après une réunion de lancement, les ingénieurs s'appuient sur des documents de requirements des équipes produits, les designs fonctionnels les plus récents de leur équipe UX, les copies de leur équipe marketing ou de copywriting, et plus encore.
Et, bien sûr, ils devront fréquemment se référer à toute documentation technique qui impacte la fonctionnalité sur laquelle ils travaillent, ou qu'ils devront mettre à jour plus tard dans le développement.
Chez Guru, nous suivons les diverses ressources nécessaires au développement du produit dans une Carte de Ressources de Projets Actifs, championnée par le responsable d'ingénierie de chaque projet. Ces Cartes sont la ressource de référence de l'équipe d'ingénierie durant les premières étapes du cycle de vie du développement de produit, et sont maintenues à jour pour refléter tout changement.
À mesure que le processus de développement progresse, la collaboration entre l'ingénierie et le design doit être synchronisée. Mais en raison de la nature souvent asynchrone et à distance du travail, les concepteurs et les ingénieurs ne peuvent pas toujours se connecter à un appel Zoom pour discuter des problèmes ou des retours. Pour s'assurer qu'ils suivent notre protocole interne agréé pour solliciter des retours sur le design, notre équipe d'ingénierie utilise notre Retours sur le Design pour les modifications UI, documentées dans Guru.
Documentation pérenne
La documentation a toujours été et sera toujours une partie nécessaire du travail d'un ingénieur. Mais ce qui autrefois provoquait des gémissements douloureux et des soupirs stressés peut devenir une partie simple et naturelle de leur quotidien lorsqu'elle est directement intégrée dans leur flux de travail. L'extension de navigateur de Guru apporte la documentation directement aux endroits où les ingénieurs en ont besoin, plutôt que de les forcer à changer de contexte pour y accéder, et des Cartes courtes, vérifiées par des experts, soulagent la pression des articles longs d'autrefois qui étaient difficiles à rédiger et encore plus difficiles à maintenir. Alors pourquoi aggraver la dette technique avec une documentation obsolète quand vous pouvez facilement l'actualiser dès maintenant ? Commencez aujourd'hui gratuitement.
Toutes les équipes d'ingénierie s'appuient sur un outil de documentation pour communiquer des informations importantes sur le produit à leurs collègues. Pour les petites équipes qui commencent à peine, cela peut être aussi simple qu'un Google Doc, et pour les équipes plus grandes avec des produits complexes, cela peut être un wiki hiérarchique. En fonction de la structure de leur entreprise, d'autres équipes (comme les RH ou le marketing) peuvent également utiliser ce wiki, ou avoir d'autres domaines où elles stockent les informations de leur équipe.
Lorsqu'une nouvelle équipe d'ingénierie rejoint (qu'elle soit interne ou externe), le processus d'intégration est crucial pour déterminer à quelle vitesse un nouveau membre se sent prêt à contribuer. De la configuration de leur environnement de codage à l'examen de la documentation des fonctionnalités, il y a beaucoup à faire pour se mettre à jour et être prêt à assumer de nouvelles responsabilités.
Pour de nombreuses équipes d'ingénierie, le processus d'intégration se révèle être laborieux pour un autre membre de l'équipe, qui est désigné comme le « buddy » du nouvel employé et qui les guiderait à travers ces informations en temps réel. Mais en fournissant à leur équipe des Cartes vérifiées par des experts et à jour dans Guru, les dirigeants d'ingénierie de RS21 permettent aux nouvelles recrues de s'intégrer à leur propre rythme. Cela leur permet de gagner du temps avec leur « buddy » pour établir des relations interpersonnelles ou poser des questions en suspens.
Lorsqu'un nouvel ingénieur rejoint l'équipe de RS21, il se connecte à Guru pour commencer à travailler sur ses matériaux d'intégration. Il examinera un tableau des « informations sur l'équipe » où il pourra apprendre un peu sur ses coéquipiers, utiliser des Cartes d'infrastructure pour configurer correctement ses environnements et lire les normes de codage de son équipe pour comprendre comment collaborer au mieux avec ses nouveaux collègues.
De même, chez Guru, lorsqu'un ingénieur rejoint ou passe à une nouvelle équipe, son intégration se fait dans Guru. Ils utiliseront les Cartes d'historique de vie pour apprendre à connaître leurs coéquipiers, consulter des guides sur comment ils devraient s'attendre à travailler ensemble, et parcourir la Collection de leur nouvelle équipe dans Guru pour se familiariser avec les fonctionnalités du produit et les domaines dont ils sont désormais responsables.
Meilleures pratiques et normes de l'équipe
Une fois que toute l'équipe est intégrée, les ressources continues, telles que les normes de codage et les meilleures pratiques de documentation, ont également leur place dans Guru. Lorsqu'elles sont documentées de manière à être accessibles dans leurs workflows, cela facilite la collaboration productive des ingénieurs avec le reste de leur équipe et le reste de l'entreprise. Cela empêche également de devoir mémoriser des politiques ou procédures, ou pire, de marquer et de compter sur des documents obsolètes.
La Collection d'ingénierie de RS21 dans Guru comprend un tableau dédié aux directives de processus, y compris des Cartes avec des instructions pour fusionner le code, créer un script bash, demander une révision de code, et plus encore. Ils ont également des tableaux dédiés au style de syntaxe de codage convenu par leur équipe, aux instructions de configuration AWS, aux informations sur l'administration système, et plus encore. Ils ont même des extraits de code fréquemment utilisés disponibles pour un copier-coller facile dans les Cartes Guru.
En dehors de ces Cartes spécifiques à l'ingénierie, Guru est également un excellent endroit pour que les ingénieurs accèdent aux meilleures pratiques et directives interfonctionnelles pour les processus entre équipes. Par exemple, l'équipe de RS21 mène des discussions asynchrones en utilisant Guru pour donner aux membres de l'équipe plus de temps pour répondre de manière réfléchie, et pour offrir à chacun une plateforme égale et juste pour contribuer. Les instructions sur la façon de configurer et de surveiller ces discussions sont conservées dans un modèle Guru, afin que tout le monde puisse en créer un facilement au besoin.
Chez Guru, nous sollicitons des équipes extérieures à notre organisation de développement de produits pour nous aider dans notre processus d'assurance qualité (AQ). Avec des opinions plus diverses, nous sommes mieux en mesure d'identifier des bugs, d'explorer les défis potentiels des clients et de nous en protéger avant la sortie. Mais un processus aussi technique que l'AQ nécessite des instructions et des procédures documentées lorsqu'il implique des équipes interfonctionnelles. Avant de commencer l'AQ pour une nouvelle fonctionnalité, un responsable d'équipe d'ingénierie utilisera notre modèle de processus AQ pour créer un guichet unique pour tout ce dont notre équipe et les parties prenantes auront besoin pour l'AQ de bout en bout. Lorsque nous sommes prêts à commencer l'AQ, ils l'enverront comme une annonce à l'équipe et aux parties prenantes, et incluront les dates d'AQ actives dans le message.
Planification de projet et documentation de développement
Chaque fois qu'un nouveau projet de développement démarre, une quantité importante de documentation suit pour s'assurer que chacun possède tout le contexte dont il a besoin pour jouer son rôle. Après une réunion de lancement, les ingénieurs s'appuient sur des documents de requirements des équipes produits, les designs fonctionnels les plus récents de leur équipe UX, les copies de leur équipe marketing ou de copywriting, et plus encore.
Et, bien sûr, ils devront fréquemment se référer à toute documentation technique qui impacte la fonctionnalité sur laquelle ils travaillent, ou qu'ils devront mettre à jour plus tard dans le développement.
Chez Guru, nous suivons les diverses ressources nécessaires au développement du produit dans une Carte de Ressources de Projets Actifs, championnée par le responsable d'ingénierie de chaque projet. Ces Cartes sont la ressource de référence de l'équipe d'ingénierie durant les premières étapes du cycle de vie du développement de produit, et sont maintenues à jour pour refléter tout changement.
À mesure que le processus de développement progresse, la collaboration entre l'ingénierie et le design doit être synchronisée. Mais en raison de la nature souvent asynchrone et à distance du travail, les concepteurs et les ingénieurs ne peuvent pas toujours se connecter à un appel Zoom pour discuter des problèmes ou des retours. Pour s'assurer qu'ils suivent notre protocole interne agréé pour solliciter des retours sur le design, notre équipe d'ingénierie utilise notre Retours sur le Design pour les modifications UI, documentées dans Guru.
Documentation pérenne
La documentation a toujours été et sera toujours une partie nécessaire du travail d'un ingénieur. Mais ce qui autrefois provoquait des gémissements douloureux et des soupirs stressés peut devenir une partie simple et naturelle de leur quotidien lorsqu'elle est directement intégrée dans leur flux de travail. L'extension de navigateur de Guru apporte la documentation directement aux endroits où les ingénieurs en ont besoin, plutôt que de les forcer à changer de contexte pour y accéder, et des Cartes courtes, vérifiées par des experts, soulagent la pression des articles longs d'autrefois qui étaient difficiles à rédiger et encore plus difficiles à maintenir. Alors pourquoi aggraver la dette technique avec une documentation obsolète quand vous pouvez facilement l'actualiser dès maintenant ? Commencez aujourd'hui gratuitement.
Découvrez la puissance de la plateforme Guru de première main - faites notre visite interactive du produit
.webp)
