Vývoj mobilní aplikace: 8) Jak komunikovat s vývojářským týmem

21. 12. 2023

Vývoj mobilní aplikace má mnoho různorodých aspektů, které je dobré vědět. V následujícím seriálu Vám představujeme jednotlivé díly, které Vás provedou celým procesem vývoje softwaru od začátku do konce.

Jelikož je software development věda, pokračování o vývoji má zase pod palcem ten, kdo o spolupráci vývojáře s klientem ví nejvíce. 

Programátor.

Náš Android kolega:

„Programátor potřebuje odborníka, který rozdělí abstraktní nápad klienta na konkrétní kusy ke zpracování.“

 


Přemýšlíte o vlastní aplikaci?

Dejte nám vědět a rádi to s Vámi probereme.

Chci aplikaci

 


 

Když se ale klient rozhodne komunikovat přímo s vývojáři a ne přes projektového manažera – teda odborníka, může to vést k neefektivitě.

Řekněme si na rovinu – překlenout ideu a realitu je sakra těžká práce.

Komunikace je při vývoji naprosto důležitá. Google na dotaz ‚jak komunikovat s programátorem‘ našel 169 miliónů výsledků za půl sekundy!

 

Komunikace zadavatele, tedy klienta, a programátora je neefektivní hned z několika hledisek:

  1. Celý zbytek týmu, který při rozhovoru nebyl, musí buď pečlivě naslouchat všemu, co se kde šustne, nebo se paradoxně neustále doptávat.

    Může se stát, že po takovéto domluvě nebude změna zanesená do společných “logů”, tím pádem tester neví, co má testovat a projektový manažer netuší, na čem se pracuje, protože ho klient obešel.
     

  2. Zadavatel nerozumí možnostem a omezením platforem či aktuálnímu stavu hotové aplikace, (které mu může osvětlit komunikace s projekťákem) a programátoři zase nerozumí byznys cílům, (které naopak dobrý projekťák bere do úvahy neustále). 

    Může docházet k nedorozuměním, kdy oba – programátor i klient – chtějí to samé, ale nedokážou se kvůli těmto rozdílům dohodnout.

 

Pokud jste se rozhodli jako klient s vývojářem komunikovat přímo, čemu se vyhnout?

“Oni to mají, proč my nemůžeme?“

Vyhněte se vyžadování funkcí, které mají jiné aplikace, speciálně ty od velkých vývojářů (Facebook, Twitter, …). Ne všechny funkce jsou rovnocenné, ne všechna “UIčka” jsou stejná.

Představte si např. předhodit kamarádovi, který si postavil cihlové ohniště, fotku Burj Khalify a vyžadovat, aby vám ji postavil.

 

Vyhněte se emocionálnímu nátlaku a přehnaným reakcím. Věřte, že všichni chtějí, aby Váš produkt byl úspěšný a s co nejmenším počtem chyb.

Vývoj softwaru je každopádně kompromis mezi “cizelováním” a přidáváním “byznys hodnot”.

Několik příkladů jak zpětnou vazbu pro vývojáře fakt nedělat:

“No ale to přece nemůžeme uživatelům poslat, vždyť to vůbec nefunguje!”
             – reakce na odsazení tlačítka o 13 pixelů

“No tuhle aktualizaci snad nemyslíte vážně?!‘
          – reakce na list, který se přestal načítat, protože klientovi vypadla Wi-Fi

 

————————————————————————————————
💡 Rada: Ověřte si jestli chyba není i na Vaší straně. V případě, že jste si jisti, že není, méně emocionální reakce padne každému lépe: “Tato funkcionalita je v rozporu s mojí představou.” Od toho se potom můžete odrazit dospecifikováním oné fíčury.
 

Programátoři bohužel nepracují v drag’n’drop systému a každou změnu je potřeba znovu naprogramovat. Velká část změn není jednoduchá, tak se přestaňte vracet zpátky v čase a měnit podmínky.
Existují změny, které jsou velmi jednoduché ke zpracování, ale takových je pomálu.
——————————————————————————————

💡 Rada: Pokud máte tendence měnit zadání po zpracování, učiňte tak ve fázi návrhu, kdy lze abstraktní nápady měnit z minuty na minutu.
 

Všechno opravdu nevíte nejlépe, jinak byste si to naprogramovali sami 🙂

Nesčetněkrát se setkáme s tím, že klient rozporuje roky studovaných fakt, předloh a směrnic pro design a návrh aplikací. S takovým klientem nejde nalézt “společnou půdu” a proto tím trpí celý produkt.
————————————————————————————————
💡 Rada: Věnujte se části aplikace ve Vaší specializaci (typicky například marketing) a micro-management nechte u ledu.  

