SYNTACTIC SUGAR Různé styly vedení projektu, vliv přístupu zákazníka na průběh projektu Tomáš Holub, ,

Osnova Představení společnosti Syntactic Sugar Jakým způsobem probíhá vývoj software v naší společnosti Předpoklady pro úspěch softwarového projektu Možné problémy Projekt první – úspěšnější Projekt druhý - méně úspěšný Jak si „vybrat zákazníka“ Doporučení pro spolupráci se zákazníkem Co s problematickým zákazníkem? Shrnutí

Představení společnosti Syntactic Sugar Syntactic Sugar nabízí zakázkový vývoj software, příp. bodyshopping Velikost firmy: 4 stálí zaměstnanci + 14 externistů, často studentů Technologická firma, slušná firma Následující přednášku je nutno chápat v kontextu naší společnosti (tj. velikost firmy, styl práce, typ projektů apod.)

Jakým způsobem probíhá vývoj software v naší společnosti Typické kroky: Oslovení zákazníkem Stručná analýza Vytvoření nabídky Výběrové řízení Akceptace nabídky Podrobná analýza – výstupem je SRD a SDD (Software Requirements Document a Software Design Document)

Jakým způsobem probíhá vývoj software v naší společnosti Typické kroky – pokračování: Fáze implementace: postupné iterace zapojení zákazníka průběžné schvalování Testování (splnění požadavků, funkčnosti, zátěžové testy...) Akceptace zákazníkem Zhodnocení projektu

Předpoklady pro úspěch softwarového projektu Dobře definovaný cíl projektu Realistický plán, jak cíle dosáhneme Dostatek kvalitních lidí Ale i: Zkušenosti s podobnými projekty, vyzkoušený styl práce Spolupráce se zákazníkem při řešení problémů

Možné problémy Problémy se vyskytnou vždy! Ve fázi analýzy nelze vše dostatečně přesně specifikovat Požadavky zákazníka se během vývoje (z)mění: Mění se trh Zákazník si některé věci uvědomí až postupně Technické, resp. technologické problémy: Některé věci nefungují dle očekávání Problémy s výkonem Testování uživateli odhalí logické problémy, příp. vzniknou náměty na zlepšení

Přístup k řešení problémů je kritický pro úspěch projektu.

Co ovlivňuje řešení problémů: Rychlost komunikace Kvalita komunikace, porozumění Používání doporučených a standardizovaných postupů - ze strany zákazníka i naší Zájem zúčastněných – opět na obou stranách

Zkušenosti ze dvou projektů Obecná charakteristika projektů: Počet členů týmu: cca 5 (během projektu se mění) Role v týmu (komunikace se zákazníkem, řízení projektu, programování, testování) Délka trvání projektu: více měsíců Typ zákazníka: menší společnost (nemusíme řešit problémy typu „jednáme jen s malým manažerem, vedení toho o projektu moc neví“)

Zkušenosti ze dvou projektů Každý projekt je jiný: Vzniká v jiné době (technologie, firemní kultura) Řeší jiné potřeby zákazníka Je třeba se do určité míry přizpůsobit stylu práce zákazníka Upozornění: Prezentujeme zde i naše neúspěchy, což není moc obvyklé

Projekt první - úspěšnější Pozitiva a úspěchy: Ze strany zákazníka vyčleněn zodpovědný člověk, který se projektu plně věnoval (až 100 hodin týdně!) Zodpovědný člověk rozuměl softwarové problematice Velmi rychlé řešení všech problémů Velký důraz na analýzu řešení a pečlivé sepsání všech dokumentů

Projekt první - úspěšnější Pozitiva a úspěchy: Pečlivé dokumentování všech kroků a dohod Z hlediska implementace: zvoleno hodně obecné řešení, které nebylo třeba během vývoje zásadně měnit

Projekt první - úspěšnější Negativa a problémy: Při analýze se nepodařilo vyhnout narůstání požadavků („velké oči“) - náročnost projektu vzrostla téměř čtyřikrát! Při narůstání požadavků nebyly dostatečně navýšeny časové odhady (přístup „to nějak zvládneme“ lze aplikovat jen do určité míry, pak ztrácíme možnost řešit nepředvídané situace atd.)

Projekt první - úspěšnější Negativa a problémy: Enormní nároky na vývojářský tým (práce non-stop) Z hlediska implementace: hodně obecné řešení bylo pracnější Psychicky náročné (nelze nic „ukecat“)

Projekt první - úspěšnější Výsledek projektu: Zákazník software úspěšně prodal/dodal svým zákazníkům v rámci větší zakázky Projekt byl sice opožděn, ale neovlivnilo to jeho obchodní úspěch (díky včasné komunikaci se mohl zákazník připravit)

