Zie hoe klant RS21 en de eigen engineeringteams van Guru Guru gebruiken om hun ontwikkelingsdocumentatie toekomstbestendig te maken, inclusief processen en sjablonen.
Alle engineeringteams vertrouwen op een soort documentatietool om belangrijke productinformatie met hun collega's te communiceren. Voor kleine teams die net beginnen, kan dit zo eenvoudig zijn als een Google Doc, en voor grotere teams met complexe producten kan dit een hiërarchische wiki zijn. Afhankelijk van hoe hun bedrijf is gestructureerd, kunnen andere teams (zoals HR of marketing) deze wiki ook gebruiken, of andere gebieden hebben waar ze de informatie van hun team opslaan.
Wanneer je bij een nieuw engineeringteam (intern of extern) komt, is het onboardingproces cruciaal voor het bepalen hoe snel een nieuwe teamgenoot zich klaar voelt om bij te dragen. Van het instellen van hun code-omgeving tot het doorlezen van documentatie over functies, er is veel nodig om up-to-speed te komen en klaar te zijn om nieuw werk op te nemen.
Voor veel engineeringteams wordt het onboardingproces een zware taak voor een andere teamgenoot, die wordt aangesteld als de 'buddy' van de nieuwe werknemer en deze informatie in real-time doorneemt. Maar door hun team van expert-geverifieerde, actuele Cards in Guru te voorzien, geven de engineeringleiders van RS21 nieuwe medewerkers de flexibiliteit om in hun eigen tempo in te werken. Dit laat hen tijd besparen met hun onboarding 'buddy' voor meer interpersoonlijke relatieopbouw of openstaande vragen.
Wanneer een nieuwe engineer zich bij het team van RS21 aansluit, loggen ze in op Guru om te beginnen met het doorlopen van hun onboardingmaterialen. Ze zullen door een 'Team Info' Board kijken waar ze iets over hun teamgenoten te weten kunnen komen, infrastructuur Cards kunnen gebruiken om hun omgevingen correct in te stellen, en door de codestandaarden van hun team kunnen lezen om een idee te krijgen van hoe ze het beste met hun nieuwe collega's kunnen samenwerken.
Evenzo, bij Guru, wanneer een engineer bij een nieuw team komt of naar een nieuw team verhuist, wordt hun onboarding in Guru gedaan. Ze zullen gebruik maken van levensverhaal Cards om hun teamgenoten te leren kennen, zien gidsen over hoe ze samen moeten werken, en de Collectie van hun nieuwe team in Guru doorbladeren om vertrouwd te raken met de productkenmerken en gebieden waarvoor ze nu verantwoordelijk zijn.
Best Practices en Teamnormen
Zodra het hele team is onboard, hebben doorlopende middelen, zoals codestandaarden en documentatie best practices, ook een plek in Guru. Wanneer gedocumenteerd op een manier die toegankelijk is in hun werkprocessen, maken deze het gemakkelijker voor engineers om productief samen te werken met de rest van hun team en de rest van het bedrijf. Het voorkomt ook dat ze enige beleidslijnen of procedures hoeven te onthouden, of erger nog, dat ze verouderde documenten moeten opslaan en op vertrouwen.
De Engineering Collectie van RS21 in Guru omvat een Board die is gewijd aan procesrichtlijnen, inclusief Cards met instructies voor het samenvoegen van code, het maken van een bash-script, het aanvragen van een codebeoordeling, en meer. Ze hebben ook Boards die zijn gewijd aan de afgesproken coderingsstijlen van hun team, instructies voor AWS-installatie, informatie over systeembeheer, en meer. Ze hebben zelfs vaak gebruikte codefragmenten beschikbaar voor eenvoudig kopiëren en plakken in Guru Cards.
Afgezien van deze engineering-specifieke Cards, is Guru ook een geweldige plek voor engineers om toegang te krijgen tot cross-functionele best practices en richtlijnen voor teamprocessen. Bijvoorbeeld, het team van RS21 voert asynchrone discussies uit met behulp van Guru om teamleden meer tijd te geven om doordacht te reageren, en om iedereen een evenwichtig en eerlijk platform te bieden om bij te dragen. Instructies voor het opzetten en monitoren van deze discussies worden bewaard in een Guru-sjabloon, zodat iedereen er gemakelijk een kan opzetten wanneer dat nodig is.
Bij Guru betrekken we teams buiten onze productontwikkelingsorganisatie om te helpen met ons kwaliteitsborgingsproces (QA). Met meer diverse zienswijzen kunnen we beter bugs identificeren, potentiële klantuitdagingen verkennen en ons ertegen beschermen voordat we vrijgeven. Maar een proces dat zo technisch is als QA vereist gedocumenteerde instructies en procedures bij het betrekken van cross-functionele teams. Voordat we beginnen met QA voor een nieuwe functie, gebruikt een engineeringteamleider onze QA Proces-sjabloon om een one-stop-shop te creëren voor alles wat ons team en belanghebbenden nodig hebben voor end-to-end QA. Wanneer we klaar zijn om met QA te beginnen, zullen ze dit als een aankondiging naar het team en de belanghebbenden versturen en de actieve QA-datums in de boodschap opnemen.
Projectplanning en ontwikkelingsdocumentatie
Telkens wanneer een nieuw ontwikkelingsproject van start gaat, volgt er veel documentatie om ervoor te zorgen dat iedereen de volledige context heeft die nodig is om hun rol te vervullen. Na een kick-off bijeenkomst vertrouwen engineers op eisen-documenten van productteams, de meest recente functionele ontwerpen van hun UX-team, teksten van hun marketing- of copywritingteam, en meer.
En natuurlijk zullen ze vaak enige technische documentatie moeten raadplegen die van invloed is op de functie waaraan ze werken, of die ze later in de ontwikkeling moeten bijwerken.
Bij Guru houden we de verschillende middelen bij die nodig zijn voor productontwikkeling in een Actieve Projectmiddelen Card, opgezet door de engineeringleider van elk project. Deze Cards zijn de go-to-resource van het engineeringteam gedurende de vroege stadia van de productontwikkelingscyclus, en worden up-to-date gehouden om eventuele wijzigingen weer te geven.
Naarmate het ontwikkelingsproces vordert, moet de samenwerking tussen engineering en ontwerp in sync blijven. Maar door de vaak asynchrone en afstandsgebonden aard van het werk, kunnen ontwerpers en engineers niet altijd een Zoom-oproep maken om eventuele problemen of feedback te bespreken. Om ervoor te zorgen dat ze onze afgesproken interne protocollen volgen voor het vragen om ontwerpreacties, gebruikt ons engineeringteam onze Design Feedback voor documentatie van UI-wijzigingen in Guru.
Toekomstbestendige documentatie
Documentatie is altijd een noodzakelijk onderdeel van het werk van een engineer geweest en zal dat altijd zijn. Maar wat ooit pijnlijke kreten en gefrustreerde zuchten opriep, kan een eenvoudig, natuurlijk onderdeel van hun dagelijkse werkzaamheden worden wanneer het direct in hun werkproces wordt geïntegreerd. De browserextensie van Guru brengt documentatie naar de plaatsen waar ingenieurs deze nodig hebben, in plaats van ze te dwingen hun context te veranderen om toegang te krijgen, en korte, door experts goedgekeurde Cards verminderen de druk van de lange artikelen van vroeger die moeilijk te schrijven en nog moeilijker te onderhouden waren. Dus waarom technische schuld vergroten met verouderde documentatie als je het nu gemakkelijk toekomstbestendig kunt maken? Begin vandaag gratis.
Alle engineeringteams vertrouwen op een soort documentatietool om belangrijke productinformatie met hun collega's te communiceren. Voor kleine teams die net beginnen, kan dit zo eenvoudig zijn als een Google Doc, en voor grotere teams met complexe producten kan dit een hiërarchische wiki zijn. Afhankelijk van hoe hun bedrijf is gestructureerd, kunnen andere teams (zoals HR of marketing) deze wiki ook gebruiken, of andere gebieden hebben waar ze de informatie van hun team opslaan.
Wanneer je bij een nieuw engineeringteam (intern of extern) komt, is het onboardingproces cruciaal voor het bepalen hoe snel een nieuwe teamgenoot zich klaar voelt om bij te dragen. Van het instellen van hun code-omgeving tot het doorlezen van documentatie over functies, er is veel nodig om up-to-speed te komen en klaar te zijn om nieuw werk op te nemen.
Voor veel engineeringteams wordt het onboardingproces een zware taak voor een andere teamgenoot, die wordt aangesteld als de 'buddy' van de nieuwe werknemer en deze informatie in real-time doorneemt. Maar door hun team van expert-geverifieerde, actuele Cards in Guru te voorzien, geven de engineeringleiders van RS21 nieuwe medewerkers de flexibiliteit om in hun eigen tempo in te werken. Dit laat hen tijd besparen met hun onboarding 'buddy' voor meer interpersoonlijke relatieopbouw of openstaande vragen.
Wanneer een nieuwe engineer zich bij het team van RS21 aansluit, loggen ze in op Guru om te beginnen met het doorlopen van hun onboardingmaterialen. Ze zullen door een 'Team Info' Board kijken waar ze iets over hun teamgenoten te weten kunnen komen, infrastructuur Cards kunnen gebruiken om hun omgevingen correct in te stellen, en door de codestandaarden van hun team kunnen lezen om een idee te krijgen van hoe ze het beste met hun nieuwe collega's kunnen samenwerken.
Evenzo, bij Guru, wanneer een engineer bij een nieuw team komt of naar een nieuw team verhuist, wordt hun onboarding in Guru gedaan. Ze zullen gebruik maken van levensverhaal Cards om hun teamgenoten te leren kennen, zien gidsen over hoe ze samen moeten werken, en de Collectie van hun nieuwe team in Guru doorbladeren om vertrouwd te raken met de productkenmerken en gebieden waarvoor ze nu verantwoordelijk zijn.
Best Practices en Teamnormen
Zodra het hele team is onboard, hebben doorlopende middelen, zoals codestandaarden en documentatie best practices, ook een plek in Guru. Wanneer gedocumenteerd op een manier die toegankelijk is in hun werkprocessen, maken deze het gemakkelijker voor engineers om productief samen te werken met de rest van hun team en de rest van het bedrijf. Het voorkomt ook dat ze enige beleidslijnen of procedures hoeven te onthouden, of erger nog, dat ze verouderde documenten moeten opslaan en op vertrouwen.
De Engineering Collectie van RS21 in Guru omvat een Board die is gewijd aan procesrichtlijnen, inclusief Cards met instructies voor het samenvoegen van code, het maken van een bash-script, het aanvragen van een codebeoordeling, en meer. Ze hebben ook Boards die zijn gewijd aan de afgesproken coderingsstijlen van hun team, instructies voor AWS-installatie, informatie over systeembeheer, en meer. Ze hebben zelfs vaak gebruikte codefragmenten beschikbaar voor eenvoudig kopiëren en plakken in Guru Cards.
Afgezien van deze engineering-specifieke Cards, is Guru ook een geweldige plek voor engineers om toegang te krijgen tot cross-functionele best practices en richtlijnen voor teamprocessen. Bijvoorbeeld, het team van RS21 voert asynchrone discussies uit met behulp van Guru om teamleden meer tijd te geven om doordacht te reageren, en om iedereen een evenwichtig en eerlijk platform te bieden om bij te dragen. Instructies voor het opzetten en monitoren van deze discussies worden bewaard in een Guru-sjabloon, zodat iedereen er gemakelijk een kan opzetten wanneer dat nodig is.
Bij Guru betrekken we teams buiten onze productontwikkelingsorganisatie om te helpen met ons kwaliteitsborgingsproces (QA). Met meer diverse zienswijzen kunnen we beter bugs identificeren, potentiële klantuitdagingen verkennen en ons ertegen beschermen voordat we vrijgeven. Maar een proces dat zo technisch is als QA vereist gedocumenteerde instructies en procedures bij het betrekken van cross-functionele teams. Voordat we beginnen met QA voor een nieuwe functie, gebruikt een engineeringteamleider onze QA Proces-sjabloon om een one-stop-shop te creëren voor alles wat ons team en belanghebbenden nodig hebben voor end-to-end QA. Wanneer we klaar zijn om met QA te beginnen, zullen ze dit als een aankondiging naar het team en de belanghebbenden versturen en de actieve QA-datums in de boodschap opnemen.
Projectplanning en ontwikkelingsdocumentatie
Telkens wanneer een nieuw ontwikkelingsproject van start gaat, volgt er veel documentatie om ervoor te zorgen dat iedereen de volledige context heeft die nodig is om hun rol te vervullen. Na een kick-off bijeenkomst vertrouwen engineers op eisen-documenten van productteams, de meest recente functionele ontwerpen van hun UX-team, teksten van hun marketing- of copywritingteam, en meer.
En natuurlijk zullen ze vaak enige technische documentatie moeten raadplegen die van invloed is op de functie waaraan ze werken, of die ze later in de ontwikkeling moeten bijwerken.
Bij Guru houden we de verschillende middelen bij die nodig zijn voor productontwikkeling in een Actieve Projectmiddelen Card, opgezet door de engineeringleider van elk project. Deze Cards zijn de go-to-resource van het engineeringteam gedurende de vroege stadia van de productontwikkelingscyclus, en worden up-to-date gehouden om eventuele wijzigingen weer te geven.
Naarmate het ontwikkelingsproces vordert, moet de samenwerking tussen engineering en ontwerp in sync blijven. Maar door de vaak asynchrone en afstandsgebonden aard van het werk, kunnen ontwerpers en engineers niet altijd een Zoom-oproep maken om eventuele problemen of feedback te bespreken. Om ervoor te zorgen dat ze onze afgesproken interne protocollen volgen voor het vragen om ontwerpreacties, gebruikt ons engineeringteam onze Design Feedback voor documentatie van UI-wijzigingen in Guru.
Toekomstbestendige documentatie
Documentatie is altijd een noodzakelijk onderdeel van het werk van een engineer geweest en zal dat altijd zijn. Maar wat ooit pijnlijke kreten en gefrustreerde zuchten opriep, kan een eenvoudig, natuurlijk onderdeel van hun dagelijkse werkzaamheden worden wanneer het direct in hun werkproces wordt geïntegreerd. De browserextensie van Guru brengt documentatie naar de plaatsen waar ingenieurs deze nodig hebben, in plaats van ze te dwingen hun context te veranderen om toegang te krijgen, en korte, door experts goedgekeurde Cards verminderen de druk van de lange artikelen van vroeger die moeilijk te schrijven en nog moeilijker te onderhouden waren. Dus waarom technische schuld vergroten met verouderde documentatie als je het nu gemakkelijk toekomstbestendig kunt maken? Begin vandaag gratis.
Ervaar de kracht van het Guru-platform uit de eerste hand - maak onze interactieve producttour
.webp)
