Komunikace je důležitá

Nedávno jsme měli v práci opravdu kritickou situaci. Nasazovali jsme nový release aplikace a při tom se vloudila chybička. Ta nic ošklivého sice neprovedla, ale naneštěstí za ní následovala další, která kvůli té první už ano. Zničehonic jsme se dostali do pěkně ošklivé situace, ze které se nešlo dostat zpět. Aspoň ne jednoduše a bez újmy. I přesto, že jsme se pečlivě připravovali a promýšleli různé scénáře…

Co se dalo dělat. Muselo se to prostě dokončit a dostat do co nejlepšího stavu. Zůstali jsme tedy v práci o „něco“ déle a snažili se to dát do pořádku. Byla to rušná noc a po pár hodinách spánku i krušné ráno. Vlastně ještě několik dalších dní. Nic příjemného.

Proč to ale píšu – po každé takové situaci se snažím ohlédnout zpět a najít chyby, kterých jsem se dopustil. Po takové situaci jsou totiž vidět nejlépe mezery, které je potřeba eliminovat. A těmto chybám se příště, pokud možno, vyhnout velkým obloukem.

Ohlédl jsem se i nyní a našel u sebe nedostatek v komunikaci. Ne, že bych měl problém mluvit nebo tak podobně, ale spíš problém se přesně vyjádřit. Aby když popíšu hrníček na kávu, aby si spolukonzultant představil přesně ten samý hrníček jako já.

Hodně dobře problém dvojznačnosti popisuje ukázka z knížky The Cleaner Coder: A Code of Conduct for Professional Programmers od Robet C. Martin:

Sam (stakeholder): “OK, now these log files need to be backed up.”
Paula: “OK, how often?”
Sam: “Daily.”
Paula: “Right. And where do you want it saved?”
Sam: “What do you mean?”
Paula: “Do you want me to save it a particular sub-directory?”
Sam: “Yes, that’d be good.”
Paula: “What shall we call it?”
Sam: “How about ’backup’?”
Paula: “Sure, that’d be fine. So we’ll write the log file into the backup directory every day. What time?”
Sam: “Every day.”
Paula: “No, I mean what time of day do you want it written?”
Sam: “Any time.”
Paula: “Noon?”
Sam: “No, not during trading hours. Midnight would be better.”
Paula: “OK, midnight then.”
Sam: “Great, thanks!”
Paula: “Always a pleasure.”

Later, Paula is telling her teammate Peter about the task.

Paula: “OK, we need to copy the log file into a sub-directory named backup every night at midnight.”
Peter: “OK, what file name should we use?”
Paula: “log.bakckup ought to do it.”
Peter: “You got it.”

In a different office, Sam is on the phone with his customer.

Sam: “Yes, yes, the log files will be saved.”
Carl: “OK, it’s vital that we never lose any logs. We need to go back through all those log files, even months or years later, whenever there’s an outage, event, or dispute.”
Sam: “Don’t worry, I just spoke to Paula. She’ll be saving the logs into a directory named backup every night at midnight.”
Carl: “OK, that sounds good.”

Ukázku zvěřejňuju s laskavým svolením autora

Jak je z ukázky dobře vidět, oba se domluvili, oba byli spokojení, ale každý si to představil jinak. Sam, stejně jako zákazník Carl, měl na mysli zálohu každého dne, ale Paula to pochopila jako zálohu jen za poslední den. Bylo by velmi nešťastné, kdyby na to přišli až v produkčním nasazení.

Proto je potřeba se takových situací vyvarovat. Asi nejlépe to jde s akceptačními testy, jak posléze popisuje ve zmíněné knize Robert C. Martin. O těch se ale nebudu rozepisovat – přečtěte si knížku, anebo si akceptační testy vyguglete. Chci ukázat, jak může jednotlivec pomoct v obraně proti nejednoznačnosti (bez nutné aktivní účasti dalších lidí).

Poměrně jednoduše to lze pomocí odlehčených akceptačních testů. Například zrovna dnes jsem něco takového udělal: potřeboval jsem si ověřit, že vývoj nové funkcionality souhlasí se zadáním. Jednoduše jsem si proto přivolal zadavatele a poprosil, zda se může podívat na polotovar. Zda je to takhle OK. Ještě, že jsem to udělal! Nebyla tam nějaká drobná nejasnost, ale poměrně zásadní. Upravovat to později by mě stálo zbytečně dost času navíc. A hlavně firmu zbytečně více peněz.

Stále se ale může stát, že k nejednoznačnosti dojde a dělá se zbytečná práce. Proto je dobré být neustále na pozoru – hledat možné nesrovnalosti a případně si je ihned vyjasnit. Jako dobrá pomůcka si mi osvědčilo si po přečtení nebo vyslechnutí požadavku celý problém znovu projít, popsat ho svými(!) slovy, sdělit je zpět zadavateli a nechat si potvrdit, že vše souhlasí. Případně si o tom ještě promluvit.

Podle zkušeností mohu říct, že tyhle dvě pravidla pomohou snížit „ambiguity“ na minimum. Bohužel to je jen pro přijímání zpráv. Opačně se musí (pro jistotu) předpokládat, že si druhá strana nejednoznačnosti nevšimne, a podle toho se vhodně vyjadřovat. A to je přesně to, co mi zatím moc nejde a na čem musím zapracovat. Snad nebude dlouho trvat a budu psát pokračování k tomuto článku s ověřenými tipy, jak na to. :)