Proč si klienti nerozumí s dodavatelem jejich software aneb jak poznat problémovou zakázku (I. díl)

podla mna by uplne stacilo nepustat sa do programovania pred tym, nez je vypracovane zadanie - podpisane konzultantom aj zadavatelom a kym nie su presne vymedzene pravidla, za akych je mozne zadanie po zacati prace zmenit.

Yano, je to jistě jedna z možných cest, která teoreticky funguje skvěle, prakticky se však těžko vždy daří "přesně vymezit pravidla" a dobře "vypracovat zadání".

(Opačnou cestou jdou agilní metodiky vývoje že..)

Každopádně, pokud jdete cestou "vše dobře popsat" a pak teprve začít programovat, doporučím do vymezených pravidel sepsat nejen to, co přesně je obsahem zakázky, ale i vše to, co jejím obsahem není.

Vyhnete se pak pozdějším námitkám typu "ale to je přeci samozřejmé, že" a) součástí dodávky musí být xy, vždyť to dá rozum ne.. b) že tohle bude fungovat tak a tak..

My problémové klienty zvládáme snadno - pošleme je do pr.dele :)

Normální práce je dost, tak proč se s někým zahazovat. Stejně jako si klient může vybírat nás, můžeme si i my vybírat klienta. Nejsme žádný hypermarket, kde si každý může nakupovat jak chce.

Jak snadno poznat problémového klienta? Jde po co nejnižší ceně. Zdánlivě jednoduché pravidlo, ale funguje.

1. ad yana - podepsane zadani klientem je sice hezka vec, ale v momente, kdy se jedna o opravdu problemoveho klienta pak zcela neucinna. Nehlede na to, ze sepsat komplexni analyzu systemu je prakticky nemozne (a velmi casto pro klienta financne neunosne), protoze existuje vzdy n pocet variant reseni a funkci, o kterych muze klient predpokladat, ze jsou logickou soucasti systemu aniz jsou nekde popsany :-) Obecne je tento model dnes uz prakticky nepouzivany. Je lepsi pouzivat bud agilni metodiky nebo reseni, ktera jsou "balickova".

2. souhlasim s Martinem a jeste doplnim, ze ne vzdy se problemovy klient identifikuje hned na pocatku. Proto jako jednu z dulezitych praktik vidim opustit projekt vcas v momente, kdy je jasne, ze jde o problemoveho klienta a projekt se dostal do slepe ulicky (tj. kdy byly vycerpany veskere - podotykam VESKERE prostredky jak dosahnout shody s klientem v dalsim procesu vyvoje zakazky). Ono je to totiz tak, ze pak existuji jen dve varianty dalsiho vyvoje: 1. firma nainvestuje statisice do projektu a jeho novych funkci jen aby byl klient spokojeny (a to problemovy klient nikdy neni) 2. firma dokonci projekt v souladu s puvodnim zadanim bez ohledu na namitky klienta. Obe varianty vedou ke shodnemu cili - nespokojeny zakaznik. V obou pripadech take firma investuje sve prostredky do dokonceni projektu (1 varianta je uplne nejhorsi) aniz by je zakaznik ve finale zaplatil. Tady plati jedine - projekt v dany moment ukoncit a radeji se venovat dalsim vecem, ktere maji smysl :-)

Pokud je „problémový“ klient, který přesně neví, co chce, který dodavateli tak docela nerozumí, a který má málo času a prostředků, pak je problémový v podstatě každý klient :) Žádné jednoduché řešení podle mě neexistuje. Říct, že je potřeba dát na procesy a zkušenosti, je podle mě – nic ve zlém – cesta do pekel. Protože procesy jsou jen prostředek (kam a proč vlastně chceme?) a zkušenosti buď jsou a je to dobrý, nebo nejsou a je to špatný (čili opět žádné konstruktivní a zopakovatelné řešení).

Podle mě je dobrý začít tím, že si člověk uvědomí komunikační problémy, ten impedanční rozdíl mezi světem klienta a dodavatele. Největší problém je totiž v přesné specifikaci požadavků – a problémový klient je ten, ze kterého se specifikace špatně tahá. (Ne nutně jeho vinou, třeba kvůli povaze projektu.) Na tohle téma je výborná kniha Software Requirements od Karla Wiegerse (ISBN 0735606315), která teď někdy vyjde v českém překladu u Computer Pressu. [Překládal jsem ji já, takže si trochu hřeju polívčičku, ale upřímně si myslím, že je to dobrá kniha a stojí za přečtení.]

Zajimave tema ale nadlouho. Pridam k tomu 2 odkazy:
* http://www.fandor.cz/vysiraci-typologie-zakaznicke-skupiny/
a
* http://beneta.blog.lupa.cz/0801/nas-zakaznik-nas-pan-napiste-si-to-alespon-96-bodovym-pismem-nad-sve-lcd
ten druhy odkaz podle mne je logickym zacatkem mnoha problemu popsanych vyse :)

