Objektívan nézve a szavazásban ez nyert, így ez az első, de következőnek követi majd a tervezési folyamat. Kevésbé objektíven nézve a szavazószoftver az adblockereseknek jó eséllyel nem működött megfelelően (legalábbis kaptam erre utaló visszajelzéseket), de valami alapján dönteni kellett…

A requirement analysisnek (magyarul: megtudni, mit is kéne csinálni) a gyakorlatban két módja van:

  • az egyiket már félig-meddig bemutattam, ez a use-case analízis. Ez egy lassú, de biztos módszer.
  • A másik egy sajátos európai módszer: a klónozás. Ez általában nem is a programozókat érinti leginkább, hanem a megrendelőket: “egy olyat akarok, mint ez”.

(Hívják ezt kreatív másolásnak is…)

Ez utóbbi módszer megrendelői oldaláról egyszer elmondtam az őszinte véleményemet. Azóta több ember nem hajlandó velem szóbaállni; olyan se, aki részt se vett benne, csak klónozott terméket felügyel. Így most csak azzal foglalkozunk, a fejlesztés műszaki vezetőjeként mit tehetsz a szituációval.

A klónozás ugyanis egy dolgot nem mond meg: hogy mi miért van ott. Pont a legfontosabbat hagyja ki, azt, hogy mikre van szükség. Nem jó általában dolgozni olyan ügyféllel, akit nem lehet túllendíteni ezen.

De mégis, mit lehet tenni?

Ha előre nem megy, kénytelenek vagyunk visszafele.

Az adatstruktúrákkal ne foglalkozz. Nyilván pillanatok alatt le fog jönni az

  • űrlapokból,
  • adatlapokból és
  • táblázatokból

úgyis, hogy milyen adatokra lesz szükséged.

Emlékezz: a modellek három dolgot ábrázolnak:

  • elemeket,
  • viszonyokat,
  • és kölcsönhatásokat.

Ezek közül az elemek felismerése a legkönnyebb, viszont épp ezért a legkevésbé hangsúlyos.

De mik a kölcsönhatások? Azaz: mik lehettek a fő use case-ek? Erre kell rájönnöd első körben.

Ebben segíthet a rendszer igéinek kigyűjtése (gombok, menük feliratai), de én mégis azt mondom, inkább a

  • méretekkel és az
  • ismétlődések gyakoriságával
  • (az elhelyezkedéssel)

foglalkozz. Nyilván az a legfontosabb, ami a főoldalról (vagy a leggyakoribb képernyőfajtákon) elérhető, nagy, és középen van.

A végeredménynek olyannak kell lennie, mintha a másik végéről fogtad volna meg a requirement analízist. Tehát pontosan olyannak amiről az előző requirement postban szó volt.

Ez azért van így, mert az az a formátum, amivel lehet dolgozni. Természetesen az ügyfél, pláne, ha informatikai végzettséggel rendelkezik, ezt el fogja bagatellizálni, de ne higgy neki! Ha kell, részletekben, és folyamatában, részről-részre csináld, de akkor a legfontosabbakat vedd előre, és győződj meg róla, az a legfontosabb, építésbe ne kezdj requirementek nélkül!

A viszonyokra sokkal nehezebb lesz rájönnöd, persze, ehhez már szükséged lesz az adatstruktúrákra is, de sokszor sajnos rejtve maradnak, illetve csak a fejlesztés egy későbbi szakaszában jössz rá.

Mi a baj a klónokkal?

A probléma a klónprojektekkel, hogy a legtöbb megrendelő nem túl segítőkész ilyenkor: minek kérdezel, ott az eredeti (aztán persze konkrétan rámutatva egy-egy adott részre kiderül, mégsem.).

Megmondom az őszintét: a legtöbb klónprojektem bebukott, mert nem vagyok jó klónozó, és félreértésekkel volt teli a dolog. Ezért minden tapsot megérdemelnek azok, akiknek ez sikerül (a programozók, nem a kitalálók! Azok így néha megússzák házifeladatukat…)

Látszatra pl. a belső használatú szoftvereknél néha tényleg olcsóbb saját fejlesztéseket készíteni, mint megvenni a konkrét terméket, de ez sokszor csak látszat: hosszabb távon kijön, a szoftverházak által tömegével árusított szoftverek jelentősen olcsóbbak, jobbak.

A belső klónprojekteket elég nagy számban váltja le előbb-utóbb maga a klónozott szoftver vagy versenytársa, akkor is, ha a projekt amúgy sikeres volt, (több, mint) dupla árat fizetve a funkcionalitásért. Ehhez persze az kell, hogy az eredeti termék jól adaptálható legyen (de erre a jobbak figyelnek.)

(Meg persze a klónozás gyakran eltereli a figyelmet az aktuális szituációról, környezetről, de ez ismét megrendelői kritika lenne.)

De ha ugyanolyan, az nem is jó?

Ötleteket lopni nem szégyen. Volt, hogy egy interfész-tervem egy-az-egyben hasonlított egy már meglévő, asztali szoftverre. Ennek két oka lehet pozitív esetben:

  • Úgy a jó! Ha neked is az jön ki, hogy az ideális az adott helyzetben is az, amit láttál (pl. egy ikon elhelyezkedése, mérete, szimbólumkészlete), akkor egyszerűen úgy jó és kész.
    A baj az, hogy a végiggondolást a már meglévő minta sokszor akadályozza, nota bene, ezzel izzadós munkát spórolnak a concept-emberek, és néha áldásnak, nem pedig akadálynak tekintik.
  • Így szokta meg a célközönség: általában a honlapokon a keresők a jobb felső sarokban vannak. Ez nem az egyetlen lehetséges helyük (és tudom, a honlap jelenlegi reinkarnációban nem is ott van nálam), viszont itt szokták meg az emberek.
    Így alakult ki a jelenlegi, néha leválthatatlannak tűnő asztal-ablak metaforarendszerünk is.

Végül egy jótanács azoknak, akik mégis enélkül a lépés nélkül vágnának bele:

Előbb-utóbb kialakul benned a specifikáció, de ez leginkább olyan, mint vakegér a labirintusban: ahelyett, hogy GPS-szerűen megmondanák, mikor merre kell fordulni, ehelyett folyamatosan mész valamerre, falakba ütközve pedig visszafordulsz. Az meg, hogy van egy kész szoftver, amit másolsz, legfeljebb abban segít, hogy nem ködből vannak a labirintus falai.