Nezdržujte aktualizace, opravy zaneste do dalších verzí

Za předpokladu, že se pracuje na několika verzích dopředu (jedna v beta fázi, jedna v alpha fázi a poslední v aktivním vývoji), je velmi drahé např. z beta fáze propagovat změny do všech ostatních verzí.
————————————————————————————————
💡 Rada: Nejlepší přístup je tedy zanést opravy do aktivního vývoje a všechno ostatní vydat tak, jak to je.

💡 Rada: Nenechávejte procházet aplikaci zdlouhavým schvalovacím procesem, vydávejte funkcionality, se kterými jste spokojeni.

💡 Rada: Držte si přehled všech aktuálních verzí a stádií vývoje pro sledování a zařazení oprav chyb nebo úprav funkcí.

„Chci testovat s vámi!“ „… Ale tohle mi přece nemůžete posílat!“

“Chci testovat s vámi” pro vývojáře znamená zapojení klienta do “pre-alpha” fáze, kdy lze odhalit velké množství chyb předtím, než se kód dostane do stabilnějších variant. Takové aplikace jsou často posílané každý den nebo několikrát týdně.

Chybou klientů je potom to, že jsou naštvaní, že aplikace spadne, prvky nejsou zarovnané správně a tak podobně.

Na druhé straně spektra jsou potom klienti, kteří urputně testují každou jednu verzi a sepisují dlouhé dokumenty o funkčnosti té oné verze.

Ani jedno se od Vás nečeká.

 

Jaké jsou teda fáze vývoje a jak k nim nejlépe reagovat?

 

Stabilita aplikace ve vývojovém procesu se udává v takzvaných fázích: “pre-alpha”, “alpha”, “beta” a “release”.

 

 

Přistupujte k jednotlivým fázím následovně:

  • pre-alpha

Vyjádřete se pouze pokud se vám nelíbí směr, jakým se aplikace ubírá. Chyby v této fázi vznikají z nepochopení, nebo z nedostatečného upřesnění zadání a lze je rychle podchytit.

Např.: “Obrazovka přihlášení nemá naskočit automaticky, ale pouze po kliknutí na tlačítko “přihlásit”.

  • alpha

Vývojář je v této fázi v zásadě spokojen se svou prací a je na Vás, abyste jeho práci zkritizovali.

Např.: “Tlačítka mají nesprávnou barvu a tvar.”

  • beta

V tomto stádiu je aplikace téměř připravena na vydání (release). Markantní změny nelze provést, protože častokrát je kód dále rozvinut pro další verze nebo fíčury. Žádoucí je opravit pouze fatální chyby.

Např.: “Aplikace spadne pokud uživatel vypne mobilní data.”

  • release

Aplikace se vydává a není cesty zpět. Všechny další problémy se budou řešit v dalších verzích.

No neříkali jsme vám, že vývoj softwaru je celá věda?

No říkali

.. a lhali jsme?

Pokud jste ale prošli tuto lekci pozorně, je fakt malá šance, že programátora při vzájemné komunikaci nas***te.

 

V příštím díle více o tom, jak na Google play a AppStore a jestli vůbec.

 

Všechny chystané díly seriálu

  1. Pasti software projektů
  2. Mám nápad, co když mi ho ukradnou
  3. Konzultujte. Ušetříte čas i peníze
  4. S kým spolupracovat na vývoji software
  5. Je produkt skutečně potřeba
  6. Proč tvořit dobré zadání
  7. Jak se vyvíjí aplikace
  8. Jak komunikovat s vývojářským týmem
  9. Jak na Google play a AppStore a jestli vůbec
  10. Jak na soukromí v aplikaci
  11. Funguje mi vůbec ta aplikace?

 

Klíčové funkce a komponenty APS systémů

Vaše moderní výrobní firma čelí neustálým výzvám. Musíte pružně reagovat na nečekané události, a přitom udržet nízké náklady s maximální …

Číst článek

Co je APS (Advanced Planning and Scheduling)?

Jste výrobní firma? Tak to určitě znáte, jak se vám mění poptávka pod rukama a jak je konkurence ostrá. Bez …

Číst článek

Zkušený iOS vývojář

iOS programátor se zkušenostmi, který si chce řídit vlastní čas v remote-first týmu. Jsme svobodná full remote vývojářská firma. Technologie, …

Číst článek

Kontakt