İş akışı durum etiketleri: Ekibinizin paylaşabileceği 7 net durum

Neden belirsiz durumlar işi yavaşlatır

Belirsiz iş akışı durum etiketleri, meşgul görünümlü ama verimsiz bir süreç yaratır. İnsanlar öğeleri ilerletir, ancak gerçekten neyin değiştiğinden kimse emin olmaz. “In Progress” olarak işaretlenen bir ticket, kişiye göre “Üzerinde düşünmeye başladım”, “Engellendim” veya “Tamamlandı ve inceleme bekliyor” anlamına gelebilir.

Bu uyumsuzluk üç öngörülebilir probleme yol açar: yeniden çalışma, kaçırılan devralmalar ve gürültülü bildirimler. Bir durum bir sonraki kişiye ne yapılacağını söylemiyorsa iş gidip gelir. Bir devralma belirsiz bir etiketin içinde gizlenmişse, birisi fark edene kadar bekler. Herkes durumları sadece aktivite “sinyali” vermek için güncelliyorsa, akış bulanıklaşır ve gerçek değişiklikler kolayca gözden kaçar.

Başka yaygın bir belirti de aynı etiketin farklı ekranlarda farklı kullanılmasıdır. Bir ekip üyesi “Ready”i incelemeye hazır anlamında kullanır. Diğeri “Ready”i başlamak için hazır anlamında kullanır. Bir yönetici panoyu kontrol ettiğinde ekibin bekleyip beklemediğini, çalışıp çalışmadığını ya da işin bitip bitmediğini anlayamaz.

Amaç her kenar durumu tanımlamak değil. Amaç normal yolu daha az durumla ve daha net anlamlarla açık hale getirmektir. Durumlar her yerde tutarlı olduğunda, el değişimleri daha hızlı olur ve “Bu gerçekten tamamlandı mı?” gibi sorular azalır.

Ekibiniz nereden başlayacağını bilmiyorsa, çoğu işi kapsayacak şekilde 5–7 durumu hedefleyin: yeni öğeler için bir, aktif çalışma için bir, bekleyen veya engellenmiş işler için bir, inceleme veya onay için bir ve tamamlanmış için bir. Temeller stabil olana kadar detay eklemeyin ve herkesin aynı anlamları kullandığından emin olun.

Bir durum etiketi ne anlama gelmeli (ve ne olmamalı)

Bir durum etiketi, bir sonraki adım hakkında paylaşılan bir sözdür. Birisi durumu değiştirdiğinde, herkes takip eden adımı bir takip sorusu sormadan tahmin edebilmelidir.

İyi iş akışı durum etiketleri, işin şu anki gerçeğini anlatır, birinin görüşünü değil. Etiket doğruysa, ekip öğenin ilerleyip ilerlemediğini, bekleyip beklemediğini veya engellenip engellenmediğini ve bir sonraki dokunan kişinin kim olması gerektiğini anlayabilir.

Durum, öncelik, atanan kişi, kategori veya ilerleme notu ile aynı şey değildir. Bu alanlar önemli olabilir, ancak bunları durumla karıştırmak durumu güvenilmez kılar.

Ayrıca “state” ile “stage”i ayırmak yardımcı olur. State şu anda doğru olan şeydir (örneğin, “müşteri yanıtını bekliyor”), stage öğenin süreçte nerede durduğudur (örneğin, “inceleme”). Birini harmanlayabilirsiniz, ama tek bir durum her ikisini de tanımlamaya çalıştığında genellikle belirsizleşir.

Kullanışlı bir durum şu üç şeyden birini tetiklemelidir:

• Bir sonraki sahip (kimin alacağı)
• Bir sonraki eylem (sonraki yapılacak)
• Bir bekleme koşulu (neyi beklediğiniz)

Hızlı bir gerçek kontrolü: küçük bir liste görünümünde biri etiketi okuyup hala ne yapacağını bilebiliyor mu? Cevap “duruma bağlı” ise, etiket muhtemelen başka bir yerde (örneğin öncelik kuralları veya atama) yapılması gereken bir kararı gizliyor.

Kaç durum kullanılmalı ve neden 5–7 işe yarar

