Uygulama geliştirirken gerçek dünya istisnalarını yönetmek

Neden temiz akışlar gerçek hayatta başarısız olur

Temiz bir akış diyagramı iyi görünür çünkü insanların işleri doğru sırada, doğru verilerle ve doğru zamanda yapacağını varsayar. Gerçek iş nadiren böyle olur. Birisi bir formu geç gönderir, bir yönetici hastalandığı için yoktur, bir müşteri önemli bir detayı atlar veya bir ödemeye başlangıçta kimsenin bahsetmediği özel bir onay gerekir.

Bu yüzden bir uygulamanın ilk versiyonu demo sırasında bitmiş gibi hissedilebilir ve gerçek insanların kullanmaya başlamasından sonra bozulmaya başlar. Mutlu yol (happy path) çalışır. Günlük işler uzun süre mutlu yolda kalmaz.

En güvenli başlangıç noktası, düzenli görünen versiyonun eksik olduğunu varsaymaktır. Küçük bir detay eksik olduğunda basit bir istek hızla değişebilir. Bir alan eksik, bir müşteri sıradışı veya bir onay gecikmişse bütün süreç durabilir ve insanlar sonraki adımda ne yapacaklarını tahmin etmeye çalışır.

Yaygın hatalar genellikle basittir:

• Bir istek ilerler, sonra onaylayıcı müsait olmadığı için takılır.
• Bir kayıt kaydedilemez çünkü gerekli bir detay henüz bilinmiyor.
• Özel bir durum normal vaka gibi ele alınır ve sonra elle düzeltilmesi gerekir.

Bu, küçük bir rahatsızlıktan daha fazlasıdır. Tek bir tuhaf vaka arkadaki her şeyi tıkayabilir. Personel sohbet, hesap tablosu veya e-postada geçici çözümler kullanmaya başlar ve uygulama işlerin tek merkezi olmaktan çıkar.

Daha iyi bir hedef basit: kuralları yazmadan önce istisnaları toplayın. Veri eksik olduğunda, zamanlama bozulduğunda ve bir istek standart yolu takip etmediğinde ne olduğunu sorun. Bu dağınık örnekler yan ayrıntı değildir. Uygulamanızın gerçek hayatta işe yarayıp yaramayacağını belirleyen şeylerdir.

Öncelikle hangi istisnaları bulmalısınız

İlk yakalamanız gereken problemler nadir kenar durumlar değildir. Bunlar her hafta olan ve temiz iş akışını sessizce kıran karışık olaylardır. Daha güçlü bir ilk sürüm istiyorsanız, işin geciktiği, engellendiği veya sistemin karar veremediği için bir kişiye devredildiği yerleri arayın.

Geç onaylar genellikle listenin başındadır. Bir yönetici bir isteği son tarihten, bordro kapandıktan veya stok yeniden sipariş edildikten sonra onaylayabilir. Uygulamanın o an için bir kuralı olmalı. İsteği yeniden açmalı mı, yeni bir tane mi oluşturmalı, finansı mı bilgilendirmeli yoksa onayı zamanında gelmiş gibi mi göstermemeli?

Eksik veri başka yaygın bir engeldir. Bir form vergi kimliği, makbuz, teslim tarihi veya müşteri iletişimi olmadan gönderilebilir. Sonraki adım bu alana bağlıysa akış belirsiz bir hatayla başarısız olmamalıdır. Duraklamalı, neyin eksik olduğunu göstermeli ve düzeltmeyi kolaylaştırmalıdır.

Özel durumlar normal yolun sınırlarını gösterdiği için önemlidir. Belki çoğu iade basittir, ama belirli bir tutarın üzerindeki iadeler ekstra kanıt ister. Belki bir bölüm farklı bir onay kuralı izliyordur. Bu durumlar tüm uygulamayı yeniden yapmayı gerektirmez, ama net dallanmalar ister.

Faydalı bir ilk bakış dört deseni aramaktır: orijinal yolu takip etmek için çok geç gelen onaylar, bir sonraki adımı engelleyen eksik detaylar, farklı bir kural gerektiren sıradışı talepler ve sistemin durup bir kişiye sorması gereken anlar.

İnsan incelemesi bir başarısızlık değildir. Uygulama çelişkili veriler, politika istisnaları veya yüksek maliyetli bir eylem gördüğünde genellikle en güvenli seçimdir. Duraklatılmış bir inceleme kuyruğu sessiz bir hatadan genellikle daha iyidir.

Bu istisnaları erkenden bulursanız, ilk versiyon çok daha gerçek hissettirir ve çok daha az kırılgan olur.

