Рок у мобилним апликацијама — шта је то, рокови и управљање

Шта је рок?

Рок — англицизам који је чврсто ушао у лексикон програмера и менаџера. У преводу са енглеског деадлине значи „мртва линија": датум или време након којег се задатак сматра закаснелим. Кршење рокова води ка губитку поверења, казнама и пропуштеним тржишним приликама.

Рок као алат за планирање

У здравом тиму рок није алат притиска, већ тачка синхронизације очекивања. Тим и заинтересоване стране договарају када ће функционалност бити готова и користе рок за планирање зависних активности: маркетинга, издавања, тестирања. Овакав приступ захтева транспарентност и поверење између свих учесника.

Рок наспрам рокова у Аgile-у

У Аgile-у рокови се не укидају, али постају флексибилнији: уместо фиксног датума за цео пројекат користе се тајмбоксови — фиксни временски периоди (спринтови) у којима тим ради максимум могућег. Сцрум оперише спринтовима фиксне дужине, где обим може да варира, али датум завршетка спринта је непроменљиви рок.

Нивои рокова у мобилном развоју

У мобилном развоју постоји неколико нивоа рокова, од којих сваки захтева свој приступ управљању и контроли.

Рокови за функције

Рокови за функције — најкраћи и најконкретнији. Програмер процењује време за реализацију одређеног екрана или компоненте. На овом нивоу важно је предвидети бафер за неочекиваности: сложена грешка, неочигледан захтев, зависност од другог тима. Оптимални бафер — 20-30% од процене.

Рокови издања

Издање у Апп Сторе-у или Гоогле Плаy-у — чврст рок који се не може померити без губитка пословних прилика. Рокови издања укључују време за преглед продавница (Апп Ревиеw — 24-48 сати, Гоогле Плаy — од 2 сата), зато финална верзија мора бити готова 3-5 дана пре жељеног датума издања.

Пројектне прекретнице

Прекретнице — велике тачке пројекта: МВП, бета, прво издање. Оне се одређују у фази планирања и ретко се преиспитују. Прекретнице захтевају најпажљивије управљање ризицима: свака кашњења у раним фазама се акумулирају и пробијају финални рок.

Зашто се рокови пробијају: главни разлози

Пробијање рокова — системски проблем, а не последица лењости програмера. Истраживања Пројецт Манагемент Институте показују: главни разлози кашњења су везани за процесе, а не за људе.

Нереална процена

Процена радног напора често се ради од стране менаџера или клијента без учешћа програмера. Резултат: рокови 2-3 пута краћи од реалних. Правило: процену даје онај ко ће радити задатак. Колективна процена тима (Планнинг Покер) је 30-40% прецизнија од индивидуалне.

Промена захтева

Сцопе црееп — постепено ширење захтева без ревизије рокова. Клијент додаје „мале исправке" које укупно дају недеље додатног посла. Решење: свака промена захтева мора бити праћена ревизијом рока. Ако је рок фиксан — обим мора бити фиксан такође.

Неурачунате зависности

Блокирајуће зависности од других тимова, спољних АПИ-ја, дизајна или одобрења често се не урачунавају у процену. Ако бекенд није спреман — мобилни програмер не може да тестира интеграцију. Мапа зависности (депенденцy мап) треба да се састави пре почетка рада на задатку.

Технички дуг

Стари код без тестова, застареле зависности, недостатак ЦИ/ЦД — све то успорава развој и чини рокове непредвидивим. Тим троши 30-50% времена не на нову функционалност, већ на борбу са постојећим кодом. Инвестиције у квалитет кода се исплаћују предвидивим роковима.

Како управљати роковима: методе и алати

Професионално управљање роковима заснива се на транспарентности, разлагању и редовној комуникацији. Постоји неколико проверених метода.

Тимебоксинг: фиксно време

Тимебок — фиксни временски период у коме тим ради максимум могућег. На крају тимебокса резултат се представља, чак и ако није све готово. Тимебоксинг спречава бесконачно дотеривање и учи тим да се фокусира на битно. У Сцруму, сваки спринт је тимебокс.

Управљање бафером

Временски бафер — резерва која штити рок од неизбежних кашњења. Метода Цритицал Цхаин Пројецт Манагемент препоручује предвиђање 50% бафера од трајања задатка. На пример, ако је задатак процењен на 10 дана, у план се уноси 15. Бафер је видљив само менаџеру како се тим не би опустио.

Дневни састанак за контролу

Дневни 15-минутни састанци — једноставан и ефикасан алат за контролу рокова. Сваки програмер одговара на три питања: шта је урадио јуче, шта ће урадити данас, има ли блокатора. Ако задатак ризикује да не стане у рок — блокатор се открива првог дана, а не последњег.

Систем семафора

Семафор (зелено / жуто / црвено) — визуелни статус рока. Зелено — све по плану. Жуто — постоји ризик од пробијања, потребне мере. Црвено — рок ће сигурно бити пробијен, потребна ескалација. Систем је једноставан и јасан: сваки учесник пројекта види статус и разуме где је потребна интервенција.

Типичне грешке у раду са роковима

Грешке у управљању роковима понављају се у већини ИТ тимова. Познавање ових образаца помаже да се избегну.

Синдром студента

Синдром студента — навика да се посао почиње у последњем тренутку, када је рок већ близу. Програмер одлаже задатак мислећи да „још има времена", а на крају све ради у журби и са грешкама. Решење: разложити задатак на микро-кораке са међуро́ковима.

Хофштатеров закон

„Све увек траје дуже него што очекујете, чак и ако узмете у обзир Хофштатеров закон". Ово је самоиспуњавајуће пророчанство: процене су увек оптимистичне, јер програмери не узимају у обзир непознате непознанице (ункновн ункновнс). Решење: удвостручите сваку процену дату без разлагања.

Вишеструки рокови без приоритета

Када програмер има 5 задатака са истим роком, не зна за шта да се ухвати. Резултат: сви задаци су урађени напола. Решење: један приоритет за један временски период. Ако су рокови у сукобу — ескалирати менаџеру за преприоритизацију.