Kaizen nedir? VibeKaizen'de sürekli iyileştirme rehberi

VibeKaizen'in adındaki "kaizen" bir süs değil. Platformun nasıl çalıştığını, Japon sanayisinden gelen bu fikir belirliyor: işi küçük parçalara bölmek, her parçayı görünür kılmak, her turdan bir şey öğrenip bir sonrakine taşımak. Bu rehberde önce kaizen'in ne olduğunu ve nereden geldiğini anlatıyoruz. Sonra bir kaizen panosunun nasıl kullanıldığına, bu fikirlerin VibeKaizen'de neye karşılık geldiğine ve sizin neler yapabileceğinize geçiyoruz.

Kaizen nedir?

Kaizen (改善) Japonca bir kelime. Anlamı kabaca "iyileştirme" ya da "daha iyiye doğru değişim". Wikipedia'daki kaizen maddesi kelimenin iş dünyasında, bir şirketin her köşesinde yapılan çok sayıda küçük ve sürekli iyileştirme için kullanıldığını yazıyor.

Kaizen'in üç temel fikri var:

Küçük adımlar. Büyük ve riskli bir dönüşüm yerine her gün küçük, geri alınabilir değişiklikler yapılır.
Süreklilik. İyileştirme bir proje değil, bir alışkanlıktır. Bir sorun çözülünce bir sonrakine bakılır.
Herkesin katılımı. Fikir yalnızca yöneticiden gelmez. Kaizen maddesine göre üst yöneticiden temizlik personeline kadar herkes katılır. Kaizen Institute bunu "herkes, her yerde, her gün" diye özetliyor.

Kısa bir tarih

Kaizen'in kökü İkinci Dünya Savaşı sonrası Japonya'sına uzanıyor. Savaştan sonra Amerikalı danışmanlar Japon sanayisinin yeniden kurulmasına yardım etti. Bu yardımın bir parçası, ABD'nin savaş yıllarında (1940–1945) fabrikalar için geliştirdiği Training Within Industry (TWI) programıydı. TWI'nin "iş yöntemleri" eğitimi çalışanlara kendi işlerinin her adımını sorgulamayı öğretiyordu: bu adım kaldırılabilir mi, başka bir adımla birleşebilir mi, sırası değişebilir mi, basitleşebilir mi? Program Japonya'da çok iyi karşılandı ve Japon sanayisindeki kaizen kültürünün temeli oldu. Kaizen maddesine göre 1951'de hazırlanan "İyileştirmenin Dört Adımı" adlı bir eğitim filmi, kaizen kelimesini bu anlamıyla Japonya'ya tanıttı.

İkinci önemli isim istatistikçi W. Edwards Deming. Deming 1950 yazında Japon Bilim İnsanları ve Mühendisleri Birliği'nin (JUSE) davetiyle yüzlerce mühendis ve yöneticiye kalite kontrolü anlattı. Ana mesajı şuydu: kaliteyi artırmak maliyeti düşürür, verimliliği ve pazar payını artırır. JUSE aynı yıl onun adına Deming Ödülü'nü kurdu. Deming'in Walter Shewhart'tan devralıp geliştirdiği döngü bugün PDCA olarak biliniyor: Planla, Uygula, Kontrol et, Önlem al. Bu dört adımlı kısaltma, Deming'in 1950'lerin başındaki Japonya derslerinde katılımcılar tarafından konuldu. Deming kendisi "kontrol et" yerine "incele" demeyi tercih ediyordu.

Kaizen'i bir fabrikanın gündelik işine en derin yerleştiren şirket Toyota oldu. Toyota Üretim Sistemi 1948 ile 1975 arasında Taiichi Ohno ve Eiji Toyoda tarafından geliştirildi. Sistemin iki ayağı var: "tam zamanında" üretim (yalnızca gerekeni, gerektiği zaman, gerektiği kadar yapmak) ve "insan dokunuşlu otomasyon" (jidoka). Sürekli iyileştirme bu sistemin ilkelerinden biri. Taiichi Ohno bugün sistemin babası sayılıyor; Batı'daki "yalın üretim" akımına da bu sistem ilham verdi.

Kelimeyi Batı'ya taşıyan kişi Masaaki Imai. Imai 1985'te Kaizen Institute'u kurdu, 1986'da da McGraw-Hill'den "Kaizen: The Key to Japan's Competitive Success" (Kaizen: Japonya'nın Rekabet Başarısının Anahtarı) kitabını yayımladı. Kitap, kaizen'i Japon olmayan yöneticilerin de anlayıp uygulayabileceği bir yöntem olarak anlattı.

