Przykłady złego zarządzania

0

Wiadomo, jak jest z bugami. Często są to wpadki i przeoczenia, ale istnieje też tzw. "buggy by design", czyli bug jest po prostu nieuchronną konsekwencją złego designu.

Zauważyłem, że podobnie jest z metodyką pracy. Ona może się potykać, ale czasami pomysł na model pracy jest już sam w sobie głęboko toksyczny.

Np. pracowałem w firmie, w której przy zakładaniu zadań trzeba było oszacować czas wykonania (dajmy na to, 60h). A żeby zacząć, musiałeś wystąpić o akceptację głównego programisty, który z zasady lubił marudzić i się o te estymaty targować.

Za to czas na obsługę zgłoszeń od klientów (ticketów) nie wymagał niczyjej akceptacji, i w praktyce można było z niego korzystać bez ograniczeń. Oczywiście niby bardzo mądrze, bo klient nasz pan i jego problemy są naszym priorytetem.

Połączenie jednego z drugim tworzyło mieszankę zabójczą, bo łatwo sobie wyobrazić, do czego ten system prowadził. Opłacało się wypuszczać wadliwy soft, oszczędzając na testach, a bugi leczyć na produkcji. Było mi niebywale głupio, ale z uczciwości serca sam wprost radziłem klientom, żeby nie dawali z siebie robić świnek morskich i unikali jak ognia wszelkich wersji kończących się na ".0". I aktualizacje robili dopiero po wyjściu kilku łatek.

Mieliście coś takiego, że firma w zasadzie sama, przez swą głupotę, popycha programistów do zachowywania się nieprofesjonalnie?

2

Myślę, że może cię zainteresować książka "Marsz ku klęsce", która opisuje właśnie takie sytuacje.

A żeby zacząć, musiałeś wystąpić o akceptację głównego programisty, który z zasady lubił marudzić i się o te estymaty targować.

W którą stronę? Jeśli w górę to przyznałbym mu rację. Estymaty zwykle są zaniżone o kilkadziesiąt czy kilkaset procent, bo programiści (i PMowie też!) to optymiści i wydaje im się, że zrobią coś w godzinę, a zajmie im to np. cały dzień. Więc to normalne, że estymaty trzeba zwykle pomnożyć przez liczbę rzeczywistą większą od 1, żeby było realistyczniej.

Chyba, że w drugą stronę (co 60 godzin? Zrób to w 30 godzin), wtedy moim zdaniem jest to sabotowanie własnego zespołu, bo wiadomo, że te estymaty będą przekroczone i tak.

1
V-2 napisał(a):

Wiadomo, jak jest z bugami. Często są to wpadki i przeoczenia, ale istnieje też tzw. "buggy by design", czyli bug jest po prostu nieuchronną konsekwencją złego designu.

Zauważyłem, że podobnie jest z metodyką pracy. Ona może się potykać, ale czasami pomysł na model pracy jest już sam w sobie głęboko toksyczny.

Np. pracowałem w firmie, w której przy zakładaniu zadań trzeba było oszacować czas wykonania (dajmy na to, 60h). A żeby zacząć, musiałeś wystąpić o akceptację głównego programisty, który z zasady lubił marudzić i się o te estymaty targować.

Za to czas na obsługę zgłoszeń od klientów (ticketów) nie wymagał niczyjej akceptacji, i w praktyce można było z niego korzystać bez ograniczeń. Oczywiście niby bardzo mądrze, bo klient nasz pan i jego problemy są naszym priorytetem.

Połączenie jednego z drugim tworzyło mieszankę zabójczą, bo łatwo sobie wyobrazić, do czego ten system prowadził. Opłacało się wypuszczać wadliwy soft, oszczędzając na testach, a bugi leczyć na produkcji. Było mi niebywale głupio, ale z uczciwości serca sam wprost radziłem klientom, żeby nie dawali z siebie robić świnek morskich i unikali jak ognia wszelkich wersji kończących się na ".0". I aktualizacje robili dopiero po wyjściu kilku łatek.

Mieliście coś takiego, że firma w zasadzie sama, przez swą głupotę, popycha programistów do zachowywania się nieprofesjonalnie?

Przecież w Polsce tak działa jakieś 90 procent firm. W czym problem? :D

1

dlugo by wymieniac.
co mnie najbardziej irytowalo w poprzedniej pracy to koniecznosc dostarczenia dowodow na przetestowanie kazdej jiry, nie wazne jak bardzo by to nie mialo sensu. release managerzy byli tacy sobie technicznie wiec w praktyce sprowadzalo sie to do tego ze dodawalismy screenshoty logow albo konsoli z rezultatem dzialania komend typu ps czy top (w 90% screenshoty byly 'ustawione' albo opis byl zwyczajna sciema). oczywiscie nie mialo to zbyt duzego znaczenia dla jakosci softu ale czas i kreatywnosc programistow byla marnowana na dowodzenie przetestowania zamiast realnych dzialan poprawiajacych jakosc produktu. wazne ze audyt byl happy ze mamy swietne procedury :)

0

Przykład z życia:
Pracodawca A - postawienie całego projektu od A do Z - dwóch programistów - łączna estymata 370mh - reakcja - co tak długo?
Pracodawca B - dopisanie w miarę skromnego API - jeden programista - estymata 120mh - reakcja - no OK :)

1

SCRUM w wersji czystej i przegadanej do bólu obłożony formalnymi procedurami.

1

Lepiej jeden przykład dobrego zarządzania ;)

0
Czarny Krawiec napisał(a):

Lepiej jeden przykład dobrego zarządzania ;)

http://www.defmacro.org/2014/10/03/engman.html

Ewentualnie książka Peopleware, jeśli masz ochotę na coś dłuższego.
https://www.amazon.com/Peopleware-Productive-Projects-Teams-Second/dp/0932633439

0

Ja pracowałem przy wdrożeniach ERP. Generalnie trochę pracowałem nad jakimiś tam modyfikacjami systemu, trochę nad raportami takimi a'la z hurtowni danych - narzędzie coś jak SSRS w MSSQL, trochę nad wydrukami w Crystal'u. Spotykało się zadania, które były przewidziane do realizacji np. w maju, ale żeby można było to zrobić trzeba było czekać na zadanie przewidziane do realizacji na czerwiec, albo ktoś spieprzył analizę przed wdrożeniem i mamy tam do wykonania "raport X". Na tym opis się kończył i co on miał zawierać nikt nie wiedział. Jednakże kierownicy królestwo Excelowe mieli rozpisane, że dane zadanie ma być w tym terminie i koniec, nieważne czy nie da się jego zrobić bo nie, oni mają w Excelu i koniec.

0

Najpopularniejsze - zatrudnić kogoś nowego i powiedzieć 'masz google, radź sobie, ma być zrobione'

0
Najpopularniejsze - zatrudnić kogoś nowego i powiedzieć 'masz google, radź sobie, ma być zrobione'

Super podejście! Tak własnie pracujemy, a radzimy sobie całkiem dobrze...;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1