Norveon блог

Workalitic је сада на Android-у, и направљен је за онога ко држи кључ у руци

Norveon doo — Fri, 16 Oct 2026 00:00:00 GMT

*Ниједна контролна табла није угурана на екран од шест инча током израде ове апликације.* [Workalitic](https://workalitic.com) је наша платформа за радне налоге и залихе намењена малим тимовима теренског сервиса. Замислите HVAC екипе, фирме за одржавање, управнике зграда, електричаре. Већина њих нам дође док посао још воде преко WhatsApp групе и табеле коју разуме тачно једна особа. Од данас је Workalitic апликација на [Google Play-у](https://play.google.com/store/apps/details?id=com.norveon.workalitic&hl=en). Следећи је iOS. ## Веб апликација је већ радила на телефонима Workalitic од првог дана ради у мобилном прегледачу. Можете да га закачите на почетни екран и наставља да ради кад веза пукне. Менаџеру који између два састанка проверава како дан тече, то је и више него довољно. А сад замислите техничара у котларници, с рукавицама на рукама и батеријском лампом у једној од њих, како покушава да нађе прави радни налог у пуном веб приказу. Рећи ће себи да ће то „попунити касније“. Касније обично значи никад. То је део до ког нам је било стало. Све што Workalitic ради за менаџера (извештаји, трошкови, стање залиха) зависи од тога да човек на терену унесе шта је урадио. Ако то захтева превише додира, прескочиће, а менаџерове бројке ће тихо почети да лажу. Зато нисмо преносили веб апликацију. Питали смо се шта техничар заиста ради на послу, којим редом, и око тога направили апликацију. ## Шта је у њој Апликација покрива две Workalitic улоге. Запослени обављају посао. Посматрачи морају да виде шта се дешава, али не могу ништа да мењају. Администратори и менаџери остају на вебу, где планирање и распоређивање ионако имају више смисла на великом екрану. Техничар отвори апликацију и прво види послове који су му додељени. Претрага и филтери су ту за све остало. На послу може једним додиром да започне и заврши рад, а ти сати иду право у извештаје које његов менаџер већ чита. Посао може да пребаци у статус У току или да га означи као Блокиран кад чека део или је неко заборавио да остави кључеве. Блокиран је статус до ког нам је било највише стало. Менаџери га виде одмах, уместо да за њега чују у петак. Чек-листе се штиклирају на лицу места. Коментари остају на послу за онога ко га следећи преузме. Материјал се прати целим путем: преузет из магацина, утрошен на терену, вишак враћен. Стање залиха се ажурира у реалном времену, што је важније него што звучи. Нико не жели да вози преко целог града по део који је неко други узео пре сат времена. Можете и да фотографишете стање пре и после камером и закачите слике уз посао, а push обавештења вам јављају кад вам је нешто додељено. Сами бирате која обавештења добијате. Посматрачи виде исте екране, само без дугмади. Нисмо желели никоме да прикажемо дугме које постоји само да би му рекло да не сме да га притисне. ## Досадан део посла Списак функција је лако написати. Већина израде отишла је на ствари које приметите тек кад се покваре. Слаб сигнал је био највећи изазов. Теренски рад се често одвија у подрумима и на крововима, где је једна црта сигнала добар дан. Апликација зна кад је ван мреже, јасно то каже и не претвара се да је нешто сачувано кад није. Техничару који мисли да је унео три вентила, а није, горе је него ономе ко зна да мора да покуша поново. Дозволе долазе са платформе, не са телефона. Кад менаџер на вебу некоме промени улогу, апликација то прати. Ако апликација и сервер свако за себе воде списак ко шта сме, пре или касније ће се разићи, и неко ће притиснути дугме које ће сервер онда одбити. Пријава не смета. Токени се чувају у безбедном складишту телефона и освежавају се у позадини, тако да техничар на заједничком службеном телефону не куца лозинку сваког дана у 7 ујутру. Апликације које вас на то терају људи обично обришу. Направљена је у Expo-у и React Native-у, истом стеку који користимо за мобилне пројекте за клијенте. То је било намерно. Радије препоручујемо стек који смо сами испоручили и одржавали, са стварним корисницима који се жале кад нешто не ради. О једној Android главобољи са тим стеком писали смо у [нашим белешкама о миграцији на величину странице од 16 KB](/sr/blog/android-16kb-page-size-migration-challenges). ## Зашто се трудимо Уз [Arheev](https://arheev.com) и [Omnotic](/sr/blog/introducing-omnotic-our-pos-hardware-brand), Workalitic је још један производ који сами водимо. Сваки нас је научио нечему што смо касније применили на клијентским пројектима, а клијенти ту лекцију нису морали да плате. Овај нас је подсетио да веб апликација која „ради на мобилном“ и даље може да буде мука за некога ко стоји у котларници. Респонзивни CSS решава распоред. Не решава број додира. ## Пробајте Ако водите тим теренског сервиса, [Workalitic](https://workalitic.com) има бесплатан пробни период од 30 дана са свим функцијама и без кредитне картице. Направите неколико радних налога на вебу, а онда инсталирајте [Android апликацију](https://play.google.com/store/apps/details?id=com.norveon.workalitic&hl=en) на телефоне својих техничара. Ако размишљате о сопственој мобилној апликацији, за свој тим или за своје кориснике, [јавите нам се](/sr/#contact). Тиме се бавимо. *Ниједан техничар није морао да попуни формулар два пута. У томе је и била цела поента.*

Зашто и даље улажемо у менторство

Norveon doo — Wed, 23 Sep 2026 00:00:00 GMT

*Ниједном јуниор инжењеру није додељен списак лектире током настанка овог текста.* Један од наших инжењера месецима се борио с истом врстом бага. Нестабилни интеграциони тестови, сваки пут други тест, сваки пут нешто с тајмингом. Постао је веома вешт у поправљању. Радио је брзо, а у опису PR-а увек је тачно објаснио шта је пошло наопако. Онда је један сениор двадесет минута пратио дељење екрана и рекао: не поправљаш нестабилне тестове, поправљаш заједнички fixture у који све уписује. То је било то. Цела интервенција. Двадесет минута, једна реченица, и проблем који је сваког месеца тихо односио пажњу вредну целог спринта престао је да постоји. Инжењер је могао да пита модел за било који од тих падова и добио би добар одговор. И јесте питао, често, и одговори су били тачни. Али нико му није сам од себе рекао да су сви ти одговори били на погрешно питање, јер нико други није пратио образац кроз месеце. ## Бити продуктиван и постајати бољи нису иста ствар Та разлика се у последње две године замутила, и мислимо да нас то скупо кошта. Инжењер с добрим алатима данас може да испоручи прави посао а да не разуме много о томе зашто он ради. То није критика. То је поента алата. Али испоручивање и раст су се тихо раздвојили, и тим може подуже да изгледа здраво по учинку пре него што ико примети да се ничија процена не развија. Најјасније то видимо у прегледима кода. Нечији код је у реду. У реду је већ годину дана. Али је све време у реду на исти начин, решава исти облик проблема на исти начин, а кад се облик промени, особа се заглави онако како њена историја PR-ова никад не би предвидела. Учинак вам говори шта је неко произвео. Готово ништа вам не говори о томе шта би могао да произведе следећег квартала. ## Преглед кода није менторство Веровали смо да јесте дуже него што је требало, делом зато што је згодно у то веровати. Преглед је већ у календару. Већ подразумева да сениор гледа јуниоров рад. Довољно близу, зар не? Није, из структурног разлога: преглед види артефакт, а не размишљање које га је произвело. Кад PR једном постоји, занимљиве одлуке су већ нестале. Три приступа одбачена у првом сату, погрешан ментални модел због ког је други приступ деловао примамљиво, претпоставка о понашању базе која се показала нетачном, али овог пута случајно ништа није сломила. Ничег од тога нема у diff-у. Можете прегледати само оно што је преживело. А погрешно размишљање је управо оно што вреди ухватити, јер ће следећег месеца произвести другачији баг у фајлу који нико неће помислити да повеже с овим. И даље прегледамо све, само смо престали да очекујемо да преглед обави посао за који никад није био скројен. ## Не можете питати за слепу тачку Очигледан приговор свему овоме у 2026. гласи да је модел доступан у два ујутру, никад није уморан, никад није снисходљив и о вашем фрејмворку зна више од било кога у тиму. Све тачно. Ове алате користимо стално. Део учења који има облик питања учинили су скоро бесплатним, и то је стварни добитак. Инжењер који је некад чекао понедељак да нешто пита сада просто пита. Али свака од тих интеракција почиње тиме што ви знате шта да питате. То је ограничење, и није привремено. Модел може да оспори претпоставку коју ставите пред њега. Не може да прође поред вашег стола, метафорички речено, и примети да већ шест месеци радите нешто чудно. Не прати вас кроз време. Сваки разговор почиње од нуле. Оно што инжењере заиста кочи ретко су рупе у знању. То су навике. Посезање за истом апстракцијом сваки пут. Хронично потцењивање одређене врсте задатка. Ћутање кад се заглавите уместо да питате, што је много већи проблем у [потпуно удаљеном тиму](/sr/blog/why-we-went-fully-remote), где нико не може да види да сте утихнули. Ништа од тога нису питања, и у томе је управо проблем. Неко други мора то да примети уместо вас. ## Сви остали су ово одавно схватили Помало је чудно што софтверска индустрија рад с тренером третира као корективну меру. Ниједан озбиљан спортиста не остаје без тренера кад постане добар. Музичари који наступају тридесет година и даље иду на часове. У оба случаја тренер је често мање способан од онога кога тренира, и то је у реду, јер посао тренера није да буде бољи. Посао му је да гледа споља. Софтвер је ту изузетак. Изградили смо културу у којој тражење ментора звучи као признање слабости, а за сениорност се прећутно подразумева да сте прерасли потребу за њим. Наши најискуснији људи пишу продукциони код од 1997. и још увек извуку више из сата током ког их неко посматра док раде него из већине конференција. Унутар тима то данас углавном никоме није необично. Требало је времена да се стигне дотле. ## Повратна информација у софтверу је лоше калибрисана Ово је у нашој струци важније него у већини других делом и зато што је размак између одлуке и њене последице крајње непредвидив. Погрешите синтаксу и знате за мање од секунде. Погрешите архитектуру и она се компајлира, пролази тестове, глатко прође преглед, оде у продукцију, а онда вас осамнаест месеци касније кошта цео квартал кад стигне захтев који модел података не може да прими. Дотад је онај ко је донео одлуку заборавио да ју је донео, а веза између узрока и последице је неповратно изгубљена. Из повратне информације на тој временској скали не можете учити. Нико не може. Петља је предуга и превише бучна. Ментор је вештачки скраћује. Он је тих осамнаест месеци већ проживео, и то више пута, и може вам у уторак рећи оно што бисте иначе сазнали 2028. Ту нема никакве мудрости, само искуства које је неко већ платио, и то је отприлике најкориснија ствар коју искусан инжењер има да преда даље. Писали смо о [метрици брзине која је сломила тим једног клијента](/sr/blog/the-velocity-metric-that-quietly-broke-our-client), и то је исти неуспех на нивоу организације. Последица је стигла далеко прекасно да би се повезала с одлуком. ## Трење је носећи зид На једно пазимо, јер је лако погрешити и у супротном смеру. Кад се инжењер мучи, први нагон је да му уклоните препреку. Брже је, љубазно је, и обично је погрешан потез, јер учење живи управо у том мучењу. Кад некоме дате одговор, добијате функцију која ради и никакву нову способност. Зато је корисна верзија ужа него што звучи. Пустите људе да се заглаве. Само им немојте дозволити да остану заглављени на нечему у чему нема лекције, или у правцу који је структурно безнадежан. Питање је да ли трење ичему учи, а погодити ту процену је већи део вештине. То је уједно и слабост асистента који је увек доступан. Он трење уклања без разбора. Не уме да разликује муку која вреди од споредног посла који вас само одвлачи, јер не зна шта би требало да научите ове године. ## Да ли је ово свима потребно? Није, и радије ћемо то рећи него вам га продавати. Ако тек почињете, добра књига и заједница одвешће вас даље него ментор, јер су основе добро документоване, а још немате оне специфичне рупе због којих се рад један на један исплати. Ако имате јасно ограничено питање, прочитајте документацију. Ако вам треба преглед кода, тражите преглед кода. Менторство оправдава своју цену кад је повраћај вишеструко већи од уложеног времена, а то обично важи у тачно једној ситуацији: овим се бавите професионално, прошли сте почетничку фазу и ударили сте у плафон чији облик не видите. Тај последњи део је кључни знак. Кад можете да именујете шта вам недостаје, идите и научите то. Кад не можете, а годину дана стојите на истом нивоу, тада се неко ко гледа споља исплати за једно поподне. ## Шта ми заправо радимо Ово смо намерно оставили неструктурираним, јер је сваки формални менторски програм који смо видели изнутра у року од два квартала постао обавеза у календару. У Norveon-у је овако: нико дуго не ради сам ни на чему, рад у пару је подразумеван, а не на захтев, а [наш стендап](/sr/blog/how-we-run-standup-meetings) изричито није статусни састанак, што значи да се оклевање у нечијем гласу чује. То оклевање је обично знак да је неко заглављен на начин који још није успео да преточи у речи. Друга половина је то што [запошљавамо с тим на уму](/sr/blog/how-we-hire-engineers). Нас је 14. Једна особа која питања доживљава као сметњу може да угаси учење у целом тиму, и ниједан програм то не преживи. Ништа у процесном документу није важније од тога да ли најискуснија особа у соби видљиво и даље учи. Узгред, нисмо сасвим сигурни да ово држи воду. Неформалност значи да они који питају добију менторство, а тихи могу дуго да прођу а да нико не примети. Неко ово покрене отприлике два пута годишње и никад нисмо дошли до решења које се не претвори у ону календарску обавезу коју смо избегавали. Са 14 људи то можете да покријете тиме што све познајете. Претпостављамо да то на некој величини престаје да ради, а не знамо на којој. Испоставило се да смо већину овога приметили радећи на [Arheev-у](/sr/#products). Кад исти тим дуго испоручује исти производ, тачно видите ко постаје бољи, а ко је стао у месту, а да је притом савршено продуктиван. На спринт табли то двоје изгледа потпуно исто. Две године касније, уопште не личе. *Ниједан ментор није додељен путем тикета. Неколико разговора се одужило.*

Један производ, много добављача, много канала

Norveon doo — Tue, 01 Sep 2026 00:00:00 GMT

*Ниједна табела није повређена. Неколико их је пензионисано.* Скоро сваки систем за е-трговину претпоставља да производ има цену. То је толико разумна претпоставка да и не приметите да сте је направили док не наиђете на посао у коме не важи. Дистрибуција је један од таквих послова. Исти артикал купујете од неколико дистрибутера, а сваки нуди другачију набавну цену и другачије стање залиха. Продајете га кроз туђе продавнице, а свака хоће другачију цену и узима другачију провизију. Производ у средини је један производ. Скоро ништа везано за њега није у једнини. Ову годину смо провели градећи систем за такав облик посла, за [Inovio doo](/sr/case-studies/inovio-hub). Ево шта бисмо понели у следећи. ## Оба смера су адаптери Увоз од добављача и извоз ка каналу изгледају као различити проблеми. Улаз је XML од једног дистрибутера, CSV фајл од другог, REST API од трећег. Излаз су маркетплејсови од којих сваки хоће сопствени формат фида. Структурно су идентични: нешто спољашње и променљиво, с једне стране границе коју ви контролишете. Зато је сваки добављач адаптер који производи понуде у једном интерном облику, а сваки канал адаптер који конзумира каталог у једном интерном облику. Оно што се мења стоји у адаптеру, а оно што је битно у средини. Елеганција је успутна; права добит је у томе колико кошта следећи. Додати добављача значи написати адаптер. Не значи дирати цене, ни залихе, ни било који други канал. Једно правило је рано зарадило своје место: ништа се не одбацује тихо на граници. Ред који не можемо да упаримо не нестаје у једној линији лога. Ако је активан и има назив, постаје нацрт производа који чека на човека, означен разлогом због ког није могао да се смести, и на сваком следећем пролазу упарује се по својој шифри уместо да се поново креира као дупликат. Улазни фидови стоје и иза заштитног прекидача (circuit breaker), па добављач коме је кренуло лоше јутро добија паузу и пријаву, уместо да га покушавамо изнова до бесвести. ## Израчунајте цену једном Правило које бисмо највише желели да задржимо: ништа не прерачунава цену у тренутку извоза. Нисмо то наследили. Неки канали су на излазу примењивали сопствену формулу марже, па су цена у систему и цена на маркетплејсу биле различити бројеви, а она права постојала је само унутар кода који је генерисао баш тај фид. Питајте зашто је артикал јефтинији на једном маркетплејсу и нико не уме да одговори а да не прочита два генератора фида. Сада је формирање цена један мотор који зна за услове по каналу и производи број који се заиста објављује. Извоз форматира. Не рачуна. Залихе раде исто, изведене у тачно једној функцији из интерне доступности и доступности код добављача. Друга имплементација се третира као баг, јер је друга увек она која одлута. ## Ваши идентификатори припадају другима Ово је оно што је коштало највише размишљања, и оно на шта бисмо скренули пажњу свакоме ко мења каталог. Када мигрирате, природно желите чисте нове интерне идентификаторе. Проблем је што сваки маркетплејс кроз који продајете већ познаје ваше производе по идентификатору који је генерисао стари систем. Та шифра живи у њиховој бази, везана за историју вашег огласа и његово рангирање. Промените је и више не мигрирате, већ оглашавате од нуле и бацате све што су ти огласи зарадили. Зато мигрирани производ и даље одговара на своју стару шифру на каналима који су га већ знали, а за све остало носи нови интерни идентификатор. Моделовање без имало гламура, а од њега зависи да ли миграцију ван фирме нико неће ни приметити или ће коштати четвртину учинка на маркетплејсовима. Општа верзија: када мењате систем, његови идентификатори могу бити баш онај део од ког други зависе, а они нису пристали на вашу миграцију. ## Бек-офис није веб-сајт Прилично рано смо престали да се према администраторском интерфејсу односимо као према веб-сајту. Оператери овде већи део дана раде једну ствар: прелазе дугачке табеле производа, понуда и цена у потрази за редом који је погрешан. Сваки инстинкт који сте покупили градећи маркетиншке сајтове ради против вас. Великодушан празан простор значи мање редова на екрану. Удобних 16px за основни текст значи мање редова на екрану. Сваки милиметар ваздуха који додате кошта корисника управо оно због чега је дошао. Зато је основни текст 12px, размаци су намерно збијени, а број редова по екрану је величина коју оптимизујемо. Отишли смо дотле да укључимо алтернативни сет глифова фонта за l, 1 и I, јер се у уској колони SKU шифри на 12px та три знака заиста тешко разликују, а погрешно прочитана шифра некога кошта десет минута и једну погрешну измену. На дизајн ревизији делује скучено, и тај разговор смо водили више пута, углавном међусобно. Нико ко га користи по цео дан није тражио да га раширимо. ## AI предлаже, човек одлучује Каталог састављен од много дистрибутера је по природи неуједначен. Један добављач шаље пун опис и уредне атрибуте. Следећи шаље назив, цену и фотографију. Оба морају бити довољно добра за маркетплејс који одбија оглас због једне димензије која недостаје. Ту рупу су некада затварали људи, па је квалитет каталога зависио од тога колико сати сте могли да уложите у њега. Зато AI третирамо као сервис за обогаћивање над подацима, из исте породице као и сваки други провајдер података које платформа позива: узме производ који имамо, попуни поља која фидови нису доставили и врати их назад. Предлаже категорију са оценом поузданости, допуњује атрибуте који недостају, изводи логистичка поља и чита слике производа када сам текст није довољан да се закључи. Свако може да позове AI endpoint. Занимљиво је где сме да заврши оно што врати. Ништа што сервис врати не уписује се на производ. Чува се поред њега као предлог на чекању, а оператер га прихвата или одбија у поређењу са тренутном вредношћу. Прихватање се бележи, па годину дана касније и даље можете да кажете која поља је човек унео, а која је човек одобрио. То својство је важније него што звучи. Очигледну глупост неко увек ухвати. Опасна је уверљива али погрешна вредност тихо уписана у запис, која се шири на сваки канал и не разликује се од података које је унео човек. Кад више не можете да разликујете једно од другог, не можете ни да ревидирате, ни да очистите а да не проверите све изнова. Дозволили смо један изузетак: физичке димензије директно попуњавају празна логистичка поља, јер у ширини кутије нема уредничке процене, а порекло се и даље бележи. Искрено, цена свега овога је ред за преглед. Неко мора да седи над њим, и у лошој недељи то је озбиљан део оператеровог дана. Може се рећи да смо превише опрезни, и многи тимови би просто уписали вредности и поправљали притужбе касније. Радије ћемо имати ред него каталог за који не можемо да гарантујемо, али то јесте компромис и направили смо га намерно. ## Шта важи и шире Према свакој спољној страни односите се као према адаптеру, и улазној и излазној. Сваки битан број изводите на тачно једном месту. Пре него што било шта мигрирате, запитајте се које су ваше идентификаторе други већ записали. А тамо где AI обогаћује ваше податке: држите оно што сервис предлаже одвојено од онога у шта ваш систем верује, уз забележен прелаз између њих, иначе завршите са скупом података који никада не можете да ревидирате. Ништа од овога није паметно, али баш од тога зависи да ли вас додавање следећег добављача кошта једно поподне или један квартал, и да ли вам AI обогаћивање оставља бољи скуп података или проблем са квалитетом података који месецима тиња. *Много канала. Један мотор за цене. И сервис за обогаћивање који никад нема последњу реч.*

Како инжењерско лидерство заиста изгледа у тиму од 14 људи

Norveon doo — Wed, 29 Jul 2026 00:00:00 GMT

*Ниједан организациони дијаграм није прецртан током писања овог текста.* У тиму смо једни другима прослеђивали текст из њузлетера Software Leads о [свакодневним активностима инжењерских лидера](https://softwareleads.substack.com/p/engineering-leaders-day-to-day-activities). Аутор тврди да менаџерски посао делује невидљиво поред писања кода, али да није безобличан. То је циклус од шест активности који се понавља цео дан: прикупљање информација, њихово дељење, доношење одлука, утицање на одлуке које нису ваше, постављање правца и планирање. Препознали смо сваку од њих. Схватили смо и да скоро ниједну не радимо онако како оквир прећутно претпоставља, јер је тај оквир написан за менаџера унутар веће организације. Нас је 14 инжењера и дизајнера, потпуно удаљено од 2023, и уз клијентски посао испоручујемо сопствене производе. Ево, дакле, истих шест активности и како свака изгледа у тиму наше величине. Неке постану лакше. Неке постану теже, а на то вас нико не упозори. ## Прикупљање информација Текст каже нешто што бисмо двапут подвукли: све што следи зависи од квалитета онога што прво прикупите. Лоши подаци, лоше одлуке, а за то нећете сазнати недељама. У већој фирми ово је прави посао. Вучете контекст са skip-level састанака, контролних табли, прегледа инцидената и од три тима који исти проблем описују на три начина. Код нас већина тога стигне сама. Писали смо о томе [како водимо стендапе](/sr/blog/how-we-run-standup-meetings), и тај састанак овде ради више посла него било шта друго што радимо. Петнаест минута дневно у којима људи деле оно што им је занимљиво уместо да извештавају о статусу, и добијете живу слику тима коју вам ниједна контролна табла не би дала. Чујете оклевање пре него што неко каже „у реду је“. Квака је у томе што ово ради само зато што смо довољно мали да станемо у једну собу. Не скалира се, и то знамо. Гледали смо клијенте како достигну величину на којој неформални контекст престане да стиже, а нико то не примети по читав квартал, јер изостанак информација не звони на узбуну. Ако вам стендап има 25 људи, то више немате. Имате статусни састанак прерушен у стендап. ## Дељење информација Ово је место где вам мали тим престаје да помаже и почиње активно да вас лаже. Кад сви чују све, претпостављате да сви знају све. Не знају. Неко је био на одмору. Неко је две недеље био закопан у миграцију. Неко се придружио прошлог месеца и нема појма да је оно што сви зовете „она стара наплата“ била свесна одлука, а не случајност. Наше правило из текста о стендапу покрива ово: стендап је пролазан, а све важно мора да се понови писмено. То правило постоји јер смо погрешили. Имали смо одлуке око којих су се сви присутни сложили, које нико није записао, и које су месец дана касније поново отворили људи који једноставно нису били у соби. Двапут. Решење нису нови састанци. Решење је да прихватите да усмени контекст има рок трајања од око недељу дана и да запишете онај мали скуп ствари које морају да га надживе. ## Доношење одлука Најоштрија реченица из текста: чекање на извесност је само по себи одлука, и носи сопствену цену. Ми бисмо додали верзију за мали тим. Кад вас је 14, цена погрешне реверзибилне одлуке је заиста ниска. Можете нешто да пробате, да га омрзнете и да га поништите у оквиру једног спринта. Цена *споре* одлуке је много виша него што изгледа, јер цео тим чека на њу, а нема другог тока посла који би упио кашњење. Зато смо склони да брзо одлучујемо о свему што је реверзибилно, а споро о свему што није. Шема базе, избор фрејмворка, све што дира податке корисника: споро, записано, испрепирано. Која библиотека, која структура фолдера, како именујемо ствари: одлучимо на стендапу, идемо даље, вратимо се ако заболи. Не погодимо увек у коју категорију нешто спада. Обично нас ода то што се „мала“ одлука стално враћа. Кад се нешто реверзибилно поново отвори трећи пут, није било реверзибилно и погрешно смо проценили. ## Утицање на одлуке које нису ваше За менаџера унутар фирме, ово значи суседне тимове. За нас то обично значи клијента. Ово је активност на коју трошимо највише времена и у којој смо у почетку били најгори. Испоручили бисмо техничку препоруку која је била тачна, гледали како је одбијају и закључили да клијент не разуме. А заправо смо одговарали на питање које нико није поставио. CTO-а није ограничавао технички квалитет, него састанак борда за пет недеља. Текст ово описује као разумевање циљева, ограничења и подстицаја ваших колега. У томе је цела ствар. Препорука која игнорише нечије стварно ограничење само је жалба са приложеним дијаграмом. Код нас се променило то што технички аргумент сада везујемо за оно по чему се та особа заиста оцењује. „Ово ће нас касније угристи“ никога не покреће. „Ово додаје две недеље сада, или отприлике шест недеља у Q4 док будете покушавали да затворите рунду“ је реченица на коју неко може да реагује. О једном случају кад је ово кренуло наопако писали смо у тексту о [метрици брзине која је тихо сломила нашег клијента](/sr/blog/the-velocity-metric-that-quietly-broke-our-client). ## Постављање правца Оквир овде говори о две ствари: како приоритете организације претворити у нешто по чему тим може да ради и како сами живети по стандардима које очекујете од других. Прву половину добијамо скоро бесплатно. Не постоји слој између људи који одлучују шта се гради и људи који граде, па приоритетима не треба много превођења. То је права предност малог тима и не намеравамо да је се одрекнемо. Другој половини је свеједно колико сте мали. Ако кажемо да су рокови искрени, а онда тихо надувавамо сваку процену, сви науче право правило за отприлике две недеље. Ако кажемо да стендап није састанак за извештавање, а онда га оснивач искористи да провери напредак, сад је то састанак за извештавање, шта год писало у документима. На [Arheev-у](/sr/#products) смо ово осетили најдиректније. Кад водите сопствени производ по сопственом процесу, раскорак између онога што тврдите и онога што радите престаје да буде апстракција. Нашли смо неколико места где су наши савети клијентима били бољи од наше сопствене праксе. ## Планирање Како од тога где сте стићи тамо где желите, корак по корак. Ми намерно планирамо на кратак рок: двонедељни спринтови са радним софтвером на крају и први радни демо за две до четири недеље. Дугорочно планирање није безвредно, али у тиму наше величине тачност плана нагло пада после отприлике месец дана. Ако се правимо да није тако, добијемо само документ уз који се сви осећају организовано. Једина ствар коју планирамо дугорочно су људи. Ко је на чему, коме је досадно, ко шест месеци није такао ништа ново. Ту је време припреме много дуже него код било које техничке одлуке, и ту кашњење заиста скупо кошта. ## Шта бисмо понели из тога Шест активности држи воду. Рекли бисмо да оквир описује нешто стварно и углавном невидљиво, и већ то га чини вредним читања. Оно што не каже, а што бисмо додали: у малом тиму три од њих постану лакше саме од себе, што не значи да сте их решили. Информације стижу саме док не престану. Правцу не треба превођење док се не појави слој коме треба. Две које никад не постану лакше, ни на једној величини, јесу утицање на одлуке које нису ваше и живљење стандарда за који тврдите да га држите. У те две можете да постанете бољи већ сутра, без икакве реорганизације. *Ниједан оквир није повређен. Са неколико смо се благо не сложили.*

Лансирали смо хардверски бренд (да, софтверска компанија је то урадила)

Norveon doo — Mon, 20 Jul 2026 00:00:00 GMT

*Ниједна лемилица није повређена током израде ове објаве.* Ми смо софтверска компанија. Пишемо React, испоручујемо мобилне апликације, водимо HR платформу. А сада продајемо и хардвер за продајна места. Упознајте [Omnotic](https://omnotic.com): наш бренд POS хардвера за српско тржиште. Два производа на лансирању, термални штампач за рачуне THP-803 и POS терминал са екраном осетљивим на додир MPOS-M6-150, за кафиће, ресторане, продавнице и магацине. Ево зашто је софтверска компанија то урадила и шта смо научили. ## Рупа није била у хардверу Ако водите кафић или малопродајну радњу у Србији и штампач за рачуне вам откаже усред смене, опције су вам суморне. Наручите замену из иностранства и чекате недељама. Купите од препродавца који подршку сматра туђим проблемом. Пробијате се кроз рекламације које се одбијају између увозника, дистрибутера и произвођача на другом континенту. Сам хардвер је решен проблем. Термални штампачи и терминали са екраном на додир зрела су, поуздана технологија. Оно што је покварено јесте све *око* хардвера: доступност, подршка, фактурисање и неко локални ко се јавља на телефон. Ту рупу не затвара инжењеринг. Затварају је бренд, продајни канал, локалне залихе и подршка која се заиста јавља. А то су, игром случаја, ствари које знамо да изградимо. ## Шта је Omnotic заправо Да прецизирамо шта тачно радимо, јер „лансирали смо хардверски бренд“ може да значи много тога. Не пројектујемо штампане плоче. Одабрали смо проверене уређаје, око њих изградили бренд Omnotic и преузели све што је једној фирми потребно да купује са поверењем: - **Локалне залихе.** Уређаји на лагеру у Србији. Без чекања на царину. - **Домаће фактурисање.** Једна домаћа фирма на фактури, у динарима, са уредном документацијом. - **Подршка на српском.** Када се нешто поквари у 11 ујутру у суботу, разговарате са нама, а не са кол-центром у иностранству. - **Поштени производи.** THP-803 штампа брзином од 260 mm/s, са секачем предвиђеним за 1.5 милиона резова. MPOS-M6-150 је терминал од 15 инча, IP65 сертификован, без вентилатора, са надоградивим модулима, тако да не застари годину дана након што га купите. ## Део који нам је заиста био нов Прављење веб-сајта било је лак део. Од тога живимо. Нов је био сав остатак: позиционирање бренда за публику коју не занимају технолошки стекови, постављање продајног канала од понуде до испоруке, писање садржаја о производима на српском за људе који вредност мере у преживљеним сменама, а не у испорученим функцијама, и осмишљавање подршке око пулта који не сме да престане да ради. Ово је исти посао који радимо за клијенте (бренд, веб, е-трговина, излазак на тржиште), само што овај пут повратне информације са тржишта слећу директно на нас. Када понуда не доноси продају или некога изнервира подршка, између нас и тржишта нема клијента да прими ударац. То су сада два производа која сами водимо. [Arheev](https://arheev.com) нас је научио шта је потребно да се софтвер направи и одржава у продукцији. Omnotic нас учи шта је потребно да се физички производ изнесе на тржиште. Шта год научимо на њима, користимо у раду са клијентима. ## Шта следи Omnotic намерно креће са два производа. Штампач и терминал покривају пулт; све остало чека док не докажемо да можемо да подржимо оно што продајемо. Ако водите угоститељски објекат, малопродају или логистику у Србији, а опрему на пулту вам на окупу држи само нада, погледајте [omnotic.com](https://omnotic.com). А ако вас занима шта бисмо направили за вас (бренд, продавницу, цео канал), управо тиме се бавимо. [Разговарајмо](/sr/#contact).

Метрика брзине која је тихо сломила нашег клијента

Norveon doo — Tue, 07 Apr 2026 00:00:00 GMT

*Ниједан стори поен није повређен током писања овог текста. Већ су били мртви.* Оснивач са којим радимо увукао нас је прошлог лета на састанак. На екрану је имао графикон. Завршени стори поени по спринту, две године уназад. Линија је упорно ишла навише. „Погледајте ово“, рекао је. „Продуктивнији смо 40% него пре осамнаест месеци. Па зашто онда делује као да се све распада?“ Погледали смо графикон. Онда смо погледали његов систем за праћење багова. Онда одлив корисника у последњих шест месеци. Графикон је лагао. Не намерно. Мерио је погрешну ствар. ## Како број постане свето писмо Овај клијент је почео да прати брзину тима (velocity) почетком 2024. Разумна ствар. Већина тимова који раде било шта налик Scrum-у то прати. Њихов VP инжењеринга ју је поставио, представио на месечном састанку борда, и борду се допало. Број расте, борд срећан. Кад се број једном покаже борду, престаје да буде број. Постаје циљ. VP је отишао шест месеци касније. Број је остао. Његов наследник је наследио контролну таблу, очекивање борда и неписано правило да брзина мора да настави да расте. Ево шта нико у том тиму не би рекао наглас: сваки инжењер је тачно знао како да број порасте. Великодушно процењивати. Разбијати посао на мање тикете. Прескочити задатак чишћења. Не јављати се за гадан баг, јер квари просек спринта. Графикон је наставио да расте. Сви су знали шта се дешава. Нико то није могао да заустави, јер је борд гледао. ## Шта смо нашли кад смо заиста погледали Провели смо два дана прелазећи њихов код и њихове тикете. Не контролну таблу, него стварни посао. Тестови су се извршавали 47 минута. Пре осамнаест месеци, 9. Нико није имао времена да то поправи јер поправка није вредела ниједан стори поен. Три од пет њихових кључних сервиса радила су на верзији Node-а којој је подршка истекла осам месеци раније. Тикет за надоградњу је постојао. У беклогу више од годину дана. Једанаест стори поена. Нико га није узео. Једанаест поена потрошених на три мале функционалности померало је графикон више него једанаест поена потрошених на то да се не сломи продукција. Број багова је порастао 3x у односу на претходну годину. Али багове су процењивали на један или два поена, а функционалности на пет или осам. Па је тим технички „радио више“ док је испоручивао гори производ мањем броју задовољних корисника. Број на графикону и здравље производа нису имали везе једно с другим. Штавише, кретали су се у супротним смеровима. ## Зашто нисмо могли просто да им кажемо да престану Рекли смо оснивачу: убијте метрику. Погледао нас је као да смо му предложили да запали канцеларију. „Борд види овај број сваког месеца. Не могу само да престанем да им га показујем. Чиме да га заменим?“ То је део о коме нико не прича кад вам каже да је метрика лоша. Не можете тек тако да уклоните метрику коју је управа навикла да гледа. Морате да је замените нечим чему више верују. А ако то немате спремно, заглавили сте. У исту замку смо гледали како упадају сениор инжењери када се противе праћењу брзине. Аргумент им је добар, али немају чиме да је замене. Ништа се не мења и број наставља да расте док производ наставља да се квари. Морали смо да изградимо замену пре него што смо смели да дирамо оригинал. ## Чиме смо је заменили Нисмо изабрали један број. Изабрали смо четири. Ниједан није савршен. Све их је теже изиграти него стори поене. Прво: време од „баг пријављен“ до „баг затворен у продукцији“ за најгорих 10% багова. Не просек, јер просек лаже. Бол живи у дугом репу. Ако вашим најгорим баговима треба три месеца да се затворе, то вам говори да ли ваш тим заиста испоручује квалитетан посао. Друго: број измена испоручених недељно које су дотакле код старији од годину дана. Ово смо украли од навике коју смо изградили интерно. Ако нико не дира стари код, ваш тим га или избегава или га не разуме. Обоје је лоше. Здрав тим се враћа старом коду, прави мала побољшања, брише ствари, рефакторише успут. Треће: проблеми које пријаве корисници, по активном кориснику месечно. Не сиров број багова. Број багова расте кад испоручујете више функционалности. Проблеми по кориснику узимају раст у обзир. Ако овај број расте док расте и ваша корисничка база, имате проблем који брзина никад неће открити. Четврто: поверење инжењера у код, како га они сами оцењују. Питамо једном месечно. Једно питање: „Колико сте сигурни у код који испоручујете овог месеца, на скали од 1 до 5?“ Анонимно. Саберемо и покажемо тренд. Кад поверење падне, нешто није у реду, и обично је то видљиво недељама пре него што било која друга метрика то ухвати. Три месеца смо их борду представљали упоредо са старим графиконом брзине. Онда смо избацили брзину. Нико из борда није питао где је нестала. ## Где смо ухватили сами себе Ово не пишемо са неке безбедне позиције спољног стручњака. Негде у четвртом месецу ангажмана приметили смо нешто непријатно у вези са сопственим праћењем у Norveon-у. Бројали смо спојене PR-ове недељно као груб пулс тимског учинка. Не за борд, не за било кога споља, само за себе. Док смо копали по клијентовој историји, морали смо да погледамо и сопствени број. Два инжењера су доследно спајала највише PR-ова. Они су уједно најчешће испоручивали малу поправку која две недеље касније сломи нешто друго. Један инжењер је спајао најмање PR-ова. Он је уједно био инжењер чији се код никад није враћао као баг, коме су други веровали да им прегледа посао, и који је током претходне године тихо поправио три најгора дела нашег кода. Наш интерни број је награђивао погрешне људе. Не на неки крупан начин. Нико није добијао отказ ни унапређење на основу њега. Али обликовао је то како смо на ретроспективама причали једни о другима, и људи који су заслуживали више признања добијали су мање. Убили смо га. Два месеца га нисмо заменили ничим док смо смишљали шта заправо желимо да знамо. Сад уопште не пратимо број PR-ова. Једном месечно сваки инжењер подели једну ствар коју је испоручио а на коју је поносан, и једну ствар у коду коју би волео да је имао времена да поправи. Мања прецизност. Више искрености. ## Део који је тешко прихватити Лоша метрика је гора од никакве. Без метрике морате да се ослоните на процену, да разговарате са људима и гледате стварни посао. То је споро и не стаје на слајд. Лоша метрика значи да имате број, број делује објективно, и број вас тихо усмерава ка одлукама које вам штете. Стори поени по спринту нису једини кривац. Видели смо да исто ради и проценат покривености тестовима. Линије кода. Учесталост пуштања у рад. Чак и доступност система кад се мери сама. Сваки број који је лако изиграти и лако представити на крају ће бити изигран и представљен. Тест који сада користимо пре него што пристанемо да било шта пратимо: ако бисмо шест месеци агресивно оптимизовали за овај број, да ли би производ заиста био бољи? Или бисмо само били бољи у производњи броја? Ако не можемо искрено да одговоримо, не пратимо га. ## Где је тај клијент сада И даље прате четири метрике. Дуги реп багова им је пао око 60% за осам месеци. Пали су и проблеми по кориснику. Број поверења се најспорије опорављао. Требало је скоро годину дана да се врати тамо где је био пре ере јурења брзине. То кашњење нешто говори. Поверење које тим има у сопствени рад гради се годинама, а оштети за месеце. Ниједна метрика вас о томе не упозорава у реалном времену. Док контролна табла то ухвати, већ сте изгубили људе који би то поправили. И даље им помажемо. Нису готови. *Тренутно помажемо другом клијенту да се одвикне од опсесије „учесталошћу пуштања у рад“. Питајте нас за шест месеци да ли је нова контролна табла преживела сусрет са бордом.*

Како запошљавамо инжењере

Norveon doo — Tue, 24 Feb 2026 00:00:00 GMT

*Током овог интервјуа нико није исписивао алгоритме по табли.* Инжењере смо запошљавали на погрешан начин више пута. У раним данима Norveon-а радили смо оно што сви раде. Објавимо оглас, скупимо CV-јеве, пошаљемо задатак за кућу, одржимо технички интервју, дамо понуду. Стандардан процес. Деловало је професионално. А онда бисмо некога запослили и у року од месец дана схватили да није прави избор. Или бисмо изгубили доброг кандидата који је прихватио посао негде другде јер смо били преспори. Променили смо ствари. Ево шта радимо данас. ## Зашто смо престали да шаљемо задатке за кућу Кандидати које смо највише желели да запослимо имали су најмање времена да их ураде. Сениор инжењери са послом, породицом, споредним пројектима. Добили би наш задатак и одмерили га наспрам још три која су примили те недеље. Приметили смо и да квалитет послатих решења нема никакве везе са учинком на послу. Запошљавали смо људе који су предали углачан рад, а онда се мучили кад би ствари постале неуредне. Одбијали смо људе чија су решења била груба, а који су се касније, када бисмо се негде другде срели, показали као одлични. Сигнал је био лош. Цена за кандидате висока. Укинули смо их. ## Шта радимо уместо тога Три корака. **Кратак разговор.** Тридесет минута. Желимо да знамо шта је особа правила, шта тражи и да ли постоји очигледан несклад. У исто време и ми се њима представљамо: многи добри кандидати имају опције и неће направити следећи корак ако им се после тридесет минута не свидимо. **Радна сесија.** Два сата. Бирамо нешто стварно: прави баг из наше базе кода, спор endpoint који одавно хоћемо да поправимо или неуредан код за који желимо друго мишљење. Решавамо га заједно, а неко од нас цело време ради у пару са кандидатом. Ово плаћамо. Реч је о два сата нечијег времена и тражимо од те особе да заиста ради. **Кратка провера препорука и понуда.** Ако је сесија прошла добро, реагујемо брзо. Губили смо кандидате тако што бисмо после доброг интервјуа нестали на две недеље. ## Шта заправо тражимо Не тражимо тачан одговор, а ни чисто решење. Посматрамо како неко размишља наглас. Да ли поставља питања пре него што загризе? Да ли чита код пре него што га мења? Да ли паничи кад нешто не ради, или постаје методичан? Најважније је шта раде кад наиђу на нешто што не знају. Добри инжењери кажу „Ово бих иначе изгуглао, смета ли вам?“ или „Нисам упознат са овим делом стека, можете ли ми дати контекст?“ То нам говори више него то да ли умеју да обрну бинарно стабло. ## Искрен компромис Ово нашем тиму одузима више времена него слање задатка за кућу. Два сата у нечијем календару, плус припрема, плус све што следи после. Не можемо да одржимо пет оваквих сесија у једној недељи а да то не утиче на остали посао. Зато смо избирљивији око тога кога позивамо на сесију и више времена улажемо у тај први разговор да бисмо били сигурни да има смисла. Нас је четрнаесторо. Не запошљавамо често. Кад запошљавамо, важније нам је да погодимо него да будемо брзи. Четворо инжењера запослено је на овај начин. Троје је и даље са нама. Једна особа се преселила у други град и нисмо успели да рад на даљину уклопимо у њену ситуацију. Нема драматичних прича о промашеним запошљавањима, али нема ни оних прича типа „на папиру одлично, у пракси сасвим другачије“ које су се раније дешавале. Ако запошљавате педесет инжењера годишње, овако вероватно не може. Ако запошљавате петоро, размислите да ли је уложено време заиста толико другачије од прегледања двадесет задатака за кућу. *Баш ове недеље водимо једну овакву сесију. Питајте нас за месец дана да ли смо дали понуду.*

Како водимо стендап састанке (није дневни Scrum)

Norveon doo — Fri, 30 Jan 2026 00:00:00 GMT

*Током овог састанка нико није ажурирао ниједну таблу.* Не волимо да радимо са Агилним Оквирима™ попут Scrum-а. Знамо како се то ради. Водили смо тимове који раде по Scrum-у и сличним методологијама. Има ситуација у којима то сасвим добро функционише. Једноставно нам то није најефикасније и најпријатније у свакодневном раду. Ипак, обожавамо концепт дневног стендапа. То је обично прва ствар коју уведемо када се придружимо новом клијентском тиму који га нема. Али наше стендапе не водимо као дневне scrum-ове, па смо закључили да вреди поделити како их заправо радимо, и интерно у Norveon-у и са тимовима са којима сарађујемо. ## Како бисмо ово данас поставили Ево како бисмо то објаснили новом тиму: **Циљ је да поделите занимљиве ствари важне за ваш тим и укажете на блокаде.** Шта се рачуна као „занимљиво“ зависиће од контекста. Користите здрав разум и не устручавајте се да питате групу да ли им је нешто занимљиво. **Састајемо се свакодневно у 12:03, пре ручка, на отприлике 15 минута.** Неки дан је то 10, неки други можда 20. Неко мери време ако затреба, али рачунамо на све да буду кратки. **Ово је пролазно.** Без табли, без белешки. Ако неко подели нешто критично, мора то да понови и писмено, асинхроно. Имејл, Slack, свеједно. **Ово није састанак за извештавање.** Сасвим је у реду да неких дана не поделите ништа. Чак то и охрабрујемо. Највероватније не радите сваког дана нешто вредно дељења. Да, озбиљно мислимо. Видећете да и ми то радимо. **Чућете новости које вас се директно не тичу.** Можда ствари које не разумете у потпуности. То је нормално и намерно. Ваш циљ је да будете пажљиви, останете радознали и покушате да пратите шта сви деле. Питања постављајте после. **На сваких неколико месеци преиспитујемо овај формат.** Разматрамо и да га укинемо. Овај облик је резултат година ситних измена. Много нам се свиђа, али није универзално решење. Негде морамо да почнемо. ## Шта се рачуна као „занимљиво“ Овај део је намерно нејасан. Шта вреди поделити зависи од тима и контекста. Да будемо конкретнији, ево шта најчешће виђамо да се дели: - **Открића.** Нова технологија, нови део стека, нова пословна прилика. - **Напредак на функционалностима.** Нешто је започето, значајна прекретница, издање, повратне информације из података. - **Предстојећи пројекти.** Резултати discovery фазе, налази истраживања, пословни или правни захтеви. - **Проблеми са поузданошћу.** Багови, испади, post mortem анализе, промене у перформансама. - **Организационе промене.** Ново запослење, нови тим. - **Лични догађаји.** Бебе, селидбе. - **Блокаде.** Потребан вам је review, проблем у комуникацији, недостатак јасноће. - **Канцеларијске вести.** Нове политике, предстојећи тимбилдинзи. ## Шта овај састанак није Рецимо изричито чему овај састанак не служи: **Ажурирању табле.** То је боље радити асинхроно. **Извештавању или праћењу задатака.** Исто. Поготово зато што неће сви свакога дана имати шта да поделе. **Позивању људи на одговорност.** Људи овде су професионалци и не би требало да им треба дневни састанак да докажу да напредују. Ако се неко с тим мучи, то треба препознати и решити на другом месту. **Планирању дана.** То радите у мањим, фокусираним групама. Не сваки дан, а чланови тима треба да буду слободни да својим пројектима управљају што самосталније. **Приморавању људи да буду присутни рано ујутру.** Да, видели смо да се то дешава. **Достизању конкретног циља.** Пошто ово није Scrum, можда нема ни спринта ни циља спринта. Достизање циљева биће нуспроизвод тога што имате кохезиван, ефикасан тим. ## Зашто мислимо да ово функционише Главне предности кратког свакодневног окупљања: **Изградња емпатије.** Пре него што вам стигне велики PR на преглед, већ ћете чути инжењера како прича о њему. Имаћете контекст о техничким одлукама, мукама, компромисима. Знаћете и понешто о његовом стању духа. Касни ли? Под стресом је? Можете прилагодити комуникацију. Исто важи и када PM подели притисак који стиже са пословне стране. **Откривање шта други раде.** Током година научили смо толико тога о раду инжењера у областима које смо слабије познавали, само слушајући их како свакодневно објашњавају кроз шта пролазе. Још је боље кад су присутни и дизајнери и PM-ови и кад и они деле. **Стварање прилика за дискусију.** Ако останете закључани у својим задацима и тикетима, краткорочно ћете можда бити продуктивнији, али ћете имати веома узак фокус. Тако ћете мање моћи да утичете на ствари. **Опипавање пулса тима.** Да ли се људи осећају добро, продуктивно, позитивно? Или се сви муче? Ово нам је посебно важно као дистрибуираном тиму у коме не можете рачунати на разговоре поред апарата за кафу. **Изградња интуиције о томе ко ради на чему.** Кад месецима слушате некога како прича о некој теми, то вам остане. Знаћете коме да преусмерите питања кад дође тренутак. **Побољшање динамике тима.** Као што редовни 1:1 састанци са менаџером граде радни однос, редовна интеракција са колегама далеко је ефикаснија од радионице једном у тромесечју. И мали бонус за тимове који раде из канцеларије: одржавање пре ручка природан је начин да се заврши преподне и да људи заједно оду на јело. Јефтин тимбилдинг. Изненађујуће ефикасан. ## Питања која увек добијамо Ово смо током година увели у многим тимовима. Укупан резултат био је позитиван. Нису сви добили 100% вредности, али се довољно исплатило да наставимо. Ево питања и приговора који се увек појављују. ### „Ово ме омета. Боље ми је да се фокусирам на свој код.“ Пошто се одржава сваког дана, можете да испланирате дан око њега. Слажемо се да омета. Али као и редовни 1:1 састанци, ово је инвестиција. Можда данас не делује исплативо, али вредност постаје видљива уз редовну праксу. Можда мислите да је ваша улога искључиво писање кода, прављење Figma дизајна или састављање PRD-ова. Посао је ипак шири од тога. Разумевање сопственог тима важније је него што бисте очекивали. Ово време ће углачати будуће интеракције и уштедети вам главобоље касније. ### „Ово би требало да радимо асинхроно.“ Пошто је циљ изградња емпатије и повезаности, писмено дељење делује непродуктивно. Још нисмо убеђени да читање Slack поруке има исти ефекат као гледање некога како исту ствар дели усмено. Уз то, писана ажурирања остављају траг и временом ће почети да личе на извештавање. А то је управо оно што покушавамо да избегнемо. ### „Нико неће разумети на чему радим.“ Понекад ћете радити на нечему шкакљивом што само ви савршено разумете. То је у реду. Потрошите мало више времена на објашњавање контекста. Можда ћете морати да га понављате чешће, што је додатни посао. Али корист је двострука: више људи се упозна са вашом темом, а ви постајете бољи у томе да дубок технички рад учините разумљивим. Обоје вреди. ### „Ја сам дизајнер, не занима ме шта раде програмери.“ Мислимо да на то гледате погрешно. Ако правите софтвер, без међусобног разумевања са инжењерима нећете далеко стићи. Ако развој видите само као детаље имплементације, ограничићете то које дизајне заиста можете да изнесете пред кориснике. Осим ако вам је посао само да производите мокапе и статичке материјале, вероватно то не желите. ### „Ја сам инжењер, не занима ме неинжењерски посао.“ Такође погрешан приступ. Невероватно је корисно разумети више од саме технологије када правите производе. Можда вам то није омиљена тема, али слушање о дизајну пар минута дневно помоћи ће вам да уочите пречице, да расправе о дизајну лакше теку и да превише сложена решења лакше доведете у питање. Охрабрили бисмо вас да свој посао видите као нешто више од писања кода. Отварање ка другим областима добар је пут до тога, а овде имате прилику да учите само обраћајући пажњу неколико минута сваког дана. Није лоша погодба. ### „Већ имамо превише састанака.“ Ако имате много других састанака, радије бисмо преиспитали и укинули њих. Дневни стендап помаже да се смањи укупан број састанака тако што спречава проблеме и неспоразуме. Његово укидање ослобађа 15 минута, али ће касније коштати много више сати. ### „Ово није у складу са Scrum-ом.“ Тачно. Није дневни scrum и нема исте циљеве. ### „Кажете да није извештавање, али заправо јесте.“ Разумемо зашто може тако да делује. Али не бележимо шта се дели, не извозимо то ван тима. Охрабрујемо вас да делите оно што је занимљиво, а то неће увек бити директан напредак на вашим задацима, што ово чини ужасним алатом за извештавање. Далеко радије користимо наш уобичајени систем за праћење тикета да видимо шта се дешава. ### „Не осећам се пријатно да не поделим ништа.“ Ако сте нови у тиму, то је нормално. Не брините. Видећете друге како то раде и временом би требало да делује мање застрашујуће. ### „Може ли заиста да се не подели ништа?“ Да. „Ништа посебно занимљиво од прошлог пута“ пролази. „И даље на истом задатку, нема ништа ново“ такође пролази. Ако неко више дана заредом нема шта да подели, то обично нешто говори. Из искуства, разлог је обично један од три: - **Мисле да њихове теме нису занимљиве.** Вреди одвојити минут и истаћи зашто би људи желели да чују о одређеном делу њиховог посла. - **Имају дубљи проблем.** Са процесом, послом, тимом, компанијом или животом уопште. Ово захтева пажњу од случаја до случаја и обично је видљиво и ван стендапа. - **Заглавили су и не осећају се безбедно да то поделе.** Ово обично прође само од себе када виде да други отворено деле блокаде. *Ниједан фрејмворк није повређен током израде овог формата стендапа. Резултати могу да варирају.*

Све организације стартап тима које смо пробали (и зашто су се све распале)

Norveon doo — Fri, 28 Nov 2025 00:00:00 GMT

[image1]: /images/blog/2025-11-28.jpg "Све организације стартап тима које смо пробали" ![Све организације стартап тима које смо пробали][image1] *Не постоји савршена структура тима, само различити начини да будете заглављени.* Прошлог месеца нас је један оснивач питао: „Како да организујемо наш инжењерски тим?“ Насмејали смо се. Не зато што је питање лоше. Него зато што смо гледали како тимови пробају сваки одговор и како се сви на крају распадну. У Norveon-у нас је 14. Сви смо генералисти. Нама то одговара. Али радили смо са клијентом који је за две године порастао са 8 на 32 инжењера. Свака реорганизација одвијала се пред нашим очима. Ево шта се заправо десило. ## Подела по технологијама Кад нарасту до око 10 људи, већина тимова се подели по технологији. Фронтенд са фронтендом. Бекенд са бекендом. Мобилни заједно. Овај клијент је то урадио у јуну 2023. Укупно 18 инжењера. React веб апликација, Swift и Kotlin мобилне апликације, Node.js бекенд. Три тима. Радило је три месеца. ## Зашто се распало Свака функционалност је захтевала сва три тима. Нови ток за увођење корисника? Бекенд прави API-је, фронтенд прави форме, мобилни ажурира апликације. Три тима морају да се усклађују због једне функционалности. Фронтенд се жалио да API-ји нису спремни. Мобилни се жалио да су API-ји прављени за веб. Бекенд није имао појма зашто уопште прави половину тих ендпоинта. Нико није био одговоран ни за један део производа. Сви су дирали све, па нико није заиста разумео како било шта ради. До четвртог месеца, сваки стендап је био „чекамо бекенд“ или „блокирани смо изменама API-ја“. ## Сквадови (као у Spotify-ју) Следећи покушај: организација око области производа. Сквад A: управљање корисницима. Сквад B: основне функционалности. Сквад C: наплата. Сваки сквад је добио фронтенд, бекенд и мобилне људе. Деловало је много боље. Сваки тим је одговарао за своју област. Могли су да испоручују без чекања на друге. Трајало је годину дана. ## Шта је убило сквадове Нико није радио на техничким стварима. Надоградња React Router-а је стајала у беклогу осам месеци. Тестови су са 3 минута порасли на 55. Чији је посао био да то поправи? Ничији. iOS програмер у скваду A није имао с ким да прича о iOS проблемима. Сквад B је изабрао једну библиотеку за стање, сквад C другу. Технички дуг се гомилао. Сваки сквад се мерио по функционалностима, не по квалитету кода. До једанаестог месеца, три инжењера су прегорела. ## Додавање чаптера Па су додали чаптере. Сви фронтенд људи у фронтенд чаптер. Сви бекенд у бекенд чаптер. Вође чаптера су се изборили за 20% времена за технички рад. Ажурирање фрејмворка, дељење знања, техничке одлуке. Прва два месеца су била сјајна. Ажурирања су завршили. Техничка предавања су се редовно држала. Онда је почела свађа. ## Проблем са чаптерима Продакт менаџери против вођа чаптера. Сваки спринт. „Зашто Alice ажурира зависности уместо да прави функционалности?“ „Зашто је Bob прескочио планирање спринта због састанка чаптера?“ Почели су да прате проценте. Alice: 23% времена у чаптеру. Bob: 11%. Сви су то мрзели. Инжењере су вукли на две стране. PM сквада хоће функционалност до петка. Вођа чаптера хоће вас на радионици. Бирајте. После шест месеци, људи су почели да дају отказ. ## Платформски тим Следеће: посвећен тим за технички рад. Пребацили су бекенд лида, два мобилна инжењера и једног фронтенд инжењера. Продуктним сквадовима су тако остале празне столице. Сквад A спао на једног бекенд инжењера. Сквад B изгубио половину мобилног капацитета. Али свађа је престала. Платформски тим је радио технички посао. Продукт сквадови су правили функционалности. Бар на папиру. ## Нови проблеми Бекенд лид никад није имао времена да помогне свом старом скваду. Сквад A је заостајао. Њихов једини бекенд програмер се давио. Мобилне инжењере су стално враћали на рад на производу. Клијенти су се жалили да iOS и Android нису усклађени. Фронтенд инжењер у платформском тиму је после три месеца хтео да да отказ. Ажурирање библиотека није забавно као прављење функционалности. Најгори део: остали инжењери су престали да маре за квалитет кода. „Платформски тим ће то поправити“ постао је изговор за аљкав код. Платформски тим је почео да додаје процесе. Између „архитеката“ и „људи који раде прави посао“ родила се огорченост. ## Привремени пројектни тимови Укинули су платформски тим. Нови план: привремени тимови за велике пројекте. Пројекат Alpha: надоградња React-а. Троје фронтенд људи, два месеца. Пројекат Beta: поновна изградња API-ја за мобилне. Двоје бекенд, двоје мобилних, два месеца. Пројекат Beta је трајао четири месеца уместо два. Лоше процењен обим. Прекасно за отказивање. Пројекат Alpha је после месец дана изгубио човека. Додали замену. Увођење трајало три недеље. Пројекат трајао седам месеци уместо два. Инжењер који је остао свих седам месеци је прегорео. Дао отказ месец дана пошто је пројекат завршен. Пројекат Beta је отказан у трећем месецу. Превише сложен. Шест месеци касније требало је да промене нешто из пројекта Alpha. Тима више није било. Првобитни инжењер дао отказ. Нико није знао како ради. ## Staff инжењери Тренутна поставка: унапредили двоје људи у staff инжењере. Један бекенд, један фронтенд. Они круже. Помажу где треба. Вратили чаптере. Правило 20% времена. Али овог пута без праћења. Само поверење. Ради већ осам месеци. Бекенд staff је помагао скваду A док нису запослили некога. Фронтенд staff је водио надоградњу React-а. Staff инжењери воде месечне „дане ажурирања“. Неколико људи из сваког сквада проведе дан ажурирајући зависности и додајући тестове. Чаптери се састају сваке две недеље. Дељење знања. Техничке одлуке. Без додељивања посла. Није савршено. Staff инжењерима никад не достаје времена. Тешко их је запослити. ## Шта смо научили Свака структура се на крају распадне. Технолошки тимови се распадају од терета координације. Сквадови се распадају кад се технички рад игнорише. Чаптери стварају сукобе. Платформски тимови се одвоје од стварности. Пројектни тимови пробијају рокове. У Norveon-у нас је 14. Сви смо генералисти. За нашу величину одговара. За 50 људи не би. Овај клијент је сада на 32 инжењера. Већ се виде пукотине у моделу са staff инжењерима. ## Ако сте сада у тој ситуацији Не копирајте Spotify. Не копирајте Google. Њихов контекст није ваш. Поправите оно што је покварено сада. Не оно што би могло да се поквари на 100 људи. Ако је координација проблем, не делите се по технологијама. Ако се технички дуг гомила, не користите чисте сквадове. Ако људи прегоревају, можда прескочите модел са чаптерима. Пробајте нешто. Дајте му шест месеци. Пратите проблеме. Промените кад је јасно да не ради. Структуру тима не решите једном заувек. Постоје само различити компромиси за различите величине. *Тренутно помажемо другом клијенту да ово разреши. Питајте нас за шест месеци да ли је упалило.*

Android и 16KB величина меморијских страница: ролеркостер једне миграције

Norveon doo — Fri, 21 Nov 2025 00:00:00 GMT

*Мислили смо да ће нам требати једно преподне. Требало нам је три недеље.* И тако Google објави: „Хеј, народе, од 1. новембра 2025. ваше апликације морају да подржавају 16KB величину страница. Биће лако!“ Мигрирали смо [Arheev](https://arheev.com), мобилну апликацију наше интелигентне HR платформе. Прочитали смо документацију. Деловало је једноставно. Ажурирамо неколико алата за билд, додамо пар конфигурационих флегова, можда попијемо кафу док се билдује. Готово до ручка, зар не? Глас наратора: *Није било готово до ручка.* ## Шта је Google хтео (и зашто) Основна идеја има смисла. Android од памтивека користи меморијске странице од 4KB, али модерни уређаји са гомилом RAM-а боље раде са страницама од 16KB. Google-ови сопствени подаци показују лепа побољшања: - Апликације се покрећу 3% брже када је меморија телефона пуна - 4.5% мања потрошња батерије при покретању - Апликације за камеру раде 5–7% брже - Телефон се подиже 8% брже Лепе предности! Па где је квака? ## Прави проблем на који нас нико није упозорио Е, овде постаје занимљиво. Свака нативна библиотека (.so фајл) у вашој апликацији мора да буде „поравната“ на границе од 16KB. Замислите то као паркинг: ваша библиотека мора уредно да стане у паркинг-места величине 16KB. Ако пишете чисту Java/Kotlin апликацију, безбедни сте. Нема нативног кода, нема проблема. Али [Arheev мобилна апликација](https://arheev.com) направљена је у React Native-у. А React Native апликације су у суштини нативне библиотеке умотане у JavaScript умотан у још нативних библиотека умотаних у егзистенцијална питања зашто једноставно нисмо направили одвојене нативне апликације. Када библиотеке нису правилно поравнате, добијате: - Апликације које одбијају да се инсталирају - Загонетне поруке о грешкама које вам ништа не говоре - Падове који се дешавају само на одређеним уређајима (обично баш на онима које ваш шеф тестира) Баш забавно! ## Шта се заправо догодило: хронологија ### Дан 1: „Ово ће бити лако“ Ажурирали смо на Android Gradle Plugin 8.5.1 и NDK r28. Документација је тврдила да ове верзије аутоматски решавају поравнање на 16KB. Додали смо неколико флегова у AndroidManifest.xml: ```xml ``` Билд је прошао. Тестови зелени. Тапшали смо се по раменима. Миграција за мање од сат времена, ко би рекао! ### Дан 3: „Зашто ово не ради?“ Подигли смо Android 15 емулатор са укљученом подршком за 16KB. Инсталирали апликацију. Пала је истог тренутка. Испоставило се да неколико библиотека скривених у нашем стаблу зависности није било поравнато на 16KB: - Наша библиотека за обраду звука (libandroidlame.so) - Нека ствар за компресију слика - SDK треће стране који смо једва и памтили да смо додали Порука о грешци? „Native module initialization failed.“ Хвала, Android-е. Баш си од помоћи. Провели смо два дана учећи о ELF поравнању више него што смо икада желели да знамо. ### Дан 5: „Добро, заобићи ћемо то“ После много гугловања (и можда мало роњења по Stack Overflow-у уз кафу) пронашли смо магични флег: `android:extractNativeLibs="true"`. Он говори Android-у да библиотеке распакује при инсталацији апликације уместо да их учитава директно из APK-а. Тако се захтев за поравнање практично потпуно заобилази. Да ли је савршено? Не. Да ли ради? Да. Да ли то шаљемо у продукцију? Апсолутно. **Добро:** - Тренутно је решило наше падове - Ради са било којом библиотеком, поравнатом или не - Нема чекања да програмери трећих страна ажурирају своје ствари **Мање добро:** - Апликације се инсталирају мало дуже - Заузима више простора на уређају - Google би ово временом могао да укине (али то је проблем нас из будућности) Ово третирамо као привремено решење док са одржаваоцима библиотека радимо на правим верзијама поравнатим на 16KB. ### Дан 7: „Хајде да ово аутоматизујемо пре него што заборавимо“ Последње што смо желели јесте да неко покрене `expo prebuild` и случајно обрише све наше тешко стечене конфигурације. Зато смо направили Expo конфигурациони плагин који све решава аутоматски: **Измене у AndroidManifest.xml:** - Додаје својство за 16KB величину страница - Укључује callback за гест „назад“ - Поставља флег extractNativeLibs **Ажурирања у build.gradle:** - Конфигурише NDK ABI филтере - Укључује подршку за multidex - Подешава потписивање release билда **Подешавања у gradle.properties:** - Подешавања алата за билд - Флегови за нову архитектуру React Native-а - Оптимизација ресурса Сада, кад год неко из тима покрене prebuild, сва ова подешавања једноставно... раде. Нема више тренутака типа „чекај, где је нестао онај конфиг?“. ## Ствари које смо волели да знамо од првог дана ### 1. Прво ажурирајте све Немојте ни да помишљате да почнете ову миграцију без Android Gradle Plugin-а 8.5.1+ и NDK-а r28+. Старије верзије једноставно не решавају поравнање на 16KB како треба. Ажурирајте свој `android/build.gradle`: ```gradle dependencies { classpath('com.android.tools.build:gradle:8.5.1') } ``` Да, ажурирање алата за билд је досадно. Урадите то свеједно. ### 2. Утврдите да ли уопште имате нативни код Пре него што паничите, проверите да ли ваша апликација уопште користи нативне библиотеке. Најлакше је преко APK Analyzer-а у Android Studio-у: 1. Отворите Android Studio (било који пројекат ће послужити) 2. Кликните на **Build > Analyze APK...** 3. Изаберите свој APK фајл 4. Потражите фасциклу **lib** Ако видите фасциклу lib са .so фајловима унутра, честитамо, имате нативни код са којим морате да се носите. Проверите колону Alignment за евентуална упозорења. [image2]: /images/blog/2025-11-21-1.jpg "Мени APK Analyzer-а у Android Studio-у" ![Мени APK Analyzer-а у Android Studio-у][image2] Нема фасцикле lib? Користите чисту Java/Kotlin и вероватно можете да прескочите већи део ове главобоље. Благо вама. ### 3. Заиста тестирајте на 16KB емулатору Направите Android 15 емулатор у AVD Manager-у и укључите „16KB page size“ у напредним подешавањима. Ваш обични уређај неће ухватити ове проблеме јер и даље користи странице од 4KB. Верујте нам, не желите да проблеме са поравнањем откријете тек након што апликација оде у продукцију. ### 4. Пронађите своје нативне библиотеке Пронађите све те .so фајлове који вребају у вашој апликацији: ```bash # List all native libraries in your APK unzip -l app-release.apk | grep '\.so$' ``` Или опет отворите APK Analyzer. Много је лакше, а и интерфејс је леп. Направите списак. Проверите да ли неке праве проблеме. Опсујте оне које праве. ### 5. Држите зависности на оку Нису сви одржаваоци библиотека ускочили у 16KB воз. Неки за њега нису ни чули. За React Native: - Проверите да ли ваша верзија Expo SDK-а има исправке - Прегледајте GitHub issue-е за своје нативне модуле - Размислите о промени библиотеке ако је одржавалац нестао без трага ### 6. Трик са extractNativeLibs је привремен Да, `android:extractNativeLibs="true"` тренутно решава све. Али третирајте га као селотејп: ради, али ћете пре или касније хтети право решење. Запишите којим библиотекама је потребан и пратите њихова ажурирања. ## Ваша контролна листа за миграцију (да ништа не пропустите) Ево шта заправо треба да урадите: - [ ] Ажурирајте AGP на 8.5.1+ и NDK на r28+ - [ ] Ажурирајте Gradle на 8.14+ (кад сте већ ту) - [ ] Користите APK Analyzer да проверите да ли имате нативне библиотеке - [ ] Додајте флегове за 16KB величину страница у AndroidManifest.xml - [ ] Подесите NDK ABI филтере у build.gradle - [ ] Додајте extractNativeLibs ако вам апликација пада - [ ] Направите Android 15 емулатор са укљученим 16KB - [ ] Заиста све тестирајте (немојте само претпоставити да ради) - [ ] Направите списак проблематичних библиотека - [ ] Аутоматизујте конфигурацију (ви из будућности ћете бити захвални) ## Како то изгледа кад развијате за више платформи Овакви захтеви платформе погађају и ваш код и баш сваку библиотеку у стаблу зависности. Када Google каже „подржите 16KB“, сваки програмер нативних модула, сваки добављач SDK-а, сваки пакет из заједнице мора да се прилагоди. А ваша миграција је готова тек када и најспорија библиотека коначно сустигне остале. React Native ово чини још забавнијим јер чекате више од једног екосистема: нативни iOS програмери, Android програмери и JavaScript програмери морају сви да се ускладе. То је као да чувате мачке, само што мачке уз то и жонглирају. ## Да ли се исплатило? Да ли смо после свег тог посла заиста видели побољшања? Да, јесмо: - Мања фрагментација меморије на новијим уређајима - Нешто брже покретање апликације (тешко је прецизно измерити, али ту је) - Нема више пријава типа „ваша апликација не ради на мом телефону“ од корисника Android-а 15 Заобилазно решење са extractNativeLibs мало успорава инсталацију, али када се апликација једном покрене, све делује сасвим у реду. ### Шта још увек није савршено И даље користимо `extractNativeLibs="true"` уместо правилно поравнатих библиотека. То ради, али је технички заобилазница, а не решење. Неколико зависности још увек није објавило верзије поравнате на 16KB. Пратимо њихове GitHub issue-е, али неке нису ажуриране месецима. Можда ћемо их на крају морати форковати или наћи алтернативе. И нисмо 100% сигурни како ће се ово понашати на правим 16KB уређајима када постану уобичајени. Емулатори су једно, прави хардвер нешто друго. Сазнаћемо. ## Шта следи? Вероватно још истог. Како Android телефони постају моћнији, захтеви платформе ће се и даље преливати низ стабла зависности. Аутоматизација коју смо направили за ову миграцију поново ће добро доћи код следеће. ## Суштина Ако желите да објављујете на Google Play-у, миграција на 16KB странице није ствар избора. А посла има знатно више него што документација даје наслутити. Али када једном прођете кроз њу, мирни сте. Конфигурација се углавном сама стара о себи, апликација боље ради на новијим уређајима, а ви имате један рок мање због кога бринете. Ако сте тренутно усред ове миграције и наилазите на чудне проблеме, нисте сами. Били смо тамо. Слободно нам се јавите ако желите да заједно кукате над поравнањем библиотека или да разменимо ратне приче о загонетним Android порукама о грешкама. ## Корисни линкови ако се упуштате у ово - [Android документација о 16KB величини страница](https://developer.android.com/guide/practices/page-sizes): званична документација (у којој све звучи много лакше него што јесте) - [Белешке о издањима Android Gradle Plugin-а](https://developer.android.com/studio/releases/gradle-plugin): да проверите која вам верзија треба - [Водич за Expo конфигурационе плагине](https://docs.expo.dev/config-plugins/introduction/): ако користите Expo и желите да аутоматизујете овај хаос *За разлику од већине миграција, ова заиста има рок. Бар нисте сами у томе: сваки React Native програмер пролази кроз исте ноћне море са поравнањем.* [image1]: /images/blog/2025-11-21.jpg "Android и 16KB величина меморијских страница: ролеркостер једне миграције" ![Android и 16KB величина меморијских страница: ролеркостер једне миграције][image1]

Када тим постане превелик: ево шта је заиста упалило

Norveon doo — Tue, 24 Jun 2025 00:00:00 GMT

[image1]: /images/blog/2025-06-24.jpg "Када тим постане превелик: ево шта је заиста упалило" ![Када тим постане превелик: ево шта је заиста упалило][image1] *Шест месеци неуспелих експеримената. Ево до чега смо заправо дошли.* Лето 2024. Наш тим је стигао до четрнаест људи и одједном је све деловало погрешно. Стендапи су се развлачили по 45 минута. Пола тима је буљило у екране и очигледно није слушало. За испоручене функције сазнавали смо накнадно, обично кад би их клијент поменуо. Нешто се покварило, а нисмо били сигурни када. ## Када су ствари кренуле наопако Они свакодневни састанци? Чисто мучење. Марко би причао о свом раду на API-ју док је Милош гледао у телефон, очигледно размишљајући о ручку. Дарија је за то време објашњавала своје муке са CSS-ом пуној соби бекенд програмера које то ни најмање није занимало. А док смо сви умирали од досаде на састанцима, прави посао се одвијао у сенци. Неко би успут поменуо да је управо испоручио функцију за коју нико од нас није чуо. Обично зато што је Стефан из маркетинга тражио „малу услугу“, а наши предусретљиви инжењери су је просто... одрадили. ## Наши неуспели експерименти (сви до једног) ### Август 2024: подела Пробали смо да се поделимо на фронтенд и бекенд тим. Сваки тим би имао свој стендап, свој фокус. Потрајало је један спринт. Испоставило се да на Arheev-у оба дела морају стално да разговарају. Ко би рекао? ### Септембар 2024: асинхрони извештаји „Хајде да уместо састанака пишемо дневне извештаје на Slack-у!“ Прве недеље су сви писали детаљне извештаје. Друге недеље су се скратили. До треће недеље вратили смо се на „радио на стварима“, а ионако их нико није читао. ### Октобар 2024: ротирање водећих Сваке недеље друга особа води стендап, с фокусом на своју област. Звучало је сјајно у теорији. У пракси: неки су завршили на сваком састанку (јер су дирали све), други су потпуно нестали. Силоса је после тога било више, а не мање. ### Новембар 2024: умало смо одустали Пробали смо да се вратимо на „без формалног процеса, снађите се“. У року од две недеље имали смо исте проблеме као раније. Шест месеци неуспеха. Понестајало нам је идеја. ## Почетак 2025: случајно решење Нисмо ово планирали. Неко је предложио да пробамо моб програмирање за један посебно гадан баг у Arheev-у. Петоро људи, један екран, рад на проблему који је захватао фронтенд, бекенд и базу података. Мислили смо да ће то бити једнократно. Баг је решен. Али десило се и нешто друго: људи су упознали делове кода које никад нису дирали. Фронтенд програмер је схватио зашто је упит ка бази спор. Бекенд програмер је видео зашто је стање учитавања битно. Почели смо то да радимо недељно. Не за све, али за сложене функције или тешке багове. ## Шта се заиста променило **Знање се брже ширило.** Кад сви виде како нешто ради, не деси се да само једна особа зна како се систем пушта у рад. **Мање тренутака типа „то није мој проблем“.** Тешко је рећи да вас фронтенд не занима кад сте управо помогли да се дебагује проблем с React рендеровањем. **Преглед кода је постао бољи.** Ко је уживо гледао како код настаје, касније га је боље и прегледао од онога ко га види први пут. ## Шта је и даље покварено Будимо искрени: нисмо решили све. **Моб програмирање не ради са 14 људи.** Обично нас је 4–6 у сесији. Сви остали раде свој посао. Зато и даље имамо проблема с координацијом. **Неки га мрзе.** Посебно интроверти. Два сата у групној сесији кодирања уме да исцрпи. Још нисмо скапирали како да то функционише за све. **Силоси и даље настају.** Чак и с генералистима, неко на крају постане „особа која зна AWS“ или „особа која разуме ток плаћања“. Само... мање него пре. **AI алати помажу, али нису магија.** Да, можете користити Claude да вам помогне да напишете SQL кад сте иначе фронтенд програмер. Али и даље морате да разумете шта радите. AI учење чини лакшим, не непотребним. ## Где смо сада (новембар 2025) Стендапи су пали на 15 минута. Заиста разговарамо о ономе што је битно уместо да подносимо извештаје о статусу. Моб програмирамо 2–3 пута недељно. Не учествују сви сваки пут. То је у реду. И даље имамо проблеме с координацијом. И даље имамо силосе знања. Али су мањи и мање болни него пре шест месеци. ## Ако се и ви с овим борите Протраћили смо шест месеци на испробавање различитих приступа. Ево шта бисмо поручили себи из прошлости: **Немојте делити тим.** Осим ако нисте заиста довољно велики (50+ људи), подела ствара више проблема него што решава. **Не терајте све да преко ноћи постану генералисти.** То је постепен прелаз. Моб програмирање или програмирање у пару помаже, али траје месецима, не недељама. **Прихватите да ће до неке специјализације доћи.** То је у реду. Само се побрините да нешто критично не зна само једна особа. **Пробајте правило 30%.** Ако градите производ паралелно с радом за клијенте, резервишите капацитет. Иначе га никад нећете направити. Ваше искуство ће се разликовати. Нас је четрнаесторо, радимо удаљено и правимо HR платформу. Ваш тим, производ и ограничења су другачији. Али ако вам стендапи делују као губљење времена, а за посао стално сазнајете тек кад је готов, можда имате исте проблеме које смо ми имали. *За разлику од ваше омиљене серије о канцеларији, ова прича нема уредан крај. Решавамо је и даље, како растемо.*

Зашто је Norveon прешао на потпуно удаљен рад (и зашто се не враћамо)

Norveon doo — Wed, 02 Apr 2025 00:00:00 GMT

*Нема канцеларијске политике кад нема канцеларије.* Сви нас питају кад се „враћамо у канцеларију“. Питање нема смисла: никад је нисмо ни имали да бисмо се у њу вратили. Наш тим ради потпуно удаљено од новембра 2023, много пре него што је Norveon формално основан. То није био одговор на пандемију ни мера штедње. Једноставно нисмо видели разлог да радимо другачије. Градимо софтвер. Наши алати су онлајн. Наши клијенти су широм света. Зашто бисмо се ограничили на људе који свакодневно могу да стигну до Београда? Две године касније и даље радимо удаљено. Ево шта се заиста десило. ## Ствари на које су нас сви упозоравали (а нису се десиле) ### „Културу не можете градити на даљину“ Погрешно. Само је градите другачије. Једном недељно имамо тимски позив на ком заиста разговарамо о томе на чему радимо. Статусни извештаји иду на Slack, а ту водимо праве расправе о техничким одлукама, проблемима на којима смо запели и стварима које смо научили. То је она врста разговора какву бисте водили у канцеларијској кухињи, само што нико не мора да се претвара да му се свиђа кафа. Сваких неколико месеци видимо се уживо на неколико дана. Не због обавезног „тимбилдинга“: после месеци заједничког рада онлајн просто пожелите да колеге упознате уживо. Ти сусрети су међу најпродуктивнијим данима које имамо. ### „Комуникација ће се распасти“ Заправо је постала боља. У канцеларији прекидате нечији дубоки рад да бисте поставили брзо питање. Удаљени рад вас тера да размислите: да ли је ово заиста хитно или може да сачека? Могу ли то јасно да напишем на Slack-у или нам треба кратак позив? Постали смо заиста добри у асинхроној комуникацији. Детаљне Slack нити, снимци екрана уз пријаве багова, права документација, јер не можете само да потапшете некога по рамену и питате како нешто ради. Друга страна медаље: то смо морали да научимо. У почетку смо имали Slack нити које су трајале по недељу дана, а требало је да буду позив од 15 минута. Сада боље знамо кад да пређемо на други медиј. ### „Људи ће мање радити“ Неким данима, да. Неким данима имате преглед код лекара, или чекате доставу, или просто не можете да се сконцентришете и одлучите да прошетате уместо да се претварате да радите. Али видели смо и супротно. Неко ће послати исправку у 23 часа јер је у налету и хоће да заврши. Неко други почиње рано јер се тада најбоље концентрише. Меримо учинак, не евидентиране сате. Класична канцеларија се претвара да су сви продуктивни од 9 до 17. Удаљени рад признаје да је то бесмислица и прилагођава се тренуцима кад људи заиста раде најбоље. ## Ствари које су заиста биле проблем ### Временске зоне су и даље физика Наш тим је распоређен кроз неколико временских зона. За покривеност је то сјајно, јер је увек неко доступан ако клијенту нешто затреба. За заказивање је ужасно. Договорили смо се за термин од 2 сата (од 10 до 12 часова по CET) у ком су сви теоретски доступни за састанке. „Теоретски“ јер неко увек путује или има нешто. Заказивање састанка с целим тимом и даље захтева више покушаја и бар једну особу која се укључује у незгодно доба. ### Потребни су вам бољи алати (и дисциплина да их користите) Рад у канцеларији опрашта много лоших навика. Заборавили сте нешто да документујете? Само питајте Џима. Нисте сигурни како се пушта у рад? Гледајте неког ко то ради. Удаљени рад то кажњава. Морали смо да напишемо праву документацију, уведемо добро управљање пројектима, поставимо јасне процесе. Не зато што смо организовани (нисмо), него зато што би у супротном настао хаос. Користимо Slack, Linear, Notion, Figma, GitHub и вероватно превише других алата. Сваки решава конкретан проблем. И сваки мора да се одржава ажурним или постаје бескористан. ### Сагоревање је подмуклије У канцеларији колеге примете ако изгледате исцрпљено. На даљину? Можете недељама тихо да тонете пре него што ико схвати. Немамо савршено решење за ово. Распитујемо се једни за друге, трудимо се да уочимо знаке, подстичемо узимање слободних дана. Али и даље је превише лако просто... наставити да радите, јер вам је радни простор увек ту. ## Шта бисмо рекли некоме ко покреће удаљену фирму Урадите то ако ваш посао заиста може да се ради на даљину, ако сте спремни да свесно и промишљено комуницирате и ако вам је учинак важнији од евидентираних сати. Ако можете да поднесете неуредност асинхроне координације, вреди пробати. Немојте ако мислите да је то само јефтинији канцеларијски простор или ако желите да надзирете шта људи раде по цео дан. А ако ваш посао заиста захтева сталну физичку сарадњу, удаљени рад ће вам се опирати на сваком кораку. Исто важи ако нисте спремни да уложите у праве алате и процесе: бићете само у канцеларији с лошијом комуникацијом. ## Да ли бисмо икада узели канцеларију? Људи то питају. Одговор је: вероватно не. Не зато што су канцеларије зло или што је удаљени рад савршен. Него зато што смо изградили системе који нама одговарају. Наше запошљавање није ограничено географијом. Наш тим ради кад је најпродуктивнији. Ми штедимо новац на канцеларијском простору, а наши људи штеде време на путовању до посла. Да ли бисмо с канцеларијом били продуктивнији? Можда. Али бисмо изгубили флексибилност која омогућава да нам се придружи неко из друге временске зоне и да људи свој дан организују око живота, а не око путовања на посао. Подаци кажу да већина компанија прелази на хибридни модел. За њих је то вероватно исправно. За нас потпуно удаљени рад и даље има највише смисла. ## Искрено речено Удаљени рад није сам по себи ни бољи ни гори од рада у канцеларији. Другачији је, с другачијим компромисима. За Norveon, који гради софтвер с дистрибуираним тимом, удаљени рад функционише. Успели смо у томе тако што свесно водимо рачуна о комуникацији, улажемо у добре алате и прихватамо да ће неке ствари (као што је заказивање) увек бити теже. После две године и даље учимо. Али се у канцеларију сигурно не враћамо. [image1]: /images/blog/2025-04-02.jpg "Зашто је Norveon прешао на потпуно удаљен рад (и зашто се не враћамо)" ![Зашто је Norveon прешао на потпуно удаљен рад (и зашто се не враћамо)][image1]

Постали смо стартап са каквим смо желели да радимо

Norveon doo — Sat, 15 Mar 2025 00:00:00 GMT

*Ниједна пивот табела није консултована током прављења овог производа.* Откако се наш тим окупио крајем 2023, радимо клијентски посао за стартапе. Градимо им MVP-јеве, поправљамо технички дуг, скалирамо инфраструктуру. Добар посао, занимљиви проблеми, солидан приход. Онда смо почетком 2024. почели да градимо Arheev, нашу сопствену HR платформу, и одједном смо се нашли са друге стране сваког разговора који смо икада водили са стартап клијентима. Испоставило се да је уз сервисну фирму много теже градити сопствени производ него што смо клијентима говорили. ## Класична агенцијска замка Ево како сервисне фирме обично размишљају о грађењу производа: „Искористићемо слободно време да направимо интерни производ. Кад клијентски посао стане, радићемо на њему. Биће сјајно!“ Знали смо да је ово замка. Гледали смо како пропада другим агенцијама. Говорили смо себи да ћемо ми бити другачији. Нисмо били другачији. Првих неколико месеци сви су одушевљени. Људи се добровољно јављају да викендом раде на Arheev-у. Напредак је брз. Направимо радни прототип, добијемо прве повратне информације, све је сјајно. Онда стигне велики клијентски пројекат. „Само две недеље“, кажемо себи. „Онда се враћамо на Arheev.“ Три месеца касније Arheev нико није ни такао, а ми смо заборавили пола одлука које смо донели. ## Шта смо променили (и шта је заиста упалило) Кад се то поновило, увели смо правило: **Arheev добија 30% нашег капацитета, сваке недеље, без обзира на све.** Не „кад имамо времена“. Не „ако је клијентски посао стао“. Просто... 30% је резервисано за наш производ. Увек. Ово је било застрашујуће. Шта ако будемо морали да одбијемо клијентски посао? Шта ако не стигнемо рокове? Показало се да ограничења терају на ефикасност. Постали смо бољи у процењивању клијентских пројеката. Престали смо да пристајемо на све. Запослили смо још једну особу да имамо резерву. А Arheev је коначно почео редовно да добија нове функције. ### Катастрофа са мобилном апликацијом Док смо правили мобилну апликацију за Arheev, налетели смо на савршену олују Android захтева. Google је најавио да меморијске странице морају бити величине 16KB. React Native је морао да се ажурира. Пола наших зависности није било компатибилно. Класичан кошмар техничког дуга, онај за чије бисмо поправљање клијенту иначе наплатили највишу тарифу. Само што је ово био наш производ, наш проблем, наши викенди. Три недеље смо провели у дебаговању поравнања нативних библиотека. Нико нам то није плаћао. Нисмо могли никоме да наплатимо. Просто смо морали, јер је алтернатива била да не испоручимо. Ово стартап клијентима никад нисмо како треба објаснили: понекад једноставно морате да прогутате трошак платформских захтева, покварених зависности и техничких промена које нисте ви изазвали. ### Стварно слушање корисника (на тежи начин) За клијентски посао имамо процес. Истраживање корисника, вајерфрејмови, прототипови, тестирање. Веома професионално. За Arheev? Направили смо оно што нам је имало смисла, испоручили и гледали како се људи збуњују. Једну функцију коју смо правили три недеље (паметан аутоматизовани ток одобравања) буквално нико није користио. Сви су само ручно одобравали све, јер је наш „паметни“ систем био превише компликован да се разуме. Избацили смо га и направили нешто једноставније. Требало нам је четири сата. Људи то заиста користе. За клијента бисмо своје сложено решење вероватно бранили недељама. Кад је производ ваш, просто га поправите, јер немате кога другог да окривите. ## Шта је ово променило у раду са клијентима Кад нам стартап клијент данас каже „сами ћемо пустити мобилну апликацију у рад“, не климамо само главом. Испричамо им о три недеље које смо провели на 16KB страницама. Кад хоће да направе сложену функцију зато што делује кул, покажемо им наш напуштени ток одобравања. Кад покушавају да угурају рад на производу „између“ других приоритета, објаснимо зашто смо морали да резервишемо 30% капацитета или Arheev никад не би био испоручен. Бољи смо у раду са клијентима јер смо исте проблеме проживели као интерни стартап. Не као консултанти који су о томе читали. Као тим који је у 23 часа поново пуштао код у рад јер је претходно пуштање пукло, а корисници су чекали. ## Непријатна истина Грађење Arheev-а нас је натерало да схватимо колико је лакше давати савете него их се држати. Говорили смо клијентима „само брзо испоручите и итерирајте“ док смо недељама пеглали функције Arheev-а. Говорили смо „прво се фокусирајте на кључне кориснике“ док смо покушавали да направимо сваку могућу функцију за сваки могући HR сценарио. Препоручивали смо „једноставно побеђује сложено“ док смо градили сложена решења јер смо мислили да знамо боље. Тек кад смо се нашли са друге стране, почели смо заиста да радимо оно што проповедамо. Или бар да покушавамо. ## Где смо сада Arheev ради у продукцији. Људи га користе. И даље правимо нове функције, поправљамо багове и миримо се с тим да софтвер никад није „готов“. И даље радимо за клијенте и од тога долази већина нашег прихода. Али сада водимо и сопствени производ. Неуредно је. Неких недеља Arheev добије више од 30%. Неких мање. Учимо успут. Боља смо сервисна фирма јер смо прошли кроз исто што и наши клијенти. Притисак, компромисе, касне ноћи дебаговања нечега што је „требало да буде једноставно“. Кад клијенту кажемо да је нешто тешко, они знају да то не говоримо само да бисмо наплатили више сати. Сами смо то прошли.

Како мали тим гради производе (а да не полуди)

Norveon doo — Mon, 03 Mar 2025 00:00:00 GMT

*Ниједна корпоративна фраза није повређена током писања овог текста.* Нас је четрнаест. Довољно мало да сви знају на чему ко ради, али довољно велико да не можете да импровизујете без икаквог процеса. Ова величина је чудна. Превелика за „хајде сви на позив да се договоримо“, премала за одељења, менаџере и формалне хијерархије. Морали смо да смислимо како да на овој величини заиста градимо производе и, искрено, још увек смишљамо. ## Шта заправо градимо Тренутно радимо на две главне ствари: 1. **Arheev**: наша HR платформа за компаније у расту. То је производ који градимо за себе (и за друге којима треба). 2. **Пројекти за клијенте**: радимо развој по мери за стартапе и компаније којима треба техничка експертиза коју немају у кући. Жонглирање обома је понекад хаос. Таман зађемо дубоко у нове функције за Arheev, а онда се на клијентском пројекту појави критичан баг и пола тима пређе на њега. Или испланирамо спринт за клијента, па схватимо да Arheev-у хитно треба нешто за демо следеће недеље. Са четрнаест људи нема решења типа „одвојени тимови“. Сви дирају све. ## Како заиста доносимо одлуке У великој компанији постоје процесни документи и ланци одобравања. На нашој величини то је претеривање. Уместо тога, имамо једно правило: **ако мислите да нешто треба урадити, направите прототип**. Не „закажите састанак да о томе разговарамо“. Не „напишите предлог за разматрање“. Само направите грубу верзију и покажите је тиму. Ово звучи хаотично. Понекад и јесте. Али зато брзо напредујемо и брзо гасимо лоше идеје. Далеко боље него две недеље расправљати о нечему на састанцима, па то изградити и схватити да не ради. Марко (наш руководилац инжењеринга) дошао је из фирме где је свака измена захтевала три нивоа одобрења. Каже да је, кад му је неко у Norveon-у први пут рекао „само испоручи и види шта ће бити“, помислио да је то тест. Није био. Заиста верујемо да свако од нас може сам да процени. ## Петком извештај о неуспесима Сваког петка имамо стални састанак на ком људи деле шта те недеље није успело. Не успехе. Неуспехе. Пуштање у рад на Azure-у које је срушило продукцију. Функција коју смо направили, а корисници је мрзе. Рефакторисање које је перформансе погоршало уместо да их побољша. Састанак с клијентом који је кренуо наопако. У почетку су људи нерадо делили неуспехе. Сада је то најкориснији састанак који имамо. Далеко више научите из „ево шта сам покварио и како сам поправио“ него из „ево шта је добро прошло“. ## Када је јуниор програмер био у праву Док смо правили Arheev, недељама смо дизајнирали распоред контролне табле. Више итерација, много расправе о хијерархији информација и корисничким токовима. Онда је неко новији у тиму (ко је на већини састанака ћутао) гурнуо на staging окружење прототип који је одбацио цео наш приступ навигацији. Просто... потпуно другачије. Прва реакција је била „ово руши све наше дизајнерске обрасце“. Друга реакција, након што смо то заиста користили, била је „чекај, ово заправо ради боље“. На крају смо испоручили њихову верзију. Требало је још око две недеље да се дотера, али суштинска идеја, која је дошла од некога ко није учествовао у нашим ранијим расправама и није делио наше претпоставке, решила је проблем боље од нашег „експертског“ приступа. Поука: кад сте нови, понекад још нисте покупили све погрешне обрасце. ## Ствари које се не скалирају (а ми их ипак радимо) Са четрнаест људи и даље можемо оно што веће компаније не могу: **Сви прегледају свачији код.** Не само сениори који прегледају јуниоре. Сви виде свачији рад. То значи да преглед кода понекад траје дуже, али и да се знање брзо шири. **Испоручујемо директно у продукцију.** Нема посебног тима за пуштање у рад, нема одбора за одобравање измена. Ако сте то направили и прошло је тестове, можете да га поставите. Ово ужасава људе из већих компанија. Нама је у реду. **Сви разговарају с клијентима.** Нема „тима за односе с клијентима“ који штити програмере од корисника. Ако сте направили функцију, можда ћете баш ви да је демонстрирате или дебагујете с корисником. Неефикасно је, али тако се научи шта је заиста битно. ## Шта се дешава кад ово не ради Није све савршено. Неке ствари на нашој величини просто... не ваљају. **Силоси знања и даље настају.** Чак и с прегледима кода и заједничким пројектима, једна особа на крају постане „она која зна како се пушта у рад“ или „она која разуме ток плаћања“. Кад је на одмору, ствари успоре. **Политика и даље постоји.** Мањи тим не значи да нема неслагања или повређених осећања. Само имамо мање места да се од њих сакријемо. **Раст је чудан.** Премали смо за специјализоване улоге, а превелики да сви раде све. Да запослимо још једног програмера генералисту или нађемо специјализованог дизајнера? Погрешан избор и месецима смо неуравнотежени. Немамо решења за све ово. Само смо свесни да постоји и трудимо се да их не погоршамо. ## Зашто је ово битно за производе Начин на који радимо директно утиче на оно што градимо. У Arheev-у (нашој HR платформи) можете да прилагодите практично све. Токови рада, дозволе, поља података, извештаји: све се подешава. Не зато што смо планирали да направимо „најфлексибилнији HR систем“, него зато што тако радимо интерно. Мрзимо кад нас терају у круте процесе, па смо направили алат који не тера кориснике у круте процесе. Да ли је већи, структуриранији тим могао да направи нешто слично? Можда. Али би требало више састанака, више планирања, више слојева одобравања. Док би они испоручили, тржиште би се померило. Са четрнаест људи можемо брзо да напредујемо јер лоше идеје немају где да се сакрију. Ухвате се у прегледу кода, или на петковом састанку о неуспесима, или кад неко покуша заиста да користи функцију и схвати да је ужасна. ## Где смо Нисмо открили савршен начин да се граде производи. Нико није. Само делимо шта нама функционише на овој величини, у овој фази. Нешто од овога ће пући како будемо расли. Нешто већ не ради онако добро као кад смо били мањи. Прилагодићемо се, или нећемо, и о томе ћемо такође писати. Питајте нас поново за годину дана и одговор би могао бити другачији.

Направили смо HR платформу (јер су нас табеле убијале)

Norveon doo — Sat, 22 Feb 2025 00:00:00 GMT

*Док смо писали ову објаву, ниједну табелу нисмо отворили.* Направили смо Arheev јер је наш сопствени HR процес био катастрофа. Четрнаесторо људи. Слободни дани праћени у Google Sheets-у. Досијеи запослених у Notion-у. Документи на Drive-у. Неко пита „колико ми је још остало дана годишњег?“ и морате да отворите три таба и да рачунате. Пробали смо постојеће HR платформе. Биле су или превише једноставне (у суштини само лепше табеле) или превише сложене (корпоративни системи за 500+ запослених, уз које иде и обука). Зато смо направили нешто између. Испоручили смо га у фебруару 2025. Ево шта смо научили. ## Стварни проблем Наш HR „процес“ изгледао је овако: **Неко тражи слободне дане:** 1. Пошаље поруку на Slack-у 2. Менаџер проверава Google табелу да види да ли је још неко одсутан те недеље 3. Менаџер ручно ажурира табелу 4. Неко (надамо се) ажурира годишње збирове 5. Заборави да ажурира, схвати два месеца касније када неко пита зашто му не штима број дана годишњег **Долази нови запослени:** 1. Додамо га на Slack, GitHub, имејл, Linear, Notion 2. Заборавимо да га додамо у табелу годишњих одмора 3. Сетимо се три недеље касније када затражи свој први слободан дан 4. У паници покушавамо да се сетимо датума његовог почетка да бисмо израчунали стечене слободне дане Као софтверској компанији, срамота нас је да ово признамо. Ми буквално правимо системе за друге, а нисмо могли да изађемо на крај са сопственим HR-ом. ## Зашто нисмо могли једноставно нешто да купимо Пробали смо. Стварно. **BambooHR, Workday, SAP SuccessFactors** - Направљени за компаније са 200+ људи. Плаћали бисмо модуле за оцењивање учинка, планирање наследника, управљање зарадама... ствари које нам не требају. **Gusto, Rippling** - Одлични за америчке компаније. Мање одлични када вам је тим раширен по Европи и не треба вам обрачун плата (за то користимо књиговође). **Једноставни алати попут Timetastic-а** - У суштини само улепшају табелу. И даље одвојени од свега осталог. Требало нам је нешто што може да расте са нама, а да нас не тера да користимо функције које нам још не требају. ## Шта смо заправо направили [image1]: /images/blog/dashboard-interface-2.png "Интерфејс Arheev контролне табле" ![Интерфејс Arheev контролне табле][image1] Верзија 1.0 има оно што нам је најхитније требало: - Управљање слободним данима: захтев, одобравање, праћење стања. Замена за табелу. - Досијеи запослених: основни подаци, детаљи о запослењу, документи, све на једном месту. - Одељења и позиције: организациона структура без софтвера за органиграме. - Праћење присуства: ко ради, ко је одсутан, ко је на одмору. - „Pulse“ контролна табла: видите шта се дешава у тиму без отварања пет табова. То је то. AI не доноси одлуке и нема „интелигентне аутоматизације“ коју нико није тражио. Само основе које раде. ### Једина AI функција (коју заиста користимо) Једну ствар смо ипак урадили уз помоћ AI: при прегледу захтева за слободне дане систем означава потенцијалне сукобе. „Троје људи из инжењеринга већ је одсутно те недеље“ или „Ово се преклапа са роком пројекта у Linear-у.“ Не одобрава и не одбија аутоматски. Само вам пред очи изнесе информације које бисте иначе морали ручно да тражите. Испоставља се да је то много корисније од покушаја да се аутоматизује сама одлука. ## Шта још градимо Изашли смо са основним функцијама које раде. Али има много тога што још нисмо направили: Модул за регрутацију стиже касније ове године. Можда. Још увек тражимо прави приступ. Оцењивање учинка је у плану, али искрено нисмо сигурни како да то урадимо а да не делује као бирократија. Интеграције: тренутно можете да извезете податке. Желимо праве API интеграције са Slack-ом и Linear-ом. На списку је. Android апликација ради, али је миграција на 16KB величину страница трајала три недеље и још увек проналазимо граничне случајеве. Верзија 1.0 решава наш непосредни проблем (излазак из табеларног пакла). Све остало чека свој ред у плану развоја. ## Миграција је била неуреднија него што смо очекивали Сами смо себи били први прави корисници. Крајем јануара 2025. мигрирали смо сопствене HR податке из табела у Arheev. Трајало је два пуна дана. Не зато што је увоз био тежак, већ зато што су нам табеле биле недоследне. Неки дани одмора били су у децималама, неки у данима. Неки датуми форматирани на један начин, неки на други. Схватили смо да месецима погрешно рачунамо стицање слободних дана. Ако су наши подаци били неуредни, вероватно су и сви остали. Зато смо направили алате за увоз који покушавају да изађу на крај са недоследностима. Нису савршени, али је то боље него рачунати на чисте податке. ## Коришћење у пракси Arheev интерно користимо од краја јануара. То је... углавном добро. Захтеви за слободне дане раде одлично. Нема више забуне око табела. Чување докумената је у реду. Боље од фасцикли на Drive-у, али и даље заборављамо да отпремимо ствари. Праћење присуства понекад прескачемо, јер је „присуство“ чудан појам кад се ради на даљину. Једноставно ради боље од онога што смо имали раније. За верзију 1.0, то је довољно. ## Ако се и ви давите у табелама Arheev је доступан. Можете га испробати ако желите. Направљен је за тимове попут нашег - 10-50 људи, у расту, којима још не требају функције за велике компаније. Да будемо искрени: није углачан као велики играчи. У неким областима још увек тражимо прави UX. Мобилна апликација ради, али није спектакуларна. Багове исправљамо како их људи пријављују. Али ако HR пратите у Google Sheets-у и то вас излуђује, Arheev би можда вредело пробати. Направили смо га јер нам је требао. Ако имате исти проблем, можда ће и вама одговарати.