Situace
Situation
Všechny obchodní procesy jedou na cca 50 aplikacích, které jsou navzájem výrazně propojeny. Čtyřikrát do roka je třeba připravit nový tarif spojený s novou kampaní. Do toho probíhají ale větší transformace, které nahrazují staré aplikace novými. Aby toho nebylo málo, tak se ještě implementují úplně nové produkty na nových systémech s novými propojeními na partnerské aplikace.
All business processes run on about 50 applications that are heavily integrated. Four times per year a new tarif is prepared together with a new campaign. In parallel there are bigger transformation initiatives replaceing old applications by new ones. To not make it too easy there are also completely separate brand new products being implemented on new systems and with new integrations to external partners.
Marketing je nespokojen s kvalitou a flexibilitou IT. IT není schopno něco nasadit včas a následně je vždy velká chybovost produkce. Aby bylo možné něco realizovat rychle, je potřeba využívat ostřílené projektové manažery, kteří dokážou proplout mezi množstvím administrativních překážek a dokážou si došlápnout na vývojáře.
Marketing is not satisfied with the quality and flexibility of IT. IT is not able to launch anything on time and there are always too many issues in production. To deliver anything quickly enough it is necessary to use seasoned project management masters that are able to overcome number of administrative obstacles and to hit on developpers.
Analýza
Analysis
Dosavadní systém počítá se čtyřmi velkými releasy za rok. V mezidobí je možné si dohodnout výjimku a do produkce dávat věci nezávisle, čehož se využívá hlavně pro nové produkty. Často se dělají ještě mimořádné releasy, kde se "doráží" věci, které se nestihly. Mimoto existují ještě čtrnáctidenní technické odstávky na opravu chyb, ale nově tam nasazuje i agilní tým, do kterého vložilo vedení velkou naději.
The current way is based on four releases per year. In between those slots it is also possible to arrange for a specific release which is mainly used by new products. Often there are also exceptional releases used to fix things that were a bit late for the regular releases. Besides that bi-weekly technical maintenance windows give the opportunity to focus on fixing incidents but since recently it is also used by the new agile team to deliver new things. Agile is a new concept heavily supported by top management so not possible to challenge their needs.
Vše se testuje na integrovaném testovacím prostředí. Stav prostředí je ale poslední dobou špatný, není jasné, kdo ho řídí. Jelikož se tam testuje současně více věcí, těsně před každým releasem vývojáři připraví speciální balíčky pro produkci. Po releasu se často objevují chyby, které nebylo možno odhalit při testech a chyby se opravují formou mimořádných odstávek. Díky těmto opravám zbývá méně času na vývoj dalších releasů, zpoždění se kumuluje a kvalita je ještě horší.
Everything is tested on a common integrated test environment which is in a bad shape because nobody really knows who manages it. Because many things targeting different launch dates are being tested in parallel just before each release developers prepare specific deployment packages that contain only what needs to be there. The bad shape of the test environment causes bugs to be discovered on production and effort is spent on fixing those after the release instead of developpping the next release.
Testeři vidí problém v tom, že o testování vědí pozdě a dodávky mají velké zpoždění. Výjáři jsou zavaleni "dorážkami", které jsou ovšem trochu načerno, v reportech to svítí jako dodáno. Projektoví manažeři se necítí zodpovědni za nic jiného než jejich projekt a mají problém zejména se zpožděním dodávek vývoje a s měnícími se požadavky marketingu. Manažeři vývoje vnímají zejména velký tlak marketingu, který zadává požadvky přiliš pozdě.
Testers see the issue in how late they are informed about the scope to be tested and how late developpers deliver to the test environment. Developpers are overloaded also by things that were officially (as per the reports) released but not in reality. Project managers do not feel to be responsible for anything that is just a big external to their project and see issues mainly in late deliveries byt eh development teams and in changing requirements from business. Development managers feel a big business pressure together with late requirement submission.
Celá situace je dokreslena stanovisky typu tady to děláme odjakživa takhle, já bych se dokázal změnit ale to by se museli změnit nedřív ti ostatní, tak tohle jsme již zkoušeli a nazafungovalo to.
The whole situation is complemented by statements of the type we have always done like that, I cn change but the others need to change first, we have tried that but it did not work for us.
Plán
Plan
Řešení není jedno ale jde o komplexní práci na všech frontách s cílem dosáhnout flexibility ale zároveň spolehlivosti plánování. Je potřeba začít u schvalování projektů v portfoliu a u základního rozvržení kalendáře releasů, který je v podstatě nefunkční, jelikož neodpovídá reálným požadavkům marketingu a je tím pádem obcházen. Pro každý projekt je také nutno dosáhnout toho, že nejdříve se něco naplánuje, následně se to dělá. Z tohoto budou mít strach jako projektoví manažeři, tak marketing a bude třeba je přesvěčit.
There is not one single solution but a complex effort in all areas with the goal to obtain flexibility but also reliability of planning. The key place where to start is at the project validation gates in the portfolio function and at the planning of the release calendar that is in fact useless if not reflecting marketing needs because it is then just ignored by people. The principle of planning before doing needs to be refelctd by all projects. This might seem as a threat for some project managers and for marking hence it will be necessary to make them understand the benefits.
Další velký problém je na úrovni řízení změn do testovacího prostředí a do produkce, kdy se dnes jedná o dva nezávislé procesy, které znemožňují jakoukoliv kontrolu kvality. Správně by mělo být testovací prostředí vždy v "budoucím stavu produkce". Pro dosažení tohoto principu bude třeba velmi precizně definovat strukturu dodávek všech aplikačních týmů (jejich dílčích releasů) a stanovit pravidla, kdy se tyto dodávky mohou dostat na které prostředí. Bude třeba řešit i nástrojovou podporu s možností automatizace.
The next issue is in the disconnection of the change management processes for the test environment and for production. We need to introduce the princple that the test environment is the image of the future production environment. To implement the principle very specific rules on the structure of the delivered packages from all teams will be required. Also rules on when packages can be deployed to what environment. There will be room to implement new supporting tools with possible automation.
Standardní oříšek je rozdělení zodpovědnosti mezi projektovými manažery a někým, kdo bude ručit za všechny dodávky, říkejme mu release manažer, i když jinde bycho zvolili třeba "delivery manager". Zde budeme opět bojovat s projektovými manažery, zejména s těmi zkušenými nezávislými, aby přijali to, že pro daný release jsou zodpovědni vůči release manažerovi, který má větší zodpovědnost tedy i hlas.
A typical challenge is the split of responsibility between project managers and the overall delivery manager, let's call him/her the release manager. The goal will be to make understand espacially to the most experienced project managers, that starting a point in time they will report to the release manager who will have higher responsibily hence voice as well.
V neposlední řadě bude třeba měřit výsledek našeho snažení. Z dálky triviální metrika počet incidentů na produkci ale nepůjde použít dřív, než se napraví užitá praxe označovat některé chyby jinak než incidenty. Tato praktika vzniká většinou z důvodu vylepšování reportů IT provozu, který má na počet incidentů bez dalšího členění navázány prémie.
Last but not least it will be necessary to measure the result of all our erffort. At high-level a trivial metric number of incidents in production will not be functional unless removing the bad habbit not to record all issues as incidents but to hide them as various other types of tickets. The habbit comes usually from the need to embellish reports of IT operations, who often have that rough metric in their KPIs with no room for interpretation.
Výsledek
Result
Samozřejmě to dopadlo dobře, jinak bych to sem nedával. Zeptejte se mne.
Of course it went well, otherwise I would not put it here. Ask me.
