Zdrowy rozsądek przede wszystkim. Jednak kolejne lektury pozycji dotyczących świata IT, projektowania stron, zarządzania zespołami ludzi, pozwalają wysnuć dużo ważniejszą tezę, którą w niniejszym artykule pozwolę sobie obronić. Mianowicie, aby „zostać zwycięzcą” nie można pozwolić sobie na kompromisy w zakresie zespołu jak i warunków pracy.

Oczywiście przez ostatnie lata popularna zwinność często wykorzystywana jest jako argument to tego, by te kompromisy stosować. W mojej ocenie nie jest to złe, a świadczy o zdroworozsądkowym podejściu do biznesu. Jednak jeśli na każdym kroku staramy się wdrażać kompromisy, prowadzi to do, krótko mówiąc, problemów.

 

Odzwierciedlenie w doświadczeniu pracowników

Czuję się zobowiązany na samym początku sprostować pewne nieścisłości. Pewnie większość z Was zadaje sobie podświadomie pytanie: wszystko fajnie, ale gdzie w takim razie mają się podziać osoby zbierające dopiero doświadczenie? Każdy z nas kiedyś był juniorem (bądź jest, pozdrawiam tych czytelników) i na pewno docenia(ł) możliwość nauki u boku bardziej doświadczonych kolegów. Czy takie osoby wpisują się w grupę „Najlepszych pracowników”? Tak, ale pod pewnym warunkiem. Zespół projektowy musi być sensowny i mądrze zarządzany. Zauważcie, że w tezie pojawiają się „Najlepsi pracownicy” – to celowy zabieg, gdyż aby projekt zakończył się powodzeniem, każda jego faza rozwoju musi być nadzorowana przez kompetentnych ludzi.

Kluczową kwestią jest posiadanie kompetentnych ludzi do wszystkich zadań. Rzeczą niepojętą jest podejmowanie się projektu (tudzież dążenie do sukcesu), gdy:

  1. Nie ma się pracownika, który w swoim stosie technologicznym posiada technologie, które mają być wykorzystane w projekcie;
  2. Zakłada się zarządzanie projektem poprzez osoby niekompetentne;
  3. Projektowanie/prototypowanie systemu spoczywa na naszej firmie i mają za to odpowiadać stażyści;
  4. Graficy mają pracować nad widokami przed finalizacją fazy prototypowania;
  5. Frontend deweloperzy tworzą widoki na podstawie draftu projektu graficznego;
  6. Kontakt i przepływ informacji jest rozproszony w kilku systemach zarządzania projektami (JIRA, Redmine, Trello, Slack, Asana, Evernote, Google Documents).

Postaram się teraz rozwinąć każdy z punktów. Wyobrażacie sobie rozpoczynanie projektu od zera, którego efekt finalny jest gdzieś w głowie u klienta, ma on już jakiś rozmyty termin oddania, nie posiada żadnej dokumentacji, ale ma wytyczne co do niektórych technologii, których żaden z pracowników firmy nie ma w swoim stosie technologicznym? Nielogiczne, nieodpowiedzialne, zupełnie bezmyślne postępowanie. W tym przypadku pierwsze co należy uczynić to zatrudnić w trybie pilnym osobę, która:

  1. Weźmie na siebie ciężar rozwoju systemu;
  2. Szybko zasymiluje się z zespołem;
  3. Współpraca będzie przebiegać zgodnie z założeniami.

Wydaje się mało. Ale już na tym etapie mamy potencjalne ryzyko, które w dokumencie analizy ryzyka powinno się znaleźć, ale … no właśnie taki dokument nie istnieje, bo dokumentacja nie istnieje. Wydawać by się mogło, że jest to zbędna papierologia, ale celem tego artykułu jest też udowodnienie, że dokumenty projektowe powinny powstawać, bowiem są rzetelnym, wiarygodnym punktem odniesienia – a przede wszystkim na pewnym etapie są zatwierdzane (niektóre z nich) przez klienta. Wracając do tematu, mamy na samym początku ryzyko związane z zasobami ludzkimi. Ryzyko jest mocno skorelowane z rozmiarem systemu, który tworzymy. Nie można zakładać, że jeden senior w zespole to dobre rozwiązanie – mamy kolejne ryzyko – wypadki losowe, rezygnacja z pracy, przecenienie swoich możliwości.