Bugün nerede kullanılıyor?

Üretim: Otomotivden elektroniğe, kaizen ve yalın üretim hâlâ fabrika yönetiminin temel dili.
Sağlık: ABD'deki Virginia Mason hastanesi 2002'de Toyota Üretim Sistemi'ni hasta güvenliği için sağlık hizmetine uyarladı ve kendi adını taşıyan bir üretim sistemi kurdu.
Yazılım: 2001'de yayımlanan Çevik Yazılım Manifestosu'nun son ilkesi düpedüz kaizen: ekip düzenli aralıklarla nasıl daha etkili olabileceğini düşünür ve davranışını buna göre ayarlar. Mary ve Tom Poppendieck'in 2003 tarihli kitabıyla başlayan yalın yazılım geliştirme de yalın üretim ilkelerini yazılıma taşıdı.
Kişisel verimlilik: Kaizen Institute, kaizen'i iş hayatının yanında ev ve sosyal hayatta da süren bir iyileştirme olarak tanımlıyor. Her gün bir alışkanlığı biraz düzeltmek de kaizen'dir.

Kaizen panosu nasıl kullanılır?

Kaizen'in en görünür aracı panodur. Bir duvar, bir beyaz tahta ya da bir ekran olabilir. Japoncada "tabela" anlamına gelen kanban, Toyota'da Taiichi Ohno'nun geliştirdiği bir kart sistemi olarak doğdu. Toyota bunu süpermarketlerden esinlenerek kurdu: raf, müşteri ne aldıysa o kadar doldurulur. Yazılım ekipleri bu fikri kanban panosu olarak benimsedi. Kaizen panosu dediğimizde aynı aracı kastediyoruz.

Sütunlar işin aşamalarıdır

Panodaki her sütun bir aşamadır: bekliyor, yapılıyor, kontrol ediliyor, bitti gibi. Her iş bir karttır ve aşamaları soldan sağa geçer. Panoya bakan herkes, kimseye sormadan hangi işin nerede olduğunu görür.

Aynı anda yürüyen iş sınırlıdır

Kanban'ın en önemli kuralı, bir aşamada aynı anda bulunabilecek iş sayısına üst sınır koymaktır. İngilizcede buna WIP limiti (work in progress) denir. Sınır dolunca yeni iş başlamaz; önce elde olan bitirilir. Bu, yarım kalmış onlarca işin birikmesini önler. Bir aşama tıkandığında da bunu herkes görür.

Sorunlar görünür olmalı

Takılan bir kart saklanmaz, işaretlenir. Sınırlı iş kuralı da buna yardım eder: bir aşama dolunca tıkanıklık herkesin önündedir. Amaç, sorunu küçükken ve tazeyken çözmektir. Panoda "durdu" yazan bir kart, bir hata değil, bir davettir.

Her gün kısa bir bakış

Ekipler panoya her gün kısa bir süre bakar. Ne ilerledi, ne takıldı, kimin yardıma ihtiyacı var? Bu bakış uzun bir toplantı değildir; amaç akışı sürdürmektir.

Küçük partiler

Büyük bir iş tek kart olarak panoya konmaz; küçük parçalara bölünür. Küçük bir iş çabuk biter, çabuk kontrol edilir ve hatası çabuk bulunur. Büyük bir işte hata geç fark edilir ve pahalıya patlar.

İyileştirme döngüsü ve retrospektif

Pano yalnızca işi değil, işin nasıl yapıldığını da iyileştirmek için vardır. PDCA döngüsü burada devreye girer: bir değişiklik planlanır, denenir, sonucu kontrol edilir, işe yarıyorsa kalıcı hâle getirilir. Yazılım ekipleri bunu belli aralıklarla yaptıkları retrospektif toplantılarıyla uygular: ne iyi gitti, ne kötü gitti, bir dahaki sefere neyi farklı yapacağız? Bir retrospektifin değeri, çıkan kararların gerçekten bir sonraki tura taşınmasıdır.

VibeKaizen'de nasıl işliyor?

VibeKaizen bu fikirleri yapay zekâ ajanlarından oluşan bir ekibe uyguluyor. Ekipte dört rol var: ürün sahibi, mimar, geliştirici ve inceleyici. Testleri ayrı bir ajan değil, platformun test kapısı çalıştırıyor. Siz kurucu olarak fikri veriyor, kararları alıyor ve sonucu deniyorsunuz.

