Yapay zeka uygulamaları için iş kurallarını sade bir dille belgeleyin

Belirsiz kurallar neden güvenilmez uygulamalar yaratır

İş kuralları bir uygulamaya gerçek durumlarda ne yapması gerektiğini söyler. Kim bir isteği onaylayabilir, toplam nasıl hesaplanır ve bir vaka alışılmış kalıpların dışına çıktığında ne olur gibi soruları yanıtlar.

Bu kurallar belirsizse, uygulama yine bir yol seçmek zorunda kalır. Sadece beklediğiniz yolu seçmeyebilir.

Örneğin "büyük harcamalar yönetici onayı gerektirir" gibi bir kural kulağa net gelebilir. Bir kişi için açık görünebilir, ama uygulamayı inşa eden için öyle değildir. Büyük nedir: 500$, 5.000$ mı yoksa takım bütçesinin üzeri mi? Hangi yönetici: doğrudan yönetici, departman başkanı mı yoksa finans mı? Eğer iki gün içinde kimse yanıt vermezse istek bekler mi, süresi dolar mı yoksa başka birine mi gider?

İşte bu yüzden belirsiz kurallar güvenilmez uygulamalara yol açar. İnşa eden kişi verilen talimatlar kadar tutarlı olabilir. Sözcüklerin tahminde bulunmaya yer bırakması, uygulamanın bugün bir şekilde, yarın biraz farklı davranmasına neden olur.

En büyük sorunlar genellikle birkaç alanda ortaya çıkar:

• yuvarlama, vergi, indirimler veya tarih aralıkları gibi ayrıntıları eksik hesaplamalar
• herkesin varsaydığı ama kimsenin yazmadığı istisnalar
• sahibinin, sırasının veya yedeğinin net olmadığı onay adımları

Basit bir örnek problemi gösterir. Bir kurucu Koder.ai'de dahili bir gider uygulaması oluşturur ve "Seyahat masraflarını olağandışı görünmedikçe geri öde" yazar. Bu kulağa makul geliyor, ama uygulamanın "olağandışı"yı güvenilir şekilde değerlendirme yolu yok. Bir çalışanın taksi masrafı onaylanır, benzer bir başkası işaretlenir ve kimse nedenini bilmez.

Güvenilir davranış, her seferinde aynı şekilde uygulanabilen kurallarla başlar. "Büyük", "acil" ve "özel durum" gibi sözcükler kesin limitler, koşullar ve eylemlerle değiştirilmeli. İki farklı kişi kuralı aynı şekilde uygularsa, uygulama da büyük olasılıkla aynı şekilde davranır.

Net bir iş kuralı nasıl görünür

Net bir iş kuralı tek bir kararı veya tek bir eylemi kapsar, tüm süreci değil. Bu çoğu ekip için beklenenden daha önemlidir. Bir kural onay, fiyatlandırma, istisnalar ve bildirimleri aynı anda kapsamaya çalıştığında, inşa eden hangi kısmın en önemli olduğunu tahmin etmek zorunda kalır.

İyi bir kural yüksek sesle okunması kolaydır. Ekip dışından biri iç kısaltmalarınızı bilmeden anlayabilmelidir. "Hızlı işleme", "standart durum" veya "yönetici onayı" gibi terimleri tam olarak ne olduğunu söyleyen sade ifadelerle değiştirin.

Çoğu net kural dört temel soruyu yanıtlar:

• Kararı kim veriyor veya eylemi kim yapıyor?
• Kural ne zaman uygulanır?
• Uygulamada ne değişir?
• Sonra ne olur?

Bu yapı kuralı gerçek davranışa bağlar. "Büyük siparişler gözden geçirilmeli" demek yerine "Bir sipariş 5.000$'ın üzerindeyse, gönderime gönderilmeden önce satış yöneticisinin onayı gerekir" yazın. Bir cümle, bir karar, bir sonuç.

Ayrıca ilgili kuralları ayrı tutmak faydalıdır. Onay kuralı kendi başına durmalı. E-posta gönderme kuralı ayrı olmalı. Sevkiyatı engelleme kuralı da ayrı olmalı. Bu, her kuralı test etmeyi, güncellemeyi ve düzeltmeyi kolaylaştırır.

