Šta WorkThroughLine ume danas - ceo spisak, i kada koja stvar ima smisla

Ovih dana sam seo i napisao spisak svega što WorkThroughLine ume. Nameravao sam da to bude interna beleška pred razgovor sa jednim timom, a ispalo je dugačko dovoljno da me je iskreno malo uplašilo. Ne zato što je puno funkcionalnosti - nego zato što spisak funkcionalnosti sam po sebi ne pomaže nikome da odluči išta.

Zato ovaj tekst nije katalog. Uz svaku stvar stoji zašto postoji, kad je vredi uključiti i, gde ima smisla, konkretna situacija u kojoj se ta stvar isplati. Snimak je od 10. avgusta 2026. Za pola godine će delovi biti netačni, i to je u redu - datum je gore da bi se znalo o kom stanju govorimo.

Jedna napomena unapred: ako uključiš sve odjednom, dobićeš gore iskustvo nego da nisi uključio ništa. Većina onoga što sledi rešava problem koji tvoj tim možda još nema.

Jedno pravilo iz kojeg sledi sve ostalo

Cilj je entitet prvog reda, a isporuka je sredstvo.

Praktično to znači da svaki zadatak može da odgovori na pitanje „čemu ovo služi", a ne samo „ko ga radi i u kojoj je koloni". Veze između godišnjeg cilja, OKR-a, prilike, rešenja, eksperimenta i tiketa nisu tekst u opisu, nego tipizirane ivice u grafu koji se može proći u oba smera. Otvoriš cilj i vidiš šta se sve iz njega izrodilo; otvoriš tiket i vidiš zbog čega postoji.

Ako je to jedina stvar koju ćeš zapamtiti iz ovog teksta, dovoljno je. Sve ispod je infrastruktura za to.

Strategija: ciljevi, OKR-ovi i planiranje vremena

Hijerarhija ide: godišnji cilj → produktni cilj (opciono) → OKR. Produktni cilj je međusloj koji koristiš samo kad jedan godišnji cilj ima više jasno odvojenih produktnih pravaca. Ako ga nemaš, ništa ne gubiš.

OKR se ponaša različito zavisno od toga gde stoji, i to je namerno. OKR direktno pod godišnjim ciljem nosi klasične key results - merljive brojeve. OKR pod produktnim ciljem umesto toga nosi rešenja, kroz automatski napravljen odraz u Discovery-ju. Razlog je prost: na nivou produktnog pravca retko postoji jedan broj koji sve opisuje, a skoro uvek postoji spisak stvari koje probamo.

Svaki OKR ima i nivo poverenja od 1 do 5. To nije procenat završenosti nego procena koliko verujemo da ćemo stići. Kad tri OKR-a stoje na dvojci, to je razgovor koji treba voditi u septembru, a ne u januaru.

Vreme se meri planskim periodima koje sam biraš: tercijali (3 puta po 4 meseca), kvartali ili polugodišta, sa podesivim početnim mesecem. Mi radimo u tercijalima jer četiri meseca daju dovoljno prostora da se nešto zaista završi, a kvartal se u praksi pretvara u dva meseca rada i mesec dana planiranja.

Roadmap prikazuje OKR-ove kroz te periode, na dva načina: kao vremensku osu ili kao Sada / Sledeće / Kasnije kolone. Grupisanje ide po godišnjem cilju, planskom periodu ili produkt menadžeru. Boja je status, ispuna je progres.

Roadmap se može podeliti javnim linkom, samo za čitanje, sa rokom važenja ili bez njega, i može se opozvati u svakom trenutku. Link ne prikazuje imena vlasnika ni delivery kartice - samo ciljeve, OKR-ove i progres.

Kad ovo koristiš: kad neko izvan tima traži „da vidi roadmap", a ne želiš ni da mu praviš nalog ni da izvoziš slajdove svakog meseca. Klijent, investitor, partnerski tim. Link ističe za 30 dana i time se sam čisti.

Discovery: od razgovora do dokaza

