HTML

Magunkról

The blog of the Budapest based Digital Natives covers the topics such as technological challenges we meet in our work, also our solutions and developments related mostly to Ruby on Rails and e. g. JavaScript. You can read about project management methodologies, which drive our workflow, such as agile or scrum. We don’t forget to report about our work and free-time related events and activities.

Facebook

Címkék

2011 (1) 2012 (4) 2013 (5) 2014 (2) agency (1) agile (1) agilis (13) android (1) angel (2) anita (2) API (1) árazás (2) artisjus (1) balaton (1) bécs (1) becs (1) becslés (1) befektető (7) befekteto (1) bemutatkozás (1) berlin (1) beszédfelismerés (2) beszédtechnológia (1) bitbucket (1) blog (1) borkóstoló (1) budapest.rb (1) célok (1) client (4) cloud (1) code hulk (1) coding (1) coin (1) concept (2) conference (1) continuous integration (1) cross browser (1) cross platform (2) csapat (4) csapatépítés (1) csocsó (1) David (1) ddb (1) deployment (3) design (2) dev (5) dev meeting (2) digital (1) diktálás (1) dojo (1) ebook (1) education (1) elemzés (3) elmélet (1) English (1) english (9) értékelés (1) értékesítés (3) extreme programming (1) fejlesztő (3) feliratozás (1) Friday (1) frontend (2) game (3) game of thrones (1) gerzson (2) hackfwd (2) heroku (1) hirdetés (1) hosting (1) icatapult (2) idcee (4) idea (1) implementation (2) inkubáció (9) ios (1) javascript (1) jenkins (1) jogdíj (1) jruby (1) kaizen (1) kalandpark (1) kanban (3) képzés (2) kijev (1) kipuedu (1) kirándulás (1) kocákzati tőkealap (1) kommunikáció (1) lean (2) LinkedIn (1) Logidok (1) mahasz (1) marketing (1) meetup (9) mindroom (2) Mitnick (1) mixgar (14) mobil (4) moving (1) mvp (2) MVP (1) nabaztag (1) natives (1) olasz (1) open source (1) people search (1) piknik (1) planning (1) playertise (3) prága (1) presentation (1) product owner (1) product roadmap (1) project (1) prototípus (1) prototype (1) rabbit (1) rails (15) ruby (14) rupy (1) scrum (9) search API (1) series (2) sharewood (1) siker (2) social (1) sorozat (1) spaceship (1) speedinvest (1) startup (6) startup week (1) String (1) szerződés (1) szolgáltatás (2) taxi (3) taxitrust (3) taxtrust (1) techshow (2) testing (2) teszt (1) titanium (1) toborzás (2) tőke (2) toptal (1) trónok harca (1) tumblr (1) ügyfél (1) UI (1) UML (1) UX (2) üzletiangyal (1) vagrant (1) varga anita (1) verseny (2) videó (1) videóarchívum (1) vienna (1) világhírnév (8) virtualbox (1) vm (1) vodka (1) web (8) wired (2) workflow (2) xp (3) XP (1) Címkefelhő

A posztban összefoglalom, hogy milyen hatásai vannak az értékesítési folyamatra, ha egy webes projektet agilis módszertan szerint szeretnénk megvalósítani. A módszertan nyújtotta előnyökről - hátrányokról és az értékesítési folyamat mérföldköveiről lesz szó, illetve arról, hogy ezek hogyan változnak meg és miért. Ha nem ismered, vagy csak szeretnéd gyorsan átfutni, hogy mit is jelent az agilis fejlesztés és azon belül a Scrum, akkor ezt a magyar Wikipédia oldalon, vagy a Scrum Alliance oldalán teheted meg.

Érdekes megfigyelni, hogy egy webes fejlesztési projekt megrendelésekor az ár - határidő páros mellett milyen szempontok szerint hoznak döntést a megrendelők. Rengeteg szempont szóba jöhet kezdve a fejlesztő csapat hozzáállásától a cég méretéig, vagy a megvalósítás során alkalmazott technológiákig.Ritkán szokott szóba kerülni a megvalósítás módszertana, pedig ha kilépünk abból a kliséből, hogy a projekteket waterfall (hagyományos) módszer szerint kell és lehet megvalósítani, akkor rengeteg új lehetőség nyílik meg a megvalósításban, így az értékesítésben is.

 

1. A módszertan eladása

Magyarországon a nagy fejlesztő cégeket leszámítva egyelőre kevesen ismernek és még kevesebben alkalmaznak agilis módszertant a fejlesztések során, ezért elsőként magát a módszertant kell eladni (a fejezet végén felsoroltam néhány pozitívumot, ami általában mindenkinek felkelti az érdeklődését).

