Tworzenie oprogramowania: jakie są kluczowe role w zespole?

Wiele osób uważa, że ​​do stworzenia aplikacji wystarczy zatrudnić jednego programistę. Jednak wraz ze wzrostem złożoności i wydłużaniem się czasu rozwoju staje się jasne, że ktoś musi pełnić inne role, nawet jeśli nie są one jasno określone.

Rozwój oprogramowania odbywa się w ramach projektów. Ramy czasowe, pożądany rezultat i budżet są jasno określone. Każdy projekt obejmuje również zasoby ludzkie, a odpowiedni dobór uczestników jest kluczowy, ponieważ wpływa to na wymagany budżet. Spróbujmy więc dowiedzieć się, kto jest zaangażowany w rozwój projektu i jakie ma obowiązki.

10 kluczowych ról w zespole programistów

„Analizując role projektowe, należy zrozumieć, że typowy pracownik firmy może pełnić jednocześnie kilka ról, a także uczestniczyć w różnych projektach w różnych rolach”. – o czym wspomina w jednym ze swoich ostatnich artykułów Sebastian Streiffert, dyrektor ds. marketingu firmy Beetroot.

Porozmawiamy później o połączeniu ról. Zwróćmy teraz uwagę na główne role i stanowiska w zespole projektowym wytwarzania oprogramowania:

Polecane dla Ciebie: Jak firmy zajmujące się oprogramowaniem i IT radzą sobie z pandemią COVID-19?

1. Kierownik projektu

Osoba ta ustala plan projektu i bierze odpowiedzialność za jego realizację. On lub ona otrzymuje fragmenty planu od personelu, łączy je i weryfikuje ich spójność. PM jest odpowiedzialny za tworzenie raportów dla członków zespołu i dostarczanie wyników na czas iw ramach określonego budżetu. Poza tym wykonują następujące zadania:

• Przeprowadzaj regularne (cotygodniowe) przeglądy planu z klientem i zespołem projektowym;
• Dostosuj plan zgodnie z wymaganiami klienta;
• Pisz cotygodniowe raporty z projektów;
• Poinformuj klienta i personel o problemach i spróbuj je rozwiązać w ramach budżetu itp.

Zasadniczo PM jest odpowiedzialny za KPI projektu. Według statystyk tylko nieliczne projekty rozwojowe są realizowane terminowo z założonymi KPI iw ramach początkowego budżetu. Niezależnie od tego, czy coś pójdzie nie tak, PM ostatecznie bierze odpowiedzialność za opóźnienie wydania produktu, błędy w aktualizacjach itp.

2. Analityk

Analityk jest odpowiedzialny za pisanie i aktualizowanie wymagań. W szczególności jest głównym negocjatorem z klientem w sprawie wymagań projektowych. Ta osoba pisze rekomendacje dla projektu, przegląda je z interesariuszami, architektami i czołowymi programistami. Ponadto analityk przegląda plany testów, wyjaśnia trudności testerom, a także może brać udział w testowaniu kodu. Osoba ta może również uczestniczyć w przeglądzie rozwoju na najwyższym poziomie.

Złożone projekty mogą wymagać zespołu analityków i lidera, odpowiedzialnego za zespół.

3. Architekt

Ta osoba opracowuje architekturę projektu. W przypadku dużych projektów architekt powinien być pracownikiem pełnoetatowym. Ten członek zespołu jest odpowiedzialny za dokumenty wysokiego poziomu (HLD), dostosowanie architektury do wymagań technicznych klienta. Uporządkowuje projekt, rozdziela zadania między programistów i pomaga im w trudnych kwestiach.

4. Wiodący programista (kierownik zespołu)

W małych projektach bez dedykowanych architektów wiodący programiści są odpowiedzialni za wszystkie zadania programistyczne. Wyznaczają deweloperów, przeglądają plan i ustalają dla nich terminy. Poza tym wykonują następujące zadania:

