Co budujete vs v čem to budujete
Když lidé píší svou zkušenost s vývojem aplikace, webu nebo jiného produktu, obvykle mají články dvě podoby. Co jsme budovali vs jak jsme to budovali. Jeden by řekl, že je to nahodilé, že kdokoliv může napsat článek na obě témata. Ale nezdá se mi, že to tak opravdu je.
Článek původně vyšel na autorově blogu.
Ze zkušenosti, když si s lidmi povídám o jejich práci, se lidé dělí na ty, které zajímá a baví se buď o tom, co řeší a pro koho, nebo o tom, jak to řeší a co k tomu používají.
Když to přeženu, budou dvě sorty lidí.
Jedni ví o nějakém problému, který je potřeba vyřešit. A je jim jedno, jestli to vyřeší tejpovací páskou, excelovou tabulkou, Visual Basicovým skriptem nebo nejmodernější technologií. Mnoho mých zákazníků používá Zend Framework 1 a nemají zatím žádný plán nahradit ho za ZF2, Symfony, Nette nebo jakýkoliv jiný framework.
Pro druhé je problém k řešení jen stafáž, na kterou si navěsí experimentování s technologiemi. Je jim víceméně jedno, jestli bude produkt úspěšný, dokud bude úspěšný dost na to, aby si mohli pracovat v čem chtějí. Ještě neví, co bude jejich příští projekt, ale už ví, že použijí React, Meteor, Mongo nebo cokoliv jiného, o čem před 14 dny zjistili, že je to teď cool.
Úspěšné firmy, které jsem poznal, obsahovaly obě skupiny takových lidí. Jak ty, kteří jsou v technologiích konzervativní a tlačí na řešení problémů uživatelů, tak i ty, kteří se informují, vědí, co je dnes bleeding edge a jaké jsou možnosti.
Když máte v týmu obě skupiny lidí, inovujete, umíte dělat ty věci, které jsou nové a kde je velká poptávka a malá nabídka. Tak vypadají úspěšné týmy.
Když budete mít jen „konzervativce“, asi budete krátkodobě, možná i střednědobě schopni vydělat dost peněz a pomoci spoustě lidí. Budete produktivní jako hrom. Ale jste na cestě do historie a do zapomnění.
Když budete mít pouze „inovátory“, postavíte nejvíc „cool“ produkt, který buď nikdo nebude chtít, protože předběhnete dobu, nebo pravděpodobněji proto, že jste neměli čas zabývat se tím, co váš uživatel opravdu chce a jestli mu nestačí ta excelová tabulka.
Pro firmy i startupy to znamená určitou lekci.
Jednu dobu byl nesmírně populární Web 2.0, tagování, obsah generování uživateli, sociální sítě. Pak přišlo oblíbené „mobile social local“. Teď jsou to Internet Of Things, mezi kterými jeden z hitů, který už začíná být fakt vidět, jsou Wearables. Technologie a společnost uzrály a startupy (ale s nimi i korporace jako Microsoft, Apple) pokrývají celý svět tím, co se dá.
Takže vznikaly mobilní aplikace pro nakupování, bydlení, dopravu atd. Teď budou vznikat chytré trouby, termostaty, alarmy, topení do domácností. Asistenční drony, které budou pomáhat vozíčkářům atd.
A pak přijde další změna, posun. A znovu se rozeběhne ten boj o to, kdo obsadí ty nové možnosti. To získání trhu zpravidla neudělá ten, kdo jej obsadí první (jak tvrdí oblíbený mýtus), ale ten, kdo daný problém vyřeší první dobře. A na dobré řešení je někdy potřeba víc nových technologií, jindy víc produktového uvažování. První je někdy zbytné. Vždy tam ale musí být to druhé.
Moudrý manažer pak podle toho staví svůj tým. Jste-li v situaci: „Vybudujte to a oni přijdou.“ (velmi vzácné touto dobou), lze mít tým plný experimentátorů s nejnovější technologií. Častěji budete muset nějak řešit problémy zákazníka a tomu je jedno, jestli je vaše aplikace v PHP+jQuery, v nodejs+Reactu nebo jestli je zcela statická.
Ještě jednou to zopakuju. Vašemu zákazníkovi je naprosto zcela ukradené, v čem a jak je aplikace naprogramovaná, dokud řeší jeho problém. Single Page Aplikace jak taková neřeší žádný problém. Až to, že funguje offline, přináší nějaký benefit. To, že aplikaci můžete zabalit do PhoneGapu a distribuovat na mobily, nepřináší žádnou hodnotu, až to, že ji skutečně takto začnete distribuovat, to hodnotu přinese.
Takže použití nové technologie by mělo být odůvodněno tím, že platí aspoň jedna z následujících věcí:
- už danou technologii umíte odjinud
- daná technologie vám umožní něco, co dosud nemůžete dělat – a co zároveň udělat chcete
- na novou technologii seženete lidi, na starou ne
- budete v nové technologii produktivnější i po započítání času potřebného na naučení
Podle toho, jak si odpovíte, byste měli vyslyšet volání po tom použít nějakou novější technologii. A dál si pište nebo čtěte články, které vyhovují vašemu přístupu.
Jiří Knesl už 8 let úspěšně školí Scrum a Agile v českých i zahraničních firmách.
Jiří Knesl
Jiří Knesl se zabývá hlavně Scrumem a správným vývojem software (prevence chyb, vyšší produktivita).
To by se dalo tesat, vše je pravda.
Tvrzení, že
je aplikovatelný tak akorát ve zbytnělých korporátech a státní správě, kde jsou tak dlouhé manažerské komunikační trasy, že stejně nikdo neví co kdo dělá (tam také působí nejvíc agile poradců, co jim úspěšně radí, jak správně programovat).
Prvně, kromě greenfield projektů si člověk technologie těžko vybere. Za druhé, různé technologie poskytují různé výsledky z hlediska rychlosti/produktivity vývoje produktu a jeho následné efektivity.
Je proto mnohem pravděpodobnější, že si firma nechá udělat proof of concept popř. feasibility study, aby zjistila, co a jak a na základě výsledků pak do non-functional requirements přidá požadavky na použité technologie a protokoly.
No je pravda, že většina mých zakázej je stylem potřebuju to a to v tomhle.
Je to jedno. Dnes tak rozšířený SaaS servíruje HTML+CSS a je jedno, jestli je na pozadí Python, C# nebo PHP. Pokud jste firma, která vyvíjí svůj produkt (jako je ABRA, browser Opera atd.) tak je opět úplně vaše věc, v čem to naprogramujete, lidi nezajímá, jestli je Firefox napsaný v C, Vale nebo Brainfucku. Když budete vyvíjet operační systém, opět je to vaše věc a lidem je jedno, jestli je v C++, Haskellu nebo v Rustu.
Různé technologie mají různé aspekty. Ale ze zkušenosti můžu říci (a prošel jsem projekty v mnoha různých jazycích), že v produktivitě vývojáře, který dělá třeba v PHP, Pythonu, Ruby, JavaScriptu, jsou jen mizivé rozdíly.
Ten drobný kopanec do „agilních poradců“ je mimo. Kdyby bylo ve státním sektoru víc agilních poradců, mohla státní správa vypadat jak ta Estonská.
Lidi to samozřejmě zajímá, i když nepřímo. Například je důležité, jaké chyby SW obsahuje, a toto může být dáno programovacím jazyekm.
Jaké chyby sw obsahuje je z většiny dáno programátorem a ne jazykem.
Ano, ty chyby udělal programátor, ale kdyby použil jiný jazyk, tak by tam být nemusely. Například v C nebo C++ může snadno dojít k přetečení bufferu, kterého si nikdo nevšimne – v C# je to těžší. Nebo v Prologu snadno vytvoříte nechtěný choice point – v Javě se to nestane, choice pointy tam nejsou. V Haskellu lze snadno napsat program, který zcela nečekaně používá vysoké množství paměti nebo CPU – jazyky se striktním vyhodnocováním dovolují snazší a modulárnější uvažování o spotřebě paměti nebo CPU.
Takže většině lidí je to jedno. Je zajímá, jestli je to dostatečně rychlé, dostatečně spolehlivé (a bezpečné), kolik to stojí a případně jestli se produkt dostatečně rozvíjí s časem, ale je jim už jedno, jak jste toho dosáhli – jestli máte vše v Javě, nebo jestli si v Ruby pomáháte nativním kódem, nebo jestli jste to všechno napsali v ASM. Jestli vám některé chyby odchytí kompilátor, nebo TDD. Jestli děláte TDD, nebo formální verifikaci ;) Jestli máte jednoho člověka, který to dělá po večerech, nebo jestli máte full-time 50 lidí.
Tím nepopírám, že volba jazyka, platformy, knihoven třetích stran, způsobu zajišťování kvality (TDD, statická analýza, …) apod. má vliv na rychlost, bezpečnost, rychlost vývoje a náklady na vývoj. Vliv to má, ale zákazník obvykle vnímá až ten výsledek.
Najde se pár výjimek, ale to musí zákazník nějakým způsobem vidět do té technologie. Já třeba dnes už rozlišuju mezi virtualizací ve VirtualBoxu a v Xenu a i v tom Xenu by mi záleženo na konfiguraci. Jen tak bych v práci nepřipustil knihovnu implementující kryptografická primitiva v Javascriptu. A mohl bych pokračovat. Jsou zase lidi, kteří nechtějí aplikaci v JS/Javě/Flashi/, i když by splnila svůj účel.
Pokud čekáte, že toto bude typický zákazník řešit, pak je OK tomu věnovat více pozornosti, ale je to IMHO dost specifický případ. V obou případech by měl z pohledu manažera stát v popředí zákazník a až za ním technologie.