Alt görev ve bağımlılık: işin sırasını CRM'e yazmak

Perşembe 14:20. Bir bakım firmasının servis sorumlusu, müşteriye söz verilen işin o hafta kapanmayacağını fark ediyor. Görev listesinde tek bir satır var: "Hat 3 revizyonu — 12 Mart". Sorumlu atanmış, tarih girilmiş, öncelik yüksek işaretlenmiş. Ama o satırın içinde altı adım saklı: parça siparişi, parçanın depoya ulaşması, vardiya planı, saha ziyareti, test ve müşteri onayı. Sipariş iki gün geç verilmiş. Arkasındaki beş adım da iki gün kaymış, kimse görmemiş. Çünkü kayıtta kaymayı gösterecek bir yer yoktu: tek satır, tek tarih, tek durum.

Aşağıda bu tek satırın nasıl açılacağını sırayla ele alacağız: büyük görevin neyi gizlediğini, bir işi alt göreve mi ayrı göreve mi kontrol listesine mi böleceğinizi, bağımlılığın "sıra" ile "engel" arasındaki farkını, zinciri kimin ne zaman yazacağını, Gantt görünümünde neyin okunduğunu, bir halka koptuğunda tarihlerin ne olacağını, hangi işlerin bağımlılık yazmayı hak etmediğini, tıkanan işin sahibinin nasıl bulunacağını ve mevcut bir projeye bağımlılığın hangi sırayla ekleneceğini.

Tek satırlık bir görev neyi gizler?

Bir görev başlığı çoğu zaman söz verir ama plan vermez. "Hat 3 revizyonu" cümlesi, o işi yapacak kişinin kafasındaki adımları taşımaz; adımlar kayıtta değil, birinin hafızasındadır. Hafıza kötü bir yer değildir — o kişi işin başındayken çark döner. Sorun, o kişi izne çıktığında, iş devredildiğinde ya da aynı kişi paralelde üç iş birden yürütmeye başladığında ortaya çıkar.

Tek satırlık görevin gizlediği üç şey vardır. Birincisi sıra: hangi adım hangisinden önce gelmek zorunda? İkincisi bekleme: iş bizim yavaşlığımızdan mı duruyor, yoksa dışarıdan gelecek bir şeyi mi bekliyor? Üçüncüsü devir: iş bir kişiden diğerine geçerken tam olarak ne teslim ediliyor? Bu üçü yazılmadığında görev haftalarca "devam ediyor" durumunda kalır ve durum alanı teknik olarak doğru olduğu için kimse yanlış bir şey söylemiş olmaz.

Bu üç bilginin kayda geçmesi, işi karmaşıklaştırmaz; halihazırda var olan karmaşayı görünür kılar. Bir servis organizasyonunda sahadan faturaya uzanan iş emri akışının tek bir satırda temsil edilemeyeceğini herkes bilir; aynı şey pazarlama kampanyası, işe alım süreci ya da bir teklifin hazırlanması için de geçerlidir. Fark şu ki fabrikada adımlar fiziksel olarak görünür, ofiste görünmez.

Alt görev ve bağımlılık, bu görünmezliği kapatmak için vardır. Alt görev "bu iş şu parçalardan oluşuyor" der. Bağımlılık ise "bu parça, şu parça bitmeden başlayamaz" der. İkisi ayrı sorulardır ve çoğu ekip bunları birbirine karıştırdığı için ya hiç kırılım yapmaz ya da her şeyi gereksiz yere birbirine bağlar.

Alt görev mi, ayrı görev mi, kontrol listesi mi?

Bir işi bölmeye karar verdiğinizde ilk soru "kaç parça" değil, "hangi biçim" olmalıdır. Kontrol listesi maddesi, alt görev ve bağımsız görev farklı ağırlıklardadır. Kontrol listesi maddesinin sahibi yoktur, tarihi yoktur, raporda görünmez; sadece unutmamak içindir. Alt görevin sahibi ve tarihi vardır ama kendi başına anlamı yoktur, üst göreve bağlıdır. Bağımsız görev ise tek başına ayakta durabilen, kendi son teslim tarihi olan bir taahhüttür.

Pratikte karar üç eşikle verilir: parçanın sahibi üst görevin sahibinden farklı mı, parçanın kendi tarihi var mı, parça bittiğinde başka birinin işi başlıyor mu? Üçüne de "hayır" diyorsanız kontrol listesi yeter. Birine "evet" diyorsanız alt görev açın. Üçüne de "evet" diyorsanız o parça artık alt görev değil, kendi başına bir görevdir.

