Az első okosotthon projekt különös helyzet. Addig lehet, hogy már van egy jól összerakott folyamatod. Tudod, hogyan érdemes igényt felmérni, rendszerlogikát építeni, ajánlatot adni, dokumentálni, kivitelezni és átadni.
Papíron ez szépen hangzik.
Aztán egyszer csak ott van előtted egy valódi projekt.
Valódi ügyféllel. Valódi házzal vagy lakással. Valódi igényekkel. És kompromisszumokkal.
És hirtelen már nem az a kérdés, hogy van-e folyamatod. Hanem az, hogy mit kezdesz vele, amikor a projekt nem pontosan úgy viselkedik, ahogy előre elképzelted.
Ezért nehéz az első projekt.
Nem azért, mert lehetetlen. Hanem azért, mert ekkor derül ki először, hogyan működik a meglévő folyamatod valós döntésekkel és nem várt helyzetekkel.
A folyamat papíron más, mint éles projektben
Egy jól felépített folyamat nagyon sokat segít.
De a valós projektben ritkán történik minden elsőre tankönyvszerűen. Ezért az első projekt előtt nem csak arra érdemes felkészülni, hogy mi a következő lépés. Arra is, hogy milyen helyzetek boríthatják meg a tervet.
Ilyenkor a folyamat önmagában nem old meg mindent. De segít abban, hogy ne kapkodásból reagálj, hanem vissza tudd nézni, mi volt az eredeti cél, mi változott, mit érint a változás, és mit kell újra tisztázni.
A helyszínen mindig van meglepetés
És erre jön rá az, amit papíron a legnehezebb előre érezni: a helyszíni valóság.
- Lehet, hogy nincs áram, amikor odaértek.
- Lehet, hogy a szerelvények máshová kerültek, mint ahová a terven vagy az egyeztetésen kerültek volna.
- Lehet, hogy a kiválasztott eszköz nem fér el a dobozban, vagy nincs elég hely a modulnak és a kötésnek.
- Lehet, hogy az ügyfélnek nem tetszik a szerelvény színe, formája vagy kinézete.
- Lehet, hogy a WiFi vagy a rádiós jel nem úgy működik a helyszínen, mint ahogy papíron várható volt.
- Lehet, hogy valaki már módosított a villanyszerelésen, de ez csak akkor derül ki, amikor dolgozni kezdenél.
- Lehet, hogy az ügyfél azt mondja: „ha már itt vagytok, ezt is meg lehetne oldani?”
Ezek nem különleges kivételek. Ezek nagyon is valós projekthelyzetek. Idővel ezekre is lesz folyamatod, de nem biztos, hogy mindenre gondoltál előre
És az első projektben pont az a nehéz, hogy egyszerre kell kezelni a szakmai részleteket, az ügyfél elvárásait és ezeket a helyszíni apróságokat, amelyek nagyon gyorsan nagy döntésekké nőhetnek.
Mire kell felkészülni az első valós projektben?
Arra, hogy az ügyféligény változhat.
Arra, hogy amit az ügyfél egyszerűnek mond, szakmailag több döntést igényel.
Arra, hogy egy helyszíni adottság korlátozza az eredeti elképzelést.
Arra, hogy egy új kérés nem csak egy plusz eszközt jelent, hanem érintheti az ajánlatot, a dokumentációt, a kivitelezési sorrendet és az átadást is.
Arra, hogy bizonyos dolgokat újra kell egyeztetni, még akkor is, ha első körben már lezártnak tűntek.
Arra, hogy lesznek pontok, ahol nemet kell mondani, vagy külön munkaként kell kezelni egy módosítást.
Az első projektben az a nehéz, hogy ezeket még nincs miből rutinszerűen felismerni.
A nem várt helyzetek mutatják meg, mennyire áll össze a projekt logikai felépítése
Az első projektben sok minden csak akkor válik igazán konkréttá, amikor már nem példáról beszélünk.
Mit vállalsz be, és mit nem?
Mikor kell újra tisztázni az ügyféligényt?
Mikor kell módosítani a rendszerlogikát?
Mikor maradhat az eredeti elképzelés, és mikor kell elengedni?
Hol húzod meg a projekt határát?
Ezek azok a döntések, amelyek egy éles projektben nap közben, helyszínen, egyeztetés közben vagy ajánlatírás előtt jönnek elő.
És pont ezért nehéz az első projekt.
Mert a folyamat nem helyetted dönt. Csak abban segít, hogy amikor jön egy eltérés, legyen mi alapján visszanézni: mi volt a cél, mi változott, mit érint, és mit kell újra tisztázni.
Könnyű visszacsúszni eszközszintre
Amikor jön egy nem várt helyzet, nagyon könnyű rögtön eszközben gondolkodni. Akkor legyen másik relé. Akkor kell még egy szenzor. Akkor oldjuk meg másik vezérléssel. Akkor tegyünk be egy új funkciót.
Néha tényleg ez a megoldás.
De sokszor előbb vissza kell menni egy lépést.
Mi volt az eredeti ügyféligény? Milyen működési helyzetet akarunk kiszolgálni? A módosítás illeszkedik a rendszerlogikába? Vállalható lesz később is? Dokumentálható? Átadható?
Az első projektben ez az egyik legnagyobb kihívás. Nem szabad elveszni az eszközökben, amikor valójában a projektlogikát kell újra tisztázni.
A projekt dokumentáció ilyenkor nem adminisztráció
Sokan a dokumentációt felesleges adminisztrációnak érzik.
Pedig az első projektben inkább kapaszkodó. Segít visszanézni, hogy miből indultatok ki, milyen működéseket kellett kiszolgálni, milyen döntések születtek, mi maradt nyitva, és hol változott a projekt.
Ez különösen akkor fontos, amikor valami nem várt dolog történik.
Ha nincs dokumentáció, minden fejben marad. Ilyenkor könnyű úgy módosítani, hogy közben szétesik az eredeti logika.
Ha van dokumentáció, van mihez visszanyúlni. Nem azért, hogy mereven ragaszkodj hozzá. Hanem azért, hogy tudd, mit módosítasz, miért módosítod, és milyen következménye lesz.
A lényeg: nem minden helyzet új, csak elsőre annak tűnik
Az első projektben sok váratlan helyzet azért ijesztő, mert még nincs saját példatárad hozzá. De ettől ezek nem egyedi, megoldhatatlan esetek. Ezekre fel lehet készülni.
Nem úgy, hogy mindenre előre kész válaszod van. Hanem úgy, hogy felismered, milyen típusú helyzettel állsz szemben, mit érint a változás, mit kell újra tisztázni, és mihez kell visszanyúlni a projektvázlatban.
Ez nem látványos rész. De ettől marad egyben az első projekt.
Nem attól, hogy nem lesz benne meglepetés, hanem attól, hogy a meglepetés nem viszi el az egész projektet eszközszintű kapkodásba.
Pesze később sem lesz felesleges a dokumentáció, amikor már sok projekten dolgoztál, csak átalakul a funkciója, hiszen több év projektjét lehetetlen észben tartani, pedig a hosszútávú support miatt szükséged lesz rá, különösen ha már nem (csak) te mész a terepre, hanem a csapatod.
