Prepustite AI rutinu, vratite čoveku — ljudsko

Ceo stek za jedan dan: od ideje do funkcionalnog bota

Kontekst

Dan 1 projekta „Dnevnici navigacija". Istraživačka agencija se priprema da pokrene dnevničko istraživanje: 32 ispitanika tokom 7 dana beleže svako putovanje po gradu u Telegram grupama. Metodologija je složena, tim je distribuiran, podataka će biti mnogo.

Rukovodilac projekta — nije programer. Iskustvo sa kodom: nula. Alat: Cursor (IDE sa AI asistentom). Zadatak: za jedan dan napraviti funkcionalnu infrastrukturu koja će raditi tokom cele nedelje terenskog rada.

---

Šta je bilo na početku

• Glasovna poruka sa opisom zadatka: „hoću da postoji botić u Telegramu koji odgovara prema metodologiji iz baze znanja"
• Folder na Google Drive-u sa metodologijom
• Nijedna linija koda
• Nijedan podešen servis

Šta je bilo posle 8 sati

• Telegram bot koji odgovara na pitanja o metodologiji (/kb)
• Bot koji prikuplja zapise iz dnevnika iz četova (tekst, foto, audio, krugovi)
• Automatska transkripcija glasovnih poruka
• Čuvanje svega na Google Drive u strukturirane foldere
• Sinhronizacija dnevnika sa lokalnim računarom
• Automatsko ažuriranje baze znanja po rasporedu
• Deploy na Render sa auto-deploy-om iz GitHub-a
• Sistem brzih komandi za upravljanje svim time

Kako je to bilo moguće

Ceo dijalog — to je ~5800 linija prepiske u Cursor-u. Rukovodilac projekta je opisivala zadatke glasovnim porukama i tekstom, AI asistent je pisao kod, objašnjavao svaki korak, debagovao greške prema screenshot-ovima i logovima. Svaka odluka je donošena zajednički: AI je predlagao varijante, čovek je birao.

Ključni principi koji su se formirali u procesu:

• „Sve što možeš da napraviš sam — pravi sam" — čovek daje samo tajne podatke (tokene, ključeve), AI radi ostalo
• Vođenje korak po korak — svaki screenshot korisnika → objašnjenje → sledeći korak
• Prvo commit + push, pa deploy — pravilo koje je nastalo posle zabune sa redosledom radnji

---

Čemu služi ovaj projekat

Ovo nije priča o tome kako je programer napisao bota. Ovo je priča o tome kako je istraživač, koji nikada nije pisao kod, za jedan dan dobio funkcionalnu infrastrukturu za terensku fazu.

Napravili bota za bazu znanja o metodologiji

Problem

Metodologija dnevničkog istraživanja — to su desetine stranica: kako opisati probleme i pokretače, šta reći na uvodnom sastanku, kako beležiti nalaze, formati zapisa, čeklistovi, primeri i anti-primeri. Tim je distribuiran: istraživači, regruteri, naručilac.

Šta je bilo nezgodno:

• Da bi se podsetio formata opisa problema, treba otvoriti Google Drive, pronaći pravi fajl, pronaći pravi odeljak
• Istraživač na terenu to neće raditi — pitaće u četu i dobiće približan odgovor od kolege
• Nema jedinstvenog mesta gde se brzo dobija tačan izvod iz metodologije
• Novi članovi tima moraju da čitaju sve u celini

Šta je potrebno:

• Bot u Telegram-u kome se može postaviti pitanje na prirodnom jeziku
• Odgovor iz baze znanja, a ne izmišljotina AI-ja
• Link na konkretan odeljak/dokument

---

Šta smo uradili

Arhitektura:

• Telegram Bot (BotFather → token)
• FastAPI backend na Python-u
• OpenAI Responses API + vector store sa metodologijom
• Komanda /kb <pitanje> → odgovor iz baze znanja

Izbor modela: gpt-4.1-mini. Za FAQ bota sa retrieval-om — dovoljno. Može se promeniti jednom linijom kasnije.

---

Čemu to služi

Istraživačima — pitati „kako opisujemo barijeru?" i dobiti tačan izvod iz metodologije za 3 sekunde, bez otvaranja Google Drive-a.

Rukovodiocu projekta — ne odgovarati na ista pitanja. Bot odgovara preciznije jer citira dokument, a ne prepričava po sećanju.

Deploy-ovali bota: od „šta je GitHub" do funkcionalnog servisa

Problem

Kod bota je napisan, ali leži na lokalnom računaru. Rukovodilac projekta nikada nije deploy-ovala aplikacije, nije radila sa GitHub-om.

Šta smo uradili

Proces korak po korak: GitHub → Git config → Push → Render → Webhook → Debug. Dva baga su rešena za minute (stara verzija SDK-a, neplaćeni API).

Rešenje: Render Free. Kašnjenja pri buđenju nisu kritična za istraživačkog bota.

Podesili sinhronizaciju fajlova između Google Drive-a i lokalnog diska

Google Drive for Desktop za metodologiju (dvosmerna sinhronizacija) + rclone za dnevnike (Drive → lokalni disk, samo kopiranje).

Naučili bota da prikuplja dnevnike iz Telegram-a

Automatsko prikupljanje celokupnog sadržaja iz 32 četa: tekst, foto, audio, video → Google Drive u strukturirane foldere. Transkripcija putem Whisper-a.

Izgradili sistem komandi i dokumentovali pajplajn

Dve ključne komande: „ažurirala sam metodologiju" i „sinhronizuj dnevnike". Pajplajn-podsetnik za tim.

Naučili bota da prikuplja dnevnike iz Telegram-a

Problem

32 ispitanika će voditi dnevnike u Telegram grupama: tekst, glasovne poruke, foto, video-krugovi. Svaki — u zasebnom četu sa istraživačem. To je ~150–200 zapisa dnevno, raspoređenih po 32 grupe.

Šta je bilo nezgodno:

• Informacije žive samo u Telegram-u — ako se ne sačuvaju, izgubiće se u toku poruka
• Ručno čuvanje je nemoguće: 32 grupe × 7 dana = stotine fajlova
• Glasovne poruke treba ponovo slušati — nema tekstualne transkripcije
• Nema strukture: gde je zapis od konkretnog ispitanika za konkretan dan?

Šta je potrebno:

• Automatsko prikupljanje celokupnog sadržaja iz četova
• Čuvanje na Google Drive u strukturirane foldere po ispitanicima i datumima
• Automatska transkripcija audio zapisa i krugova
• Strukturirani nazivi fajlova

---

Varijante koje smo razmatrali

1. Bot proverava istoriju četa 3 puta dnevno

Prednosti: može se podesiti raspored, ništa se neće propustiti. Mane: Telegram API ne dozvoljava botu da čita istoriju četa. Bot prima samo ono što dolazi u realnom vremenu putem webhook-a.

Rešenje: odbijeno. To je ograničenje Telegram API-ja — bot vidi samo nove poruke.

2. Prikupljanje u realnom vremenu putem webhook-a (izabrali smo)

Prednosti: ništa se ne gubi, svaka poruka se obrađuje odmah. Mane: ako server padne — poruke su izgubljene (Telegram ponavlja webhook nekoliko puta, ali ne beskonačno).

---

Problem sa Google Drive-om: „Moj disk" vs „Računari"

Neočekivana poteškoća: servisni nalog Google-a vidi samo „Moj disk", a Google Drive for Desktop sinhronizuje fajlove u odeljak „Računari". To su različita mesta.

Rukovodilac se iznenadila: „Bot koji nam radi, on će nositi na Google Disk, na moj disk, zar ne?" — tačno, ali ne u „Računare", već u „Moj disk".

Rešenje: napraviti folder za dnevnike u „Moj disk", podeliti ga sa servisnim nalogom. Ali servisni nalog nije mogao da piše u lični Drive (nema Shared Drive na besplatnom nalogu).

Konačno rešenje: OAuth pristup umesto servisnog naloga. Dobili refresh_token putem skripte za autorizaciju, dodali u Render.

---

Šta smo uradili

1. Isključili Privacy Mode U BotFather-u: /setprivacy → Disable. Bez toga bot vidi samo komande (/kb), a obične poruke ignoriše.

2. Napravili strukturu foldera 33 foldera: po jedan za svakog ispitanika + testni. Latiničnim pismom — ćirilica je izazivala greške. Podfolderi sa datumima se kreiraju automatski pri prvoj poruci.

3. Podesili prikupljanje svih formata

Format	Šta radi bot	Šta se čuva
Tekst	Čuva kao .md	fajl sa tekstom zapisa
Foto	Preuzima fajl	foto u formatu .jpg
Glasovna poruka	Preuzima + transkribuje	audio + tekstualna transkripcija
Krug	Preuzima + transkribuje audio zapis	video + tekstualna transkripcija
Video	Preuzima fajl	video u formatu .mp4

Transkripcija — OpenAI Whisper (whisper-1).

4. Evolucija formata u procesu

• Prva verzija: JSON. Rukovodilac: „format JSON — najoptimalniji za naše zadatke?" → ne, za istraživače je potreban format čitljiv za ljude
• Druga verzija: .txt. Rukovodilac: „txt mi se ne sviđa, hajde markdown"
• Finalna verzija: .md za tekst i transkripte, mediji kako jesu

5. Imenovanje fajlova Prva verzija: message_1.md, message_2.md. Rukovodilac je tražila: „prvo ime ispitanika, pa datum, broj i vreme". Rezultat: strukturirani nazivi sa identifikatorom ispitanika, datumom i vremenom.

---

Testiranje

Testirali smo na testnoj grupi gde je rukovodilac bila „ispitanik":

1. Poslali tekst → pojavio se folder sa datumom, ali su fajlovi prazni → logovi → greška upisa na Drive → OAuth nije podešen → podesili → proradilo
2. Poslali audio → fajl + transkripcija sačuvani
3. Proverili krug → čuva se

---

Kako to funkcioniše

1. Ispitanik piše u Telegram grupu (tekst/foto/audio/krug)
        ↓
2. Telegram šalje webhook na Render
        ↓
3. Bot identifikuje ispitanika po chat_id
        ↓
4. Kreira folder za dan, ako ne postoji
        ↓
5. Preuzima medija fajl sa Telegram servera
        ↓
6. Ako je audio/video → šalje u Whisper → čuva transkripciju
        ↓
7. Sve otprema na Google Drive u folder ispitanika
        ↓
8. Na komandu „sinhronizuj dnevnike" → rclone kopira na lokalni disk

---

Čemu to služi

Istraživačima — svi zapisi ispitanika u jednom folderu, sa transkripcijama. Nema potrebe da ponovo slušaju glasovne poruke — tekst je već tu.

Rukovodiocu projekta — strukturiran arhiv za analizu. Svako putovanje — u fajlu sa razumljivim nazivom.

Za analizu — na osnovu ovih podataka će se kasnije graditi kartice monitoringa, tabela trekinga putovanja i analitički izveštaji.

Prenos konteksta između AI sesija

Problem

Do kraja prvog dana kontekstni prozor AI asistenta u Cursor-u se popunio: ~5800 linija dijaloga. Asistent je počeo da „zaboravlja" ranije dogovore. Bilo je potrebno otvoriti novu sesiju — ali kako joj preneti sve što je urađeno?

Šta smo uradili

Strukturiran summary od 7 blokova: baza znanja, bot, dnevnici, Render ENV, OAuth, rclone, pravila. Rukovodilac je kopirala summary na početak novog dijaloga — i novi agent je odmah razumeo kontekst.