Fark açıkça görülür:

"Premium müşteriler öncelikli işlem görür" belirsizdir.

"Müşteri premium plana sahipse, destek talebi oluşturulduğunda Yüksek Öncelik olarak işaretlenir" nettir.

İkinci versiyon tetikleyiciyi, koşulu ve uygulama içindeki değişikliği adlandırır. İnşa edene güvenilir davranışın nasıl görünmesi gerektiğini söyler.

Eğer sohbet tabanlı bir kurucu kullanıyorsanız, bu tür bir ifade büyük fark yaratır. Net kurallar yasal dile ihtiyaç duymaz. Basit kelimelere, tek seferde bir fikre ve tek cümlelik beklenen bir sonuca ihtiyaç duyarlar.

Hesaplamaları sade dille yazmak

Hesaplamalar genellikle basit görünür ta ki biri onları inşa etmeye çalışana kadar. En güvenli yaklaşım, uygulamanın tam olarak ne yapması gerektiğini söyleyen bir sade cümleyle başlamaktır.

İyi bir kural şöyle duyulur: "Geri ödeme tutarı onaylı mil x mil ücreti ile eşittir." Bu, "seyahat ödemesini hesapla" veya "standart geri ödemeyi uygula" demekten çok daha açıktır.

O ilk cümleden sonra, uygulamanın kullanacağı her girdiyi tanımlayın. İnşa edenin tahmin etmesine gerek kalmayacak kadar spesifik olun.

Her hesaplama için neyi tanımlamalısınız

Her hesaplama için şunları yazın:

• girdiler, basit isimler ve birimler ile
• her değerin nereden geldiği
• yuvarlama kuralları
• herhangi bir minimum veya maksimum değer
• bir değer eksikse ne olacağı

Küçük ayrıntılar önemlidir. "Nihai tutarı 2 ondalık basamağa yuvarla" her satırı önce yuvarlamaktan farklı bir sonuç verir. Bir sınır varsa, uygulamanın o sınırda durup durmayacağını veya bir uyarı gösterip göstermeyeceğini söyleyin.

Sade dille yazılmış bir kural şöyle olabilir: "Seyahat geri ödemesi onaylı mil x 0,67$ olarak hesaplanır. Nihai tutarı 2 ondalık basamağa yuvarlayın. Her yolculuk için maksimum geri ödeme 300$'dır. Eğer onaylı mil boşsa, tutarı hesaplamayın. Talebi eksik olarak işaretleyin ve kullanıcıdan mil bilgisini girmesini isteyin."

Sonra bir veya iki gerçek sayılı örnek ekleyin. Örnekler soyut formüllerden daha hızlı boşlukları ortaya çıkarır.

Örnek 1: "Onaylı mil 120 ise, geri ödeme 120 x 0,67$ = 80,40$. Bu 300$ sınırının altında olduğu için nihai tutar 80,40$ olur."

Örnek 2: "Onaylı mil 500 ise, geri ödeme 500 x 0,67$ = 335,00$. Maksimum 300$ olduğu için nihai tutar 300,00$ olur."

Bu stil insanların incelemesini kolaylaştırır ve inşa edenin uygulama davranışına dönüştürmesini kolaylaştırır.

İstisnaları karışıklık olmadan yakalamak

Çoğu uygulama ana kuralda başarısız olmaz. Kenar durumlarda başarısız olur.

Normal yol basit olabilir, ama gerçek işler son tarih sonrası iadeler, VIP müşteriler, eksik belgeler ve tek seferlik onaylar içerir. İstisnalar dışarıda bırakılırsa, uygulama boşluğu kendi doldurur ve tutarsız sonuçlar başlar.

İstisnaları yazmanın basit bir yolu kısa if-then kuralları kullanmaktır. Her birini tek bir koşul ve tek bir sonuç üzerine yoğunlaştırın.