Juniorzy, ambitni, chętni do pomocy, często podchodzą nieoptymalnie do rozwiązania poszczególnych problemów lub rozwoju produktu. To nie jest ich winą. Oni się uczą. Każdy z nas się uczy. Aby zostać biegłym w określonej technologii często trzeba przepracować kilka pełnych cyklów projektowych, przeczytać kilkaset artykułów i wypić kilka tysięcy kaw. Można poruszać się zwinnie w kilkunastu technologiach, ale zawsze jest się specjalistą tylko w kilku z nich. Ciężar odpowiedzialności przede wszystkim musi spoczywać na tych najbardziej doświadczonych. Jednak, że stosunek doświadczenia do młodości nie może być zbyt mały, bowiem cierpi na tym efektywność i jakość. To ma bezpośredni wpływ na kolejne opóźnienia. O ile panujemy nad sytuacją i czas nas nie goni (to jest jednak mało realne) to czas poświęcony na każdy przyrost należy pomnożyć przez współczynnik efektywności. Bardzo dużo tutaj zależy od PMów, którzy panując nad rozwojem produktu dają poczucie spokoju i bodziec do pracy bez presji czasowej (w miarę możliwości). Płynnie przeszliśmy do kwestii czasu i to jest temat, nad którym warto się pochylić.

Harmonogram powinien być ustalony z klientem i powinien brać pod uwagę każde ryzyko. Często zdarza się, że w luźnych rozmowach dochodzi do wstępnego porozumienia, gdzie rzucone zostaje nieśmiało „niech będą 4 miesiące” lub „pół roku to rozsądny termin”. Nieeeee. Wszystko musi mieć oparcie w dokumentacji. Czujecie, że takie deklaracje bez wyklarowanej listy funkcjonalności i przepływu akcji w systemie, sieją spustoszenie w pracy przy rozwoju produktu? To jest tak logiczne, że kierowanie się w ten zaułek musi skończyć się problemami. Harmonogram to też nie tylko czas rzeczywistego wytwarzania oprogramowania. Jeśli software house bierze na swoje barki wszystkie fazy tworzenia oprogramowania:

  1. Specyfikacja
  2. Projektowanie
  3. Implementacja
  4. Integracja
  5. Ewolucja

… to taki harmonogram koniecznie musi zawierać je wszystkie i może się zdarzyć, że będzie to wielokrotność czasu (szacunku) przewidzianego na implementację. Metodyk wytwarzania oprogramowania jest mnóstwo, ale popularne Agile nie może wpływać na zaniechanie rzetelnego szacowania.

Wszelkie problemy wpisane w ryzyko propagują problemy na kolejne fazy wytwarzania produktu. Myślę, że nie trzeba się nad tym zbyt długo rozwodzić. Zaniechania w fazie specyfikacji, w skrajnych przypadku brak dokumentacji ma katastrofalny wpływ na dalsze fazy. Podczepianie modnej zwinności do tej fazy jest tylko pudrowaniem rzeczywistości. Żaden rozsądny człowiek nie dopuści do projektowania przed zatwierdzeniem specyfikacji. Mimo wszystko firmy podejmują takie ryzyko z gromkim „eee jakoś to będzie”, „kto jak nie my”, „przecież trzeba się rozwijać”.

