Scopri come il cliente RS21 e i team di ingegneria di Guru utilizzano Guru per mettere a prova il futuro della loro documentazione di sviluppo, inclusi processi e modelli.
Tutti i team di ingegneria si basano su qualche tipo di strumento di documentazione per comunicare informazioni importanti sui prodotti con i loro colleghi. Per i piccoli team che stanno appena iniziando, questo potrebbe essere semplice come un Google Doc e per team più grandi con prodotti complessi, potrebbe essere un wiki gerarchico. A seconda di come è strutturata la loro azienda, altri team (come HR o marketing) possono usare questo wiki, oppure avere altre aree dove conservano le informazioni del loro team.
Quando ci si unisce a un nuovo team di ingegneria (internamente o esternamente), il processo di onboarding è fondamentale per determinare quanto rapidamente un nuovo membro del team si sente pronto a contribuire. Dall'impostazione del loro ambiente di codifica alla consultazione della documentazione delle funzionalità, c'è molto da fare per mettersi al passo e pronti a intraprendere nuovi lavori.
Per molti team di ingegneria, il processo di onboarding risulta laborioso per un altro compagno di squadra, che è designato come "buddy" del nuovo dipendente e che lo guiderà attraverso queste informazioni in tempo reale. Ma fornendo al loro team Schede verificate da esperti e aggiornate in Guru, i leader ingegneristici di RS21 danno ai nuovi assunti la flessibilità di adattarsi al loro ritmo. Questo permette loro di risparmiare tempo con il loro "buddy" per costruire relazioni interpersonali o affrontare domande in sospeso.
Quando un nuovo ingegnere si unisce al team di RS21, accede a Guru per iniziare a lavorare sui loro materiali di onboarding. Esamineranno un' "Informazioni sul Team" Board dove possono conoscere un po' i loro compagni di squadra, utilizzare Schede infrastrutturali per configurare correttamente i loro ambienti, e leggere gli standard di codifica del loro team per avere un'idea di come collaborare al meglio con i loro nuovi colleghi.
Allo stesso modo, in Guru, quando un ingegnere si unisce o passa a un nuovo team, il loro onboarding viene effettuato in Guru. Utilizzeranno Schede della mia storia di vita per conoscere i loro compagni di squadra, vedere guide su come dovrebbero aspettarsi di lavorare insieme, e sfogliare la Collezione del loro nuovo team in Guru per familiarizzare con le funzionalità del prodotto e le aree di cui ora sono responsabili.
Migliori Pratiche e Standard del Team
Una volta che l'intero team è stato onboardato, risorse continue, come standard di codifica e migliori pratiche di documentazione, hanno anche una casa in Guru. Quando sono documentati in un modo accessibile nei loro flussi di lavoro, questi rendono più facile per gli ingegneri collaborare in modo produttivo con il resto del loro team e il resto dell'azienda. Ciò impedisce anche loro di dover memorizzare politiche o procedure o, peggio, di segnare e fare affidamento su documenti obsoleti.
La Collezione di Ingegneria di RS21 in Guru include una Board dedicata alle linee guida sui processi, comprese le Schede con istruzioni per unire codice, creare uno script bash, richiedere una revisione del codice, e altro ancora. Hanno anche Board dedicate allo stile di sintassi di codifica concordato dal loro team, istruzioni per l'impostazione di AWS, informazioni sugli amministratori di sistema, e altro ancora. Hanno persino frammenti di codice utilizzati frequentemente disponibili per facile copia e incolla nelle Schede di Guru.
Oltre a queste Schede specifiche per l'ingegneria, Guru è anche un ottimo posto per gli ingegneri per accedere a migliori pratiche e linee guida trasversali per processi inter-team. Ad esempio, il team di RS21 conduce discussioni asincrone utilizzando Guru per dare ai membri del team più tempo per rispondere in modo ponderato e dare a tutti una piattaforma equa per contribuire. Le istruzioni per come impostare e monitorare queste discussioni sono conservate in un modello Guru, in modo che chiunque possa crearne uno con facilità quando necessario.
In Guru, coinvolgiamo team al di fuori della nostra organizzazione di sviluppo dei prodotti per assistere nel nostro processo di assicurazione della qualità (QA). Con punti di vista più diversi, siamo in grado di identificare meglio i bug, esplorare potenziali sfide per i clienti e proteggere contro di esse prima del rilascio. Ma un processo tecnico come il QA richiede istruzioni e procedure documentate quando coinvolge team trasversali. Prima di iniziare il QA per una nuova funzionalità, un team lead di ingegneria utilizzerà il nostro modello di processo QA per creare un punto di riferimento per tutto ciò di cui il nostro team e le parti interessate hanno bisogno per un QA end-to-end. Quando siamo pronti per iniziare il QA, lo invieranno come un annuncio al team e alle parti interessate, e includeranno le date attive di QA nel messaggio.
Pianificazione Progetti e Documentazione Sviluppo
Ogni volta che un nuovo progetto di sviluppo ha inizio, segue molta documentazione per garantire che tutti abbiano il contesto completo necessario per svolgere il proprio ruolo. Dopo una riunione di kickoff, gli ingegneri si affidano a documenti di requisiti dei team di prodotto, ai design funzionali più recenti del loro team UX, a testi del loro team di marketing o copywriting e altro ancora.
E, ovviamente, dovranno frequentemente fare riferimento a qualsiasi documentazione tecnica che impatti sulla funzionalità su cui stanno lavorando, o che dovranno aggiornare più avanti nello sviluppo.
In Guru, teniamo traccia delle varie risorse necessarie per lo sviluppo del prodotto in una Scheda Risorse Progetti Attivi, sostenuta da ciascun responsabile di progetto. Queste Schede sono la risorsa di riferimento del team di ingegneria durante le fasi iniziali del ciclo di vita dello sviluppo del prodotto, e vengono mantenute aggiornate per riflettere eventuali cambiamenti nel tempo.
Con il progresso del processo di sviluppo, la collaborazione tra ingegneria e design deve essere mantenuta in sincronia. Ma a causa della natura spesso asincrona e remota del lavoro, designer e ingegneri non possono sempre partecipare a una chiamata Zoom per discutere problemi o feedback. Per garantire che seguano il protocollo interno concordato per la richiesta di feedback sul design, il nostro team di ingegneria utilizza il nostro Feedback sul Design per le modifiche all'UI documentato in Guru.
Documentazione a prova di futuro
La documentazione è sempre stata e sarà sempre una parte necessaria del lavoro di un ingegnere. Ma ciò che un tempo suscitava gemiti dolorosi e sospiri angosciati può diventare una parte semplice e naturale della loro vita quotidiana quando viene integrato direttamente nel loro flusso di lavoro. L'estensione del browser di Guru porta la documentazione direttamente nei luoghi in cui gli ingegneri ne hanno bisogno, piuttosto che costringerli a cambiare contesto per accedervi, e Schede brevi verificate da esperti alleviano la pressione dagli articoli lunghi del passato che erano un mal di testa da scrivere e persino più difficili da mantenere. Allora perché accumulare debito tecnico con documentazione obsoleta quando puoi facilmente metterla a prova di futuro proprio ora? Inizia oggi gratuitamente.
Tutti i team di ingegneria si basano su qualche tipo di strumento di documentazione per comunicare informazioni importanti sui prodotti con i loro colleghi. Per i piccoli team che stanno appena iniziando, questo potrebbe essere semplice come un Google Doc e per team più grandi con prodotti complessi, potrebbe essere un wiki gerarchico. A seconda di come è strutturata la loro azienda, altri team (come HR o marketing) possono usare questo wiki, oppure avere altre aree dove conservano le informazioni del loro team.
Quando ci si unisce a un nuovo team di ingegneria (internamente o esternamente), il processo di onboarding è fondamentale per determinare quanto rapidamente un nuovo membro del team si sente pronto a contribuire. Dall'impostazione del loro ambiente di codifica alla consultazione della documentazione delle funzionalità, c'è molto da fare per mettersi al passo e pronti a intraprendere nuovi lavori.
Per molti team di ingegneria, il processo di onboarding risulta laborioso per un altro compagno di squadra, che è designato come "buddy" del nuovo dipendente e che lo guiderà attraverso queste informazioni in tempo reale. Ma fornendo al loro team Schede verificate da esperti e aggiornate in Guru, i leader ingegneristici di RS21 danno ai nuovi assunti la flessibilità di adattarsi al loro ritmo. Questo permette loro di risparmiare tempo con il loro "buddy" per costruire relazioni interpersonali o affrontare domande in sospeso.
Quando un nuovo ingegnere si unisce al team di RS21, accede a Guru per iniziare a lavorare sui loro materiali di onboarding. Esamineranno un' "Informazioni sul Team" Board dove possono conoscere un po' i loro compagni di squadra, utilizzare Schede infrastrutturali per configurare correttamente i loro ambienti, e leggere gli standard di codifica del loro team per avere un'idea di come collaborare al meglio con i loro nuovi colleghi.
Allo stesso modo, in Guru, quando un ingegnere si unisce o passa a un nuovo team, il loro onboarding viene effettuato in Guru. Utilizzeranno Schede della mia storia di vita per conoscere i loro compagni di squadra, vedere guide su come dovrebbero aspettarsi di lavorare insieme, e sfogliare la Collezione del loro nuovo team in Guru per familiarizzare con le funzionalità del prodotto e le aree di cui ora sono responsabili.
Migliori Pratiche e Standard del Team
Una volta che l'intero team è stato onboardato, risorse continue, come standard di codifica e migliori pratiche di documentazione, hanno anche una casa in Guru. Quando sono documentati in un modo accessibile nei loro flussi di lavoro, questi rendono più facile per gli ingegneri collaborare in modo produttivo con il resto del loro team e il resto dell'azienda. Ciò impedisce anche loro di dover memorizzare politiche o procedure o, peggio, di segnare e fare affidamento su documenti obsoleti.
La Collezione di Ingegneria di RS21 in Guru include una Board dedicata alle linee guida sui processi, comprese le Schede con istruzioni per unire codice, creare uno script bash, richiedere una revisione del codice, e altro ancora. Hanno anche Board dedicate allo stile di sintassi di codifica concordato dal loro team, istruzioni per l'impostazione di AWS, informazioni sugli amministratori di sistema, e altro ancora. Hanno persino frammenti di codice utilizzati frequentemente disponibili per facile copia e incolla nelle Schede di Guru.
Oltre a queste Schede specifiche per l'ingegneria, Guru è anche un ottimo posto per gli ingegneri per accedere a migliori pratiche e linee guida trasversali per processi inter-team. Ad esempio, il team di RS21 conduce discussioni asincrone utilizzando Guru per dare ai membri del team più tempo per rispondere in modo ponderato e dare a tutti una piattaforma equa per contribuire. Le istruzioni per come impostare e monitorare queste discussioni sono conservate in un modello Guru, in modo che chiunque possa crearne uno con facilità quando necessario.
In Guru, coinvolgiamo team al di fuori della nostra organizzazione di sviluppo dei prodotti per assistere nel nostro processo di assicurazione della qualità (QA). Con punti di vista più diversi, siamo in grado di identificare meglio i bug, esplorare potenziali sfide per i clienti e proteggere contro di esse prima del rilascio. Ma un processo tecnico come il QA richiede istruzioni e procedure documentate quando coinvolge team trasversali. Prima di iniziare il QA per una nuova funzionalità, un team lead di ingegneria utilizzerà il nostro modello di processo QA per creare un punto di riferimento per tutto ciò di cui il nostro team e le parti interessate hanno bisogno per un QA end-to-end. Quando siamo pronti per iniziare il QA, lo invieranno come un annuncio al team e alle parti interessate, e includeranno le date attive di QA nel messaggio.
Pianificazione Progetti e Documentazione Sviluppo
Ogni volta che un nuovo progetto di sviluppo ha inizio, segue molta documentazione per garantire che tutti abbiano il contesto completo necessario per svolgere il proprio ruolo. Dopo una riunione di kickoff, gli ingegneri si affidano a documenti di requisiti dei team di prodotto, ai design funzionali più recenti del loro team UX, a testi del loro team di marketing o copywriting e altro ancora.
E, ovviamente, dovranno frequentemente fare riferimento a qualsiasi documentazione tecnica che impatti sulla funzionalità su cui stanno lavorando, o che dovranno aggiornare più avanti nello sviluppo.
In Guru, teniamo traccia delle varie risorse necessarie per lo sviluppo del prodotto in una Scheda Risorse Progetti Attivi, sostenuta da ciascun responsabile di progetto. Queste Schede sono la risorsa di riferimento del team di ingegneria durante le fasi iniziali del ciclo di vita dello sviluppo del prodotto, e vengono mantenute aggiornate per riflettere eventuali cambiamenti nel tempo.
Con il progresso del processo di sviluppo, la collaborazione tra ingegneria e design deve essere mantenuta in sincronia. Ma a causa della natura spesso asincrona e remota del lavoro, designer e ingegneri non possono sempre partecipare a una chiamata Zoom per discutere problemi o feedback. Per garantire che seguano il protocollo interno concordato per la richiesta di feedback sul design, il nostro team di ingegneria utilizza il nostro Feedback sul Design per le modifiche all'UI documentato in Guru.
Documentazione a prova di futuro
La documentazione è sempre stata e sarà sempre una parte necessaria del lavoro di un ingegnere. Ma ciò che un tempo suscitava gemiti dolorosi e sospiri angosciati può diventare una parte semplice e naturale della loro vita quotidiana quando viene integrato direttamente nel loro flusso di lavoro. L'estensione del browser di Guru porta la documentazione direttamente nei luoghi in cui gli ingegneri ne hanno bisogno, piuttosto che costringerli a cambiare contesto per accedervi, e Schede brevi verificate da esperti alleviano la pressione dagli articoli lunghi del passato che erano un mal di testa da scrivere e persino più difficili da mantenere. Allora perché accumulare debito tecnico con documentazione obsoleta quando puoi facilmente metterla a prova di futuro proprio ora? Inizia oggi gratuitamente.
Scopri il potere della piattaforma Guru in prima persona - fai il nostro tour interattivo del prodotto
.webp)
