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

  • 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?
  • Bethy: Sziasztok! Most olvastam a hozzászólásokat. Csak érdekelne, azóta mi történt? 2017-re alakult valami? (2017.05.01. 04:04) Milyen volt hazaköltözni?
  • 232323: Aztán az nem lehet hogy egyszer csak az igásló felcsattan, és azt kiabálja, hogy "Basszátok meg, hülye azért nem vagyok? Mindenki rajtam mászik fel?" Mert rajta kívül mindenki csak a pecsenyéjét sü... (2016.02.02. 09:40) Hungarian Teamwork
  • 232323: kimentem, hazajöttem és most nem találom a helyem. és az az érzésem, ha másodjára mennék ki ott se találnám a helyemet. Most már lehet sose fogom megtalálni... de az is lehet, hogy a fejemben kéne ... (2015.12.03. 08:58) Milyen volt hazaköltözni?
  • Pálinkó Menyhért: Valóban jó írás, de mint szakmabeli a 7. ponttal nagyon nem értek egyet! "Értelemszerűen a legolcsóbbat: open source, Linux, Apache, PHP, HTML. Minél rosszabb, annál több munka lesz vele" ezt felháb... (2015.11.08. 19:09) A gagyi diadala
  • Utolsó 20

29.
április

A gagyi diadala

akocsis  |  3 komment

Avagy hogy vigyük sikerre „minőséghiányos" szoftverfejlesztési vállalkozásunkat?

Az itt leirt elképzelések kizárólag a képzelet szüleménye. Bármilyen hasonlóság a valósággal csak a véletlen műve. Ha véletlenül valaki magára ismerne, akkor szégyellje magát :) 

Multinacionális cégekről az embernek általában magas elvárások, nemzetközi szabványok és minőségi munka jut eszébe. Azonban ott is emberek dolgoznak, ezért megfelelően agilis cégvezető a minőség ködén tisztán átlátva sikerre viheti gagyi cégét.

1) A munkatársakról
A sikeres gagyi cég maximum 10 fős. A munkatársak fiatalok és keveset keresnek, cserébe sokat dolgoznak (ismerős a „fiatal dinamikus csapat jól terhelhető munkatársat keres" hirdetés?). Fontos hogy keveset keressenek, mert így nem lesz tartalékuk, és nem tudnak felmondani. Fontos hogy sokat dolgozzanak, hogy ne legyen idejük másik állás után szaladgálni. És fontos hogy fiatalok legyenek, akik még nem tudják hogyan kellene szoftvert fejleszteni, így elhiszik hogy ez a világ legjobb helye.

2) A cég múltjáról
A legbutább multinak is nehéz lenne eladni egy múlt nélküli céget. Szükség van néhány „hiteles emberre", akik ilyen-olyan oklevéllel-minősítéssel rendelkeznek. Esetleg a cég szerezzen be néhány elismerő címet.
A cégnek legyen néhány jól csengő referenciája - elég ha beadtunk egy ajánlatot valahova, az már üzleti kapcsolat, nem? És persze megadjuk a sógort, a komát, a szomszédot, őket fel lehet hívni referencia gyanánt.

3) Hogyan vegyük fel a kapcsolatot a multival?
Ahogy minden sikeres gagyi cég csinálja: ismerősökön és rokonokon keresztül. Egy percet se fáradjunk tenderezéssel vagy pályázatosdival - az a lúzereknek való.
Az ismerősnek megszállott arccal adjuk elő, hogy mi egy nagyon komoly szoftverfejlesztő cég vagyunk, csak a világ gonosz és nem ért meg bennünket.

4) Hogyan szerezzünk projektet?
Mint „jóbarát" segitsük az ismerősünk munkáját a multinál. Világítsunk rá, hogy az IT Osztály által javasolt szabványok teljesen feleslegesek. Látványosan hördüljünk fel az IT Osztály által adott becslésre, mondjuk azt hogy fele annyiból is meg lehet csinálni a projektet. A hatás kedvéért dühöngjünk hogy milyen inkompetens informatikusok ülnek az ismerősünk cégénél.
Amikor végül ismerősünk kiböki, hogy na és akkor tényleg megcsinálnánk-e fele annyiért, akkor szívjuk a fogunkat és mondjunk igent. Hangoztassuk a szakma becsületét és a „most mi megmutatjuk"-ot.
Amennyiben az IT letett egy kész tervet, akkor nevessük ki. Mondjuk el ismerősünknek, hogy olyan tevékenységek mint elemzés, tervezés, tesztelés, projekt koordináció, management, minőség biztosítás vagy dokumentálás egyáltalán nem szükségesek. Ezzel is pénz, időt lehet megspórolni.