W takim przypadku narzekania obejmują dział projektowy – UX, grafików. Niemiła atmosfera tylko narasta i każdy robi to co musi z przesłaniem „byle tylko to skończyć”. Ale to nie koniec. Faza projektowania poprzez zaniechania w poprzedniej ma nie lada orzech do zgryzienia. Nie ma dokumentacji = nie ma punktu odniesienia = niekończące się iteracje uwag od klienta. Dramat – na razie w dwóch aktach. Od początku cierpi na tym jakość składowych produktu, a w konsekwencji jakość całego produktu. Na pierwszy rzut oka może być nieskazitelny, ale to tylko złudzenie. Wszystkie uchybienia muszą mieć jakiś koszt. Ten koszt to:

  1. Kiepska atmosfera pracy (po stronie wykonawcy)
  2. Kiepska jakość produktu (przedmiot realizacji)
  3. Niezadowolenie, frustracja klienta (zleceniodawca)

Fazy trzecia, czwarta i piąta – tutaj mamy UI, deweloperów, wdrożeniowcow i testerów. To oni obrywają najbardziej, bowiem w nawet bardzo źle prowadzonym projekcie faza projektowania zawsze mieści się w czasie oddania gotowego produktu. Presja osiąga apogeum u koderów. Nagle okazuje się, że w tydzień muszą zrobić coś na co powinny zostać przewidziane 2-3 miesiące. Ba, okazuje się, że na fazę testów nie ma w ogóle czasu – i mamy dramat w trzech aktach.

Często spotykanym zjawiskiem jest pudrowanie rzeczywistości poprzez zwiększanie zasobów ludzkich w projekcie. Dlaczego to dolewanie benzyny do ognia? Większość z Was powinna znać prawo Brooksa:

Dodanie siły roboczej na późnym etapie projektu informatycznego prowadzi tylko do jego opóźnienia.

Frederick Brooks, The Mythical Man-Month: Essays on Software Engineering, Addisson-Wesley, Reading, MA, 1975.

Prywatnie w tym prawie uwzględniłbym również zmiany kadrowe w zespołach projektowych, jeśli dotyczą ważnych ich członków.

 

Zawsze osobiście bardzo ceniłem dobrych Project Managerów. Tak to dzięki nim pracuje się lepiej. To w nich mają oparcie wszyscy z zespołu: UX, UI, graficy, testerzy, programiści. Dobrze zorganizowany PM to bezcenny członek zespołu. Cenny jest bezpośredni kontakt każdego członka zespołu z klientem, ale wszystkie kwestie powinny przechodzić przez PMa. 

Kierownik projektu zajmuje się m.in. integracją, podejmowaniem decyzji oraz motywowaniem zespołu, odpowiada za komunikację w projekcie. Jest łącznikiem między zewnętrznymi i wewnętrznymi interesariuszami projektu. Kierownik projektu jest odpowiedzialny za poinformowanie wszystkich członków zespołu projektowego o zadaniach, które mają wykonać, o harmonogramie, budżecie projektu i jego celach. Trafiają do niego wszystkie raporty, notatki służbowe, wnioski, uwagi sponsora, a także skargi. Prowadzi negocjacje we wszystkich sprawach mających wpływ na wynik projektu.

Kierownik projektu jest osobą odpowiedzialną za zachęcania całego zespołu do pracy i wyznaczanie kierunków działania. Powinien on inspirować pozostałych członków zespołu, umacniać przekonanie o wartości projektu. Kierownik projektu odpowiada za zdobycie budżetu i zasobów dla projektu. Kontroluje posiadane zasoby finansowe. Ponadto musi być otwarty na zmiany, przygotowywanie nowych rozwiązań. Musi szybko reagować na problemy i odpowiednio obsługiwać zmiany, które mogą negatywnie wpłynąć na ostateczny wynik projektu.

Wikipedia, Kierownik projektu [1]

 

Project Manager to nie jest zawód, na który łatwo się „przebranżowić”. Sporo osób boleśnie się o tym przekonuje. Praca przebiega na trzech płaszczyznach, które zostały już wcześniej wymienione w opisie ponoszonych kosztów – praca ze swoim zespołem, kontakt z interesariuszami (klienci) oraz zarządzanie projektami. Mnóstwo pracy, której celem jest sukces.

