Když se řekne „produktový vývoj“, většina lidí si pořád představí větší tým, spoustu rolí, plánování, handoffy a čekání na to, až bude něco dost hotové na ukázku.
Na Harrym si ale ověřujeme, že to jde i jinak.
HarryApp je aplikace pro realitní makléře. A dnes na něm pracujeme ve dvou lidech: já a Udaya.
To samo o sobě není pointa. Pointa je v tom, jakým způsobem ten produkt stavíme.
Nejdřív lidé
S Udayou jsme spolu dřív pracovali asi rok v Grouponu. Patřil tehdy mezi šikovné a proaktivní vývojáře. Později z Grouponu odešel a dal si přibližně půlroční pracovní pauzu.
Když jsem pak jel do Indie školit nový způsob vývoje přes Encore, znovu jsme se potkali. Ukázal jsem mu HarryApp, představu produktu i způsob, jak bych ho chtěl stavět. Ta myšlenka ho zaujala. Po návratu do Prahy a dohodě s cofounderem Danielem Helclem jsme ho vzali do týmu.
Daniel Helcl je mimochodem člověk, se kterým se známe už z dřívějška. Před HarryApp jsme spolu působili v topite.cz, později ve Woltairu, kde byl Dan spoluzakladatel a hledal někoho, kdo povede vývoj. Tuhle roli jsem tehdy převzal jako CTO.
Tenhle předchozí společný kontext je důležitý, protože HarryApp nevzniká mezi lidmi, kteří se poznali teprve před měsícem. Staví na důvěře, předchozí zkušenosti a společně zažitých lekcích z předchozí firmy.
Na projektu začal Udaya pracovat v prosinci. Já jsem se k němu naplno přidal v lednu po odchodu z full-time role v Grouponu.
Tenhle detail je důležitý, protože HarryApp není jen příběh o technologii. Je to i příběh o přenosu zkušenosti a o tom, jak se dnes dá stavět produkt s malým týmem a vysokou pákou.
Co znamená „ve dvou lidech“
Neznamená to, že všechno děláme ručně a lineárně od rána do večera.
Znamená to, že:
- držíme malý tým,
- pracujeme po menších změnách,
- rychle si předáváme kontext,
- používáme AI jako páku tam, kde to dává smysl,
- a soustředíme se na to, aby systém zůstával průběžně použitelný.
To je podle mě zásadní rozdíl oproti představě, že produktový vývoj je automaticky otázka velkého týmu.
Co je vidět přímo v repozitáři
Na Harrym je dobré to, že se o něm nemusí mluvit jen abstraktně. Reálný repozitář ukazuje velmi konkrétní stopy toho, jak tenhle způsob práce vypadá.
V repozitáři je během krátkého období vidět, že se produkt hýbe ve více vrstvách najednou. Vedle sebe tam jsou například změny jako:
- refactoring iOS formulářů a detail view pro lepší end-user UX,
- zobrazení contact a property jmen v iOS submission rows,
- backend utility pro contact display a refactoring notifikací,
- AI-triggered phone calls,
- inline editing ve webových taskách,
- lokalizované backend messages,
- opravy backend testů,
- a průběžná dokumentace a automatizační zázemí.
To je důležité proto, že to ukazuje několik věcí najednou:
- produkt se hýbe napříč backendem, webem i iOS,
- změny nejsou soustředěné jen do jedné vrstvy,
- práce je rozpadlá na menší konkrétní dodávky,
- a malý tým zvládá držet poměrně široký rozsah systému.
Jak vypadá rytmus práce
Velká část efektivity nevzniká z nějakého kouzelného nástroje. Vzniká z rytmu práce. Každý den se potkáme a děláme tři jednoduché věci:
1. Co jsme udělali
Řekneme si, co je hotové, ukážeme si změny a doplníme si kontext o tom, co se v systému mezitím změnilo.
2. Co jsme zjistili a co změnit
Druhá část je často stejně důležitá jako samotný delivery update. Sdílíme si nové poznatky, služby, modely, API, nastavení a zkušenosti, které mohou ovlivnit další práci. Zároveň spolu řešíme i produktové otázky a návrhy na změny v aplikaci. Debatujeme nad frontendem, backendem i architekturou, aby bylo jasné nejen co udělat, ale i proč to dává smysl právě takhle.
3. Co bude hotové zítra
Na konci dáme krátkou rekapitulaci a upřesníme si, co má být do dalšího dne hotové.
Tahle jednoduchá rutina drží tempo, snižuje šum a pomáhá nám udržet vysokou rychlost bez zbytečného chaosu.
TODOs jako součást vlastní aplikace
Jeden z nejpraktičtějších příkladů toho, jak přemýšlíme o systému práce, je náš přístup k TODOs.
Zkoušel jsem přemýšlet, jestli na řízení práce použít Linear, Notion nebo jiný externí nástroj. Dokonce jsem některé z těch variant i zkusil. Jenže to pro náš styl práce bylo nakonec zbytečně komplikované.
Pak jsme přešli k souborům v repozitáři, které jsme commitovali. Bylo to blíž vývoji, ale pořád to nebylo ono.
Nakonec jsme TODOs přesunuli přímo do webové části aplikace a začali v ní řídit vlastní práci.
To má několik výhod:
- kontext zůstává blíž produktu,
- systém používáme sami na sobě,
- rychleji vidíme tření a nedostatky,
- a nevytváříme zbytečnou další vrstvu nástrojů kolem vývoje.
Je to malý detail, ale krásně ukazuje širší princip: nejlepší způsob, jak navrhnout software pro řízení práce, je začít v něm řídit vlastní práci.
Kde do toho vstupuje AI
AI do toho nevstupuje jako náhrada přemýšlení. Vstupuje jako páka.
Pomáhá:
- rychleji navrhovat varianty,
- rychleji rozpadat práci,
- rychleji připravovat implementaci,
- rychleji dělat review a iterace,
- a rychleji doplňovat menší specializované kontexty.
Ale celek pořád musí držet člověk. Bez toho se zrychlení snadno změní v chaos.
Co mě na tom baví nejvíc
Nejvíc mě na HarryApp baví, že je to skutečný produkt a zároveň živá laboratoř nového způsobu vývoje software.
Neověřujeme hypotézy na slidech. Ověřujeme je v běžném pracovním rytmu, v commitech, v releasích a v tom, co nám funguje a co ne.
A čím déle na tom pracujeme, tím víc mi dochází, že budoucnost opravdu nebude patřit jen velkým týmům. Bude patřit lidem, kteří umí držet kontext, architekturu, rychlou iteraci a dobrý systém práce.
HarryApp je pro mě důkaz, že to není teorie. Je to něco, co už dnes funguje v praxi.