• Eğer gider 100$'ın altındaysa, otomatik onayla.
• Eğer gider 100$'ın altındaysa ama 30 günden sonra gönderildiyse, elle inceleme gönder.
• Eğer çalışan yönetici ekibindeyse, 100$ sınırını atla ve finansmana yönlendir.
• Eğer bir finans yöneticisi talebi acil olarak işaretlerse, elle geçersiz kılma geçerli olur ve talep kuyruğun başına taşınır.

Bu format gizli mantığı görünür kılar. Ayrıca çakışmaları hata haline gelmeden önce görmeyi sağlar.

Aynı şekilde, iki kural çatıştığında hangisinin geçerli olduğunu söyleyin. Bir müşteri indirimden yararlanabilir ama sipariş aynı zamanda bir tatil kara liste dönemine denk gelebilir. Önceliği açıkça yazın: "Eğer bir tatil kara liste kuralı müşteri indirimiyle çelişiyorsa, kara liste kuralı geçerlidir."

Sınırlar konusunda kesin olun. Tarihler, kullanıcı tipleri, lokasyonlar, hesap durumu ve elle geçersiz kılmalar genellikle sonucu değiştirir. "Geç gönderimler onay gerektirir" demek yerine "Bir talep olaydan sonra 14 takvim gününden daha geç gönderildiyse, yönetici onayı gereklidir" yazın.

Ayrıca uygulamanın her istisnada kullanıcıya ne göstermesi gerektiğini söyleyin. İyi bir kural kararla bitmez. Aynı zamanda mesajı da tanımlar: örneğin "14 günden sonra gönderildi. Yönetici onayı gerekli" veya "Finans yöneticisi tarafından elle geçersiz kılma uygulandı."

İstisnalar bu şekilde yazıldığında, sıra dışı vakalar sıra dışı olmaktan çıkar. Normal, test edilebilir davranış haline gelirler.

Onay mantığını adım adım anlatmak

Onay mantığı bir dizi karar olarak yazıldığında en iyi çalışır; belirsiz bir politika olarak değil. Her adım beş soruyu yanıtlamalı: kim hareket ediyor, hangi tetikleyici inceleme başlatıyor, hangi sınırlar uygulanıyor, ne kadar süresi var ve karar verdikten sonra talep hangi duruma geçiyor.

Önce rolü adlandırın, sadece takımı değil. "Finans büyük talepleri inceler" demek yerine "Finans Müdürü 5.000$ üzerindeki herhangi bir talebi onaylayabilir, reddedebilir veya geri gönderebilir" yazın. Bu tahmini ortadan kaldırır ve davranışı inşa etmeyi kolaylaştırır.

Sonra her adım için tetikleyiciyi tanımlayın. Bir tetikleyici talebi bir sonraki kişiye gönderen koşuldur. Miktara, departmana, risk seviyesine, istek tipine veya bunların karışımına göre olabilir.

Örneğin:

• Talep 500$'ın altındaysa, takım lideri inceler.
• Talep 500$ ile 5.000$ arasındaysa, takım lider onayından sonra departman müdürü inceler.
• Talep 5.000$'ın üzerindeyse, departman müdürünün onayından sonra finans inceler.
• Talep yüksek risk olarak işaretlendiyse, nihai onaydan önce uyumluluk incelemelidir.

Eşik değerlerin tam sınırları olmalı. "Büyük" veya "hassas" demeyin. "5.000$'ın üzeri", "Satış departmanından" veya "risk puanı 8 veya daha yüksek" gibi net ifadeler kullanın. İki eşik aynı anda uygulanabiliyorsa, hangisinin kazandığını söyleyin. Örneğin: "Yüksek risk her zaman uyumluluğa gider, miktar düşük olsa bile."

Ayrıca bir zaman aşımı kuralı belirtmelisiniz. Eğer kimse yanıt vermezse, uygulama sonsuza dek beklememelidir. Belirli bir süreden sonra ne olacağını söyleyin, örneğin 48 saat veya 3 iş günü. Talep onaycının yöneticisine yükseltilebilir, yedek onaycıya atanabilir veya otomatik olarak iptal edilebilir.