5) Hogyan nyerjük meg a projektet?
A győzelem titka az, hogy ne legyen vetélytársunk. Igyekezzük elkerülni, hogy az IT, a beszerzés vagy ismerősünk egy másik informatikai céget is bevon a projektbe.
A formaságokat és a szerződéskötést ugorjuk át. Szerződésre amúgy sincs szükség úriemberek között. (Ha mégis ragaszkodnak hozzá, akkor minél rövidebb annál jobb. Fontos: felejtsük ki a szerzői jogra vonatkozó részt)
Kerüljünk mindennemű írásos ajánlattételt. Szigorúan csak telefonon és személyesen kommunikáljunk, ne legyen írásos nyoma semminek.

6) Hogyan építsük fel az árat?
Kérdezzünk rá, hogy mennyi pénz van a projektre, és annyiba fog kerülni. Ilyen egyszerű.
Óradíjnak adjunk meg valami eszement alacsonyat, ami alá tisztességes informatikai cég nem megy, így biztosan nem lesz konkurenciánk. Persze aztán az 1 napos munkára 1 hónapos időt mondunk.
Az ultimate trükk az árral kapcsolatban az, hogy a döntéshozók kizárólag a végösszeget nézik meg, azt nem hogy mit tartalmaz. A többit a fantáziátokra bízom...
Ja, és az ajánlatokat ne részletezzük, mert belekötnek. Elég csak annyit mondani, hogy a kért webes nyilvántartó rendszer kifejlesztése 5 hónap munka és 3,660,000.00 Ft+Áfa lesz.

7) Milyen technológiát használjunk?
Értelemszerűen a legolcsóbbat: open source, Linux, Apache, PHP, HTML. Minél rosszabb, annál több munka lesz vele, és annál inkább ránk szorul az ügyfél.
Ha mégis valami komolyabbra lenne szükség, valamilyen egzotikus technológiát válasszunk, amihez senki más nem ért Magyarországon.

8) Hogyan építsük fel a projektet?
A képlet egyszerű: mi elvonulunk fejleszteni, és majd szólunk ha készen vagyunk. Elemzés, specifikáció készítés, meetingek, státusz report, ezek mind feleslegesek.
A projekt szervezet úgy nézzen ki, hogy mindenki csak bennünket ismer, és senki sem kommunikál senkivel csak velünk. A fejlesztők ne ismerjék a kulcsfelhasználókat, a rendszergazda a fejlesztőket, a manager a fejlesztőket, stb.
Csak akkor fogják a munkánkat értékelni, ha akadozik a kommunikáció.

9) Hogyan adjuk át a kész (félkész) szoftvert?
Hibamentes szoftver nincs, ezt az átadás előtt többször mondjuk el az ügyfélnek. Egyébként is a rendes software projektek csúsznak, tehát semmi gond, nem kell kapkodni.
Nyugtassuk meg a kulcsfelhasználókat, hogy mi mindent megteszünk a hibák kijavítására, ne aggódjanak.
Ha sürgős, akkor induljunk el a félkész szoftverrel, és majd menet közben garanciálisan javítjuk a hibákat - ez egy fair megegyezés, nem?
A szoftver funkcionalitását firtató kérdéseknél kezdjük el az amnézia tüneteit mutatni - nem, erről a funkcióról eddig nem volt szó, nem beszéltünk róla, nem vállaltuk be, nem emlékszek rá. (Na EZÉRT fontos hogy ne készüljön dokumentáció és jegyzőkönyvek)

10) Hogyan történik az átadás?
Fontos: a forráskódot SEMMILYEN KÖRÜLMÉNYEK KÖZÖTT NE ADJUK ÁT, még akkor sem ha nyomatékosan kérik. A programot mi írtuk, tehát a miénk, a megállapodásnak megfelelően. (itt megint jöhet az amnézia)
Ha a teljesítés miatt mégiscsak át kell adni valamit, akkor ügyeljünk rá hogy az használhatatlan legyen.
Az átadás csak annyiból álljon, hogy mi átadjuk a szoftvert (úgy ahogy van), az ügyfél pedig átveszi. Ezután rögtön küldjük a számlát - elvégre teljesítettük a ránk eső részt.
Dokumentációt nem kell átadni, hiszen csak szoftvert vettek tőlünk. A dokumentáció egyébként is a mi szellemi termékünk.

