Görevler Neden Kaçırılır (ve PM Aracı Sorunu Çözmez)
Görevler sürekli kaçırılıyor mu? Sorun ekibinizde ya da araçlarınızda değil – aralarındaki boşluklarda. İşte sistemsel çözüm.
By Ellis Keane · 2026-03-12
Piyasadaki her proje yönetim aracı, hiçbir şeyin kaybolmayacağı bir yer olduğunu vaat eder. Ortalama bir ekibin bu araçlardan altı ya da yedisini aynı anda kullandığı ve her birinin tek gerçek kaynak olduğunu ciddiyetle ilan ettiği düşünüldüğünde, bu oldukça ilginç bir satış konuşmasıdır – oysa gerçek bilgi hepsine dağılmış durumdadır ve hiçbirinde eksiksiz kayıtlı değildir. Görevlerin kaçırılması herhangi bir aracın başarısızlığı değil – birbirinden habersiz araçlara iş dağıtmanın doğal bir sonucudur.
Bu bir yazılım sorunu değil. Bu bir tür sorunu.
Kaçırılan bir görevin anatomisi: Adli bir zaman çizelgesi
Geçen yıl birlikte çalıştığım bir ekipte kaçırılan tek bir görevi izlemek istiyorum – dramatik olduğu için değil, o kadar sıradan olduğu için ki, ekibin yaklaşık bir haftasına mal olana kadar kimse kayıp yaşandığını fark etmedi.
Pazartesi, 10:14. Bir tasarımcı, Figma dosyasına bir ayarlar panelindeki kontrast oranına ilişkin bir erişilebilirlik sorununu işaretleyen bir yorum gönderir. Baş mühendisi @-mentions ile etiketler. Yorum Figma'da kalır – bu ekibin işleri takip ettiği yer değildir.
Pazartesi, 11:02. Mühendis bildirimi görür, Figma dosyasını açar, yorumu okur ve "iyi yakaladın, bir bilet açacağım" diye yanıt verir – tam bir içtenlikle, çünkü gerçekten öyle düşünmektedir; ama yaklaşık kırk beş dakika sonra bir PR incelemesine çekilecek ve her şeyi tamamen unutacaktır.
Pazartesi, 14:30. Aynı erişilebilirlik sorunu, yaklaşan sürümle ilgili bir Slack başlığında yeniden gündeme gelir – kimse bunu Figma yorumuyla ilişkilendirdiği için değil, QA mühendisi bağımsız olarak bir Lighthouse denetimi çalıştırıp aynı kontrast hatasını tespit ettiği için. Üç kişi konuyu tartışır, lansmantan önce düzeltilmesi gerektiğinde hemfikir olur ve biri (kimin olduğu net değil, ki bu da sorunun bir parçası) "takip altına alındığından emin olacağını" söyler.
Salı, 09:15. Standup. Kontrast sorununu kimse gündeme getirmez. Linear'da olmadığı için kimsenin panosunda görünmez. Tasarımcı, mühendisinin bilet açtığını varsayar. Şu sıralar ilgisiz bir yeniden yapılandırmanın içinde olan mühendis gerçekten unutmuştur. QA mühendisi, Slack başlığının konuyu çözdüğünü varsayar. Herkesin varsayımı mükemmel derecede makul ve tamamen yanlıştır.
Perşembe, 16:00. Sürüm çıkar ve kontrast sorunu da beraberinde çıkar. Düşük görme yetisine sahip bir müşteri sorunu üç gün sonra destek aracılığıyla bildirir; asıl düzeltme bir mühendise yaklaşık yirmi dakika sürerken, etraftaki karmaşa – destek bileti, eskalasyon, bu konunun nasıl gözden kaçtığına dair retrospektif konuşma, özür niteliğindeki commit mesajıyla açılan pull request – neredeyse bir gün alır.
Cuma, retrospektif. Ekip "daha iyi bilet hijyenine" ihtiyaçları olduğu konusunda hemfikir olur. Biri bir Slack botu önerir. Diğeri haftalık bir triage toplantısı önerir. Her ikisi de gerçekte olanın yaklaşık sıfır yüzdesini ele alan mükemmel derecede makul fikirlerdir.
title: "Bir Hatanın Takip Edilmeden Üretime Nasıl Ulaştığı" Pazartesi, 10:14|ok|Tasarımcı Figma'da erişilebilirlik sorununu işaretler; lead engineer'ı @-bahseder Pazartesi, 11:02|amber|Mühendis bilet oluşturmayı vaat eder; PR incelemesine çekilir ve unutur Pazartesi, 14:30|amber|Aynı sorun QA tarafından Slack'te bağımsız olarak gündeme getirilir; sahiplik belirsiz Salı, 09:15|missed|Standup: sorun Linear'da yok, bahsedilmiyor – herkes başkasının hareket ettiğini varsayıyor Perşembe, 16:00|missed|Sürüm yayınlanır; kontrast sorunu beraberinde gider Cuma|amber|Retrospektif: ekip "daha iyi bilet hijyeni" konusunda hemfikir – semptomu ele alır, nedeni değil
Asıl suçlu araçlar değil
Zaman çizelgesine baktığınızda sinyal başından beri mevcuttu – Pazartesi sabahı Figma'da, Pazartesi öğleden sonra Slack'te. Üç ayrı kişi aynı sorunu tespit etti, tartıştı ve önemli olduğu konusunda hemfikir oldu. Bilgi doğruydu, görünürdü ve tamamen işe yaramazdı; çünkü görünürlüğün eyleme dönüştüğü tek yere bir türlü sıçrayamadı.
Görev takipçinizin pazarlama materyallerinde pek yer bulmayan temel bir sınırlaması vardır: yalnızca birinin zaten içine yazdığı işleri takip edebilir. Figma yorumu Linear'ın evreninde var olmaz. Üç kişinin bir şeyin yapılması gerektiğine karar verdiği Slack konuşması da orada var olmaz. Her araç, mükemmel dahili arama özelliğine sahip ancak komşusunda olup bitenden tamamen habersiz kapalı bir sistemdir. Proje yönetimi sektörü yirmi yıl boyunca giderek daha iyi duvarlarla çevrili bahçeler inşa etti ve sonra duvarlar arasındaki boşluklarda şeylerin kaybolmasına şaşırdı.
Çözümün yalnızca "daha iyi entegrasyon" olması rahatlatıcı olurdu, çünkü bu parayla çözülebilecek bir sorun. Ama "bilet açacağım" diyen mühendis dikkatsiz değildi – dikkatini gerektiren bir PR incelemesine çekildi ve Figma yorumunun bir erteleme düğmesi yoktu, dolayısıyla bağlam değiştirmeyi atlatmak için tamamen hafızasına bağlıydı. "Takip altına alındığından emin olacağım" diyen QA mühendisi ihmalden kaynaklanan belirsizlikte değildi – Slack'te "birinin bunu takip etmesi gerekiyor" demek, özelde kimseye delege etmese de somut bir eylem gibi hissettiriyor. Ekiplerin bu boşlukları başvuru formları, Slack-to-Jira botları ve standup'larda "henüz biletlenmemiş bir şey var mı?" gibi zorunlu sorularla kapatmaya çalıştığını gördüm – ve dürüst olmak gerekirse bir kısmı bir süre işe yarar (bir Slack botu yaklaşık üç ay kullandık; insanlar refleks olarak onu yok saymaya başlayana kadar – ki bu her otomatik hatırlatıcının kaçınılmaz akıbetidir).
Rahatsız edici gerçek şu ki (ve bunun için temiz bir çözüm olduğundan emin değilim) işte şeylerin kaçırılması büyük ölçüde insan dikkatinin çok fazla kanala dağıldığında nasıl çalıştığının bir sonucudur. Biz tutarsız varlıklarız – dikkati dağınık, yorgun, seyirci etkisine açık – ve hiçbir disiplin eğitimi, bugün otuz kez bağlam değiştirdiğiniz ve her değiştirmenin zihninizdeki her şeyden biraz götürdüğü gerçeğinin üstesinden gelemez.
"Birisi sorunu tespit etti" ile "birisi sorunu takibe aldı" arasındaki boşluk, kaçırılan görevlerin çoğunun yaşandığı yerdir. Bu boşluk bir araç sorunu değil, insan dikkati sorunudur; bu yüzden daha fazla araç eklemek bu boşluğu nadiren kapatır.
Gerçekten işe yarayanlar (dürüst uyarılarla)
Hiçbir maliyeti olmayan ve gerçek fark yaratan dört uygulama. Her birinin nerede sınıra ulaştığını açıkça belirteceğim; çünkü bunlardan herhangi birinin eksiksiz bir çözüm olduğunu iddia etmek dürüst olmaz.
Dönen sinyal sahibi. Ekip başına bir kişi, haftalık dönüşümlü olarak, tüm işi takip edilmesi gereken ama henüz takip edilmeyen şeyler için Slack başlıklarını ve toplantı notlarını taramak olan kişi. Bu uygulama yerindeyken dikkat çekici biçimde iyi çalışır; çünkü seyirci sorununu açık bir atamaya dönüştürür – boşluğun bir sahibi olur. Sınırına ulaşır; çünkü sinyal sahibi Figma yorumlarını, PR inceleme başlıklarını ve e-postayı aynı anda izleyemez (deneyebilir, ama çok hızlı tam zamanlı bir iş haline gelir).
24 saatlik triage SLA'sı. Eyleme geçilebilir olduğu işaretlenen her şey bir gün içinde sınıflandırılır: bir bilete dönüştürülür, mevcut bir biletle ilişkilendirilir ya da – ve bu çoğu ekibin atladığı kısım – bir gerekçeyle açıkça reddedilir. Bu red son derece önemlidir. Birisinin sinyale baktığı ve "hayır" dediği anlamına gelir. Sinyallerin belirsizce süresiz asılı kalmasından çok daha iyidir.
Slack'te emoji etiketleme. "Bu bir bilete ihtiyaç duyuyor" anlamına gelen bir bilet emojisi kullanırız. Herkes herhangi bir mesajı etiketleyebilir, iki saniye sürer. Sinyal sahibi etiketlenen mesajları her sabah kontrol eder. Utanç verici derecede düşük teknoloji ve sinir bozucu derecede etkili – ta ki biri Cuma günü 16:55'te bir mesajı etiketleyip Pazartesi'ye kadar kimse kontrol etmeyene kadar.
PR inceleme kontrol noktası. Merge etmeden önce: "Bu incelemede bilete dönüşmesi gereken yorumlar var mıydı?" Bir soru, belki on saniye. Yeniden yapılandırma uyarılarını ve "bunu daha sonra gerçekten düzeltmeliyiz" notlarını yakalar; bunlar aksi takdirde GitHub'ın dipsiz arşivine karışır.
Bunların hepsi iyi alışkanlıklar ve her birini öneririm. Ama ortak bir tavanları var: insanların bir şeyi tutarlı biçimde yapmayı hatırlamasına dayanırlar ve (türün sorunu yeniden karşımıza çıkıyor) biz bunu sadece yapmıyoruz. Daha fazla kaçırmayı önlersiniz. Hepsini önleyemezsiniz.
İşe yarayan
- Dönen sinyal sahibi – Haftalık dönen bir kişi, araçlar arasındaki boşluğa açıkça sahip çıkar
- 24 saatlik triyaj SLA'sı – Uygulanabilir sinyaller bir gün içinde sıralanır veya açıkça reddedilir
- Slack'te emoji etiketleme – Bir sinyalin bilet gerektirdiğini iki saniyede işaretleme
- PR inceleme kontrol noktası – Birleştirmeden önce bir soru, takip edilmesi gereken yorumları yakalar
Başarısız olan
- Bireysel disiplin – İnsanların tutarlı biçimde hatırlamasına dayanır – bunu sadece yapmayız
- Otomatik hatırlatıcı botlar – Her otomatik hatırlatıcı gibi sonunda görmezden gelinir
- Daha fazla PM aracı ekleme – Hiç girilmemiş işi takip edemez
- "Daha iyi entegrasyonlar" – UI boşluğunu köprüler ama insan dikkat boşluğunu değil
Proje yönetimi sektörü yirmi yıl boyunca giderek daha iyi duvarlarla çevrili bahçeler inşa etti ve sonra duvarlar arasındaki boşluklarda şeylerin kaybolmasına şaşırdı. attribution: Ellis Keane
Araçların değil boşlukların izlenmesi
Chris ve benim Sugarbug'ı inşa ederken sürekli geri döndüğümüz soru şuydu: araçların kendisinden ziyade araçlar arasındaki boşlukları izleyebilseydiniz ne olurdu?
Sugarbug bunu yapar – API aracılığıyla mevcut kurulumunuza bağlanır ve kaynaklar genelinde sinyalleri birbirine bağlayan bir grafik oluşturur. Figma yorumu, Slack başlığı ve PR inceleme yorumu, birbirlerine ve ilgili kişilere bağlanan aynı grafiğin düğümleri haline gelir. Kimsenin takip etmediği bir sinyal geldiğinde, Sugarbug onu retrospektifin konusu olmadan önce doğru kişiye iletir.
Daha zor sınıflandırma sorunlarının üzerinde hâlâ çalıştığımızı dürüstçe belirtmeliyim. "Birinin toplantıda sesli düşünmesi" ile "birinin gerçek bir eylem öğesi belirlemesi" arasındaki çizgi tam olarak nerede? Bu gerçekten zor bir sorun ve hiçbir sistemin – bizimki dahil – bunu %100 doğru yapacağına emin değilim. Ama temel döngü – araçlar genelinde sinyallerin gözlemlenmesi, eyleme geçilebilir olanların sınıflandırılması ve takip edilmeyenlerin öne çıkarılması – çalışıyor ve neye eylem gösterdiğinize karşı neyi reddettiğinizden öğrendikçe zaman içinde daha da iyileşiyor.
---
Sugarbug, hiçbir şeyin düşmemesi için araçlarınız arasındaki boşlukları izler. Nasıl çalıştığını görün
---
Kaçırılan görevlerin gerçek maliyeti
Adli zaman çizelgesindeki erişilebilirlik sorununa geri dönmek istiyorum; çünkü aşağı yöndeki maliyet açıklanmaya değer.
Mühendislik düzeltmesi yirmi dakika sürdü. Toplam maliyet – destek bileti, müşteri eskalasyonu, iç soruşturma, retrospektif ve düzeltme için açılan PR – üç kişiye yayılmış tam bir iş gününe yakındı. Bir kaçırılan sinyal, belki altı saatlik israf. Bu matematik tek başına pek de kötü görünmez; ama deneyimlerime göre sekiz ila on kişilik bir ekip, sprint başına üç ila dört sinyal kaçırır; bu da her iki haftada yaklaşık altı ila sekiz saatlik boşa harcanan zamana tekabül eder.
Ölçülmesi daha güç olan maliyet (ve sanırım daha pahalı olan) arka plan kaygısıdır – çok araçlı bir ekipteki her mühendisinin taşıdığı "bir şeyi mi unutuyorum?" şeklindeki alçak perdeli vızıltı. Aşırı kontroller, "hey, Salı günkü konuyu takip etmeyi kaybetmedik değil mi?" şeklindeki DM'ler, yalnızca kimse sistemin bağlamı tutmasına güvenmediği için var olan durum toplantıları. Bu, hiçbir sprint raporunda görünmeyen ama insanların işleri hakkındaki hislerine kesinlikle yansıyan bilişsel yük. For a practical system to address this, see our guide on keeping work from slipping through the cracks. We also cover the dropped-ball pattern in project management for the organisational angle, and recovering after dropping the ball for when something has already been missed.
Sinyal zekasını gelen kutunuza alın.
Sıkça Sorulan Sorular
Sugarbug görevlerin kaçırılmasını nasıl önler?
Sugarbug, araçlarınıza API aracılığıyla bağlanır ve sinyaller, kişiler ile iş öğeleri arasındaki ilişkileri haritalayan bir bilgi grafiği oluşturur. Bir araçta eyleme geçilebilir bir şey ortaya çıkıp hiçbir yerde takip edilmediğinde, Sugarbug bunu işaretler ve ilgili bağlamla ilişkilendirir; böylece doğru kişi, kaçırılan görev haline gelmeden önce harekete geçebilir.
Sugarbug bir proje yönetim aracı mı?
Hayır – halihazırda kullandığınız PM aracının yanında çalışır. Sugarbug, Linear, Asana veya Jira'nın yerini almaz; araçlarınız arasında hareket eden sinyalleri izler ve aksi takdirde boşluklara karışacak olanları yakalar.
Ekipler proje yönetim araçları kullanmasına rağmen görevler neden kaçırılır?
PM araçları yalnızca açıkça girilmiş işleri takip edebilir; bu da yukarı akışta yaşanan her şeye kör oldukları anlamına gelir – biri endişesini belirttiği Slack başlığı, bir sorunu öngören PR yorumu, karar alınan ama hiç kaydedilmeyen toplantı. Konuşma ile bilet arasındaki bu boşluk, görevlerin en sık kaçırıldığı yerdir.
Sugarbug mevcut proje yönetim kurulumumuzla birlikte çalışabilir mi?
Evet. Mevcut iş akışınızı tamamen korursunuz. Sugarbug mevcut araçlarınıza bağlanır ve üzerine bir sinyal izleme katmanı ekler – çalışma şeklinizi değiştirmenizi istemez, yalnızca çalışırken daha az şeyin kaçırılmasını sağlar.
"Bir şeyi mi unutuyorum?" şeklindeki alçak perdeli vızıltı kulağınıza tanıdık geliyorsa, tam da Sugarbug'ı geliştirdiğimiz sorun budur. Bekleme listesine katılın.