• Przyjmuj pracę od programistów i przeprowadzaj przegląd kodu;
• Scal gałęzie w repozytorium i upewnij się, że do głównej gałęzi trafia tylko przetestowany i odpowiedni kod;
• Pisz dokumenty projektowe;
• Szkolić pracowników i pomagać im w trudnych sprawach;
• Napisz kod.

5. Deweloper

Ta osoba pisze kod dla projektu. Czyta wymagania, analizuje złożone obszary z analitykiem, przyjmuje zadania rozwojowe od lidera zespołu lub architekta iw razie potrzeby udziela informacji zwrotnej. Do ich bezpośrednich obowiązków należy:

• Tworzenie komponentów kodu i testów jednostkowych;
• Testy uruchomieniowe;
• Sprawdzenie, czy zaimplementowana funkcjonalność spełnia wymagania;
• Przyjmowanie zgłoszeń od testerów i korygowanie błędów;
• Udział w testach w trudnych przypadkach.

Bez napisanego i skompilowanego kodu nie będzie aplikacji. Dlatego nie można wykluczyć programistów, nawet jeśli niektóre aplikacje są tworzone w prostym konstruktorze wizualnym, który też jest swego rodzaju programowaniem.

Może ci się spodobać: Przyszłość inżynierii oprogramowania | Trendy, prognozy na rok 2021 i kolejne lata.

6. Specjalista ds. kontroli jakości/Tester

Są to osoby, które sprawdzają, czy aplikacja działa poprawnie. Co więcej, poprawnie nie zawsze oznacza przyjazność dla użytkownika. Tester może napisać notę ​​użyteczności, ale jego głównym celem jest upewnienie się, że aplikacja działa zgodnie z wymaganiami i specyfikacjami. Mogą testować aplikacje zarówno ręcznie, jak i za pomocą autotestów.

Jeśli chodzi o analityków, testerów można przypisać według podsystemu projektu lub metod testowania. Jeśli jest więcej niż jeden tester, jeden z nich powinien zostać wyznaczony na lidera zespołu. Jeśli w zespole projektowym nie ma dedykowanych testerów, ich funkcje są zazwyczaj delegowane do programistów. Jednocześnie uważa się, że programiści nie mogą poprawnie testować własnych kodów, dlatego lepszym rozwiązaniem jest testowanie krzyżowe.

7. Projektant

To osoba, która decyduje o tym, jak aplikacja będzie wyglądać i działać. Projektant musi przemyśleć rozmieszczenie elementów, schematy ruchu, animacje itp. Złożone aplikacje mogą wymagać kilku projektantów. Na przykład jeden projektant może narysować interfejs, podczas gdy drugi może przemyśleć całą koncepcję interakcji użytkownika. Niektóre firmy tworzące oprogramowanie nie mają projektantów, więc programiści mogą przyjąć tę rolę w przypadku prostych projektów. Do głównych zadań projektanta należy:

• Rozwój ScreenFlow;
• Prototypowanie ekranu;
• Optymalizacja interakcji użytkownika (przekazywanie rekomendacji);
• Konsultacje z zespołem deweloperskim.

Czasami projektant razem z programistami odpowiada za jakieś błędy w aplikacji. Na przykład wdrożenie pomysłów projektowych klienta może być dość trudne, więc prawdopodobieństwo popełnienia błędów wzrasta. W konsekwencji wszystkie awarie związane są z pracą projektanta.

8. Administrator systemu/oficer DevOps

Ten członek zespołu jest odpowiedzialny za przepływ pracy ciągłej dostawy i ciągłej integracji, organizację interakcji między systemami, wdrażanie, identyfikowanie problemów podczas testowania. Biorą udział w planowaniu i pracach nad migracją i synchronizacją danych. Poza tym wykonują następujące zadania:

• Napisz przewodnik po wdrażaniu i administrowaniu systemem;
• Interakcja z klientami;
• Skomponuj i ustrukturyzuj sprzęt systemowy;
• Zainstaluj VPN i radź sobie z zaporami ogniowymi;
• Wdróż system bez programistów.

