[Java lista] várom a véleményeteket

[ern0]

> Nézd, nem akarok kötözködni, de ilyen, hogy "helyzetfelmérés",
> szerintem nincs.

De van
http://www.google.com/search?q=helyzetfelm%C3%A9r%C3%A9s+szervez%C3%A9s

> Van egy ajánlattételi szakasz. Ennek célja az, hogy kiderüljön,
> egyáltalán akarok-e üzletet kötni. Nagyjából meg kell érteni, mégis
> mit akar a tisztelt ügyfél. Ez még messze nem tartozik a
> szoftverfejlesztés projektbe, ez sokkal inkább marketing/sales
> tevékenység.

Ez így igaz. Nem mondom azt, hogy ehhez semmi közünk, mert néha-néha
részt veszünk ilyesmiken szakértőként, de ez tényleg nem a mi melónk.

> Ha úgy döntök, hogy indulni akarok az üzletért, akkor jön a
> megvalósíthatósági terv elkészítése. Itt már részletesebben meg kell
> értenem, hogy mit is szeretne a megrendelő; fel kell mérni valamennyi
> nem funkcionális követelményt is. A felmérés messze nem lesz teljes,
> de azért nagyjából látnom kell, mégis mekkora melót készülök
> elvállalni. Sokan itt buknak el.

Ez így igaz, és ez elég éles téma, mert az árat is itt kell megálmodni.

> Szóval szerintem van ajánlattételi szakasz, és van fejlesztési
> szakasz. Ha az elsőt akarod "helyzetfelmérésnek" hívni, részemről
> rendben,

Az az előzetes helyzetfelmérés. Persze helyzettől függ, mi merre, mert
pl. ha a kedves ügyfél egy lezárt projekt során azzal jön hozzánk, hogy
csináljuk meg akkor azt is, amit legutóbb kihúztunk, akkor ez az
ajánlattételi szakasz igencsak lerövidül, meg akkor is, ha nagyon
egyértelmű a feladat.

> viszont az nem teszi ki a meló 40 százalékát. A meló közel felét
> sztem az üzleti folyamatok megismerése, majd modellezése teszi ki.

Stop. Ez volna a helyzetfelmérés. Amikor még nem arra koncentrálunk,
hogy mi legyen, hanem hogy mi van, és ezt dokumentáljuk is. A 
dokumentációs résszel átlalában nincs baj, mármint azzal, hogy mindneki 
tudja, dokumentálni kell (aztán hogy milyen minőségű dokumentumok 
születnek, az már egy dolog), de az információszerzés módszertana kicsit 
elsikkad, pl. - ebben a kontextben - rég olvastam már, hogy "interjú".

BTW kettős érzelemmel viseltetek mindenféle szervezés- és projektviteli 
tudományok felé.

Egyrészt aki tud gondolkodni, az úgyis folyamatosan meta-meta szinten 
ellenőrzi önmagát, a módszert, minden projekt során kitalálja újra a 
módszertanát, a részproduktumokat, azok funkcióját, mintegy igazodva az 
adott melóhoz. Erről nézvést utálom, hogy azt az egyszerű és triviális 
gondolatot, hogy "a prgmot kis lépésekben fejlesszük, a felhasználót 
minél inkább bevonva, sűrű release-ekkel kényeztetve" elnevezzük 
bárminek is, illetve erről az egy mondatról könyveket írjunk. Márcsak 
azért is, mert ha egy szakmailag dilettáns csávó akarja így csinálni, 
neki nem fog menni, neki sehogyan sem fog menni, ráadásul csak 
beszennyezi az egyébként jó módszer nevét.

Másrészt igenis meg kell fogalmazni a triviálist, mert igazán okos 
gyerekek vagyunk, de biztos van a módszertanokban olyan apróság, ami 
hasznunkra válhat. Aztán a kommunikációt is segíti, ha nem elmesélem 
hosszú estébe nyúlóan, hogyan fogok dolgozni, hanem azt mondom: agile, 
vagy waterfall.
-- 
ern0
dataflow programmer & evangelist