Lanac je: intervju ili analiza → insight → prilika → rešenje → eksperiment.

Intervju je razgovor sa korisnikom, sa transkriptom i sažetkom. Analiza je istraživanje nad podacima, sa pitanjem, metodom i rezultatom. Oboje proizvode insighte, a insighti „ojačavaju" prilike - jedna prilika može da nosi dokaze iz sedam različitih razgovora i to se vidi na njoj.

Prilike se prioritizuju RICE skorom: doseg puta uticaj puta poverenje, podeljeno naporom. Doseg se meri brojem korisnika po planskom periodu, napor u čovek-nedeljama, uticaj po Intercom skali. Skor nije presuda nego alat za razgovor - kad neko traži da se nešto radi „jer je važno", RICE prisiljava da se kaže koliko korisnika i koliko nedelja.

Rešenja se ocenjuju kroz uticaj, napor i poverenje i imaju svoj životni ciklus: predloženo → izabrano → u eksperimentu → validirano ili odbačeno.

Eksperimenti postoje da bi se hipoteza proverila pre pune izrade. Eksperiment se promoviše u delivery kao TEST kartica, radi se, pa se zaključuje kao uspešan, neuspešan ili neuveren. Sve veze i trag se nasleđuju, pa se posle šest meseci vidi ne samo šta smo isporučili, nego i šta smo probali i odustali.

Ceo lanac se vidi kao opportunity solution tree, sa pomeranjem i zumiranjem, jer stablo posle godinu dana rada ne staje na ekran.

Zanimljiv slučaj: neuspeo eksperiment je najjeftiniji artefakt u sistemu i najskuplji za ponovno otkrivanje. Ono „proverili smo i nije radilo" se ručno nikad ne zapiše, jer nema šta da se pokaže, pa isto pitanje neko ponovo istražuje sledeće godine. Ovde ostaje zapisano zajedno sa metodom.

Delivery: jedan model umesto pet tabela

Delivery ima jednu tabelu work item-a sa tipom i roditeljem, umesto odvojenih epika, priča i zadataka. Zvuči kao tehnički detalj, ali menja svakodnevicu: promena tipa je izmena polja, a ne migracija tiketa.

Na kartici stoji sve ono što se očekuje - opis sa markdown formatiranjem, checkliste, prilozi sa pregledom slika i fajlova, komentari sa odgovorima u niti i @pominjanjem, veze tipa blokira / blokiran je / povezano / duplikat, potkartice, procena i story points, oznake, rokovi. Izmene se čuvaju automatski, a istorija se rekonstruiše iz audit log-a, pa se vidi ko je šta promenio i kada.

Sprint i board rade kao hibrid Scrum-a i Kanban-a. Backlog puniš, u sprint ubacuješ, a na tabli pomeraš kroz statuse. Svaki tim može da ima svoj workflow - nazive i redosled sedam koraka - a tabla automatski koristi workflow tima kome sprint pripada. Zatvaranje sprinta pita šta sa nezavršenim stavkama: prenos u sledeći sprint (uz brojač prenosa) ili povratak u backlog. Stavke dodate usred sprinta se posebno obeležavaju kao ad-hoc.

Ta dva brojača - koliko puta je nešto preneto i koliko je upalo van plana - obično kažu više o timu nego bilo koja velocity metrika.

Klasifikacija rada je stvar oko koje smo najviše lomili koplja. Postoje razvoj i održavanje. Bug i sve što nosi kategoriju održavanja je održavanje, čak i kad je vezano za OKR. Sve ostalo je razvoj, koji se deli na razvoj po cilju i razvoj van cilja. Nadogradnja frameworka i refaktor su razvoj, ne održavanje - proaktivan rad nije upkeep.

Zašto je to dobro: dobiješ odgovor na pitanje koje menadžment postavlja svaki kvartal - „u šta nam odlazi vreme" - bez ijedne dodatne tabele. I dobiješ ga u obliku koji se ne može ulepšati, jer klasifikacija ne zavisi od toga kako je neko nazvao tiket.

