Oh my god, Micsoda gyömgyszem. Öröm a lelkem, hogy ilyen írűásokat olvasok…. Ezek csak olyan kiemelések, de a cikk minden szava arany. Be kellene kereteztetni.
- Ha a régi fejemmel gondolkodnék, akkor azt mondanám, hogy állítsuk rá az üzleti elemzőinket, mérjék fel az igényeket, majd specifikálják a feladatot, melyet a fejlesztőcsapatunk majd kivitelez. Ez jól is hangzana, a probléma csak az, hogy a legtöbb esetben a belsős üzleti elemző záros határidőn belül nem képes kellő mélységben átlátni a problémakört. A legtöbb informatikai projekt már az üzleti elemzés fázisánál zátonyra fut úgy, hogy sem a megrendelő, sem a kivitelező nem ismeri fel a fejlesztés valódi rákfenéjét. Gyúrják, pofozzák a szerencsétlen programot, míg végül lesz belőle egy agyonfoltozott sánta óriás, melyre sem bevezetni, sem karbantartani nincs elég erőforrás.
- Jelenlegi szemléletem alapján, az első dolgom az lenne, hogy megkeressem a túloldalon ülő vérbeli szakértőt. Azt a személyt, aki már több éve belülről ismeri az összes ága-bogát a banki ügyvitelnek, aki vezetett már banki irattárat, és saját maga is sok iratot írt alá. Ha nem találok ilyet, akkor tovább keresek: ez az első és legfontosabb erőforrás, melyre mindenképpen szükségem lesz, ha sikerre akarom vinni a projektet. Ha megtaláltam a kívánt személyt, leszerződök vele: be kell hoznom a projektbe ahhoz, hogy száz százalékban nekem dolgozzon, hogy belülről képviselje az ügyfelet. Ő lenne a projekt szakmai gazdája, az első számú üzleti elemző.
A második lépés ennél jóval könnyebb, de egyáltalán nem triviális: a frissen hozott erőforrás bár nagyon ért az adott területhez, informatikailag egyáltalán, vagy csak alig képzett személy. Szükség van mellé egy olyan üzleti elemzőre, aki a fejlesztői csapat élén állva megformálja a program lelkét képező domaint. Ha ezt a két személyt megtaláltam, akkor a kezemben van a projekt szakmai sikerességének garanciája
...
Ideális esetben külön lehet szerződni a követelményspecifikáció elkészítésére, és az abban megfogalmazott követelmények alapján lehet becsülni a fejlesztés, tesztelés, bevezetés stb. költségét. (Rosszabb esetben úgy adsz ajánlatot, hogy nem vagy tisztában a rendszer szkópjával, és csak annyit tudsz, amennyi a pályázati kiírásban szerepelt.)
…
Minden fejlesztőtársamnak azt javaslom, hogy próbáljanak meggyőzni az ügyfél oldaláról egy segítőkész embert, aki rendelkezésre tud állni, hogy segítsen a fejlesztés során. Hihetetlen dolgokat lehet így véghez vinni!
…
Fontos kockázatcsökkentő tényező, ha egy olyan ember legyen képes az ügyfélnél jelen lenni, aki proaktívan, dialógust kezdeményezve próbál olyan előzetes megoldásokat felvázolni, amik csökkenthetik a későbbi ráfordításokat. Valószínűleg nem csak nekem "áll fel a szőr a hátamon", amikor nem egy kövspecben ezt olvasom: "a rendszer naplózzon minden módosítást és módosítási kísérletet". Ha valaki olyan megy oda, akinek fogalma sincs a megvalósítás hátteréről, simán "benyel" egy ehhez hasonló követelményt. Amikor egy ilyen elhangzik, további kérdéseket lehet feltenni az ügyfélnek, hogy valójában mi a célja ezzel, mik a legfontosabb adatkörök, hogyan fogja ezeket felhasználni stb. Így egy pontosabb képet lehet alkotni az elképzelésekről, és ráadásul ésszel lehet neki állni egy ilyen követelmény megvalósításához.
...
Original
