Temat: Umowa z wykonawcą

Witam

Chciałem się dowiedzieć jakie są Wasze doświadczenia i zasady współpracy z firmami zewnętrznymi wykonującymi większość projektu.

Załóżmy, że zlecam firmie programistycznej wykonanie całej pracy.
To co oczekuje ode mnie mój klient to:
- ile to będzie kosztowało
- na kiedy będą gotowe najważniejsze i kluczowe elementy systemu

Natomiast same firmy programistyczne często wymagają:
- dobrych wymagań i dokumentacji aby w miarę dobrze wycenić projekt (tak wiem, początkowa wycena nie będzie miała zbyt dużo wspólnego z rzeczywistością)

Więc jak radzi sobie z tym podejście Agile? Klienta mogę namówić na pracę według Agile ale termin i koszt realizacji musi być i tak mniej więcej określony.

Jak podpisać umowę z firmą wykonawczą. Płacę za faktyczny czas pracy programistów? Jak radzicie sobie z projektami fixed price?

Jedyne co mi w tej chwili przychodzi do głowy to:
1. określenie kluczowej funkcjonalności projektu
2. firma wykonawcza dostarczy mi wycenę i termin realizacji
3. dokładam większy budżet na pojawiające się zmiany w wymaganiach
4. pracujemy do wyczerpania się funduszy mając na uwadze, ze najważniejsze są zadania z punktu 1?

Jakoś mnie to nie przekonuje. Będę wdzięczny za sugestie :)

Temat: Umowa z wykonawcą

Witam,
wiem, że np. w Scrumie powszechne jest planowanie i szacowanie każdego sprintu - jeśli klient w międzyczasie wrzuci tam nowe wymagania, koszt produktów do wykonania w sprincie ulega zmianie. Klient ma świadomość kosztów i czasu zmiany.Paweł Banaś edytował(a) ten post dnia 21.03.10 o godzinie 14:17

Temat: Umowa z wykonawcą

Dawid, zatrudnij analityka systemowego :-) Niech ogarnia wymagania
biznesowe i merytoryczną komunikację z dostawcą.

Generalnie harmonogram jest po to, żeby się go trzymać. Powinieneś z dostawcą uzgodnić różne warianty, np: kiedy jest obsuwa lub kiedy nie da się zaimplementować czegoś co sobie wcześniej zaplanowałeś. W praktyce za obsuwy powinien płacić dostawca, bo jeśli się do czegoś zobowiązał powinien to zrobić. Za błędy w wymaganiach biznesowych powinien płacić sponsor.Przemek Wiśniewski edytował(a) ten post dnia 21.03.10 o godzinie 20:33

Temat: Umowa z wykonawcą

Witam
Pytanie jest jak dokładne chcesz mieć oszacowanie i do czego ma ono służyć. Jeśli ma być "z grubsza" na potrzeby zgrubnego ustalenia wymaganego budżetu, to tak jak piszesz wystarczy określić co to znaczy "kluczowe elementy systemu" i z grubsza co jeszcze chciałby mieć klient. Jeśli oszacowanie ma być dokładne, to bez dokładnych wymagań się nie obędzie.

Zespół z doświadczeniem (popartym danymi ze swoich wcześniejszych projektów) w szacowaniu nie pomyli się za dużo - zarówno co do tego "na kiedy" jak i co do tego "za ile" (w końcu jedno jest funkcją drugiego). Choć oczywiście diabeł tkwi w szczegółach.

Szacowanie w zwinnych projektach różni się tym od zwykłego szacowania, że bazuje na danych statystycznych dotyczących wcześniejszych projektów i szacowaniu zbiorowym a nie wishful thinking jakiegoś eksperta. My np. trzymamy sobie oszacowania i statystyki z wykonanych prac, mamy więc do czego się odnieść przy szacowaniu. Dzięki temu mamy dość mały błąd.

Co do tego jak wygląda realizacja projektu, to zależy od tego czego wy (jako klient) oczekujecie. Jeśli krytyczne jest utrzymanie założonego budżetu co do złotówki, pewnie dostawca będzie mniej chętny do umożliwiania wam zmian. Można liczyć pewnie tylko na wymianę zadań podobnych rozmiarów (czyli każda zmiana zakresu będzie musiała być dokładnie oszacowana). Jeśli zakładacie jakiś budżet na zmiany, to pewnie będzie łatwiej z dodawaniem funkcjonalności.

Od tego czego wy oczekujecie i jak chcecie pracować, zależy rodzaj umowy. Jeśli chcecie fixed price i fixed time, to i zakres musi być fixed (przynajmniej co do ilości pracy). Jeśli natomiast bardziej wam zależy na dopasowaniu produktu idealnie do Waszych potrzeb, dużo lepsze są umowy bazujące na czasie albo ukończonych zadaniach (umowy per story point, itp).

Generalnie umowa to taka gra między dostawcą i odbiorcą. Jeśli nie mają do siebie zaufania, to pozostaje wam "wszystko fixed". Jeśli jest zaufanie, albo przynajmniej sposób weryfikacji i akceptacji pracy, to elastyczniejsze umowy są dużo lepsze. My np. mamy w tej chwili tak, że jeśli klient nie zaakceptuje wyniku/zakresu iteracji, a my nie będziemy się w stanie z tego wytłumaczyć, to po prostu nie dostajemy pieniędzy (na szczęście to tylko teoria, jeszcze się tak nie zdarzyło :)). Klient na bieżąco śledzi postępy i widzi ile pracy jest wykonane w każdej iteracji, może też więc nie tylko wpływać na to co i kiedy jest realizowane, ale może też kontrolować koszty. Taka umowa wymaga oczywiście ścisłej współpracy dostawcy z odbiorcą, ale tego przecież chcemy :)

Strasznie się rozpisałem. Jak byś miał jakieś wątpliwości - służę wiedzą, pomocą i... zespołem.

Temat: Umowa z wykonawcą

Fajnie jakby to pojawiło się jakieś rozwinięcie na blogu Studio Pragmatists ;-).

Temat: Umowa z wykonawcą

Ha, można kiedyś napisać :-)

A tymczasem polecam przejrzeć internet pod kątem artykułów typu agile contracts i optional scope contracts.

Coś napisałem na ten temat też w artykule, który kiedyś napisałem: http://pragmatists.pawellipinski.com/Downloads/Pragmat...

Jeśli chodzi o kontrakty fixed price, to fajny artykuł napisał Marcin Niebudek: http://www.tinypm.com/whitepapers