Son olarak her karar sonrası durumu tanımlayın. Etiketleri kısa ve tutarlı tutun:

• Approved: istek ilerler veya tamamlanır.
• Rejected: istek kapanır ve başka işlem yapılmaz.
• Sent back: talep eden düzenleyip yeniden göndermelidir.
• Escalated: talep yedek veya daha üst düzey onaycıya gider.

Onay mantığı bu şekilde yazıldığında, inşa edenin tahmin etme alanı azalır ve iş akışı çok daha güvenilir olur.

Yeniden kullanabileceğiniz basit bir kural şablonu

Tutarlı davranış istiyorsanız, her kurala aynı şekli verin. Karışık yazım stilleri genellikle karışık sonuçlar oluşturur.

Basit bir format çoğu durum için iyi çalışır: tetikleyici, koşullar, eylem, sonuç. Bu hızlı yazmak için yeterince kısa ve bir başkası tarafından sonradan incelenmesi için yeterince nettir.

Bir kural, bir birim kullanın

Her kuralı kendi satırında, kartında veya bloğunda tutun. Bir paragrafta birkaç fikir sıkıştırmayın. Bir kural fiyatlandırma, onay ve istisnayı aynı anda kapsıyorsa, test etmesi zor ve yanlış okunması kolay olur.

Pratik bir şablon şöyle görünür:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

Her seferinde her alanı doldurmanıza gerek yok. Ama aynı sırayı korumak insanların kuralları hızlıca taramasına yardımcı olur.

Örnek:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

Örneğin kuralın altında durur, içinde değil. Bu kuralı temiz tutar. Örnek sadece kuralın nasıl davranması gerektiğini gösterir.

Varsayımları açıkça işaretleyin. "Varsayım" veya "Doğrulanması Gerekiyor" gibi küçük bir not, açık soruları inşa zamanından önce gözden geçirmeyi kolaylaştırır.

Ayrıca ifadelerinizi tutarlı tutun. Tetikleyicilere her zaman "When" ile, koşullara "If" ile ve eylemlere "Then" ile başlayın. Bu tür küçük kalıplar kafa karışıklığını azaltır, özellikle kurallar uygulama mantığına dönüştürülürken.

Kısa bir test işe yarar: birisi bu kuralı test edebiliyor mu ve başka biri yanlış anlayabilir mi? Eğer ilkine hayır veya ikincisine evet ise, ifadeyi sıkılaştırın.

Örnek: bir gider onay uygulaması

Bir çalışan gider uygulaması iyi bir test vakasıdır çünkü politika tanıdık ve kenar durumlar çabuk ortaya çıkar. Personel yemek, taksi, otel ve küçük müşteri masraflarını talep edebilir; ancak her talebin limitleri, istisnaları ve onay adımları vardır. Bu, sade dilin önemli olduğu süreçlerin tam da olduğu yerdir.

Örnek politika

Yemek kuralını şöyle yazın: çalışanlar normal iş günlerinde gündelik başına 40$'a kadar yemek masrafı talep edebilirler. Uygulama aynı tarih için tüm yemek fişlerini toplayıp toplamı günlük limite göre karşılaştırmalıdır; tek tek fişlere göre değil.

Çalışan Salı günü kahvaltı için 12$ ve öğle yemeği için 22$ harcadıysa, toplam 34$ olur ve talep geçer. Aynı güne 15$'lık bir akşam yemeği eklerse, toplam 49$ olur ve uygulama talebi limitin üstünde olarak işaretlemelidir.

Şimdi bir istisna ekleyin. Eğer yemek onaylı iş seyahati veya müşteri toplantısı sırasında gerçekleştiyse, günlük yemek limiti 75$'a çıkar. Bu istisna yalnızca çalışan "Seyahat günü = Evet" veya "Müşteri toplantısı = Evet" seçip müşteri adı veya gezi amacını içeren kısa bir not eklediğinde uygulanır.

Bu, "özel durumlara izin verilebilir" gibi belirsiz ifadelerden daha güvenilirdir çünkü istisna net koşullara bağlanmıştır.

Onay adımları

