Udržitelnost v projektovém řízení
Naší misí je být go-to partnerem pro udržitelnou digitalizaci. Pod tím si každý z týmů v Ackee může představit něco trochu jiného. Vývojáři se na udržitelnost dívají třeba jako na psaní kódu v technologiích, kterým aktuálně stoupá popularita, ale jsou už dostatečně osvědčené, aby bylo jasné, že vydrží. Designeři zase jako na nutnost vytvořit dostatečně robustní a flexibilní design systém, v kterém je možné navrhnout UI celé aplikace a kde jednotlivé komponenty dávají smysl samostatně i jako celek.
V případě projektového řízení vnímám udržitelnost jako schopnost využívat znalosti a existující řešení nebo přístupy z ostatních projektů, minimalizovat množství věcí, které se musí předělat (ať už je důvod jakýkoliv), a dělat projekty, které mohou fungovat z dlouhodobého hlediska. Nechceme zkrátka projekty jednorázově odevzdat a jít od nich pryč, chceme u produktů zůstávat, dál je vyvíjet a udržovat.
Jak to můžeme ovlivnit my projekťáci? Například tím, že motivujeme a směrujeme tým k řešení problému tak, aby co nejvíc splňoval předchozí body, nebo diskutujeme s klientem o potřebě změny a dost možná společně dojdeme k tomu, že není nutná. Co nám pomáhá? Učit se z předchozích chyb – a to nejen vlastních.
Kultura sdílení
Chyby dělá každý. A dělat chyby je normální. Důležité je to, co se děje potom. Měli bychom totiž jejich množství a hlavně opakování co nejvíce eliminovat. V týmu se proto snažím podporovat kulturu sdílení chyb na projektech, abychom měli možnost se o nich vzájemně dozvědět, probrat je do detailu a diskutovat různé přístupy a nápady, jak se jich příště vyvarovat. Na každém týmovém meetingu máme proto vyhrazené 10-15minutové okno s názvem “Fuck-up academy”, abychom si připomněli, co se nám za posledních 14 dní nepovedlo a mohli to rozebrat s ostatními.
Kromě chyb je samozřejmě dobré sdílet i úspěchy, ale osobně razím názor, že fuckupy jsou hodnotnější, protože ukazují, jak se do daných problémů dá dostat a jak z nich ven. Navíc obsahují i onu část správného řešení a následného úspěchu. Jen s větším kontextem.
Ale dost bylo teorie, teď trochu praxe. Pojďme podívat na pár fuckupů, které se za poslední dobu staly mně.
Fuckup 1: Příliš vstřícný přístup k vystavenému API pro partnery
Kontext projektu
Tento fuckup se týká projektu BOX NOW, který si můžete představit jako zásilkovou službu v Řecku s doručováním do boxů. Proces funguje tak, že si zákazník nakoupí na e-shopu a při placení si vybere, do kterého boxu chce zboží doručit. E-shop objednávku vytvoří přes partnerské API v BOX NOW systému a následně dojde k doručení zboží.
Popis problému
Během návrhu partnerského API jsme se společně s klientem zamýšleli, jaké funkce by mohli partneři chtít a využívat. Kromě vytváření objednávek tak obsahuje funkce jako:
- stažení dostupných boxů pro doručení
- generování a stahování štítku pro jeden nebo několik balíků
- získání stavu zásilky, nebo několika zásilek včetně všemožných filtrů a hledání jako jméno, telefon, e-mail zákazníka, případně libovolný textový řetězec vyskytující se v různých položkách objednávky, tak aby bylo jednoduché objednávku najít
Nepředpokládali jsme žádné větší problémy, protože e-shopy, které se na nás budou integrovat, budou mít vlastní kvalitní IT oddělení. Většina těch větších jsou v podstatě IT společnosti. Tento náš předpoklad se nám ale s rostoucím počtem partnerů rozplynul před očima. Integrace jsou často vytvořeny co nejjednodušším způsobem, takže většina firem používá právě ono obecné vyhledání, i když vědí, že hledají např. podle telefonního čísla a to je pro náš systém výpočetně daleko složitější.
A tady vzniká problém. Donutit totiž firmy integrace opravit, je skoro nemožné, protože jsou jich tisíce a systém z jejich pohledu funguje, tak proč něco měnit. Pro službu to ale znamená zbytečně navíc vynaložené prostředky na infrastrukturu a optimalizaci funkcí tak, aby byly rychlejší a nezatěžovaly systém.
Poučení
Pokud bychom byli v návrhu služby od začátku tvrdší a nedávali firmám funkce, které vyloženě nepotřebují, ale možná by se jim mohly líbit, pravděpodobně bychom tento problém vůbec nemuseli řešit.
Další ponaučení, které si odnáším, je myslet dopředu. Co by se dělo se systémem, kdyby se funkce začala využívat výrazně víc, než jsme předpokládali? A nepřináší funkce spíše riziko, než přidanou hodnotu? Tyto otázky je dobré si pokládat předem.
Fuckup 2: Změna brand identity
Kontext
Tento fuckup se týká dlouhodobějšího klienta, pro kterého kontinuálně vyvíjíme back office aplikaci včetně mobilní appky. V době, kdy už všechny části systému existovaly, se klient rozhodl pro rebranding, který dostala na starost jiná agentura. Po jejím dokončení se nová brand identita začala aplikovat i do systémů, které tvoříme my.
Problém
Během implementace nové identity do mobilní aplikace jsme narazili na to, že obsahuje jiný font. To by nebyl takový problém, kdyby ovšem font nebyl placený. Po vyžádání fontu od klienta jsme zjistili, že informaci o tom, že je font placený, slyší poprvé od nás. Při detailnějším pohledu na cenu fontu jsme vypočítali, že pro použití v mobilní aplikaci by mohl stát až 1/4 milionu korun. A s tím se v rozpočtu nepočítalo. Nový rebranding byl už ale v procesu a nedalo se tak snadno opět vše měnit, protože náklady by mohly být ještě vyšší.
Prozatím jsme tedy font koupili a aplikovali jen do nutných částí, čímž jsme snížili náklady na 80 tisíc korun a do budoucna se budeme snažit domluvit custom pricing, případně přechod na jiný, podobný font.
Poučení
Poučení pro nás je nepředpokládat, že klient má licenci ke všem potřebným zdrojům, a to ani v případě, že mu identitu zpracovala profesionální agentura. Před začátkem designu na naší straně zkontrolovat licence k fontu pro různé platformy a zařízení v rámci projektu, který budeme vytvářet. A dávat si na tyto věci zvlášť pozor v případě, že by součástí projektu byly i nějaké věci ve fyzickém světě. Výměna by totiž nemusela být tak jednoduchá jako v případě softwaru.
Závěr
Kdybych si své fuckupy nechal pro sebe a nesdílel je v rámci firmy a týmu, je pravděpodobnější, že je udělá někdo znovu. A to bychom k udržitelnému vývoji aplikací směřovali těžce. Osobně vidím jako daleko lepší, snažit se v rámci týmu podporovat kulturu sdílení, bavit se o tom, co se nám nepovedlo, a společně se tak v řízení projektů zlepšovat. Pokud vás zajímají další fuckupy, podívejte se na můj talk, případně na další talky z naší série meetupů na téma udržitelné digitalizace.