Bir durum sistemi, işi bir bakışta okunur hale getirmeli. Çok fazla durum olduğunda insanlar gördüklerine güvenmeyi bırakır. Çok az olduğunda ise devralmaları yönetmek için gereken ayrıntıyı kaybedersiniz.

Çoğu ekip için 5–7 durum tatlı noktadır. Tek bir ekranda sığar, Kanban panosu veya basit liste görünümünde iyi çalışır ve günlük sorulara yanıt verecek kadar sinyal sağlar: neler engellenmiş, neler üzerinde çalışılıyor ve neler inceleme bekliyor.

Seti küçük tutmak ayrıca “durum avını” (12 seçenekten hangisinin en yakın olduğunu tahmin etme) azaltır, raporlamayı kolaylaştırır ve öncelik, sahip ve türü ayrı alanlar olarak tutmanızı zorunlu kılar.

İsimler değişebilir ve bu sorun değil. Bir ekip “In Progress” diyebilir, başka bir ekip “Doing” diyebilir. Değişmemesi gereken şey anlamdır. Eğer “In Review” bazen “QA bekliyor” anlamına gelip bazen “müşteri bekliyor” anlamına geliyorsa, panonuz gürültüye döner.

Anlamları tutarlı tutmak için tek bir gerçek kaynağı ayarlayın: her durumun ne anlama geldiğini ve bir öğenin ne zaman girip çıktığını tanımlayan kısa bir ekip dokümanı. İki dakikada okunacak kadar kısa tutun. Sonra bu aynı seti işi gösterdiğiniz her yerde kullanın.

Başlamak için basit 7 durumluk set

Zaman içinde net kalan iş akışı durum etiketleri istiyorsanız, şu anda kimin sahip olduğu, bir sonraki ne olduğu ve “tamam”ın ne olduğunu cevaplayan küçük bir setle başlayın.

Çoğu ekip için çok detaylanmadan işe yarayan basit 7 durumluk set:

Ana kural: tek başına “Waiting” kullanmayın. Bir şey takıldıysa, Blocked deyin ve notta bağımlılığı adlandırın (örneğin “Blocked: müşteri yanıtı” veya “Blocked: erişim sağlanması”).

Her durum için tanımlar (giriş ve çıkış kuralları ile)

Net iş akışı durum etiketleri, her birinin şu anda neyin doğru olduğunu cevapladığı zaman en iyi çalışır.

New

Ne doğru: öğe kaydedildi ama kimse henüz değerlendirmedi.

Ne doğru değil: öncelik, kapsam veya sahip kararlaştırılmış değil.

Giriş: bir talep gönderildi.

Çıkış: birisi onu okur ve Triaged'e taşır.

Örnek: “Bir destek temsilcisi bir ekran görüntüsüyle hata raporu kaydeder.”

Triaged

Ne doğru: ekip talebi yönlendirebilecek ve geçerli olduğunu doğrulayabilecek kadar anladı.

Ne doğru değil: başlamak için hazır.

Giriş: birisi temel bağlam ekler (özet, etki, etkilenen alan).

Çıkış: ya işe hazır hale getirilir (Ready) ya da kasıtlı olarak reddedilir (iş akışı dışında ele alınır, durum olarak değil).

Örnek: “PM bunu gerçek bir hata olarak işaretler ve yeniden üretme adımlarını not eder.”

Ready

Ne doğru: eksik bilgi olmadan başlanabilir.

Ne doğru değil: çalışma başladı.

Giriş: kabul kriterleri net ve bağımlılıklar yerinde.

Çıkış: bir kişi işe başlar ve ilk anlamlı değişikliği yapar (In Progress).

Örnek: “Form alanları ve doğrulama kuralları üzerinde anlaşılmıştır.”

In Progress

Ne doğru: aktif çalışma gerçekleşiyor.

Ne doğru değil: kuyruğa alınmış bekleme.

Giriş: birisi alır ve çalışmaya başlar.

Çıkış: kontrol edilecek seviyeye (In Review) gelir veya bir bağımlılıkla karşılaşıp Blocked olur.