Tapasztalatok szerint néhány mélyreható beszélgetés szükséges hozzá, hogy egy olyasvalaki is  átlássa az agilis fejlesztés és a “megszokott” fejlesztés közötti főbb különbségeket, aki korábban nem foglalkozott a területtel. Erre azonban általában nincs lehetőségünk, néhány percben kell felkelteni annyira az érdeklődést, hogy agilis irányba tudjunk tovább haladni és a megfelelő kulcsgondolatokat, előnyöket elültessük a megrendelő fülében (lásd szintén a fejezet végén). Megint csak nem mindegy, hogy kivel beszélünk: technikai, pénzügyi vagy marketing döntéshozóval, hiszen a lenti érvek közül nem mindegyik lesz ugyanolyan fontos a különböző területekért felelős menedzsereknek.

Érvek az agilis módszertan mellett:

  • Rugalmas scope: Nem várja el a módszertan, hogy a legelején ismerjük a részleteit a projektnek, azt viszont igen, hogy az alap funkcionalitás egyértelmű legyen.
  • Közvetlen irányítás a projektben: A megrendelők nem csak a tervezés és a tesztelés során találkoznak a fejlesztőkkel és a termékkel. A napi megbeszéléseken részt vehetnek, így egy-egy félreértés alkalmával akár azonnal korrigálhatnak, az iterációk átadása során pedig 2-4 hetente tesztelhetik az új funkciókat.
  • Pontos határidők: az iterációk fix ideig tartanak, így nem lehet csúszni velük. Egyes esetekben egy-egy funkció nem készül el teljesen, de mivel prioritások szerint haladunk, a legfontosabbak mindig határidőre elkészülnek és csak az apróságokban lehet csúszás.
  • Pontos becslések: Az iteratív fejlesztésnek köszönhetően rövid időszakokat kell csak megbecsülni. Általában az első iterációban pontatlanabb a becslés, a későbbiekben azonban ez nagy mértékben javul, a második-harmadik iterációtól tapasztalataink szerint 10% alatti tévedési pontosság is elérhető.
  • Dinamikus változás kezelés: Az iteratív fejlesztésnek köszönhetően folyamatosan tesztelhetők az elkészült funkciók, az újabb ötletek, módosítások pedig folyamatosan beépítetők. Az élesítéssel sem kell megvárni a teljes projekt végét, akár már az első iteráció után publikálhatók a kész funkciók.
  • Iteráció teljesítésenként fizetés: teljesített iterációnként kell fizetni, így a költségeket jobban lehet szabályozni és bármikor fel lehet mondani a projektet.

 

2. Scope pontosítása és “Scrumosítása”

Miután egy első beszélgetés és egy esetleges specifikáció alapján nagyjából tisztázódott a scope, elkezdjük közösen sorra venni a követelményeket, úgynevezett User storykat gyártunk a scope-ból, például: “Én mint felhasználó fel tudjak iratkozni hírlevélre, hogy értesüljek az újdonságokról”. 

A következő lépésben ezekhez a storykhoz prioritásokat rendelünk, ami meghatározza a megvalósításuk sorrendjét. Ez eleinte nehézkes, mivel a megrendelőnek  gyakran minden közel egyformán fontos a projektben (holott a kifejlesztett funkciók egy jelentős részét a felhasználók nem is használják, vagy üzleti szempontból kevésbé fontosak...). 

A rutinos megrendelő (és fejlesztő) a scope pontosítása során megpróbál mindenre előre gondolni: “Ugye ez a funkció illeszthető lesz majd ehhez? Ez hol helyezkedik majd el a felületen?” stb., ez alapvetően egy nagyon jó hozzáállás, csak éppen lehetetlen mindenre előre gondolni, főleg ha az adott funkció csak a 2. vagy 3. iterációban kerül kifejlesztésre, addig pedig rengeteg minden történhet a projekttel.

Ezekere a felvetésekre ezt szoktuk válaszolni: “Ezen nem kell most ilyen részletesen gondolkozni. Tudjuk, hogy lesz egy ilyen feladat, nagyjából ismerjük a követelményeket, de részletesen ráérünk majd akkor megtervezni a működést és designt, amikor megtervezzük az adott iterációt - Lehet, hogy addigra (2-3 hónap múlva) ti is máshogy látjátok majd optimálisnak a működését”

Ki ne szeretne ilyet hallani, hogy nem kell előre mindent kitalálni? A legjobb benne az, hogy ráadásul még igaz is: felesleges részletesen megtervezni valamit, aminek az alapjait nem ismerjük 100%-osan, hiszen a változáskezelés költségeinek pontosan az ilyen információhiányos tervezés adja ki a jelentős részét. 

