Kaçırılan Görevler Bir İnsan Sorunu Değil
Proje yönetimindeki kaçırılan görevler neden disiplin ya da hafıza sorunu değildir ve ekibiniz ne zaman bir sisteme gerçekten ihtiyaç duyar.
By Ellis Keane · 2026-03-17
Ekibiniz, hepinizin birlikte öğle yemeği yiyebileceği kadar küçükse (ya da en azından teoride, aynı şehirde aynı anda bulunabilseydiniz), muhtemelen bunu okumanıza gerek yok. Sekmeyi kapatın. Bir şeyler inşa etmeye gidin. Sizin ölçeğinizdeki kaçırılan görev sorunu, çarşamba öğleden sonrasında bir Slack hatırlatıcısıyla çözülebilir – bunu gerçekten kastediyorum.
Hâlâ buradasınız? Peki, o zaman proje yönetimindeki kaçırılan görevlerden konuşalım – ve daha spesifik olarak, standart tavsiyenin ekibiniz belirli bir büyüklüğe ulaştığında neden işe yaramadığından.
Devam Etmeden Önce
Bu sorunu ele alan bir araç geliştiriyoruz (Sugarbug – bunun aksini iddia etsem yalan olur), ama dürüst cevap şu ki bunu okuyan ekiplerin çoğu, geliştirdiğimiz şeye henüz ihtiyaç duymuyor. Henüz değil. Belki hiç olmayacak. İhtiyaç duydukları şey, topun neden düşürüldüğünü anlamak – çünkü çözüm nedene bağlı, ve neden neredeyse hiçbir zaman insanların düşündüğü şey değil.
Görevler Neden Kaçırılır
Çoğu yöneticiye görevlerin neden kaçırıldığını sorarsanız, tanıdık bir liste duyarsınız: biri unuttu, biri dikkat etmiyordu, biri süreci takip etmedi. Dolayısıyla çözüm, daha iyi süreçler, daha fazla hatırlatıcı, belki her sabah insanları dürtükleyen bir standup botu.
Bakın, bazen bu gerçekten de sorun oluyor. Bir mühendisin Linear biletini güncellemeyi unutması ve PM'in sprint incelemesinden önce kontrol etmemesi, bu insan hatası ve süreç açığı. Tamam. Bir kontrol listesi ekleyin. Devam edin.
Ancak bu, mühendislik yöneticilerini geceleri uyutmayan türde kaçırılan görev değil. Gerçekten acıtanı, herkesin kendi işini yaptığı, süreci takip ettiği, araçlarını güncellediği – ama bir şeyin yine de boşluğa düştüğü durumlar. Çünkü boşluk, bir kişi ile onun görevi arasında değil. Bir araç ile diğeri arasında.
Kastım şu: Bir mühendis, bir GitHub issue'unu kapatan bir PR gönderiyor. Issue bir Linear biletiyle bağlantılıydı ve bilet "Tamamlandı"ya geçiyor. Harika. Tek sorun, özgün talebin üç hafta önce bir Slack konuşmasından gelmiş olması – orada PM, kimsenin ayrı bir görev olarak kaydetmediği bir takip gereksiniminden de söz etmişti. Bu takip gereksinimi Şubat ayından kalma bir Slack thread'inde. Linear'da değil. GitHub'da değil. Kimsenin sprint'inde değil. Teknik olarak kaçırılmış bir görev – ama onu kaçıran tek bir kişi yok. Slack ile görev takipçisi arasındaki yapısal boşluktan düştü.
Bu kalıp, aramaya başladığınızda her yerde karşınıza çıkıyor. Bir tasarımcı Figma'da bir yorum bırakıyor – bir kenar durumunun Notion'daki spesifikasyonla çeliştiğini belirtiyor – ama özellik üzerinde çalışan mühendis Figma'yı hiç kontrol etmiyor ve PM yorumu görmüyor çünkü Linear'da yaşıyor. Bir müşteri başarı lideri bir görüşmede bir özellik söz veriyor, e-posta ile özetliyor ve bu hiçbir zaman mühendislik backlog'una girmiyor çünkü o belirli boşluğu kimse köprülemiyor. Bir olay post-mortem'i üç takip maddesi tespit ediyor, belge Slack'te paylaşılıyor ve üçün ikisi hiçbir zaman takip edilen göreve dönüşmüyor çünkü bunu yapan kişi o hafta hastaydı.
Proje yönetimindeki en zarar verici kaçırılan görevler, insanlar ile görev listeleri arasındaki boşluklarda değil, araçlar arasındaki boşluklarda oluşur.
Süreç Çözümü (ve Durduğu Yer)
İyi süreçlerin çoğu ekip için bu sorunların büyük bölümünü çözdüğüne gerçekten inanıyorum. İşe yarayanlar bunlar – ve bunu herhangi bir art niyet olmaksızın paylaşıyorum çünkü (dürüst olmak gerekirse) lansman öncesindeyiz ve şu an yapabileceğimiz en iyi şey faydalı olarak güven inşa etmek.
Haftalık tarama. Bir kişi – ideal olarak PM veya mühendislik lideri – her cuma 30 dakika Slack thread'lerine, toplantı notlarına ve e-postalara bakarak tartışılan ama hiç takip edilmeyenleri yakalar. Sıkıcı mı? Kesinlikle. Etkili mi? Belirli bir noktaya kadar şaşırtıcı biçimde evet.
Karar günlüğü. Bir Slack thread'inden veya toplantıdan çıkan her karar, tarih, kim karar verdi ve takibin ne olduğu bilgisiyle birlikte paylaşılan bir belgeye (Notion, Google Docs, farketmez) yapıştırılır. Basit geliyor, ve gerçekten öyle – ta ki haftada on beş karar alıp dört kanalda dağıtılıncaya ve hangisinin kaydedildiğini kimse hatırlamayana kadar.
Bağlantı disiplini. Her PR, Linear biletine atıfta bulunur. Her Linear bileti, gereksinimin tartışıldığı Slack thread'ine bağlanır. Her Notion spesifikasyonu, Linear epic'ine bağlanır. Biri zinciri koparırsa (ve biri yapacak – bu bir "eğer" meselesi değil), görünürlük de onunla birlikte kopar.
Bunların hepsi iyi uygulamalar. Üçünün de versiyonlarını biz kendimiz kullanıyoruz. Ama ortak bir başarısızlık modu var: her biri, insanların küçük, sıkıcı bir şeyi her seferinde, tutarlı biçimde, sonsuza dek yapmasına bağlı. Buna dair araştırma cesaret verici değil (araştırma alıntılamam gerekmez – beşten fazla kişilik bir ekibi yönettiyseniz, bunu zaten biliyorsunuzdur).
Süreç Çözümü Ölçeklenmeyi Durdurduğunda
Bir eşik var ve size kesin bir sayı vermeyi isterdim, ama henüz bunu çözemedik (dürüstçe söylemek gerekirse, muhtemelen ekipten ekibe ve insanlarınızın ne kadar disiplinli olduğuna göre değişiyor). Bizim çalışma sezgimiz – ve bunun bir sezgi olduğunu, kıyaslanmış veri olmadığını açıkça belirtmek istiyorum – şeylerin yaklaşık dört veya beş araç, on artı kişi ve birden fazla paralel iş akışı etrafında bozulmaya başladığı yönünde.
Kimse tembelleştiği için değil. Süreç kötüydü diye değil. Araçlar arasındaki bağlantıların hacmi, herhangi bir kişinin bunları manuel olarak takip etme kapasitesini aştığı için. Haftalık tarama 30 dakika yerine 90 dakika alıyor ve PM okumayı atlıyor. Karar günlüğü, onu tutanın izne çıkması ve kimsenin devralmaması nedeniyle bayatıyor. Bağlantı disiplini Linear ve GitHub için tutuyor, ama Slack ve Figma için çöküyor çünkü bu araçlar aynı tür yapılandırılmış referanslara sahip değil.
Bu (ve bunu netleştirmek istiyorum) bir disiplin sorunu değil, bir ölçekleme sorunudur. Gerçekten mükemmel PM'lerin ve mühendislik liderlerinin – her şeyi sıkı tutan ve hiçbir şeyin gözden kaçmamasını derin bir özenle önemseyen insanların – bununla boğuştuğunu gördüm. Belirli bir ölçekte, sorun çözümü aşıyor. Bu, kişinin başarısızlığı değil – araç ekosisteminin kendi içinde bağlantı sağlayamamasının başarısızlığı.
"Araçlarınız konusunda sofistike olmanın ödülü, kaçırılan görevler için daha karmaşık bir başarısızlık yüzeyi. Bunu derin biçimde ironik buluyorum." – Ellis Keane
Ve bence bu konuda gerçekten haksız olan kısım şu: ekibiniz araçlarını kullanmada ne kadar iyiyse, araçlar arası boşluklar için o kadar fazla alan oluyor. Linear'ı titizlikle kullanan, Notion spesifikasyonlarını güncel tutan, aktif Figma incelemeleri yürüten ve iyi organize edilmiş Slack kanallarında iletişim kuran bir ekibin, yalnızca e-posta ve elektronik tablo kullanan bir ekipten daha fazla devir teslim noktası var.
Araçlarınız Neden Yardım Edemez
Bu sorunun tamamında gerçekten ilginç bulduğum ve yeterince konuşulduğunu düşünmediğim şey şu: araçlarınız tasarlandıkları şeyi tam olarak yapıyor. Linear, Linear issue'larını takip etmekte mükemmel. GitHub, kod değişikliklerini takip etmekte mükemmel. Notion, belgeleri düzenlemekte mükemmel. Slack, Slack olmakta mükemmel (iyisiyle kötüsüyle).
Ama hiçbiri birbirleri arasındaki bağlantıları takip etmek için tasarlanmadı. Ve gerçek iş, tek bir araçta olmuyor – hepsinde akıyor. Araçlar arasındaki devir noktaları şeylerin kaybolduğu yerler, ve herhangi bir aracı ne kadar geliştirseniz de bu sorunu çözmez. Linear'ı issue takibinde daha iyi yapabilirsiniz, ama bu, mühendislik liderinin takip etmediği bir kanalda geçen Slack konuşmasına dayanarak en baştan oluşturulması gereken issue için yardımcı olmaz.
Bunu Gerçekten Çözecek Olan
Bu yazıda kasıtlı olarak ürün konusunda muğlak kaldım – geliştirdiğimiz şeyi kullansanız da kullanmasanız da faydalı olmasını istedim. Ama buraya kadar geldiğinize göre (ve bunu takdir ediyorum), gerçek çözümün neye benzediğine dair düşündüklerimi dürüstçe paylaşayım.
Daha iyi bir görev takipçisi değil. Daha iyi bir süreç değil. Bir standup botu ya da haftalık gözden geçirme ya da paylaşılan bir elektronik tablo değil. Bunların hepsi yardımcı olur ve küçük ölçekte yeterliler, ama hepsi semptomu tedavi ediyor.
Gerçek çözüm, araçlarınız arasındaki bağlantıları izleyen ve bir şey uyumsuz göründüğünde işaret eden bir şey. Bir Slack kararı bilet olmuyor. Bir GitHub PR issue'yu kapatıyor ama çözülmemiş yorumlar var. Bir Notion spesifikasyonu, spesifikasyon yazarının hiç görmediği bir konuşmada önceliği düşürülmüş bir gereksinime atıfta bulunuyor.
Bunu somutlaştırmak için, bunun nasıl göründüğünü anlatalım. Diyelim ki sisteminiz hem Slack'i hem de Linear'ı izliyor. #engineering'de birinin "e-postasını doğrulamamış kullanıcı durumunu da ele almalıyız" dediği bir konuşma görüyor – bu yeni bir gereksinim. Bu gereksinim, 48 saat içinde Linear bileti olarak görünmezse sistem bunu işaret ediyor. Size bağıran bir bildirimle değil (kimsenin buna ihtiyacı yok), ama PM'in cuma taraması sırasında inceleyebileceği "henüz takip edilmemiş kararlar" görünümündeki bir giriş olarak. Aynı fikir, Linear biletlerini kapatan ama hâlâ açık inceleme yorumları olan GitHub PR'ları için veya spesifikasyon yazıldığından beri önceliği düşürülmüş özelliklere atıfta bulunan Notion spesifikasyonları için de geçerli.
Bunu şirket içinde oluşturun (bazı ekipler webhook'lar, bir mesaj kuyruğu ve mütevazı miktarda tutkal kod ile yapıyor), hazır bir şey kullanın ya da sadece kaçırılan görevleri iş yapmanın bir maliyeti olarak kabul edin – bu sizin kararınız. Bu cevabın bir versiyonunu geliştiriyoruz, ama tek versiyon bu değil ve pek çok ekip için henüz doğru olan değil.
Ne zaman sizin için doğru olabileceğini bilmek istiyorsanız, dürüst sezgim şu: haftalık taramanız 30 dakikadan fazla sürüyor ve şeyler hâlâ düşüyorsa, manuel yaklaşımı aştınız.
---
Haftalık tarama 30 dakikadan fazla sürdüğünde ve şeyler hâlâ düşmeye devam ettiğinde, manuel yaklaşımı aştınız. Sugarbug boşlukları otomatik olarak izler.
Q: Sugarbug, proje yönetimindeki kaçırılan görevleri nasıl önler? A: Sugarbug, araçlarınız genelinde bir bilgi grafiği oluşturur – Linear, GitHub, Slack, Figma, Notion – ve görevleri, konuşmaları ve kararları bunlar arasında hareket ederken takip eder. Bir şey durduğunda veya özgün taleple bağlantısını kaybettiğinde, Sugarbug onu boşluğa düşmeden önce yüzeye çıkarır. Bu bir hatırlatıcı sistemi değil – araçlar arasındaki öğeler arasındaki ilişkileri anlıyor ve bu ilişkiler koptuğunda işaret ediyor.
Q: Sugarbug, Slack'te tartışılan ama hiç kaydedilmeyen görevleri yakalayabilir mi? A: Evet. Sugarbug, Slack konuşmalarını izler ve bir karar ya da eylem maddesinin tartışıldığını ama Linear'da görev veya GitHub'da bilet olarak hiç görünmediğini tespit eder. Boşluğu işaretler, böylece biri üzerine hareket edebilir. İşaret etmenin ne kadar agresif olması gerektiğini hâlâ geliştiriyoruz (kimse her şeyin üstüne bildirim yorgunluğu istemiyor), ama temel algılama çalışıyor.
Q: Kaçırılan görevleri düzeltmek için bir araca mı ihtiyacım var, yoksa bu bir süreç sorunu mu? A: Dürüstçe söylemek gerekirse, ölçeğe bağlı. İki veya üç araçla çalışan küçük ekipler bunu genellikle daha iyi alışkanlıklarla çözebilir – haftalık gözden geçirme, paylaşılan bir belge, bağlantı disiplini. Ancak dört veya beş araçtan ve on kişiden fazlasına geçtiğinizde, manuel yaklaşım ölçeklenmeyi durdurur ve bağlantıları otomatik olarak izleyen bir şeye ihtiyacınız olur. Eşik ekipten ekibe değişir, ama ulaştığınızda anlarsınız.
Q: Proje yönetimi için görev takipçisi ile sinyal istihbaratı sistemi arasındaki fark nedir? A: Bir görev takipçisi size söylediklerinizi kaydeder. Bir sinyal istihbaratı sistemi araçlarınızda gerçekte ne olduğunu izler ve bir şey uyumsuz göründüğünde işaret eder – tamamlandı olarak işaretlenen ama çözülmemiş yorumları olan bir görev, Slack'te alınan ama spesifikasyona yansıtılmamış bir karar. İnsanların kaydetmeyi unuttuğu şeyleri yakalar – ki bu bizim deneyimimize göre bu boşlukların çoğunun gerçekte kaynaklandığı yer.