Durum	Doğru biçim	Neden
Aynı kişi, aynı gün, birkaç dakikalık adımlar	Kontrol listesi maddesi	Sahip ve tarih tekrarlanırsa gürültü olur
Farklı kişi, aynı teslim tarihi	Alt görev	Sorumluluk ayrışır, hedef ortak kalır
Farklı kişi, farklı tarih, sıra zorunlu	Alt görev + bağımlılık	Gecikme zincirin devamına yansımalı
Kendi başına raporlanan, müşteriye söz verilen iş	Bağımsız görev	Üst görev kapansa da izlenmeye devam eder
Her ay aynı biçimde tekrarlayan adım seti	Şablon veya tekrarlayan görev	Elle kurulum her seferinde eksik kalır

Bu tabloyu her yeni iş için baştan uygulamak zorunda değilsiniz. Aynı kırılım ikinci kez elle kuruluyorsa o kırılım artık bir kalıptır ve görev şablonu olarak kaydedilmeyi hak eder; şablon, adım listesini ve aralarındaki sırayı birlikte taşır.

Bir alt görevin metni de biçim kadar önemlidir. "Tasarımı hazırla" bir alt görev değil, bir temennidir. Kabul kriteri, teslim biçimi ve kime teslim edileceği yazılmadığında zincirin bir sonraki halkası işi geri çevirir. Bu yüzden iyi bir alt görev tanımı, yazara verilen bir içerik brief'i gibi okunur: ne, kime, hangi biçimde, ne zaman.

Bağımlılık "sıra" mıdır, "engel" midir?

Bu ayrım, bağımlılık kurmanın en sık atlanan yeridir. Kronolojik sıra, işlerin bizim planımızda hangi hafta yapılacağını söyler. Engel ise bir işin fiziksel ya da mantıksal olarak başlayamamasıdır. İkisini aynı şeymiş gibi kaydettiğinizde plan katılaşır: aslında paralel yürüyebilecek iki iş, yalnızca takvimde art arda yazıldıkları için birbirini beklemeye başlar.

Sınamak için tek bir soru yeter: "Önceki iş bugün bitmeseydi, bu iş bugün başlayabilir miydi?" Cevap evetse ortada bağımlılık değil, sadece bir tercih vardır. Cevap hayırsa gerçek bir bağımlılık vardır ve kayda geçmelidir. Servis tarafında bu soru genellikle kendini net biçimde gösterir: yedek parça deposundan çıkış yapılmadan montaj adımı başlayamaz; burada bekleyen şey kişi değil, malzemedir.

Bağımlılıkların büyük çoğunluğu "bitir–başla" tipindedir: önceki bitmeden sonraki başlamaz. Daha az sıklıkla "başla–başla" kurmak istersiniz; iki iş birlikte yürümek zorundadır, biri başlamadan diğeri anlamsızdır. Üçüncü bir kategori de beklemedir: kimsenin çalışmadığı ama takvimde yer kaplayan süre — onay bekleyen sözleşme, kargoda geçen gün, laboratuvar sonucu. Bekleme süresini görev olarak açmak yanlış görünür ama açmadığınızda planınız gerçekte olmayan bir hız varsayar.

Zinciri kim, ne zaman yazar?

Bağımlılık geriye dönük yazıldığında işe yaramaz. İş tıkandıktan sonra "aslında bu şuna bağlıydı" demek, bir açıklamadır; plan değildir. Zincirin, işin başladığı gün — projeyi açan kişi tarafından — kurulması gerekir. Bunun için detaylı bir proje planı gerekmez; ilk oturuşta yalnızca "hangi adım hangisini bekliyor" sorusunun cevabı yazılır, süreler sonra netleşir.

Zinciri yazacak kişi, işin sonucundan sorumlu olan kişidir. Adımı yapacak kişi değil — çünkü her uzman kendi adımını merkeze koyar ve ötesini görmez. Rocketly'nin Görev Yönetimi tarafında Alt Görev & Bağımlılık, bu kararı görevin kendi kaydında tutar: hangi görev hangisini bekliyor bilgisi bir toplantı notunda değil, işin üzerinde durur ve zincir değiştiğinde bu değişikliği kimin yaptığı Aktivite Geçmişi'ne düşer. Böylece "bu sırayı kim değiştirdi" tartışması, hatırlamaya değil kayda dayanır.

Zincirin ilk taslağı çoğu zaman bir toplantıda çıkar. Buradaki risk, kararların not olarak kalmasıdır. Toplantıdan aksiyon maddesi çıkarma disiplini tam da burada işe yarar: konuşulan sıra, toplantı biterken göreve ve bağımlılığa dönüşmediyse ertesi gün yeniden konuşulacak demektir.

Gantt görünümünde aslında ne okunuyor?