Panonun sütunları

Biriktirme listesi: Fikriniz burada başlar. Kurulum sihirbazında ne istediğinizi anlatırsınız; ürün sahibi eksikleri size sorar, mimar planı ve her görevin kabul kriterlerini yazar, iş görevlere bölünür. Görev dökümünü siz onaylarsınız. Sonraya bıraktığınız işler de burada bekler.
Hazır: Onaylanmış ve sırası gelmeyi bekleyen görevler. Bir görev, bağlı olduğu görevler bitmeden başlamaz.
Geliştirmede: Geliştirici ajan görevi kendi yalıtılmış çalışma ortamında yazar ve testleri çalıştırır. Görev incelemeye geçmeden önce testler gerçek bir tarayıcıda koşar. Figma dosyası bağladıysanız platform ekranı tasarımla da karşılaştırır.
Kod incelemesi: İnceleyici değişikliği okur. Bulgu varsa görev Geliştirmede sütununa geri döner ve düzelmeden ilerlemez. Varsayılan olarak en fazla iki inceleme turu denenir; geliştirici ile inceleyici anlaşamazsa karar size gelir.
Kabul testi: Görev size, tarayıcıda açıp deneyebileceğiniz bir önizlemeyle gelir. Onaylarsanız değişiklik uygulamanıza eklenir. Beğenmezseniz nedenini yazıp geri gönderirsiniz.
Bitti: Onaylanmış ve uygulamaya eklenmiş görevler.

Takılan bir görev panoda Durdu olarak görünür. Kartta nedeni ve sizden ne beklendiği yazar: bir anahtar, bir karar ya da sağlayıcı hesabınızda kredi. Bu, kaizen'deki "sorunu görünür kıl" ilkesinin karşılığı.

Aynı anda yürüyen iş

VibeKaizen'de WIP limiti, aynı anda kaç görevin geliştirildiği demek. Üst sınırı planınız belirler: Solo'da 1, Pro'da 2, Team'de 5 görev. Proje içindeki sayıyı Ayarlar'daki Pano sekmesinden, Geliştirmede sütunu için ayarlarsınız. Fazla paralel iş, aynı dosyalara dokunan görevlerin birbirine çarpmasına yol açabilir; küçük bir sınır çoğu zaman daha hızlı bitirir.

İnceleme döngüsü ve kabul testi

Her görev iki kontrolden geçer. Önce inceleyici ajan kodu okur; bulduğu her sorun geliştiriciye geri gider. Sonra siz önizlemede denersiniz. Bu, kaizen'deki küçük PDCA döngüsünün görev ölçeğindeki karşılığı: plan (kabul kriterleri), uygulama (geliştirme), kontrol (inceleme, test ve sizin denemeniz), önlem (düzeltme ya da onay).

Sprint, kapanış ve retro

Görevler sprintler hâlinde ilerler. Sprint bitince bir sürüm adayı hazırlanır ve bir retrospektif yazılır. Retro iki şey önerir: akış kurallarında değişiklikler ve ajanlar için kalıcı dersler. İstemediklerinizin işaretini kaldırıp retroyu onaylarsınız. İşaretli dersler projenizin deposundaki AGENTS.md dosyasına eklenir ve sonraki her görevde ajanlar bu dosyayı okur. Kaizen döngüsü burada ajanların kendisi için kapanır: bir sprintteki hata, bir sonraki sprintte kurala dönüşür. Sonra "Sürümü yayınla" dersiniz; siz demeden sürüm çıkmaz.

Ayarlar → Akış

Akışın kurallarını Ayarlar → Akış ekranından değiştirirsiniz:

Otomatik onay süresi: 0 ile 24 saat arası, varsayılan 4 saat. Bu sürede yanıt vermezseniz görev kendiliğinden onaylanır. 0 yaparsanız görev siz onaylayana kadar bekler.
İnsan incelemesi: Açarsanız her değişiklik, inceleyici ajandan sonra önizlemeden önce sizin onayınızı da bekler.
Tur sınırları: İnceleme turu, test deneme ve kabul testi ret sayıları.
Tek çalışma bütçesi: Tek bir ajan çalışmasının harcayabileceği üst sınır; varsayılan $5, $1 ile $20 arasında ayarlanır. Aşılırsa görev durur ve size haber verilir.

Püf noktaları

