Otomasyon Projesine Nasıl Başlanır: Araçtan Değil Problemden

Araçtan değil problemden başlarım. İlk yapılan iş kod yazmak değil, iki şeyi ölçmektir:

• Hangi iş, ne sıklıkla tekrarlanıyor?
• Mevcut süreçte zaman tam olarak nerede kayboluyor?

Bu iki soru kulağa basit gelir ama cevapları çoğu zaman sürprizlidir. Bir ekip "modelleme çok uzun sürüyor" der; ölçtüğünüzde asıl kaybın modellemede değil, teknik resim çıktılarının elle düzenlenmesinde olduğu görülür. Yanlış yeri otomatikleştiren bir proje, teknik olarak kusursuz çalışsa bile hissedilir bir kazanç üretmez.

Ölçüm karmaşık olmak zorunda değil. Çoğu zaman iki hafta boyunca tutulan basit bir kayıt — hangi iş, kaç kez, yaklaşık kaç dakika — yeterlidir. Önemli olan hassasiyet değil, doğru kalemi bulmak.

Otomasyonun getirisi, kazanılan süre çarpı tekrar sayısıdır. Tekrar sayısı düşük bir işi mükemmel otomatikleştirmek, yüksek tekrarlı bir işi kabaca otomatikleştirmekten daha az değer üretir.

İkinci adım, birinci adımdan çıkan listeye bakıp şu ayrımı açıkça yapmaktır: neyin yazılıma, neyin insana kalacağı.

Bu adım atlanırsa proje şu iki şekilden biriyle bozulur:

1. Kapsam sürekli büyür. Her istisna yazılıma eklenir, sistem kural yığınına döner ve bakımı imkânsızlaşır.
2. Kimse güvenmez. Nerede devreye girip nerede çıkacağı belirsiz olan bir otomasyonun çıktısı, kullanıcı tarafından her seferinde baştan kontrol edilir — yani kazanılan süre geri verilir.

Sınırı çizerken işe yarayan pratik bir ayrım şudur: kural haline getirilebilen iş yazılıma, yargı gerektiren iş insana. Bir profilin uzunluğunu parametreden hesaplamak kuraldır. Müşteri özel bir talep gönderdiğinde bunun standart üretim akışına uyup uymadığına karar vermek yargıdır.

Sınırın nerede olduğu kadar, nerede olduğunun yazılı olması da önemlidir. Sonradan gelen her istisna talebi bu belgeye karşı değerlendirilir.

Üçüncü adımda kod yazmaya başlanır — ama tamamı değil. Küçük ve sonucu ölçülebilir bir parça seçilir.

Pilotun iyi seçilmiş olduğunun ölçütü şudur: bittiğinde, işe yarayıp yaramadığı tartışmaya açık olmamalı. "Daha iyi hissettiriyor" bir sonuç değildir. "Aynı çerçevenin hazırlanması 40 dakikadan 6 dakikaya indi" bir sonuçtur.

Pilot ayrıca bir şeyi daha yapar: varsayımları erken kırar. Otomasyon projelerinde en pahalı hatalar, altı ay kod yazdıktan sonra üretim verisinin sandığınız formatta olmadığını fark etmektir. Küçük bir pilot bunu ikinci haftada gösterir.

Pilot kapsamı seçerken şuna dikkat ederim: mümkünse uçtan uca olsun, dar olsun. Yani tek bir ürün varyantı için parametre girişinden üretim çıktısına kadar tüm zinciri kapsasın. Zincirin yalnızca ortasını otomatikleştiren bir pilot, gerçek darboğazları göstermez.

Son adım, kapsamı genişletmektir — ama kanıtla, tahminle değil.

Pilot sahada çalıştığını gösterdikçe bir sonraki varyant, bir sonraki ürün ailesi, bir sonraki çıktı tipi eklenir. Her genişleme öncesinde aynı soru sorulur: bu ekleme, birinci adımda ölçtüğümüz kayıp kalemlerinden hangisine karşılık geliyor?

Bu disiplin olmadan otomasyon projeleri, kimsenin kullanmadığı özelliklerle şişer. Kullanılmayan her özellik yalnızca boşa harcanmış zaman değildir; bakım yükü olarak kalıcı bir maliyet üretir.

Bir yöntemi anlatırken neyi kapsamadığını söylemek, kapsadığını söylemek kadar önemli.

• Yargı gerektiren kararlar. Yapay zeka araçlarını hız ve iterasyon için kullanırım; mimari kararlar, doğrulama ve test yükü bende kalır.
• Az tekrarlanan işler. Ayda bir yapılan bir işi otomatikleştirmek, çoğu zaman elle yapmaktan pahalıdır.
• Henüz oturmamış süreçler. Sürekli değişen bir iş akışını otomatikleştirmek, hareketli bir hedefi sabitlemeye çalışmaktır. Önce süreç oturur, sonra otomatikleştirilir.

Otomasyon projesinin başarısı, ilk gün seçilen kütüphaneyle değil, ilk hafta sorulan sorularla belirlenir:

Araç seçimi bu dört sorunun cevabından sonra gelir — ve genellikle o noktada zaten belli olmuştur.