Onlangs was er op Frankwatching een artikel te lezen met de titel “Behandel digitale producten niet als eenmalige projecten“. Hoewel er in het artikel niet specifiek wordt gesproken over de projectmanagement methodieken en de wijze van beheer, is het interessant die relatie wel te leggen. In dit artikel dan ook een andere blik op dezelfde argumenten uit het artikel.
Frankwatching noemt de volgende 5 punten in het artikel:
- Digitale producten zijn nooit af
- Een digitaal project staat zelden alleen
- Een eenmalig project heeft een lage adoptiegraad binnen de operatie
- Aandachtspunten voor een continue benadering
- Continue doorontwikkeling
Omgaan met veranderingen
De wereld staat niet stil en de eisen en wensen aan een product zullen dan ook geregeld veranderen. Dit kan zijn omdat de consument (waarvoor uiteindelijke waarde moet worden gecreëerd) anders tegen de producten en diensten aan is gaan kijken, of bijvoorbeeld omdat er nieuwe technologieën beschikbaar komen die een andere weg mogelijk maken. Bij een traditioneel waterval project kan dit een probleem zijn, omdat hierbij minder goed met deze veranderingen kan worden omgegaan. Bij Agile projecten wordt ruimte gemaakt om deze veranderingen wel op te kunnen vangen, door het producten stukje bij beetje uit te breiden met de belangrijkste zaken op dat moment.
De kans dat een product niet helemaal af is, is bij waterval methodes dus meestal het gat wat inmiddels is ontstaan tussen de oorspronkelijke ideeën en de werkelijkheid van nu. Bij Agile projecten is de kans op het niet gereed zijn simpelweg een prioriteitskwestie en hoeveel geld het product mag/mocht kosten. Overigens sluit dit aan bij de gedachte van DevOps: alles is beheer, het product is nooit klaar, dus laten we in plaats van een project te definiëren, accepteren dat we continu doorwerken aan het product, met gezamenlijke effort tussen Beheer en Ontwikkeling, als ware het een lijntaak.
Relaties en afhankelijkheden
Een ander lastig aspect is dat projecten en producten in de meeste gevallen niet op zichzelf staan. Zelfs de meeste hippe start-ups leveren apps die niet los zijn te denken van een inlegmogelijkheid met je Facebook of LinkedIn account bijvoorbeeld. Als die partijen besluiten hun koppeling aan te passen, ben je hier direct ook “slachtoffer” van. Er is dus sprake van een grote hoeveelheid relaties en afhankelijkheden aanwezig. In die zin kun je er dus alleen maar rekening mee houden dát zaken gaan veranderen en dat er dus onvermijdelijk iets aan het product moet worden aangepast.
Je kunt een project niet eindeloos in de lucht houden. Dat gaat sowieso in tegen de definitie van project. Het is dus van belang om tijdens de ontwikkel- en bouwfase zoveel mogelijk rekening te houden met eventuele aanstaande wijzigingen, die je al dan niet al verwerkt in je product. Maar zodra het in beheer is, blijf je hier dus mee worden geconfronteerd. Met een DevOps aanpak kun je hier efficient mee omgaan. Met een traditioneel projectmodel wordt dat al lastiger: voordat het projectplan is geschreven en het budget er is, ben je al zo weer een maand of twee verder.
Cultuur en gewoonte
Tot slot is er nog een stukje menselijkheid te benoemen. Het lastige is namelijk dat als opdrachtgevers projecten starten om een product te lanceren, zij vooral kijken naar de kosten van die eerst release, tot in beheername. Het feit dat het product dan nog niet klaar is en er continu sleutelwerk nodig is, zit nog niet bij elke opdrachtgever goed tussen de oren. Overigens zien we dat niet alleen bij ontwikkelde software, maar ook bij producten uit “de doos”: ook daar dienen kosten te worden gemaakt voor updates, upgrades, onderhoud, enzovoorts. Met dezelfde reden: het product is nog niet “af”.
Bovendien is het eenmalig doen van een project een kortdurend (hopelijk) feestje. Het team is tijdelijk gemotiveerd (hopelijk) en er wordt in korte tijd wat moois neergezet. Maar als het klaar is, gaat de glans ervan af: mensen (en zeker IT-ers) vinden het namelijk leuker om zaken te bouwen en op te zetten, dan om deze te blijven beheren tot in het einde der tijden. Ook hierbij kan DevOps helpen, omdat de scheidslijn van ontwikkeling en beheer hierbij vervaagd en het team continu blijft doorwerken aan het product en zorgt dat het product zich tot een parel blijft doorontwikkelen.
Dus, wat nu?
Het belangrijkste om te beseffen is dat als je digitale producten ontwikkeld, je bij voorbaat al rekening moet houden met het feit dat gedurende de hele lifecycle van het product aanpassingen nodig zijn. Er blijft onderhoud nodig, doorontwikkeling en finetuning. Die aanpassingen kunnen in de waterval methode worden gebouwd, maar Agile biedt hierin meer flexibiliteit om actuelere issues te kunnen adresseren. Wil je geen apart projectteam, maar het als lijnactiviteit aanvliegen, dan is DevOps wellicht de keus voor jou.
[bol_search_form limit=”6″ block_id=”bol_55670e6bc3bbb_search-form” cat_id=”8299″ cat_select=”0″ default_search=”devops” name=”DevOps” sub_id=”” link_color=”003399″ subtitle_color=”000000″ pricetype_color=”000000″ price_color=”CC3300″ deliverytime_color=”009900″ background_color=”FFFFFF” border_color=”D2D2D2″ width=”580″ cols=”3″ show_bol_logo=”1″ show_price=”1″ show_rating=”1″ show_deliverytime=”1″ link_target=”1″ image_size=”1″ admin_preview=”1″]
