Hetiszámok használata projektmenedzsmentben — sprintek, roadmapek és a rejtett koordinációs csapdák

A hetiszámok a projekttervezés alapjai. A „Cél release: W22” tisztább, mint a „május 27-ei hét”, és pontosabb, mint a „május vége”. A roadmapek, sprintnaptárak és szállítási ütemtervek is rendezettebbnek tűnnek, ha hetiszámokkal fejezzük ki őket.

Csakhogy a hetiszámok rejtett feltételezéseket hordoznak — arról, hogy mikor kezdődik a hét, melyik hét számít 1-es hétnek, és melyik számozási rendszert használják az eszközeid. Egy országon belüli csapatban, egyetlen tool-lal ezek a feltételezések általában egyeznek, és fel sem tűnnek. Elosztott csapatban viszont megjelennek: elcsúszó átadások, félreértett határidők, és olyan delivery ablakok, amik nem fedik át egymást úgy, ahogy bárki gondolta.

Miért használnak a csapatok hetiszámokat a tervezéshez?

A naptári dátumoknak van egy projektmenedzsmentbeli problémájuk: túl konkrétak. Egy pontos dátumokra épített roadmap olyan precizitást sugall, ami fél év távlatában ritkán valós. A „Feature X március 14-ig” azonnal hibás lesz, amint csúszik a timeline, és minden dátum frissítése súrlódást okoz.

A hetiszámok egyensúlyt teremtenek a homályos negyedévek és a törékeny, pontos dátumok között:

• Elég részletesek sprintekhez és mérföldkövekhez
• Elég absztraktak ahhoz, hogy csússzanak anélkül, hogy az egész dokumentumot át kellene írni
• Könnyű róluk relatív módon gondolkodni („3 hét múlva” = aktuális hét + 3)
• Egységesek egy éven belül — minden hét ugyanakkora, ellentétben a hónapokkal

Kéthetes sprinteknél különösen természetes a struktúra. Sprint 1 = W1–W2, sprint 2 = W3–W4, stb. A sprint száma és a hetiszám gyakran egész évben „együtt mozog”.

A kétféle hetiszám-probléma

A csapda: az USA és Európa alapértelmezésben eltérő hetiszámozást használ.

ISO 8601 (Európa, a világ nagy része): A hét hétfőn kezdődik. Az 1. hét az, amelyik az év első csütörtökét tartalmazza. Alapértelmezett sok európai projekt-eszközben, és minden „ISO” jelölésű rendszerben.

US rendszer: A hét vasárnap kezdődik (néha hétfőn). Az 1. hét az, amelyik január 1-jét tartalmazza. Sok USA-központú eszközben ez az alapértelmezés.

Az év nagy részében a számok megegyeznek, vagy legfeljebb 1 héttel térnek el. Az évhatárok körül viszont látványosan szétcsúsznak — és a mismatchet nem könnyű észrevenni, ha nem tudod, hogy erre figyelni kell.

Példa — 2026. december vége:

Egy berlini fejlesztő január 1-jét 2026 W53-ként látja. Egy New York-i PM ugyanazt W1 2027-ként. A „zárjuk le W1-ben” mást jelent mindkettőjüknek.

Jira, Linear, Asana, Monday.com — mit használnak valójában?

Eszközönként és konfigurációnként eltér, és a legtöbb tool nem teszi ezt túl láthatóvá.

Jira: A sprintek dátumai naptári dátumok, nem hetiszámok. Ha hetiszámok megjelennek riportokban vagy board nézetekben, általában a Jira instance lokál beállítását követik — európai instance-oknál tipikusan ISO, amerikaiaknál US-stílus. A beállítás admin oldalon el van rejtve.

Linear: Roadmap nézetben hetiszámokat mutat. Alapból ISO 8601-et használ. Hétfői kezdés, csütörtök-szabály.