Gerçek örnekleri nerede toplayacaksınız

Kötü bir istisnayı kaçırmanın en hızlı yolu yalnızca süreci tasarlayan yöneticiyi sormaktır. Gerçek problemler genellikle işi her gün yapan insanlarda yaşar. Hangi adımların atlandığını, hangi alanların sık boş kaldığını ve hangi onayların geç, sıradışı sırayla veya sistem dışında gerçekleştiğini onlar bilir.

Kısa konuşmalarla başlayın. İnsanlardan normal bir vakayı adım adım anlatmalarını isteyin, sonra işler karıştığında son sefer neler değiştiğini sorun. Süreç hakkında geniş görüşlerini sormayın. Gerçek hikayeler isteyin: ne oldu, ne eksikti, kim düzeltti ve elle ne yapmak zorunda kaldılar.

Eski işler de iyi bir kaynaktır. Geçmiş e-postalar, destek talepleri, sohbet mesajları ve devretme notları genellikle temiz bir akışın kırıldığı tam anı gösterir. Bu kayıtlar kullanışlıdır çünkü bir şey ters gittiğinde insanların kullandığı dili yakalar, süreç dokümanlarındaki cilalı versiyonu değil.

Ayrıca insanların yan araçlarını kontrol edin. Birisi istisnaları takip etmek için bir elektronik tablo, yapışkan not listesi veya özel belge tutuyorsa bu güçlü bir sinyaldir. Geçici çözümler bir sebeple vardır. Genellikle uygulamanızın ilk günden ihtiyaç duyacağı kuralları ortaya çıkarırlar.

İlk gözden geçirilecek en iyi kaynaklar genellikle gölge sistemlerdir: elektronik tablolar ve kişisel kontrol listeleri; eksik detaylar veya manuel onaylar için sorulan e-posta dizileri; acil düzeltmelerle ilgili sohbet konuşmaları; gecikmeler veya reddedilen girdilerden bahseden destek talepleri; ve yanlış giden son birkaç vaka ile tam zaman çizelgesi.

Son kaynak olduğundan daha önemli olabilir. Yeni başarısız vakalar eski özetlerden daha iyidir çünkü olayların tam zincirini gösterir. Onayın son tarihten sonra gelmesi, bir müşterinin gerekli dosyayı hiç göndermemesi veya kimsenin belgelememiş özel bir kural kullanması gibi kalıplar bulabilirsiniz.

Eğer ilk versiyonu sohbet tabanlı bir oluşturucuda taslaklıyorsanız, mantık üretmeden önce bu örnekleri toplayın. Karışık vakalar erken görünür olduğunda daha güvenli akışlar oluşturmak çok daha kolaydır.

Karışık hikayeleri uygulama mantığına nasıl dönüştürürsünüz

Bir teoriden değil bir gerçek vakadan başlayın. Bunu bir kişinin ekip arkadaşına anlatacağı şekilde yazın: ne yapmaya çalıştılar, ne ters gitti, kim devreye girdi ve nasıl sonuçlandı.

"İstek yönetici izindeyken takıldı, sonra finans eksik bir alanla daha sonra onayladı" gibi karışık bir hikaye düzenli bir akıştan daha faydalıdır. Nerede kırılmalar olduğunu gösterir.

Hikayeden kurala

Her vaka için dört gerçeği çıkarın: ne oldu, kim karar verdi, neden böyle karar verdiler ve uygulama bir sonraki adımda ne yapmalı.

Bu odaklanmayı davranışa çevirir, sadece ekranlara değil. Hedef ilk günden her garip durumu kapsamaya çalışmak değil; tekrar eden kalıpları tespit etmektir.

Birkaç hikayeniz olunca, benzer hissedenleri gruplayın. Basit kovalar genellikle kendi kendine görünür: geç onay, eksik bilgi, yanlış kişiye sorulmuş, yinelenen istek veya belirli bir limitin üzerinde özel onay gerektiren vakalar.

Sonra her kovayı işe yarayan en hafif kurala dönüştürün. Bu kural her zaman tam otomasyon gerektirmez. Bazen en iyi kural bir uyarı, bir duraklatma veya manuel bir inceleme adımıdır.

Örneğin, onaylayıcı izinliyse onay geciktiyse uygulama 24 saat sonra hatırlatma gönderebilir, 48 saat sonra yeniden atayabilir veya yedek onaylayıcıya yönlendirebilir. Önemli bir alan eksikse, en iyi seçenek sert bir hata yerine kaydedilebilen ve geri dönülebilen bir taslak olabilir. Bu süreç ilerlerken sorunu gizlemez.

