eBusiness Consultant en Product Owner

by Jeroen van Eck on 12 February, 2009

Als eBusiness Consultant heb ik binnen onze organisatie een proactieve en een reactieve functie naar de klanten die ik bedien. We doen projecten en voeren wijzigingsverzoeken door in bestaande websites. Ik geef advies en help bij het nemen van bepaalde beslissingen op basis van klantwaarde en rendement. Als eBusiness Consultant ben ik de schakel tussen de klant en de techniek.

In onze projectorganisatie passen we SCRUM toe bij het uitvoeren van projecten. SCRUM is een agile ontwikkelmethode waarbij in korte cycli werkende software wordt opgeleverd. Dit betreft nog niet het complete eindproduct, maar de functionaliteit die af is zou in productie kunnen worden genomen. Het voordeel van SCRUM is dat het de effectiviteit van het team vergroot, beter inzicht in de voortgang geeft, en risico’s en problemen eerder opgelost kunnen worden. Hiernaast blijven we door deze methode tijdens het project pragmatisch en flexibel. Het is dus mogelijk om bepaalde wensen en eisen toe te voegen aan de lijst van requirements. Dit kan impact hebben op overige functies, die hierdoor zouden kunnen komen te vervallen.


Ik heb binnen deze methode de rol van Product Owner. De Product Owner (PO) is de proxy van de klant en stelt een vision statement op. Aan de hand van dit vision statement is voor iedereen duidelijk wat de doelstelling van het project is. De PO bepaalt de prioriteit van bepaalde functionaliteit en beslist in welke cyclus een specifieke functie opgenomen wordt. Hiernaast is de Product Owner de gatekeeper van de kwaliteit: hij bepaalt of dat ingebouwde functies voldoen of niet en accepteert dus de opleveringen.

De prioriteit wordt bepaald door de volgende criteria:

- De functie is belangrijk voor een grote groep gebruikers;
- De functie is belangrijk voor een kleine groep belangrijke gebruikers (stakeholders);
- De relatie tussen bepaalde functies; en
- De impact op het budget van functies.

Samen met het team wordt besloten hoe complex functionaliteit wordt uitgewerkt. De mogelijkheid om contact op te nemen kan bijvoorbeeld door een eenvoudige mailto-link worden gerealiseerd, maar ook door de implementatie van een webformulier waarbij de output opgeslagen wordt in een extern CRM-systeem.

De voortgang wordt bewaakt door dagelijkse korte bijeenkomsten, en aan het einde van een cyclus wordt de geïmplementeerde functionaliteit in een demo door het team aan de stakeholders getoond. Het team is continu bezig het proces te optimaliseren en draagt zelf de verantwoordelijk van gebruikte techniek.

Uit tussentijdse resultaten blijkt dat de kwaliteit van de software toeneemt en het eindproduct beter aansluit bij de wensen en eisen van de klant. Er zijn echter nog een aantal zaken die binnen onze organisatie verbetert dienen te worden: Onze projecten worden vooralsnog tegen een vaste prijs verkocht. De klant verwacht dan ook een vaste set aan functies. In principe zouden dergelijke projecten als timebox moeten worden verkocht. Dit vereist een hoge mate van vertrouwen aangezien de klant een budget ter beschikking stelt en dit budget in principe naar eigen inzicht verbruikt kan worden.
Onze teams (11 momenteel) werken tegelijkertijd aan meerdere projecten. Hierdoor zijn resources beperkt beschikbaar en is het opstellen van een planning een complexe taak. 7 Van onze teams bevinden zich op een andere locatie, wat het lastig maakt om voortgang te blijven meten (ondanks het gebruik van videoconferencing).

Momenteel bevinden wij ons nog in een lerende fase en “spelen” we met het toepassen van specifieke technieken en methoden. We weten dat we de SCRUM methode niet volledig kunnen toepassen, echter is iedereen ervan overtuigd dat het een positieve invloed op het resultaat heeft. In de toekomst zal ik hier specifieker ingaan op de verschillende taken, verantwoordelijkheden en functies binnen dit proces.

{ 4 comments… read them below or add one }

Perry 13 February, 2009 at 01:45

Jeroen,
Net verhaal wederom al deed de titel mij vermoeden dat het zou gaan over de verschillen tussen de rollen ‘eBusiness Consultant’ en ‘Product Owner’. Dat komt niet helemaal uit de verf vind ik.

Verder vind ik het een goed verhaal en met jouw goedkeuring stuur ik het ook aan onze recruiter omdat het prima te gebruiken is om extern uit te leggen wat wij doen.

Thumbs Up!

Jeroen 13 February, 2009 at 02:42

Bedankt voor je terugkoppeling. De post eBusiness Consultant vs Product Owner zit nog in de pipeline. Die komt dus zeker.

Brasiano 16 March, 2009 at 06:21

Een ander interresante mogelijkheid naast fixed price en time box, is de klant te factureren per opgeleverde functionaliteit.

Dit heeft uiteraard zijn voor- en nadelen.

Jeroen 16 March, 2009 at 16:49

@Brasiano het lastige van een dergelijke constructie is dat het nogal wat vertrouwen vereist van de klant. Hiernaast zul je de realisatie van elke functionaliteit ook als apart project moeten beschouwen waarbij dezelfde uitdagingen van toepassing zijn. Maar zoals je zelf al stelt heeft dit z’n voor- en nadelen, wat voor elke constructie geldt.

Leave a Comment

Previous post:

Next post: