Kontrakty ze stałą ceną w środowisku non-Agile po stronie klienta
7 views
Skip to first unread message
bartek
Oct 23, 2009, 9:07:41 AM10/23/09
to Polish Agile User Group
Cześć,
natrafiłem na interesujący artykuł Andiego: http://www.scrumalliance.org/articles/70
W szczególności interesujący dla mnie jest ostatni komentarz Pettera
Thor. Opisuje on sytuację, gdy po stronie klienta kierownik projektu
musi starać się o jego finansowanie. W związku z tym potrzebuje
czegoś, co pomoże mu określić rząd potrzebnej kwoty. Najczęściej
sytuacja sprowadza się do sporządzenia zakresu systemu (zawierającego
wszystko co możliwe - żeby było bezpiecznie), przekazania zakresu
potencjalnym wykonawcom z żądaniem wyceny (to pierwszy krok w kierunku
fixed price, fixed scope, ale jeszcze można to zmienić).
Załóżmy, że szczęśliwym trafem takie zapytanie trafia do naszej firmy.
Załóżmy też, że kontrakt jest ciekawy od strony realizacyjnej (np.
nowe technologie), a zarząd uważa, że nowy system umożliwi zdobycie
nowego rynku. Co wtedy? Zapewne mieliście do czynienia z podobną
sytuacją.
Jak zmieniliście nastawienie klienta? Jak Kierownik Projektu zdobył
finansowanie mając jedynie estymaty? Jaki model umowy został
zastosowany? Chodzi mi o konkretne, rzeczywiste przypadki, a nie
teoretyczne rozważania.
Podzielisz się swoją historią?
pozdrawiam,
Bartek
natrafiłem na interesujący artykuł Andiego: http://www.scrumalliance.org/articles/70
W szczególności interesujący dla mnie jest ostatni komentarz Pettera
Thor. Opisuje on sytuację, gdy po stronie klienta kierownik projektu
musi starać się o jego finansowanie. W związku z tym potrzebuje
czegoś, co pomoże mu określić rząd potrzebnej kwoty. Najczęściej
sytuacja sprowadza się do sporządzenia zakresu systemu (zawierającego
wszystko co możliwe - żeby było bezpiecznie), przekazania zakresu
potencjalnym wykonawcom z żądaniem wyceny (to pierwszy krok w kierunku
fixed price, fixed scope, ale jeszcze można to zmienić).
Załóżmy, że szczęśliwym trafem takie zapytanie trafia do naszej firmy.
Załóżmy też, że kontrakt jest ciekawy od strony realizacyjnej (np.
nowe technologie), a zarząd uważa, że nowy system umożliwi zdobycie
nowego rynku. Co wtedy? Zapewne mieliście do czynienia z podobną
sytuacją.
Jak zmieniliście nastawienie klienta? Jak Kierownik Projektu zdobył
finansowanie mając jedynie estymaty? Jaki model umowy został
zastosowany? Chodzi mi o konkretne, rzeczywiste przypadki, a nie
teoretyczne rozważania.
Podzielisz się swoją historią?
pozdrawiam,
Bartek
Daniel Drozdzewski
Oct 23, 2009, 1:12:54 PM10/23/09
to polish-agil...@googlegroups.com
To nie przyklad z mojej pracy, ale ze spotkania z ludzmi z ThoughtWorks.
Oni starajac sie o kontrakty z klientami, ktorzy wymagaja fixed price
+ fixed scope pokazuja, ze podobny projekt, ktory robili z kims
wczesniej zajal im tyle dni i kosztowal tyle. Do tego dokladaja
wystarczajaco duzo klauzul bezpieczenstwa o delikatnych
przesunieciach, czyli ze ich dokladnosc w szacowaniu jest +/- 15%.
Oczywiscie wszystko dziala dobrze, gdy ma sie wystarczajaco wiele
ukonczonych projektow wczesniej.
Do tego jeszcze dolozylbym uwage, ze chyba lepiej jest poswiecic
troche wiecej czasu (i kasy) i wyedukowac klienta niz sie meczyc w
ukladzie fixed cost ,scope and time.
Warto jest ciagle podlreslac klientom, ze ZADEN projekt IT nie jest
fixed scope (chyba, ze piszemy mission critical soft, np. serowanie
hamulcami ABS czy tez elektrownia jadrowa), dlatego tez utrzymujac
fixed cost, scope bedzie musial sie zmniejszyc, poniewaz nigdy (lub
prawie nigdy) nie jest tak, ze projekt kosztowal mniej niz
przewidziano i podwykonawca zwraca nadmiar albo dodaje ekstra funkcje.
Daniel
2009/10/23 bartek <b.kob...@gmail.com>:
--
Daniel Drozdzewski
Oni starajac sie o kontrakty z klientami, ktorzy wymagaja fixed price
+ fixed scope pokazuja, ze podobny projekt, ktory robili z kims
wczesniej zajal im tyle dni i kosztowal tyle. Do tego dokladaja
wystarczajaco duzo klauzul bezpieczenstwa o delikatnych
przesunieciach, czyli ze ich dokladnosc w szacowaniu jest +/- 15%.
Oczywiscie wszystko dziala dobrze, gdy ma sie wystarczajaco wiele
ukonczonych projektow wczesniej.
Do tego jeszcze dolozylbym uwage, ze chyba lepiej jest poswiecic
troche wiecej czasu (i kasy) i wyedukowac klienta niz sie meczyc w
ukladzie fixed cost ,scope and time.
Warto jest ciagle podlreslac klientom, ze ZADEN projekt IT nie jest
fixed scope (chyba, ze piszemy mission critical soft, np. serowanie
hamulcami ABS czy tez elektrownia jadrowa), dlatego tez utrzymujac
fixed cost, scope bedzie musial sie zmniejszyc, poniewaz nigdy (lub
prawie nigdy) nie jest tak, ze projekt kosztowal mniej niz
przewidziano i podwykonawca zwraca nadmiar albo dodaje ekstra funkcje.
Daniel
2009/10/23 bartek <b.kob...@gmail.com>:
Daniel Drozdzewski
Bartek Kobyłecki
Oct 23, 2009, 2:38:14 PM10/23/09
to polish-agil...@googlegroups.com
Mi również wydaje się, że najlepszym rozwiązaniem jest edukacja klienta w temacie. Najprawdopodobniej wysłanie go (na koszt
dostarczającego oprogramowanie) na kurs np. CSPO i uzyskanie efektu 'swojego człowieka' po stronie klienta będzie dużo tańsze niż próby radzenia sobie z FP&FS.
Ciekawy jestem czy ktoś z Was tak zrobił ?
Bartek
2009/10/23 Daniel Drozdzewski <daniel.dr...@gmail.com>
Piotr Gabryanczyk
Oct 24, 2009, 8:31:42 AM10/24/09
to Polish Agile User Group
Opowiem o naszym ostatnim projekcie, nad ktorym pracujemy od lipca:
Klient przyszedl do nas po rozwiazanie problemu, ktory na oko wygladal
mi na 6 miesiecy. Oczywiscie nie chcielismy wchodzic w fixed price/
date - glownie, bo to niekorzystne dla klienta, a naszym zdaniem w
biznesie nalezy dazyc do systuacji win-win. To znaczy takiej, ze
klient jest zadowolony z wykonanej pracy, a nasz zespol nadal istnieje
(ludzie nie odchodza z przepracowania) i chce sie podejmowac
nastepnych projektow dla tego klienta.
Zeby wygrac przetarg - tu mielismy latwo bo klient to niewielka i
elastyczna firma - zrobilismy prototyp najprostszej funkcjonalnosci w
ciagu 3 dni i zaprezentowalismy go klientowi. Na pytanie: "Ile bedzie
kosztowac calosc?" odpowiedzielismy: "Wybierzmy najprostsza
funkcjonalnosc z listy wymagan, ale taka, ktora da wam wartosc
biznesowa i zrobmy ja w ciagu nastepnych 3-4 tygodni. W tym czasie
zdobedziemy wiecej informacji, czego tak na prawde potrzebujecie i
bedziemy mogli dac wam lepsza wycene. Na razie szacujemy, ze pierwszy
etap bedzie kosztowal X, a kolejne funkcje - tu rozbilismy to na
podobnej wielkosci kawalki przez triangulacje - beda kosztowac 75% *
X, bo na poczatku jest zawsze trudniej i trzeba dogadac wiele
szczegolow oraz poznac uwarunkowania srodowiska klienta."
Oczywiscie bylismy w latwiejszej sytuacji niz w przecietnym przetargu,
bo klient sam nie wiedzial, w ktora strone chce rozwijac projekt i
nasza elastycznosc mu odpowiadala. Nie mniej jednak zaczynalo sie
standardowo - "Dajcie nam cene i date!" - i gdyby nie nasza
niestandardowa odpowiedz pewnie nikt nie bylby dzis zadowolony.
Sytuacja na dzis jest taka:
Dostarczylismy pierwszy etap na produkcje zgodnie z ustalonym
harmonogramem - 3 tygodnie pracy + 2 tygodnie na integracje z
platforma, poprawki i ostateczne wypuszczenie na produkcje.
W trakcie prac jedno, na czym nie oszczedzalismy, to jakosc. Dzieki
temu dzis mozemy wypuszczac kolejne poprawki w ciagu kilku godzin.
Klient w miedzy czasie zorientowal sie, ze tak naprawde to wazniejsze
dla niego sa zupelnie inne funkcje, niz te sprzed kilku tygodni i
prosi o zrobienie zupelnie czego innego w kolejnym etapie.
Nowa funkcjonalnosc podzielilismy na kawalki - znow przez porownanie
(triangulacje) i ustalilismy z klientem cene za kolejny krotki etap
3-4 tyg.
W backlogu mamy caly czas oryginalne wymagania, wiec jesli nic sie nie
zmieni to zajmiemy sie nimi w kolejnych etapach.
Jesli chodzi o sprawy prawne, to mamy nastepujace zalozenia:
1. win-win
2. zaufanie
3. Jesli 1 i 2 zawioda to etapy sa na tyle krotkie, ze potencjalna
strata dla nas jest niewielka
4. Jesli nie ma 1 lub 2 to praca na zachodzie nauczyla mnie, ze nie
warto wchodzic w taka relacje - szkoda zycia. Wiem, ze to moze byc
najtrudniejszy punkt do spelnienia bo Polacy sa nieufni, a zwlaszcza
jesli chodzi o pieniadze.
Co z tego wynika?
Podpisalismy z klientem list intencyjny zawierajacy opis
funkcjonalnosci na etap 1 i harmonogram wdrozenia/integracji i cene.
Jestesmy w trakcie formulowania kontraktu, ale na dobra sprawe tylko
po to, zeby prawnicy spali spokojnie i zeby dopiac drobiazgi typu
support SLA, etc.
Chetnie opowiem o tym wiecej... :)
Piotr Gabryanczyk
-
http://www.2ndlanguagelimited.co.uk
Klient przyszedl do nas po rozwiazanie problemu, ktory na oko wygladal
mi na 6 miesiecy. Oczywiscie nie chcielismy wchodzic w fixed price/
date - glownie, bo to niekorzystne dla klienta, a naszym zdaniem w
biznesie nalezy dazyc do systuacji win-win. To znaczy takiej, ze
klient jest zadowolony z wykonanej pracy, a nasz zespol nadal istnieje
(ludzie nie odchodza z przepracowania) i chce sie podejmowac
nastepnych projektow dla tego klienta.
Zeby wygrac przetarg - tu mielismy latwo bo klient to niewielka i
elastyczna firma - zrobilismy prototyp najprostszej funkcjonalnosci w
ciagu 3 dni i zaprezentowalismy go klientowi. Na pytanie: "Ile bedzie
kosztowac calosc?" odpowiedzielismy: "Wybierzmy najprostsza
funkcjonalnosc z listy wymagan, ale taka, ktora da wam wartosc
biznesowa i zrobmy ja w ciagu nastepnych 3-4 tygodni. W tym czasie
zdobedziemy wiecej informacji, czego tak na prawde potrzebujecie i
bedziemy mogli dac wam lepsza wycene. Na razie szacujemy, ze pierwszy
etap bedzie kosztowal X, a kolejne funkcje - tu rozbilismy to na
podobnej wielkosci kawalki przez triangulacje - beda kosztowac 75% *
X, bo na poczatku jest zawsze trudniej i trzeba dogadac wiele
szczegolow oraz poznac uwarunkowania srodowiska klienta."
Oczywiscie bylismy w latwiejszej sytuacji niz w przecietnym przetargu,
bo klient sam nie wiedzial, w ktora strone chce rozwijac projekt i
nasza elastycznosc mu odpowiadala. Nie mniej jednak zaczynalo sie
standardowo - "Dajcie nam cene i date!" - i gdyby nie nasza
niestandardowa odpowiedz pewnie nikt nie bylby dzis zadowolony.
Sytuacja na dzis jest taka:
Dostarczylismy pierwszy etap na produkcje zgodnie z ustalonym
harmonogramem - 3 tygodnie pracy + 2 tygodnie na integracje z
platforma, poprawki i ostateczne wypuszczenie na produkcje.
W trakcie prac jedno, na czym nie oszczedzalismy, to jakosc. Dzieki
temu dzis mozemy wypuszczac kolejne poprawki w ciagu kilku godzin.
Klient w miedzy czasie zorientowal sie, ze tak naprawde to wazniejsze
dla niego sa zupelnie inne funkcje, niz te sprzed kilku tygodni i
prosi o zrobienie zupelnie czego innego w kolejnym etapie.
Nowa funkcjonalnosc podzielilismy na kawalki - znow przez porownanie
(triangulacje) i ustalilismy z klientem cene za kolejny krotki etap
3-4 tyg.
W backlogu mamy caly czas oryginalne wymagania, wiec jesli nic sie nie
zmieni to zajmiemy sie nimi w kolejnych etapach.
Jesli chodzi o sprawy prawne, to mamy nastepujace zalozenia:
1. win-win
2. zaufanie
3. Jesli 1 i 2 zawioda to etapy sa na tyle krotkie, ze potencjalna
strata dla nas jest niewielka
4. Jesli nie ma 1 lub 2 to praca na zachodzie nauczyla mnie, ze nie
warto wchodzic w taka relacje - szkoda zycia. Wiem, ze to moze byc
najtrudniejszy punkt do spelnienia bo Polacy sa nieufni, a zwlaszcza
jesli chodzi o pieniadze.
Co z tego wynika?
Podpisalismy z klientem list intencyjny zawierajacy opis
funkcjonalnosci na etap 1 i harmonogram wdrozenia/integracji i cene.
Jestesmy w trakcie formulowania kontraktu, ale na dobra sprawe tylko
po to, zeby prawnicy spali spokojnie i zeby dopiac drobiazgi typu
support SLA, etc.
Chetnie opowiem o tym wiecej... :)
Piotr Gabryanczyk
-
http://www.2ndlanguagelimited.co.uk
Andy Brandt
Oct 25, 2009, 3:23:53 PM10/25/09
to polish-agil...@googlegroups.com
Witam!
2009/10/23 bartek <b.kob...@gmail.com>:
> natrafiłem na interesujący artykuł Andiego: http://www.scrumalliance.org/articles/70
Dzięki za dobre słowo.
> W szczególności interesujący dla mnie jest ostatni komentarz Pettera
> Thor. Opisuje on sytuację, gdy po stronie klienta kierownik projektu
> musi starać się o jego finansowanie. W związku z tym potrzebuje
> czegoś, co pomoże mu określić rząd potrzebnej kwoty.
Ja generalnie nie widzę nic złego w oszacowywaniu wielkości projektu
jako takiej, w długofalowym planowaniu i tak dalej. To są dobre
rzeczy, dopóty, dopóki pamięta się o tem, że oszacowanie to nie
obietnica a plan to nie rzeczywistość. Właśnie mylenie planów z
rzeczywistością i próba ich zamrażania w kontraktach jest źródłem
dużej części zła, o którym pisałem.
Nasze podejście jest takie, że pytanie: ile circa to będzie
kosztować/trwać uważamy za całkowicie uprawnione. Budujemy wspólnie z
klientem i/lub na podstawie dokumentów dostarczonych oszacowanie i
wynikiem tegoż dzielimy się z klientem. Jest zupełnie jasne, że klient
ma konkretny budżet a często i konkretny termin i chce wiedzieć czy
to, co chce zbudować w ogóle się w tym mieści. Jeśli się nie mieści to
może albo pójść gdzie indziej i kupić pikną malowaną obietnicę, że jak
się o-tu podpisze to będzie wszystko cacy (czyli fix bid) albo może
wspólnie z nami się zastanowić co się da zrobić w czasie lub budżecie
jaki mamy do dyspozycji.
Innymi słowy: uważam, że klient ma prawo wymagać oszacowania wielkości
swojego projektu bo ma prawo z grubsza wiedzieć ile to będzie
kosztować i jak długo trwać. Ostatecznie na jakiejś podstawie musi na
przykład zdecydować czy się w to w ogóle bawić w obrębie pieniędzy
jakimi dysponuje, a poza korporacyjnym światem darmowych developerów
rzadko kto ma nieograniczone fundusze na swój projekt.
--
Regards,
Andy
http://www.codesprinters.com/
http://www.andybrandt.net/
Wave to me: akbr...@googlewave.com
Andy Brandt
Oct 25, 2009, 3:24:43 PM10/25/09
to polish-agil...@googlegroups.com
Witam!
2009/10/24 Piotr Gabryanczyk <pio...@gmail.com>:
>
> Opowiem o naszym ostatnim projekcie, nad ktorym pracujemy od lipca:
>
> Klient przyszedl do nas...
Bardzo fajna historia. Tak się właśnie przekonuje klientów do agile.
Jedno pytanie: klient z Polski czy nie?
bartek
Oct 25, 2009, 3:43:03 PM10/25/09
to Polish Agile User Group
Podoba mi się Twój przypadek. Mam kilka przemyśleń po przeczytaniu
Twojego postu.
Jestem jak najbardziej za strategią win-win. Jest jednak oczywiste, że
nie wszędzie da się ją zastosować, mimo najlepszych chęci ze strony
firmy software-owej. Co wtedy? Ja bym postąpił tak jak piszesz -
najlepiej w taki kontrakt po prostu nie wchodzić. Mam wrażenie że
wiele firm softwareowych upadło /ma problemy/ nie dlatego, że
zrealizowało za mało kontraktów, lecz dlatego, że podjęli się
niewykonalnego. I niestety - dopóki będą firmy które będą realizować
gówniane kontrakty, dopóty klienci będą się upierać przy fixed
everything. Jeżeli naprawdę zależy nam na realizacji jakiegoś projektu
myślę że warto wcześniej poświęcić czas na edukację klienta. Gdy
będzie mu zależało na etapie przed podpisaniem umowy, można
przypuszczać, że później przerodzi się to w efektywną współpracę. If
there's a will, there's a way, jak mawiają gdzieśtam.
Niezłym, według mnie, mechanizmem do negocjacji z klientem jest
macierz kompromisów (trade-off matrix) - tutaj opisane jest jak działa
http://gary-crow.com/resources/agile_project_management_create_products/ch05lev1sec5.html
W ogóle cały project data sheet (tak nazywa się ten arkusz w metodyce
Agile Project Management - APM) wydaje się być dobrym narzędziem.
Zarówno Daniel jak i Ty piszecie, że bardzo pomocne przy estymowaniu
projektu są poprzednie, podobne przedsięwzięcia. Chyba działa tu
podobny mechanizm punktów relatywnych jaki wykorzystuje się przy
estymowaniu User Stories. Wniosek stąd taki, że warto trzymać dane
historyczne o przedsięwzięciach - choćby to ile łącznie w ramach
projektu wykonano Story Points i ile poświęcono godzin (dlaczego jedno
i drugie może się przydać zobaczcię tutaj - punkt Bob Martin's idea).
Jedno pytanie: jaka była rola listu intencyjnego? Nie spotkałem się z
tym wcześniej.
Zachęcam do dalszego dzielenia się swoimi historiami :o)
pzdr
bartek
> -http://www.2ndlanguagelimited.co.uk
Twojego postu.
Jestem jak najbardziej za strategią win-win. Jest jednak oczywiste, że
nie wszędzie da się ją zastosować, mimo najlepszych chęci ze strony
firmy software-owej. Co wtedy? Ja bym postąpił tak jak piszesz -
najlepiej w taki kontrakt po prostu nie wchodzić. Mam wrażenie że
wiele firm softwareowych upadło /ma problemy/ nie dlatego, że
zrealizowało za mało kontraktów, lecz dlatego, że podjęli się
niewykonalnego. I niestety - dopóki będą firmy które będą realizować
gówniane kontrakty, dopóty klienci będą się upierać przy fixed
everything. Jeżeli naprawdę zależy nam na realizacji jakiegoś projektu
myślę że warto wcześniej poświęcić czas na edukację klienta. Gdy
będzie mu zależało na etapie przed podpisaniem umowy, można
przypuszczać, że później przerodzi się to w efektywną współpracę. If
there's a will, there's a way, jak mawiają gdzieśtam.
Niezłym, według mnie, mechanizmem do negocjacji z klientem jest
macierz kompromisów (trade-off matrix) - tutaj opisane jest jak działa
http://gary-crow.com/resources/agile_project_management_create_products/ch05lev1sec5.html
W ogóle cały project data sheet (tak nazywa się ten arkusz w metodyce
Agile Project Management - APM) wydaje się być dobrym narzędziem.
Zarówno Daniel jak i Ty piszecie, że bardzo pomocne przy estymowaniu
projektu są poprzednie, podobne przedsięwzięcia. Chyba działa tu
podobny mechanizm punktów relatywnych jaki wykorzystuje się przy
estymowaniu User Stories. Wniosek stąd taki, że warto trzymać dane
historyczne o przedsięwzięciach - choćby to ile łącznie w ramach
projektu wykonano Story Points i ile poświęcono godzin (dlaczego jedno
i drugie może się przydać zobaczcię tutaj - punkt Bob Martin's idea).
Jedno pytanie: jaka była rola listu intencyjnego? Nie spotkałem się z
tym wcześniej.
Zachęcam do dalszego dzielenia się swoimi historiami :o)
pzdr
bartek
Piotr Gabryanczyk
Oct 26, 2009, 10:34:58 AM10/26/09
to Polish Agile User Group
Klient jest z Polski.
On 25 Paź, 19:24, Andy Brandt <akbra...@gmail.com> wrote:
> Witam!
>
> 2009/10/24 Piotr Gabryanczyk <piot...@gmail.com>:
On 25 Paź, 19:24, Andy Brandt <akbra...@gmail.com> wrote:
> Witam!
>
> 2009/10/24 Piotr Gabryanczyk <piot...@gmail.com>:
>
>
>
> > Opowiem o naszym ostatnim projekcie, nad ktorym pracujemy od lipca:
>
> > Klient przyszedl do nas...
>
> Bardzo fajna historia. Tak się właśnie przekonuje klientów do agile.
> Jedno pytanie: klient z Polski czy nie?
>
> --
> Regards,
> Andy
>
> http://www.codesprinters.com/http://www.andybrandt.net/
> Wave to me: akbra...@googlewave.com>
>
> > Opowiem o naszym ostatnim projekcie, nad ktorym pracujemy od lipca:
>
> > Klient przyszedl do nas...
>
> Bardzo fajna historia. Tak się właśnie przekonuje klientów do agile.
> Jedno pytanie: klient z Polski czy nie?
>
> --
> Regards,
> Andy
>
> http://www.codesprinters.com/http://www.andybrandt.net/
Piotr Gabryanczyk
Nov 1, 2009, 3:28:00 PM11/1/09
to Polish Agile User Group
> Jedno pytanie: jaka była rola listu intencyjnego? Nie spotkałem się z
> tym wcześniej.
Rola listu intencyjnego bylo skonkretyzowanie wspolpracy i okreslenie
> tym wcześniej.
wstepnych ramow projektu. Jest to taki rodzaj wstepnej umowy czyli:
"My jako firma XYZ podejmujemy sie zrealizowania funkcjonalnosci XYZ w
mniej wiecej takim a takim czasie za mniej wiecej takie a takie
pieniadze. Ustalamy ze zarowno harmonogram jak i zakres prac bedzie
podlegal zmianom tak aby dostarczyc rozwiazanie ktore satysfakcjonuje
klienta. Cena moze rowniez podlegac zmianie w zaleznosci od zmian w
zakresie prac."
Klient po podpisaniu papierka zaczyna powazniej traktowac projekt mimo
tego, ze nic tak na prawde nie jest ustalone.
Data podpisania listu staje sie data rozpoczecia prac, co popycha caly
projekt do przodu.
Zaraz za listem powinna isc umowa.
Piotr Gabryanczyk
Reply all
Reply to author
Forward
0 new messages