Avagy milyen az, amikor a programozók alulról jövő kezdeményezéssel, demokratikus módszerekkel dolgoznak?
Avagy milyen az, amikor a programozók alulról jövő kezdeményezéssel, demokratikus módszerekkel dolgoznak?
Sok programozó álmodik egy olyan munkahelyről, ahol nincsenek menedzserek, ahol nincs vízfej, és ahol nem a fejétől bűzlik a hal. Ahol úgy lehet szoftvert fejleszteni, ahogy csak akarnak.
Már több munkahelyen belefutottam olyan szituációba, ahol a menedzsment gyenge volt és/vagy nem foglalkozott az operatív munkával (azaz magával a szoftverfejlesztéssel és a szoftverfejlesztőkkel). Ezek alapján megpróbálom összeszedni azokat a tipikus hibákat, amik ilyenkor – effektív menedzser hiányában – előfordulnak.
Pre-sales és sales támogatás hiánya
A pre-sales és a sales egy informatikus szemében nem munka, ezért ezzel senki sem fog foglalkozni. Senki nem fog ajánlati dokumentumot készíteni, teljesen rábízva azt a kereskedőkre – akik ezért majd azt írnak bele, ami az eszükbe jut.
Az ajánlatok nem úgy és nem arra fognak szólni amire kell, esetleg súlyos koncepcionális hibákat tartalmaznak.
Tipikusan ezek a projektek, amik már az induláskor műszaki hibásak.
Ügyfélkapcsolat hiánya
Nem lesz senki, aki az ügyfél lelkivilágát ápolja. A fejlesztő fejleszteni akar, nem szeretne „emberi” problémákkal foglalkozni. Ennek eredményeképpen az ügyfél nem tudja, kihez fordulhatna, kit hívjon fel, és két rossz közül választhat:
- Vagy a fejlesztőket próbálja minél határozottabban zavarni (és elragadni őket a munkavégzéstől)
- Vagy napi szinten a cég vezérigazgatójához eszkalál
Az elvárásokat senki sem térképezi fel
Közhely, hogy az igényeket fel kell tárni és oda kell figyelni arra, mit akar az ügyfél. Na ez az, ami nem fog megtörténni. Márpedig ha nem figyel senki oda az ügyfélre, akkor pont az nem fog kiderülni, mire van szükség a szoftverben, mik a funkcionális követelmények és a nem funkcionális követelmények, illetve milyen apróságok vannak amik a szoftver működését befolyásolják.
Nem az készül el, amire szükség van
Ha a követelmények nem ismertek, akkor azt gondolná az ember, hogy a fejlesztés áll és senki nem csinál semmit. Ennek pont az ellenkezője lesz igaz: a fejlesztés teljes gőzzel halad, mindenki dolgozik. De mi alapján? Vélt követelmények alapján. A végén el fog készülni egy szoftver, ami bizonyos szempontból – a fejlesztők szempontjából – jó. De az ügyfél számára nem jó. Nagyon nem.
Nincs terv
A fejlesztők nem szeretik, ha van terv és van határidő, ezért nem lesz egyik sem. Márpedig amikor a sales megállapodott az ügyféllel, akkor megegyeztek egy határidőben és megegyeztek a leszállítandóban. (Vagy legalábbis az ügyfél úgy értette…)
Mivel nincs terv, ezért határidőre nem is készül el a munka… az ügyfél pedig nagyon meg fog haragudni.
Nincs QA
Ha a fejlesztőkön múlik, akkor nincs code review és nincs tesztelés, hiszen ezek csak lassítják a munkavégzést.
Nincs dokumentáció
A másik dolog, amit a fejlesztők nem szeretnék – és menedzser hiányában nem is fognak csinálni – az a dokumentáció. Minden tudás a fejekben lesz, és a fejlesztőknek egymás között egy jó is lesz így.
Senki sem tudja, hogy áll a munka
Mivel nincs terv, ezért nincs mit visszaellenőrizni. De ha lenne is terv, a fejlesztők nem fogják azt nézegetni, hogyan állnak – csak dolgoznak. Csak a fejlesztők tudják, hogy áll a szoftver, rajtuk kívül senki. A menedzsment és az ügyfél pedig aggódik, hogy elkészül-e.
De ha egy picit komolyabb a munka, akkor már a fejlesztők sem fogják tudni, hogyan állnak. Legfeljebb egyénileg azt tudják megmondani, hogy amin éppen dolgozik az hogyan áll, de hogy az egész mikor lesz kész?
Nincsenek eszközök és nincsen információ
A fejlesztés akadozni fog, mert a szükséges eszközöket senki sem szerezte be, illetve kulcsfontosságú információ hiányzik. Ezek beszerzését senki sem érzi saját feladatának. A nemszeretem feladatokkal senki sem foglalkozik.
Nincs válságkezelés
Amikor vészhelyzet van és gyorsan reagálni kellene, akkor nincs kit felhívni. Nincs senki, aki a válságot kezelje és visszaterelje a munkát a helyes kerékvágásba. Ezért bármilyen jók is a fejlesztők, a legelső válsághelyzet tönkrevágja a projektet.
Nincs felelős
A válsághelyzetekben az is ki fog derülni, hogy senki sem felelős.
Széteső csapat
Ha nincs kinevezett főnök a csapatban, valaki akkor is fog irányítani. Mindig van alfa hím. Ha nincs egy tudatos menedzser, akkor esetleg nem a megfelelő ember lesz az alfa hím. Esetleg olyanok fogják dominálni a csapatot, akik rossz hatással lesznek a többiekre (és a teljesítményre). És nem lesz senki, aki ezt megállítaná.
Tabuk kialakulása
Normális, hogy egy csapatban szokások és tradíciók alakulnak ki. Viszont ezeket időről időre felül kell vizsgálni és ha szükséges, javítani rajtuk. Ha nincs egy erős vezető a csapatban, aki ilyen döntéseket meghozna, akkor a szokások rabjává válik a csapat, és nem fog tudni fejlődni.
Nincs priorizálás
Mivel nincs terv, nincs határidő és nem tudjuk, mi fontos az ügyfélnek, ezért adott helyzetben nem lehet megszervezni, hogy mi az amin aktuálisan dolgozni kell (fontos, sürgős) és mi az, ami ráér később (kevésbé fontos vagy kevésbé sürgős). Tehát a csapat nem azon fog dolgozni, amin akkor és ott kellene, hanem ami éppen a kezükbe kerül.
Összességében az a helyzet, hogy bármennyire is inkompetens és drága egy öltönyös menedzser, és bármennyire is ballaszt egy szoftverfejlesztésben, de nélküle sokkal nagyobb károk fogják érni a céget.
Utolsó kommentek