Moje projekty to porażki

2

Przez ostatnie kilka lat pracowałem w kilku różnych firmach typu software house. We wszystkich miałem podobne obowiązki i pracowałem przy podobnym stacku (backend). Łącznie pracowałem przy kilkunastu projektach, zazwyczaj byłem w nich od początku lub nie były zbyt rozbudowane gdy do nich wszedłem. Proste projekty doprowadziłem do końca, poszły na produkcję, klient w miarę zadowolony i strony działają do dziś. Natomiast jeśli projekt wykraczał scopem poza CRUDa z kilkoma dodatkami i zawierał mniej lub bardziej skomplikowaną logikę lub integrację to zaczynają się schody. Zawsze swoje zadania wykonuję porządnie, zdarza mi się sporadycznie przekroczyć wycenę, ale nigdy nie są to jakieś dramatyczne różnice. W wielu projektach miałem wrażenie, że front strasznie wolno robi postępy (z reguły było to API na backendzie + SPA na froncie), przez co czasem wracałem do zamkniętych tasków by zrobić coś niezgodnie z dobrymi praktykami, ale 'na rękę" frontowi, żeby dowieźć projekt w rozsądnym czasie. Z tych bardziej rozbudowanych projektów chyba tylko dwa poszły na produkcję, z czego tylko jeden miał wg mnie ręce i nogi. Pozostałe albo zostały zawieszone, klient kompletnie z nich zrezygnował lub przeniósł się z projektem do innego SH. Nie wiem ile w tym mojej winy i czy w ogóle powinienem się tym przejmować, ale się przejmuję. Nie wiem co mogę robić lepiej, a po każdym takim projekcie strasznie mi spadają morale i mam wrażenie, że klepię "do szuflady". Co mogę zmienić w swoim podejściu, żeby wyprowadzać takie projekty na prostą?

Dodam, że zazwyczaj na demach klient był zadowolony lub neutralny w stosunku do efektów mojej pracy, nigdy nie dostawałem feedbacku na temat tego, że źle lub zbyt wolno wykonuję zadania.

3

Czasami decyzja o przeniesieniu projektu lub jego zamknięciu nie jest związana z tym, że ktoś go źle zrobił. Poza tym, jeśli nie masz pewności, czy robisz wszystko jak należy, to pytaj często o konkretny feedback od klienta i innych programistów, doczytaj książki, dokumentację, itp. żeby mieć pewność, że wiesz, że robisz coś jak należy.

6

Jak nie wiesz kogo wina, to wina klienta lub managementu :D

Nie każdy biznes odnosi sukcesy.

10

Praca wielu ludzi, nie tylko w IT, tak wygląda: robią latami, wypruwają sobie żyły, a na koniec jeden manager z drugim się przetasowuje i cały projekt czy inny proces idzie do kosza. Różne inne wypadki się dzieją, startupy z nieraz naprawdę nieźle zrobionymi tworami powstają i bankrutują (statystyka jest bezlitosna - jakieś 90% takich pada), całe systemy rozkwitają po czym odchodzą do lamusa wyparte przez inne trendy, języki i technologie, wszystko generalnie kotłuje się w jednym wielkim chaosie. Generalnie zalecam nie brać pracy zawodowej do siebie i terapeutycznie czytać Dilberta.

0
wiciu napisał(a):

Czasami decyzja o przeniesieniu projektu lub jego zamknięciu nie jest związana z tym, że ktoś go źle zrobił. Poza tym, jeśli nie masz pewności, czy robisz wszystko jak należy, to pytaj często o konkretny feedback od klienta i innych programistów, doczytaj książki, dokumentację, itp. żeby mieć pewność, że wiesz, że robisz coś jak należy.

Feedback zarówno od współpracowników, jak i od klientów, zawsze dostawałem przynajmniej neutralny, z reguły pozytywny. Nigdy nie otrzymałem sygnału, że źle rozumiem domenę, źle piszę kod lub za wolno pracuję. Wiadomo, że zawsze znalazło się w feedbacku kilka minusów, ale nigdy nie było to nic istotnego z punktu widzenia doprowadzenia projektu do końca, raczej typowo miękkie skille lub sprawy organizacyjne.

1

@throwaway123, ilu ludków, oprócz Ciebie, robi w tym SH w backendzie?

0
lamerski napisał(a):

@throwaway123, ilu ludków, oprócz Ciebie, robi w tym SH w backendzie?

W zależności od firmy od 3 do 30

0

Co mogę zmienić w swoim podejściu, żeby wyprowadzać takie projekty na prostą?

odpowiedź jest prosta:
Improve your skills

1
throwaway123 napisał(a):

Nie wiem co mogę robić lepiej, a po każdym takim projekcie strasznie mi spadają morale i mam wrażenie, że klepię "do szuflady".

Czy "klepanie do szuflady" jest dla Ciebie czymś złym? (Oczywiście nie mówię, że nie może być).

0
Silv napisał(a):
throwaway123 napisał(a):

Nie wiem co mogę robić lepiej, a po każdym takim projekcie strasznie mi spadają morale i mam wrażenie, że klepię "do szuflady".