Eğer Koder.ai gibi sohbet tabanlı bir araçla inşa ediyorsanız, düz dilde yazılmış vakalar çok yardımcı olur. Sisteme somut bir şey verirler, böylece ilk iş akışı temiz ama gerçekçi olmayan bir tahmine değil gerçek kararlara dayanır.

Gerçek vakalarla test edin

Mantığı kilitlemeden önce iki veya üç gerçek hikayeyi bunun üzerinden çalıştırın. Birkaç temel soru sorun. Akış gerçek vakayla aynı sonuca ulaşıyor mu? Bilgi eksik olduğunda güvenli bir şekilde mi başarısız oluyor? Durup bir insan sorması gerektiğini biliyor mu?

Cevap hayırsa, hemen karmaşıklık eklemeyin. Önce kuralı daha basit kelimelerle yeniden yazın. Açık kurallar genellikle kimsenin açıklayamayacağı zekice kurallardan daha iyi iş akışlarına yol açar.

Basit bir örnek: gider onayları

Temiz versiyonla başlayın. Bir çalışan müşteri ziyareti sonrası 42$ taksi masrafı gönderir. Tarihi, tutarı, proje adını ve makbuzu ekler. Yöneticisi bordro kesimine kadar onaylar ve finans bunu bir sonraki geri ödeme çalışmasına dahil eder.

Bu yol modellemek kolaydır ama işin tamamı değildir.

Şimdi ilk istisnayı ekleyin. Çalışan isteği zamanında gönderir, ama yönetici bordro kapandıktan bir gün sonra onaylar. Uygulama bunu sessizce ilerletmemeli ya da talebi reddetmemelidir.

Daha iyi bir yanıt, isteği "kesim sonrası onaylandı" gibi net bir duruma taşımaktır. Oradan uygulama ödemeyi bir sonraki bordro döngüsünde bekletebilir, çalışana yeni ödeme tarihini bildirebilir ve şirket politikası manuel ara ödemeye izin veriyorsa vakayı finansın incelemesine gönderebilir.

Bu, uygulamanın birden fazla tarihi saklaması gerektiği anlamına gelir. Giderin ne zaman gönderildiğini, ne zaman onaylandığını ve hangi kesimi kaçırdığını takip etmelidir.

Şimdi ikinci istisnayı ekleyin. Çalışan makbuzu unutur, bu yüzden yönetici yalnızca açıklamaya dayanarak isteği onaylar. İki gün sonra makbuz gelir.

Uygulama iyi inşa edilmişse vaka kaybolmaz veya baştan başlamaz. "Makbuz bekleniyor" bekletmesine girer, hatırlatma gönderir ve açık kalır. Makbuz daha sonra yüklendiğinde vaka yeniden açılır ve yalnızca hâlâ işlem gerektiren adıma gönderilir.

Böyle bir akış birkaç basit durumdan geçebilir: gönderildi, yönetici onayı bekleniyor, kesim sonrası onaylandı, eksik makbuz için beklemede ve finans incelemesi için yeniden açıldı.

İşte gerçek istisna yönetimi pratikte böyle görünür. Uygulama sadece evet veya hayır kararları vermez. Tutup bekletme, yönlendirme veya bir vakayı bağlamı, tarihleri ve sorumluluğu kaybetmeden yeniden açma kararları verir.

Eksik veriyi akışı bozmadan nasıl yönetin

Eksik bilgi normaldir, nadir bir kenar durumu değil. Uygulamanız her formun ilk seferde eksiksiz geleceğini varsayarsa, gerçek kullanıcılar bir boşlukla karşılaştıklarında akış tıkanacaktır. Daha iyi bir kural basit: yalnızca bir sonraki adım için gerekeni zorunlu kılın.

Adım adım planlayın. Uygulamanın şu an ne bilmesi gerektiğini ve neyin daha sonra bekleyebileceğini sorun. Bir gider talebi gönderilmeden önce tutar ve çalışan adı gibi bilgilere ihtiyaç duyabilir, ama nihai makbuz ödeme öncesi gerekmeyebilir. Bu, kontrolü düşürmeden işin ilerlemesini sağlar.

Eksik işleri görünür kılın

Kullanıcılar bazı detaylar eksikken ilerlemeyi kaydedebilmelidir. Yeniden açılabilen bir taslak, baştan başlamaya zorlayan bir formdan çok daha iyidir. Bu, eksik bilgi başkasına bağlıysa (yönetici, satıcı veya finans takımı gibi) daha da önemlidir.