Örnek: “Bir geliştirici yeni durum açılır menüsünü oluşturur ve mantığı kaydeder.”

In Review

Ne doğru: doğrulama yapılıyor (peer review, QA veya paydaş onayı).

Ne doğru değil: yeni özellikler eklenmeye devam ediyor.

Giriş: işi yapan kişi doğrulama için gönderir.

Çıkış: ekip kabul kriterlerini karşılayan bir onay alırsa Done olur veya geri bildirimle In Progress'e döner.

Örnek: “QA hem web hem mobilde çalıştığını doğrular.”

Blocked

Ne doğru: çalışma belirli, adlandırılmış bir bağımlılık nedeniyle devam edemiyor.

Ne doğru değil: öğe sadece daha düşük öncelikte.

Giriş: atanan kişi kendi başına çözemeyeceği bir bağımlılıkla karşılaşır.

Çıkış: bağımlılık kaldırılır ve çalışma devam eder (genellikle In Progress).

Örnek: “Blocked: üretim loglarına erişim bekleniyor.”

Done

Ne doğru: kabul kriterlerini karşılıyor ve dağıtıldı veya dağıtıma hazır.

Ne doğru değil: hâlâ inceleme, test veya takip gerektiriyor.

Giriş: inceleme geçer ve sürüm adımları tamamlanır (ekibinizin tanımına göre).

Çıkış: yok; yeniden açma açık bir gerekçeyle yeni bir döngü başlatır.

Örnek: “Düzeltme canlıda ve hata tekrar üretilemiyor.”

Adım adım: 60 dakikada durum sisteminizi oluşturun

Dağınık durumları bir odaklanmış toplantıda düzeltebilirsiniz. Amaç mükemmel model değil. Amaç, işin gerçekte nasıl ilerlediğiyle eşleşen ve tekrarlanabilir kurallara sahip ortak bir etiket setidir.

60 dakikalık çalışma oturumu (tek bir çıktı ile)

İşi etkileyen her rolden bir kişi getirin (istekçi, yapan, inceleyen, onaylayan). Mevcut panonuzu veya listenizi paylaşın.

Önce gerçek iş akışını haritalayın (ideal olanı değil). Tipik bir öğe seçin ve gerçekte neler olduğunu, bekleme süreleri dahil, izleyin. Adımları düz fiillerle yazın (“taslak”, “incele”, “onayla”). Bir adım yalnızca bazen oluyorsa, onu bir dal olarak not edin.

Sonra çoğaltmaları çıkarın ve belirsiz etiketleri yeniden adlandırın. Aynı şeyi ifade eden etiketleri birleştirin (“In Progress” vs “Doing”). Belirsiz olanları (“Pending”) eyleme dönük bir şeye çevirin (“Blocked: müşteri yanıtı”). Bir etiketi bir cümlede açıklayamıyorsanız, hazır değildir.

Ardından her durum için giriş ve çıkış kuralları ekleyin. Her durum için neyin doğru olması gerektiğini ve hangi koşulla çıkacağını yazın. Kısa tutun. Örnek: “In Review, iş teslim edildiğinde girer, geri bildirimler ele alınıp inceleyen onay verdiğinde çıkar.”

Bundan sonra her devralma için sahipleri seçin. Her durumun varsayılan bir sahibi olmalı (rol yeterli). Bu öğelerin takılmasını önler. Örnek: “In Review’daki öğeler, işi yapan kişi değil, inceleyen tarafından sahiplenilir.”

Son olarak 10 son öğede test edin ve ayarlayın. Son birkaç haftadan 10 bitmiş veya aktif öğe alın ve her birine o zamanki durumu atayın. Sık tartışıyorsanız etiketleriniz örtüşüyor demektir. Bir öğe yerleştirilemiyorsa, eksik bir durumunuz var veya iki fikri tek bir etikette karıştırıyorsunuz.

Toplantıdan sonra tanımları tek bir yerde yayınlayın ve etiketlerin insanların gördüğü her yerde aynı olduğundan emin olun.

Web ve mobil ekranlarda durumları tutarlı tutma