Obowiązki na rzecz zespołu [2]:

  • buduje zespół
  • przypisuje zadania, deleguje odpowiedzialność
  • ustala priorytety zadań
  • wspiera zespół i wyznacza kierunek działania
  • identyfikuje i rozwiązuje konflikty
  • ocenia wydajność zespołu

Obowiązki na rzecz projektu [2]:

  • uruchamia i zamyka projekt
  • zarządza procesem dostarczenia projektu i całym cyklem jego życia
  • wyjaśnia zakres i priorytety projektu, jak również cele biznesowe
  • ułatwia rozumienie zakresu projektu, celów i kluczowych rezultatów
  • definiuje zadania do wykonania w ramach projektu
  • mierzy postęp projektu
  • monitoruje kluczowe parametry projektu
  • zapewnia jakość
  • identyfikuje, ocenia i zarządza ryzykiem projektu
  • zarządza zmianami, analizuje ich wpływ na projekt

Obowiązki względem klientów [2]:

  • utrzymuje relacje z interesariuszami
  • komunikuje się z interesariuszami oraz sponsorem projektu
  • raportuje i prezentuje postęp projektu, przygotowuje i dostarcza sprawozdania
  • eskaluje problemy oraz proponuje rozwiązania
  • tworzy rekomendacje
  • angażuje interesariuszy, wpływa na ich decyzje
  • buduje świadomość oraz wsparcie organizacji we wprowadzaniu zmian

Pozostałe obowiązki [2]:

  • tworzy plan projektu oraz harmonogram
  • planuje zasoby potrzebne do realizacji
  • wdraża narzędzia, standardy, strategię oraz plan komunikacji
  • utrzymuje i aktualizuje dokumentację projektu
  • monitoruje budżet i wydatki
  • projektuje i usprawnia procesy

Jest tego trochę. Pozwoliłem sobie zacytować poszczególne punkty. Od siebie dodam, że niezbędne w pracy PMa, by usprawnić i zorganizować dobrze pracę są systemy do zarządzania projektem. Osobiście cenię sobie bardzo system JIRA oraz Redmine. Pozwalają wszystkie informacje dotyczące projektu przechowywać w jednym miejscu i to powoduje łatwe i szybkie uzyskanie odpowiedzi na nurtujące pytania. Generowanie raportów, analizy czasochłonności zadań, przepracowany czas, postęp w projekcie i wiele innych staje się z takim systemem intuicyjne i co najważniejsze pozwala zaoszczędzić sporo czasu. Notatki ze spotkań projektowych, wynik negocjacji, odpowiedzi klienta oraz wszystkie kwestie mające bezpośredni wpływ na przebieg projektu muszą zostać umieszczone w miejscu, do którego każdy członek zespołu ma dostęp. Organizacja pracy całego zespołu leży w gestii PMa, ale nie zapominajmy, że każdy wnosi do tego cegiełkę. Tutaj idealnie pasuje motto, którego staram się trzymać:

Organizuj swoją pracę tak, aby maksymalnie pomóc innym. Dopiero wówczas oczekuj tego od innych.

 

Pomyślicie, że trochę chaotycznie przechodzimy po fazach projektu, ale jest w tym trochę sensu. Project manager jest osobą, która w każdej fazie pełni kluczową rolę. Jego profesjonalizm i kompetencje stanowią o sile i powodzeniu przedsięwzięcia.

 

Bardzo dobre założenia na początku swojej książki stawia Michał Bartyzel [3]:

  • klient zawsze wie czego chce – wie, że chce rozwiązać jakiś problem, osiągnąć jakiś cel, coś usprawnić;
  • klient nie zawsze wie, czego potrzebuje – ponieważ jest skupiony przede wszystkim na swoich procesach biznesowych;
  • klient często nie zdaje sobie sprawy z konsekwencji swoich oczekiwań – gdyż jest ekspertem w obrębie swojej działalności biznesowej, a nie w obszarze technologii informatycznych.

 

