Skalowanie zespołu programistów z zewnętrznymi inżynierami bez utraty jakości kodu

Wprowadzenie

Najważniejsze informacje

1. Korzystaj z usług zewnętrznych inżynierów, gdy Twój plan działania jest zbyt napięty dla głównego zespołu.
2. Przed ich dołączeniem ustal proste wytyczne dotyczące jakości i podstawowy proces dostarczania.
3. Wprowadź zewnętrznych programistów za pomocą jasnej listy kontrolnej i jednego partnera kontaktowego.
4. Stosuj jeden wspólny zestaw zasad, przeglądów i wskaźników dla wszystkich inżynierów.
5. Aby zapewnić spójność rosnącego, zróżnicowanego zespołu, należy polegać na krótkich pisemnych aktualizacjach.

Dlaczego warto rozbudować zespół programistów o zewnętrznych inżynierów?

Należy rozbudować zespół programistów o zewnętrznych inżynierów, gdy plan działania jest pełny, a własni pracownicy nie są w stanie nadążyć w zdrowy sposób. Główna kwestia jest prosta: zewnętrzni inżynierowie powinni zwiększyć tempo pracy i umiejętności bez obniżania standardów jakości. Jeśli pomagają oni w dostarczaniu stabilnych rozwiązań, które można bezpiecznie utrzymywać, takie rozwiązanie ma sens. Jeśli powodują jedynie dodatkowy stres i przypadkowe zmiany, to nie jest to odpowiedni moment.

Wielu liderów w firmach produkujących produkty odczuwa tę samą presję. Zaległości rosną, terminy się przesuwają, a zatrudnienie dobrych inżynierów w Twoim mieście zajmuje dużo czasu. W tym momencie zaczynasz myśleć o rozbudowie zespołu inżynierów przy pomocy z zewnątrz. Możesz rozważyć outsourcing zespołu programistów z innego regionu lub mniejszą grupę bliżej Twojej strefy czasowej. Prawdziwym pytaniem nie jest to, czy możesz skorzystać z pomocy z zewnątrz, ale kiedy będzie ona wspierać Twój plan działania, a nie ukrywać głębsze problemy.

Jednym z powodów, dla których warto zaprosić zewnętrznych inżynierów, jest dostęp do umiejętności, których obecnie nie masz w firmie. Możesz potrzebować krótkoterminowego wsparcia w takich obszarach, jak dane, aplikacje mobilne lub nowe konfiguracje chmury. Być może nie chcesz budować zupełnie nowego zespołu wokół każdego nowego tematu. W takim przypadku rozbudowa zespołu programistów może zapewnić elastyczną warstwę wsparcia wokół Twojej podstawowej grupy. Zachowujesz podstawową wiedzę i kierunek działania wewnątrz firmy, a pomoc zewnętrzną wykorzystujesz do jasno określonych i skoncentrowanych zadań. W codziennym życiu wygląda to bardziej jak dodanie jednego spokojnego eksperta do zapracowanego zespołu niż stworzenie drugiej firmy.

Istnieje również bardzo podstawowy aspekt czasu i kosztów. Samodzielne zatrudnienie silnych pracowników może zająć wiele tygodni, a nawet miesięcy, a w tym czasie zaległości nie znikną. W tym przypadku można dostrzec wyraźne korzyści płynące ze wzmocnienia personelu IT. Można zatrudnić dodatkowych pracowników na określony czas i w określonym zakresie, jednocześnie rozważając długoterminowe zatrudnienie. W przypadku niektórych zespołów opcja ta pozwala wyrównać szczyty zapotrzebowania, zamiast wymuszać duży wzrost stałego zatrudnienia. Tego rodzaju rozwiązanie pozwala sprawdzić, jak dodatkowe zasoby wpływają na produkt, zanim na stałe zmienisz całą strukturę.