Ovaj obrazac „primopredaje smene" se kasnije pretvorio u stalni sistem: fajl MEMORY.md (učitava se automatski pri svakoj sesiji Claude Code) i CLAUDE.md (instrukcije projekta).

Popravili prikupljanje dnevnika: 4 baga, 4 commit-a

4 uzastopna commit-a, svaki po konkretnoj grešci iz Render logova:

1. JSON umesto MD na Drive-u
2. Foto/audio se ignorišu
3. UnboundLocalError: media_paths
4. Whisper: Invalid file format

Ceo ciklus „bag → fix → deploy → provera" trajao je 3–5 minuta po bagu.

Kašnjenja na besplatnom Render-u: svestan izbor „ne popravljaj"

Odluka „ne popravljaj sada" uštedela je vreme za važnije zadatke. Tri varijante optimizacije su bile spremne, ali umesto da se arhitektura komplikuje unapred, izabrali smo monitoring (YAGNI).

Prelazak iz Cursor-a u Claude Code: novi horizonti dirigenta

U Cursor-u je rukovodilac bila operater: AI je govorio „klikni ovde", ona je klikala. U Claude Code-u je rukovodilac postala dirigent: ona kaže „ažuriraj monitoring" — i sve se dešava.

Aspekt	Cursor	Claude Code
Commit i push	AI piše kod, traži da se uradi commit	AI radi commit + push sam
Pokretanje skripti	„Ubaci ovu komandu u PowerShell"	AI pokreće skriptu direktno
Kontekst između sesija	Ručno kopiranje summary-ja	MEMORY.md se učitava automatski

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Dnevničko istraživanje, 32 ispitanika. Regruteri šalju tok kandidata iz skrinig ankete — desetine ljudi, svakog treba oceniti po nekoliko parametara: geografija, bihejvioralni profil, učestalost kontakta sa predmetom istraživanja, raznovrsnost situacija, korišćeni alati, angažovanost.

Šta je bilo nezgodno:

• Odluke „uzimamo / ne uzimamo" su se donosile prema osećaju — regruter je gledao anketu i davao preporuku intuitivno
• Kada ima mnogo kandidata, kriterijumi počinju da variraju: prve ocenjuješ strogo, do dvadesetog — umoriš se i propuštaš nijanse
• Nema zabeleženog obrazloženja: ako naručilac pita „zašto je ovaj uzet, a onaj ne?" — odgovor je samo u glavi regrutera
• Greške klasifikacije: regruter je zapisala Perm i Rostov u „velike gradove" — po osećaju su veliki, ali po mreži projekta to su „srednji". Bez formalizacije takve greške se ne otkrivaju
• Rezultati procene nigde nisu čuvani strukturirano — nemoguće se vratiti i uporediti kandidate

Šta je potrebno:

• Formalizovana rubrika: šta tačno ocenjujemo, po kojoj skali, sa kojom težinom
• Automatski proračun bodova po podacima iz ankete
• Tekstualno obrazloženje za svakog kandidata — razrada po kriterijumima
• Rezultati u tabeli rasporeda intervjua: regruter i rukovodilac vide bod, preporuku i komentar direktno u radnom dokumentu

---

Varijante koje smo razmatrali

1. Ručna ocena od strane regrutera

Prednosti: brzo, nisu potrebni alati. Iskusan regruter oseća „svog" kandidata. Mane: neponovljivo (dva regrutera će oceniti istu osobu različito), nema obrazloženja za naručioca, greške klasifikacije se ne otkrivaju, umor pri velikom toku.

Rešenje: odbijeno kao jedini metod. Ali živa ekspertiza regrutera se zadržava u sledećim fazama (poziv).

2. Bodovna rubrika + skripta za automatski skoring (izabrali smo)

Prednosti:

• Svaki kandidat se ocenjuje po istim kriterijumima sa istim pragovima
• Numerički bod + tekstualno obrazloženje — može se pokazati naručiocu
• Skrineri (šetači, profesionalna upotreba, sukob interesa) se proveravaju automatski — nijedan neće proći
• Greške klasifikacije se otkrivaju: skripta zna da je Perm = „srednji" i neće propustiti
• Rezultati se zapisuju u Excel — regruter ih vidi u uobičajenom radnom dokumentu

Mane: potrebno je vreme za razvoj rubrike i skripte. Skripta ne vidi ono što vidi živi regruter (intonaciju, motivaciju, nijanse). Zato je ovo dopuna regruteru, a ne zamena.

---

Šta smo uradili

1. Razvili rubriku od 25 bodova sa 8 kriterijuma

Svaki kriterijum je vezan za zadatke istraživanja, a ne za apstraktan „kvalitet kandidata": geografija, bihejvioralni profil, učestalost kontakta, raznovrsnost situacija, korišćeni alati, učestalost korišćenja, varijabilnost uslova, angažovanost. Težina svakog kriterijuma odražava njegov značaj za ciljeve projekta.

Ključna odluka: situacioni korisnici (koriste alat ne uvek, već u zavisnosti od konteksta) dobijaju maksimalni bod za bihejvioralni profil. Ne „uvek" (predvidljiv, bez barijera) i ne „nikada" (malo materijala), već upravo onaj koji ponekad uključuje, ponekad ne. Kod njega su najzanimljiviji prelazi i okidači.

2. Napisali skriptu za automatski skoring

Skripta na Python-u (+ openpyxl):

• Čita ankete iz Excel-a
• Primenjuje svih 8 kriterijuma
• Proverava stroge skrinere: profesionalni panelisti, profesionalna upotreba predmeta istraživanja, zaposleni naručioca, nespremnost za format
• Zapisuje u Excel tri kolone: komentar (razrada po kriterijumima), preporuku, bod

Pragovi: >=18 = preporučen, 15–17 = uslovno (proveriti prilikom poziva), <15 = nije preporučen.

3. Preneli rezultate u tabelu rasporeda intervjua

Putem skripti za ažuriranje rezultati skoringa su se upisivali u radnu tabelu regrutera — fajl rasporeda intervjua. Pet kolona: GEO segment, kvota, komentar sa obrazloženjem, preporuka, numerički bod. Regruter otvara uobičajeni dokument i vidi za svakog kandidata: zašto je dobio takav bod, na šta obratiti pažnju prilikom poziva.

4. Povezali automatiku sa živom ekspertizom

Skoring — to je prvi filter. Dalje regruter zove kandidate iz zona „preporučen" i „uslovno" i proverava ono što skripta neće uhvatiti:

• Da li se anketa poklapa sa onim što osoba priča glasom
• Motivacija: da li je zainteresovan za iskustvo ili samo za naknadu
• Artikulisanost: da li može da opiše svoje iskustvo svojim rečima

Ako je skoring označio nešto kao „proveriti prilikom poziva" — regruter ciljano razjašnjava upravo to.

---

Čemu to služi

1. Regruteru — ne pogađati „uzimamo ili ne", već videti numerički orijentir i konkretne oznake za poziv. Fokusirati vreme na kandidate iz zone „uslovno", a ne pregledati sve.
2. Rukovodiocu projekta — objasniti naručiocu zašto uzorak izgleda upravo tako. Pokazati rubriku, bodove, obrazloženja — umesto „smatramo da ovi odgovaraju".
3. Projektu — otkrivati greške klasifikacije (gradovi, bihejvioralni obrasci) pre nego što kandidat uđe u uzorak. Jedna takva greška = pokvarena kvota.
4. Timu — jedinstven jezik: „preporučen 21/25" je razumljivije od „kao da je ok".

---

Kako to funkcioniše

1. Kandidat popunjava skrinig anketu
        ↓
2. Podaci dolaze u Excel (Preliminarni odabir)
        ↓
3. Skripta proverava 8 kriterijuma + skrinere
        ↓
4. U Excel se upisuju: bod, preporuka, komentar po kriterijumima
        ↓
5. Rezultati se prenose u tabelu rasporeda intervjua
        ↓
6. Regruter vidi bod i oznake → zove kandidata sa konkretnim pitanjima
        ↓
7. Konačna odluka: skoring + utisak regrutera sa poziva

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Drugog dana terenske faze istraživanja imamo 6 aktivnih ispitanika (+ 1 testni), svaki od kojih beleži 1–5 putovanja dnevno. Za nedelju dana to je ~150–200 zapisa u Telegram grupama.

Šta je bilo nezgodno:

• Zapisi su razbacani po 32 zasebne Telegram grupe
• Da bi se razumelo šta se dešava sa konkretnim ispitanikom, treba pročitati sve njegove poruke za sve dane
• Nema jedinstvenog mesta gde istraživač vidi sliku o ispitaniku: šta je već shvaćeno, šta je novo danas, šta vredi dodatno pitati
• Rukovodilac projekta ne može brzo proceniti napredak po svim ispitanicima
• Priprema za dubinski intervju zahteva ručnu svodku za svaku osobu

Šta je potrebno:

• Kompaktna kartica za svakog ispitanika, ažurirana svakodnevno
• Vidljivi obrasci, barijere, pokretači, odstupanja od kvote
• Povezanost sa poslovnim zadacima istraživanja
• Pitanja za intervju — konkretna, vezana za putovanja
• Pristup za ceo tim, ali zatvoren od spoljnih lica

---

Varijante koje smo razmatrali

1. Automatska generacija na serveru (GPT-4.1-mini na Render-u)

Prednosti: potpuno automatski, bez učešća čoveka. Mane: GPT-4.1-mini je previše slab model za kvalitetnu istraživačku analizu. Površni zaključci, nema dubine, neće uočiti suptilne obrasce. Potreban je bar GPT-4 ili Claude Opus — a to zahteva API ključ i dodatne troškove.

Rešenje: odloženo. Nije taj nivo kvaliteta za istraživačku analizu.

2. Claude API na serveru (Anthropic API na Render-u)

Prednosti: visok kvalitet analize (Claude Opus), automatski po rasporedu. Mane: potreban je API ključ Anthropic-a (posebno plaćanje), podešavanje promptova, dodatni troškovi po svakom zahtevu.

Rešenje: odloženo. Nema API ključa, i u ovoj fazi to je preterano.

3. Claude Code na računaru istraživača (izabrali smo)

Prednosti:

• Maksimalan kvalitet analize (Claude Opus 4.6 — najjači model)
• Nikakvi dodatni troškovi (uključeno u pretplatu na Claude)
• Puna kontrola: čovek vidi i može da ispravi rezultat
• Fleksibilnost: može se zatražiti analiza za jednog ispitanika ili za sve

Mane: nije potpuno automatski — treba pokrenuti ručno. Ali to je 1 minut: otvoriti Claude Code → napisati „ažuriraj monitoring" → gotovo.

Čuvanje kartica: Google Drive vs Git

Prvobitno smo planirali da otpremamo kartice na Google Drive. Ali servisni nalog Google-a ne može da kreira fajlove (nema kvote za skladištenje).

Konačno rešenje: kartice se čuvaju u repozitorijumu bota, pri push-u u main Render automatski deploy-uje ažurirani sajt. Dodatno se kopija čuva lokalno.

---

Šta smo uradili

1. Proširili skil UX analitičara (7 → 9 režima)

Dodana su dva nova režima:

• Režim 8 — Kartica monitoringa ispitanika. Kompaktan živi dokument: ko je to, šta vidimo (obrasci, barijere, pokretači, odstupanja), šta to znači za biznis, šta dodatno pitati, hronologija putovanja. Ažurira se svakodnevno, svako ažuriranje = delta.