Net durum etiketleri herkesin ne olduğunu anlamasına yardımcı olur. Kısa ve taraması kolay tutun: bilgi bekleniyor, belge eksikliği nedeniyle engellendi, inceleme gerekiyor, onaya hazır, güncelleme için geri gönderildi.

Bu etiketler aynı anda iki işi yapar. Geçerli durumu gösterir ve kullanıcının ne tür bir sorunu çözmesi gerektiğini söyler.

Her eksik öğenin bir sahibi de olmalıdır. Vergi kimliği eksikse bunu kim ekler? Makbuz belirsizse kim onu değiştirir? Onay notu yoksa kim sağlayabilir? Düzeltmeyi kimse sahiplenmezse kayıtlar limbo'da bekler.

Basit bir örnek bunu netleştirir. Bir çalışan otel makbuzu henüz gelmediği için seyahat giderini makbuz olmadan gönderirse uygulama yine de kaydetmeye ve "makbuz bekleniyor" gibi bir durumla gönderilmesine izin vermelidir. Finans geri kalanını inceleyebilir, çalışan neyin eksik olduğunu bilir ve isteğin sessiz bir hatada kaybolması engellenir.

Ne zaman otomatikleştirmeli, ne zaman bir insana sormalısınız

Otomasyon, aynı girdinin neredeyse her zaman aynı sonuca götürmesi gerektiğinde en iyi şekilde çalışır. Bir istek net bir kalıp izliyorsa ona bir kural verin. Cevap eksik bağlama, sıradışı zamanlama veya yargıya bağlıysa insanlara gönderin.

Bu ayrım önemlidir. İyi bir uygulama normal vakalarda hızlı ilerlemeli, belirsiz vakalarda yavaşlamalıdır. Yanlış otomatik karar kısa bir manuel incelemeden daha fazla iş yaratabilir.

Basit bir test yardımcı olur: Aynı veriye iki farklı ekip üyesi baksa aynı kararı verirler miydi? Eğer evet ise otomatikleştirin. Değilse, insanı dahil tutun.

Otomasyona iyi aday olanlar: gerekli tüm alanları doldurulmuş formlar, politika limitlerine uyan talepler, net son tarihleri olan tekrar eden eylemler ve her zaman aynı yolu izleyen onaylar.

Tahmin edilmemesi gereken bazı durumlar: anahtar detaylar eksik, istek normal kalıbı kırıyor, iki kural çelişiyor, maliyet veya risk yüksek veya birisi istisnayı açıklamalı.

Örneğin hedefi olmayan, acil bir tarihi olan ve olağan limitlerin üstünde bir maliyeti olan bir seyahat talebi düşünün. Uygulama akıllı olmaya çalışmamalıdır. Vakayı işaretlemeli, akışı duraklatmalı ve doğru kişiye yönlendirmelidir.

Aynı derecede önemli olarak, her istisnanın nedeni görünür tutulmalıdır. Uygulamanın neden durduğunu, hangi kuralın tetiklendiğini ve hangi bilginin eksik olduğunu gösterin. Bu, incelemeleri hızlandırır ve ekibi iş akışını daha sonra geliştirmeye yardımcı olur.

Kaçınılması gereken yaygın hatalar

Pek çok uygulama projesi mantık yazılmadan önce yanlış yola girer. Ekip temiz bir yolu çizer, insanların onu takip edeceğini varsayar ve haftalık olarak gerçekleşen tuhaf durumları görmezden gelir. Bu, basit iş akışlarının destek taleplerine, manuel düzeltmelere ve karışık kullanıcılara dönüşmesinin yoludur.

İlk hata yalnızca varsayımlarla tasarlamaktır. Onayların, eksik alanların veya istisnaların genellikle nasıl işlediğini tahmin ederseniz en önemli vakaları kaçırırsınız. Yönetici geç onay verir, müşteri kaydı yarım gelir veya bir ödeme olağandışı bir tutar nedeniyle ekstra inceleme ister.

Diğer bir hata birçok farklı durumu tek bir belirsiz kuralın içine saklamaktır. "Bir şey yanlış görünüyorsa yönetime gönder" gibi bir kural esnek gibi görünür ama yeni problemler yaratır. Yönetici kim? Ne yanlış sayılır? Eğer iki gün kimse cevap vermezse ne olur?

Ayrıca uygulama herkesi tamamen yeniden başlatmaya zorladığında kullanıcılar zarar görür. Bir belge eksikse veya bir onay adımı reddedildiyse insanlar her şeyi baştan girmek zorunda kalmamalıdır. Daha iyi bir akış ilerlemeyi kaydeder, sorunu netleştirir ve kullanıcının yalnızca engellenen kısmı düzeltmesine izin verir.