Uz to idu sačuvani pregledi: podesiš filtere na backlogu i sačuvaš ih kao privatni ili deljeni pregled za celu organizaciju. URL nosi filtere, pa isti pogled možeš poslati i kao link. Postoje grupne akcije, oznake, i dodatna polja koja sam definišeš kad ti standardna ne dostaju.

Moj rad je lični pregled - sve gde si dodeljen, pominjan ili pratilac, bez obzira na rolu.

Pratioci kartice su najnovija stvar u proizvodu. Na karticu dodaš kolege ili stakeholdere koji treba da znaju šta se dešava, i oni dobijaju obaveštenja o promeni statusa i novim komentarima, bez da im išta dodeljuješ.

Kad ovo koristiš: kartica koju čeka pravna služba, marketing ili neko iz podrške. Umesto da ih pinguješ tri puta, dodaš ih kao pratioce i sistem ih obaveštava. Umanjuje broj poruka tipa „je l’ ono gotovo".

Prijave: kanal za sve što stiže sa strane

Intake tabla ima dve trake - bagovi i zadaci, i predlozi unapređenja - i četiri kolone: prijavljeno, u pripremi, radi se, završeno. Svaka kolona prikazuje najviše pet kartica dok ne klikneš na prikaz svih, što je sitnica koja tablu drži čitljivom.

Ono što se ovde radi jeste odvajanje dva različita procesa. Bag koji je neko preuzeo automatski prati svoj delivery status - kad se tiket zatvori, prijava se sama pomera u završeno. Predlog unapređenja se pomera ručno, jer predlog ne prolazi kroz delivery nego kroz odluku.

Prijava se može prebaciti u delivery (sa ili bez OKR-a, sa dodavanjem u aktivni sprint) ili pretvoriti u priliku u Discovery-ju. Ima komentare, istoriju toka, watchere koji dobijaju ista obaveštenja kao prijavilac, i deljivi link.

Zanimljiv slučaj: prijava koja se pretvara u priliku je najkorisniji put, a najređe se koristi. Kad ista stvar stigne treći put od tri različita čoveka, to više nije bag nego signal. Pretvaranje u priliku znači da ostaje u discovery-ju sa dokazima umesto da se zakrpi i zaboravi.

Javni portal i changelog

Portal je javna stranica organizacije na kojoj ljudi bez naloga predlažu unapređenja, glasaju za tuđe predloge i čitaju novosti. Uključuje se jednim prekidačem i javno je samo ono što izričito odobriš.

Uz to ide moderacija: posetioci mogu da prijave sadržaj kao spam, uznemiravanje, govor mržnje, objavljene lične podatke ili nezakonit sadržaj, a ti odlučuješ da li se sadržaj sakriva ili prijava odbacuje, uz internu belešku o razlogu.

Changelog je druga polovina istog prostora - objave o tome šta je isporučeno, vezane za konkretne work item-e, sa kontrolom nad tim šta je objavljeno a šta ostaje interno.

Kad ovo koristiš: kad podrška provodi sate na pitanju „da li ćete ovo dodati". Javni glasački portal ne rešava prioritizaciju - i ne bi trebalo da je rešava - ali skida najveći deo tog saobraćaja i pretvara ga u nešto što se može čitati jednom nedeljno.

Dokumentacija koja i sama ulazi u graf

Dokumenti mogu da žive na dva načina, i biraš na kom kad ih praviš.

Prvi je usidren za entitet - za godišnji cilj, OKR, priliku, rešenje, eksperiment ili tiket. Stablo se gradi samo iz modela, pa mesto dokumenta kazuje na šta se odnosi. Dokument sa discovery nivoa se automatski vidi i na povezanim delivery karticama. Za PRD, tehnički dizajn, ADR i beleške o odlukama.

Drugi je slobodan wiki prostor sa ručnim folderima, bez veze sa entitetima. Za priručnik tima, onboarding, procese i rečnik pojmova.