• Režim 9 — Dnevna svodka uvida. Telegram post za tim: kros-ispitanička analiza za dan, ključni nalazi, trendovi, zadaci za istraživače. (Za sada nije tehnički realizovan, format je spreman.)

2. Napravili uslužne alate za monitoring

Skripta za monitoring:

• Sinhronizacija dnevnika sa Google Drive-a
• Čitanje zapisa po ispitaniku i datumu
• Čuvanje kartica na dva mesta (lokalno + za veb sajt)
• CLI interfejs za debagovanje

3. Napravili veb stranicu monitoringa

Zaštićena stranica monitoringa:

• Pristup putem lozinke (odvojena od lozinke ispitanika)
• Tabovi po ispitanicima: „R-01, pešak, Voronež"
• Kartice renderovane iz Markdown-a u HTML
• Responzivan dizajn za mobilne uređaje
• Direktan link na ispitanika po identifikatoru

4. Generisali kartice za ispitanike

Svaki ispitanik — ima svoju karticu monitoringa. U njoj: profil, akumulirani obrasci, barijere i pokretači, ključni uvidi za svaki dan i pitanja za dubinski intervju. Kartice se ažuriraju svakodnevno sa pristizanjem novih zapisa.

---

Čemu to služi

1. Istraživačima — videti akumulirano razumevanje o ispitaniku pre postavljanja pitanja. Ne čitati ponovo sve zapise, već otvoriti karticu i za 2 minuta razumeti sliku.

2. Rukovodiocu projekta — brzo proceniti napredak: ko ima zanimljive obrasce, ko ima malo podataka, gde su odstupanja od kvote.

3. Priprema za intervju — blok „Šta dodatno pitati" sa vezom za konkretna putovanja = gotova osnova za vodič dubinskog intervjua.

4. Za naručioca — blok u svakoj kartici pokazuje šta nalazi znače za proizvod.

---

Kako to funkcioniše (tehnički lanac)

1. Ispitanici pišu u Telegram grupe
        ↓
2. Bot čuva zapise na Google Drive
        ↓
3. Claude Code sinhronizuje dnevnike na lokalni računar
        ↓
4. Claude Code (Opus 4.6) čita zapise i generiše/ažurira kartice
        ↓
5. Kartice se čuvaju lokalno i u repozitorijumu za sajt
        ↓
6. Git push → Render auto-deploy → sajt ažuriran
        ↓
7. Tim otvara stranicu monitoringa

Napravili tabelu trekinga putovanja u Google Sheets

Problem

Kartice monitoringa daju opštu sliku o ispitaniku, ali za finalni izveštaj i pripremu za intervju potrebno je raditi sa podacima na nivou pojedinačnih putovanja.

Šta je bilo nezgodno:

• Nema jedinstvenog skladišta gde je svako putovanje — zaseban red sa punim kontekstom
• Ne može se brzo filtrirati: „pokaži sva putovanja bez navigacije na poznatim rutama" ili „pokaži sve barijere"
• Informacije o jednom putovanju mogu se akumulirati 1–2 dana (ispitanik je zabeležio putovanje, istraživač je postavio pitanja, ispitanik je odgovorio sledećeg jutra) — nema gde sve to objediniti
• Istraživači ne mogu da vide analitiku i ostavljaju komentare na istom mestu
• Nema strukturiranog analitičkog sloja: tip uvida, snaga uticaja, grupa funkcionalnosti, pitanja za intervju

Šta je potrebno:

• Tabela sa punim podacima svakog putovanja + analitičkim slojem
• Filtriranje po bilo kom parametru (tip rute, navigacija da/ne, aplikacija, tip uvida)
• Pristup za istraživače sa mogućnošću komentarisanja
• Svakodnevno ažuriranje: nova putovanja, dopune starih, obrada komentara
• Kolona „Pun tekst" — SVE informacije o putovanju bez skraćivanja

---

Varijante koje smo razmatrali

1. Lokalni Excel/CSV

Prednosti: lako napraviti, poznat format. Mane: nema zajedničkog pristupa, istraživači ne vide i ne mogu da komentarišu. Potrebno je prosleđivati fajl posle svakog ažuriranja.

Rešenje: ne odgovara. Timski rad je važniji.

2. Google Sheets sa ručnim popunjavanjem

Prednosti: zajednički pristup, komentari, filteri. Mane: ručno popunjavanje ~30 kolona za svako putovanje — nerealno pri 5–10 putovanja dnevno. Analitički sloj zahteva ekspertsko popunjavanje po taksonomiji.

Rešenje: ne odgovara. Previše naporno ručno.

3. Google Sheets + automatsko popunjavanje preko Claude Code (izabrali smo)

Prednosti:

• Zajednički pristup za tim (komentari)
• Automatsko popunjavanje iz sirovih dnevnika (Claude Code čita zapise, raščlanjuje na putovanja, popunjava sve kolone)
• Analitički sloj se popunjava po taksonomiji uvida (8 tipova) sa vezom za analitički okvir projekta
• Svakodnevno ažuriranje jednom komandom: „trekuj tabelu"
• Komentari istraživača se obrađuju interaktivno

Mane: popunjavanje nije potpuno automatsko — treba pokrenuti ručno. Ali to je isti model kao i sa monitoringom: komanda → rezultat.

---

Šta smo uradili

Napravili poseban skil Claude Code (diary-tracking)

Skil je odvojen od analitičkog — različite uloge, različiti ritmovi. Analitičar duboko raščlanjuje zapise. Data-inženjer ih strukturira u tabelu.

Tri režima rada:

• Režim 1 — Primarno kreiranje taba ispitanika (jednom)
• Režim 2 — Svakodnevno ažuriranje (~12:00 MSK): nova putovanja + dopune + komentari
• Režim 3 — Priprema za intervju (kraj nedelje): finalizacija svodke, odstupanja, prioritetna pitanja

Projektovali strukturu tabele

Jedan tab = jedan ispitanik. Tri zone na tabu:

Zona	Kolone	Šta sadrži
Portret (sidebar)	A–D	Kartica ispitanika: segment, grad, kvota, stil, istraživač
Tabela putovanja	E–V	18 kolona: ruta, cilj, kontekst, navigacija, transkripcija, pun tekst
Analitički sloj	W–AD	8 kolona: tip uvida, formulacija, snaga, grupa funkcionalnosti, pitanje za intervju

Plus svodka po ispitaniku (obrasci, barijere, pokretači, odstupanja) — u zasebnim kolonama desno.

Testirali na jednom ispitaniku

• 2 dana dnevnika, 7 putovanja
• 51 fajl zapisa (tekst, transkripcije glasovnih poruka, dijalozi sa istraživačem)
• Svi podaci su raščlanjeni i upisani u tabelu, uključujući pune tekstove glasovnih poruka

Iterirali layout po povratnim informacijama

Prva verzija: portret na vrhu (10 redova), pa prazni redovi, pa tabela. Problem: tabela ne staje na ekran, nezgodno.

Druga verzija: portret — kompaktan sidebar levo (kolone A–D, zaključane). Tabela putovanja počinje od prvog reda. Red sa zaglavljima i filterima je zaključan. Sve se vidi odmah pri otvaranju.

Obavestili tim

Poslali u timski čet uputstvo: šta je u tabeli, kako je organizovana, kako ostavljati komentare, redosled svakodnevnog ažuriranja.

---

Kako to funkcioniše

1. Ispitanici pišu u Telegram → bot čuva na Google Drive
2. Claude Code sinhronizuje dnevnike na lokalni računar
3. Claude Code čita zapise, raščlanjuje na putovanja (šablon od 9 tačaka + glasovne poruke + dijalozi)
4. Svako putovanje → red u Google Sheets (svih 26 kolona)
5. Analitički sloj se popunjava po taksonomiji uvida projekta
6. Istraživači otvaraju tabelu, filtriraju, ostavljaju komentare
7. Pri sledećem ažuriranju komentari se obrađuju interaktivno (rukovodilac projekta odlučuje šta sa svakim uraditi)

Svakodnevni ciklus (~12:00 MSK):

• Komanda „trekuj tabelu" → sinhronizacija dnevnika → raščlanjivanje novih putovanja → ažuriranje redova (uključujući dopune starih putovanja) → ažuriranje analitike → obrada komentara → izveštaj

---

Zašto je to potrebno

Za finalni izveštaj — strukturirani podaci po svakom putovanju sa analitičkim slojem. Nije potrebno ponovo čitati 500+ poruka — sve je u jednoj tabeli sa filterima.

Za pripremu za intervju — svodka po ispitaniku + prioritizovana pitanja vezana za konkretna putovanja. Otvoriš tab — spreman si za intervju.

Za istraživače — mogućnost da vide analitiku i utiču na nju kroz komentare. Ne „crna kutija", već zajednički rad.

Za kros-ispitaničku analizu — ista struktura po svim ispitanicima omogućiće na kraju projekta poređenje, grupisanje i izgradnju tipologija.

Razlika u odnosu na monitoring — monitoring daje brzu sliku „šta se dešava". Tabela daje pune podatke „šta tačno i zašto" — za duboku analizu i izveštaj.

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Četvrtog dana terenske faze pokrenuto je 16 od 32 dnevnika. Regruteri biraju ispitanike po kvotnoj matrici sa nekoliko dimenzija — ciljni broj ispitanika u svakoj ćeliji.

Šta je bilo nezgodno:

• Da bi se razumelo trenutno stanje kvota, treba otvoriti fajl „Profili ispitanika", ručno izbrojati koliko je ljudi u svakoj ćeliji matrice i uporediti sa ciljnim brojevima
• Regruteri nemaju brz način da saznaju ko nedostaje — treba pitati rukovodioca
• Skoring kandidata (sistem od 25 bodova, 8 kriterijuma) se radio skriptom jednom u fazi odabira. Oceniti novog kandidata u hodu nemoguće — treba podići skriptu, razumeti kolone u Excel-u
• Kreiranje profila novog ispitanika — ručni posao: pronaći podatke u Excel-u, popuniti šablon, ažurirati zbirnu tabelu, preračunati kvote
• Nema provere da li za svaki pokrenut dnevnik postoji profil (i obrnuto)

Šta je potrebno:

• Trenutni izveštaj o kvotama po komandi — u Telegram-u, za ceo tim
• Mogućnost ocene kandidata po 8 kriterijuma za 1 minut
• Automatizacija kreiranja profila i ažuriranja kontrole kvota
• Kros-provera: folderi dnevnika ↔ profili ↔ tabela trekinga

---

Varijante koje smo razmatrali

1. Samo komanda bota /kvote

Prednosti: brzo za realizaciju, dostupno celom timu u Telegram-u, ne zahteva Claude Code. Mane: prikazuje samo trenutno stanje. Ne pomaže da se oceni kandidat, kreira profil ili pronađu odstupanja. Izveštaj je statičan — parsira gotov fajl, ne analizira.

Rešenje: delimično — realizovali smo kao brzi alat za tim.

2. Samo Claude Code skil

Prednosti: duboka analiza, skoring, kreiranje profila, kros-provera — sve na jednom mestu. Mane: dostupan samo onome ko ima pokrenut Claude Code. Regruteri i administratori neće videti izveštaj bez rukovodioca.

Rešenje: delimično — realizovali smo za analitičke zadatke.