Projekt druhý - méně úspěšný Pozitiva a úspěchy: Dokumentace vývoje - umožnila předávat práci mezi členy týmu a pokračovat v projektu po dlouhých obdobích nečinnosti Velký počet odpracovaných hodin Snaha o vytvoření prostředí důvěry ze strany zákazníka

Projekt druhý - méně úspěšný Negativa a problémy: Ze strany zákazníka komunikace pouze s členem vedení, který často nemá čas a cokoliv získat je problém (typická odpověď na s jednoduchou otázkou je, že odpověď pošle zítra, ale reálně ji dostaneme až po několika urgencích zhruba po týdnu) Výsledkem je, že problémy se řeší buď pomalu nebo se je snažíme řešit sami (ale bohužel ne vždy podle představ zákazníka)

Projekt druhý - méně úspěšný Negativa a problémy: Ze strany zákazníka nezkušenost a neznalost software a jeho vývoje - i jednoduché problémy je třeba podrobně vysvětlovat Výsledkem není jen pomalejší komunikace, ale i několik chybných zásadních rozhodnutí - zákazník se rozhoduje obecně („databáze musí být bezpečná“), protože nedokáže posoudit dopady svých rozhodnutí (pokud se to s bezpečností přežene, tak je vše dražší a složité na používání)

Projekt druhý - méně úspěšný Negativa a problémy: Neschopnost určit priority (vše je priorita 1A) Přehnaný důraz na detaily (např. dostaneme přesnou specifikaci všech barev, každý náš krok a postup je pečlivě kontrolován a často „vylepšován“) Během vývoje proběhlo několik zásadních změn v zadání, které vždy vrátily projekt o podstatný kus dozadu

Projekt druhý - méně úspěšný Výsledek projektu: Projekt průběžně odkládán a opětovně oživován již několik let Některé části kódu obsahují historii několika změn. Vždy jsou ale změny dělané narychlo - tj. vzniká špatně udržovatelný kód. Zklamání všech stran (zákazník nemá produkt, my nemáme referenci)

Jak si „vybrat zákazníka“ Předem lze jen obtížně odhadnout zákazníka a možné problémy Zákazníka si lze vybrat jen v ideálním světě… tj. jediné možné řešení je využít naše zkušenosti, schopnosti a možnosti jak zlepšit komunikaci se zákazníkem a průběh projektu

Doporučení pro spolupráci se zákazníkem Vysvětlit zákazníkovi důležitost jeho zapojení, smluvně ho k tomu zavázat Požadovat "kontaktní osobu" nejlépe s technickými znalostmi (tvoří most mezi námi a vedením) Nepodcenit analýzu, výstupy analýzy do dokumentu (nebo ještě lépe do několika dokumentů), který musí být oběma stranami odsouhlasen

Doporučení pro spolupráci se zákazníkem Umožnit zákazníkovi co nejlepší přehled o projektu, tj. dát mu přístup do interních systémů - čím dříve odhalí problém, tím jednodušeji se bude opravovat Mít neustále přehled o stavu projektu - týdenní meetingy, přehled úkolů rozdělených do verzí

Doporučení pro spolupráci se zákazníkem Řešit problémy společně Problém většinou znamená prodloužení a zdražení projektu Možností je i úprava funkcionality (problematická část může být nahrazena jinou neproblematickou částí, která bude stejně dobře řešit zákazníkovy potřeby) Další možností je omezení funkcionality (trojúhelník: zdroje, čas, kvalita) Jednotlivé problémy lze řešit, ale kombinace několika problémů může být pro projekt zničující

Co s problematickým zákazníkem? Funkce „poradce“ z našeho týmu, který bude zákazníkovi vysvětlovat technické problémy Prototypy („co neuvidím, to si neumím představit“... platí to i naopak) Vše důsledně dokumentovat (požadavky, zápisy z jednání, zápisy z telefonátů)

Co s problematickým zákazníkem? Snažit se přiblížit stylu jeho práce (telefon vs. vs. IM) Občas může být přínosné umožnit zákazníkovi přímo komunikovat s konkrétním programátorem, aby se rychleji vyřešila dílčí část (záleží na soft skills programátora)

Shrnutí Vývoj softwaru není jen o technologiích, ale i o komunikaci se zákazníkem a způsobu vedení projektu Úspěch projektu často závisí na schopnosti řešit problémy Každý projekt je přes veškerou snahu odlišný Mnoho zkušeností je nepřenosných, stejně tak hodně jich je ale obecných

Otázky? Děkuji za pozornost …hledáme nové kolegy na úspěšné projekty ;-)…