Zastanawia mnie ja wygląda praca pod względem czasu u developerów. Czy jest tak, że macie wyznaczony task na skończenie zadania? Albo może nie ma oficjalnego czasu, ale co jakiś czas stoi nad wami kierownik i marudzi że jeszcze nieskończone? Oczywiście wiadomo, że są okresy gdzie projekt ma być gotowy na przedwczoraj, lecz chodzi mi tak ogółem. A bardzo interesowałoby mnie temat juniorów i mindów.
Pozdrawiam
Ogólnie jak w każdej pracy. Tylko estymacja czasu jest inna niz w kazdej innej pracy. Wynika to z tego ze zadania w większości przypadków nie sa powtarzalne i 7-8 przypadków na 10 za każdym razem robisz albo cos innego niż wczesniej albo wyskakuje cos nowego. Albo jak dzisiaj szukanie błędu w wywalonych walidacjach, a okazalo sie ze blad spowodowany byl dodaniem nowego gema.
Jak dla mnie zależy od skali projektu, prestiżu klienta, trudności zadania, wiadomo jak z jednym crudem będziesz walczył miesiąc to pewnie w końcu ktoś to zauważy :)
Różnie to bywało.
Jednak dobrze jest, jeśli ludzie z którymi współpracujesz mają świadomość tego, że programowanie to pewien proces.
Czyli nie na zasadzie, że stoją nad tobą (bywało, że dosłownie nad monitorem nade mną stali) i mówią "2 piksele w lewo, raz, raz, dajesz".
Ani nie na zasadzie, że np. przez tydzień nie dowiozłeś kompletnego taska to już mówią, że jesteś "mało efektywny". A możliwe, że przez ten tydzień robiłeś research i zbierałeś know-how, żeby się dowiedzieć w jaki sposób można stworzyć dobre rozwiązanie - a takie rzeczy nie zawsze są widoczne w historii comitów w Git, więc ktoś patrząc z boku może pomyśleć, że jest opóźnienie w projekcie.
Z drugiej strony bywało tak, że starałem się zrobić ładne (i bardziej czasochłonne) rozwiązanie, a okazało się, że biznes tego wcale nie potrzebował i się okazało, że biznes najbardziej zadowolony byłby, jakbym dowiózł spaghetti, żeby tylko było coś do pokazania na demówkę dla klienta w czwartek o 15:00.
Tylko że takie rzeczy (czy lepiej szybko ale bylejak, czy wolniej ale porządniej) też się powinno między sobą dogadywać. Ta presja czasu czasem wynika z jakichś braków komunikacji czy zrozumienia się stron, a nie z tego, że faktycznie projekty zapieprzają.
Ew. jeszcze bywają spore opóźnienia w projektach przez spłacanie długu technologicznego. I to też trudno wytłumaczyć niektórym, że niestety, w zastanym spaghetti kodzie będzie się robiło trochę dłużej niż normalnie.
Ja powiem tak: Jak zaczynałem pracować, to task który robiłem przez cały 1 dzień wydawał mi się mega wielki. Obecnie nie dziwi mnie jak prosta zmiana jednej linijki trwa 3 dni.
Duży Zając napisał(a):
Zastanawia mnie ja wygląda praca pod względem czasu u developerów. Czy jest tak, że macie wyznaczony task na skończenie zadania? Albo może nie ma oficjalnego czasu, ale co jakiś czas stoi nad wami kierownik i marudzi że jeszcze nieskończone? Oczywiście wiadomo, że są okresy gdzie projekt ma być gotowy na przedwczoraj, lecz chodzi mi tak ogółem. A bardzo interesowałoby mnie temat juniorów i mindów.
Pozdrawiam
Wygląda to różnie w zależności od organizacji pracy w konkretnej firmie. Przykładowo w poprzedniej firmie developerzy informowali dopiero po zrobieniu taska ile zajął i kiedy go realizowali, a efektywność była oceniania "na oko". Z kolei w obecnej firmie zadania przed sprintem wycenia cały zespół i każdy developer musi dowieźć swoje taski w ciągu 2 tygodni. Jeżeli ktoś się nie wyrobi, to musi się z tego tłumaczyć przed przełożonym.
Odnośnie presji w pracy i nierealnych terminów - jeżeli jesteście uczciwi wobec siebie i pracodawcy i jesteście profesjonalistami to przeczytajcie poniższy tekst jak postępować.
... Z pewnością sposób bycia Franka stanowił jakiś problem. Jego ciągłe onieśmielanie rozmówcy sprawiało, że ciężko było mu usłyszeć prawdę. Z pewnością Bill i James powinni byli bardziej naciskać Franka. Z pewnością szef zespołu programistów nie powinien był zgadzać się na piątkowy termin. Ostatecznie ja sam powinienem był powiedzieć ,.nie", zamiast wstawiać się za szefem zespołu. Profesjonaliści mówią prawdę niezależnie od sytuacji. Profesjonaliści mają odwagę powiedzieć ,nie" swoim przełożonym. Ale jak powiedzieć ,nie" swojemu szefowi? W końcu to Twój szef! Czy nie należałoby robić tego, co szef nakazuje? Nie. Nie, jeżeli uważasz się za profesjonalistę. Niewolnik nie ma prawa powiedzieć,.nie". Robotnicy mogą mieć opory przed mówieniem nie. Ale od profesjonalistów oczekuje się, że będą mówić "nie". Co więcej, dobrzy menedżerowie szukają ludzi, którzy mają charakter, żeby się sprzeciwiać. Tylko w ten sposób można naprawdę wiele osiągnąć.
Menedżerowie są ludźmi, którym powierzono określone zadanie, i większość z nich doskonale wie jak to zadanie wykonać. Część ich pracy polega na jak najagresywniejszej obronie wyznaczonych im celów. Podobnie programiści - też są ludźmi, którzy również mają do wykonania pewne zadanie i większość z nich wie. jak się z niego dobrze wywiązać. Jeżeli są oni profesjonalistami, to będą starali się bronić swoich celów tak agresywnie, jak tylko będą mogli.
Gdy Twój kierownik mówi Ci, że strona logowania ma być gotowa na jutro, to stara się osiągać swoje własne cele. Wykonuje po prostu swoją prace. Jeżeli doskonale wiesz, że przygotowanie strony logowania na jutro jest po prostu niemożliwe, to mówiąc: "OK, spróbuje", zdecydowanie nie wykonujesz swojej pracy. Te pracę wykonasz właściwie tylko twierdząc, że to jest niemożliwe. Czy jednak nie masz obowiązku wykonywania poleceń przełożonego? Wcale nie. Twój menedżer liczy właśnie na to, że będziesz bronić swoich celów tak agresywnie, jak on broni swoich. Tylko w ten sposób będziecie w stanie wypracować rozwiązanie najlepsze z mozliwych. Takim rozwiązaniem jest cel, pod którym Ty i Twój kierownik możecie się podpisać. Cała sztuka polega na odnalezieniu takiego celu, a to zwykle wymaga negocjowania.
Czasami takie negocjacje mogą być całkiem przyjemne.
Mike: "Paula, ta strona logowania musi być gotowa na jutro"
Paula: "O rany! Tak szybko? Ale OK, spróbuję"
Mike: "Świetnie, wielkie dzięki!"
To była całkiem miła rozmowa. Całkowity brak konfrontacji, a obie strony rozstały się z uśmiechem. Wspaniale. Jednak obie strony zachowały się bardzo nieprofesjonalnie. Paula wie doskonale, że przygotowanie strony logowania zajmie jej trochę więcej niż jeden dzień, a zatem kłamie. Być może nawet nie myśli o tym w kategorii kłamstwa i naprawdę ma zamiar spróbować, bo ma choć cień nadziei, że uda jej się dotrzymać terminu. Jak by na to nie patrzeć to nadal jest kłamstwo. Jednakże Mike uznał słowo "spróbuję" za "tak". To wyjątkowo głupie założenie. Powinien wiedzieć, że Paula próbuje tylko uniknąć konfrontacji...
Zalezy od wielu czynnikow.
Podczas wdrozenia sprawdza Twoje tempo, tutaj raczej beda Ci szli na reke bo 3 miesiace to malo czasu na duzy projekt i na styk na sredni projekt.
Jak bedzie mniej wiecej okej to przedluza Ci umowe.
Potem z biegiem czasu beda oczekiwac, ze uplynnisz prace.
Teraz tak, Twoj manager bedzie prawdopodobnie nietechniczy wiec bedzie polegac na produkt ownerze i kolegach z zespolu(seksizm!!!) wiec jesli bedziesz cos robic bardzo dlugo a to jest proste to moze sie o tym dowiedziec, to prawdopodobienstwo rosnie jesli nie masz kolegow w zespole ale spada jesli zespol Cie lubi.
Tyle.
Są jakieś różnicę w zależności od stanowiska? np. czy Front-end Dev ustala czas na realizacje zadania w taki sam sposób jak Backend Dev? czy może Front-end ma więcej "swobody"?
Smutny Ogrodnik napisał(a):
Są jakieś różnicę w zależności od stanowiska? np. czy Front-end Dev ustala czas na realizacje zadania w taki sam sposób jak Backend Dev? czy może Front-end ma więcej "swobody"?
W taki sam sposób.
hmm... a jak to wygląda w przypadku C++ albo Data Scientist?
W pewnej Wroclawskiej firmie wszyscy liniowi sa teraz PO. Masz PO i Twoj bezposredni przelozony to Twoj PO.