Sok okosotthon projekt fejben úgy indul, hogy valaki elkezd eszközöket sorolni.
Kell pár okoskapcsoló, néhány érzékelő, termosztát, redőnyvezérlés. Kell központ. Kell applikáció. Legyen világítási jelenet, fűtésvezérlés, jelenlétérzékelés, pár automatizálás.
Ez így elsőre logikusnak tűnik. Csak éppen nem innen kellene indulni.
Az eszközlista ugyanis nem a projekt kezdete. Az eszközlista következmény.
Egy jó okosotthon projekt nem azzal kezdődik, hogy mit építünk be. Hanem azzal, hogy megértjük, mire van valójában szükség.
Az ügyfél sokszor nem igényt mond, hanem megoldásötletet
Amikor egy ügyfél azt mondja, hogy „okos világítást szeretnék”, az még nem egy pontos igény.
Lehet, hogy azt szeretné, hogy este ne kelljen kapcsolókat keresni. Lehet, hogy hangulatvilágítást akar. Lehet, hogy a gyerekek mindig égve hagyják a lámpát. Lehet, hogy biztonsági célja van. Lehet, hogy egyszerűen látott egy videót, és megtetszett neki.
Ugyanaz a mondat sokféle valós igényt takarhat.
Ha rögtön eszközlistát írsz, akkor könnyen lehet, hogy technikailag megoldasz valamit, ami nem is a valódi probléma volt.
Ezért az okosotthon projekt első lépése nem az eszközválasztás, hanem a kérdezés. Mit szeretne az ügyfél könnyebbé tenni? Mi zavarja most? Mit használ naponta? Mi az, ami automatizálva tényleg segítség lenne? Mi az, ami csak látványos, de nem fontos?
Ezek nélkül az eszközlista csak találgatás.
A technológia csak akkor jó, ha használati helyzetből indul
Az okosotthon nem attól lesz jó, hogy sok eszköz van benne. Attól lesz jó, hogy a rendszer illeszkedik az ott élők szokásaihoz.
Egy családi házban teljesen más logika működik, mint egy lakásban. Egy kisgyerekes család máshogy használja az otthonát, mint egy egyedül élő felnőtt. Egy új építésű ház más lehetőségeket ad, mint egy felújítás. Egy technológia iránt lelkes ügyfél mást fog elfogadni, mint valaki, aki csak azt szeretné, hogy „működjön, és ne kelljen vele foglalkozni”.
Ha ezt nem érted meg az elején, akkor könnyen túltervezel vagy alultervezel.
Túltervezésnél az ügyfél olyan rendszert kap, amit nem használ ki, nem ért, vagy később bonyolultnak érez.
Alultervezésnél pedig hamar kiderül, hogy a rendszer nem tudja azt, amire valójában szükség lenne.
Mindkettő ugyanoda vezet: elégedetlenséghez.
Az ajánlatadás előtt kell tisztázni a határokat
Az okosotthon projektek egyik legnagyobb csapdája, hogy a feladat határai könnyen elmosódnak.
Mi tartozik bele a projektbe? Mi nem? Ki adja az eszközöket? Ki végzi a villanyszerelési munkát? Ki állítja be az automatizációkat? Mi történik, ha az ügyfél később módosítást kér? Mi számít hibának, és mi új igénynek?
Ha ezek nincsenek tisztázva, akkor a projekt közben feszültség lesz. Nem feltétlenül azért, mert bárki rosszindulatú. Sokszor egyszerűen azért, mert mindenki mást értett ugyanazon a mondaton. Az ügyfél azt hitte, „ez még benne van”. A kivitelező azt hitte, „ez már pluszmunka”.
Ezt nem a projekt végén kell megbeszélni, hanem az elején.
Dokumentáció nélkül a projekt fejben marad – vagy mág ott se
Egy okosotthon projektben rengeteg apró döntés születik. Melyik kapcsoló mit vezérel? Milyen jelenetek vannak? Mi történik mozgásra? Mi történik éjszaka? Mi történik áramszünet után? Milyen logika alapján működik a fűtés, a világítás, az árnyékolás?
Ha ezek csak fejben vannak meg, akkor a projekt törékeny. Nehéz átadni., módosítani, visszakeresni, elmagyarázni. És ha más is belép a munkába, ő sem fogja látni, mi miért úgy lett megoldva.
A dokumentáció nem adminisztrációs nyűg. Hanem a projekt egyik védőrétege.Nem kell túlbonyolítani. De legyen világos, mit vállaltál, milyen logika szerint épül fel a rendszer, és hogyan lehet később hozzányúlni.
Az eszközlistának megvan a maga ideje
Természetesen egy okosotthon projekthez eszközök is kellenek. De jó eszközlistát csak akkor lehet írni, ha előtte tiszta az igény, a használati helyzet, a rendszerlogika és a vállalási keret. Máskülönben az eszközlista nem terv, csak bevásárlólista. A bevásárlólista pedig ritkán old meg valódi projektproblémát.
Egy jó okosotthon projektben először megérted az ügyfelet, utána megérted a használati helyzeteket, utána kialakítod a rendszerlogikát, utána tisztázod a kereteket, és csak ezután választasz eszközöket.
Ez lassabbnak tűnik, mint rögtön termékeket keresni.
De hosszú távon sokkal stabilabb.
Mert az okosotthon projekt nem az eszközlistával kezdődik. Hanem azzal, hogy megérted, mit kell a rendszernek valójában szolgálnia.
