mój system pracy a praca w IT

3

W kazdej firmie sie w ten sposob odnajdziesz jezeli bedziesz zawyzal estymaty lub nie przyznawal sie wczesnie ze cos zrobiles przed czasem, bo i po co.
Najlepiej jeszcze jak w miedzyczasie doglebnie rozgryziesz architekture, obecny kod itd tak ze pozniejsze debugowanie i szukanie rozwiazan bedzie Ci latwo przychodzilo podczas gdy inni (wlasnie tacy co kiedys pisalem srednio rozumujacy robiacy na czuja metoda prob i bledow czesto z pomoca innych) musza poswiecic na to duzo czasu. Ty tez wtedy mozesz udawac ze poswiecasz na to czas. To jest moja taktyka ktora sprawdza sie od 3 lat i wraz ze wzrostem doswiadczenia i kolejnym projektem jest coraz latwiej.
Czasu wolnego zaoszczedzonego w ten sposob poswiecam 25% na rozwoj, reszte na sprawy prywatne.

3

To kiedy to przebranżowienie, byku?

2
kosmonauta80 napisał(a):

Wyobraźcie sobie, że budujecie biurowiec. Rozległy task od wykopania fundamentów po końcowe odbiory. Ewidentnie task, który w czasie musi być rozgrzebany. I co, codziennie chłopy od łopat, elektrycy i malarze mają raportować kierownikowi budowy/inwestorowi co się dzieje? WTF?!

Nie wiem w jakiej branży jesteś obecnie, ale w budowlance byłem przez lat ok. 10 i nie wyobrażam sobie sytuacji, żeby kierownik budowy nie wiedział, co się na budowie dzieje.
Zwykle ma on codziennie (albo prawie) informacje od ludzi poniżej ( a ci z kolei od jeszcze niższych szczebli), które przekazuje inwestorowi (też regularnie, ale gorzej niż w IT, bo zwykle "wtedy kiedy inwestor zapyta" - czyli np. 3 razy dziennie "bo tak").

Elektryk/malarz/itp. musi powiedzieć swojemu szefowi / majstrowi / dyspozytorowi/itp., na jakim jest etapie i najczęściej też ile mu dany etap zajmie (żeby można było w miarę sensownie zaplanować pracę). Szeregowy malarz nie jest zostawiany samemu sobie na miesiąc, mając przydzielone np. 3 piętra.

4

Jak to sobie wyobrażasz? Dostajesz jakieś zadanie do zrobienia, zostanie dostarczone na "kiedyś" w żadnym momencie robienia tego zadania nie jesteś w stanie powiedzieć czy i na kiedy zostanie zrobione, a później nagle w biurze stoi choinka a pod nią to co miałeś zrobić?
Taki system pracy się nie sprawdza, bo zazwyczaj pod tą choinką jest coś innego niż wszyscy myśleli, że będzie. Jak masz jakieś terminy, na kiedy to jest potrzebne, to presja czasu też będzie. Ale da się ogarnąć pracę, gdzie nie ma terminów totalnie z d...y, typu "jutro kończy się sprint i musimy dowieźć" i da się znaleźć zespoły, w których nikt nie pyta co piętnaście minut o to czy aby na pewno będzie zrobione.

0
kosmonauta80 napisał(a):

Wyobraźcie sobie, że budujecie biurowiec. Rozległy task od wykopania fundamentów po końcowe odbiory.

To o czym piszesz to analogia do monolitu. Tylko teraz nie tworzy się już tak oprogramowania. Co najwyżej utrzymuje.

Jeśli miałbym coś wskazać, co najbardziej może być zbliżone do opisanego przez Ciebie systemu pracy, to może jakieś działy R&D firm rozwijających własne produkty, gdzie tak trochę na czuja wymyślają i opracowują nowe funkcjonalności, z czego potem i tak nie wszystko trafia na produkcję ostatecznie. Obstawiam, że raczej niezbyt wiele takich firm łatwo znajdziesz, aczkolwiek się zdarzają.

Ooo, i może też gdzieś w działach IT w budżetówce. Ale tam też kokosów nie zarobisz.

0

Lubię takie dyskusje. Są bardzo wartościowe, bo w pewnym sensie "refraktoryzują" poglądy.

0

@PaulGilbert: To raczej ten słynny waterfall. A w R&D pracowałem i też, jak miało się jakiś pomysł, to trzeba było też mieć jakieś zgrubne pojęcie ile on będzie kosztował pracy. Interakcji międzyludzkich było tam zresztą więcej niż przy klepaniu jakiegoś CRUD'a.

0

Juz wiem, szukasz czegos co jest okreslane jako: "rest and vest"

0
piotrpo napisał(a):

@PaulGilbert: To raczej ten słynny waterfall. A w R&D pracowałem i też, jak miało się jakiś pomysł, to trzeba było też mieć jakieś zgrubne pojęcie ile on będzie kosztował pracy. Interakcji międzyludzkich było tam zresztą więcej niż przy klepaniu jakiegoś CRUD'a.

Tak, o takiego waterfalla mi chodziło. I tak, w takim R&D więcej się gada niż pracuje technicznie. Czasami nawet i cały dzień spory o jakąś funkcjonalność. To miałem właśnie na myśli, że taki luźniejszy styl pracy - a przynajmniej tak może być postrzegany. Bo jak nie masz spiny na przeforsowanie jakiegoś pomysłu a pracujesz zdalnie, to w zasadzie tylko słuchasz jak się inni spierają i tylko czasami coś tam wrzucasz do rozmowy, żeby nie było, że usnąłeś. :-D

Osobiście jak dla mnie to chyba bardziej męczące takie spotkania niż wykonywanie konkretnych zadań. Ale to wszystko już zależy od tego, co kto lubi a i też z kim się pracuje.

0

Jakiś czas temu robiłem stronę WWW dla klientów firmy (mini katalog + formularz PDF), całość w czystym HTML/CSS/JS/PHP. Generalnie cały dzień klepałem ten kod (i przeglądałem StackOverflow xD ). Przyznam, że to mi pasowało. I co ważne, każdego dnia na koniec był jakiś progres. Więc w sumie mini raport z postępu prac by mi nie przeszkadzał.

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