Oryginalny post: No Matter What They Tell You, It's a People Problem
Autor: Jeff Atwood
Bruce Eckel zręcznie identyfikuje źródło wszystkich problemów związanych z tworzeniem oprogramowania:
Pracujemy w młodej branży. W zasadzie to prymitywnej -- nie wiemy za bardzo co działa i wydaje nam się, że znaleźliśmy prosty sposób, który rozwiązuje wszystkie problemy. W rezultacie przechodzimy przez wieloletnie okresy wzlotów i upadków, w miarę jak nowe pomysły się pojawiają, startujemy, wyczerpujemy możliwości, a następnie tracimy energię. Ale niektóre idee mają permanentną moc. Jak na przykład, wiele idei w zwinnych metodykach wydaje się mieć rzeczywisty wpływ na produtywność i jakość. Jest tak, ponieważ skupiają się one na problemach ludzi pracujących razem, a mniej na technologiach.
Człowiek, od którego wiele się nauczyłem, Gerald Weinberg, napisał parę swoich pierwszych książek o technologiach programowania. Następnie przestawił się i współtworzył 50 następnych, o procesach programowania, i jest najbardziej znany z powiedzenia "nie ma znaczenia co Ci powiedzą, zawsze jest to problem z ludźmi."
Rzeczami, które zazwyczaj powodują, iż projekt się udaje bądź nie, są problemy z procesem bądź ludźmi. Sposób w jaki pracujesz każdego dnia. To kim są Twoi architekci, Twoi menadżerowie oraz to z kim pracujesz w zespole. To, jak się komunikujesz i co ważniejsze, jak rozwiązujesz problemy z procesem i ludźmi, gdy się pojawią. Najszybszym sposobem na napotkanie trudności jest myślenie, że to wszystko jest winą technologii i wiara w to, że można sobie wytrasować drogę za pomocą innych rzeczy. Te inne rzeczy to najprawdopodobniej te, które Cię zatrzymają.
Bruce źle zapamiętał rzeczywisty cytat; brzmi on "niezależnie od tego co to za problem, jest to problem z ludźmi." Ale przekręcenie Bruce'a ma pewną niewypowiedzianą prawdę, która naturalnie jest w duchu dzieł Geralda Weinberga.
Powiedzmy, że dano mi zadanie określenia czy Twój projekt nie powiedzie się. Posiadając odpowiedzi na trzy poniższe pytania, mogę Ci powiedzieć niemal z całą pewnością, czy Twój projekt upadnie:
- Ile linii kodu Twój zespół napisze?
- Jaki rodzaj oprogramowania tworzysz?
- Czy lubisz swoich współpracowników?
To ostatnie pytanie nie jest żartem. Nie zlewam się. Czy lubisz towarzystwo członków Twojego zespołu? Czy szanujesz ich zawodowo? Czy jakbyś zaczynał w innej firmie, czy zaprosiłbyś swoich współpracowników do siebie? Czy macie nastrojowe, zespołowe dyskusje, czy poniżające, przeciągane, obstrukcyjne zespołowe kłótnie do ostatniej krwi? Czy wielu jest ludzi w Twoim zespole, za którymi byś głosował, żeby odeszli, jeśli byś mógł?
Może banalnym wydawać się skupianie na ludziach, z którymi pracujesz zamiast na rzeczach bardziej namacalnych, powiedzmy, faktycznej pracy bądź konkretnej technologii, której używasz do wykonywania tej pracy. Ale tak nie jest. Ludzie, których wybierasz do pracy, są najdokładniejszym wskaźnikiem satysfakcji z pracy, jaki kiedykolwiek znalazłem. A satysfakcja z pracy, bazując na moim dotychczasowym doświadczeniu, świetnie koreluje z sukcesem. Nigdy nie widziałem szczęśliwego, zdrowego, solidnego, towarzysko zgranego zespołu programistów, który odniósł porażkę. To wstyd, że takie zespoły to rzadkość.
Tak jak to powiedział Weinberg, to zawsze problem z ludźmi. Jeśli nie pracujesz z ludźmi, których lubisz, ludźmi których szanujesz, ludźmi którzy rzucają Ci wyzwania i inspirują Cię -- to czemu by nie? Co Cię zatrzymuje?
Data publikacji oryginału: 9 stycznia, 2008
Zachęcamy do wzięcia udziału w sondzie oraz do podzielenia się w komentarzach własnymi doświadczeniami związanymi z tematyką dzisiejszego wpisu.