Czy to ja mam problem?

1

Cześć,
zastanawiam się ostatnimi czy to ze mną jest jakiś problem... otóż pracuję sobie w pewnej firmie i od nie dawna dostaliśmy nowy projekt do budowania. Wszystko fajnie - projekt jest ciekawy i wydaje się sensowny. Szybko przeszliśmy do developmentu i tutaj zaczął się problem. Od początku planowania pracy i pierwszego kodu widzę, że coś tutaj jest nie tak. Że za bardzo się macha ręka na wszystko. Estymacja pojedynczego taska odbywała się na podstawie prostego opisu tegoż zadania (1-2 zdania) i prototypu designu. PM nakazał pędzić do przodu bo klient jest zły jak się robi nie wiadomo co - on musi mieć jasno powiedziane nad czym my siedzimy i co robimy - więc robimy task za taskiem - czasem na odczep, bo mało czasu. Jestem front-endowcem w tym projekcie, pracujemy w React. Pierwsza rzecz, która przestała mi pasować to to, że zaczęliśmy klepać komponenty stron bez przygotowania reużywalnych komponentów UI. Teraz ciagle czegoś brakuje i trzeba dorabiać, zmieniać bo jednak w jakimś jednym miejscu są wyjątki w wyglądzie. Jak coś robię chwilkę dłużej (dzień lub dwa) to już jest problem, bo za długo robię. Że już powinienem robić kolejny task bo czas leci... bardzo mnie to demotywuje, praca traci sens i nie chce mi się. Może to mój perfekcjonizm jest tutaj problemem, że wprost nienawidzę robić czegoś na odczep. Lubię refaktorować kod, by był czysty. Co robić? Czy ja powinienem wybrać się do psychologa? Czy to ze mną jest problem?

6

Dzień dobry Panie psychologu, mam taki problem. Lubie refaktorować

15

Z opisu wynika że pracujesz u Janusza.

0

Ja bym szukał spokojniejsze roboty :) co do samego pięknego kodu refactoingu itp to pamiętaj, że nawet w korpo musisz mieć poważne argumenty za by to przeszło. Refaktoryzuje się przy robieniu nowych tasków, wliczając koszt pracy w ten task zgodnie z zasadą "zostawiaj kod lepszym niż go zastałeś" ale na czysty refactoring to rzadko kiedy można sobie pozwolić.

0

Czyli jeśli już od początku robicie byle jak to tak już zostanie :D Game over

10

title

0

Jeśli to projekty krótkoterminowe to raczej nie dziwne, co innego z utrzymaniem to w takiej sytuacji faktycznie strzał w stopę.

6

Estymacja pojedynczego taska odbywała się na podstawie prostego opisu tegoż zadania (1-2 zdania) i prototypu designu.

To akurat jedyna pozytywna rzecz. Estymacja to strata czasu, więc należy na nią poświęcać jak najmniej czasu. Można nawet rzucić kostką i zobaczyć co wypadnie. A idealnie to w ogóle nie estymować, bo w programowaniu za dużo jest niewiadomych i każda estymacja większego zadania to zgadywanka.

PM nakazał pędzić do przodu bo klient jest zły jak się robi nie wiadomo co - on musi mieć jasno powiedziane nad czym my siedzimy i co robimy

Czyli micromanaging ze strony klienta. Przypuszczalnie niski budżet projektu / klient sknera, który żałuje kasy na każdy kolejny dzień roboczy.

Jak coś robię chwilkę dłużej (dzień lub dwa) to już jest problem, bo za długo robię. Że już powinienem robić kolejny task bo czas leci...

Czyli micromanaging ze strony (jak się domyślam) PMa? To źle, bo PM powinien was właśnie chronić przed złym klientem, a nie przejmować jego emocje (swoją drogą czy to nie śmieszne, że to są niby "poważne biznesy", a tyle zależy po prostu od ludzkich emocji, ktoś się wścieka na coś, że coś jest niezrobione, a przecież to tylko jego emocje są, bo racjonalnie podchodząc to programowanie to pewien proces, a nie, że "już". Trochę jakby się wściekać na kobietę, że musi aż 9 miesięcy być w ciąży i poganiać, żeby się pośpieszyła)

i co robimy - więc robimy task za taskiem - czasem na odczep, bo mało czasu.

Jeśli programiści mieliby w przyszłości zakładać związki zawodowe i robić strajki - to taka sytuacja mogłaby być właśnie powodem, dla którego mieliby to robić. Jakbyście się zebrali całą grupą i przestali kodzić, albo zrobili strajk włoski(czyli wszystko 10 razy dokładniej niż potrzeba), to coś by to może dało.

Tylko, że w praktyce to i tak w IT się nie strajkuje, tylko zmienia firmę w takiej sytuacji. Bo tak prościej, poza tym skuteczniej (jak twój szef jest Januszem to i tak w głębi serca nim będzie).

