Brick Broadcasting
(CC BY-NC 2.0)

Už jsem se věnoval srovnání servisní a produktové firmy. Nastínil jsem, že jedno z úskalí, kterému produktová firma čelí, je zpětná kompatibilita. Ovšem řeší jiné, mnohdy důležitější, problémy. Tak jako ostatní články i tento píšu rovněž pro sebe, abych si srovnal myšlenky a jednotlivá úskalí pojmenoval. Nevyhnu se tomu, abych se k rozdílu servisní a produktové firmy ještě nevrátil.

Ohlasy

Začnu ohlasy, které srovnání servisní a produktové firmy, respektive jejich přerod, vyvolal. Pavel Müller, v reakci na můj předchozí příspěvek, napsal

Můj závěr ale je, že se servisní firma nedá transformovat na produktovou. Pro podnikatele je podle mě lepší založit komplet novou firmu a chovat se v ní jako investor, byť peníze pochází z výnosů původní servisní firmy.

Produktová firma

V servisní firmě je zákazník vaším pánem. V produktové taky, ale tam potřebujete vyvažovat pohledem produktu, který má nějaký plán či jízdní řád, a slouží i jiným zákazníkům.

Abych citoval Petra Dvořáka z Wultra.

„Jak dělat produktový vývoj agilně v kontextu dodávek produktu ke koncovým zákazníkům?“ je z kategorie otázek za milion.

Strhla se kolem toho diskuze. Samotnému mi vadí, že slovo agilní devalvovalo, ale znal jsem kontext tohoto citátu, tady konkrétně pružná reakce na změnový požadavek. U velkých produktových molochů nemáte moc šanci něco ovlivnit. Menší firmy v tomto můžou mít konkurenční výhodu, ale vocaď pocaď. Někde si ty hranice neumí nastavit a pak je obhájit, protože to drhne.

A ještě vypíchnu jednu citaci, která věc dovysvětlovala:

Konkrétně: Často potkáváme situaci, kdy po nás klient chce změnu, která sama o sobě vlastně zabere třeba 5 dní práce. Jenže nám přišla měsíc před vydáním produktového release, který vydáváme po 6 měsících, a tak klienta „zazdíme“ větou: „Za 7 měsíců vám to dodáme jak na koni…“

Když to dokážete ukočírovat, získáte nezměrné výhody. Zvládnete zákazníkovi neustále dodávat (jak obchodně, tak i reálně) nové verze s funkčnostmi, které implementačně vznikly, aby pokryly potřebu jiného zákazníka.

Na menši dodavatele může být vyvíjen větší tlak, aby udělali nějakou výjimku. Ve firmě 37 Signals šli tak daleko, nebo to alespoň v knize It Doesn’t Have to Be Crazy at Work píšou, že zavedli paušální platbu a ne částku za uživatele, aby na ně velcí zákazníci neměli takovou páku.

Dokumentaristi

Dokumentace mnohdy bývá popelkou. Servisní firma to dokáže možná překlepat, ale v produktové se vám problém vyjeví v celé síle. Bez kvalitní dokumentace jste zahlceni dotazy, které by bývaly mohly být zodpovězeny dokumentací, což vám zabere čas na nový vývoj.

Doporučím starší rozhovor Meet Anna, the documentation team lead for IntelliJ IDEA.

V mnoha firmách je bohužel dokumentace stále psaná jen proto, že se očekává, že ji zákazník dostane. Ve skutečnosti se nikdo nezastaví a nezamyslí, pro koho ji píšou a jaké byznysové problémy řeší.

Kdo by se tak dokázal zamyslet? Podle mě je chyba dokumentaci (nemluvím o javadocu) svěřovat programátorům. Kompetencí dokumentaristy je znalost jazyka a uživatelská znalost (ne na úrovni kódu, ale domény). Raději než absolventa technické školy bych vzal někoho z filologie.

Závěr 208. dílu CZ Podcastu, kde byli jako hosté Radim Šnajdr a Vilém Vatrt z Quadientu, si nechám zarámovat.

Poměr, který více méně dodržujeme, je deset vývojářů ku jednomu dokumentaristovi.

Logování a podpora

S logováním je to obdobné jako s dokumentací. Logujete-li špatně, trávíte čas dotazy a dohledáváním, což vás obírá o prostor, který jste mohli věnovat rozvoji produktu.

Tady bych se pozastavil u úrovně podpory, které chápu následovně:

  • L1 - dokáže restartovat server, najít logy, vyřešit běžné problémy
  • L2 - zvládne konfigurovat systém podle příručky a upravit pro byznysové potřeby (napsat makro, plugin…)
  • L3 - průzkum až na úrovni zdrojových kódů a jejich případnou opravu

Jako servisní firma pravděpodobně řešení provozujete sami. Jako produktová firma nejspíš ne, ideálně je mezi vámi a zákazníkem ještě partner. Podpora L1 je nejspíš zákazník, L2 partner a L3 vy jako produktová firma (nebude to mít takto ostrou hranici, může se prolínat). K rukám L3 se dostanou jen kusy logu a vy z těch střípků máte něco vyřešit. Nehledě na to, že bez kvalitní dokumentace a logů padá na L3 příliš mnoho věcí.

Z knihy Monolith to Microservice (Sam Newman), zdarma dostupné na nginx.com, bych chtěl zdůraznit dvě myšlenky týkající se situace produktové firmy, kterou mikroslužby ještě zhorší.

  1. Nemůžete očekávat, že zákazníci mají schopnosti nebo dostupnou platformu, aby provozovali vaši architekturu mikroslužeb. A i kdyby měli, nemusí to být to samé, co vyžadujete.
  2. Pokud s mikroslužbami začínáte, nemějte obavu o to, jak velké mají být. Zaměřte se na to, kolik jich dokážete zvládnout a jak mají definované hranice.

Závěr

Kdo čekal nějaký návod, bude zklamaný. Kdo se chystá začít s produktovou firmou, vidí, co ho čeká. Já si zopakoval, že v těchto čtyřech oblastech (zpětná kompatibilita, dokumentace, logování a správa požadavků) vidím zdroj potíží, které je potřeba řešit.

Související