Blogdaki beş demo uygulamayı bilerek en az girdiyle yaptık: fikri kısa yazdık, çoğu soruda varsayılanı seçtik, görev dökümüne dokunmadık. Sonuçlar çalışıyor, ama daha fazla yönlendirme daha iyi sonuç verir. İşte madde madde yapabilecekleriniz:

Sihirbazda fikri ayrıntılı yazın. Uygulamayı kim kullanacak? Ana akışlar neler (kayıt olur, ürün ekler, sipariş verir)? Ne olmamalı (başkasının verisini görmek, ödeme olmadan sipariş)? Görünüm ve his nasıl olmalı? Birkaç paragraf, birkaç cümleden çok daha fazla soruyu baştan kapatır.
Önemli sorulara kendi cevabınızı verin. Ürün sahibinin her sorusunda bir varsayılan cevap ve sonucu yazar. Varsayılan çoğu zaman makuldür, ama ürününüzün özünü ilgilendiren sorularda kendi cevabınızı yazın. Bir e-postanın gerçekten gitmesini istiyorsanız "deneme değil, gerçek gönderim" deyin.
Görev dökümünü onaylamadan önce düzenleyin. Görev dökümü ekranında başlığı, açıklamayı, kabul kriterlerini, önceliği ve bağımlılıkları değiştirebilir, şimdilik gerekmeyen görevi çıkarabilirsiniz. Büyük görünen bir görevi bölmek ya da sırayı değiştirmek için "Değişiklik iste" ile ürün sahibine yazın.
Tasarımınız varsa Figma'yı bağlayın ve neyin önemli olduğunu söyleyin. Platform ekranları tasarımla karşılaştırır, ama sizin için hangi ayrıntının öncelikli olduğunu bilmez. İkonlar mı, boşluklar mı, yazı tipi mi? Bunu yazın.
Rol talimatları yazın. Ayarlar → Yapay zekâ ve roller ekranında her rol için talimat ekleyebilirsiniz: kod stiliniz, tasarım tercihleriniz, inceleyicinin özellikle neye bakması gerektiği. Talimatlar kaydettiğiniz andan sonraki ilk çalışmadan itibaren uygulanır.
Her önizlemeyi gerçek bir kullanıcı gibi deneyin. Yalnızca ana ekrana bakmayın; kayıt olun, yanlış bilgi girin, telefonda açın. Reddederken somut yazın: ne yaptınız, ne bekliyordunuz, ne oldu. "Çalışmıyor" yerine "Kaydet'e bastım, liste güncellenmedi, sayfayı yenileyince göründü" gibi.
Görevleri küçük tutun. Küçük görev daha ucuz, daha hızlı ve daha kolay denenir. Bir görevde üç ekran varsa bölünmesini isteyin.
Retroyu kurala çevirin. Aynı sorun iki kez çıktıysa retroda onu bir derse dönüştürün ve AGENTS.md'ye girmesini onaylayın. Örneğin "Her form boş gönderildiğinde hata mesajı gösterilir."
Modelleri role göre seçin. Büyük görevleri kendi anahtarınızla güçlü bir modele, küçük görevleri platform modeline verebilirsiniz. Ayarlar'daki "Küçük görevler için" seçeneği bunu yapar.
Sağlayıcınızda harcama sınırı koyun. Akış ayarlarındaki bütçe sınırına ek olarak, Anthropic, OpenAI ya da Google panelinizden de bir aylık harcama sınırı belirleyin.
Sprint kapanınca sürümü yayınlayın. Sürüm adayı hazır olduğunda retroyu okuyup sürümü yayınlayın. Bekleyen bir sürüm, bir sonraki sprintin neyin üzerine kurulacağını belirsizleştirir.

En az girdiyle neler çıktığını demolarda görebilirsiniz. Daha fazla yönlendirme, daha iyi sonuç demek.

Kaynaklar

Kaizen (Wikipedia)
Masaaki Imai (Wikipedia)
What is KAIZEN™ (Kaizen Institute)
Training Within Industry (Wikipedia)
W. Edwards Deming (Wikipedia)
PDCA (Wikipedia)
Toyota Production System (Wikipedia)
Taiichi Ohno (Wikipedia)
Kanban ve Kanban (development) (Wikipedia)
Virginia Mason Medical Center (Wikipedia)
Agile software development ve Lean software development (Wikipedia)

Küçük bir fikir de olsa, ilk adımı bugün atın; gerisini her sprintte birlikte iyileştiririz.