Podpisuję się pod tym obiema rękami. Zrozumienie tego ułatwi kontakt z klientem, a przede wszystkim pozwoli spokojniej interpretować oczekiwania klienta wobec produktu. Dlatego specyfikacja projektu jest ważna. Na samym początku należy wyjaśnić z klientem wszystkie kwestie, wobec których mamy wątpliwości. Nie można się bać (oczywiście w odpowiednim tonie) próbować przekonać klienta do błądzenia, jeśli ma to miejsce. Często klient/sponsor ustalając harmonogram, tudzież termin oddania projektu, zakłada, że to i tak zbyt późno. W głowie mu zapewne pojawia się myśl – „po co im tyle czasu”. W tym momencie merytorycznie należy wytłumaczyć ile czasu potrzebnych jest na każdą fazę projektu. Zawsze zakładajmy zapas czasowy. Czas jest nierozciągliwy (niestety), a wobec określonego terminu klient może poczynić jakieś zobowiązania u strony trzeciej (reklama, współpraca z innymi podmiotami). Grunt to transparentność. Ona pozwala zachować dobre relacje stron podczas całego czasu tworzenia produktu.

Kilka sugestii w związku efektywnym prowadzeniu projektów informatycznych przedstawia Magdalena Płaza z HighSolutions w artykule na łamach Nowego Marketingu.

Nie można pozwolić sobie na nadmiarowe naginanie terminów pierwszych faz projektu, bowiem to ma swoje konsekwencje później. Owszem jest to mniej obciążające aniżeli brak specyfikacji lub kiepska organizacja całego projektu, ale niesie za sobą piętno.

Mając specyfikację, druga faza to powinna być tylko formalność. Makiety, prototypy wychodzące spod ręki UXa to chleb powszedni. Właściwy człowiek we właściwym miejscu przebrnie to bez problemu. Gdy nie ma dokumentacji sam UX błądzi, ale co gorsza każdy będzie błądził, kto przejmie wynik jego pracy w dalszym etapie – grafik, a w konsekwencji deweloper i tester. Projekt graficzny – tutaj klient zazwyczaj trochę marudzi, wiadomo o gustach się nie rozmawia – powinien powstawać w ciągłej konsultacji z klientem, aby jego finalna wersja została zaakceptowana. Jeśli klient bierze czynny udział w powstawaniu warstwy wizualnej swojego przyszłego produktu na pewno na tym etapie poczuje się „dopieszczony”, a sam efekt jest „namacalny”. Sensowne na tym etapie są też konsultacje w działem UIbackend developerami, aby jak najbardziej usprawnić pracę w kolejnych etapach. Bywa, że grafik-czarodziej tworząc kolejne widoki nieumyślnie dokłada pracy programistom, którzy aby sprostać wymaganiom zobligowani są poczynić dodatkowe kroki, aby efekt finalny był zgodny z oczekiwanym.

Czas – tak, to on jest najbardziej deficytowym zasobem. Dlatego opóźnienia na etapie pierwszym i drugim nie mogą nieść za sobą konsekwencji na dalszych etapach. Należy negocjować z klientem – w końcu i jemu i nam zależy na jakości produktu. Jeśli ta będzie niska i on i my będziemy mieli problemy. Wykonawcy na pewno większe. Jakiekolwiek opóźnienia powodują, że przedostatnia i ostatnia faza (integracja i ewolucja) są traktowane po macoszemu. Testy są przecież niezwykle ważne i dają poczucie spokoju.

Sporo treści za nami. Cieszę się, że dobrnęliśmy do tego momentu – właśnie kończymy zarys „Kroku drugiego” z naszej tytułowej grafiki, mającej obrazować tezę „Dlaczego zwycięzca bierze wszystko?” … mianowicie „Najlepszy pracownik”.

 

Warunki pracy

