Vlákno názorů k článku
Vývojář si jen s programováním nevystačí

„Dobrý vývojář musí totiž znát (kromě programování) spoustu věcí“

Mít širší rozhled, nemít klapky na očích, nevidět jen ty svoje proměnné, bajty a nízkoúrovňové metody… je samozřejmě správné. ALE: ne neznamená to, že by programátor měl všechny ty věci kolem dělat (byť rozumět by jim měl).

Tady jsou totiž dva protichůdné faktory:

• Týmová práce zdržuje – e-mailování, telefonování, IM, schůzky, to všechno bere čas. Vysvětlit, co chci udělat, ostatním* zabere často víc času než kdyby si to měl člověk udělat sám. K tomu se přičítají ještě případné osobní antipatie, byrokratické procesy (kdy schvalovací proces trvá několikanásobně déle než vlastní činnost – a stejně to většinu času někomu jen leží na stole nebo ve schránce). Z tohoto pohledu je ideální renesanční člověk, všeuměl, který zvládne projekt od začátku do konce a nemusí se s nikým rozčilovat.
• Příliš mnoho činností člověka rozptyluje, „multitasking“ má velkou režii, člověk se nemůže soustředit na to, co umí nejlépe a řeší administrační věci kolem. Proto máme specializaci (které vděčíme za ekonomický růst a díky které nežijeme v jeskyních). Každý dělá to, co umí nejlépe, pak efektivně využíváme zdroje (lidi). Není dobré když vysoce kvalifikovaný zdroj (programátor) dělá věci, které může zastat sekretářka nebo nějaký brigádník, který se stará o síť, myši a tiskárny.

Než doputuje informace od zákazníka/uživatele k programátorovi, je to taková tichá pošta, na každém komunikačním rozhraní (zákazník/analytik, analytik/vývojář atd.) dochází k šumům a nedorozuměním – a také k časovým zpožděním, než se dohodne několik schůzek. Ovšem když má vývojář vstávat od rozdělané práce a sbírat požadavky od zákazníků, to je taky otrava a žrout drahocenného času. Ideálně by měl mít každý vývojář (nebo skupina vývojářů) sekretářku (někdy tuhle roli zastává projekťák), který zařídí všechno kolem a vývojář se pak může soustředit na svoji práci a výjimečně důležité schůzky, kde se řeší zásadní věci. A nemusí zabít třeba půl dne vyjednáváním o tom, aby mu síťaři povolili nějaký port na firewallu nebo popohánět jiné kolegy, aby dodali ikony nebo překlady, které měly být hotové už dávno.

Univerzální závěr z toho udělat nejde, záleží čemu dáme větší váhu, co nás víc trápí. Trochu se obávám, že budeme vždy nespokojení – každý chce to, co nemá (jako s manželstvím :-). Když budu mít problémy s analytiky a dalšími kolegy, budu se vztekat a říkat, že bych si radši všechno udělal sám a po svém. Když budu na všechno sám, budu naštvaný na to, že musím trávit čas s těmi pitomými zákazníky a vysvětlovat jim banality, což může dělat obchodník s analytikem, a já bych se mohl soustředit na programování (což nikdo jiný dělat nemůže). Prostě život je boj a trefit to optimum není vůbec jen tak.

„Samosebou, každý má možnost říct: Já jsem přeci PROGRAMÁTOR, tyhle věci za mne má řešit někdo jiný, já jsem od toho, abych programoval… Ano, ale takový ‚programátor‘ je něco jako dělník u pásu – ráno přijde do práce, osm hodin dělá to, co má v pracovní návodce, a pak jde domů.“

S tím si dovolím nesouhlasit – šéf směny v montovně si klidně může stoupnout k pásu a montovat, mistr na stavbě nebo v dílně může vzít rozdělanou práci po učňovi a dodělat ji (dokonce často lépe než on). Ale dokáže si manažer (nebo projekťák, obchodník, analytik, tester…) stáhnout zdrojáky aplikace a pokračovat v práci programátora, který odešel? Někdy ano, zažil jsem takové dva (nebo spíš jeden a půl), ale většinou to v IT neplatí a manažeři umí řídit a všechno kolem, ale programovat neumí (v lepším případě už to zapomněli, v horším to nikdy neuměli). To je v pořádku – každý má nějakou specializaci, ale není to vztah jako na té stavbě nebo v dílně či montovně u pásu.

*) ať už to jsou podřízení nebo někdo další v řetězci (např. analytik → vývojář → tester), nebo kolegové z jiných odděleních (síťaři, po kterých něco chci).

