Tetikleyiciler, koşullar, eylemler ve sahipleriyle iş kurallarını belgelemenin basit bir yolunu öğrenin; böylece insanlar katılıp ayrıldığında iş akışları net kalır.
İş kuralları nadiren bir anda yok olur. Bir kişi ayrıldığında bağlamla birlikte kaybolduklarında yavaş yavaş solarlar.
Bir destek sorumlusu hangi iade taleplerinin yönetici onayı gerektirdiğini bilir. Bir operasyon yöneticisi belirli bir bölgeden gelen siparişlerin sevk öncesi incelenmesi gerektiğini bilir. Bir ürün sahibi, bir müşteri hesabının neden iki değil üç başarısız belge kontrolünden sonra kilitlendiğini bilir. Bu kişiler olduğu sürece risk düşük görünür çünkü herkes onlara sorabilir.
Sorun devrin olduğu zamanda başlar. Yeni ekip üyeleri genellikle uygulamaya erişim, birkaç not ve kısa bir gösterim alır. Nerelere tıklanacağını öğrenirler, ama bir kuralın neden var olduğunu, ne zaman uygulanacağını veya kimlerin değiştirebileceğini öğrenmezler. Aktarılan süreç yüzeyidir; altında yatan mantık değil.
İyi niyet olsa bile devrin neden başarısız olduğunun açıklaması budur. İnsanlar "isteği onayla" veya "incelemeye taşı" gibi adımları anlatır, ama bu adımların arkasındaki gizli kararları atlar. Yeni bir ekip üyesi mutlu yolu bir kez izleyebilir, ama durum değişince takılır.
Kurallar ayrıca aynı anda çok fazla yerde yaşadıkları için kaybolur: bir kişinin belleğinde, sohbet dizilerinde, eski ticket'larda, tabloların notlarında ve uygulama ayarlarında ya da iş akışı oluşturucularda. Mantık varsayıldığında yazılmadığında, uygulama güvenilir hissettirmeyi bırakır. Bir buton bir kullanıcı için çalışır ama bir başkası için çalışmaz. Bir durum otomatik değişir ama tetikleyeni kimse bilmez. Bir form bir isteği engeller diğerini izin verir, oysa görünüşte aynı olabilirler.
Bu, iş akışlarının değiştiği uygulamalarda yaygındır. AppMaster gibi görsel bir platformda ekipler mantığı hızla kurabilir; bu faydalıdır. Ama hız yalnızca her eylemin arkasındaki kural da açıkça yazılıysa işe yarar. Aksi halde iş akışı uygulamada kalır, anlamı ise birinin zihninde kalır.
Çözüm devasa bir el kitabı değil. Her seferinde yeniden kullanılabilecek basit bir formattır. Her kural aynı şekilde kaydedildiğinde, gözden geçirmek, güncellemek ve devretmek tahmin gerektirmez.
Bir iş kuralı, onu oluşturmayan birinin anlayabileceği şekilde olmalıdır. Yeni bir ekip üyesi altı ay sonra açtığında dört temel soruyu cevaplayabilmelidir: kuralı ne başlatır, hangi koşullar sağlanmalı, sonra ne olur ve kimin sorumluluğunda?
Bu parçalardan biri eksik olsa insanlar tahmin etmeye başlar. Tahmin etmek atlanan adımlara, tutarsız kararlara ve uygulamanın kim son değiştirdiyse ona göre davranmasına yol açar.
Açık bir kural genellikle beş parçaya ihtiyaç duyar:
Tetikleyiciyi belirsiz bir an yerine gerçek bir olay olarak yazın. "Bir sipariş sevk edildiğinde" nettir. "Sevk edildikten sonra" değildir.
Koşulları bir başkasının takip test edebileceği şekilde yazın. "Fatura 7 gün geciktiğinde" işe yarar. "Fatura gecikti" işe yaramaz. Aynı kural eylemler için de geçerlidir. "Hatırlatma e-postası gönder ve durumu Takip Gerekiyor olarak değiştir" "ekibi bilgilendir" demekten çok daha iyidir.
Sahip önemlidir çünkü kurallar hızla eskir. Bir indirim onayı kuralı Satış Operasyonları'na ait olabilir. Bir iade kuralı Destek veya Finans'a ait olabilir. Sahip belirtilmediğinde, eski mantık uygulamada kalır çünkü kimse düzeltmekle sorumlu hissetmez.
İstisnalar genellikle unutulan parçadır ve sonradan en çok karışıklığa neden olur. "Müşterinin aktif bir itirazı varsa hatırlatma gönderme" gibi tek cümleli bir not birçok hatayı önleyebilir.
İyi bir kural formatı hızlıca bir soruyu cevaplamalı: ne oluyor, ne zaman ve kim sorumlu?
Bunun en kolay yolu her kuralı ayrı bir sayfa, kart veya veritabanı kaydında tutmaktır. Basit gibi görünür ama önemlidir. Birden fazla kural tek bir belgede karıştığında küçük istisnalar gömülür ve sahiplik belirsizleşir.
Her kurala kısa bir ad ve tek satırlık bir amaçla başlayın. Ad olayın kendisini tanımlamalı, iç jargon değil. "Faturayı vadesi geçmiş olarak işaretle" "AR durum mantığı 3B"den daha nettir. Amaç kuralın neden var olduğunu açıklar; örneğin "ödemeler geciktiğinde finansı uyarmak için".
Her seferinde aynı sırayı kullanın:
Bu sıra insanların düşünme biçimini takip ettiği için işe yarar. İlk önce kuralı ne başlatır. Ardından hangi koşullar sağlanmalı. Sonra uygulamanın ne yapması gerektiği. Son olarak kuralın hâlâ doğru olup olmadığını kimin karar vereceği.
Her alanı kısa tutun. Bir tetikleyici genellikle "müşteri bir form gönderdi" veya "fatura vade tarihine ulaştı" gibi tek bir olaydır. Koşullar "tutar $500'ın üzerinde" veya "müşteri hesabı aktif" gibi basit kontrollerdir. Eylemler görünür sonuçlardır: mesaj gönderme, durum değiştirme, görev oluşturma veya bir isteği engelleme.
Sahip alanını atlamayın. Sahip yalnızca kuralı sisteme yazan kişi değildir. Kuralın iş ile uyumlu kalıp kalmadığına karar veren roldür.
Ayrıca istisnalar, tarihler ve versiyon notları için alan bırakın; ilk bakışta gereksiz görünseler bile. Kurallar değişir. Birisi neden bir koşul eklendiğini, bir eşik neden değiştirildiğini veya eski bir istisnanın hâlâ geçerli olup olmadığını soracaktır. "v2: politika güncellemesi sonrası limit $250'den $500'e yükseltildi" gibi kısa bir not saatler kazandırabilir.
Ekibiniz AppMaster kullanıyorsa ve iş akışı ağırlıklı uygulamalar inşa ediyorsa, bu format görsel mantığa güzelce uyar. Yazılı kural tetikleyici, karar ve eylem akışının yanında durabilir; böylece uygulama davranışı ile işin anlamı uyumlu kalır.
Küçük başlayın. Tüm sistemle başlamayın. "Yeni bir sipariş ödenmemiş olarak işaretlendi" veya "bir destek kaydı kapatıldı" gibi tek bir olay seçin. Tek bir olay kuralı daha okunabilir ve sonra güncellemesi daha kolay yapar.
Sonra tetikleyiciyi tek, düz bir cümle olarak yazın. İyi tetikleyiciler kuralın tam olarak ne zaman başladığını anlatır: "Müşteri iade talebi gönderdiğinde." "Gerekirse" veya "uygun olduğunda" gibi belirsiz ifadelerden kaçının. İki kişi cümleyi okuyup farklı anlar hayal edebiliyorsa yeniden yazın.
Sonra koşulları evet-hayır kontrollerine çevirin. Bu kuralı test edilebilir yapar. "Yüksek değerli müşteriler için" demek yerine "Müşteri öncelikli destek planında mı?" veya "Sipariş tutarı $500'ın üzerinde mi?" gibi yazın. Net kontroller tartışmayı ortadan kaldırır.
Ardından eylemi kesin kelimelerle tanımlayın. "1 saat içinde ödeme hatırlatma e-postası gönder" nettir. "Hızlıca takip et" değil. Eylem veriyi değiştiriyorsa alanın adını yazın. Mesaj gönderecekse kim alacağını söyleyin. Görev oluşturuyorsa nerede görüneceğini belirtin.
Sahibi rol ile adlandırın, kişinin ismiyle değil. İnsanlar ayrılır, pozisyon değiştirir veya birbirlerinin yerine bakar. "Destek yöneticisi" "Emma"dan daha uzun ömürlüdür. Bir rol kuralı onaylayıp başka bir rol uyguluyorsa, her ikisini de yazın.
Kaydetmeden önce bir başkasına soğuk bir şekilde okutun. Üç soruyu ekstra bağlam istemeden cevaplayabilmeliler: Bu neyi başlatır? Hangi koşullar sağlanmalı? Sonra ne olur? Tereddüt ederlerse kural hâlâ eksik demektir.
Müşteri desteği iyi bir test vakasıdır çünkü süreç sık değişir ve küçük hatalar gerçek etkiler yaratır. Notlar belirsizse, bir sonraki kişi aynı ticket'ı tamamen farklı şekilde ele alabilir.
Varsayalım ajanların gelen talepleri triage ettiği bir destek uygulamanız var. Paylaşılan bir kural, normal kuyruğun dışında daha hızlı ilgi gerektiren acil ticket'ları kapsıyor.
Kural adı: Yüksek değerli hesaplar için acil ticket eskalasyonu
Tetikleyici: Bir destek temsilcisi bir ticket'ı Acil olarak işaretlediğinde.
Koşullar: Müşteri Premium veya Enterprise planda veya ticket ilk yanıttan 30 dakikadan fazla bekliyorsa.
Eylemler: Uygulama nöbetçi destek sorumlusuna bildirim gönderir, ticket'ı eskalasyon kuyruğuna atar ve durumu Eskalasyona Alındı olarak günceller.
Sahip: Müşteri Destek Operasyonları Müdürü.
İstisna: Ticket zaten aktif bir kesinti üzerinde çalışan bir mühendise atanmışsa, uygulama yeniden atama yapmaz. Mevcut atamayı korur, destek sorumlusuna iç not ekler ve durumu İşlemde olarak bırakır.
Gerçek bir vaka hayal edin. Enterprise plandaki bir müşteri, parola politikası değişikliğinden sonra kullanıcıların giriş yapamadığını bildiriyor. Temsilci ticket'ı Acil olarak işaretliyor. Hesap türü kural ile eşleştiği için uygulama hemen eskalasyon yapar; ilk yanıt zamanlayıcısı 30 dakikaya ulaşmamış olsa bile.
Başka bir vaka istisnanın neden önemli olduğunu gösterir. Bilinen bir kesinti sırasında acil bir ticket gelir ve bir mühendis zaten üzerinde çalışıyordur. İstisna olmasaydı ticket yeni bir kuyruğa gidip herkesi karıştırabilirdi. İstisna yazılı olduğu için sahiplik net kalır ve destek sorumlusu yine uyarılır.
Basit bir kural formatının gerçek değeri budur. Yeni bir ajan kuralı açıp neyin kuralı başlattığını, hangi koşulların gerektiğini, uygulamanın ne yapacağını ve kural değişirse son kararı kimin vereceğini görebilir.
Karışıklık genellikle yazıldığında açık görünen bir kural ile başlar. Bir ay sonra yeni bir ekip üyesi okur ve ne anlama geldiğini, ne zaman uygulanacağını ve kimlerin değiştirebileceğini tahmin etmek zorunda kalır.
Belirsiz ifadeler en büyük sorunlardan biridir. "Yakında", "büyük", "yüksek risk" veya "önemli" gibi kelimeler iki kişi farklı tanımlayınca netliğini yitirir. "Büyük siparişleri yakında gözden geçir" kullanılabilir bir kural değildir. "Herhangi bir $5.000 üzeri siparişi 2 iş saati içinde incele" kullanılabilir bir kuraldır.
Bir diğer yaygın hata politika ile uygulama davranışını aynı cümlede karıştırmaktır. Politika amacı açıklar. Kural uygulamanın ne yapacağını açıklar. İkisi bir arada olduğunda okuyucu gerçek davranışı kaçırır.
Örneğin, "VIP müşteriler ekstra özen görmeli, bu yüzden şüpheli iadeler finansa gider" çok fazla yoruma açık bırakır. Politikayı ayrı tutup kuralı şöyle yazmak daha nettir: "Eğer müşteri seviye = VIP ve iade sahtekârlık incelemesine işaretliyse, vaka Finans'a ata."
Şu uyarı işaretlerine dikkat edin:
Bunu önlemenin basit bir yolu kuralları teker teker belgelemektir. Her kurala kendi kaydını verin; birkaç kural aynı iş akışına ait olsa bile. Bu güncellemeleri daha güvenli ve testleri daha kolay yapar.
Ayrıca istisnaları yoğun metinden çıkarıp net şekilde yazmak yardımcı olur. Bir iade kuralının üç istisnası varsa, bu üç istisnayı listeleyin; tek uzun paragrafta saklamayın.
Bu, iş akışları değişen uygulamalarda daha da önemlidir. Görsel oluşturucular mantığı güncellemeyi kolaylaştırır ama yazılı kural akış kadar net olmalı. Kural kaydı belirsizse uygulama bir şekilde çalışırken ekip başka şekilde bekleyebilir.
Bir kuralı tamamlandı olarak işaretlemeden önce yeni bir ekip üyesi gibi okuyun. Birisi gelecek hafta katılsa, alanın ne anlama geldiğini, ne zaman başladığını veya sonucu kimin onayladığını sormadan kuralı takip edebilir mi?
İyi bir kural okunması kolay değil, doğrulanması kolay olmalıdır. Eğer bir koşul "büyük sipariş" veya "etkin olmayan müşteri" diyorsa, bunun uygulamada tam olarak ne anlama geldiğini tanımlayın. Test edilebilir ifadeler tahminleri ortadan kaldırır ve devri kolaylaştırır.
Her seferinde şu kısa kontrol listesini kullanın:
Alan adları insanların düşündüğünden daha önemli. Eğer belgede "müşteri durumu" yazıyorsa ama uygulamadaki alan adı gerçekte "account_state" ise insanlar varsayımlarda bulunmaya başlar. Sistemdeki kesin etiketleri kullanın.
Sahiplik de kısa bir gerçeklik kontrolüne ihtiyaç duyar. Eski bir yöneticinin adı yazılıysa genellikle hiç sahip yokmuş gibi davranılır. Ekip veya rol adlandırması daha mantıklı ise rolü yazın, ama güncel bir kişinin güncellemelerden sorumlu olduğundan emin olun.
İnceleme tarihi tazelik testinizdir. En net format bile kuralların geçen ay mı yoksa üç yıl önce mi kontrol edildiği bilinmezse güvenilmez olur.
Son bir test isterseniz kuralı sürecin dışında birine verin ve onların düz Türkçe olarak geri anlatmasını isteyin. Tereddüt ederlerse bir düzenleme daha gerekir.
Tüm işteki kurallarla başlamayın. En çok değişen iş akışıyla başlayın. Genellikle devrin, politika güncellemesinin veya uygulama değişikliğinin ardından karışıklığın ilk ortaya çıktığı yer orasıdır.
Sipariş onayları, iade talepleri veya lead yönlendirme gibi gerçek etkisi olan bir süreç seçin. Yoğun bir iş akışını iyi belgelerseniz, gerisi kolaylaşır.
Kurallar bir değişiklik sonrası güncellenmediğinde bayatlar. Çözüm basittir: süreç değiştiğinde, uygulama değiştiğinde veya sahiplik değiştiğinde kural kaydını gözden geçirin.
Büyük temizlik projelerinden ziyade küçük alışkanlıklar daha etkilidir. Birisi bir formu düzenlediğinde, bir durumu değiştirdiğinde, bir onay adımı eklediğinde veya bir koşulu güncellediğinde ilgili kural da aynı anda kontrol edilmelidir.
Pratik bir rutin şöyle görünebilir:
Kuralları nerede sakladığınız önemlidir. Ekip paylaşılan bir çalışma alanında, proje aracında veya uygulama spesifikasyonunda çalışıyorsa kuralları orada tutun; kimsenin açmadığı ayrı bir klasörde saklamayın. İyi iş akışı dokümantasyonu, birisi gerçekten ihtiyaç duyduğunda kolay bulunur.
Basit bir örnek: destek liderleri iade limitini $100'den $150'ye değiştirdiyse, güncelleme aynı anda iki yerde olmalı - uygulama mantığında ve kural kaydında. Sadece bir yerde güncelleme olursa ekip tahmin etmeye başlar.
Süreç ağırlıklı uygulamalar inşa ediyorsanız, mantığın kolay görülmesi yardımcı olur. AppMaster bunun bir örneğidir: ekipler backend, web ve mobil uygulama davranışını görsel olarak oluşturabilir; bu süreç değiştiğinde tetikleyicileri, koşulları ve eylemleri izlemeyi kolaylaştırır. Yine de yazılı kural önemlidir çünkü akışın arkasındaki nedeni açıklar, sadece akışı değil.
Amaç mükemmel dokümantasyon değil; güncel dokümantasyondur. Bir kural net, kolay bulunur ve iş değiştikçe gözden geçirilirse, onu devralan bir sonraki kişiye mantıklı gelmeye devam eder.
10 Mar 2026
8 dk
08 Mar 20269 dk
07 Mar 20267 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