Możesz również wybrać różne modele dołączania tych osób do Twojego świata. W modelu zwiększania liczby pracowników dodajesz zewnętrznych inżynierów do swojego zespołu, a Twoi liderzy kierują ich codzienną pracą. W przypadku zespołu programistów nearshore pracownicy znajdują się w podobnej strefie czasowej i mogą dołączać do rozmów telefonicznych i czatów w normalnych godzinach pracy. Wiele firm współpracuje z doświadczonym partnerem w zakresie tworzenia oprogramowania, który wie już, jak prowadzić nearshore development i współpracować z zespołami wewnętrznymi. Im bardziej zbliżona jest kultura, strefa czasowa i narzędzia, tym łatwiej jest sprawić, aby wiele osób czuło się jak jeden zespół, nawet jeśli umowy są różne. Ta wspólna podstawa sprawia, że praca zewnętrzna wydaje się naturalna, a nie krucha.

Jak przygotować bazę kodu i procesy przed dodaniem zewnętrznego zespołu programistów?

Przygotowujesz się do pracy z zewnętrznym zespołem programistów, ustalając jasną i prostą podstawę dotyczącą sposobu tworzenia i dostarczania produktu. Przed przybyciem nowych osób potrzebujesz wspólnych zasad, podstawowych narzędzi i widocznego sposobu pracy. Bez tej podstawy każda zmiana zależy od osobistego stylu i pamięci, a nowe osoby nie mają możliwości odgadnięcia właściwej drogi. Dzięki tej podstawie nawet świeże spojrzenie może poruszać się w bezpiecznym i stałym rytmie.

Podstawę tę można traktować jako zabezpieczenie jakości kodu. Zabezpieczenia te to proste kontrole, które musi przejść każda zmiana, niezależnie od tego, kto ją wprowadził. Mogą one obejmować sposób nazywania elementów, formatowanie plików oraz znaczenie terminu „zakończone” w odniesieniu do każdego niewielkiego zadania. Gdy zabezpieczenia są takie same dla wszystkich, produkt wydaje się stabilny, nawet gdy zespół się powiększa i zmienia. Dzięki temu łatwiej jest zaufać całemu procesowi, a nie tylko osobom, które już znasz.

Potrzebna jest również podstawowa ciągła integracja i proces dostarczania. To długie wyrażenie opisuje prostą ideę. Za każdym razem, gdy ktoś zmienia kod, system przeprowadza kontrole i pomaga wprowadzać tę zmianę do użytkowników małymi, bezpiecznymi krokami. Ten proces może działać na popularnych platformach i może być uruchamiany przy każdym przesłaniu do głównego repozytorium kodu. Działający proces zamienia wiele małych zmian w przejrzystą linię postępu zamiast stosu dużych, przerażających wydań. Nowi pracownicy mogą nauczyć się tej ścieżki raz, a następnie podążać nią bez dodatkowych domysłów.

Testy są kluczową częścią tej ścieżki. Zautomatyzowane testowanie w CI/CD oznacza, że testy są uruchamiane samodzielnie za każdym razem, gdy ktoś udostępnia nowy kod. Możesz zacząć od prostych kontroli, które obejmują najczęściej używane ścieżki w Twoim produkcie. Z czasem możesz dodać więcej testów, gdy zauważysz, gdzie najczęściej pojawiają się błędy. Nawet niewielki zestaw stabilnych testów zapewnia większe bezpieczeństwo niż ogromna lista ręcznych kontroli, których nikt nie wykonuje na czas. Takie podejście pozwala zachować realizm i wspiera zarówno wewnętrznych, jak i zewnętrznych inżynierów.

Pomaga również przyjrzeć się starszym częściom systemu, zanim poprosisz innych o ich modyfikację. Tutaj pojawia się podstawowe zarządzanie długiem technicznym. Dług techniczny to sposób opisania kodu, który działa, ale jest trudny do zmiany bez ryzyka. Możesz oznaczyć strefy, które są bezpieczne dla nowych osób, oraz strefy, które nadal wymagają opieki ze strony najbardziej doświadczonych pracowników. Wiedząc, gdzie znajdują się ryzykowne części, możesz najpierw skierować zewnętrzny zespół programistów do bezpieczniejszych obszarów. Chroni to Twój produkt i pozwala nowym osobom uniknąć ukrytych pułapek.

