t Zapewnia, że priorytety zespołu odpowiadają potrzebom klienta...

Pokaż mi serce nie opętane zwodniczymi marzeniami, a pokażę ci człowieka szczęśliwego.

t Odpowiednio przedstawia wykonywane w zespole zadania kierownictwu firmy.
t Izoluje programistów od menedżerów wyższego szczebla, którzy nie mają przygotowania technicznego.
t Tłumaczy techniczne kwestie udziałowcom bez odpowiedniego przygotowania.
t Przekazuje pozatechniczne problemy programistom.
Jaś pyta...
Kim jest udziałowiec?
Udziałowiec jest to osoba, która ma związek z Twoim produktem.
Pracując nad projektem, powinieneś wiedzieć, kim będą jego odbiorcy. Twoimi udziałowcami mogą być klienci, ale jeśli ich jeszcze nie poznałeś, może ich zastąpić dział sprzedaży lub marketingu.
W małych firmach udziałowcami mogą być inwestorzy. W więk-szych firmach udziałowcami są czasem inne działy, które rozwijają swoje produkty, opierając się na Twoich. Jest bardzo istotne, aby rozpoznać te osoby tak, aby stworzyć produkt, którego potrzebują.
96
Sprzedaj swój program
Jakie więc czynności musi wykonać kierownik techniczny, aby zrealizować te zadania?
Zakres odpowiedzialności kierownika technicznego
Kierownik techniczny ma kilka ważnych obszarów odpowiedzialności, które różnić się będą w zależności od rodzaju firmy i składu zespołu. Oto mini-malna lista kompetencji kierownika technicznego:
t ustalanie wytycznych dla programistów,
t zarządzanie listą funkcji projektu,
t ustalanie priorytetów,
t izolowanie członków zespołów od czynników zewnętrznych3.
Przyjrzyjmy się bliżej każdej z tych dziedzin.
Ustalanie wytycznych dla programistów
Kierownik techniczny jest reżyserem zespołu, ustala kierunki i priorytety.
Współpracuje z każdym programistą przy tworzeniu i modyfikowaniu osobistej wersji listy zadań (patrz: podrozdział 10. na stronie 78). Kierownicy techniczni korzystają ze swojej znajomości postępów, problemów oraz pro-gnozowanych terminów realizacji związanych z ich zespołem, tak aby wytwo-rzyć ogólny obraz stanu projektu oraz śledzić jego postępy. Jako pojedynczy punkt kontaktowy dają oni możliwość szybkiego powiadamiania o statusie projektu dla wszystkich zainteresowanych.
Zarządzanie listą funkcji projektu
Kierownik techniczny jest głównym nadzorcą listy funkcji związanych z projektem. Zapotrzebowanie na nowe funkcje nie jest przekazywane bezpośrednio programistom, tylko wszystkie są najpierw zgłaszane do kierownika technicznego. Zarządza on wszystkimi zmianami na liście funkcjonalności.
3 Istnieje ryzyko przesadnej izolacji, która może pozbawić wartościowych sprzężeń zwrotnych.
Rozdział 3. • Pragmatyczne techniki projektowe 97
Kierownik techniczny jest jedyną osobą, która rozumie nie tylko powiązania techniczne każdej funkcji, ale zna również życzenia udziałowców projektu. Kierownik techniczny dodaje i usuwa funkcje oraz ukierunkowuje wysiłki poszczególnych programistów.
Kierownik techniczny oraz udziałowcy najpierw ustalają zakres pracy poprzez stworzenie listy funkcji (najlepiej za pomocą listy zadań!). Następnie kierownik spotyka się z całym zespołem, aby oszacować czas potrzebny na realizację każdej funkcji. Czasem oznacza to podział rozbudowanej funkcji na kilka pozycji listy zadań. Następnie przypisuje on poszczególne zadania programistom i ustala wstępny harmonogram projektu (wstępne oszacowania podlegają zmianom w miarę postępów projektu, ale więcej na ten temat później).
Zarządzanie listą funkcji przez kierownika technicznego bardzo pomaga w sytuacji, gdy ciągle pojawiają się osoby próbujące dodać do projektu nowe funkcje. Kierownik techniczny pełni rolę bufora filtrującego zapotrzebowa-nia i ustalającego dla nich rozsądne priorytety.
Kierownik techniczny może być bardzo przydatny jako pośrednik w kontak-tach z zespołem programistów. Na przykład w wielu firmach spotyka się kilku nadmiernie „kreatywnych” pracowników. Mają oni zawsze wspaniałe pomysły, ale rozpraszają tym innych pracowników. Ten typ pracowników ma zwyczaj zjawiać się, kiedy inni są najbardziej zajęci.
Jeden szczególnie kreatywny pracownik (Ernest), którego znaliśmy, był gor-szy niż inni. Aby zniwelować jego wpływ, kazaliśmy mu przynosić pomysły do nas (a nie do programistów). Następnie dodawaliśmy jego pomysł