9. Kierownik Działu Rozwoju

Osoba ta bierze udział w tworzeniu zespołów projektowych. Odpowiadają za kwalifikacje pracowników, więc ich zadaniem jest organizowanie szkoleń, monitorowanie rozwoju kariery pracowników. Poza tym odpowiadają również za komfort w miejscu pracy.

10. Klient/właściciel produktu

To główny członek zespołu, który decyduje o całym przebiegu tworzenia produktu. Osoba ta decyduje, co należy zrobić i ocenia, czy wdrożenie jest zgodne z koncepcją produktu, czy też nie. W szczególności odpowiedzialny właściciel produktu wykonuje następujące zadania:

• Definiuje koncepcję produktu;
• Tworzy strategię marketingową;
• Dokonuje analizy konkurencji;
• Przeprowadza kontrolę stanu rozwoju;
• Wybór strategii produktowej i metod monetyzacji;
• Generuje pomysły na poprawę wyników biznesowych;
• Ocenia jakość produktów.

Tak więc głównym celem tej osoby jest upewnienie się, że produkt odpowiada celom biznesowym.

Typowe połączenie ról

Czasami podczas omawiania wyników klienci mówią, że programiści zrobili coś złego. Taka sytuacja może wystąpić, jeśli niektórzy członkowie personelu projektu muszą pełnić kilka ról jednocześnie. Problem ten pojawia się zazwyczaj w przypadku braku środków finansowych na zatrudnienie grupy programistów. Czasami połączenie ról może przynieść pozytywne rezultaty. Na przykład możliwe są następujące opcje:

• Analityk + tester – brzmi nieźle, ale taka osoba będzie Cię kosztować fortunę;
• Kierownik projektu + analityk – taka opcja jest dopuszczalna w małym projekcie;
• Architekt + wiodący deweloper – to jest ok w małych projektach;
• Kierownik projektu + wiodący programista – w przypadku mniejszych projektów z doświadczonym zespołem programistów i testerów również możesz wypróbować tę opcję;
• Deweloper + projektant – możliwe w przypadku zręcznego zespołu programistów.

Tymczasem istnieją również role zespołowe, których w miarę możliwości nie należy łączyć w projekcie tworzenia oprogramowania:

• Deweloper + tester – niedozwolone.
• Architekt + Analityk – na pierwszy rzut oka brzmi to akceptowalnie, ale ogólnie nie wchodzi w grę. Te dwie role są nieco antagonistyczne.

Jak widać, podczas gdy niektóre pozycje można połączyć, inne stworzą wybuchową mieszankę, która zaszkodzi ostatecznemu wynikowi. Staraj się unikać łączenia ról lub inwestuj wystarczająco dużo czasu w rozwój projektu.

Może Cię również zainteresować: Wskazówki dotyczące samorozwoju jako zdalny programista w COVID-19.

Podsumowując

Teraz już wiesz, kto jest kim w zespole opracowującym projekt. Jeśli zastanawiasz się nad stworzeniem aplikacji na Androida lub iOS, będziesz wiedział, jakich ludzi musisz znaleźć. Tymczasem kluczowe role mogą się znacznie różnić w zależności od rodzaju projektu. Jeśli chcesz stworzyć oprogramowanie od podstaw, potrzebujesz innego zespołu niż wdrażający system ERP czy instalujący aplikację BI dla najwyższego kierownictwa klienta.

Jeśli zatrudniasz własny zespół, musisz utrzymywać pełną kadrę pracowników, nawet jeśli nie są oni zaangażowani lub nie w pełni zaangażowani w Twoje bieżące projekty. W rzeczywistości większość projektów nie wymaga pełnoetatowego projektanta, administratora systemu ani testera. Dlatego zatrudnienie dedykowanego zespołu programistów lub powierzenie tej pracy outsourcingowi może być dobrym pomysłem.

Jakie role w programowaniu były przydatne dla Twojego projektu i dla Twojego zespołu? Podziel się z nami swoimi doświadczeniami w komentarzach.