Bir durum webde bir anlam ifade edip mobilde hafifçe farklı anlama geliyorsa, insanlar ona güvenmeyi bırakır. Sohbette sormaya, detayları tekrar kontrol etmeye veya kendi “gerçek durumlarını” yorumlarda yaratmaya başlarlar. İş akışı durum etiketlerinin amacı ortak gerçekliktir, süs değil.

Durumu tek bir paylaşılan alan olarak düşünün ve tek bir gerçek kaynağı olsun. Aynı etiket her yerde aynı yazım, büyük-küçük harf ve anlamla görünmelidir: listeler, detay ekranları, bildirimler, dışa aktarımlar ve push mesajları.

Gerçek işe yarayan küçük ekran kuralları

Mobil ekranlar uzun isimleri ve zayıf görsel tasarımı cezalandırır. Masaüstünde iyi görünen bir durum, telefonda okunaksız bir rozet haline gelebilir.

• İsimleri kısa tutun (mümkünse 1–2 kelime).
• Renkleri tutarlı kullanın, ama asla sadece renge güvenmeyin.
• Hiçbir şey okunaksız parçalanmaya uğramasın diye en uzun etikete göre tasarlayın.
• Sıralamayı platformlar arasında tutarlı tutun.
• “In Progress” vs “Working” gibi neredeyse aynı etiketlerden kaçının. Birini seçin.

Yerleşim de önemlidir. Detay görünümünde durumu başlığın yakınında koyun ki açıklamayı okumadan önce görülsün. Liste görünümlerinde her zaman aynı konumda gösterin.

Erişilebilirlik temelleri herkese yardımcı olur. Renk bir ipucudur, mesajın kendisi değildir. Metin etiketi her zaman gösterilmeli ve basit bir simge (Done için onay işareti gibi) düşünülmelidir, böylece ekran okuyucu kullananlar veya renk görme sorunları olanlar bile anlamı hızlıca alır.

Durumların saptığı yaygın hatalar

Durumlar, “iş nerede” demekten çıkıp “insanların iş hakkında nasıl hissettiği” anlamına geldiğinde sürüklenir. Bu olduğunda panonuz meşgul görünür ama kimse ona güvenemez.

Yaygın nedenlerden biri her küçük adımı eşleyen çok fazla etikettir. Bir görev bir saatte üç kez hareket edebiliyorsa, insanlar güncellemeyi bırakır veya “yakın olanı” seçer. Her hareketin gerçek bir hazır olma veya sorumluluk değişimi olduğu küçük bir set en iyi sonucu verir.

Başka bir sapma noktası farklı boyutları tek bir alanda karıştırmaktır. Öncelik ve aciliyet önemlidir, ama ayrı alanlarda olmalıdır, durumda değil. “Urgent” bir durumsa, “In Review” ile yarışır ve raporlama anlamsızlaşır.

Şunlara dikkat edin:

• Net farkı olmayan birden çok “tamam gibi” etiket
• Tek seferlik kişisel etiketler (“Sam’i bekliyor”)
• “In Progress”in park yeri haline gelmesi
• Yazılı giriş ve çıkış kurallarının olmaması
• Yeni ekranların farklı durum adları veya sıralama göstermesi

Sapmayı önlemek için durum setinin bir sahibi olsun ve değişiklikleri nadir yapın. Değiştirdiğinizde neyin değiştiğini, nedenini ve neyin yerine geçtiğini yazın.

Örnek: bir talebin başlangıçtan tamamlanmaya geçişi

Bir müşteri destek yazar: “Mobilde sipariş geçmişi sayfası boş görünüm gösteriyor, oysa siparişlerim var.” Destek bu öğeyi ürün düzeltmesi olarak kaydeder ve sonra bir sürüme gider.

New: Destek ekran görüntüleri, cihaz bilgileri ve doğru görünmesi gereken durumu kaydeder.

Triaged: Ürün sahibi bunun gerçek bir hata olduğunu doğrular, nereye ait olduğunu seçer (mobil uygulama, backend değil) ve etkiyi netleştirir.

Ready: Yeniden üretme adımları doğrulanır ve kabul kriterleri nettir.