Czy "klepanie do szuflady" jest dla Ciebie czymś złym? (Oczywiście nie mówię, że nie może być).

W pracy - tak. Do szuflady to mogę pisać projekty w nowych (dla mnie) technologiach lub rozwiązujące nowe (dla mnie) problemy. W pracy, gdzie wykorzystuję najlepiej znane sobie narzędzia moim celem jest dostarczenie jakiejś wartości klientowi. Często wychodzi tak, że nie jestem w stanie tego celu osiągnąć.

0
throwaway123 napisał(a):

W pracy, gdzie wykorzystuję najlepiej znane sobie narzędzia moim celem jest dostarczenie jakiejś wartości klientowi. Często wychodzi tak, że nie jestem w stanie tego celu osiągnąć.

Rzeczywiście, na tym może polegać praca. Z tego wynika, że Twoja ocena, czy dostarczyłeś wartość klientowi, czy nie, jest zwykle negatywna. A z pierwszego Twojego postu wynika, że ocena klienta jest zwykle "neutralna" lub pozytywna. Która ocena według Ciebie powinna się liczyć – Twoja czy klienta?


PS. Jeśli źle myślę, to mnie popraw.


UPDATE: Nie, chyba rzeczywiście źle myślę. Nie bardzo wiem, co masz na myśli przez "dema". Czy dobrze rozumiem, że ocena klienta była zwykle raczej ogólna, nie dotyczyła wiązania całego projektu z Twoją osobą, ale raczej z zespołem?

1

W pracy, gdzie wykorzystuję najlepiej znane sobie narzędzia moim celem jest dostarczenie jakiejś wartości klientowi.

No to i dostarczaj. Jeżeli klient zdecyduje się wyrzucić - jego pieniądze, jego decyzja, jego sprawa.

6

Ja kiedyś w SH pracowałem przy utrzymywaniu aplikacji, którą klient zapomniał wdrożyć na produkcję. Bugów zgłoszonych nie było, a ja w wolnym czasie przepisałem sobie ich inny systemik ze strasznej jednowarstwowej kupy do czegoś prawie zgodnego z DDD.
Klienci mają niesamowite ilości pieniędzy do zmarnowania, projekty na miesiąc potrafią komplikować i ciągnąć latami przy użyciu wielokrotnie przerośniętych ekip. Do tego wewnętrzna polityka, wojny między managerami powodujące upadanie projektów. W tym świecie od programisty nic nie zależy.

Jak chcesz pracować przy czymś wdrożonym na produkcję, to idź do firmy, która ma swój produkt wdrożony na produkcję.

5
  1. Unikaj software houseów i projektów fixed price.
  2. Szukaj firm produktowych.
  3. Nie rób JDD - Jira Driven Development.
  4. Zbieraj więcej feedbacku. Analizuj interakcję użytkowników. Rozmawiaj z klientem. Nie daj się odciąć.

W wielu firmach software traktuje się jako zło konieczne. Byle dostarczyć "COŚ", zgarnąć premię, pobawić się sexy technologią i uciec. Cała konkurencja na czas. Raz, Dwa, Trzy task za taskiem, cegła za cegłą. Niech się mury pną do góry.

To, że odhaczasz taski w jirze i mieścisz się w estymatach to nic nie znaczy. Czy jakikolwiek twój kod działał dłużej niż 4 lata, przy czym na bieżąco był aktualizowany i rozwijany? Startując np w Javie 7, a kończąc na Javie 11?

Unikaj środowisk, gdzie czas i biznes nie weryfikują jakości.

3
[throwaway123 napisał(a)]

W zależności od firmy od 3 do 30

To skąd przypuszczenie, że to Twoje programistyczne niedomagania są przyczyną odrzucania projektów przez klientów?

0

Masz pewnie jakiś korpo stack w ręku (Java/C#), i się dziwisz, że klepiesz biedne rzeczy. Albo stack pod software house (JS/Py/Ruby). Zmień branżę po której się poruszasz. Albo wskocz w jakiś DevOps. Zupełnie inny fun pracy.
Ludzie się dziwią, że robota nudna, powtarzalną robotę. A kto kazał się pchać w takie branże? :-)

4

Zostań fullstackiem, wtedy nie będziesz musiał czekać na front i zrobisz wszystko po swojemu, szybko i skutecznie. Klienci będą zadowoleni, a Ty będziesz miał satysfakcję z dobrze wykonanej pracy.

0

Zadawaj więcej pytań na temat nowych projektów i postaraj się wymierzyć czy to jest coś co faktycznie znajdzie potrzebę czy projekt wydmuszka. Może tym jakoś zwiększysz sobie procent działających aplikacji na środowisku produkcyjnym. Wiadomo, czasem przyjdzie mimo wszystko zrobić coś co pójdzie do szulfady/kosza, ale to już ryzyko zawodowe.

3

Co mogę zmienić w swoim podejściu, żeby wyprowadzać takie projekty na prostą?

