Rozpor mezi kreativitou v týmu a dodržováním technologické disciplíny při tvorbě SW (a jaké je řešení)

Jednou z nejvíce kreativních lidských činností je určitě tvorba SW. Programátor jako meta-tvůrce systému určuje, jak bude jeho virtuální svět vytvořen a jak bude vypadat. Při týmové práci (což výroba SW většinou bývá) se ale na druhé straně  vyžaduje dodržování tzv. technologické disciplíny. Ta naopak ale brzdí kreativitu. Dodržování technologické disciplíny je však určitě nezbytné, protože při jejím porušování se nám celý projekt rozsype jako domeček z karet.

Otázkou je, jak tento rozpor „kreativita versus disciplína“ při tvorbě SW vyřešit, aniž by ani jedna z těchto dvou zdánlivě protichůdných vlastností nebyla narušena?

Příklad na porušení technologické disciplíny

V této souvislosti vzpomínám s úsměvem na jednu historku.

Málokdy se mi stane, že bych se tak rozčilil, že bych musel vyjít ven z místnosti, napočítat do deseti a pak se vrátit a v klidu situaci dořešit. V tomto příběhu jsem to ale udělat musel …

Měli jsem jednání v bance jako dodavatelé informačního systému, který uměl poskytovat služby klientům přes SMS zprávy.

Jako hlavní analytik seznamuji pracovníky v bance s analytickým návrhem, zda s tím souhlasí: „Víme, že ideální řešení by bylo, kdyby každý klient měl pod sebou v evidenci dva nezávislé seznamy: Jeden seznam jeho telefonů a jeden seznam jeho služeb. Mohl by tak využívat libovolnou službu ze seznamu jeho služeb z libovolného telefonu ze seznamu jeho telefonů. My to ale v této první verzi máme jednodušší: Klient nemá přímo seznam telefonů, ale každá služba má telefon jako svůj atribut. Takže klient má pouze seznam nabízených služeb a telefon je přímo v ní jako její atribut. Jinak by to byl problém malinko složitější, protože ne každý telefon může podporovat libovolnou službu, takto to ošetříme přímo u dané služby. Není to úplně nejlepší, ale je to pro první verzi velice jednoduché.“

Dotaz z banky: „Jaké to má důsledky?“

Odpověď: „Za prvé, pokud klientovi přidáte telefon, tak mu pro něj musíte přidat službu i pro tento telefon…a tu mu zpoplatkujete.“

„To nám nevadí, naopak.“

„A za druhé, pro každou službu se může daný telefon opakovat, takže obsluha při zadávání služeb musí telefon znovu zadat, což je ale řešeno buď hromadně anebo implicitní nabízenou hodnotou, aniž by to obsluha ťukala znovu a znovu.“

„To nám taky nevadí, to obsluha zvládne.“

Řešení bylo takto odsouhlaseno zákazníkem a takto se objevilo i ve funkční specifikaci.

Asi tak za měsíc jdu kolem programátora juniora, bavíme se, koukám mu přes rameno do monitoru a vidím formulář „Editace klienta“, uvnitř listbox se seznamem jeho telefonů… Tuším zradu.

Ptám se: „Co je to tady toto, ten seznam telefonů?“ Ještě si v duchu říkám, možná vytáhl telefony ze služeb jako unikátní SELECT, ale v zadání to nebylo.

„No přece seznam telefonů.“

„To vidím, ale odkud jej máš?“

„Přece z tabulky telefonů.“

„Kde je nějaká tabulka telefonů?“ ptám se udiveně.

„No přece v databázi.“

„Tam žádná taková tabulka není.“

„Je.“

Otevřeme model databáze a vidím, má pravdu: Tabulka telefonů, v ní cizí klíč ID_CLIENT. Hned je mi jasné, že se jedná o onen zamítnutý analytický model „Klient má svůj seznam telefonů“…

Ptám se už trochu podrážděně: „Kde se tady ta tabulka vzala? Kdo ji tam dal?“

A junior odpověděl s nevinným výrazem: „No, já.“

„A proč…jak jsi mohl?“

„No, takto je to přece lepší!“

To byla ta chvíle, kdy jsem vypochodoval z místnosti, napočítal do deseti, uklidnil se a vrátil se zpátky s pokynem „předělej to“.

Problém byl v tom, že nejenom že zákazník odsouhlasil jiné řešení, ale navíc toto jiné řešení nebylo vůbec promyšleno se všemi logickými důsledky. A k tomu ještě poznámka: Všichni účastníci projektu (testování, tvůrce helpu, obchodníci atd.) už počítali s tímto návrhem a začalo se i citovat v paralelní dokumentaci.

Evidentně se jednalo o případ porušení technologické disciplíny.

Jak měl tedy programátor postupovat správně? Pokud si dotyčný programátor všiml, že by se někde hodilo lepší řešení, nebo dokonce narazí na chybu, tak měl jít a nahlásit to jako jinou lepší nebo správnou verzi řešení. A musím dodat, že i když jsme to už kdysi projednávali (a on o tom z nějakého důvodu nevěděl), tak by byl za tu iniciativu pochválen s tím, že to v příští verzi určitě bude…

Problém nutné disciplíny při zachování kreativity

Na druhé straně je jasné, že kreativitu v týmu nelze ubíjet nevhodně nasazenou disciplínou tam, kde by škodila. Vývojáři by se měli podílet na kreativní práci tvorby SW a to včetně programátorů. Kde je tedy ona jasná hranice, kdy kreativitu podporovat a kdy naopak vyžadovat disciplínu?

A hlavně jakými postupy a prostředky dosáhnout symbiózy těchto dvou přístupů?

O tom bude další pokračování článku.



Categories

About the Author:

správce a majitel Serveru objektových technologíí http://www.objects.cz

0 Comments
0 Pings & Trackbacks

Leave a Reply