Napisałem "od", takie widły to raczej góra stawek programistów w PL, ale oczywiście mogą być wyjątki.
A Ty niby nie podałeś góry dla PMów?
Niestety prosto to wygląda z perspektywy osoby, która nie jest PM, bo:
- skąd tych ludzi?
- ile czasu zajmie wdrożenie aby osiągnąć produktywność?
- o ile obniży się wydajność zespołu jak dostawisz niekomatybilny klocek?
- kto za tego człowieka zapłaci?
Skąd brać ludzi - to nie problem PM, tylko firmy. (Oczywiście głupotą jest obiecywanie klientowi ludzi, których się nie ma.)
Czas wdrożenia i spadek wydajności - dlatego należy dodać tych ludzi sensownie, a nie na zasadzie, że "jeden student zastąpi nieskończoną liczbę specjalistów". ;) A jeśli okaże się, że nie ma sensu dodawać ludzi, to się ich nie dodaje.
A za ludzi płaci klient, przecież nie urząd pracy...
Takie estymaty są podstawą wyceny projektu, więc jak najbardziej są wiele warte, dosłownie.
Finansowo może i są warte, ale jeśli chodzi o ich związek z rzeczywistością są zupełnie bezwartościowe. Zwłaszcza, jeśli tak jak proponujesz, nie uwzględni się w nich architektury i technologii.
Często estymowany jest koszt wewnętrzny, a do klienta idzie inna wycena bo np: plan sprzedaży firmy zakłada wypracowanie przychodu X, koszt developmentu to Y i można go rozłożyć między N klientów.
To zależy od modelu biznesowego firmy. Nie każda firma ma plany sprzedażowe, nie każdy kontrakt to fixed price.
Sztuką jest robić to tak aby nie popłynąć z wyceną i dopiąć kontrakt, bo monetyzacja owego kontraktu jest źródłem pieniędzy na Twoim koncie.
Ja akurat jestem sprzedawany klientowi na godziny. I wydaje mi się, że tak jest z większością ludzi w tej branży, takie przynajmniej mam wrażenie na podstawie rozmów kwalifikacyjnych na których byłem w ciągu ostatnich 2 lat. Ale oczywiście mogę nie mieć racji.
Tak czy siak, zapomnij o Scrumie w biznesie no chyba, że masz klienta, któremu odpowiada praca na tzw "time & material".
Rozsądni klienci już wiedzą, że oprogramowanie to nie jest wykopanie dołka 2x3x4 metry i zwyczajnie nie da się zaplanować ile to zajmie czasu i zasobów przed rozpoczęciem. Rozsądni klienci już wiedzą, że waterfall nie działa. Rozsądni klienci zdają sobie sprawę z tego, że może zajść potrzeba zatrudniania więcej ludzi, przełożenia terminu zakończenia prac, albo zmniejszenia funkcjonalności.
Im większy projekt tym większym samobójstwem jest fixed price. Zarówno dla wykonawcy jak i klienta.
Bardzo bym chciał żyć w świecie, w którym PMowie są niepotrzebni.
Nie mówię, że sa niepotrzebni, napisałem tylko, że w Scrumie ich oficjalnie nie ma. :)
Sam pracowałem w firmie, w której jeden z działów wprowadził Scruma, z wielką pompą i dumą. I do tej pory jest wszystko super pięknie. Tyle tylko, że te "super pięknie" oznacza "oni są ciągle spóźnieni, nawet w porównaniu do ludzi pracujących w waterfallu". No, ale mają Agile'a.
Bo nie wystarczy programistów wysłać na szkolenie ze standupów, a jednego testera obwołać scrum masterem, żeby być agile. Agile jest jak repozytoria - zazwyczaj błędnie używane przez ludzi, którzy coś tam słyszeli, ale nie do końca zrozumieli, i robią po swojemu.
Może i jest dobry dla klienta i producenta, ale z drugiej strony jest rakiem, który zabija produktywność dobrych programistów.