Ez a poszt a peer létrehozása és pozícionálása kapcsán folyó beszélgetések eredménye.
Amikor tervezés centrikus fejlesztésről beszélünk, akkor elsőre talán mindenkinek az jut az eszébe, hogy a grafikus leül és rajzol, majd utána beindul a programozás. Valójában nem, a tervezés centrikus gyártás arról szól, hogy az erőforrások drasztikus átstrukturálásával a fejlesztés helyett a tervezést teszik a projekt fókuszába.
A mai tipikus, vagy klasszikusnak mondható termékfejlesztés - webes projektek esetében - optimális esetben a következőképp néz ki:

Rövid koncepcionálási időszak után készülnek a tervek, majd a tervezést követően megkezdődik a gyártás és függően a projekt nagyságától egy-két hónap, esetleg fél év után megtörténik az indítás. Az eredmény pedig általában siralmas és a "szépen megtervezett, de nem túl életképes" között mozog, a termék tele vannak alap koncepcionálási hibákkal, a kiválasztott interakciós sémák a legritkább esetben vannak közelében az optimálisnak.
A Windows 7 minden idők egyik legjobb operációs rendszere a kritikusok szerint, ebben többek között az is szerepet játszik, hogy a tervezés centrikus termékfejlesztés egyik pápája, Bill Buxton-t megszerezék és újragondoltatták vele a tervezés módszertanát.
Bill Buxton pedig a következőt mondta, nincs olyan termék tervezési folyamat, amiből feltétlenül jó termék esne ki, de van olyan termék tervezési folyamat, amiből jóval nagyobb valószínűséggel fog használható termék kiesni. És ez a lényeg. Nem mindegy, hogy miként alakítod ki a terméked koncepcióját, miként tervezed meg és miként adod a fejlesztők kezébe, hogy valósítsák meg. Bill Buxton azt mondja, hogy a tervezés és koncepcionális időszakot drasztikusan növelni kell, akár a konkrét fejlesztési idő kárára is és meg kell tanulni ezt az időszakot sokkal erőteljesebben strukturálni, mérhetővé és számonkérhetővé tenni.
Az Apple-ből kiszivárgó tervezési eljárások szerint a cég elképesztő energiát tesz termékek koncepcionálásába, minden termékből alap szinten számos vázlatos koncepciót gyárt és több kiválasztott darabból olyan prototípust készít, ami már közelében van a végleges terméknek. A csapatok és a koncepciók versenyeznek az elfogadásért és sokkal több utat járnak be a koncepcionálási időszak alatt, mint egy átlagos cégnél, ahol hasonló termékeket gyártanak.
Amit a két fenti példából leszűrhetünk tanulságként, hogy a terméktervezés koncepcionálási és tervezési részét sokkal komolyabban kell venni, sokkal többet kell invesztálni a termék megfelelő modelljének megtalálására, mint abba, hogy egy adott koncepcióban milyen funkció mennyiség fogja kiszolgálni a felhasználókat. Az új modell Bill Buxton után valahogy így néz ki:

Tervezni kell, méghozzá sokat. Persze nem úgy, hogy a grafikus srác ül és tervezi a grafikákat. Nem, egy jó szolgáltatás sikeres bevezetése rengeteg üzleti paramétertől, erőforrástól és egyéb olyan dologtól függ, aminek meg kell jelennie a termékben és amire a grafikus nem feltétlenül lát rá. A részletes tervezést és a vízió között helyet kell szorítani a koncepcionális tervezésnek, amit leginkább a vázlat fogalma ír le jól. Kézirajztól a magas kidolgozottságú drótvázakon át a kattintható prototípusokig minden vázlat, ami nem a végleges termék, hanem annak bizonyos paramétereit és sajátosságait tesztelő eszköz.
Miért nem terjedt el eddig nyilvánvaló előnyei ellenére ez a modell? Mert a menedzsment output szemléletű, kódot kell tenni az asztalra és azt gondolják , hogy a koncepcionálási időszak nem strukturálható eléggé. Pedig ez egyáltalán nem igaz, nagyon is jól strukturálható, csak meg kell tanulni a megfelelő módszereket. Cserébe a szervezet kap egy játékteret, ahol rengeteg ötletet tesztelhet olcsón.
A másik legnagyobb ellenérv, hogy fix erőforrások esetén a koncepcionális tervezés az építés kárára megy. Ezzel nem lehet és nem is kell vitatkozni. Kevesebbet kell költeni gyártásra. Ha fele annyi funkció fér bele egy büdzsébe mert a tervezés időszaka kitolódott, akkor le kell vágni a funkciók rosszabbik felét. A legtöbb projekt esetében nem lenne semmiféle hiány abból, ha csak fele akkora termék készült volna. A lényeg a megfelelő funkciók megtalálása és ezek beépítése, legtöbb mai webes termék abba hibába esik, hogy a rossz funkciókat valósítja meg, rossz prioritások mentén. Vajon a Youtube-ban és a Google-ben sok funkció volt? Nem, egyáltalán nem. Ezek egyáltalán nem bonyolult termékek, az eredeti legalábbis nem. Ma már rengeteg ember dolgozik rajtuk, de induláskor egy-két egyszerű, de jól megválasztott koncepciót jól kigondolt formában tálaltak. Ezt kell megtanulni manapság minden cégnek, ha versenyben akar maradni.
Többet tervezni, kissebbet de pontosabbat célozni. A költségek nem fognak csökkenni, de úgy strukturálhatóak, hogy nagyobb valószínűséggel jöjjön létre érték.
A koncepcionális tervezés pedig a következő komoly kihívásokat támasztja az ember elé. Miként lehet koncepciókat tesztelni? Miként lehet strukturálni a koncepcionális és előkészítési folyamatot, hogy az jól tervezhető legyen? Milyen modellben érdemes csinálni, kit kell megbízni a koncepciók kidolgozásával? Többek között ezekkel a kérdésekkel fogunk foglalkozni mostanában.
Hozzászólások [0]