11) Mi történik az átadás után?
Próbáljuk meg a funkcionalitást a minimálisra csökkenteni, amivel még éppen elmegy a szoftver. Túl sok munkát ne fektessünk a hibajavításba.
Ha ebből gond lenne, akkor ígérjük meg hogy mindent megteszünk, de ez plusz munkával jár, amiért plusz pénzt illene adni. Mondjuk el, hogy a projekt részünkről totál ráfizetés, szívességből csináljuk az egészet, szóval nem tudunk csodákat tenni. Szegények vagyunk mint a templom egere, és az ág is húz.

12) És eljő a Kánaán...
A használatban lévő szoftverre előbb-utóbb úgyis érkeznek változáskérések, ez az élet rendje. Na ilyenkor fogjuk a nagyon alacsony órabérünket és hihetetlen magas óraszámokat hozzunk ki (napok helyett hónapok), a kettő szorzataként pedig szép takaros összegeket (milliók).
Úgyis minden gyorsan kell, ezért hagyjuk lealkudni a határidőt hónapokról hetekre, az ár minimális csökkentése mellett. Így jobb óradíjunk lesz mint egy olajsejknek.
A módosítások után szintén ne adjuk át a forráskódot. Esetleg mondjuk azt, hogy az ügyfél csak az eredeti szoftvert birtokolja, a módosítottat nem.

13) Mi a teendő, ha jön az IT Osztály?
Mindenképpen kerüljük ki. Soha senkinek ne beszéljünk a szoftver felépítéséről, működéséről, ez legyen a mi belső titkunk.
Igyekezzünk minden kommunikációban az ismerősünkre szorítkozni. Ha az IT beszélni akar velünk, ne menjünk el meetingre. Ha mégis elmegyünk, ne akarjuk megérteni amit mondanak.
Amikor valamilyen szabvánnyal vagy minőségbiztosítással jönnek, a meeting után az ismerősünknek magyarázzuk el, ez mennyire felesleges.

14) Mi a teendő, ha jön a Jogi Osztály vagy a Beszerzés?
Ha nem volt szerződés, ha nem voltak jegyzőkönyvek, akkor jöhetnek. Úgyse tudnak mit csinálni. Majd keménykednek egy sort, szigorúan néznek, de ennél többet úgyse tehetnek.
Legrosszabb esetben említsük meg nekik, hogy mennyire elegünk van ebből a projektből, és már többször megfordult a fejünkben hogy lekapcsoljuk a szervert.

15) Mi a teendő, ha valaki másnak az ismerőse beelőz bennünket?
Mivel nem a teljesítményünkkel jutottunk be, ezért a teljesítményünk nem is fog tudni bent tartani. A lehetőség elúszott, nézzünk másik ismerős után.

+1) Ha valaki azt kérdi, miért nem halad előre a cégünk, kezdjünk sírni. Mondjuk azt hogy ebben az országban csak ismerősökkel lehet bármit is elérni, a teljesen fair és műszakilag magas szintű szolgáltatásunkat egyszerűen nem tudjuk eladni.

Címkék: it szoftver pályázat gagyi fejlesztés ismerős tender management diadala bejutni

A bejegyzés trackback címe:

http://akocsis.blog.hu/api/trackback/id/tr45211217

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.

Hesz Roland · http://rolandhesz.com 2009.05.01. 14:09:01

Még jó, hogy ilyen sose fordul elő. *megkönnyebült sóhaj*

Pálinkó Menyhért 2015.11.08. 19:09:12

Valóban jó írás, de mint szakmabeli a 7. ponttal nagyon nem értek egyet! "Értelemszerűen a legolcsóbbat: open source, Linux, Apache, PHP, HTML. Minél rosszabb, annál több munka lesz vele" ezt felháborítónak tartom, és kérlek javítsd. Csak a linux kernelen számtalan fejlesztő dolgozik a világ minden tájáról, és az open source felfogást ilyen megvilágításban használni szörnyen nagy tudatlanságra vall. Az a tény, hogy Magyarországon egy pitiáner vállalkozó a hosszútávú együttműködést arra a tényre szeretné megalapozni, hogy olyan operációs rendszer használ, melyhez hazánkban sajnos kevesen értenek, nem jelenti azt, hogy ezeket az eszközöket minősíteni kellene a vállalkozóval szembeni negatív véleménynyilvánítás közepette. A vállalkozó hibás, amennyiben szándékosan az IT osztály kompetenciáját meghaladó eszközök használatára igyekszik a monopólium kialakítása érdekében, de könyörgöm IT szakemberként jussunk már túl Pista bácsi színvonalán, ha nem ismerem a világító kütyüt akkor az rossz...