3. Komanda bota + Claude Code skil (izabrali smo)

Prednosti:

• Dva nivoa: brzi (bot, /kvote → HTML-izveštaj za 3 sekunde) i duboki (skil, 5 režima analize)
• Bot je dostupan svim 6 članova tima u Telegram-u
• Skil rešava zadatke koje bot ne može: skoring, profilisanje, kros-provera
• Jedinstven izvor podataka — fajl „Profili ispitanika.md" na Google Drive-u

Mane: dva alata umesto jednog — treba zapamtiti kada šta koristiti.

---

Šta smo uradili

1. Komanda bota /kvote

Novi modul za Telegram bota:

• Preuzima „Profili ispitanika.md" sa Google Drive-a (file_id iz konfiguracije)
• Parsira Markdown tabelu: RESP, ime, segment, grad, GEO, kvota, status
• Upoređuje sa ciljnom matricom (12 ćelija: 2×2×3)
• Generiše HTML-izveštaj sa kolornom indikacijom (zeleno / žuto / crveno) i listom deficita
• Šalje u čet odakle je pozvana komanda

Izmenjeno je 5 postojećih fajlova: handler komande, prepoznavanje komande, konfiguracija Google Drive-a, metod preuzimanja, zavisnosti (openpyxl).

2. Skil recruitment-analyst (5 režima)

Režim	Okidač	Šta radi
1. Skoring kandidata	„oceni kandidata"	8 kriterijuma iz skoring skripte, tabela bodova, preporuka po pragovima
2. Analiza kvota	„proveri kvote"	Parsira profile, upoređuje sa matricom, pronalazi deficite i iskrivljenja
3. Kreiranje profila	„napravi profil"	Uzima podatke iz Excel-a/od regrutera, popunjava šablon, ažurira kontrolu kvota
4. Kros-provera	„kros-provera"	Upoređuje foldere dnevnika sa profilima: ko postoji, ko nedostaje
5. Generisanje posta	„napiši post za regrutere"	Ljudski čitljiv HTML-post za timski čet

4 referentna fajla: sistem skoringa (25 bodova), kvotna matrica (ciljna), šablon profila, struktura Excel fajlova.

3. Povezivanje skila write-case-study

Otkrili smo da je skil za pisanje kejsova ležao u korenu projekta, a ne u .claude/skills/. Premestili smo ga — skil se automatski prepoznao.

4. Ažuriranje priručnika komandi

Tabela komandi proširena sa 5 na 10 redova + zasebna sekcija komandi Telegram bota.

---

Zašto je to potrebno

1. Regruterima — videti deficite kvota direktno u Telegram-u za 3 sekunde (/kvote), bez pristupa Claude Code-u.
2. Rukovodiocu projekta — ocenjivati nove kandidate po 8 kriterijuma za 1 minut umesto ručne analize Excel-a.
3. Istraživačima — kros-provera: brzo pronaći ispitanike bez profila ili profile bez zapisa.
4. Timu — jedinstven priručnik od 10 komandi + 5 komandi bota. Ne treba pamtiti šta je gde — dovoljno je reći „podseti me na komande".

---

Kako to funkcioniše

/kvote u Telegram-u

1. Član tima piše /kvote u timski čet
        ↓
2. Bot preuzima „Profili ispitanika.md" sa Google Drive-a
        ↓
3. Parsira tabelu, klasifikuje po kvotnoj matrici
        ↓
4. Generiše HTML-izveštaj sa deficitima
        ↓
5. Šalje u čet (3 sekunde)

Skil regrutera u Claude Code

1. Rukovodilac kaže „oceni kandidata" / „proveri kvote" / ...
        ↓
2. Claude Code učitava skil recruitment-analyst
        ↓
3. Čita podatke iz Excel-a / profila / foldera dnevnika
        ↓
4. Primenjuje skoring od 25 bodova / kvotnu matricu / šablon profila
        ↓
5. Daje strukturiran rezultat

Ekspres-analiza kandidata regrutera

Problem

Dan 4 terenske faze. Regruter šalje u radni čet listu od 8 kandidata sa molbom da se proveri da li „svi GEO odgovaraju". Izgleda jednostavno — ali u praksi treba istovremeno držati u glavi:

Šta je teško uraditi ručno:

• Setiti se koji gradovi se smatraju „velikim" po našoj mreži
• Izbrojati koliko je slotova slobodno u svakoj od 6 ćelija kvotne matrice za pešake
• Proveriti geografski balans: iz kojih gradova već ima ispitanika, gde je višak, gde je prazno
• Formulisati jasnu preporuku: koga uzimamo, koga ne, šta još treba naći

Procena utrošenog vremena: ~30 minuta ručnog rada — otvoriti profile, kvotnu matricu, portret ciljne grupe, izbrojati, proveriti, napisati odgovor.

---

Varijante koje smo razmatrali

1. Odgovoriti „napamet" iz glave

Prednosti: trenutno, nisu potrebni alati. Mane: lako se pogreši. Upravo tako je regruter zapisala Perm i Rostov u „velike" — po osećaju su veliki. Greške u klasifikaciji dovode do iskrivljenja kvota, koje se otkrivaju tek na kraju.

Rešenje: odbijeno. Prevelik rizik greške pri 12 ćelija i 16 promenljivih.

2. Ručna analiza: otvoriti sve dokumente, izbrojati

Prednosti: tačno, pouzdano. Mane: ~30 minuta rada. Rukovodilac projekta troši vreme na mehanički rad umesto istraživačkog.

Rešenje: tako smo radili do tog momenta.

3. Claude Code: učitati kontekst i dobiti analizu (izabrali smo)

Prednosti:

• Sav kontekst projekta je već u radnom direktorijumu: kvotna matrica, profili, portret ciljne grupe
• Analiza za 5 minuta umesto 30
• Pronalazi neočigledne konflikte (duplikat po gradu, konkurencija za isti slot)
• Odmah formuliše post za regrutera

Mane: treba proveriti rezultat — AI može da pogreši u nijansama. Ali proveriti gotovu analizu je brže nego raditi od nule.

---

Šta smo uradili

1. Zatražili od Claude Code da analizira listu kandidata

Kopirali smo poruku regrutera iz Telegram-a u Claude Code: „Pogledaj ispitanike, daj preporuku".

Claude Code je automatski:

• Pročitao kvotnu matricu iz modula kvota
• Pročitao trenutne profile iz fajla profila
• Pročitao portret ciljne grupe iz baze znanja
• Izbrojao popunjenost svake ćelije
• Klasifikovao gradove kandidata
• Pronašao konflikte

2. Otkrili grešku u klasifikaciji

Regruter je sve četiri kandidata zapisala za „veliki grad" — ali dvoje po našoj mreži spadaju u „srednji/mali". To nije intuitivno: oba grada su milionski.

Bez provere: 4 kandidata bi otišla u jednu ćeliju, 2 od njih — u pogrešnu.

3. Ljudski mozak obogaćuje AI: pol i uzrast

Nakon što je analiza bila gotova i postovi poslati, rukovodilac regrutinga je skrenula pažnju na ono što AI nije predvideo: polni i uzrastni balans uzorka.

Formalno u dogovoru sa naručiocem nema zahteva za ravnomernom raspodelom po polu i uzrastu. Zato ni kvotna matrica, ni skil regrutera, ni Claude Code ovaj parametar nisu pratili. Ali rukovodilac regrutinga — iskusan regruter — intuitivno je primetila iskrivljenje.

Šta je provera pokazala:

U trenutnom uzorku postojalo je primetno iskrivljenje po polu — značajna predominacija jednog pola. Po uzrastu: jedna uzrastna grupa uopšte nije bila zastupljena, a druga je bila prezastupljena.

To nije greška — tako se složilo po skriningu. Ali ako se ne prati, iskrivljenje će rasti.

Claude Code je brzo pronašao uzraste svih 8 kandidata u skrininškom Excel-u i napravio prognozu.

Šta se promenilo u preporuci:

Jedan od rezervnih ispitanika je dobio prioritet za razmatranje, jer je spadao u jedinstvenu kvotnu ćeliju koja do tada nije bila zastupljena u uzorku.

Zašto je ovo važno za kejs:

AI je odradio zadatak u okviru formalizovanih kriterijuma (kvote, GEO, ćelije). Ali čovek — rukovodilac regrutinga — video je ono što nije bilo u zadatku: demografski balans. Ovo je klasičan primer toga kako ljudski mozak zadaje pravac, a AI ubrzava izvršenje. Bez rukovodioca regrutinga ne bismo pogledali pol i uzrast. Bez Claude Code provera bi trajala još 30 minuta umesto 5.

---

Zašto je to potrebno

1. Rukovodiocu projekta — 5 minuta umesto 30 za analizu serije kandidata. Vreme odlazi na proveru rezultata, a ne na mehaničko brojanje.
2. Regruteru — jasan odgovor: koga uzimamo, koga ne, zašto. Plus edukativni post o klasifikaciji gradova — greška se više neće ponoviti.
3. Projektu — sprečena greška kvotiranja. Dva kandidata iz srednjih gradova nisu ušla u ćeliju „veliki" — kvote su ostale validne.
4. Timu — primedba rukovodioca regrutinga o polu i uzrastu otkrila je slepu tačku: formalizovani kriterijumi ne pokrivaju sve aspekte kvaliteta uzorka.

---

Kako to funkcioniše

1. Regruter šalje listu kandidata u radni čet
        ↓
2. Rukovodilac kopira poruku u Claude Code
        ↓
3. Claude Code čita kvotnu matricu + profile + portret ciljne grupe
        ↓
4. Analiza: klasifikacija gradova, brojanje slotova, traženje konflikata
        ↓
5. Rukovodilac proverava i koriguje preporuke
        ↓
6. Tim dopunjuje: pol, uzrast, drugi neformalizovani kriterijumi
        ↓
7. Gotovi postovi se šalju u radni čet

---

Metrike (intervju 2026-02-16)

━━━ Proračun D4-EXPRESS ━━━━━━━━━━━━━━━━━━━━━━━━━━━

  Bilo:  ~35 min × 3 serije = 105 min ≈ 1,75 č (istraživač)
  Postalo: ~5 min × 3 serije = 15 min = 0,25 č (rukovodilac + Claude Code)
  Učestalost: 3 puta za projekat

  Ušteda: 1,75 - 0,25 = 1,5 č
  Bonus: uhvaćena greška klasifikacije gradova,
         koju bi ručno propustili.

  → HRS saved: 1,5 č
  → PPL involved: 1 (istraživač — oslobođen)
  → Confidence: high

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Dnevna analitička svodka (režim 9)

Problem

14 ispitanika vodi dnevnike 1–2 dana. Kartice monitoringa su ažurirane, tabela trekinga je popunjena. Ali tim nema opštu sliku: šta se dešava u istraživanju u celini, koji se obrasci formiraju, šta to znači za proizvod.

Šta je bilo nezgodno:

• Nema redovne analitičke svodke po svim ispitanicima — samo pojedinačne kartice
• Rukovodilac vidi detalje, ali tim ne vidi kros-ispitaničke zaključke
• Nejasno koji nivo pouzdanosti je primeren u ranim danima (hipoteza vs tendencija)
• Preporuke istraživačima se dupliraju na različitim mestima

Šta je potrebno:

• Svakodnevni post sa kros-ispitaničkom analizom za tim
• Format kalibrisan prema fazi istraživanja (dani 1–3 vs dani 5–7)
• Vezanost za poslovne zadatke istraživanja, a ne samo nabrajanje putovanja