Nic, bo to nie twoja działka :) Jeśli projekt jest klapą przez problemy techniczne, to jest twój problem, ale jeśli problemem jest zły research rynku czy złe decyzje biznesowe, szczególnie kiedy nie jesteś ekspertem dziedzinowym, to serio nie bardzo masz na to wpływ. Firma ma innych ludzi, analityków, managerów itd którzy dostają pieniądze żeby ogarniać organizacyjnie sytuację. Nie daj sie złapac w klasyczny marsz ku klęsce. Ty się narobisz żeby "ratować projekt" ale nikt tego i tak nie doceni. Nie warto.

Pozostałe albo zostały zawieszone, klient kompletnie z nich zrezygnował lub przeniósł się z projektem do innego SH.

Pytanie brzmi: czemu? Jesli klient zrezygnował bo:

  • system powstawał za wolno -> problem managera, może trzeba przeanalizować harmonogram prac i ustalić z klientem jakieś MVP
  • system nie spełniał oczekiwań / wymagań -> problem analityków/product ownerów oraz testów akceptacyjnych
  • system działał za wolno, wysypywał się, pewne funkcje były niemożliwe do wykonania przez zły design -> problem zespołu programistów

Nie próbuj być zbawcą świata, chyba że to twoja firma. Zatrudniaja cię i płacą za bycie ekspertem w pewnej konkretnej dziedzinie i tego się trzymaj.

Nie wiem co mogę robić lepiej, a po każdym takim projekcie strasznie mi spadają morale i mam wrażenie, że klepię "do szuflady"

Tak jak ktoś wspomniał, idź do firmy która ma swoje wdrożone produkty.

1

Polecam wyciągać wnioski z tych "cudzych" projektów dla klientów i tworzyć własne, lepsze. Niekoniecznie rozwiązujące ten sam "problem".
O ile ja własnych skopałem, bo zakopałem się w środku projektu, jak mnie moja bieda architekturowa trzasnęła z nienacka... ale zawsze to jakiś feedback, jakiś plus co następnym razem zrobić lepiej, na jaki szczebel nie wchodzić, bo się może złamać...

Także to nie są "porażki". To tylko informacje zwrotne. (C) Turkucio Coehlo

6
throwaway123 napisał(a):

W wielu projektach miałem wrażenie, że front strasznie wolno robi postępy (z reguły było to API na backendzie + SPA na froncie), przez co czasem wracałem do zamkniętych tasków by zrobić coś niezgodnie z dobrymi praktykami, ale 'na rękę" frontowi,

No tu widzę duży problem, bo jeśli od razu nie robiłeś tego backendu DLA frontu - to dla kogo? I co do są dobre praktyki? Bo jeśli tój backend to był klasyczny CRUD / Rest to ja tego od dawna nie uważam za dobrą praktykę.

Dobra praktyka to taka, gdzie najpierw front mówi Ci czego potrzebuje, a Ty to robisz, ewentualnie to trochę naginasz/ negocjujesz - jeśli coś bardzo przeszkadza.
Front pracuje wg wymogów klienta, a backend wg wymogów frontu. Ma im być wygodnie. W innym przypadku backend pracuje do szuflady, czyli jakby zdziwienia nie ma.

3
throwaway123 napisał(a):

Dodam, że zazwyczaj na demach klient był zadowolony lub neutralny w stosunku do efektów mojej pracy, nigdy nie dostawałem feedbacku na temat tego, że źle lub zbyt wolno wykonuję zadania.

A jaka twoja rola w tych projektach była? Jakiś lead czy senior programista albo PM i programista w jednym, że obwiniasz się za niepowodzenie całego projektu? No bo na fakt, czy coś trafiło na produkcję czy nie, to zwykle szeregowy programista ma niewiele do powiedzenia, choćby nawet chciał.

0
throwaway123 napisał(a):

Feedback zarówno od współpracowników, jak i od klientów, zawsze dostawałem przynajmniej neutralny, z reguły pozytywny. Nigdy nie otrzymałem sygnału, że źle rozumiem domenę, źle piszę kod lub za wolno pracuję. Wiadomo, że zawsze znalazło się w feedbacku kilka minusów, ale nigdy nie było to nic istotnego z punktu widzenia doprowadzenia projektu do końca, raczej typowo miękkie skille lub sprawy organizacyjne.

Czyli zawsze cię chwalili. Mi to wygląda na syndrom oszusta.

1
jarekr000000 napisał(a):

Dobra praktyka to taka, gdzie najpierw front mówi Ci czego potrzebuje, a Ty to robisz, ewentualnie to trochę naginasz/ negocjujesz - jeśli coś bardzo przeszkadza.

A jeśli frontów jest 20, to czekamy na wymagania od nich wszystkich?
A jeśli jeszcze 2 fronty są w produkcji, to czekamy aż się skończą tworzyć?
W sumie czemu nie, w końcu płacą od godziny. ;)

Jak się ma cruda z jednym frontem, to sobie można czekać na nich. W trochę bardziej skomplikowanych sytuacjach jednak przydaje się, żeby BA/PO zdefiniowali wymagania.

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