Asana: A Timeline nézet hetente címkéz. A workspace locale beállítását követi. Új workspacenél gyakran vasárnapi kezdés (US-stílus) az alap.

Monday.com: A week number oszlop hétfői kezdést követ, de US-stílusú 1. hetet használ (az első hét, amelyik január 1-jét tartalmazza, nem az első csütörtök). Emiatt évente 3–4 hét környékén eltér az ISO-tól.

Notion: A database dátummezők nem jelenítik meg natívan a hetiszámot. Az interneten terjedő, felhasználók által írt hetiszám-formulák gyakran hibásak — sokan ceil(dayOfYear / 7)-et használnak, ami sem ISO, sem US standard.

Google Sheets / Excel (tervezéshez): Alapból US-stílusra hajlanak. Az ISOWEEKNUM() explicit használata a biztonságos választás.

Gyakorlati következmény: két csapat különböző eszközökkel (vagy ugyanazzal az eszközzel eltérő locale beállításokkal) valid hetiszámot használhat, ami mégis mást jelent.

Sprinttervezés hetiszámokkal

A kéthetes sprintciklus szépen illeszkedik az ISO hetekhez, ha a sprintek hétfőn indulnak. Sprint N lefedi a 2N-1 és 2N ISO heteket. Sprint 1 = W1+W2, sprint 2 = W3+W4, stb.

A bonyodalom az 53 hetes évek. Olyan évben, amikor 53 ISO hét van, a W1-ben induló kéthetes sprintciklus „pont ráfut” az 53. hétre — a végén egy hét „maradék” keletkezik. A csapatok ezt többféleképpen kezelik:

• Elnyelik: a 26. sprint 3 hetes lesz. Előre bejelentve jó technikai adósságra vagy buffer időre nagy release előtt.
• Figyelmen kívül hagyják: nem igazítják a sprinteket a naptári hetekhez, csak onnan számolnak, ahol az év indult. A csúszás lassan nő, és senki nem veszi észre Q4-ig.
• Újratervezik nyáron: egyes csapatok félévkor resetelik a sprintnaptárt, és a második félévet „tiszta” illesztéssel indítják.

Az 53 hetes évek: 2026, 2032, 2037. Ha most a sprintnaptárad közel tökéletes ISO-illesztésben fut, tervezd meg előre a plusz hetet.

Az évhatár-sprint probléma

Még 53 hetes évek nélkül is okozhat zavart az év vége.

A legtöbb szervezet naptári év szerint tervez. Januárban resetel a roadmap. Resetel a budget. Változik a headcount. Az ISO 1. hét viszont nem mindig január 1-jén kezdődik — bizonyos években január első néhány napja még az előző év utolsó hetéhez tartozik.

2027: január 1. (péntek) ISO szerint 2026 W53-ban van. 2027 első hétfője január 4., ami ISO szerint 2027 W1.

Ha a csapatod „az év első sprintjét” W1-nek tekinti, és január 4-én indítja, akkor január 1–3 sem a tavalyi utolsó sprintbe, sem az idei elsőbe nem esik. Egy „senki földje” hétbe kerül, ami technikailag az előző évhez tartozik.

Tiszta megoldás: ismerd el, hogy a sprintnaptár és a pénzügyi/naptári év nem mindig ugyanazon a napon indul. Ne próbáld erővel január 1-re összeigazítani.

Roadmap-hetiszámok és a „relatív hét” csapda

A roadmapek gyakran fix oszlopként mutatják a hetiszámokat — W1, W2, W3 — mintha konkrét naptári hetekre utalnának. De egyes csapatok a hetiszámot relatív számlálóként használják a projektindulástól, nem naptári hetiszámként.

A „cél launch W8-ban” jelentheti:

• az aktuális év ISO 8. hetét (konkrét dátumtartomány)
• a projekt indulása óta eltelt 8. hetet (teljesen a start dátumtól függ)
• a 8. sprintet (ami lehet, hogy nem kéthetes)