Ostatnia część podstawy to proste bezpieczeństwo i dostęp. Bezpieczny cykl życia oprogramowania brzmi poważnie, ale opiera się na jasnych krokach. Dajesz ludziom tylko taki dostęp, jakiego potrzebują, chronisz prawdziwe dane użytkowników i ostrożnie traktujesz tajne klucze. Zapisujesz też, co robić, gdy coś pójdzie nie tak, nawet na małą skalę. Gdy bezpieczeństwo jest częścią normalnej pracy, zewnętrzni inżynierowie mogą dołączyć do Twojego procesu bez wywoływania nowych obaw. Twoje zespoły prawne i bezpieczeństwa również widzą, że ten rozwój jest zgodny z planem, a nie szybkim rozwiązaniem.

Jak wygląda bezpieczny plan wdrażania zewnętrznych programistów?

Bezpieczny plan wdrażania zewnętrznych programistów zapewnia im kontekst, narzędzia i jasne pierwsze kroki, nie rzucając ich od razu na głęboką wodę. Powinien on przypominać ścieżkę z przewodnikiem, gdzie każdy dzień ma prosty i realny cel. Gdy plan jest jasny, nowi pracownicy mogą wnieść wartość dodaną w ciągu tygodni, a nie miesięcy, a Twój zespół nie czuje się wyczerpany ciągłymi pytaniami.

Wdrażanie zewnętrznych programistów zaczyna się od wspólnego ustalenia, czego muszą się najpierw nauczyć. Obejmuje to Twój produkt, użytkowników i normalny sposób pracy. Lista kontrolna wdrożenia programistów może zawierać wszystkie te elementy w jednym miejscu. Może to być prosty dokument, który obie strony mogą otworzyć i dostosować. Widoczna lista kontrolna zamienia stwierdzenie „Myślę, że już im to powiedzieliśmy” na „Wiemy dokładnie, co zostało zrobione i co jest następne”. Ta niewielka zmiana eliminuje wiele cichego stresu dla wszystkich.

Oto prosta lista, która często sprawdza się jako podstawa takiej listy kontrolnej:

1. Zapewnij dostęp do kodu, narzędzia do śledzenia pracy i głównych czatów.
2. Kroki niezbędne do uruchomienia produktu na laptopie lub serwerze testowym.
3. Krótki przewodnik dla użytkowników, główne przepływy i kluczowe zasady biznesowe.
4. Nazwiska osób, które można zapytać o produkt, kod i narzędzia.
5. Dwa lub trzy małe, jasne zadania gotowe do pierwszej rzeczywistej zmiany.

Pomocne jest również wyznaczenie konkretnej osoby kontaktowej. Kierownik techniczny lub starszy inżynier może pełnić rolę opiekuna wdrożeniowego przez pierwsze tygodnie. Osoba ta może przeglądać wszystkie wczesne zmiany, odpowiadać na pytania i wyjaśniać, dlaczego poprzednie wybory wyglądały tak, a nie inaczej. Krótkie codzienne spotkania, nawet pięciominutowe rozmowy na czacie, mogą pomóc w utrzymaniu właściwego kierunku działań. Spokojny opiekun i stałe punkty kontaktowe mają większy wpływ na bezpieczne wdrożenie niż wielka rozmowa pierwszego dnia. Z czasem można przenieść więcej aktualizacji do komunikacji asynchronicznej dla zespołów programistycznych, na przykład w formie krótkich notatek pisemnych.

Z mojego doświadczenia wynika, że największym ryzykiem podczas wdrażania nowych pracowników jest ciche zamieszanie. Nowi pracownicy boją się, że zadają zbyt wiele pytań, a starzy członkowie zespołu mają nadzieję, że wszystko „zaskoczy” samoistnie. Jasny plan wdrażania zewnętrznych programistów i jedna osoba odpowiedzialna za ten plan zmieniają tę sytuację. Kiedy jedna osoba jest odpowiedzialna za ten proces, można dostrzec wzorce, naprawić słabe punkty i sprawić, że każda kolejna runda wdrażania będzie przebiegać płynniej. W ciągu kilku miesięcy plan staje się powtarzalnym atutem, a nie nowym wyzwaniem za każdym razem, gdy dołącza ktoś nowy.

Jak utrzymać jakość kodu w mieszanym zespole programistów, gdy zarządzasz zewnętrznymi programistami?