Joel Spolsky w swojej książce [4] w przepiękny sposób rozwodzi się na temat wszechobecnych otwartych przestrzeni biur w stosunku do wydzielonych gabinetów. Cały wywód opiera się na książce-biblii „Czynnik ludzki” [5] i dotyczy udostępnienia programistom (sam odniósłbym to do wszystkich pracowników) mnóstwa wolnej przestrzeni, nawet w formie osobistych gabinetów. Oczywiście sam autor owej biblii zna rzeczywistość – popularność open-space jest tak duża, że w chwili obecnej każdy pracownik uznaje to za normalność. Rzekomo wynika to z tego, że programiści są zbyt towarzyscy … to jednak przekłada się na niższą produktywność, która w istocie jest tolerowana przez prezesów. W ogólnym rozrachunku to im się dobrze kalkuluje, ale to może być tylko złudzenie. W moim przekonaniu w grę wchodzą niemałe pieniądze. Zapewnienie pewnej prywatnej przestrzeni (nie mylić z boksem w open-space!) to spory koszt. Ale podobno dowiedziono, że osobne gabinety podnoszą produktywność twórców oprogramowania. Joel odsyła do kilku pozycji potwierdzających kwestie sporne:

  • wzrost produktywności programistów w wydzielonych gabinetach [6], [7], [8]
  • praca z założonymi słuchawkami i słuchanie muzyki zagłuszającej dźwięki otoczenia utrudnia dochodzenie do wartościowych wniosków [9]
  • wydzielenie gabinetów dla programistów w praktyce nie zwiększa łącznych kosztów firmy [10]

Wnioski można przedstawić w dwóch punktach:

  • osobiste gabinety sugerują wyższy status pracownika
  • boksy i inne przestrzenie otwarte są niefortunne w kontekście relacji towarzyskich

Z dowodami się nie wygra, ale moim prywatnym zdaniem warto znaleźć złoty środek. Open-space jest zły – bez dwóch zdań – zawsze zdarzy się osoba, która prowadzi dyskusje projektowy (lub nie tylko projektowe) w sposób rozpraszający współpracowników. Wydaje mi się, że idealnym rozwiązaniem jest stworzenie gabinetów dla kilku osób (maksimum 4). Wówczas proces rozpraszania nie dotyczy całego zespołu, a jedynie jego części – przy odrobinie chęci głośne rozmowy można przenieść do sali konferencyjnej. Jednak nie zawsze natężenie dźwięku ma znaczenie. Przecież łatwo o rozproszenie wykorzystując bodźce wzrokowe – przemieszczający się przez pokój kurierzy, dostawcy, petenci. Takie drzwi w gabinecie mają swoją zaletę. Proszę tylko nie piszcie, że „open-space = otwarta firma”. Obecnie, gdy tempo życia jest niesamowicie szybkie, panuje przekonanie, że nie ma czasu chorować. W myśl niego większość osób pomimo swojej choroby stawia się w pracy i … zaraża współpracowników. To nie jest „wyssane z palca”. To jest smutna rzeczywistość. Niestety powodem tego jest niewkalkulowanie w harmonogram zwolnień chorobowych niektórych członków zespołu. Późniejsze nadganianie straconego czasu nie byłoby przyjemnością dla uszczuplonego zespołu, ale też i dla osoby na zwolnieniu, która zapewne odczułaby to na swoich barkach po powrocie. Efekt domina – przykra prawda, z którą niewiele się robi w wielu firmach.

Idąc od ogółu do szczegółu czas na sprawy dotyczące komfortu pracy przy biurku. Mamy pewien standard – krzesło ergonomiczne, biurko duże schludne, monitory (w zależności od zapotrzebowania). Bardzo dobrą praktyką jest zwrot kosztów za książki branżowe, które pozwalają się rozwijać pracownikowi.

Czy generalnie branża IT zasługuje na miano roszczeniowej? W mojej ocenie rynek weryfikuje i doświadczenie i zaangażowanie. Zapotrzebowanie wpływa na wysokość płac. Zarobki w branży są godziwe i przez to wynagrodzenie nie stanowi najwyższego priorytetu przy wyborze pracodawcy. Cenne to spostrzeżenie – zadowolony pracownik to efektywny pracownik. Natomiast dobrze zarządzana firma z branży IT na pewno nie upadnie. Taka firma też będzie mieć wielu zadowolonych pracowników, a w konsekwencji klientów.

 

