Blog
Pilot tek ekipte çalıştı, otuzda çöküyor
Kısaca: Pilot bir ekipte çalıştı diye ikincisinde çalışmaz. Pilotu taşıyan şey genelde model değil, o ekibin koşullarıdır: gönüllü kullanıcılar, yakın destek, tanıdık girdiler. Yaygınlaştırma kararı vermeden önce pilot ekip ile hedef ekipler arasındaki farkları yazın. O listede üçten fazla fark varsa elinizde yaygınlaştırma değil, yeni bir pilot var.
Pilot iyi geçti. Kullanıcılar memnun, sayılar tutuyor, yönetim onay verdi. Karar net görünüyor: aynı kurulumu diğer birimlere açın.
Sonraki altı haftada iş beklenmedik bir yerden tıkanır. Model aynı, prompt aynı, ekran aynı. Ama ikinci birimde kimse kullanmıyor, üçüncüsünde çıktı yanlış geliyor.
Bu bir model sorunu değil. Pilotun neyin üzerinde durduğunu hiç yazmamış olmanın sonucu.
Yaygınlaştırma kurumda genelde bir tarih olarak konuşulur: hangi ay kaç birim açılacak. Oysa yaygınlaştırma bir tarih değil, bir karşılaştırmadır. Pilotun çalıştığı koşulları hedef birimin koşullarıyla yan yana koymadan verilen her tarih tahmindir.
Pilotu taşıyan şey genelde model değildi
Pilot ekipler kurumun ortalaması değildir. Seçilme sebepleri zaten onları avantajlı kılıyordu.
Pilot ekipte kullanıcılar genelde gönüllüydü. İşin neden denendiğini biliyorlardı, ilk hatada vazgeçmediler. Soru sorabilecekleri bir kişi vardı ve o kişi birkaç saat içinde cevap veriyordu. Girdiler tanıdıktı: aynı şablon, aynı dosya düzeni, aynı terimler.
Bu dört koşul çıkınca aynı kurulum aynı kurulum olmaktan çıkar. İkinci birimdeki kullanıcı gönüllü değil, kendisine söylenmiş. Destek hattının cevap süresi bir gün. Dosyalar farklı formatta geliyor ve yarısında alan boş.
Yaygınlaştırmanın ilk işi modeli taşımak değil, bu koşullardan hangilerini taşıyabileceğinize karar vermek.
Yaygınlaştırmadan önce farklar listesini çıkarın
İkinci dalgayı planlarken çoğu kurum kullanıcı sayısını konuşur. Yanlış sayı. Konuşulması gereken şey farkların sayısı.
Pilot ekip ile hedef ekipler arasındaki her fark, kurulumda bir değişiklik demektir. Üç fark yönetilebilir. On fark yeni bir projedir ve öyle adlandırılmalıdır.
Bu ayrımın pratik faydası bütçede görünür. Yaygınlaştırma kalemi genelde lisans ve eğitim olarak yazılır, oysa paranın büyük kısmı farkları kapatmaya gider: format dönüştürme, eksik alanı tamamlama, yeni onay adımı ekleme. Farkları saymazsanız bu işler bütçede hiç görünmez, takvimde gecikme olarak görünür.
Bir yapay zeka kurulumunu pilot ekipten diger birimlere
yayginlastirmayi planliyorum.
Pilot ekip: [ekip adi, kisi sayisi, yaptigi is]
Pilotta kullanilan girdiler: [dosya/veri turleri, nereden geliyor]
Pilottaki destek: [kim destek verdi, ne kadar hizli]
Hedef birimler: [birim adlari, kisi sayilari, yaptiklari is]
Bana pilot ekip ile her hedef birim arasindaki farklari cikar.
Su dort baslikta grupla:
1. Kullanici farki (gonulluluk, deneyim, dil)
2. Girdi farki (format, kalite, kaynak, hacim)
3. Surec farki (isin adimlari, onay noktalari, hiz beklentisi)
4. Destek farki (kim bakacak, ne kadar hizli)
Her fark icin kurulumda ne degismesi gerektigini yaz.
Sonuna, 3 farktan fazla cikan birimleri ayri bir liste yap
ve neden ayri ele alinmasi gerektigini tek cumleyle belirt.
Tahmin yurutme; verdigim bilgi yetmiyorsa eksik alani sor.Bu prompt yol haritası üretmez, elemeyi yapar. Çıktıdaki ikinci liste en değerli kısımdır: aynı anda açılmaması gereken birimleri gösterir. Son satır, modelin hedef birimler hakkında bilmediği şeyi uydurmasını engeller.
Girdi çeşitliliği ilk kırılan yerdir
Pilot girdileri dar bir kümeden gelir. Yaygınlaştırmada o küme genişler ve genelde kimse ne kadar genişlediğini bilmez.
İkinci dalgayı açmadan önce hedef birimlerden gerçek örnek toplayın. Tahmini örnek değil, geçen ay gelmiş olanı. Yirmi örnek çoğu zaman yeter; ihtiyacınız olan şey ortalama değil, sınırlardır.
Bir yapay zeka kurulumunu yeni birimlere acacagim.
Pilotta kullanilan girdi: [format, alanlar, kaynak]
Hedef birimlerden topladigim ornekler: [ornekleri buraya yapistir]
Bu ornekleri pilottaki girdiyle karsilastir:
- hangi alanlar eksik
- hangi formatlar pilotta hic gorulmedi
- hangi orneklerde ayni alan farkli anlamda kullanilmis
- hangileri mevcut kurulumda hatali cikti uretir
Sonucu uc kovaya ayir:
A) mevcut kurulum oldugu gibi isler
B) kucuk duzeltmeyle isler, duzeltmeyi yaz
C) isletmez, sebebini yaz
Hangi kovanin neden oldugunu tek cumleyle gerekcelendir.C kovası yaygınlaştırma takviminizi belirler, A kovası değil. Çoğu kurum A kovasının büyüklüğüne bakıp tarih verir, sonra C kovasında takılır. Üçüncü madde ayrıca önemli: aynı alan adının iki birimde farklı anlama gelmesi, format hatasından daha sessiz ve daha pahalıdır.
Destek yükü kullanıcı sayısıyla doğrusal artmaz
Pilotta on kişi vardı ve destek bir kişinin yan işiydi. Üç yüz kişiye açarsanız destek otuz kat artmaz; soru çeşidi de arttığı için daha fazla artar.
İlk otuz gün en yoğun dönemdir. O dönemi kim taşıyacak sorusunu yaygınlaştırma kararından önce cevaplayın.
Bir yapay zeka kurulumunu [sayi] kisiden [sayi] kisiye acacagim.
Pilotta gelen sorular: [en sik 5-10 soru]
Pilotta destegi veren: [rol, ayirdigi sure]
Bana ilk 30 gun icin destek plani cikar:
1. Yeni kullanicilardan hangi yeni soru turleri beklenir
2. Bunlarin kaci dokumanla, kaci kisiyle cozulur
3. Haftalik tahmini destek suresi ve bunu kimin tasiyacagi
4. Hangi sorular tekrarliyorsa kurulumda neyin degismesi gerektigi
5. 30. gunde bakilacak uc sayi
Destek yuku tasinamaz gorunuyorsa, acilisi kac dalgaya
bolmek gerektigini soyle ve dalgalari sirala.Bu promptun işi plan yazmak değil, kapasiteyi görünür kılmak. Dördüncü madde tekrarlanan soruları destek konusu olmaktan çıkarıp kurulum konusuna taşır; destek yükünün kalıcı düşmesi orada olur.
İkinci dalga pilot değil, kurulumdur
Pilot deneme izni verir. Hata normaldir, geri dönüş beklenir. Yaygınlaştırmada bu izin biter, ama çoğu kurum pilot refleksiyle devam eder.
İkinci dalgaya geçerken kurulumun bir devreye alma kontrol listesi olmalı: kim açar, hangi eğitim verilir, hangi doküman nerede durur, arıza kime gider, geri alma nasıl yapılır.
Pilot ekibin kurulumu taşıması da burada biter. Pilotta işi bilen kişi hem kullanıcı hem destek hem eğitmendi. Üç birimde bu rol tek kişiye sığmaz; işi bir role bağlamazsanız yaygınlaştırma o kişinin takvimine bağlı kalır ve o kişi izne çıktığında durur.
Bir yapay zeka kurulumunu yeni bir birime acacagim.
Kurulum: [ne yapiyor, hangi adima giriyor]
Birim: [adi, kisi sayisi, isin akisi]
Bana devreye alma kontrol listesi hazirla. Her madde
tek satir ve kontrol edilebilir olsun:
- acilistan once tamamlanmasi gerekenler
- acilis gunu yapilacaklar
- ilk hafta izlenecekler
- ariza halinde kim ne yapar
- geri alma adimlari (kurulumu kapatmak gerekirse)
Her maddenin yanina sorumlu rolu yaz.
Sorumlusu belirsiz kalan maddeleri sonda ayri listele.Son satır listenin en faydalı kısmını üretir. Sorumlusu belirsiz madde, açılış günü kimsenin sahiplenmediği iş demektir. Geri alma adımları da pazarlık konusu değil: kapatma yolunu yazmadığınız bir kurulumu kapatmak, açmaktan pahalıya gelir.
Karar için tek sayfalık geçiş notu
Yaygınlaştırma kararı genelde sunumla alınır. Sunum ikna eder, kayıt tutmaz. Altı ay sonra neyin hangi varsayımla açıldığı kimsede yazılı olmaz.
Bir yapay zeka pilotundan yayginlastirmaya geciyorum.
Elimde: [farklar listesi ozeti], [girdi kovalari ozeti],
[destek plani ozeti], [kontrol listesi durumu]
Bana tek sayfalik gecis notu yaz. Sadece su basliklar:
- yayginlastirilan is ve girmedigi yerler
- acilan birimler ve dalgalar
- tasinan varsayimlar (pilotta gecerliydi, burada da gecerli sayilan)
- kabul edilen riskler ve her birinin sahibi
- basarinin olculecegi uc sayi ve olcum tarihi
- durdurma kosulu: ne olursa acilis durur
Yorum ve tavsiye ekleme, sadece karari kaydet.Not bir sayfadan uzunsa karar henüz netleşmemiştir. Üçüncü madde özellikle önemli: taşınan varsayımları yazmazsanız, bir birimde çıkan sorunun sebebini aramak haftalar alır. Durdurma koşulu ise açılışı geri alınabilir kılar.
Sınır: ölçüm kurulumu izler, kişiyi izlemez
Yaygınlaştırmada kullanım verisi birden artar. Kim ne zaman ne sordu, kim hiç kullanmadı. Bu veri kurulumun çalışıp çalışmadığını görmek içindir, kişi bazlı performans takibi için değil. Amacını yazılı olarak sınırlamazsanız veri zamanla başka bir şey için kullanılır ve kullanımın kendisi düşer.
İkinci sınır modelde. Yukarıdaki promptlar hedef birimler hakkında sizin verdiğiniz bilgiyle çalışır. Model eksik bıraktığınız yeri makul görünen bir tahminle doldurabilir; özellikle birim sayıları, destek süreleri ve girdi hacimlerinde. Çıktıdaki her sayıyı kendi kayıtlarınızla karşılaştırın.
Pilot bir şeyin çalıştığını değil, o koşullarda çalıştığını gösterir; koşulları yazmadan yaygınlaştırdığınızda taşıdığınız şey kurulum değil, şansınızdır.