Bez obzira gde pišeš, @-pominjanjem entiteta praviš pravu vezu - dokument ulazi u trace graf i pojavljuje se u lancu.

Obaveštenja: šta stiže i gde

Tipovi su: pominjanje, dodela, dodavanje kao pratilac, promena statusa, novi komentar, približavanje roka, nova prijava i odblokiranje kartice.

Kanali su četiri. Centar obaveštenja u aplikaciji. E-pošta. Slack i Microsoft Teams kanali na nivou organizacije, za timske događaje. I lične Slack poruke - povežeš svoj nalog i bot ti šalje privatne poruke samo za ono što je namenjeno tebi, bez kanala i bez webhook-a. Komentari, opisi i email adrese se u tim porukama ne šalju.

Zašto je to podeljeno: timski kanal i lična poruka rešavaju različite probleme. Kanal je za „tim treba da zna", lična poruka je za „ovo čeka baš tebe". Kad se to spoji u jedno, kanal postane šum koji svi utišaju.

Integracije: Git, MCP, webhookovi

GitHub i GitLab se povezuju preko potpisanih webhook-ova. Staviš ključ kartice u granu, commit ili pull request i povezane grane, commit-i i review-i se pojavljuju na kartici. Provider access token se ne čuva.

Hosted MCP server povezuje Codex ili Claude Code direktno sa podacima organizacije, preko ličnog API ključa. Nije potreban lokalni server, Node.js ni kloniranje repozitorijuma. Model radi u tvom AI klijentu, a WorkThroughLine daje strukturisan kontekst i izvršava samo alate koje tvoja rola dozvoljava - ako alat nije dozvoljen, API vraća 403. Ključ vidi isključivo podatke svoje organizacije, uz istu izolaciju na nivou reda u bazi kao i obična prijava, i može se opozvati u svakom trenutku.

Agent kroz MCP može da čita ciljeve, OKR-ove, intervjue, transkripte, analize, insighte, prilike, rešenja, eksperimente, ceo trace lanac, delivery stavke sa kontekstom, sprintove i izveštaje - i da piše ono što rola dozvoljava.

Zanimljiv slučaj: „pročitaj svih dvanaest intervjua iz ovog tercijala, uporedi ih sa aktivnim OKR-ovima i reci mi koje prilike nemaju nijedan dokaz iza sebe - nemoj ništa da kreiraš dok ne odobrim". To je posao koji ručno traje dan i po, a niko ga zato ne radi. Odgovor koji dobiješ i dalje treba osporiti, o čemu sam pisao u tekstu o AI-ju kao radnoj površini.

Odlazni webhookovi šalju događaje u tvoje sisteme, sa pregledom isporuka i ponovnim slanjem kad nešto padne. REST i OpenAPI dokumentacija stoje na stranici za programere.

Uvoz iz Jire i izvoz koji stvarno vraća organizaciju

Jira Migration Assistant povezuje Jira Cloud direktno ili prima CSV. Prenosi issue-e, sprintove, komentare, veze, korisnike i Jira Product Discovery kontekst, uz preflight proveru i mapiranje statusa, tipova, prioriteta i korisnika pre svakog upisa. Uvoz samo dodaje i ažurira - nikad ne briše - i isti fajl može da se pusti više puta bez dupliranja. CSV put radi i za Productboard, Aha! i Linear.

Izvoz ide u dva oblika. CSV work item-a za tabelu, i JSON koji je pun restore paket: konfiguracija, korisnici, timovi, sav rad, istorija i sami fajlovi priloga, sa proverom integriteta. Restore se radi u novu praznu organizaciju.

Zašto je to dobro: zato što je to jedina stvar koja čini razgovor o prelasku poštenim. Ako izlaz nije stvaran, ulaz je zamka.

Podešavanja, na jednom mestu

Ovo je deo koji niko ne traži u demou, a najviše menja svakodnevni rad:

• Profil organizacije - identitet, proizvod, tržište, strateški pravac i način rada
• Korisnici i pozivnice - pozivnica sa istekom, e-poštom i linkom
• Timovi i workflow po timu - nazivi i redosled sedam delivery koraka
• Planiranje - tercijal, kvartal ili polugodište, plus početni mesec
• Praksa procene - da li kartica sme da napusti To Do bez procene i da stigne u Done bez story points
• Radna nedelja - koji dani se računaju, što ispravlja procene i podsetnike pred kraj sprinta
• Oznake i dodatna polja koja sam definišeš
• API ključevi - jedan aktivan po makeru, prikazuje se samo jednom, opoziv trenutno važi
• Uvoz i izvoz
• Audit log ključnih promena
• Odlazni webhookovi
• Slack i Teams kanali, i posebno lične Slack notifikacije
• GitHub / GitLab veze
• Javni portal - prekidač i javna adresa
• Nalog - dvofaktorska autentifikacija, promena lozinke, jezik, tema

Uz to, aplikacija ima komandnu paletu (Cmd/Ctrl+K) koja pretražuje sve i nudi akcije, tastaturne prečice na tabli, tamnu i svetlu temu, i radi na četiri jezika: srpskom, engleskom, nemačkom i mađarskom.

Role: ko šta sme

Pet rola. ADMIN upravlja organizacijom i integracijama. PRODUCT_MANAGER uređuje strategiju, discovery i delivery. DEVELOPER uređuje delivery, dokumentaciju i doprinosi discovery-ju. STAKEHOLDER ima širok pregled samo za čitanje i učestvuje kroz komentare i prijave. GUEST ima fokusiran pregled i može da pošalje prijavu.

Prve tri su maker role i one se računaju kao plaćena mesta. Stakeholder i guest su besplatni, bez ograničenja broja.

To je namerna odluka o cenovniku: naplaćuje se ono što tim gradi, a ne to koliko ljudi u firmi treba da vidi šta se dešava. Alat koji naplaćuje vidljivost sam sebi radi o glavi.

Šta još ne postoji

Da spisak ne bi zvučao kao da je sve rešeno: nema aktivne naplate ni online checkout-a, nema enterprise plana preko 30 makera, nema SAML/SSO, SCIM ni IP allowlist-e, nema ugovornog SLA ni garantovane 24/7 podrške, i nema izbora regiona za čuvanje podataka.

Ako ti je nešto od toga uslov, danas nismo pravi izbor i bolje je to znati odmah nego posle tri nedelje evaluacije.

Dva scenarija, od početka do kraja

Prvi: pitanje u sred kvartala. Direktor pita zašto tim već pet nedelja radi na nečemu što nije bilo u planu. Umesto rekonstrukcije kroz tri alata, otvoriš izveštaj razvoj naspram održavanja za taj planski period. Vidi se da je 60% rada bilo van cilja i da najveći deo toga vodi na dve prijave iz podrške koje su prebačene u delivery bez OKR-a. To nije opravdanje ni optužba, nego nalaz: ili su te prijave zaista bile važnije od cilja, i onda cilj treba promeniti, ili nisu, i onda treba promeniti ko sme da prebacuje prijave u sprint.

Drugi: predlog koji stiže spolja. Korisnik na javnom portalu predloži nešto što dobije trideset glasova. Predlog se pretvara u priliku u Discovery-ju. Prilika dobija dokaze iz dva postojeća intervjua, dobija RICE skor i ispada treća po redu - ne prva. Umesto da se odbije ćutanjem, na portalu ostaje vidljiva sa statusom. Kvartal kasnije za nju se pravi eksperiment, eksperiment se promoviše u TEST karticu, pada, i to ostaje zapisano uz metodologiju. Ukupno vreme utrošeno na ideju: nekoliko dana umesto celog kvartala. Ukupno vreme sačuvano sledećem čoveku koji pomisli istu stvar: ceo kvartal.

Nijedan od ta dva scenarija ne zahteva sve što je gore nabrojano. Zahtevaju cilj, priliku, tiket i jednu vezu između njih. Ostalo je za kasnije, kad zaboli.