HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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.

Címkék: menedzser csapat

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr555211886

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Roland Hesz 2012.10.03. 23:45:14

Általában amit tapasztalok. Fejlesztők kiugranak a bőrükből, ha kapnak egy BA-t, aki felméri a követelményeket. Általában a jó fejlesztők szeretik látni, hogy merre haladnak, mi a munka, mennyi van hátra, egyebek. Nállunk ők örülnek legjobban a bevezetett task kezelő appnak. QA - elég nagy palávert csapnak, ha teszt nélkül akar kimenni valami. Ez nem csak itt, általában tapasztaltam, hogy az ügyfél és a menedzsment ódzkodik a teszttől, azzal csak az idő megy. Volt egy pár bukta mostanában, csapat szépen felállt, és egy nagyon összeszedett "we are sorry" prezentáció tartottak - mi volt a gond, ki szúrta el, hogy javítjuk ki. Rossz kóderek persze semmit nem szeretnek. Meg persze a gyenge csapatvezetők, akik inkább rejtegetnék a problémákat. A többi az stimmt, főleg a sales. De az öreg, tapasztalt fejlesztők átlátják a szükségeét a posztban említett dolgoknak.