Pierwsza rzecz, która przestała mi pasować to to, że zaczęliśmy klepać komponenty stron bez przygotowania reużywalnych komponentów UI. Teraz ciagle czegoś brakuje i trzeba dorabiać, zmieniać bo jednak w jakimś jednym miejscu są wyjątki w wyglądzie.

Czyli ta firma to taki Titanic. Ostatni gasi światło.

2

To następnym razem, jak PM stwierdzi, że robisz jakiegoś taska zbyt długo, to mu powiedz, żeby sam go zrobił szybciej.
To nie jest zadanie PMa decydować jak długo trwają taski.

6
xd napisał(a):

Może to mój perfekcjonizm jest tutaj problemem, że wprost nienawidzę robić czegoś na odczep. Lubię refaktorować kod, by był czysty.

Najtrudniejszą sztuką jest znaleźć złoty środek między perfekcjonizmem a pragmatyzmem. Jak zauważył Zawinski: "At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products."

Klient nasz pan, i jeśli klient chce mieć projekt bazgrany w pośpiechu, to jest jego problem.

Nie zmieniałbym firmy wyłącznie z tego powodu, bo uciekać przed każdą taką sytuacją nie ma sensu. Wszędzie może się trafić taki projekt. To jest urok pracy w firmach typu software house. Zdarzają się trudni klienci. Pracuję w porządnym miejscu, a też takich miewałem.

Za problem uznałbym dopiero:
a) gdybyś nie miał oparcia we własnej firmie. Źle wróży, jeśli sam PM nie rozumie, że niechlujne estymacje itp. muszą się odbić na jakości, i bierze stronę klienta, a nie twoją.
b) gdyby firma miała wyłącznie takich klientów i takie projekty, widocznie ich w jakiś sposób przyciągając.

Każdy woli pracować z czymś czystym i dobrze przemyślanym. W rzeczywistości nie zawsze można na to liczyć. Perfekcjonizm to jest "choroba regulara", który nauczył się już wszelkich dobrych praktyk i jest pełen zapału, żeby wszystkie stosować, ale nie myśli jeszcze w kategoriach biznesowych.

Różnie się wychodzi z tego syndromu. Niejeden stary programista wraca do domu, zasłania żaluzje, otwiera z namaszczeniem szkatułkę swego laptopa - i dłubie przy własnym projekcie. Który jest piękny, z nienaganną architekturą, wzorową dokumentacją każdego zaułka, czterokrotnie poprawianym nazewnictwem; nawet układ graficzny kodu wyciska łzy wzruszenia u osób wrażliwych na estetykę. Projekcie z reguły nigdy nie skończonym ;)

3

Pewnie już wszyscy tutaj to widzieli, ale tak mi się przypomniało:

poryty kod

4

Nie jest to projekt krótkoterminowy. Duży projekt na długi czas, ale wersja MVP ma być szybko zrobiona - a jej zakres jest dość spory

Jeśli tak to niestety strzelacie sobie w stopę. Co po fazie MVP jak zrobicie paździerz którego nie będzie dało sensownie się rozwijać? Jak przekonacie klienta że trzeba refaktorować 70% kodu, i dlaczego niby miałby za to płacić? Niestety byłem w takiej sytuacji i od tamtej pory nie robię szpachli nawet jeśli taki jest przykaz z góry i jak ktoś próbuje robić to dostaje ode mnie solidny feedback dlaczego takie podejście to głupota.

Estymacja pojedynczego taska odbywała się na podstawie prostego opisu tegoż zadania (1-2 zdania) i prototypu designu.
To akurat jedyna pozytywna rzecz. Estymacja to strata czasu, więc należy na nią poświęcać jak najmniej czasu.

Nie kiedy klient chce dokładnego rozliczania, w takim wypadku estymacja taska powinna opierać się na DoD zaakceptowanym przez klienta, a nie po dwu zdaniowym opisie.

Jak coś robię chwilkę dłużej (dzień lub dwa) to już jest problem, bo za długo robię. Że już powinienem robić kolejny task bo czas leci...

Na sam koniec: estymaty != deadline. Polecam to dokładnie przedyskutować z panem PM.

5
cmd napisał(a):

Estymacja pojedynczego taska odbywała się na podstawie prostego opisu tegoż zadania (1-2 zdania) i prototypu designu.
To akurat jedyna pozytywna rzecz. Estymacja to strata czasu, więc należy na nią poświęcać jak najmniej czasu.

Nie kiedy klient chce dokładnego rozliczania, w takim wypadku estymacja taska powinna opierać się na DoD zaakceptowanym przez klienta, a nie po dwu zdaniowym opisie.

Trzeba podkreślić, że estymacja a specyfikacja to są dwie różne sprawy.
Dobre wyspecyfikowanie zadania na pewno nie jest stratą czasu, wręcz przeciwnie.
Natomiast sama estymacja może zająć 10 sekund: "no, to chyba tak na 3 dni będzie - nie, raczej 4, bo jeszcze coś tam coś tam - dobra, 4". Next! Nawet jeśli precyzja estymacji jest słaba, tak czy siak nie jest ona procesem czasochłonnym.