Ez az ambiguítás ártalmatlan, ha mindenki ugyanazzal a mentális modellel dolgozik. Probléma lesz, ha:

• a csapaton kívüli stakeholder naptári 8. hétként olvassa
• egy alvállalkozó mid-project csatlakozik és ISO hetet feltételez
• a roadmap megmarad és egy évvel később is előveszik

Best practice: bármely roadmapben/dokumentumban, ahol hetiszámot használsz, tegyél be egy referenciat sort, ami megmutatja, milyen naptári dátumoknak felel meg a W1. Ez egyértelműen „lehorgonyozza” az egészet.

Több időzónás handoffok és a hét határa

Időzónák között dolgozó csapatoknál van egy speciális probléma: a hét határa (vasárnap/hétfő éjfél) más-más órában történik meg különböző embereknek.

Tervezésnél ez többnyire nem számít — a „W14 vége” általában péntek munkaidő vége a releváns csapat helyi idejében. Automatizált rendszereknél viszont a hét határa pontos, és egy „W15 hétfő eleje” ütemezés más UTC időpontban fut, attól függően, milyen időzónára van állítva a szerver.

Tipikus hibamód: egy heti riport „a hét elején” fut, hétfő 00:00 UTC-kor. San Franciscóban ez vasárnap este — a előző hét még nem ért véget. A riport már az aktuális hét adatait is tartalmazza, de vasárnapot még nem, így a heti aggregációk következetesen 1 nappal elcsúsznak.

Megoldás: szerveroldalon mindig UTC-ben számolj hetet, és csak megjelenítéshez konvertálj lokális időre. A hét határát timestampként tárold, ne hetiszámként.

Hetiszámok release tervezésben

Szoftvercsapatoknál gyakori a release ütemezés hetiszámokkal:

• „Code freeze W19, release W20”
• „RC cut W47-ben, GA W49-ben”

Ez tiszta és működőképes, egy feltétellel: az olvasónak tudnia kell, melyik év W19-éről van szó. Ez íráskor egyértelmű, de egy Q1-ben készült roadmap Q4-ben már félreérthető lehet, ha nincs rajta év.

Jól működő konvenció: mindig írd ki az évet a hetiszám mellé. 2026-W19, ne csak W19. ISO 8601 erre ad standard formátumot: YYYY-Www.

Különösen fontos ez:

• külső release note-oknál
• más csapatokkal vagy beszállítókkal megosztott függőségi ütemterveknél
• minden olyan dokumentumnál, amit év vége után is elővehetnek

Gyakorlati ellenőrzőlista hetiszámot használó csapatoknak

Projektindulás előtt:

• Egyezzetek meg egy hetiszámozási rendszerben (nemzetközi csapatnál az ISO a biztonságos alap)
• Ellenőrizd, hogy a fő tervező eszközöd ezt használja-e
• Írd le, hogy a projekted W1-je mely naptári dátumokra esik

Roadmapekben és ütemtervekben:

• Mindig írd ki az évet: 2026-W22, ne csak W22
• Tegyél be egy dátum-horgony sort, ami megmutatja, mit jelent a 1. hét
• Írd le, hogy a „W22 vége” péntek EOD-t jelent-e, vagy vasárnap éjfélt

53 hetes évekhez (2026, 2032, 2037):

• Jelöld meg az évet az éves tervezéskor
• Döntsétek el előre, hogyan kezelitek a plusz sprinthetet
• Ellenőrizd, hogy payroll/riport/ütemező rendszerek kezelik-e az 53 iterációt

Automatizált rendszerekhez:

• Használj UTC-t minden hét-határ számításhoz
• A hét határait timestampként tárold, ne hetiszámként
• Tesztelj december utolsó hetével és január első hetével

Használd az ISO Week Number Calculator eszközt bármely hetiszám hétfő–vasárnap tartományának lekérdezéséhez, vagy nézd meg a current week number értéket most.