Diğer sorunlar gözden kaçması kolaydır çünkü ikincil gibi duyulurlar: zamanlama, sahiplenme ve geçmiş. Bunlar ikincil değildir. Bir onay son tarihten sonra gelirse uygulamanın kabul edip etmeyeceğini, yükseltip yükseltmeyeceğini veya isteği yeniden açıp açmayacağını bilmesi gerekir. Eğer bir vaka engellenirse birinin sonraki adımı sahiplenmesi gerekir. Durum değişirse insanlar kim değiştirdiğini ve nedenini görmelidir.

Denetleme geçmişi (audit history) basit nedenlerle önemlidir. İnsanlar bir değeri kimin değiştirdiğini, kim istisnayı onayladığını ve durumun ne zaman değiştiğini bilmelidir.

Mantık üretmeden önce kısa bir kontrol

Bir iş akışını kurala dönüştürmeden önce durun ve girdilerinizin gerçek işle uyuşup uymadığını kontrol edin. Temiz diyagramlar genellikle gecikmelere, karışıklığa veya sonraki manuel düzeltmelere yol açan tuhaf vakaları kaçırır.

Kısa bir gözden geçirme yardımcı olur:

• Tahminler değil gerçek örneklerle başlayın.
• Her istisnayı bir kısa cümleyle adlandırın.
• Engellenmiş vakalara kim sahip çıkar karar verin.
• Kullanıcılar eksik bilgiden nasıl kurtulacak kontrol edin.
• Baştan sona bir gerçekçi senaryoyu test edin.

Kısa bir test vakası genellikle zayıf mantığı açığa çıkarır. Bir tedarikçi adı olmadan gönderilen bir satın alma talebini ve sonra bölüm yöneticisinin geç onay vermesini hayal edin. Talep eden eksik alanı düzeltebilir mi? Uygulama isteği yeniden açmayı, devam etmeyi yoksa finansı incelemeye mi göndereceğini biliyor mu?

İşte mantık üretmeden önce istediğiniz ayrıntı düzeyi budur. Kısa, gerçek hikayeler daha güvenli ilk versiyonlara ve insanların uygulamayı kullanmaya başlamasından sonra daha az sürprize yol açar.

Daha güvenli bir ilk sürüm için sonraki adımlar

Küçük başlayın. Tüm işe değil bir iş akışına odaklanın. Sonra işi her gün yapan insanlardan beş gerçek istisna vakası toplayın: örneğin geç onay, eksik makbuz, izinli yönetici, yinelenen istek veya finansa ihtiyaç duyan bir vaka.

İlk versiyonu o dar iş akışı ve o beş vaka etrafında kurun. Kuralları okunması kolay tutun. Bir istek eksikse neyin eksik olduğunu gösterin. Onay geç geldiyse ne zaman hatırlatılacağını, ne zaman yükseltileceğini ve ne zaman duraklatılacağını karar verin. Bir vaka normal yolu takip etmiyorsa kimin incelemesi gerektiğini netleştirin.

Sonra bunu sürece dahil olan kişilerle test edin: isteği gönderen, ilk onaylayıcı, istisnaları düzelten kişi, yükseltmeleri alan yönetici ve son sonucu gören herkes.

Nerede durduklarını, tahmin ettiklerini veya yardım istediklerini izleyin. Bu anlar düzgün çalışan yerlerden daha çok önemlidir. Eğer üç kişi aynı adımda takılıyorsa kuralda veya ekranda değişiklik yapmanız gerekir.

Bir gider uygulaması, biri proje kodu olmadan taksi makbuzu gönderene veya aylık kesimi geçtikten sonra gönderilene kadar iyi çalışıyor gibi görünebilir. İlk versiyon her nadir vakayı çözmek zorunda değildir. Yaygın istisnaları yakalamalı, bir sonraki adımı açıklamalı ve insan incelemesi için net bir yol bırakmalıdır.

Sonra kuralları küçük turlarla ayarlayın. Karışıklık yaratan adımları kaldırın. Tekrar eden problemleri önlemediği sürece alan eklemeyin. Hatırlatmalar çok erken veya çok geçse onay zamanlamasını değiştirin. Gerçek testten sonra yapılan küçük düzenlemeler genellikle karmaşık özel durum mantığı eklemekten daha iyidir.

Hızlıca prototiplemek isterseniz, Koder.ai gibi sohbet tabanlı bir oluşturucu bu gerçek örnekleri adım adım çalışan bir uygulamaya dönüştürmenize yardımcı olabilir. Anahtar yine aynı: önce karışık hikayelerle başlayın, sonra kuralları onların etrafında inşa edin.