Alla ingenjörsteam förlitar sig på någon typ av dokumentation för att kommunicera viktig produktinformation med sina kollegor. För små team som just har börjat kan detta vara så enkelt som ett Google Doc, och för större team med komplexa produkter kan detta vara en hierarkisk wiki. Beroende på hur deras företag är uppbyggt, kan andra team (som HR eller marknadsföring) också använda denna wiki, eller ha andra områden där de lagrar sin teams information.
När man går med i ett nytt ingenjörsteam (antingen internt eller externt) är onboardingprocessen avgörande för att bestämma hur snabbt en ny lagmedlem känner sig redo att bidra. Från att ställa in deras kodningsmiljö till att gå igenom funktionsdokumentationen, finns det mycket som behövs för att komma ikapp och vara redo att ta sig an nytt arbete.
För många ingenjörsteam blir onboardingprocessen mödosam för en annan lagmedlem, som utses som den nya medarbetarens “kompis” och som skulle gå igenom denna information i realtid. Men genom att ge sitt team expertverifierade, uppdaterade kort i Guru, ger RS21:s ingenjörsledare nya anställningar flexibiliteten att onboarda i sin egen takt. Detta låter dem spara tid med sin onboarding “kompis” för mer relationsbyggande eller kvarstående frågor.
När en ny ingenjör går med i RS21:s team loggar de in på Guru för att börja arbeta med sina onboardingmaterial. De kommer att titta igenom en “Team Info” tavla där de kan lära känna lite om sina lagkamrater, använda infrastrukturskort för att ställa in sina miljöer korrekt och läsa igenom sitt teams kodningsstandarder för att få en uppfattning om hur de bäst samverkar med sina nya kollegor.
På samma sätt, när en ingenjör går med eller flyttar till ett nytt team, görs deras onboarding i Guru. De kommer att använda livshistorik kort för att lära känna sina lagkamrater, se guider om hur de bör förvänta sig att arbeta tillsammans, och bläddra i sitt nya teams samling i Guru för att bli bekanta med produktfunktionerna och områdena de nu ansvarar för.
Bästa praxis och teamstandarder
När hela teamet har onboardats, har pågående resurser, som kodningsstandarder och dokumentationsbästa praxis, också en plats i Guru. När de dokumenteras på ett sätt som är tillgängligt i deras arbetsflöden, gör detta det enklare för ingenjörer att samarbeta produktivt med resten av sitt team och resten av företaget. Det förhindrar dem också från att behöva memorera några policyer eller procedurer eller värre, bokmärka och förlita sig på föråldrade dokument.
RS21:s ingenjörssamling i Guru innehåller en tavla som är dedikerad till processriktlinjer, inklusive kort med instruktioner för att slå samman kod, skapa ett bash-skript, begära en kodgranskning och mer. De har också tavlor dedikerade till sitt teams överenskomna kodningssyntaxstil, instruktioner för AWS-inställningar, information för systemadministratörer och mer. De har till och med ofta använda kodsnuttar tillgängliga för enkel kopiering och klistring i Guru-kort.
Förutom dessa ingenjörsspecifika kort är Guru också en bra plats för ingenjörer att få tillgång till tvärfunktionella bästa praxis och riktlinjer för interteamprocesser. Till exempel, RS21:s team genomför asynkrona diskussioner som använder Guru för att ge teammedlemmarna mer tid att svara genomtänkt, och för att ge alla en jämn och rättvis plattform att bidra. Instruktioner för hur man ställer in och övervakar dessa diskussioner bevaras i en Guru-mall, så att vem som helst enkelt kan starta en när det behövs.
På Guru engagerar vi team utanför vår produktutvecklingsorganisation för att hjälpa till med vår kvalitetskontroll (QA) process. Med mer varierade åsikter är vi bättre kapabla att identifiera buggar, utforska potentiella kundutmaningar och skydda oss mot dem innan lansering. Men en process så teknisk som QA kräver dokumenterade instruktioner och procedurer när man involverar tvärfunktionella team. Innan vi påbörjar QA för en ny funktion kommer en ingenjörsledare att använda vår QA-processmall för att skapa en helhetslösning för allt som vårt team och intressenter kommer att behöva för end-to-end QA. När vi är redo att påbörja QA, kommer de att skicka detta som en meddelande till teamet och intressenterna och inkludera de aktiva QA-datumen i meddelandet.
Projektplanering och utvecklingsdokumentation
När ett nytt utvecklingsprojekt inleds, följer det mycket dokumentation för att säkerställa att alla har den fullständiga kontext de behöver för att spela sin roll. Efter ett kick-off-möte förlitar sig ingenjörerna på kravdokument från produktteam, de mest aktuella funktionsdesignerna från sitt UX-team, kopior från sitt marknadsförings- eller copywritingteam, och mer.
Och, självklart, kommer de ofta att behöva referera till all teknisk dokumentation som påverkar funktionen de arbetar med, eller som de behöver uppdatera senare under utvecklingen.
På Guru håller vi koll på de olika resurser som behövs för produktutveckling i ett Aktiva projektresurskort, som champas av varje projekts ingenjörsledare. Dessa kort är ingenjörsteamets gå-till-resurs under de tidiga skedena av producentutvecklingslivscykeln, och hålls uppdaterade för att avspegla eventuella förändringar.
När utvecklingsprocessen fortskrider måste samarbetet mellan ingenjör och design hållas i synk. Men på grund av den ofta asynkrona och avlägsna arbetsformen kan designers och ingenjörer inte alltid ringa ett Zoom-samtal för att diskutera eventuella problem eller feedback. För att säkerställa att de följer vår överenskomna interna protokoll för att begära designfeedback använder vårt ingenjörsteam vår designfeedback för UI-ändringar arbetsflöde dokumenterat i Guru.
Framtidssäkrad dokumentation
Dokumentation har alltid varit och kommer alltid att vara en nödvändig del av en ingenjörs arbete. Men det som en gång fick fram smärtsamma stön och plågade suckar kan nu bli en enkel, naturlig del av deras dagliga arbete när det ingrips direkt i deras arbetsflöde. Gurus webbläsartillägg för in dokumentation direkt till de platser ingenjörerna behöver det, snarare än att tvinga dem att byta kontext för att komma åt den, och kort med expertverifiering tar bort pressen från de långa artiklarna från förr som var ett huvudvärk att skriva och än svårare att underhålla. Så varför förvärra den tekniska skulden med föråldrad dokumentation när du enkelt kan framtidssäkra den just nu? Börja idag gratis.
Alla ingenjörsteam förlitar sig på någon typ av dokumentation för att kommunicera viktig produktinformation med sina kollegor. För små team som just har börjat kan detta vara så enkelt som ett Google Doc, och för större team med komplexa produkter kan detta vara en hierarkisk wiki. Beroende på hur deras företag är uppbyggt, kan andra team (som HR eller marknadsföring) också använda denna wiki, eller ha andra områden där de lagrar sin teams information.
När man går med i ett nytt ingenjörsteam (antingen internt eller externt) är onboardingprocessen avgörande för att bestämma hur snabbt en ny lagmedlem känner sig redo att bidra. Från att ställa in deras kodningsmiljö till att gå igenom funktionsdokumentationen, finns det mycket som behövs för att komma ikapp och vara redo att ta sig an nytt arbete.
För många ingenjörsteam blir onboardingprocessen mödosam för en annan lagmedlem, som utses som den nya medarbetarens “kompis” och som skulle gå igenom denna information i realtid. Men genom att ge sitt team expertverifierade, uppdaterade kort i Guru, ger RS21:s ingenjörsledare nya anställningar flexibiliteten att onboarda i sin egen takt. Detta låter dem spara tid med sin onboarding “kompis” för mer relationsbyggande eller kvarstående frågor.
När en ny ingenjör går med i RS21:s team loggar de in på Guru för att börja arbeta med sina onboardingmaterial. De kommer att titta igenom en “Team Info” tavla där de kan lära känna lite om sina lagkamrater, använda infrastrukturskort för att ställa in sina miljöer korrekt och läsa igenom sitt teams kodningsstandarder för att få en uppfattning om hur de bäst samverkar med sina nya kollegor.
På samma sätt, när en ingenjör går med eller flyttar till ett nytt team, görs deras onboarding i Guru. De kommer att använda livshistorik kort för att lära känna sina lagkamrater, se guider om hur de bör förvänta sig att arbeta tillsammans, och bläddra i sitt nya teams samling i Guru för att bli bekanta med produktfunktionerna och områdena de nu ansvarar för.
Bästa praxis och teamstandarder
När hela teamet har onboardats, har pågående resurser, som kodningsstandarder och dokumentationsbästa praxis, också en plats i Guru. När de dokumenteras på ett sätt som är tillgängligt i deras arbetsflöden, gör detta det enklare för ingenjörer att samarbeta produktivt med resten av sitt team och resten av företaget. Det förhindrar dem också från att behöva memorera några policyer eller procedurer eller värre, bokmärka och förlita sig på föråldrade dokument.
RS21:s ingenjörssamling i Guru innehåller en tavla som är dedikerad till processriktlinjer, inklusive kort med instruktioner för att slå samman kod, skapa ett bash-skript, begära en kodgranskning och mer. De har också tavlor dedikerade till sitt teams överenskomna kodningssyntaxstil, instruktioner för AWS-inställningar, information för systemadministratörer och mer. De har till och med ofta använda kodsnuttar tillgängliga för enkel kopiering och klistring i Guru-kort.
Förutom dessa ingenjörsspecifika kort är Guru också en bra plats för ingenjörer att få tillgång till tvärfunktionella bästa praxis och riktlinjer för interteamprocesser. Till exempel, RS21:s team genomför asynkrona diskussioner som använder Guru för att ge teammedlemmarna mer tid att svara genomtänkt, och för att ge alla en jämn och rättvis plattform att bidra. Instruktioner för hur man ställer in och övervakar dessa diskussioner bevaras i en Guru-mall, så att vem som helst enkelt kan starta en när det behövs.
På Guru engagerar vi team utanför vår produktutvecklingsorganisation för att hjälpa till med vår kvalitetskontroll (QA) process. Med mer varierade åsikter är vi bättre kapabla att identifiera buggar, utforska potentiella kundutmaningar och skydda oss mot dem innan lansering. Men en process så teknisk som QA kräver dokumenterade instruktioner och procedurer när man involverar tvärfunktionella team. Innan vi påbörjar QA för en ny funktion kommer en ingenjörsledare att använda vår QA-processmall för att skapa en helhetslösning för allt som vårt team och intressenter kommer att behöva för end-to-end QA. När vi är redo att påbörja QA, kommer de att skicka detta som en meddelande till teamet och intressenterna och inkludera de aktiva QA-datumen i meddelandet.
Projektplanering och utvecklingsdokumentation
När ett nytt utvecklingsprojekt inleds, följer det mycket dokumentation för att säkerställa att alla har den fullständiga kontext de behöver för att spela sin roll. Efter ett kick-off-möte förlitar sig ingenjörerna på kravdokument från produktteam, de mest aktuella funktionsdesignerna från sitt UX-team, kopior från sitt marknadsförings- eller copywritingteam, och mer.
Och, självklart, kommer de ofta att behöva referera till all teknisk dokumentation som påverkar funktionen de arbetar med, eller som de behöver uppdatera senare under utvecklingen.
På Guru håller vi koll på de olika resurser som behövs för produktutveckling i ett Aktiva projektresurskort, som champas av varje projekts ingenjörsledare. Dessa kort är ingenjörsteamets gå-till-resurs under de tidiga skedena av producentutvecklingslivscykeln, och hålls uppdaterade för att avspegla eventuella förändringar.
När utvecklingsprocessen fortskrider måste samarbetet mellan ingenjör och design hållas i synk. Men på grund av den ofta asynkrona och avlägsna arbetsformen kan designers och ingenjörer inte alltid ringa ett Zoom-samtal för att diskutera eventuella problem eller feedback. För att säkerställa att de följer vår överenskomna interna protokoll för att begära designfeedback använder vårt ingenjörsteam vår designfeedback för UI-ändringar arbetsflöde dokumenterat i Guru.
Framtidssäkrad dokumentation
Dokumentation har alltid varit och kommer alltid att vara en nödvändig del av en ingenjörs arbete. Men det som en gång fick fram smärtsamma stön och plågade suckar kan nu bli en enkel, naturlig del av deras dagliga arbete när det ingrips direkt i deras arbetsflöde. Gurus webbläsartillägg för in dokumentation direkt till de platser ingenjörerna behöver det, snarare än att tvinga dem att byta kontext för att komma åt den, och kort med expertverifiering tar bort pressen från de långa artiklarna från förr som var ett huvudvärk att skriva och än svårare att underhålla. Så varför förvärra den tekniska skulden med föråldrad dokumentation när du enkelt kan framtidssäkra den just nu? Börja idag gratis.
Upplev kraften i Guru-plattformen förstahands - ta vår interaktiva produktturné
.webp)
