Çok eskilere gitmeye gerek yok bundan yaklaşık 25 yıl önce Amerika’da yazılım üretici firmaların patronları istedikleri kalitede ve hızda yazılım üretememekle ilgili kafayı yeme noktasına geliyorlar.
Bunun üzerine akil adamlar bir araya gelip toplantı üzerine toplantı yapıyorlar. Mevcut sisteme alternatif radikal bir çözüm var mıdır diye kafa patlatıyorlar.
O güne kadar hâkim sistem “şelale” (waterfall) sistemi. Yani “önce analiz dokümanı hazırlanır, ardından müşteriye onaylatılır, sonra yazılım geliştirilir, test bölümü gerekli testleri yapar, müşteriye sunuş yapılır ve en son canlı uygulamaya geçilir” falan gibi bir düşünce hâkim.
Tabii her konuda olduğu gibi planlanan ile gerçekleşen çoğunlukla örtüşmüyor; “okunamayacak uzunlukta ve detayda dokümanlar, müşteri talebindeki güncellemeler, bitmek bilmeyen projeler, mutsuz müşteriler, mutsuz satıcılar, vs, vs.
“Peki neden” diye sorduklarında şu cevabı itiraf ediyorlar: “Hem teknoloji hem de müşteri talepleri o kadar çeşitlendi ki bu şartlarda proje yönetimi kaçınılmaz olarak kaotik bir hâl alıyor”
Yıllar süren çalışmalar ve denemeler sonucunda yeni bir yolun ilk taşlarını döşüyorlar. Örneğin şöyle diyorlar: “Müşteri dâhil hiç kimse, projenin ilk evrelerinde talebin ne olduğunu tam olarak bilemez”. Böylelikle şelale sisteminde peşisıra ilerleyen süreçler yerine daha kısa süren ve her fazda parçalı üretim yapabilecekleri bir sistem hayal ediyorlar.
Ardından aşağıdaki 4 maddelik Agile manifestosunu yazıyorlar. Çevik manifestoda ilk argüman yerine ikinci argümana önem verin diyorlar (Dikkat ilk argümanı boş verin demiyorlar). Çünkü her işletmenin zamanı ve enerjisi sınırlıdır. Her şeyi mükemmel yapamayız fakat enerjimizi daha önemli alanlara yönlendirebiliriz.
- Araçlar ve süreçler yerine şahıslar ve onların etkileşimlerine önem verin
Yani “araç ve süreç elbet önemli ama daha önemlisi onu etkin kullanabilen ve iletişim halindeki ekiptir”.
- Muhteşem dokümantasyon yerine çalışan ürüne önem verin
Binlerce sayfa dokümanı kimse okumaz, güncellemesi zordur, katma değeri düşüktür. Ürün sağlamsa doküman okuma ihtiyacı kendiliğinden azalır.
- Kontrat ve şartnameler yerine müşteri ile işbirliğine gidin
Yani yapabildiğiniz ölçüde yaptığınız işin “belirsizliğini ve değişkenliğini” müşteri ile paylaşın. İdeal ürünü üretmekle ilgili müşteriyi de süreçlerinize dâhil etmeye çalışın
- Orijinal plana sımsıkı sadık kalmak yerine değişime cevap verebilen bir sistem kurun
Üretiminde (hatta iş dışı yaşamda da öyle) hiçbir şey planlandığı gibi olmaz. Uzun vadeli detaylı planlar yapmak yerine değişiklik taleplerine nasıl cevap vereceğinize yoğunlaşın
İşte son yıllarda yazılım için geliştirilmiş Agile sistemi fabrikalar için de alternatif bir sistem olabilir mi kafa yoran ve hatta uygulamaya geçen işletmeler görüyoruz.
Tabii stardard bir seri üretim yapıyorsanız Agile (Çevik) yaklaşım sizin için uygun olmayabilir. Fakat aşağıda bazı örneklerini verdiğim süreçler Çevik yaklaşım için uygun olabilir:
- Proje usülü çalışmalar (her ürün farklı proje)
- AR-GE projeleri
- Fabrika içi süreç iyileştirme çalışmaları
- Fabrika içi yalın uygulamalar
Bu yazıda Çevik sistemin tüm detaylarını konuşmak elbette mümkün değil. Yine de fabrikalar için bazı Çevik yaklaşım uygulama örnekleri verelim:
- Uzun bir zaman sonra projenin tamamlanması ile ilgili tek bir hedef yerine örneğin 3 haftalık dönemler ve hedefler belirleyin (sprint). 3 hafta sonunda başarı seviyenizi ve sizi engelleyen konuları gözden geçirin.
- 1’den fazla çalışma takımı oluşturun. Takımlarınıza özerklik verin. Her takımın neyi ne zaman yapacağına kendilerinin karar vermesini, takımın başarısını kendilerinin ölçmesini ve yorumlamasını sağlayın. Günlük kısa toplantılarla ekip içi iletişimi arttırmaya çalışın. Takımların performansını karşılaştıracak sistemler kurun.
- Ekibinize önem verin. İyi ekip hatasız bir defada üretim anlamına gelecektir.
- Mümkün olduğu ölçüde müşterinizi proje süreçlerinize dâhil edin. Ürün kısmi olarak tamamlandığında müşterinizle gözden geçirme toplantısı yapın. Mevcut durumunuzu, tadilat taleplerini mevcut darboğazlarınızı müşteri ile paylaşın.
- Değişim taleplerinin nasıl ele alınacağı, mevcut planı ne şekilde aksatacağının izlenmesi ile ilgili sistem tasarlayın
Dokümanda boğulmayın, gereksiz açıklamalardan sakının. Basit videolar veya şematik gösterimlerin de doküman olarak kullanılabileceğini unutmayın
Çevik yaklaşımın orta vadede işletmelerde önem kazanacağını düşünüyorum.
🙂
