Az evidencia csapdája ránk is leselkedik, ezért érdemes óvatosnak lennünk, amikor határozottan képviselünk egy álláspontot, vagy értelmezünk egy helyzetet anélkül, hogy ismernénk a tényeket. Az alábbi eset szereplői kis segítséggel ugyan, de átléptek saját árnyékukon és igazi értékeket hoztak létre, közösen. Íme Történetek a gembáról sorozatunk következő része: Lean IT? – programozók az evidencia csapdájában
A szakmai cikk elolvasásához szükséges idő: kb. 3 perc
Szerző: Demeter Dénes – lean coach
Háttér
Adott egy szoftveripari vállalat, amely napjainkban több sikeres termékkel is rendelkezik. Ám ez nem volt mindig így. A vállalat korábban több cég egyesüléséből jött létre, megörökölve azok termékeit is. Ezeket a termékeket azonban különböző elgondolások mentén tervezték és hozták létre annak ellenére, hogy azok alapvetően közös felhasználói kört szolgáltak ki. Ráadásul az egyes termékek építőelemei is nagy átfedést mutattak, mégis mindegyik termékben más és más módon lettek leprogramozva azonos funkciók.
Mi a probléma?
Minden termék rendelkezett például egy bázis adattárral, amiben az adatok 90%-a megegyezett ugyan, de azok teljesen más struktúrában, más-más gyártók adatbázisában voltak tárolva. Hasonlóképpen több funkció is azonos volt az egyes termékekben, azok azonban teljesen más megfontolások alapján lettek leprogramozva.
Ennek az volt az oka, hogy az egyes csapatok nem azonos elvek mentén tervezték és valósították meg a termékeiket és azok építőelemeit. Az egyes termékek fejlesztőcsapatai kis szigetként működtek egymás mellett, mintha különálló kis cégek lettek volna a cégen belül.
Mindez azt eredményezte, hogy
- ugyanazt a munkát többször is elvégezték párhuzamosan. Például a termékek továbbfejlesztése során az azonos funkciókat többször is lefejlesztették minden olyan programban (termékben), ahol az adott funkció értelmezhető volt,
- ez jelentősen meghosszabbította az elkészítés átfutási idejét,
- ami természetesen a költségeket is jelentősen növelte,
- ráadásul a vállalat ügyfelei – akik jellemzően több terméket is használtak egyszerre –, nehezen fogadták el, hogy a termékek sem kinézetre, sem bizonyos funkciók tekintetében nem egységesek. Például az alapadatok felvitelének módja teljesen eltért az egyes termékek esetében, ezért határozott elvárás volt az ügyfelek részéről is az egységesítés.
Megoldás
A vállalat elindított egy többéves egységesítési programot azzal a céllal, hogy egységesíti a termékportfolióját, és azokat az építőelemeket, amelyek minden termékben megtalálhatóak csak egyszer, egyféleképpen készíti el.
A vállalat legtapasztaltabb szoftverfejlesztőit kérték fel, hogy dolgozzák ki az úgynevezett kód konvenciókat (szabálykészleteket) és azok alapján a kódok felülvizsgálatának (code review) folyamatát. (A kód felülvizsgálat az a folyamat, amikor egy tapasztaltabb fejlesztő átnézi a programozók által írt kódot, hogy megfelel-e a definiált elvárásoknak.) A csapat többéves tapasztalattal rendelkező, elismert szakemberekből állt, akik egy-egy szoftvertermék architectjei (egy termék tervezéséért felelős, tapasztalt szoftverfejlesztői) voltak.
A szakemberek a felkérést meglepő módon mérsékelt lelkesedéssel fogadták, többségük nem is szeretett volna részt venni benne. Azt mondták, hogy ezek a konvenciók le vannak fektetve, már az egyetemen is tanították őket, és egyébként is mindenki ezek szerint dolgozik.
Az eltérő módon megírt programmodulok viszont nem ezt támasztották alá. Sőt, ha egyik termék programkódját egy másik termék fejlesztőcsapata meglátta, jellemzően erősen kritizálta azt. Mint amikor – tisztelet a kivételnek – az építőipari „szakik” ócsárolják egymás munkáját. Nem is csoda, hogy az egyes csapatok nem szívesen engedtek betekintést a programkódjaikba „külsősök” számára. Ez a fajta működés megnehezítette az egységesítési program haladását.
Végül sikerült egy asztalhoz ültetni a szereplőket, hogy többek között olyan alapvető kérdéseket beszéljenek át mint:
- Milyen egységes irányelvek mentén, hogyan írják a programozók a kódokat?
- Milyen kimeneti, minőségi elvárások vannak az egyes kódokkal kapcsolatban?
- Milyen funkciókat, paramétereket kell ellenőrizni a kódok felülvizsgálata során?
Eljött a pillanat, amikor a megbeszélést kezdeményező kolléga azt kérte, lépéről lépésre meséljék el, hogyan is csinálják a kód felülvizsgálatának folyamatát, milyen szempontokat vesznek figyelembe, és mit is néznek meg pontosan.
Ekkor az egyik szakértő elkezdte mondani, hogy ő milyen gyakorisággal, hogyan és mit néz meg. Az első mondatát is alig tudta befejezni, már jött is a replika egy másik résztvevőtől, hogy azt nem úgy kellene, ő másképp csinálja. Ahogy haladt előre a megbeszélés egyre többen mertek őszintén bekapcsolódni a vitába. Végül aztán belátták a résztvevők, hogy amit evidenciának gondoltak az mégsem az.
Ettől kezdve vált konstruktívvá a folyamat: a releváns kérdésekben meghallgatták egymás tapasztalatát, eldöntötték, milyen egységes módon kezelik a jövőben az adott kérdést, és hogyan foglalják a megállapodásokat vállalati szintű standardba. Az első megbeszélést sok további követte, amelyek során lefektették egy közös platform programozási elveinek alapjait.
Konklúzió
A történet szépsége és egyben tanulsága is, hogy a csapattagok végül nem csak ezt az adott problémát oldották meg közösen. Megtanulták azt is, hogy feltételezések helyett mennyire fontos a jelenlegi helyzet megértése, hogy megosszák egymással a gondolataikat és meglátásaikat, majd tények alapján döntsenek. Ezen felül pedig megtapasztalták, mennyire jól tudnak együtt dolgozni, inspirálni egymást, és közös kreativitásukkal tényleges értéket létrehozni.
Feladatunk tehát, hogy közösen gondolkodjunk, tanuljunk egymástól. Így végre felszabadulnak a „szakértők” annak nyomása alól, hogy folyamatosan tévedhetetlennek, mindentudónak kell lenniük. Így megszülethet egy sokkal erősebb, összetartóbb, együtt gondolkodó és egymástól tanuló szakértői csapat, amely tanítja és fejleszti a junior kollégákat, és a vállalat programozói számára irányt mutat.
A cikk szerzője
lean coach
Történetek a gembáról sorozat
Nagyon sokat írtunk már a lean szemlélet alapelveiről, bevált eszközökről, hasznos technikákról és a kritikus gondolkodás fontosságáról. A fenti témák rendkívül fontosak, viszont úgy éreztük, hogy itt az ideje kivinni titeket a gembára, és megnézni, hogyan alkalmazhatjátok a korábban tanultakat a gyakorlatban! Íme Történetek a gembáról sorozatunk részei:
- Rázva, nem keverve – a „mix well” kísérlet
- Mit tegyünk, ha a dolgozó nem elég ügyes?
- Most akkor melyik a jó termék?
- Lean = józan paraszti ész?
- „Hagyja a cipekedést másra” – logisztikai robotok találkozása a leannel
- Lean IT? – programozók az evidencia csapdájában
- Elsőre jót! Na jó, akkor másodikra…
- Műszakvezetői standard – „Mit is csinál a műszakvezető egész nap?”
Könyvajánló
Vezető vagy és szeretnéd kihozni alkalmazottaidból a maximumot?
Érdekel, hogy mik azok a vezetői titkok, eszközök, melyek segítenek a tartós siker elérésében?
Szeretnél igazi lean szemléletű vezetővé válni?
A Tisztelet ereje – Regény a lean szemléletű vezetésről című könyv segíteni fog saját magad, és csapatod fejlesztésében, így együtt tudtok tartós sikereket elérni! Alapmű azok számára, akik szeretnék elsajátítani a lean szemléletű vezetés alapjait.
