Vývojáři, víte, proč vám váš CEO bere práci, a proč je to dobrá věc?

Stále více se cpeme do vašeho kódu. My, markeťáci, produkťáci, šéfové firem. Prostě netechničtí lidé. Občas z toho máte bolehlav, to je jasné. Ale nevyhnete se tomu.

V tomto textu jdu nastínit, co je naší motivací a proč vám můžeme být prospěšní.

Jak už víte, k právě probíhající AI revoluci mám střízlivý přístup. Nemyslím si, že zahubí SaaS. Nemyslím si, že vývojáři skončili. Nemyslím si, že nastává konec světa.

Některé věci se ale brutálně mění, například vývoj produktů.

Na meetupu Frontendisti.cz jsem ukazoval, proč vám váš CEO bere práci. Nepadlo tam ale vše, co padnout mělo, takže to teď jdu článkem doplnit a obohatit o širší kontext.

Další hyperproduktivní vajbící manažer

Jsem ten typ CEO, který chce chápat a umět to zásadní, co se ve firmě řeší. A když je potřeba pohnout, vyhrne si rukávy a jde makat. Myslím v kódu, více ode mě nečekejte. Navíc ještě donedávna aktivně weby vyvíjel.

Pomocí vibe-codingu, nebo agentního vývoje chcete-li, jsem vytvořil několik aplikací, které můžu sám používat a šetří mi čas. Tohle je asi jasné.

Nyní ale ve firmě máme za sebou první úspěšné pokusy pustit mě přímo do kódu našeho hlavního produktu v PageSpeed.ONE.

V rekordním čase a s rozumnými náklady máme nový web, připravili jsme novou aplikaci na měření rychlosti webu a tak dále. Není to dokonalé, ať už jde o výstupy navenek nebo v kódu a proces samotný, ale hlavní cíle to plní a extrémně to zrychluje iterace.

Proč je často nejlepší varianta, abych appku, rozšíření webu nebo fíčuru udělal já?

Ten hlavní argument je efektivita. Během času, který by mi zabralo vytvoření zadání a management dané věci, tu danou věc vyrobím.

Ale jsou tady i další argumenty.

Proč si myslím, že účast netechnických lidí v kódu je pro vývojáře dobrá věc?

Když vám CEO, produkťák, markeťák leze do kódu dobře, vývojářům to může přinést mnohé:

• Hmatatelný prototyp místo dlouhého zadání.
• Rychlejší rozhodnutí a méně komunikačního ping-pongu.
• Méně „překladů“ kontextu přes mnoho lidí.

A pak je tu ještě jeden důvod. Jsou to přesahy.

Jako CEO bych měl vědět, co chtějí klienti, protože jsem s nimi v kontaktu. Vím, kde máme argumentační mezery, znám celý kontext našeho produktu. Mám povědomí o marketingu nebo jej sám částečně dělám. Dělám sales, accounta, trošku finance, docela hodně produkt, musím umět naší specializaci, takže oblast rychlosti webu… A to je kombinace, která mi umožní generovat kód prospěšný produktu.

Nejsem nejlepší, co se týká kvality kódu, to obstarají jiní (a dobře nastavené procesy), ale do kódu předávám pohled, který tam předtím mohl chybět.

Do velké míry to souvisí se specializací nebo jejím opakem, takže budováním znalostí spíše do šířky než do hloubky. Jako CEO musím být generalista.

Hloubka vs. šířka znalostí lidí v týmech

Na tomhle obrázku/grafu je jednoduchá manažerská metafora pro hloubku vs. šířku znalostí:

Co vidíte na obrázku?

• Svisle je hloubka znalostí, takže jak moc jdete do detailu v jedné disciplíně.
• Vodorovně je šířka znalostí, takže kolika sousedním oblastem rozumíte natolik, že se v nich neztratíte a umíte je propojit do výsledku.
• Pokud jste „I-shaped“, rozumíte skvěle jedné věci, ale ty ostatní vám unikají. Pokud jste „T-shaped“, rozumíte skvěle jedné věci, ale zároveň máte obecné povědomí i o těch ostatních. A tak dále.

V malých týmech se obvykle lépe uplatní lidé s více přesahy, ale obecně zde není žádná definice dobrého nebo špatného „tvaru dovedností“. Je úkolem každého člověka (a jeho manažera) své dovednosti znát nebo posunovat tak, aby dobře fungovaly v daném týmu.

Extrémní příklad I-shaped může být člověk specializovaný čistě jen na frontendový vývoj. Nebo ještě hůř – jen na CSS, ehm… Nastínil jsem to na obrázku tady:

CEO firmy je druhý extrémní příklad, protože ten by naopak neměl být specialista, ale mít co nejširší záběr dovedností. Na svém příkladu jsem to ukazoval takto:

Pro to, aby vznikl jakýkoliv digitální produkt, je potřeba něco vědět nejen o produktu, UX a vývoji, ale také o vedení a strategii firmy, lidech v ní, financích a nejlépe i marketingu.

Všechny tyto dovednosti a kontexty musejí ve firmách probublat přímo k lidem, kteří mají konečné zhotovení produktu na starosti, tedy k vývojářům.

Obvykle se to děje pomocí různých zadání, dokumentací, firemních strategií, ale také schůzek nebo méně formálně, v hospodě či firemní kuchyňce.

To, že celý ten kontext máte v hlavě, znamená, že když dostanete možnost snadno konkrétní věc vyrobit, budete velmi efektivní.

No a tou možností se stala AI revoluce, která komoditizuje a tedy brutálně zlevňuje některé části vývojařiny.

Produkt mám hotový v čase, který je nižší než čas na zadání a management…

Agentní vývoj je dneska tak daleko, že když se to udělá opatrně (a CEO je bývalý vývojář), funguje to velmi dobře. Tohle jsou přesně důvody, proč se kód začíná otevírat i lidem mimo engineering:

• Prototypování je dneska dostupné prakticky všem a skoro zadarmo.
• Zlevnila se realizace některých částí aplikací.
• Není potřeba tolik zadávání, handoffů a feedback koleček.

…ale když se dobře nedomluvíme, můžu celý produkt zničit

Ale jasně, vývojáři, slyším vás. Špatně nastavené procesy nebo jejich nedodržování těmito netechnickými lidmi může přinést katastrofu:

• Obcházení procesů (PR bez code review).
• Změny bez znalosti architektury, které jdou proti ní.
• Sahání na místa, kde může vzniknout nebezpečná úprava.

Tohle je jedna z výzev, kterým nyní čelí produktové, ale i agenturní týmy. Změna pracovních postupů a technologického stacku, která umožní, aby se netechničtí lidé mohli zapojovat do práce na produktech.

Myslím si ale, že Pandořina skříňka je otevřená a zavřít ji už nemůžeme. Příspěvky netechnických lidí do kódu se dít budou a vývojáři se s tím budou muset vypořádat.

Děje se vám to ve firmě taky? Jak to řešíte? Diskutujme na LinkedInu, Facebooku nebo na síti X.