Általában ennek a szabadságnak a felismerése ad egy lökést a megrendelőnek (product owner) és elkezd ráérezni a tervezés ízére: iterációkba (sprintekre) darabolja a projektet és a User storykat (funkciókat) üzleti értékük szerint priorizálja be.

 

3. Árazás és ajánlatadás

A hagyományos projektekben általában a funkciókat szoktuk beárazni. Az agilis módszertanokban azonban többnyire erőforrás-ráfordítás alapján árazunk, azaz fejlesztési iterációkat adunk el és a megrendelő dönti el, hogy egy iterációban mit és milyen sorrendben kell lefejleszteni. Ez azt jelenti, hogy az idő, a költség és a minőség adott, mivel az iterációk fix ideig tartanak, fix létszámmal, a minőségen pedig feltehetően senki nem akar rontani... 

Tehát egyedül a scope-ot tudjuk rugalmasan kezelni: a legnagyobb kihívást az jelenti, hogy elfogadjuk/elfogadtassuk: üzletileg értékesebb 7 jól működő funkciót lefejleszteni, mint 10 közepesen jót.

Ez természetesen nem jelenti azt, hogy vaktában elkezdünk fejleszteni és majd meglátjuk hány iterációban valósítjuk meg a scope-ot: az igények felmérése után felmérhető a munka nagyságrendje, azaz hogy hány ember hány iterációban tudja megvalósítani a leírtakat, az egyes iterációkban pedig mindig lehetőség nyílik az újra priorizálásra, hogy a büdzséből a legértékesebb funkciókat valósítsuk meg.

A módszertanból következik, hogy nem lehet az óraszámokkal és az óradíjjal játszani: teljes mértékben transzparens árazási struktúra szerint adunk ajánlatot, hiszen a megrendelőnek mindig világos, hogy hány ember és mennyi ideig dolgozik majd a projekten.

 

4. Szerződéskötés

Gyakran felmerül a kérdés, hogy hogyan lehet szerződni egy olyan fejlesztési munkára, aminek nem definiált a pontos scope-ja, csak a határideje és a büdzséje.

Mi ezt úgy szoktuk megoldani, hogy a projekt indításakor egy keretszerződést kötünk, amiben általánosan összefoglaljuk a Megrendelő és Vállalkozó (Szolgáltató) kötelezettségeit. E mellett minden egyes iteráció indításkor egy egyedi szerződésben határozzuk meg, hogy az adott időszakban hány fejlesztő, milyen feladatokat lát el és pontosan milyen funkcionalitást fog kifejleszteni. Tehát a scope mindig definiálásra kerül, de pontosan csak a sprint indításakor határozzuk meg ezeket.

 

Összefoglalás

Értékesítés szempontjából a legfontosabb érték az, hogy a megrendelőt az ajánlatadás során mélyen bevonjuk a projektbe: a saját elképzelései szerint priorizálhat, ütemezheti a feladatokat, így érzelmileg is kötődni fog hozzá. (tudjuk, hogy gyakran a fejlesztő cég diktál, az ügyfél pedig követ - ez látszólag kényelmes, mivel a megrendelőnek nem kell sokat gondolkoznia és a fejlesztők is a számukra kényelmes mederben tarthatják a fejlesztéseket, de utólag ebből mindig problémák adódnak). 

A Scrum természetesen nem elegendő egy projekt megnyeréséhez, de sok esetben kínál olyan alternatívát, ami illeszkedik a megrendelő igényeihez. Ilyen eset például a szolgáltatások fejlesztése, ahol a körülmények és igények folyamatosan változnak. Különösen igaz ez az indulást követő időszakra, amikor az alapötletek helyességéről visszajelzéseket szerzünk: a Scrum segít, hogy alacsony költség mellett rövid idő alatt indítsuk majd be a szolgáltatást és a lényeges pontokra fókuszáljunk.

Ez a poszt természetesen nyitva hagy még rengeteg kérdést, legközelebb az árazási konstrukciókról és a becslési technikákról fogok írni.

Ha szeretnél találkozni és megvitatni agilis kérdéseket, vagy csak tájékozódnál a témában, látogass el a Budapes Agile Meetup Group oldalára és eseményeire.

A témában még érdekes bejegyzéseket ugyanezen az oldalon itt olvashatsz: http://www.meetup.com/AgileHungary/messages/boards/thread/9713039

 

Címkék: web szerződés értékesítés árazás becslés scrum agilis

5 komment

A bejegyzés trackback címe:

https://digitalnatives.blog.hu/api/trackback/id/tr652405042

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

akocsis · http://akocsis.blog.hu 2010.11.18. 12:22:32

Érdekes felvetés, de szerintem félrement a cikk.
Az ügyfelet az érdekli, hogy határidőre az adott áron elkészüljön amit kért. Nem érdekli a módszertan, és éppen ezért azt nem is kell neki eladni.