Gantt görünümü süslü bir takvim değildir; zincirin uzunluğunu okumak içindir. Aynı görev havuzunu Kanban, liste, takvim ve Gantt olarak açabildiğinizde her görünüm farklı bir soruyu yanıtlar. Kanban "şu an ne nerede" der, liste "kimde ne kadar var" der, takvim "bu hafta ne var" der. Gantt ise tek bir soruyu yanıtlar: bu işin toplam süresini hangi adımlar belirliyor?

Bir projede birbirine bağlı adımların oluşturduğu en uzun yol, projenin gerçek süresidir. O yolun üzerindeki bir adım bir gün gecikirse proje bir gün gecikir; o yolun dışındaki bir adım üç gün gecikse bile teslim tarihi değişmez. Bu ayrımı görmeden yapılan hızlandırma girişimleri genellikle yanlış yere yapılır — zaten boşluğu olan bir adım daha da hızlandırılır, asıl darboğaza dokunulmaz.

Aynı okuma satış tarafında da geçerlidir. Bir fırsatın aşamaları arasındaki geçişler de aslında bağımlılık zinciridir: demo yapılmadan teklif hazırlanmaz, teklif gitmeden pazarlık başlamaz. Pipeline aşamalarını doğru tasarlamak, aynı mantığın satış hattındaki karşılığıdır; oradaki aşama sırası ile projedeki görev sırası aynı soruya cevap verir.

Bir halka koptuğunda tarihler ne olur?

Zincir kurmanın asıl faydası, plan hazırken değil, plan bozulduğunda ortaya çıkar. Öndeki iş gecikti; arkadaki dört işin tarihi ne olacak? Üç yanlış cevap vardır: hepsini olduğu gibi bırakmak (liste yalan söylemeye başlar), hepsini tek tek elle ötelemek (kimse yapmaz), ya da teslim tarihini sabit tutup aradaki süreleri sıkıştırmak (ekip fark etmeden fazla mesaiye zorlanır).

Doğru cevap, gecikmeyi kayıt üzerinde açıkça yaşatmaktır. Görev ertelenirken gerekçe yazılması, ertelemenin nedenini hatırlatma geçmişine düşürür; bir ay sonra "neden kaydı" sorusunun cevabı hafızada değil kayıttadır. Rocketly'de Gerekçeli Erteleme bu yüzden ayrı bir adımdır ve yanıtsız kalan hatırlatıcılar için tanımlanan Eskalasyon Politikası, süre eşiği aşıldığında işi yedek kişiye taşır. Zincirin kopması sessiz kalmaz, bir yere düşer.

Bekleme kaynaklı gecikmeler ayrı bir kategoridir çünkü çözümü ekipte değildir. Karşı taraftan onay bekleyen bir adım, ekibin hızıyla ilgili değildir; bunu performans sorunu gibi raporlamak yanlış sonuç üretir. İmzadan yenilemeye kadar sözleşme takibinde bu ayrım özellikle belirgindir: sürenin büyük kısmı sizde değil, karşı tarafın hukuk masasında geçer ve bunu ayrı ölçmeniz gerekir.

Hangi işler bağımlılık yazmayı hak etmez?

Bağımlılık bedava değildir. Her bağlantı, sonradan bakım isteyen bir kuraldır: tarih değişince gözden geçirilir, iş iptal olunca temizlenir, yanlış kurulduğunda planı olduğundan uzun gösterir. Bu yüzden "her şeyi bağlayalım" yaklaşımı, hiç bağlamamak kadar zararlıdır. Kırk maddelik bir zincir kurup üç hafta sonra kimsenin bakmadığı bir şema bırakmak sık görülen bir sonuçtur.

Üç durumda bağımlılık yazmayın. Birincisi, iki iş gerçekten paralel yürüyebiliyorsa. İkincisi, sıra her seferinde değişiyorsa — o zaman kural değil, tercih vardır. Üçüncüsü, adım o kadar kısaysa ki takip maliyeti işin kendisinden büyükse. Rutin ve öngörülebilir işlerde kırılım yerine otomasyon daha doğru araçtır; tekrarlayan satış görevlerini tetikleyicilerle kurmak, aynı zinciri her ay elle çizmekten hem ucuz hem daha güvenilirdir.

Basit bir eşik işe yarar: bir işin altında altıdan fazla bağımlılık halkası oluşuyorsa, o iş muhtemelen tek görev değil, kendi başına bir projedir. Projeye taşıyın; görev seviyesinde tutmaya çalışmak hem görünümü hem raporu bozar.

Tıkanan iş kimin üzerinde kalıyor?