Jakość kodu w mieszanym zespole programistów utrzymuje się, stosując te same proste zasady, kontrole i liczby dla wszystkich. Jeśli chcesz, aby produkt był postrzegany jako jeden przejrzysty i bezpieczny system, Twoje standardy muszą mieć zastosowanie do wszystkich inżynierów. Gdy podzielisz zasady według rodzaju umowy, podzielisz również zaufanie i przejrzystość w zespole.

Zespół programistów mieszanych to grupa, w której inżynierowie wewnętrzni i zewnętrzni pracują nad tym samym produktem. Mogą oni pracować w różnych miejscach, ale mają jeden wspólny backlog i jeden magazyn kodu. Takie połączenie może być bardzo silne, ponieważ łączy głęboką wiedzę dziedzinową ze świeżym spojrzeniem. Może być również kruche, jeśli każda grupa kieruje się własnymi nawykami. Bez jasnych wytycznych takie połączenie zamienia się w klastry kodu, które wydają się różne i trudno jest między nimi przechodzić. W tym momencie jakość i szybkość zaczynają spadać.

Pomocne są tutaj proste najlepsze praktyki dotyczące przeglądu kodu. Każda zmiana powinna zostać sprawdzona przez co najmniej jedną osobę, niezależnie od tego, kto ją wprowadził. Podczas przeglądu należy zwrócić uwagę nie tylko na styl, ale także na przejrzystość, bezpieczeństwo i zgodność z resztą systemu. Można to wesprzeć za pomocą prostych narzędzi, które skanują kod w poszukiwaniu typowych problemów. Dzięki tym procedurom jakość kodu zewnętrznych programistów pozostaje na tym samym poziomie co reszta zespołu w spokojny i powtarzalny sposób. Ludzie uczą się od siebie nawzajem i budują wspólne poczucie tego, co jest „dobre”.

Można również śledzić niewielki zestaw wskaźników dotyczących zespołu programistów. Mogą one pokazać, ile czasu zajmuje ukończenie danego zadania, ile problemów dociera do użytkowników i jak często dostarczane są aktualizacje. Nie potrzebujesz dziesiątek liczb. Wystarczy kilka, które możesz łatwo odczytać i omówić. Gdy te wskaźniki pozostają stabilne lub poprawiają się podczas zarządzania zewnętrznymi programistami i rozbudowywania zespołu, wiesz, że Twoja konfiguracja wspiera jakość. Jeśli spadną, masz wczesny sygnał, aby przejrzeć zasady, zakres lub zestaw zadań.

Wzory komunikacji są równie ważne jak zasady i liczby. Wiele zespołów programistycznych o mieszanym składzie można również uznać za rozproszone zespoły agile, ponieważ ich członkowie pracują w różnych miejscach lub strefach czasowych. Potrzebują oni asynchronicznej komunikacji, aby postępy nie zależały od długich rozmów telefonicznych. Bardzo pomocne są krótkie pisemne aktualizacje, jasne notatki dotyczące zadań i proste tagi statusu. Dobre pisemne aktualizacje ułatwiają wszystkim inżynierom dołączenie do zespołu, śledzenie postępów i ulepszanie produktu w miarę upływu czasu. Rozmowy na żywo nadal mają znaczenie, ale nie są już jedynym miejscem, w którym podejmowane są decyzje.

Sposób, w jaki angażujesz osoby z zewnątrz, również ma wpływ na jakość. Jeśli traktujesz je jako oddzielny strumień o niejasnych celach, nie będą one czuły się w pełni odpowiedzialne za produkt. Jeśli dodasz je do istniejących zespołów zgodnie z jednym zestawem zasad, będą mogły działać jak każdy inny członek zespołu. Niektóre firmy stosują w tym celu model rozbudowy zespołu, w którym łączą osoby wewnętrzne i zewnętrzne pod jednym kierownictwem. Wspólne cele, wspólne narzędzia i wspólne recenzje mają większy wpływ na jakość kodu w tworzeniu oprogramowania niż jakikolwiek dokument dotyczący ścisłej kontroli. Z czasem można dostosować skład zespołu i zakres pracy, ale wspólna struktura pozostaje taka sama.