Podsumowanie

Powstał mały felieton na temat prowadzenia zyskownego biznesu. Zostały przedstawione etapy wytwarzania oprogramowania, koncentrując się przede wszystkim za zarządzaniu projektem przez osobę Project Managera. Wniosek jest jedyny możliwy – zespół musi być w zdecydowanej większości kompetentny. Pokazane punkty zapalne, które mają wpływ na opóźnienia, problemy i ostatecznie kłopoty „z dowiezieniem” projektu do końca w terminie, pokazują jasno, że element zaskoczenia nie może wystąpić. Dokumentacja to podstawa. W dobrze zaplanowanym projekcie jest owszem miejsce dla juniorów/stażystów, ale wszystko musi być przemyślane. Nadzór takich osób musi być wliczony w koszty czasowe i finansowe. Struktura firmy również powinna być przemyślana. Skrajne przypadki – jak jeden senior deweloper lub jeden PM na kilkadziesiąt osób i kilka równolegle prowadzonych projektów – to zdecydowana przesada i powinien to być wstyd dla prezesa takiej firmy. Każdy może popełnić błąd. Należy się jednak na tych błędach uczyć i pozwolić by określony pojawił się ponownie. Szkolenia, kursy, czerpanie z doświadczeń innych powinny dotyczyć zarówno deweloperów, testerów, PMów, UXów, grafików, jak i szefów, bo sukcesywne zarządzanie firmą jest kwestią nadrzędną.

 

Na deser bardzo sensowna puenta Joela Spolsky’ego:

Programiści nie myślą tylko o pieniądzach, chyba że kompletnie zaniedbamy pozostałe aspekty. Jeśli więc od jakiegoś czasu słyszymy skargi (które nie pojawiały się wcześniej) na zbyt niskie wynagrodzenia, możemy uznać to za sygnał sugerujący, że nasi programiści nie kochają swojej pracy. Jeśli potencjalni kandydaci na programistów nie są skłonni do najmniejszych ustępstw podczas negocjowania wynagrodzenia, najprawdopodobniej mamy do czynienia z następującą postawą: „Cóż, jeśli już muszę kompromitować się pracą w tej firmie, powinni mi przynajmniej odpowiednio zapłacić”.

To oczywiście nie oznacza, że możemy sobie pozwolić na zbyt niskie wynagrodzenie pracowników, ponieważ programiści są wrażliwi na niesprawiedliwość. Jeśli odkryją, że pracownicy innych firm otrzymują nieporównanie wyższe wynagrodzenie za tę samą pracę lub że pensje w naszej firmie są na przykład o 20% niższe niż w firmie za rogiem, kwestia pieniędzy z dnia na dzień urośnie do miana poważnego problemu.

 

Bibliografia:

[1] https://pl.wikipedia.org/wiki/Kierownik_projektu

[2] http://kjarocka.pl/zarzadzanie-projektami/project-manager-opis-stanowiska-i-zakres-obowiazkow/

[3] Michał Bartyzel, „Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce”

[4] Joel Spolsky, „Programista poszukiwany. Znajdź i zatrudnij najlepszego”

[5] Tom DeMarco, Timothy Lister, „Czynnik ludzki – skuteczne przedsięwzięcia i wydajne zespoły”

[6] Tom DeMarco, Timothy Lister, „Programmer performance and the effects of the workspace”

[7] Capers Jones, „How office space affects programming productivity”

[8] Gerald M. McCue, „IBM’s Santa Teresa Laboratory – Architectural design for program development”

[9] Tom DeMarco, Timothy Lister, „Peopleware. Second Edition” (str. 78)

[10] Joel Spolsky, „Bionic Office” – artykuł z 23.09.2003 z www.joelonsoftware.com