Zincirin en kırılgan yeri adımların içi değil, aralarıdır. İş bir kişide bitmiş, diğerine geçmesi gerekiyor ama geçmemiştir; kimse "bende değil" demez, kimse de almaz. Bu boşluk, gecikme istatistiklerinde genellikle son adımın üzerine yazılır ve yanlış kişi yavaş görünür.

Devir noktalarını görünür kılmanın yolu, alt görevin sahibini üst görevden bağımsız atamaktır. Görev kime atandı ve bu ne zaman değişti bilgisi kayıtta durduğunda, "ben haberdar değildim" cümlesi ölçülebilir bir olaya dönüşür. Yönetici tarafında Görev Yükü raporu ve Çalışma Alanı'ndaki ekip özeti aynı soruya bakar: kimin üzerinde ne kadar açık iş var, kimde yığılma başlamış, hangi kişi zincirin darboğazı haline gelmiş.

Ekip aynı ofiste değilse bu boşluklar daha da uzar, çünkü koridorda sorulacak soru artık sorulmuyordur. Dağınık ekipte görünürlük ve ritim kurmak, tam da bu devir anlarını yazılı hale getirmekle başlar: kim neyi teslim aldı, ne zaman aldı, neyi bekliyor.

Mevcut bir projeye bağımlılık hangi sırayla eklenir?

Yürüyen bir işi durdurup baştan modellemek gerekmez. Beş adımlık bir sıra çoğu ekipte yeterlidir. Birinci adım: bitmesi en çok gecikmiş üç işi seçin; zincir kurmaya oradan başlayın, çünkü fayda orada birikmiştir. İkinci adım: her biri için "bu iş şu an neyi bekliyor" sorusunu tek cümleyle yazın. Üçüncü adım: bu cümledeki bekleme, sistemde bir görev olarak var mı diye bakın; yoksa açın, çünkü olmayan bir işe bağımlılık kuramazsınız.

Dördüncü adım: bağımlılıkları kurun ve tarihleri zincire göre yeniden hizalayın — sıraya uymayan tarihleri düzeltmek için toplu işlem kullanmak, tek tek tıklamaktan hem hızlı hem tutarlıdır. Beşinci adım: gerçekten çalışılacak zamanı takvimde bloklayın. Son teslim tarihi işin ne zaman biteceğini söyler, zaman bloğu ne zaman yapılacağını; bu iki tarih birbirinden ayrıldığında plan gerçeğe yaklaşır.

İki hafta sonra Görev Süreleri raporuna bakın. Tahmin ettiğiniz süre ile gerçek süre arasındaki fark, zincirin nerede yanlış kurulduğunu tahminden daha iyi anlatır. Bu ölçümü ayrı bir proje aracında tutmak zorunda değilsiniz; işi müşteriden kopardığınız anda bağlam kaybolur ve on ayrı uygulamaya dağılmış bir yığın, zincirin kendisinden daha fazla bakım ister.

Kendi projelerinizde bu sırayı denemek isterseniz Rocketly hesabınızı ücretsiz açıp ilk zinciri tek bir gecikmiş iş üzerinde kurabilirsiniz.

Sıkça sorulan sorular

Alt görev ile bağımlılık aynı şey mi?

Hayır. Alt görev, bir işin parçalarını gösterir; bağımlılık ise parçalar arasındaki sırayı kurar. Bir işi alt görevlere bölüp aralarında hiç bağımlılık kurmayabilirsiniz — parçalar paralel yürüyorsa doğrusu da budur. Tersi de olur: iki bağımsız görev birbirine bağlanabilir, aralarında ana–alt ilişkisi olmasa bile.

Bağımlılık kurmak planı katılaştırmaz mı?

Yanlış kurulursa katılaştırır. Kronolojik tercihleri bağımlılık olarak kaydettiğinizde paralel yürüyebilecek işler birbirini bekler. Ölçüt tek: önceki iş bitmeseydi bu iş başlayabilir miydi? Cevap evetse bağlantı kurmayın.

Zincirdeki bir görev iptal olursa ne yapmalı?

Görevi silmek yerine iptal olarak kapatın ve ona bağlı adımların bağımlılığını gözden geçirin; aksi halde arkadaki işler hiç başlamaz. Yanlışlıkla silinen bir görev ya da proje için çöp kutusundan geri yükleme vardır, ancak zincir kararlarının kayıtta kalması için kapatmak silmekten daha iyidir.

Küçük ekipler için bu kırılım fazla ağır değil mi?

Üç kişilik bir ekipte her işi kırmanın anlamı yok. Kural şu: yalnızca birden fazla kişinin devrettiği ya da dışarıdan bir şey beklediği işlerde zincir kurun. Bu genellikle işlerin küçük bir bölümüdür ve gecikmelerin büyük bölümü oradan çıkar.