Wszystkie zespoły inżynieryjne polegają na jakimś narzędziu dokumentacyjnym, aby komunikować ważne informacje o produkcie z innymi kolegami. Dla niewielkich zespołów, które dopiero zaczynają, może to być tak proste jak dokument Google, a dla większych zespołów złożonych produktów, może to być hierarchiczne wiki. W zależności od struktury ich firmy, inne zespoły (takie jak HR czy marketing) mogą również korzystać z tego wiki lub mieć inne obszary, w których przechowują informacje o swoim zespole.
Dołączając do nowego zespołu inżynieryjnego (wewnętrznie lub zewnętrznie), proces wprowadzania na pokład jest kluczowy dla określenia, jak szybko nowy współpracownik poczuje się gotów do współpracy. Od skonfigurowania ich środowiska kodowania po przeglądanie dokumentacji funkcji, jest wiele rzeczy, które muszą zrobić, aby nadążyć i być gotowe na nowe zadania.
Dla wielu zespołów inżynieryjnych proces wprowadzania na pokład okazuje się być czasochłonny dla innego współpracownika, który jest wyznaczony jako „kolegą” nowego pracownika i przechodzi z nimi przez te informacje w czasie rzeczywistym. Jednak dostarczając swojemu zespołowi Karty zweryfikowane przez ekspertów, aktualne w Guru, liderzy inżynieryjni RS21 dają nowym pracownikom elastyczność w wprowadzaniu na pokład w swoim tempie. To pozwala im zaoszczędzić czas z ich „kolegą” do wprowadzania na pokład na budowanie relacji interpersonalnych lub zadawanie niejasnych pytań.
Gdy nowy inżynier dołączy do zespołu RS21, loguje się do Guru, aby zacząć pracować nad swoimi materiałami wprowadzającymi. Będą przeglądać Tablicę „Informacje o zespole”, gdzie będą mogli poznać swoich kolegów, korzystać z Kart infrastruktury, aby poprawnie skonfigurować swoje środowiska i czytać standardy kodowania ich zespołu, aby uzyskać pomysł, jak najlepiej współpracować z nowymi kolegami.
Podobnie, w Guru, gdy inżynier dołącza lub przechodzi do nowego zespołu, ich wprowadzenie na pokład odbywa się w Guru. Będą korzystać z Kart opowiadających historię życia, aby poznać swoich kolegów, zobaczyć przewodniki po współpracy, i przeglądać Kolekcję swojego nowego zespołu w Guru, aby zapoznać się z cechami produktów i obszarami, za które teraz odpowiadają.
Najlepsze praktyki i standardy zespołowe
Gdy cały zespół zostanie wprowadzony, trwałe zasoby, takie jak standardy kodowania i najlepsze praktyki dokumentacyjne, również mają swoje miejsce w Guru. Kiedy są udokumentowane w sposób dostępny w ich przepływach pracy, ułatwia to inżynierom produktywną współpracę z resztą zespołu i całej firmy. Zapobiega to również potrzebie zapamiętywania jakichkolwiek zasad lub procedur, a co gorsza, zaznaczania i polegania na przestarzałych dokumentach.
Kolekcja Inżynieryjna RS21 w Guru zawiera Tablicę poświęconą wytycznym procesowym, w tym Karty z instrukcjami dotyczącymi łączenia kodu, tworzenia skryptu bash, żądania przeglądów kodu i nie tylko. Mają również Tablice poświęcone uzgodnionemu przez ich zespół stylowi składni kodowania, instrukcjom ustawień AWS, informacjom dla administratorów systemów i nie tylko. Nawet mają często używane fragmenty kodu dostępne do łatwego kopiowania i wklejania w Kartach Guru.
Poza tymi specyficznymi dla inżynierii Kartami, Guru jest także doskonałym miejscem dla inżynierów, aby uzyskać dostęp do najlepszych praktyk międzyzespołowych oraz wytycznych dotyczących procesów międzyzespołowych. Na przykład, zespół RS21 prowadzi dyskusje asynchroniczne przy użyciu Guru, aby dać członkom zespołu więcej czasu na przemyślane odpowiedzi i zapewnić każdemu równą i sprawiedliwą platformę do wkładu. Instrukcje jak ustawić i monitorować te dyskusje są przechowywane w szablonie Guru, aby każdy mógł łatwo je uruchomić, gdy zajdzie potrzeba.
W Guru angażujemy zespoły zewnętrzne z naszej organizacji rozwoju produktu, aby wspierały nasz proces zapewnienia jakości (QA). Dzięki bardziej zróżnicowanym poglądom lepiej potrafimy identyfikować błędy, badać potencjalne wyzwania klientów i chronić się przed nimi przed wydaniem. Jednak tak techniczny proces jak QA wymaga udokumentowanych instrukcji i procedur, gdy angażuje zespoły międzyfunkcyjne. Przed rozpoczęciem QA dla nowej funkcji, lider zespołu inżynieryjnego skorzysta z naszego szablonu procesu QA, aby stworzyć jedno miejsce, które wszystko, co nasz zespół i zainteresowane strony potrzebują do kompleksowego QA. Kiedy jesteśmy gotowi, aby rozpocząć QA, wyślą to jako ogłoszenie do zespołu i interesariuszy i dołączą aktywne daty QA do wiadomości.
Planowanie projektu i dokumentacja rozwoju
Kiedykolwiek rozpoczyna się nowy projekt rozwoju, dokumentacja towarzysząca zapewnia wszystkim pełny kontekst, którego potrzebują, aby odegrać swoją rolę. Po spotkaniu inauguracyjnym inżynierowie polegają na dokumentach wymagań od zespołów produktowych, najaktualniejszych projektach funkcjonalnych z zespołu UX, tekstach od zespołu marketingowego lub copywriterskiego i więcej.
I oczywiście często będą musieli odnosić się do wszelkiej dokumentacji technicznej, która ma wpływ na funkcję, nad którą pracują, lub którą będą musieli później zaktualizować w procesie rozwoju.
W Guru śledzimy różne zasoby potrzebne do rozwoju produktu w Karcie zasobów aktywnych projektów, której prowadzi każdy lider inżynieryjny projektu. Te Karty są głównym źródłem zespołu inżynieryjnego w początkowych etapach cyklu życia rozwoju produktu i są na bieżąco aktualizowane, aby odzwierciedlić wszelkie zmiany.
W miarę postępu procesu rozwoju, współpraca między inżynierią a projektowaniem musi być utrzymywana w synchronizacji. Jednak z powodu często asynchronicznego i zdalnego charakteru pracy, projektanci i inżynierowie nie mogą zawsze uczestniczyć w rozmowach na Zoomie, aby omówić jakiekolwiek problemy lub uwagi. Aby upewnić się, że przestrzegają uzgodnionego przez nas wewnętrznego protokołu w celu uzyskania informacji zwrotnych dotyczących projektowania, nasz zespół inżynieryjny korzysta z naszego feedbacku projektowego dla dokumentacji zmian UI wymaganym w Guru.
Dokumentacja zabezpieczona na przyszłość
Dokumentacja była i zawsze będzie niezbędną częścią pracy inżyniera. Lecz to, co kiedyś wzbudzało bolesne jęki i zdenerwowane westchnienia, może stać się prostą, naturalną częścią ich codzienności, gdy jest bezpośrednio włączona do ich przepływu pracy. Rozszerzenie przeglądarki Guru przynosi dokumentację bezpośrednio w miejsca, których inżynierowie potrzebują, zamiast zmuszać ich do przełączania kontekstu w celu uzyskania dostępu do niej, a krótkoterminowe Karty zweryfikowane przez ekspertów odciągają presję z długotrwałych artykułów z przeszłości, które były uciążliwe do napisania i jeszcze trudniejsze do utrzymania. Więc po co kumulować dług technologiczny z przestarzałą dokumentacją, kiedy można ją łatwo zabezpieczyć na przyszłość już teraz? Zacznij dzisiaj za darmo.
Wszystkie zespoły inżynieryjne polegają na jakimś narzędziu dokumentacyjnym, aby komunikować ważne informacje o produkcie z innymi kolegami. Dla niewielkich zespołów, które dopiero zaczynają, może to być tak proste jak dokument Google, a dla większych zespołów złożonych produktów, może to być hierarchiczne wiki. W zależności od struktury ich firmy, inne zespoły (takie jak HR czy marketing) mogą również korzystać z tego wiki lub mieć inne obszary, w których przechowują informacje o swoim zespole.
Dołączając do nowego zespołu inżynieryjnego (wewnętrznie lub zewnętrznie), proces wprowadzania na pokład jest kluczowy dla określenia, jak szybko nowy współpracownik poczuje się gotów do współpracy. Od skonfigurowania ich środowiska kodowania po przeglądanie dokumentacji funkcji, jest wiele rzeczy, które muszą zrobić, aby nadążyć i być gotowe na nowe zadania.
Dla wielu zespołów inżynieryjnych proces wprowadzania na pokład okazuje się być czasochłonny dla innego współpracownika, który jest wyznaczony jako „kolegą” nowego pracownika i przechodzi z nimi przez te informacje w czasie rzeczywistym. Jednak dostarczając swojemu zespołowi Karty zweryfikowane przez ekspertów, aktualne w Guru, liderzy inżynieryjni RS21 dają nowym pracownikom elastyczność w wprowadzaniu na pokład w swoim tempie. To pozwala im zaoszczędzić czas z ich „kolegą” do wprowadzania na pokład na budowanie relacji interpersonalnych lub zadawanie niejasnych pytań.
Gdy nowy inżynier dołączy do zespołu RS21, loguje się do Guru, aby zacząć pracować nad swoimi materiałami wprowadzającymi. Będą przeglądać Tablicę „Informacje o zespole”, gdzie będą mogli poznać swoich kolegów, korzystać z Kart infrastruktury, aby poprawnie skonfigurować swoje środowiska i czytać standardy kodowania ich zespołu, aby uzyskać pomysł, jak najlepiej współpracować z nowymi kolegami.
Podobnie, w Guru, gdy inżynier dołącza lub przechodzi do nowego zespołu, ich wprowadzenie na pokład odbywa się w Guru. Będą korzystać z Kart opowiadających historię życia, aby poznać swoich kolegów, zobaczyć przewodniki po współpracy, i przeglądać Kolekcję swojego nowego zespołu w Guru, aby zapoznać się z cechami produktów i obszarami, za które teraz odpowiadają.
Najlepsze praktyki i standardy zespołowe
Gdy cały zespół zostanie wprowadzony, trwałe zasoby, takie jak standardy kodowania i najlepsze praktyki dokumentacyjne, również mają swoje miejsce w Guru. Kiedy są udokumentowane w sposób dostępny w ich przepływach pracy, ułatwia to inżynierom produktywną współpracę z resztą zespołu i całej firmy. Zapobiega to również potrzebie zapamiętywania jakichkolwiek zasad lub procedur, a co gorsza, zaznaczania i polegania na przestarzałych dokumentach.
Kolekcja Inżynieryjna RS21 w Guru zawiera Tablicę poświęconą wytycznym procesowym, w tym Karty z instrukcjami dotyczącymi łączenia kodu, tworzenia skryptu bash, żądania przeglądów kodu i nie tylko. Mają również Tablice poświęcone uzgodnionemu przez ich zespół stylowi składni kodowania, instrukcjom ustawień AWS, informacjom dla administratorów systemów i nie tylko. Nawet mają często używane fragmenty kodu dostępne do łatwego kopiowania i wklejania w Kartach Guru.
Poza tymi specyficznymi dla inżynierii Kartami, Guru jest także doskonałym miejscem dla inżynierów, aby uzyskać dostęp do najlepszych praktyk międzyzespołowych oraz wytycznych dotyczących procesów międzyzespołowych. Na przykład, zespół RS21 prowadzi dyskusje asynchroniczne przy użyciu Guru, aby dać członkom zespołu więcej czasu na przemyślane odpowiedzi i zapewnić każdemu równą i sprawiedliwą platformę do wkładu. Instrukcje jak ustawić i monitorować te dyskusje są przechowywane w szablonie Guru, aby każdy mógł łatwo je uruchomić, gdy zajdzie potrzeba.
W Guru angażujemy zespoły zewnętrzne z naszej organizacji rozwoju produktu, aby wspierały nasz proces zapewnienia jakości (QA). Dzięki bardziej zróżnicowanym poglądom lepiej potrafimy identyfikować błędy, badać potencjalne wyzwania klientów i chronić się przed nimi przed wydaniem. Jednak tak techniczny proces jak QA wymaga udokumentowanych instrukcji i procedur, gdy angażuje zespoły międzyfunkcyjne. Przed rozpoczęciem QA dla nowej funkcji, lider zespołu inżynieryjnego skorzysta z naszego szablonu procesu QA, aby stworzyć jedno miejsce, które wszystko, co nasz zespół i zainteresowane strony potrzebują do kompleksowego QA. Kiedy jesteśmy gotowi, aby rozpocząć QA, wyślą to jako ogłoszenie do zespołu i interesariuszy i dołączą aktywne daty QA do wiadomości.
Planowanie projektu i dokumentacja rozwoju
Kiedykolwiek rozpoczyna się nowy projekt rozwoju, dokumentacja towarzysząca zapewnia wszystkim pełny kontekst, którego potrzebują, aby odegrać swoją rolę. Po spotkaniu inauguracyjnym inżynierowie polegają na dokumentach wymagań od zespołów produktowych, najaktualniejszych projektach funkcjonalnych z zespołu UX, tekstach od zespołu marketingowego lub copywriterskiego i więcej.
I oczywiście często będą musieli odnosić się do wszelkiej dokumentacji technicznej, która ma wpływ na funkcję, nad którą pracują, lub którą będą musieli później zaktualizować w procesie rozwoju.
W Guru śledzimy różne zasoby potrzebne do rozwoju produktu w Karcie zasobów aktywnych projektów, której prowadzi każdy lider inżynieryjny projektu. Te Karty są głównym źródłem zespołu inżynieryjnego w początkowych etapach cyklu życia rozwoju produktu i są na bieżąco aktualizowane, aby odzwierciedlić wszelkie zmiany.
W miarę postępu procesu rozwoju, współpraca między inżynierią a projektowaniem musi być utrzymywana w synchronizacji. Jednak z powodu często asynchronicznego i zdalnego charakteru pracy, projektanci i inżynierowie nie mogą zawsze uczestniczyć w rozmowach na Zoomie, aby omówić jakiekolwiek problemy lub uwagi. Aby upewnić się, że przestrzegają uzgodnionego przez nas wewnętrznego protokołu w celu uzyskania informacji zwrotnych dotyczących projektowania, nasz zespół inżynieryjny korzysta z naszego feedbacku projektowego dla dokumentacji zmian UI wymaganym w Guru.
Dokumentacja zabezpieczona na przyszłość
Dokumentacja była i zawsze będzie niezbędną częścią pracy inżyniera. Lecz to, co kiedyś wzbudzało bolesne jęki i zdenerwowane westchnienia, może stać się prostą, naturalną częścią ich codzienności, gdy jest bezpośrednio włączona do ich przepływu pracy. Rozszerzenie przeglądarki Guru przynosi dokumentację bezpośrednio w miejsca, których inżynierowie potrzebują, zamiast zmuszać ich do przełączania kontekstu w celu uzyskania dostępu do niej, a krótkoterminowe Karty zweryfikowane przez ekspertów odciągają presję z długotrwałych artykułów z przeszłości, które były uciążliwe do napisania i jeszcze trudniejsze do utrzymania. Więc po co kumulować dług technologiczny z przestarzałą dokumentacją, kiedy można ją łatwo zabezpieczyć na przyszłość już teraz? Zacznij dzisiaj za darmo.
.webp)