In Progress: Bir mühendis sorunu yeniden üretir, API veriyi döndürüyor ama ekranın yanlış filtrelediğini bulur ve düzeltmeye başlar.

Blocked: Mühendis, UI’nin eski hesaplarda eksik bir alana bağlı olduğunu keşfeder ve backend değişikliği gerektiğini görür. Öğeye net bir notla Blocked işareti konur: “Blocked: backend legacy alan eşlemesi gerekiyor.”

In Review: Bağımlılık çözüldükten sonra QA iOS ve Android'i kontrol eder ve gerçekten sipariş olmadığında boş durumun doğru çalıştığını doğrular.

Done: Düzeltme onaylanır ve yayımlanır (ya da sizin ekibiniz için sıradaki sürüm penceresine kuyruklanmışsa o şekilde sayılır). Destek bunun canlı olduğunu doğrular ve müşteriye yanıt verir.

Karışıklığı önleyen şeyler: “Blocked”in bir nedeni ve bir sonraki aksiyonu var ve sahiplik etrafta zıplamıyor. Herkes öğeyi açıp kimin sorumlu olduğunu anlayabiliyor.

Ekibi tutarlı tutmak için hızlı kontrol listesi

Panonuz karışık hissediyorsa, genellikle nedenini 10 dakikada bulabilirsiniz.

10 dakikalık pano taraması

Panoyu gezip şu işaretleri kontrol edin:

• Her durum “Şu anda ne doğru?” sorusuna cevap veriyor mu?
• Her durumun varsayılan bir sahibi (rol yeterli) ve net bir sonraki eylemi var mı?
• Aynı anda aynı öğeyi tanımlayabilecek iki durum yok mu?
• Öğeler karar noktası olmadan park edilmemiş mi (günlerce duruyorsa bir çıkış kuralı ekleyin)?
• Aynı iş tipleri aynı çekirdek adımlardan mı geçiyor, yazılı bir istisna yoksa?

Bir kartın nereye ait olduğu konusunda insanlar tartışıyorsa, o durum başka biriyle örtüşüyor veya yeterince tanımlı değil demektir.

Web + mobil tutarlılık kontrolü

Aynı iş akışını bir telefonda açın ve etiketlerin dar alanlarda da çalıştığını doğrulayın.

• Etiketler liste görünümlerinde kısa ve okunaklı (kesilme yok) olmalı
• Metin, renge güvenmeden açık olmalı
• Durum değişiklikleri bir sahip tarafından onaylanmalı (takım lideri veya operasyon gibi), kişiye göre değil
• Değişiklikler kısa bir notla birlikte yapılmalı ki tanımlar sürüklenmesin

Bir süreklilik planı: sürdürün, ölçün ve zamanla iyileştirin

Durum sistemleri, bir kural kitabı gibi ele alındığında faydalı kalır: sabit ama gözden geçirilen. Amaç sürekli değişiklik değil, tutarlı kullanımdır.

Hafif bir ritim belirleyin; örneğin panoya dokunan her rolden bir kişiyle aylık 30 dakikalık bir gözden geçirme. Son 5–10 öğeyi getirip düzeltilebilecek istisnaları arayın.

Takip etmeye değer birkaç basit sinyal:

• Blocked’te geçirilen süre (ve en sık neden)
• İki durum arasında zıplayan öğeler
• Normal çevrim süresini geçen ve dokunulmamış öğeler

Bir şey ters geliyorsa, hemen yeni bir durum eklemekten kaçının. Yeni durum yalnızca gerçekten farklı bir hal olduğunda, insanların bir sonraki adımını değiştiriyorsa ve sık oluyorsa eklenmelidir. Çoğu durumda çözüm daha basittir: tanımı sıkılaştırmak, bir giriş kuralı eklemek veya sahipliği netleştirmektir.

Eğer iş akışını dahili bir araca inşa ediyorsanız, durumları ekran metni olarak değil paylaşılan veri olarak ele alın. AppMaster (appmaster.io) içinde örneğin, durum alanını Data Designer'da bir kez tanımlayıp web ve native mobil uygulamalarda yeniden kullanabilirsiniz; bu, “telefonumda farklı anlam” sürüklenmesini önlemeye yardımcı olur.