Drzá poznámka: pokud mi trvá déle vysvětlit někomu, co chi, než si to udělat sám, pak je to moje chyba, neumím vysvětlovat.

1. Na komunikaci musí být vždy dva.
2. Ne vždy je to o tom, že by ten druhý (nebo první) byl hloupější a špatně chápal (vysvětloval). Dobře vidět je to třeba na testování – vývojář už do problematiky zasvěcený je, ví, jaký je smysl programu, ví, jak se má chovat… ale tuhle znalost je potřeba předat* testerovi a až potom může testovat. Kdyby testování prováděl přímo vývojář, tak odpadne nutnost ty znalosti externalizovat a vložit je do hlavy jiného člověka, otestováno by pak bylo během chvilky. (Ovšem v tomhle případě je nepřijatelné, aby celou práci dělal jeden člověk, protože je potřeba, aby kontrolu prováděl někdo jiný než vlastní práci.)

Podobné je to se sběrem požadavků – potřeby zákazníka musí pochopit** nejdřív analytik a pak je musí nějak předat vývojáři – tzn. nějak explicitně je formulovat, převést z myšlenek ve své hlavně na papír nebo aspoň na mluven slova. A vývojář tohle zase musí dostat do svojí hlavy, pochopit. Na druhou stranu analýza nespočívá jen v předání požadavků 1:1*** a není dobré plýtvat časem programátora na to, co může dělat analytik (a vice versa).

*) je celkem jedno, zda to dělá vývojář, nebo analytik, nebo si to sám tester čte z analýzy/zadání. Dostat ty znalosti do hlavy dalšího člověka (testera) stojí čas v každém případě.

**) nebo lépe řečeno je z něj vydolovat

***) byť to tak někdy bývá

V článku je pěkně odděleno Programátor vs. Vývojář.

To je, přiznejme si, tak trochu hraní se slovíčky. Jistě, můžeme si říkat honosněji „vývojář“ místo „programátor“ nebo „kodér“, ale v principu je to totéž – člověk, který vytváří programy, píše zdrojový kód. Sice se o někom říká „to je jen kodér“ nebo „to je pan Vývojář“, ale je to vlastně jen nějaké citové zabarvení, které té větě chceme dát – práce je to stejná – jen někdo je zkušenější, druhý méně zkušený, někdo šikovnější, druhý méně šikovný. Profesi mají stejnou, znalosti a odborné kvality různé (ale to ještě není důvod je kastovat na dvě skupiny). Vyšší/jinou kategorií je až SW architekt nebo třeba programátor-analytik, který může dělat jak programování, tak analýzu, v podstatě člověk, který má dvě profese.

A pak jde ještě slovo vývojář chápat jako „člen vývojového týmu“ tzn. včetně testerů, analytiků, projekťáků atd.  – prostě ta část ajťáků, která se nezabývá provozem, ale vývojem nového.

K té tiché poště, nemáte úplně pravdu. Cílem není přeformulovávat požadavky zákazníků, ale filtrovat je. Tedy pokud se ke mě jako k programátorovi dostane požadavek od uživatele / zákazníka, zpravidla mám k dispozici veškerý záznam komunikace s helpdeskem, takže tam vidím, co říkal zákazník, jaké kroky zkusil helpdesk, co k tomu dopsal senior, a podobně. Mohu přímo formulovat formulovat dodatečný dotazy, či případně zjistit, na čí straně byla chyba (ne vždy se helpdesk zeptá správně, a kolikrát častěji „školíme“ lidi na helpdesku, než opravujeme chyby uživatelů :-)

Jistě, viz „analýza nespočívá jen v předání požadavků 1:1“. K filtrování, prioritizaci, upřesňování atd. samozřejmě dochází, ale zároveň tu s každým krokem je i ten efekt „tiché pošty“, kdy se část informace ztrácí, nebo se odchyluje od původního významu. Což může být mimochodem dobře i špatně – Jednak analytik může objevit i ty potřeby zákazníka, které sám zákazník nedokáže formulovat (a vývojář by je z něj nedostal). A jednak každý vidíme věci trochu jinak, stejná slova chápeme trochu jinak, máme jiné výchozí znalosti, někdy i jinou logiku… a význam sdělení se posouvá. Podobně to funguje i vertikálně – v organizační struktuře – např. než doputuje nějaké opatření od ministra až k úředníkovi na přepážce… :-)

Trochu se obávám, že budeme vždy nespokojení…

Já bych se toho nebál – vždyť nespokojenost je to, co nás žene dál ;-)