Onay mantığı aynı sadelikte kalabilir:

• 100$'ın altındaki talepler çalışanın yöneticisi tarafından onaylanır.
• 100$ ile 500$ arasındaki talepler önce yönetici, sonra finans onayı gerektirir.
• 500$'ın üzerindeki talepler yönetici, finans ve departman başkanı onayı gerektirir.
• "Seyahat" olarak işaretlenen herhangi bir talep, tutar 100$'ın altında olsa bile finans incelemesine ihtiyaç duyar.

Birkaç basit vaka ile kuralı test edebilirsiniz. Normal bir iş gününde 36$'lık yemek talebi, fişler ekliyse onaylanmalıdır. Seyahat gününde 60$'lık yemek talebi, seyahat işaretlenmiş ve not doldurulmuşsa geçmelidir. Normal bir günde 60$'lık yemek talebi reddedilmeli veya düzeltme için geri gönderilmelidir. 650$'lık bir otel talebi tüm üç onay adımından geçmelidir.

Amaç budur: birisi gerçek vakalarla test ettiğinde kural her seferinde aynı sonucu vermelidir.

Kötü sonuçlara yol açan yaygın hatalar

Bir kural bir kişiye net gelebilir ama inşa edeni şaşırtabilir. Bu genellikle belge belirsiz, birden fazla fikirle dolu veya satırdan satıra tutarsız olduğunda olur.

Yaygın bir hata birkaç kuralı tek bir uzun paragrafta sıkıştırmaktır. Örneğin: "Yöneticiler seyahati onaylar, toplam yüksekse finans fişleri kontrol eder ve acil istekler incelemeyi atlayabilir." Bu verimli görünse de birkaç ayrı kararı saklar. Her eylemin tek bir tetikleyicisi ve tek bir sonucu olacak şekilde ayrı kurallara bölün.

Başka bir problem bulanık dildir. Normal, büyük, acil veya yakın geçmiş gibi kelimeler yalnızca tanımlandıklarında işe yarar. Eğer "büyük gider" 2.000$'ın üzeri anlamına geliyorsa bunu söyleyin. "Acil" 24 saat içinde gerekliyse, o şartı yazın.

Eksik veri başka büyük bir sorun kaynağıdır. Ekipler genellikle mutlu yolu tarif edip bilgilerin eksik veya yanlış olduğu durumlarda ne olması gerektiğini unuturlar. Bir talepte tutar, departman veya fiş yoksa kuralın ne yapacağını söyleyin.

En çok sorun yaratan hatalar genellikle şunlardır:

• birkaç kuralı bir paragrafta birleştirmek
• boyut, zaman veya öncelik için tanımlanmamış terimler kullanmak
• hata durumlarını ve eksik alanları unutmamak
• nihai onay yetkisini belirsiz bırakmak
• aynı şey için farklı isimler kullanmak

Nihai yetki birçok ekip için beklenenden daha önemlidir. Bir yönetici ve bir finans inceleyicisi anlaşmazlığa düşerse, son sözü kim söylüyor? Eğer kimse nihai adımı sahiplenmiyorsa, uygulama takılabilir veya işleri döndürebilir.

Terim değişiklikleri daha sessiz hatalar yaratır. Başta "talep" diyip sonra "gönderim" veya "bilet" derseniz, okuyucular bunların farklı şeyler olduğunu varsayabilir. Bir terim seçin ve belge boyunca tutun.

Bu, sohbet tabanlı bir kurucuda daha da önemlidir; sade dil davranışı yönlendirir. Net kurallar resmi görünmek zorunda değildir. Spesifik, tutarlı ve eksiksiz olmaları gerekir.

İnşa etmeden önce hızlı kontrol listesi

Gereksinimleri ekranlara, akışlara veya istemlere dönüştürmeden önce son bir gözden geçirme yapın. Küçük bir kontrol şimdi tuhaf davranışları düzeltmede saatleri kurtarabilir.

