Czy to możliwe żeby połowa czasu była kodowaniem?

Ostatnio widziałem ogłoszenie z takimi statystykami
55% coding
10% documentation
20% bug fixes
15% meetings

Z tego co wiem to 80% prac z całego cyklu życia projektu to utrzymania. Tutaj jest to powiedzmy po zsumowaniu (45%)
Jakoś sceptycznie podchodzę do tych statystyk. Czy to możliwe żeby połowa czasu była kodowaniem
Co myślicie??

75% statystyk jest brane z d'py.
te też na takie wyglądają.
Poza tym nie masz żadnej pewności że za miesiąc się wszystko nie zmieni XD
Widziałem człowieka któremu się wszystko zmieniło w przeciągu tygodnia bo inwestor się wycofał :(

Ja tam lubię się grzebać w bugach, natomiast mnie strzela jak mam dopisać 6 obiektów dla nowego end pointa w API, albo zmienić 10 bo doszło nowe pole.

A bugfixy to nie kodowanie?

Osobiście meetingów mam 1-2h tygodniowo max. Reszta to analiza wymagania od strony kodu, jak to sensownie ogarnąć i właściwa implementacja. Serio tak ciężko znaleźć pracę/kontrakt, gdzie większość czasu siedzi się nad kodem?

Wg mnie bugfix to tez kodowanie. Najważniejsze jest aby działało na produkcji

A nie masz wpływu na to jak wyglada model??

Zastany kod, nie chce tam już więcej mieszać niż jest, żeby potomni mnie nie przeklinali do 6tego pokolenia.

Ogólnie fajnie, ale myślę że obiektywnie, bez jakiegoś śledzenia aktywności pracowników + przejrzenia tego minuta po minucie (bezsens), to można tylko policzyć spotkania, biorąc średni tydzień z kalendarza i dzieląc przez 40. Reszta jest wyssana z palca i "na czuja", co oczywiście nie znaczy, że jest niedokładne, może w sumie tak być faktycznie.

Ale tak - oczywiście że istnieją takie projekty gdzie większość czasu to klepanie kodu, sam pracowałem w takim - po prostu potrzebny jest: w miarę nowy projekt (czyli odpada utrzymanie) którego jeszcze nie ma na prodzie (albo jest ale mało userów), sterta mockupów i przepływów, stały kontakt z klientem na żywo i można napieprzać taski. Powiedziałbym że "siedzenia w IDE" było pewnie z 70-80%, spotkania to 1 syncup 20-30 min dziennie, reszta pomijalna.

czirman napisał(a):

Ostatnio widziałem ogłoszenie z takimi statystykami
55% coding
10% documentation
20% bug fixes
15% meetings

Z tego co wiem to 80% prac z całego cyklu życia projektu to utrzymania. Tutaj jest to powiedzmy po zsumowaniu (45%)
Jakoś sceptycznie podchodzę do tych statystyk. Czy to możliwe żeby połowa czasu była kodowaniem
Co myślicie??

To jest manipulacja. Bug fixes to też kodowanie. Coding to jak przypuszczam skrót myślowy od kodowania nowych ficzerów.
Czyli 75% to rzeczy związane z programowaniem (55% coding + 20% bug fixes).
Ale znowu:

• jak to w ogóle zmierzyli? Bardzo łatwo jest powiedzieć programistom "logujcie na time trackerze, co robicie", tylko że wiadomo, że to nie będą miarodajne statystyki. Ktoś może nic nie zrobić danego dnia, ale nabić 8h, żeby dostać dniówkę.
• 75% z czego? Jeśli 100% to (jak można przypuszczać) 8h pracy dziennie, to raczej są to mocno zawyżone statystyki. Ludzie nie pracują po 8h.
• nawet w samym kodowaniu nowych ficzerów to nie jest tak, że kodujesz cały czas, bo myślenie jest ważne. Kodowanie to może być patrzenie w okno i myślenie.
• naprawianie bugów to w większości nie naprawianie tylko próby lokalizacji buga. Jak znajdziesz przyczynę, to naprawienie zwykle jest łatwe.

Czyli te procenty nie wiadomo czy są prawdziwe i nie znaczy to, że jak tyle procentów, to przez tyle czasu będziesz pisać kod (jeśli są prawdziwe, to znaczyłoby, że faktycznego pisania kodu jest mniej niż 55%).

Wczoraj właśnie miałem spotkanie z kimś z firmy bo muszą ocenić procentowo ile czasu spędzamy na R&D żeby mieć jakieś ulgi podatkowe i potrzebują tego do zeznania dla IRS. Czas nie jest w żaden sposób trackowany więc muszą to wyciągnąć od pracowników i robią to na losowej próbce.
Godzinne spotkanie gdzie miałem opisać projekt i ocenić ile procent czasu poświęcam na różne kategorie, przy czym czułem "delikatny" nacisk na to żeby jak najwięcej przydzielić do kodowania nowych funkcji i ogólnie procesom dotyczącym rozwoju a nie utrzymania więc na "coding" wyszło koło 50%.

Także być może te wartości są właśnie z takiego spotkania, a może nie ale na pewno któryś członek zespołu po prostu wycenił to "na oko", inaczej te wartości procentowe nie byłyby takie równe.
To tylko ogólny zarys jak wygląda dzień pracy z którego możesz wywnioskować że nie musisz się zajmować supportem ani też spędzać pół dnia na spotkaniach i że utrzymują tam jakąś dokumentację, nie ma co tego brać na poważnie. Jestem przekonany że "bug fixing" przewyższa "coding" zwłaszcza że nie ma tam czasu poświęconego na "testing" chyba że pisanie testów podpięli pod "coding"

czirman napisał(a):

Ostatnio widziałem ogłoszenie z takimi statystykami
55% coding
10% documentation
20% bug fixes
15% meetings

Z tego co wiem to 80% prac z całego cyklu życia projektu to utrzymania. Tutaj jest to powiedzmy po zsumowaniu (45%)

Nie wiem jak Ty to policzyłeś. 80% dotyczy całego cyklu życia projektu, a Ty dodajesz jakieś liczby z jego losowego momentu.

Jakoś sceptycznie podchodzę do tych statystyk. Czy to możliwe żeby połowa czasu była kodowaniem

Zdarza się, że nawet 120% czasu to kodowanie. Jak się nie analizuje, i nie projektuje, to kodowania jest tyle, że nie ma kiedy taczki załadować.

obscurity napisał(a):

Wczoraj właśnie miałem spotkanie z kimś z firmy bo muszą ocenić procentowo ile czasu spędzamy na R&D żeby mieć jakieś ulgi podatkowe i potrzebują tego do zeznania dla IRS.

Czyli już sama intencja nie jest czysta, skoro nie chcą się dowiedzieć prawdy, a chcą mieć jedynie podkładkę pod papiery...

Czas nie jest w żaden sposób trackowany

...na dodatku opartą na zmyślonych informacjach.

więc muszą to wyciągnąć od pracowników i robią to na losowej próbce.

Nawet trackowany czas będzie zawyżać dane (no bo niezależnie od tego, czy ktoś pracował w rzeczywistości 7h czy 3h danego dnia, to wpisze pełne 8h, bo tego się od niego oczekuje, od tego przecież jego wypłata zależy), a co dopiero takie zgadywanki, w dodatku pod sugestią, że muszą to być takie liczby, żeby wyszło, że dużo czasu spędzamy na R&D żeby mieć jakieś ulgi podatkowe i gdzie jest "delikatny" nacisk na to żeby jak najwięcej przydzielić do kodowania nowych funkcji i ogólnie procesom dotyczącym rozwoju a nie utrzymania więc na "coding" wyszło koło 50%..

Wiadomo, że rzeczy wymyślane na potrzeby formalne często w praktyce nie mają wiele wspólnego z rzeczywistością.

No, ale przecież śledzenie czasu w zadaniach na jirze też nie da odpowiedzi na pytanie jaki procent pracy to spotkania a jaki kodowanie?
A przynajmniej jak ja to robiłem to nie dawało odpowiedzi bo w zadaniach była informacja tylko ile czasu spędziło się nad zadaniem bez rozdzielenia czy to było kodowanie czy spotkania. Dodatkowo czas z okresowych spotkań jak daily, demo jest rodzielany pomiędzy aktualnie robione zadania bo przeciez o tych zadaniach mówi się na daily.

Wiec z takiej normalnej Jiry można co najwyżej wyciągnąć informacje ile procent jest bugów a ile feature'ów

BTW trochę trochę oftop ale przypomniało mi się jak w firmie gdzie pracował znajomy programiści pożalili się że jest tyle spotkań że nie ma czasu kodować, to góra wymyśliła że spotkania nie mogą trwać dłużej niż godzinę i PO/BA zaczeli dzielić spotkania na części XD

KamilAdam napisał(a):

No, ale przecież śledzenie czasu w zadaniach na jirze też nie da odpowiedzi na pytanie jaki procent pracy to spotkania a jaki kodowanie?
A przynajmniej jak ja to robiłem to nie dawało odpowiedzi bo w zadaniach była informacja tylko ile czasu spędziło się nad zadaniem bez rozdzielenia czy to było kodowanie czy spotkania. Dodatkowo czas z okresowych spotkań jak daily, demo jest rodzielany pomiędzy aktualnie robione zadania bo przeciez o tych zadaniach mówi się na daily.

Wiec z takiej normalnej Jiry można co najwyżej wyciągnąć informacje ile procent jest bugów a ile feature'ów

Śledzenie czasu w Jirze to w ogóle brzmi jak jakiś całkowite marnotrawstwo energii.

BTW trochę trochę oftop ale przypomniało mi się jak w firmie gdzie pracował znajomy programiści pożalili się że jest tyle spotkań że nie ma czasu kodować, to góra wymyśliła że spotkania nie mogą trwać dłużej niż godzinę i PO/BA zaczeli dzielić spotkania na części XD

No u mnie tak jest. Przecież po godzinnym spotkaniu każdy jest już zmęczony, i nikt nie jest w stanie się skupić. Jeśli nie zdążyliśmy omówić wszystkiego, to ustawia się następne spotkanie za kilka dni.