Na sam koniec: estymaty != deadline. Polecam to dokładnie przedyskutować z panem PM.

Zgadza się. Estymacja to nie zobowiązanie. To jest "scenariusz środkowy", czyli pośredni między optymistycznym a pesymistycznym. Jeśli mam się zobowiązać, że coś zdążę, to zastosuję pesymistyczną estymację z buforem bezpieczeństwa.

http://cwd.dhemery.com/2003/08/estimates_are_not_commitments/

A już najlepsze jest negocjowanie estymat: "Dwa tygodnie? A nie da rady w jeden? Jak się sprężycie?" :) Wtedy faktycznie pora się rozejrzeć za inną firmą...

1

Co po fazie MVP jak zrobicie paździerz którego nie będzie dało sensownie się rozwijać?

Przypuszczam, że tym już się zajmie pewnie inna firma. Jak w demokracji przedstawicielskiej - rządzący interesują się tylko tym, co będzie do kolejnych wyborów, bo potem i tak będzie następna kadencja i ona zmiecie burdel.

A potem kolejna firma dostanie potworka spaghetti code do opieki i jacyś obcy programiści będą was przeklinać, bo będą musieli sprzątać burdel, który wyście narobili.

0
cmd napisał(a):

Jeśli tak to niestety strzelacie sobie w stopę. Co po fazie MVP jak zrobicie paździerz którego nie będzie dało sensownie się rozwijać?

idealnie w ten temat wpisuje się mój ulubiony cytat z The Mythical Man-Month:

The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.

9

A propos MVP.
Przypomniała mi się pewna sytuacja, firma robiła apkę, taka tam pod klienta biznesowego, zarządzanie mailami, chatem, jakiś newsletter takie pierdoły.
No i robił ją gościu, który po okresie próbnym umowy nie przedłużył.
Zbliżał się termin oddania, no i PM do mnie, czy bym nie zerknął tak ostatecznie, czy nie trzeba czegoś dopieścić na koniec, poprawić itp.
No i na szybko próbuję się zalogować, nic, sprawdzam dane - poprawne, o co chodzi.
Sprawdzam pliki, a tam się okazuje, że apki w ogóle nie ma, są tylko piękne (material design) statyczne pliki html/css nic więcej :D

2

Ale wy się nauczcie - że kasę kosi ten kto oddaje produkt jako tako podobny do oczekiwań klienta, a nie ten kto oddaje produkt o pięknym kodzie. A januszsofty i korpo są od koszenia kasy właśnie.

0
xd napisał(a):

Cześć,
zastanawiam się ostatnimi czy to ze mną jest jakiś problem... otóż pracuję sobie w pewnej firmie i od nie dawna dostaliśmy nowy projekt do budowania. Wszystko fajnie - projekt jest ciekawy i wydaje się sensowny. Szybko przeszliśmy do developmentu i tutaj zaczął się problem. Od początku planowania pracy i pierwszego kodu widzę, że coś tutaj jest nie tak.

Widzisz to tylko Ty czy może też inni? Znasz opinie innych?

0
czysteskarpety napisał(a):

Zbliżał się termin oddania, no i PM do mnie, czy bym nie zerknął tak ostatecznie, czy nie trzeba czegoś dopieścić na koniec, poprawić itp.
No i na szybko próbuję się zalogować, nic, sprawdzam dane - poprawne, o co chodzi.
Sprawdzam pliki, a tam się okazuje, że apki w ogóle nie ma, są tylko piękne (material design) statyczne pliki html/css nic więcej :D

Ta wspominka ma jeszcze luźniejszy związek z tematem, ale mi się skojarzyło : )

W mojej pierwszej pracy minąłem się z poprzednikiem, którego projekt przerósł. Jego morale legło w gruzach i - niczym poniżony w pojedynku Kmicic - zdecydował się na jedyny możliwy krok. Czyli odejście.

Jego ostatni dzień w firmie miał być uroczystym przekazaniem kodu, sprawozdania z barwnych dokonań, ustalenia wytycznych dla szczęśliwych kontynuatorów, itd.

Siadł z nim w tym celu główny firmowy macher. Proces szedł wszakże niemrawo. Dzień chylił się ku upadkowi, efekty były wątłe, a zmęczony szef programistów żądał już tylko absolutnego minimum - żeby delikwent przynajmniej zbudował feralny projekt.

Mimo nadludzkich i ponawianych wysiłków aplikacja nie chciała się jednak skompilować. Musiało to wpłynąć drażniąco na pęcherz nieszczęsnego młodego człowieka, bo ogłosił płaczliwie, że musi na chwilkę siku. Na biurku został jego ulubiony kubek z niedopitą kawą. I tyle zostało nam po nim po wsze czasy, bo główny programista czekał nadaremno. Facet już więcej się nie pojawił :)

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