Nie słuchaj, co mówią — problemem zawsze są ludzie

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:

  1. Ile linii kodu Twój zespół napisze?
  2. Jaki rodzaj oprogramowania tworzysz?
  3. 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.

Czy lubisz swoich współpracowników?

5 komentarze:

Anonimowy pisze...

Coraz bardziej te artykuły się nudne robią.

Jak się ma idiotów w zespole, którzy się opieprzają, to produkt jest taki jaki jest, albo w ogóle nie ma produktu i koniec.

Ehh, jak ja nie lubię szukania dziury tam gdzie jej niema.

ksirg pisze...

To nie o to chodziło, zgadzam się że jak masz idiotów to wiele z nimi nie wyczarujesz. Zdarzyło mi się pracować z ludźmi którzy byli dobrzy w tym co robią, lecz jakoś współpraca w grupie się nie układała, wiele kłótni o to kto ma racje i jak to należy zrobić nie pchało projektu do przodu. Dlatego uważam że najważniejsze to dopasować charaktery w zespole.

Ps. Dla mnie ciekawy artykuł :)

Konradzik pisze...

Ten post to podsumowanie tego co wszyscy ktrórzy pracowali, bądź pracują w zespole podświadomie już wiedzieli. Ludzie którzy się lubią słuchają sie na wzajem, pomagają sobie, wprowadzają "spoon of sugar" do pracy - np. dopisując śmieszny komentarz.

Nie bez powodu firmy które organizują imprezy typu 'zacieśnianie więzi zespołu' (paintball, quady itd.) wyrosły ostatnimi czasy jak po deszczu - pracodawcy zdają sobie sprawę z benefitów zgranego zespołu.

koziołek pisze...

Bo nawet jak projekt jest durny to można przynajmniej w fajnej ekipie pójść na browara po anulowaniu projektu.

Tomasz Kowalczyk pisze...

Ciężko jest znaleźć grupę programistów, która chciałaby ze sobą współpracować na zdrowych zasadach, bo to jest społeczność oparta na hierarchii umiejętności, więc albo należy znaleźć zespół ludzi o tych samych albo bardzo podobnych możliwościach, albo zmusić tych "lepszych", żeby byli bardziej zintegrowani i nie irytowali się aż tak pomaganiem tym gorszym.

Prześlij komentarz

Related Posts with Thumbnails