Nejjednoduší je asi žádné klienty nemít, to je pak klídek, pohoda, sociální dávky jednou za měsíc :-)

[1] Yano: Jiste, ale zkuste z hlediska objednavatele dopredu domyslet veskere moznosti reseni.
Pohled programatora byva velmi odlisny od pohledu uzivatele. Jako vyborny priklad jsou ruzne dohledove systemy ruznych technologii (SDH/PDH/radia atd)
Zakladni informace jsou nekdy hluboko zahrabane anebo se vubec nezobrazuji, zatimco kraviny efektne blikaj a houkaj jedna radost.

A nejvic ze vseho se mi libi odpoved otazkou potencionalniho dodavatele - "a proc to chcete?"

pokial ten co objednava nevie co chce tak to vacsinou znamena ze sa neskor musi vela veci prerabat - aj ked sa mu to dopredu snazite vysvetlit...

[12] Ano. Jednou z cest je zacit s programovanim (nekdy staci i jen drateny model ci hypertextovy protyp aplikace) co nejdrive.

A jeste je take dobre dat pozor na ty, co vcelku presne vi co chteji, ale chteji to, co nepotrebuji. Spravny dodavatel (analytik) by tohle mel poznat a navest klienta na to, co opravdu potrebuje.

[6] Nishkame, jestli to chápu správně, chceš tím říct, že když se budeme snažit zákazníkovi vyjít vstříc, je to začátek uvedených problémů. To je asi správný předpoklad. A tehdy se právě ukáže ten zkušený dodavatel, který si i s takovým klientem dokáže poradit. Ne nutně každý klient totiž musí být ten ideální (o tom by asi naši dodavatelé mohli vyprávět :)

Tzn. jde o to, umět klient nasměrovat do určitých pravidel (i chaos a nepřesně specifikovaný projekt může mít, v tomto případě musí mít, svá pravidla). A hlavně s ním komunikovat na správné vlnové délce, tak jak uvádějí komentáře výše.

No a nakonec mu říct (a jsme zase u té komunikace), že každá sranda něco stojí, a když jde z jakéhokoliv důvodu o problémovou zakázku, nebude to za cenu "ideální" zakázky.

PS: u nás mámě něco jako IPK (index průserovosti klienta), kterým zvyšujeme standardní kalkulovanou cenu :) A jak poznamenal Martin [3], jedním z ukazatelů je právě to, že jde za každou cenu po ceně..

[9] Petre, podle meho nazoru, ke kteremu jsem dospel po mnoha bolestnych zkusenostech, dulezita je POZICE dodavatele ve vztahu ke klientovi. Mame 2 moznosti. Bud

1* jsme sluzebnicci naseho pana ZAKAZNIKa, ktery vi co chce a my jsme od toho abychom za penize mu udelali jakykoliv jeho rozmar anebo
2* jsme duveryhodni experti, ke kterym se zakaznik obratil, abychom mu pomohli, protoze de fakto nevi co a jak

Za to, jak ten vztah vypada, odpovida jak zakaznik tak dodavatel. Proto nesouhlasim, ze problem je pouze v nepohodlnem klientovi.

Snazim se dnes pracovat pouze z pozice 2, protoze v konecnem dusledku se pak nestydim za svoji praci a zakaznik je spokojenejsi nez v pripade 1 - dostava lepsi vysledek! Vetsinou alespon teoreticky mam i vice penez. Proto ty penize jsou takovym testerem. Pokud me zakaznik respektuje jako odbornika, nema problem zaplatit. Jestlize si mysli, ze jsem sluzebnicek, pak mi urcuje jake "dyzko" dostanu a jeste to musim tezce odmakat, nejlepe aby zakaznik videl, ze tvrde pracuji :)

Myslim, ze tema je dost velike, pro mne osobne velmi dulezite. Kdyz tak to proberem na OpenCoffee ;)

Jeste 1 perlicka, kterou jsem cetl nekde na blogu SItePoint: "propusteni spatneho klienta" ma 2 vyhody:
1. Mas min starosti a muzes se venovat efektivnejsi praci
2. Ten klient pujde otravovat konkurenci

[10] Tak se vším uvedeným souhlasím. (Ono je to tak, že když jdeš dlouhodobě první naznačenou možností, tak máš možná práci, ale moc tě nebaví, děláš to co chtějí klienti a jak to chtějí klienti - což tvojí firmu i tvé nabízené řešení často posouvá směrem, kde ho chtějí mít klienti a ne směrem, kde bys ho jednou rád viděl ty).

Ale stejně dobře zvládnout variantu 2 je taky umění :) Stejně ti často ten klient do finálního grafického vzhledu mluví, a žádná argumentace nepomůže. Stejně má občas problémy pochopit, že když v průběhu projektů rozšíří zadání, tak to bude stát víc nebo trvat déle. Atp.