Blog

A scope creep nem egyetlen nagy katasztrófa, hanem lassú szivárgás - apró, önmagukban ártalmatlan kérések összeadódó hatása. Agilis projekteknél paradox módon veszélyesebb, mert a "rugalmasság" álcázza: ha minden változás agilis alkalmazkodásnak számít, senki nem mondja ki hangosan, hogy valójában kontrollálatlan bővülés történik. A cikk megmutatja ki miért felelős a kezeléséért, és ad egy működő gyakorlati eszköztárat - a kiskutyából hétfejű szörny mém apropóján.

A legacy rendszer nem szitkozódás -értéket hordoz. 4 helyzet amikor nem érdemes modernizálni: ha nem tudod pontosan mit csinál, ha IT divat hajtja a döntést, ha nincs meg a belső tudás az átálláshoz, és ha a határidő sürgeti. És 4 egyértelmű jel amikor mégis muszáj - döntési keretrendszerrel.

A fejlesztő nem azért nem találja meg a saját kódja hibáit, mert nem elég jó — hanem mert ugyanolyan gondolkodásmóddal tesztel, amellyel a kódot írta. Három valós projektpéldán keresztül — biztosítói mobilapp, Salesforce CRM, lízingcéges workflow — megmutatjuk miért strukturális ez a probléma, és mikor nem opcionális a független QA bevonása.

A Scrum iterációkban, a Kanban folyamatosan teremt értéket — de pénzügyi szektorbeli szervezeteknél ritkán kell választani: a fejlesztési csapat Scrummal, az üzemeltetés és a BA/SA csapat Kanbannal dolgozik a legjobban. Négy kérdéses döntési keretrendszer segít megtalálni melyik módszertan illik a projekthez — és mikor egyik sem a helyes válasz.

A Scrum formális alkalmazása pénzügyi szektorbeli nagyvállalatoknál sokszor nem hozza a várt eredményt — nem az agilis elvek hibásak, hanem a kontextus más. Lassú döntéshozatal, nem autonóm csapatok, compliance által diktált backlog: ezek szervezeti problémák, amelyeket módszertani változással nem lehet megoldani. Ami valóban működik: az agilis szemlélet — iteratív szállítás, transzparens kommunikáció, folyamatos prioritizálás — ceremóniák nélkül.

A digitalizációs projektek többsége azért bukik el, mert IT-projektként kezeli, holott valójában szervezeti változásról van szó. Három szereplő hiánya okozza a legtöbb kudarcot: az üzleti folyamat gazdája, az üzleti elemző aki fordít az IT és az üzlet között, és a változásmenedzsment felelős. Amíg az üzlet passzív befogadó marad, a legjobb technológia sem hoz valódi változást.

Egy pénzügyi nagyvállalatnál 50-200 digitalizálható folyamat van. Mindenki a saját területét tartja a legfontosabbnak. A sorrend döntés stratégiai — mert ha az első projekt megbukik, a következőhöz már sokkal nehezebb belső támogatást kapni. Ez a cikk egy egyszerű döntési keretrendszert ad: négy tényező - fájdalomintenzitás, megvalósíthatóság, üzleti hatás és láthatóság - alapján meg lehet határozni mivel érdemes kezdeni. Három konkrét példán keresztül: biztosítótól, banktól és lízingcégtől.

A digitális transzformációs projektek többsége nem technológiai okból bukik el, hanem azért, mert hiányzik az üzleti szemlélet, a valódi folyamatértés és a változásmenedzsment. A cikkben 25 év pénzügyi szektorbeli tapasztalatomon keresztül mutatom be azt az 5 leggyakoribb mintát, amely miatt a vállalatok 70%-a nem éri el a kívánt üzleti eredményt. Valós biztosítói, banki és lízinges példákon keresztül látszik: a sikeres transzformáció nem az új rendszerekről, hanem a jól definiált üzleti célokról, a legacy rendszerek őszinte feltérképezéséről és az üzlet–IT együttműködésről szól.

A szoftvertesztelés kiszervezése nem minden esetben a legjobb megoldás - de négy konkrét helyzetben egyértelműen az: projekt csúcsterheléskor amikor toborzással nem ér oda időben a csapat, hiányzó domain tudásnál (különösen pénzügyi szektoros projekteknél), külső fejlesztői partner esetén ahol független szemre van szükség, és ha a QA nem core tevékenység de a minőség üzletileg kritikus. A cikk döntési keretrendszert ad - és azt is megmondja mikor NEM érdemes kiszervezni.

Sok IT projekt nem a technológia miatt csúszik meg, hanem azért, mert nincs, aki valóban gazdája legyen az üzleti igényeknek. A business analyst szerepe nem adminisztratív dokumentáció, hanem a félreértések, scope creep és drága újrafejlesztések megelőzése. A cikk valós projektpéldákon és piaci számokon keresztül mutatja be, hogy egy hiányzó BA költsége gyakran többszöröse annak, mint a bevonásának ára.

A cikk bemutatja, miért nem működik sok követelmény specifikáció és funkcionális specifikáció a gyakorlatban, még akkor sem, ha szakmailag rendben vannak. Egy tapasztalt üzleti elemző nézőpontjából 5 tipikus jelet sorol fel, amikor a specifikációt nem olvassák vagy félreértik. Fő üzenet: a specifikáció nem csak dokumentum, hanem kommunikációs eszköz — minősége közvetlenül befolyásolja az IT projektek sikerét.

A legtöbb legacy modernizációs projekt nem technológiai okokból bukik el, hanem azért, mert rossz problémát próbál megoldani. A scope gyakran a meglévő rendszer logikáját követi, nem az üzleti értéket, miközben az üzlet nincs valódi partnerként bevonva, és az emberi tényező is háttérbe szorul. A siker kulcsa az értékvezérelt megközelítés: gyors, kézzelfogható üzleti eredmények, inkrementális modernizáció (pl. API encapsulation), valamint tudatos szervezeti és működési változáskezelés.

Business analyst vagy product owner amire szüksége van a projektnek? Mikor kell BA és mikor PO, és mikor mindkét pozíció? Miben különbözik a két szerepkör? Ezekre keressük a válaszokat a cikkünkben.

Meddig tart a Business Analyst munkája? Mikor mondhatja el, hogy kész van? Három viselkedési jel, ami megmutatja, hogy a BA valóban hatékonyan dolgozik

A COVI hatalmas változást hozott a szükséges proojektmenedzsment módszerekben. Változó csoportdinamika, új eszközrendszer, változó stakeholder kezelés, és egy kis jövőbe révéedés, hogy mi fog még vátozni. Ezeket a kérdseket járuk körbe....

Mélységesen felháborodnánk, ha a hűtőszekrényünket naponta javítani kellene...A szoftvereinkhez viszont naponta jönnek patch-ek, javítások! 😀 ❓ Tényleg ennyire gyenge a szoftverek minősége? ❓ Véleményünk szerint nem!