Viszont ha valaki agilisan akar fejleszteni és így akar ajánlatot adni, szerződni, akkor előbb azzal legyen tisztában, hogy az ügyfél oldalán milyen kötöttségek vannak.

Például nem azért gondolkodik a megrendelő ár-határidő kettősben, mert imádja a vízesés modellt, hanem mert:
- Neki fix határidőkkel kell dolgoznia
- A munkára szánt pénzmennyiség adott

Szívesen látnám az agilis szerződéskötésre javasolt keretszerződést. Az ASZE oldalán lévő szerződésmintát már láttam, és azon még van mit dolgozni.

kristof.bardos 2010.11.18. 13:00:11

@akocsis: Szerintem nem ennyire egyértelmű, hogy fix határidőre mit kell szállítani. Egyrészt ki mondta meg a határidőt és mire akarja használni a szoftvert?

Vannak olyan helyzetek, amikor ez persze adottság, de azért nem kezelném ezt ilyen általánosan.

Szerintem elsősorban azért látjuk másként ezt a kérdést, mert máshonnan jövünk, mások a tapasztalataink.

A mi projektjeink esetében (webes szolgáltatások fejlesztése) a megrendelők általában nem tudják pontosan specifikálni az igényeiket, egyrészt mert rengeteg ismeretlen tényező van a projektben (nulláról fejlesztünk valamit), másrészt nem technikai emberekről van szó.

A határidők sem olyanok, hogy valaminek időre el kell készülnie, különben 10 másik fejlesztés áll. Inkább az a cél, hogy a minimálisan működő verzió minél előbb élesbe menjen és termeljen.

Szerintem fontos, hogy érdekelje a módszertan az ügyfelet, hiszen az, hogy agilisan fejlesztünk sok mindent meghatároz, teljesen más szemléletmódot kíván meg az ő részéről is. Gondolok itt arra, hogy pl. ha Scrumban fejlesztünk, akkor neki is több lehetősége nyílik pl. az üzleti oldalon Lean módszertan alkalmazására.

Ahol erre nincs igény, ott nem feltétlenül kell egyébként agilisan fejleszteni.

akocsis · http://akocsis.blog.hu 2010.11.18. 16:24:47

@kristof.bardos: A határidő fakadhat olyan apróságokból, hogy a megrendelő főnöke határidőre akar eredményeket látni.

Azért általánosítok - és igen, vannak kivételek - mert annál a cégméretnél, ahol a Lean szempont és megfizetik a Lean szakértőt (ha már erre történt hivatkozás), ott feltehetőleg nem kkv-ről beszélünk. Annál a cégméretnél már a nagyvállalati működés sajátosságai befolyásolják a projektet.
Mint például az, hogy minden feladatnak van határideje, a feladatokat előre tervezik, a költségeket előre tervezik, stb stb

Kis cégnél valóban el tudom képzelni, hogy kész lesz amikor kész lesz, és teljesen más lesz az együttműködés képe.

A körülmények nagyon fontosak, "there is no silver bullett".

kristof.bardos 2010.11.19. 14:17:48

@akocsis:
Szerintem a Leant nem szabad azonosítani a nagyvállalatokkal. Akinek van ideje utána olvasni és érdekli a téma, az kiválóan alkalmazhatja a Lean szemléletet a saját cégében, mérettől függetlenül.

A határidő a kisebb cégeknél sem úgy néz ki, hogy kész lesz amikor kész lesz. A valóságban egy olyan cégnél, ahol egy vagy két szolgáltatást futtatnak létkérdés, hogy minél előbb megtalálják azt a formát, amiben sikeres lesz a vállalkozásuk - tehát a határidő a legfontosabb. Ebben segít a Scrum szerintem: már egy korai verzió élesíthető a szolgáltatásból és lehet a tapasztalatokból építkezni, hogy a 2. 3. release már valami sokkal jobb dolog legyen.
Ezért írtam, hogy a Scrum "megkövetel" egy ilyen jellegű szolgáltatás-termék fejlesztési szemléletet az ügyfél oldalról is és ezért fontos, hogy megértsék és elfogadják a módszertant, mert a cég teljes életére kihatással lehet.

akocsis · http://akocsis.blog.hu 2010.11.19. 16:44:57

Akkor ha jól értem kis cégekkel van tapasztalatod?
Ott valóban fontos lehet az ilyenfajta "értékesítés", azaz a tulajdonos-vezérigazgató meggyőzése a módszertanról.
És ott tényleg igazad van a határidőkkel kapcsolatban.

Viszont én is azt mondom, hogy ne általánosíts, mert a kis cégekre bevált felállás nem biztos, hogy nagyobb cégeknél is jó lesz.