---

Šta smo uradili

Pokrenuli režim 9 i prošli 4 iteracije ispravki sa rukovodiocem

Iteracija	Bilo	Postalo	Princip
1	„dani 1–3"	„dani 1–2 dnevnika"	Preciznost: dan projekta ≠ dan dnevnika
2	Blok „Tendencije"	„Prva zapažanja i hipoteze"	Za 1–2 dana podataka nema dovoljno za tendencije
3	„Odstupanje kvota — sistemsko"	„Pojam navigacije je nejasan"	Frejming: uvid, a ne problem
4	Blok „Na pažnju istraživačima"	Link na monitoring	Ne duplirati kartice

Fiksirali 3 nova principa u promptu:

• Kalibracija pouzdanosti: dani 1–3 = hipoteze, dani 4–5 = potvrđuje se, dani 6–7 = stabilan obrazac
• Frejming za publiku: isti nalaz može zvučati kao problem ili kao uvid — biraj frejm koji prenosi suštinu
• Ne duplirati monitoring: preporuke po ispitanicima — u karticama na sajtu, u post — samo link

Ažuriran prompt za režim dnevne svodke: šablon formata, sekcija „Prvi dani", principi br. 6–8.

---

Zašto je to potrebno

Timu — videti opštu sliku istraživanja svakog dana za 3 minuta čitanja.

Rukovodiocu — 10 minuta za pregled svodke umesto 60 minuta za pisanje. Pravila kalibracije su fiksirana — sledeće svodke su tačnije odmah.

Za projekat — jedinstven ritam komunikacije: svakodnevna svodka + trenutni pristup resursima.

Komande brzog pristupa za bota

Problem

Zakačenih poruka u radnom četu se nakupilo toliko da je pronalaženje potrebnog linka (tabele, uputstva, rasporeda) — potraga. Lozinke za sajt, linkovi ka Google Drive dokumentima, uloge — sve je razbacano po prepisci.

Šta je potrebno:

• Trenutni pristup bilo kom linku projekta po komandi bota
• Bezbednost: interni linkovi i lozinke ne smeju da dospeju u grupe ispitanika

---

Šta smo uradili

5 novih komandi bota — jednostavne, bez obraćanja API-ju, vraćaju statički HTML.

Ograničenje po bezbednosti: komande rade samo u radnom četu. U grupama ispitanika bot ih tiho ignoriše — lozinke i interni linkovi neće procureti.

---

Zašto je to potrebno

Celom timu — dobiti bilo koji link projekta za 3 sekunde direktno u Telegram-u umesto pretrage po zakačenim porukama.

Za bezbednost — lozinke za monitoring i interni dokumenti su dostupni samo u radnom četu, ne u grupama ispitanika.

Ukupno u botu: 6 komandi za tim + 3 servisne.

Izvor istine — kako smo proverili da li se oslanjamo na pouzdane podatke

Problem

Petog dana terenske faze regruter je javio da se kvota jednog od ispitanika ne poklapa sa onim što imamo u sistemu.

Počeli smo da razjašnjavamo i otkrili sistemski problem: uzimali smo kvote iz jedne kolone, ali ta kolona je popunjavana pre glasovnog skrininga. Posle poziva podaci su se ažurirali na drugom listu, a kolona je ostajala stara.

Hipoteza: deo naših kvota je bio zasnovan na preliminarnim, a ne finalnim podacima.

---

Varijante koje smo razmatrali

1. Verovati našem algoritmu skoringa

Prednosti: algoritam je objektivan, radi po formulama iz anketnih podataka. Mane: algoritam analizira tekst ankete, a ne živi razgovor. Navigaciono ponašanje — nije binarna karakteristika: čovek može iskreno da odgovori različito u zavisnosti od formulacije.

Rešenje: odbijeno — algoritam je koristan za primarni skrining, ali ne može biti izvor istine.

2. Verovati koloni od regrutera

Prednosti: podaci u strukturiranom obliku, lako se parsiraju. Mane: popunjava se pre glasovnog skrininga. Rukovodilac regrutinga je direktno rekla: „tu kolonu sam popunjavala pre skrininga, ona je nepouzdana".

Rešenje: odbijeno.

3. List „Kvotiranje" kao jedini izvor istine (izabrali smo)

Prednosti: popunjava se posle finalnog glasovnog skrininga, odražava konačnu odluku regrutera. Strukturiran po kvotnim ćelijama — odmah se vidi ko je u kojoj grupi. Mane: potrebno je svaki put otvoriti Excel i ručno proveriti.

Rešenje: prihvaćeno. Formalizovali pravilo i ugradili u pajplajn.

---

Šta smo uradili

Audit svih 26 ispitanika. Proverili kvote svakog pokrenutog sa listom kvotiranja.

Kaskadno ažuriranje. Ispravili kvote na svim mestima gde se čuvaju.

Formalizovali pravilo. U konfiguraciju projekta i skill dodali odeljak „Izvor istine":

• Pri kreiranju profila novog ispitanika → pronaći ime na listu kvotiranja → uzeti kvotu odatle
• Ako ime nije pronađeno → obavestiti rukovodioca

---

Čemu to služi

Za verodostojnost podataka — kvota ispitanika određuje u koju analitičku grupu ulazi. Pogrešna kvota → pogrešna interpretacija njegovog ponašanja u dnevniku.

Za tim — sada svako ko radi sa kvotama ima jednoznačan odgovor: „gde pogledati ispravnu kvotu?" Ne treba pogađati koji od tri izvora je aktuelan.

Za buduće projekte — lekcija: u regrutingu podaci prolaze kroz nekoliko stadijuma (anketa → preliminarna analiza → glasovni skrining → finalna odluka). Na svakom stadijumu ocena se može promeniti. Potrebno je tačno znati na kom stadijumu se fiksira „istina".

---

Kako to funkcioniše

1. Regruter sprovodi glasovni skrining kandidata
2. Po završetku popunjava list „Kvotiranje" u fajlu rasporeda intervjua
3. Pri kreiranju profila ispitanika Claude Code čita list „Kvotiranje" putem openpyxl
4. Kvota sa lista → profil → kartica monitoringa → tabela trekinga
5. Periodična provera: profili ↔ list kvotiranja (ručna ili po zahtevu)

Mapa feature zahteva iz dnevnika — kako izvući produktne zahteve iz kvalitativnih podataka

Problem

Trećeg dana terenske faze (26 ispitanika, ~100+ zapisa o putovanjima) u podacima se nakupljaju implicitni zahtevi za funkcionalnost: ljudi opisuju neugodnosti, zaobilazna rešenja, prebacivanja između aplikacija — ali ti signali su razbacani po zapisima.

• Feature zahtevi se ne formulišu eksplicitno — ispitanik opisuje putovanje, a zahtev za feature se podrazumeva
• Zapisi 26 ispitanika u 26 različitih dnevnika — nemoguće je videti koji se zahtevi ponavljaju
• Nema razdvajanja: šta treba razviti, a šta već postoji, ali korisnik ne zna
• Kontekst se gubi
• Tim nema jedinstveno mesto za analitičke materijale (monitoring = po ispitanicima, a ne po temama)

---

Varijante koje smo razmatrali

1. Ručna analiza od strane istraživača

Prednosti: duboko razumevanje konteksta svakog ispitanika. Mane: sa 26 ispitanika i ~100 zapisa — dani rada. Teško je zadržati kros-ispitaničku sliku.

Rešenje: odbijeno. Previše radno intenzivno za međupresek na 3. dan terena.

2. GPT analiza na serveru (automatski)

Prednosti: bez učešća čoveka, po rasporedu. Mane: GPT-4.1-mini ne može da se nosi sa finom klasifikacijom (feature zahtev vs problem vs barijera). Ne vidi kontekst skrininga. Ne može da odvoji „neznanje o vrednosti" od stvarnog zahteva.

Rešenje: odbijeno. Kvalitet analize je kritičan — to ide naručiocu.

3. Claude Code + stranica analize na sajtu (izabrali smo)

Prednosti: maksimalan kvalitet analize (Claude Opus), vezanost za profile i skrining, fleksibilan format (markdown → HTML sa tabovima), skalabilnost (novi .md = novi tab). Mane: pokretanje ručno. Ali analiza — nije svakodnevni zadatak, već po zahtevu.

---

Šta smo uradili

Izvukli feature zahteve iz svih dnevnika. Paralelno analizirani dnevnici 26 ispitanika (5 agenata, ~370 fajlova). Za svaki zahtev: ko, šta želi, zašto, šta bez toga, citat.

Klasterizovali u 15 tema.