Her kuralı test edilebilir hale getirin. Her kural net bir sonuçla bitmeli: evet veya hayır, onayla veya reddet, ücret uygula veya ücret uygulama gibi. Eğer iki kişi aynı cümleyi okuyup farklı cevaplar verebiliyorsa, kural üzerine çalışılmalı.

Her hesabı açıkça yazın. Girdileri, formülü ve hesabın ne zaman yapıldığını adlandırın. Yuvarlama, para birimi, tarih işleme ve bir değer eksik veya sıfırsa ne olacağını ekleyin.

İstisnaları ayrı tutun. Varsayılan kuralı önce yazın, sonra istisnaları kendi başlarına ekleyin. Ana harcama limiti, taşeronlar, acil satın almalar veya önceden onaylı seyahat için özel bir durumun içine gömülmemelidir.

Tam onay yolunu haritalandırın. Her eşik için kim onaylıyor ve sonra ne oluyor belirtin. Kenar durumlarda da kesin olun: bir kural 500$'ın üzerinde mi yoksa 500$ ve üzeri mi başlıyor söyleyin.

Sonra yeni bir ekip üyesi testini yapın. Kuralı o işi daha önce yapmamış birine verin ve kendi sözcükleriyle açıklamasını isteyin. Eğer ek bağlama ihtiyaç duyuyorlarsa, kural hala çok belirsizdir.

Küçük örnek neden önemli olduğunu gösterir. "Yönetici büyük harcamaları onaylar" açık görünür ama biri 500$'ın büyük olup olmadığını sorarsa sorun çıkar. "Yönetici 500$'ın üzerindeki harcamaları onaylar. Direktör 2.000$'ın üzerindeki harcamaları onaylar. 500$ veya daha düşük harcamalar otomatik onaylanır" demek hataya yer bırakmaz.

Kuralları çalışan bir uygulamaya dönüştürmek

Kurallar netleştiğinde, onları süreci her gün kullanan kişilerle gözden geçirin. Yöneticiler, koordinatörler, finans personeli ve onaycılar genellikle politika belgesine hiç girmeyen küçük ayrıntıları fark eder. Bu ayrıntılar genellikle bir uygulamayı akıcı veya sinir bozucu yapan şeylerdir.

Kural belgesini tek seferlik bir taslak değil, çalışma talimatı olarak ele alın. Ne olduğunu, kim karar verdiğini, istisnaların neler olduğunu ve bilgi eksik olduğunda uygulamanın ne yapacağını açıklamalıdır.

Tam uygulamayı inşa etmeden önce birkaç gerçek senaryo test edin. Hem temiz vakaları hem de karışık olanları kullanın: geçmesi gereken standart bir istek, eksik bilgi içeren bir istek, elle inceleme gerektiren bir istisna ve harcama limiti veya onay eşiğini aşan bir vaka.

Bu adım boşlukları erken yakalar. Bir kural kağıt üzerinde net görünebilir ama gerçek bir istek beklenmeyen bir şekilde uymadığında bozulabilir.

Bu senaryolar yeterli olduğunda, onları kurucunuza taşıyın. Eğer Koder.ai gibi bir sohbet tabanlı platform kullanıyorsanız, net bir kural seti inşa sürecini çok hızlandırır çünkü tanımlı bir süreci ekranlara, aksiyonlara ve onaylara dönüştürüyorsunuz; kararları anında vermek zorunda kalmıyorsunuz.

Başlatmadan sonra belgeyi doğruluk kaynağı olarak tutun. Bir politika değiştiğinde, yeni bir onaycı eklendiğinde veya bir limit güncellendiğinde önce belgeyi değiştirin, sonra uygulamayı. Bu gelecek düzenlemeleri basitleştirir ve farklı insanların kuralı farklı hatırlama ihtimalini azaltır.

Küçük bir alışkanlık yardımcı olur: süreç değiştiğinde kuralları gözden geçirin, yalnızca uygulama bozulduğunda değil. Erken yapılan küçük güncellemeler, kafa karışıklığını düzeltemeye çalışmaktan daha kolaydır.

Belge güncel kaldıkça, uygulama zaman içinde test etmesi, iyileştirmesi ve güvenilir olması daha kolay olur.