Napravili stranicu analize na sajtu. Pristup sa lozinkom, kartice-tabovi, adaptivni dizajn. Kolorni šema — teal (#0d9488). Automatska detekcija: novi .md u direktorijumu analize → novi tab.

Podesili workflow. Rukovodilac projekta traži analizu → Claude Code analizira → prikazuje rezultat → ako da → .md, commit, push, autodeploy.

---

Čemu to služi

Naručiocu — strukturirana mapa zahteva sa kontekstom i citatima. Vidi se šta je masovno, šta pojedinačno, šta već postoji, ali se ne nalazi.

Istraživačima — kros-ispitanički pogled po temama, kojeg nema u pojedinačnim karticama monitoringa.

Za finalne intervjue — lista feature-a za proveru „neznanja o vrednosti" (Blok 4 vodiča).

Rukovodiocu — mogućnost da brzo zatraži analizu po bilo kojoj temi i odmah dobije rezultat na sajtu.

---

Kako to funkcioniše

1. Rukovodilac projekta: „analiziraj feature zahteve / barijere / obrasce"
2. Claude Code čita dnevnike svih ispitanika (paralelno)
3. Klasterizacija + vezivanje za kontekst + citati
4. Rezultat u četu → rukovodilac projekta odlučuje
5. Ako da → .md u direktorijum analize → git push → Render autodeploy → novi tab na stranici analize

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Šestog dana terenske faze dnevničkog istraživanja 32 ispitanika vode dnevnike putovanja u 32 odvojene Telegram grupe. Dnevnik traje 7 kalendarskih dana, ali svaki ispitanik je startovao na svoj datum. Za 1–2 dana prvi počinju da završavaju — i treba planirati odabir za dubinske intervjue.

Šta je bilo nezgodno:

• Nejasno ko je na kom danu dnevnika: 32 ispitanika sa 5 različitih datuma starta, računati u glavi nemoguće
• Ne vidi se ko završava sutra — a za njih je potrebno hitno pripremiti intervju
• Nema opšte slike po broju putovanja — ko piše aktivno, a ko ćuti
• Troje ispitanika uopšte nije jasno da li su startovali ili ne
• Odluku o odabiru 24 od 32 za intervju treba doneti 1–2 dana pre završetka dnevnika, a instrumenta za to nema
• Ručna provera svakog — otvoriti Telegram grupu, prelisati zapise, izbrojati dane — traje ~30 minuta po ispitaniku, 32 × 30 min = 16 sati. Sa automatizacijom — ~20 minuta

Šta je potrebno:

• Jedan ekran sa statusom svih 32 ispitanika: dan dnevnika, broj putovanja, datum završetka
• Automatski proračun: ko završava za 1–2 dana (hitno) vs za 3–5 dana (može se sačekati)
• Detektor putovanja: koliko je stvarnih putovanja zabeleženo, po danima
• Sekcija odabira za intervju: ko je obavezan (jedini u kvotnom segmentu), koga se može birati
• Pokretanje jednom komandom, rezultat za 5 sekundi

---

Varijante koje smo razmatrali

1. Google Sheets sa ručnim ažuriranjem

Prednosti: poznat format, tim može da uređuje. Mane: potrebno je ručno računati dane i putovanja za svakog ispitanika. Sa 32 osobe to je 2+ sata rada, i to svakog dana iznova. Ljudski faktor — lako je pogrešiti u prebrojavanju.

Rešenje: odbijeno. Ne skalira se sa 32 ispitanika i svakodnevnim ažuriranjem.

2. Python skripta sa automatskim skeniranjem dnevnika (izabrali smo)

Prednosti:

• Skenira lokalni folder sa dnevnicima za 2–3 sekunde
• Automatski određuje dan dnevnika, broji putovanja, izračunava rokove
• Sekcija odabira za intervju sa kvotnom logikom — ne treba pamtiti ko je u kom segmentu
• Jedna komanda u terminalu

Mane: zavisi od sinhronizacije dnevnika sa Google Drive-a (potrebno je sinkronizovati pre pokretanja). Detektor putovanja je približan (~80% tačnosti) — broji na osnovu obrazaca teksta, ne na osnovu ručnog označavanja.

---

Šta smo uradili

1. Detektor putovanja (tri metoda)

Ključni zadatak — automatski odrediti koliko je putovanja ispitanik opisao u svakoj dnevničkoj poruci. Problem: ispitanici pišu u slobodnoj formi — neko numeriše, neko opisuje tekstom, neko šalje glasovne poruke.

Realizovali tri metoda detekcije, koji se primenjuju sekvencijalno.

Tačnost: ~80%. Za zadatak „opšta slika progresa" to je dovoljno.

Ključni uvid od rukovodioca projekta: „Zahvaljujući tome što su istraživači aktivno postavljali dodatna pitanja, čak i na jednom putovanju uspeli smo da dobijemo veoma mnogo važnog konteksta. To je korisno za ciljeve istraživanja i ciljeve biznisa."

2. Sekcija odabira za intervju

Od 32 ispitanika potrebno je odabrati 24 za finalni dubinski intervju. Skripta automatski raspoređuje po kvotnoj mreži i određuje tri nivoa: koga ne sme da se odseje (jedini u segmentu), koga je bolje zadržati, i gde se može birati. Rukovodilac donosi odluku, videći celokupnu sliku.

4. Format ispisa

Kompaktna ASCII tabela u terminalu: svih 32 ispitanika na jednom ekranu, grupisani po tipu (pešaci / vozači). Kolone: kod ispitanika, grad, dan N/7, broj putovanja, datum završetka, preostalo dana, putovanja po danima.

Kritično važna UX odluka: !! pored „preostalo dana" za one koji završavaju za ≤2 dana. To je vizuelni marker hitnosti.

---

Čemu to služi

1. Rukovodiocu projekta — videti progres svih 32 ispitanika za 5 sekundi umesto 16 sati ručne provere. Donositi odluke o odabiru za intervju, oslanjajući se na podatke.
2. Istraživačima — razumeti ko završava za 1–2 dana i za koga je hitno pripremiti pitanja za intervju.
3. Administratorima grupa — videti ko ćuti (0 putovanja za dan) i koga treba podstaknuti.
4. Procesu odabira — kvotna mreža automatski pokazuje koga ne sme da se odseje. Bez toga se lako slučajno ukloni jedini predstavnik segmenta.

---

Kako to funkcioniše

1. Sinhronizacija dnevnika sa Google Drive-a → lokalni folder
        ↓
2. Skripta skenira sve podfoldere ispitanika
        ↓
3. Detektor putovanja: šablon numerisanja → markeri → keywords
        ↓
4. Određivanje Dana 1: prvi dan sa ≥1 putovanjem
        ↓
5. Proračun: dan dnevnika, datum završetka, putovanja po danima
        ↓
6. Kvotna mreža: raspoređivanje 32 ispitanika po segmentima
        ↓
7. Ispis: ASCII tabela + sekcija odabira za intervju

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Dnevničko istraživanje navigacije: 32 ispitanika vode dnevnike 7 dana, od kojih 24 biramo za finalne 70-minutne intervjue. Format intervjua — detaljna razrada konkretnih putovanja iz dnevnika. To znači da ne treba birati „dobre ispitanike", već one čiji dnevnici daju maksimum materijala za produktivan razgovor.

Šta je bilo nezgodno:

• Kriterijumi odabira — u glavi rukovodioca, nema formalizovanog sistema
• 32 ispitanika x 5-7 dana x 2-6 putovanja/dan = stotine zapisa. Nemoguće ih zadržati u pamćenju pri poređenju
• Kvotna ograničenja (tip x geo x učestalost navigacije) čine odabir nelinearnim — ne može se jednostavno uzeti top-24 po „kvalitetu"
• Ispitanici počinju dnevnike u različite datume. Oni koji su počeli kasnije imaju manje podataka — nepravedna prednost ranih
• Naručiocu je potrebno transparentno obrazloženje: zašto baš ovih 24, a ne drugih

Šta je potrebno:

• Formalizovan sistem ocenjivanja: šta tačno ocenjujemo i po kojoj skali
• Vezanost svake odluke za zadatke istraživanja, a ne za apstraktan „kvalitet"
• Kvotna logika: proporcionalan odabir sa očuvanjem balansa po gradovima i učestalosti navigacije
• Pravičnost za ispitanike sa kasnim startom
• Obrazloženje za klijenta po svakom uključivanju i isključivanju

---

Varijante koje smo razmatrali

1. Ekspertski odabir bez formalizacije

Prednosti: brzo, rukovodilac ionako poznaje materijal. Mane: netransparentno za naručioca.

Rešenje: odbijeno. Naručilac očekuje argumentovano obrazloženje.

2. Jednostavan rejting po broju putovanja

Prednosti: objektivna metrika, lako se izračuna. Mane: količina != kvalitet. 20 zapisa „sve u redu, stigla sam" beskorisnije je od 5 zapisa sa refleksijom i screenshot-ovima. Ne uzima u obzir kvote — može se izgubiti ceo segment. Kažnjava korisnike sa retkom upotrebom, koji su vredni upravo zbog svog neuključivanja navigacije.

Rešenje: odbijeno. Protivreči principu „vrednost za intervju > formalna aktivnost".

3. 100-bodovni sistem sa kvotnom logikom i talasnim skoringom (izabrali smo)

Prednosti:

• 5 dimenzija pokrivaju sve aspekte vrednosti za intervju
• Kvotna logika garantuje očuvanje uzorka
• Kalibracioni sidra obezbeđuju stabilnost ocena između sesija
• Talasni skoring (dan 5+) eliminiše nepravdu za „kasne"
• Rezultat — gotovo obrazloženje za klijenta

Mane: radno intenzivno — pun skoring jednog ispitanika traje 5-10 minuta. Potrebna je ažurirana kartica monitoringa kao ulazni podaci.

---

Šta smo uradili

1. Napravili skill sa 5 dimenzija ocenjivanja

100-bodovni sistem, svaka dimenzija ocenjuje konkretan aspekt vrednosti za intervju:

Dimenzija	Maks	Šta ocenjuje
Aktivnost	25	Koliko dana i putovanja, stabilnost vođenja
Raznovrsnost putovanja	20	Vrste prevoza, ciljevi, konteksti, poznatost ruta
Kvalitet komentara	20	Refleksija, „zašto", emocije, screenshot-ovi, glasovne poruke
Istraživačka vrednost	25	Uvidi, barijere, odstupanja, feature zahtevi
Potencijal intervjua	10	Materijal za 70-minutnu razradu: protivrečnosti, hipoteze

Ključna odluka: istraživačka vrednost ima istu težinu kao aktivnost (25 bodova). Tri duboka zapisa sa uvidima vredniji su od dvadeset formalnih.

2. Ugradili kalibraciona sidra

Dva ispitanika su skorirana prva — kao sidra skale: gornje (visoka aktivnost, mnogo uvida) i donje (minimum podataka). Svaki naredni skoring se kalibriše u odnosu na ta dva.

3. Uveli talasnu logiku „dan 5+"

Pravilo: skorirati ispitanika tek kada je na 5. danu dnevnika ili dalje. 5 dana — dovoljno za pouzdanu ocenu, ostaju 2 dana rezerve za planiranje intervjua.

4. Napravili post sa metodologijom za tim

Opisali 5 dimenzija, skalu, logiku donošenja odluka — jednostavnim jezikom, bez interne kuhinje. Poslali u radni čet tima, da svi razumeju kako funkcioniše odabir.

---

Čemu to služi

1. Rukovodiocu istraživanja — formalizovan sistem umesto „ja tako osećam". Može se delegirati skoring, rezultat će biti isti.
2. Naručiocu — transparentno obrazloženje: svako uključivanje i isključivanje vezano za zadatke istraživanja.
3. Timu projekta — razumljivi kriterijumi: šta znači „dobar dnevnik" i zašto ispitanik sa 1 putovanjem može biti vredniji od onog sa 20.
4. Ispitanicima (indirektno) — pravičnost: kasni start ne znači automatski gubitak. Talasni skoring izjednačava šanse.
5. Agenciji — višekratno upotrebljiv skill. Na sledećem dnevničkom projektu nije potrebno iznova smišljati sistem odabira.

---

Kako to funkcioniše

1. Kartica monitoringa ažurirana (sveži podaci dnevnika)
        |
2. Proveravamo dan dnevnika: >=5? Ako ne — čekamo
        |
3. Pokrećemo skoring: „oceni ispitanika za intervju"
        |
4. Claude Code čita karticu + dnevnik + kvotnu mrežu
        |
5. Ocenjuje po 5 dimenzija, proverava red flags
        |
6. Određuje kvotnu poziciju (obavezan / kompetitivan)
        |
7. Izdaje karticu skoringa sa bodom i odlukom
        |
8. Rezultat se čuva u fajl rezultata
        |
9. Kada je cela ćelija skorirana — finalno odsejavanje po bodu

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Šestog dana terenske faze dnevničkog istraživanja (32 ispitanika, 32 Telegram grupe) bot je prestao da čuva zapise na Google Drive. Ispitanici su nastavili da pišu, ali fajlovi se nisu pojavljivali.

Šta se desilo:

• Pokrenuli sinhronizaciju dnevnika — preuzet je 1 fajl umesto očekivanih desetina
• Provera Google Drive-a pokazala: za ceo dan samo 5 fajlova (svi pre 04:00 ujutru)
• Telegram webhook je vraćao 500 Internal Server Error
• 224 poruke od ispitanika zaglavile su se u redu čekanja Telegram-a
• Logovi servera: RefreshError: invalid_grant: Token has been expired or revoked

Zašto je to kritično:

• Telegram čuva red poruka ~24 sata, zatim briše — podaci su bili pod pretnjom gubitka
• 32 ispitanika su nastavili da pišu ceo dan, ne sluteći o problemu
• Terenska faza traje 7 dana — gubitak čak jednog dana = nenadoknadiva šteta

Koreni uzrok: OAuth consent screen u Google Cloud Console bio je u režimu "Testing". U tom režimu Google automatski opoziva refresh token posle 7 dana. Projekat je pokrenut pre nedelju dana, token je istekao tačno posle 7 dana.

---

Varijante koje smo razmatrali

1. Prebaciti bota na servisni nalog umesto OAuth

Prednosti: servisni nalozi ne zahtevaju refresh token, ne ističu. Mane: servisni nalozi nemaju kvotu za skladištenje na Google Drive-u i ne mogu da učitavaju fajlove na lični disk korisnika. Dobijamo grešku storageQuotaExceeded. Radi samo sa Shared Drives (Team Drives).

Rešenje: odbijeno posle pokušaja — dobili 403 od Google Drive API-ja.

2. Regenerisati OAuth refresh token + publikovati consent screen (izabrali smo)

Prednosti:

• Rešava i trenutni problem (novi token) i koreni uzrok (publikacija = token je besročan)
• Ne zahteva promenu arhitekture skladištenja
• Može se uraditi za 10 minuta

Mane: potreban je pristup Google Cloud Console-u i hosting panelu.

3. Premestiti skladište na Shared Drive

Prednosti: može se koristiti servisni nalog, tokeni ne ističu. Mane: treba migrirati ~2000 fajlova, menjati sve skripte (rclone, sinhronizacija, bot), rizik gubitka podataka pri migraciji.

Rešenje: odloženo. Nesrazmeran obim posla za hitnu situaciju.

---

Šta smo uradili

1. Dijagnostika (5 minuta)

Lanac provera:

• Sinhronizacija dnevnika → samo 1 novi fajl → sumnja
• Provera Google Drive-a → za ceo dan samo 5 fajlova (svi pre 04:00) → problem na strani bota
• getWebhookInfo → 500 Internal Server Error, 224 pending updates → bot pada
• Logovi servera → RefreshError: invalid_grant → OAuth token expired

2. Kod-fiks: fallback na servisni nalog (2 minuta)

Obavili OAuth autorizaciju u try/except. Pri padu OAuth-a — bot loguje upozorenje i pokušava sa servisnim nalogom. Ovo je osiguranje za budućnost: ako OAuth ponovo padne, bot neće padati sa 500, već će pokušati alternativni put.

try:
    if not creds.valid:
        creds.refresh(Request())
except Exception:
    logging.warning("OAuth refresh failed, falling back to service account")
    return None

3. Otkrili ograničenje servisnog naloga (3 minuta)

Posle deploy-a koda sa fallback-om — dobili novu grešku: storageQuotaExceeded. Servisni nalozi ne mogu da kreiraju fajlove na ličnom Google Drive-u. Varijanta 1 ne radi — potreban je OAuth.

4. Regeneracija OAuth tokena (5 minuta)

Napisali skript za regeneraciju tokena:

• Podiže lokalni HTTP server na portu 8090
• Otvara pregledač za Google autorizaciju
• Presreće autorizacioni kod putem redirect-a
• Razmenjuje kod za novi refresh token

Ažurirali promenljivu okruženja na hostingu → Manual Deploy.

5. Publikacija consent screen-a (1 minut)

U Google Cloud Console → OAuth consent screen → Audience → pritisnuli "Publish App". Status se promenio sa "Testing" na "In production". Sada je refresh token besročan.

6. Rezultat

Metrika	Vrednost
Vreme od otkrivanja do popravke	~20 minuta
Poruka u redu čekanja	224
Poruka izgubljeno	0
Brzina obrade reda	~30 poruka/minuti
Red obrađen za	~7 minuta

---

Zašto je to potrebno

1. Rukovodiocu projekta — razumevanje tipičnog scenarija otkazivanja bota i algoritam brze dijagnostike.
2. Inženjeru — kod-fiks sa fallback-om ostaje kao osiguranje; skript za regeneraciju tokena spreman za ponovnu upotrebu.
3. Budućim projektima — čeklista pri podešavanju Google OAuth-a: uvek publikovati consent screen pre pokretanja terenske faze.
4. Timu — podaci za ceo dan su obnovljeni bez gubitaka, ispitanici ništa nisu primetili.

---

Kako to funkcioniše

1. Otkrivanje: sinhronizacija je pokazala 0 novih fajlova
        |
2. Provera Drive-a: fajlova nema → problem na strani bota
        |
3. Provera webhook-a: getWebhookInfo → 500, N pending
        |
4. Logovi servera: identifikacija greške
        |
5. Popravka: regeneracija tokena + deploy
        |
6. Telegram ponovo šalje red → fajlovi na Drive-u

Čeklista „OAuth za Google Drive"

1. Pri podešavanju projekta: Google Cloud Console → OAuth consent screen → publikovati (Publish App). Ne ostavljati u Testing.
2. Promenljive okruženja: GOOGLE_OAUTH_CLIENT_ID, GOOGLE_OAUTH_CLIENT_SECRET, GOOGLE_OAUTH_REFRESH_TOKEN — sve tri su potrebne na serveru.
3. Ako je token istekao: pokrenuti skript za regeneraciju tokena → kopirati novi token → ažurirati na hostingu → Manual Deploy.
4. Monitoring: getWebhookInfo — ako je pending_update_count > 0 i last_error_message sadrži 500 — bot je pao.

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Rok: odobrenje gajda za finalne intervjue sa naručiocem. Prvi intervjui — sutradan. Na raspolaganju — nacrt gajda od 70 minuta, 7 blokova, napisan na početku projekta. Ali tokom nedelje terenske faze mnogo toga se promenilo:

• Nakupili su se podaci iz 30 dnevnika (200+ putovanja) koji menjaju sliku
• Naručilac nije dostavio listu feature-a proizvoda i nejasno je da li će se pojaviti
• U brifu — bukvalno par hipoteza, a dnevnici generišu desetine
• Nacrt je sadržao nezatvorene TODO: „ubaciti listu feature-a", „dodati hipoteze"
• Nema mehanizma za prioritizaciju pravaca razvoja (Zadatak 4 projekta) — a to je ključni očekivani rezultat

Šta je potrebno: tokom vikenda pretvoriti nacrt u radni instrument koji garantuje dobijanje podataka po SVIM istraživačkim zadacima, i proveriti ga na realnom materijalu.

---

Varijante koje smo razmatrali

1. Kozmetička ispravka nacrta

Prednosti: brzo, struktura već postoji. Mane: kritični propusti ostaju. Bez feature-a od naručioca blok 4 (vrednost navigacije) ne funkcioniše. Bez prioritizacije Zadatak 4 nije zatvoren. Pitanja nisu vezana za podatke dnevnika. Rešenje: odbijeno.

2. Potpuno prepisati gajd

Prednosti: može se uzeti u obzir sve što znamo iz dnevnika. Mane: rizik „istraživačkog perfekcionizma" — beskonačno dorađivanje. Struktura nacrta je funkcionalna — nema smisla je rušiti. Nema vremena. Rešenje: odbijeno.

3. Sistemski review + ciljana dorada + provera na podacima (izabrali smo)

Prednosti:

• Review po 8 blokova otkriva upravo one propuste koji su kritični
• Ciljane ispravke čuvaju funkcionalnu strukturu
• Podaci dnevnika se ugrađuju u gajd kao hipoteze i obrasci
• Provera na realnom dnevniku testira da li gajd funkcioniše pre prvog intervjua
• Uklapa se u vikend

Mane: radno intenzivno — potrebno je izvući podatke iz 30 tabova, sprovesti review, doraditi, testirati. Ali rezultat — provereni instrument.

---

Šta smo uradili

Korak 1: Sistemski review po 8 blokova

Koristili smo skill za review — ocenjivanje po 8 blokova (uvodni govor, skrining, veza sa zadacima, formulacije, struktura, instrumenti, hronometraž, pilot). Sastavili matricu pokrivenosti: istraživački zadaci x pitanja gajda.

Ukupna ocena: „Potrebna dorada".

Kritični propusti:

• Blok 4 (vrednost navigacije) izgrađen „odozgo nadole": pokazati ispitaniku listu feature-a → pitati „da li znate?". Bez liste feature-a od naručioca blok ne funkcioniše
• Nema mehanizma prioritizacije
• Nema razdvajanja vozači/pešaci u pitanjima
• Nema prioriteta unutar blokova (šta je obavezno, šta ako ima vremena)
• Hipoteze nisu formulisane — TODO u tekstu

Jake strane (zadržali smo):

• Vezanost za konkretna putovanja iz dnevnika
• 7-blokovna struktura sa logičnim levkom
• Tipska pitanja po obrascima

Korak 2: Rešenje problema „nema liste feature-a"

Ovo je bio ključni izazov. Naručilac nije dostavio listu feature-a i nepoznato je da li će se pojaviti. Prva verzija bloka 4 — mrtva bez te liste.

Rešenje — obrnuti logiku: umesto „odozgo nadole" (feature-i → ispitanik) idemo „odozdo nagore" (ispitanik → njegov mentalni model):

1. Otvorena pitanja o vrednosti navigacije
2. Vezanost za konkretna putovanja iz dnevnika
3. Diskusija o rezultatima vežbe iz poslednjeg dana dnevnika
4. Segmentna produbljivanja (IF TIME)

Tako dobijamo mentalni model ispitanika bez podsticaja — a zatim ga upoređujemo sa realnim mogućnostima proizvoda pri analizi.

Korak 3: Premeštanje prioritizacije u poslednji dan dnevnika

Prioritizacija pravaca — važna je, ali troši 15-20 minuta intervjua. Pri limitu od 70 minuta to je kritično.

Rešenje: vežba prioritizacije se radi poslednjeg dana dnevnika, NE na intervjuu:

• Ispitanik dobija kartice sa barijerama i vrednostima
• Bira top-3 u svakoj kategoriji, rangira
• Na intervjuu — samo kratka diskusija o rezultatima (5 min umesto 20)

Kartice smo formirali iz realnih podataka dnevnika, odvojeno za vozače i pešake. Formulacije na jeziku ispitanika, ne istraživačkom.

Korak 4: Ekstrakcija podataka iz 30 dnevnika

Za formulisanje hipoteza i kartica bila je potrebna konsolidacija podataka svih 30 ispitanika. Napisali smo skript koji izvlači analitički sloj iz tabele trekinga u Google Sheets — obrasce, barijere, pokretače, feature zahteve, pitanja za intervju.

Rezultat: strukturirani JSON sa podacima po 8 sekcija x 30 ispitanika. Iz tih podataka:

• Formulisali 6 hipoteza za blok 5
• Identifikovali 2 nova obrasca za blok 3
• Sastavili kartice barijera i vrednosti za vežbu

Korak 5: Dorada gajda (v2.0)

Ciljane ispravke po rezultatima review-a:

Blok	Šta smo promenili
Blok 1 (zagrevanje)	Dodat zahtev za snimanje, provera vremena
Blok 3	Markeri MUST/IF TIME, uklonjene navodeće formulacije, dodato 2 obrasca iz podataka
Blok 4 (vrednost)	Potpuna prerada: odozdo nagore, 4 koraka, veza sa vežbom
Blok 5 (hipoteze)	6 hipoteza iz dnevnika umesto praznog TODO. Tri MUST, tri IF TIME
Blok 7 (zatvaranje)	Dodato ključno pitanje
Tajming	Prioriteti po svakom bloku: šta je obavezno, šta se može preskočiti

Korak 6: Virtuelni intervju — provera na realnim podacima

Najneobičnije rešenje sesije. Umesto da čekamo prvi intervju za proveru gajda, sproveli smo „virtuelni intervju" — prošli kroz gajd koristeći podatke jednog realnog dnevnika.

Za svaki blok: koje pitanje postavljamo → šta možemo predvideti iz dnevnika → čega nema i šta će dati samo živi intervju.

Šta je pokazala provera:

• Gajd funkcioniše — generiše podatke po svim blokovima
• Blok 3: sva 4 ključna putovanja daju bogat materijal za razradu
• Blok 4 (obrnuti): otvorena pitanja su primenljiva, veze sa putovanjima postoje
• Blok 5: 5 od 6 hipoteza je relevantno za ovog ispitanika
• Blok 7: Q4 „podrazumevano" — ključno pitanje, odgovora u dnevniku nema = upravo to će dati intervju

Šta gajd ne pokriva: provera je otkrila jedinstvene obrasce ponašanja koje gajd ne pokriva — oni su specifični za konkretnog ispitanika i idu u individualnu pripremu istraživača pred intervju.

Glavni zaključak: dnevnik daje „šta", intervju će dati „zašto" i „šta ako". Gajd funkcioniše upravo na tom prelazu.

Korak 7: Publikacija i timska komunikacija

• Učitali gajd v2.0 i virtuelni intervju na Google Drive
• Napravili stranicu na sajtu projekta za pogodno čitanje
• Poslali 2 posta u čet tima:
  1. Gajd + virtuelni intervju + linkovi + molba za komentare od istraživača
  2. Vežba prioritizacije: kartice barijera i vrednosti + molba za povratnu informaciju

---

Zašto je to potrebno

1. Istraživačima — radni instrument sa prioritetima (MUST/IF TIME), vezom za podatke dnevnika, gotovim hipotezama. Ne treba improvizovati
2. Rukovodiocu — sigurnost da gajd pokriva SVE istraživačke zadatke. Matrica pokrivenosti — dokaz
3. Naručiocu — gajd je zasnovan na podacima (30 dnevnika, 200+ putovanja), a ne na pretpostavkama. Hipoteze — iz realnog ponašanja korisnika
4. Projektu — prioritizacija je rešena bez gubitka vremena intervjua. Podaci se prikupljaju u dnevniku, razmatraju na intervjuu
5. Metodologiji — virtuelni intervju kao metod testiranja gajda. Može se raditi za svakog ispitanika pred živi intervju

Stranica analize: feature zahtevi + hipoteze za intervju

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Do 7. dana projekta nakupio se veliki obim analitičkih podataka iz dnevnika 32 ispitanika (~400+ putovanja). Dva ključna artefakta — mapa feature zahteva i hipoteze za finalne intervjue — postojali su, ali na različitim mestima:

• Feature zahtevi su bili na sajtu, ali zastareli — napisani na osnovu podataka prvih dana, 26 ispitanika. U preostalim danima pojavili su se novi klasteri, a postojeći su se značajno dopunili.
• Hipoteze su bile ugrađene unutar gajda za intervju — dostupne samo onima koji su čitali gajd u celini. Zasebnog dokumenta sa dokaznom bazom nije bilo.
• Tim (istraživači) se pripremao za pilotne intervjue i bio im je potreban brz pristup obema artefaktima.

Šta je potrebno: jedinstvena tačka pristupa feature zahtevima i hipotezama, aktuelna po svih 32 ispitanika, sa dokaznom bazom.

---

Varijante koje smo razmatrali

1. Ažurirati feature zahteve u trenutnom fajlu, hipoteze ostaviti u gajdu

Prednosti: brzo, minimum promena. Mane: tim neće videti hipoteze bez čitanja 10-straničnog gajda. Pred intervju je potreban brz pristup. Rešenje: odbijeno.

2. Napraviti dva zasebna dokumenta na sajtu (izabrali smo)

Prednosti:

• Stranica na sajtu već podržava auto-tabove iz .md fajlova — dovoljno je staviti drugi fajl
• Dva taba: feature zahtevi i hipoteze — logički su povezani, ali se čitaju nezavisno
• Istraživači dobijaju jedinstveni link za pripremu za intervju

Mane: radno intenzivno — potrebno je pregledati podatke svih 32 ispitanika i 87 radnih sesija.

---

Šta smo uradili

Korak 1. Ažurirali mapu feature zahteva.

Ulazni podaci: dnevnici 32 ispitanika za 7 dana, kartice monitoringa, analitički sloj tabele trekinga, kros-ispitanički obrasci.

Rezultat:

• Bilo: 15 klastera, 26 ispitanika, prvi dani, ~200+ putovanja
• Postalo: 20 klastera, 32 ispitanika, svih 7 dana, ~400+ putovanja

Korak 2. Napravili fajl hipoteza.

Izvori: gajd za intervju v2.0, tabela trekinga, kartice monitoringa, kvantitativni sloj.

10 hipoteza sa dokaznom bazom iz kompletne dnevničke faze. Svaka hipoteza: suština, dokazna tabela, objašnjenje „zašto je važno", formulacija pitanja za intervju.

Korak 3. Deploy i obaveštenje.

• Commit + push → auto-deploy na Render
• Post u timski čet: šta je ažurirano, gde pogledati, kod pristupa

---

Rezultat

Stranica analize na sajtu projekta — dva taba:

1. Mapa feature zahteva — 20 klastera sa citatima, svodnom matricom i zaključcima
2. Hipoteze iz dnevničkih podataka — 10 hipoteza sa dokaznom bazom i pitanjima za intervju

Jedinstven link za tim ka stranici analize na sajtu projekta.

---

Šta je to dalo

• Istraživačima: priprema za pilotne intervjue — brz pristup feature zahtevima i hipotezama sa vezom za konkretne ispitanike
• Rukovodiocu: aktuelna slika potreba korisnika po svih 32 ispitanika
• Projektu: metodološka veza „dnevnik → tabela trekinga → feature zahtevi → hipoteze → intervju" zatvorila se u jedinstven pajplajn

Autor: rukovodilac projekta + Claude Code (Opus 4.6)

---

Problem

Dnevnici se završavaju — počinju intervjui. Istraživači treba da se pripreme: urone u podatke svakog ispitanika, razumeju njegovo ponašanje, znaju šta da pojasne na intervjuu.

Na ulazu — 7 dana dnevničkih zapisa: desetine tekstualnih poruka, glasovnih, fotografija, snimaka ekrana, dijaloga sa istraživačem. Nijedan istraživač ne može sve to pročitati za jedno veče pred intervju.

Kartica monitoringa (koja već postoji na sajtu) je dobar alat za svakodnevno praćenje, ali to je strukturisani rezime: obrasci, barijere, pokretači, hronologija. Za pripremu intervjua potrebno je nešto drugo — razumevanje osobe: kako razmišlja, zašto se tako ponaša, šta stoji iza brojeva. Konkretni citati, konkretne situacije, konkretna pitanja.

Posle intervjua — potrebno je nešto za klijenta. Ne samo „ispitanik koristi navigaciju u 33% putovanja", već odgovor na pitanje: kako se ponašanje ove osobe odnosi prema poslovnim ciljevima? Šta funkcioniše, šta ne, i zašto.

Šta je potrebno: sistem za kreiranje analitičkih članaka o ispitanicima koji funkcioniše u svim fazama istraživanja i može se ponovo koristiti između projekata.

---

Razmatrane opcije

1. Proširiti karticu monitoringa

Dodati narativni blok, citate i pitanja za intervju u postojeći format. Prednosti: jedan fajl, jedno mesto. Mane: kartica bi postala ogromna, dva formata bi se pomešala, kartica se ažurira svakodnevno — narativ bi smetao. Odluka: odbijeno.

2. Napraviti zasebne analitičke članke po ispitaniku (izabrano)

Tri zasebna fajla u ličnom folderu ispitanika: narativna analitika, dijalozi, zone za intervju. Posle intervjua — obogaćivanje transkriptom + poslovni članak. Prednosti: svaki artefakt je zaseban fajl sa jasnom namenom, ne zagađuje monitoring, skalira se. Mane: više fajlova. Odluka: izabrano.

3. Pripremati se za svaki intervju ručno

Istraživač sam čita dnevnik, izvlači citate, formuliše pitanja. Prednosti: duboko uranjanje. Mane: 24 ispitanika × sati čitanja = nerealno u kratkim rokovima. Svaki put iz početka. Odluka: odbijeno.

---

Šta smo uradili

1. Definisali žanr — „Narativna analitika"

Ne hronologija dan po dan (ispitanici nisu radili ništa neobično — živeli su običnim životom). Ne suvi rezime (to već postoji u monitoringu). Već analitika kroz priču: kostur — mehanizmi, uzroci, struktura ponašanja; ton — konkretne situacije, citati, kontekst.

Fokus:

• Kako se osoba kreće uopšte (A→B obrasci)
• Ponavljajuće radnje i šta se menja
• Jednokratne / jedinstvene radnje

Dužina — tačno onoliko koliko je potrebno da se otkrije ponašanje i njegovi uzroci. Ne 3 pasusa i ne 30 — koliko treba.

2. Kreirali strukturu foldera

32 lična foldera — po jedan za svakog ispitanika. U svakom:

• Narativna analitika
• Dijalozi istraživač↔ispitanik
• Zone za kopanje na intervjuu

3. Napisali pilot članak

Izvori: 177 fajlova dnevnika (7 dana), kartica monitoringa, analitički sloj iz tabele praćenja.

Rezultat — tri fajla:

• Narativna analitika — portret ispitanika
• Dijalozi — sve značajne razmene istraživač↔ispitanik, organizovane po danima i temama. Citati u originalu.
• Zone za intervju — 8 konkretnih pravaca

4. Projektovali pipeline za ceo životni ciklus

Definisali tri faze primenljive na bilo koji istraživački projekat:

Faza	Kada	Šta se kreira	Ulazni podaci
Narativ	Pre ili posle intervjua	Narativna analitika	Dnevnik i/ili transkript
Priprema	Pre intervjua	Dijalozi + zone za kopanje	Bilo koji pre-data
Posao	Posle narativa	Poslovni članak	Narativ + poslovni ciljevi

Ključna odluka: veština se prilagođava dostupnim podacima, a ne metodu istraživanja. Jedna komanda pokriva:

• Dnevnički metod (narativ iz dnevnika → obogaćivanje transkriptom)
• Dubinski intervju bez pre-data (narativ iz transkripta)
• Bilo koji hibrid (šta ima — od toga i pišemo)

Istraživač ne bira „režim dnevnika" ili „režim intervjua". Kaže: „napiši narativ" — i veština sama određuje koji podaci su dostupni.

---

Šta ovo menja

Za istraživače:

• Priprema za intervju: umesto čitanja 177 fajlova — jedan narativni dokument + gotove zone za kopanje
• Posle intervjua: narativ se obogaćuje, ne piše iznova
• Za izveštaj: poslovni članak mapira ponašanje ispitanika na poslovne ciljeve

Za projekat:

• 24 ispitanika idu na intervju. Za svakog se može pripremiti isti paket
• Folderi već kreirani. Transkripti će ići tamo
• Poslovni članci za svih 24 ispitanika → sklapaju se u zajednički vision za izveštaj

Za buduće projekte:

• Pipeline nije vezan za dnevnički metod. Radi za bilo koje kvalitativno istraživanje sa intervjuima
• Žanr „narativna analitika" je ponovo upotrebljiv: analitika kroz priču, a ne suvi rezimei
• Veština (u razvoju) će biti u zajedničkim veštinama tima — priključuje se na bilo koji projekat