Bir şirketi büyütürken karşılaşılan temel zorluklardan birisi ürün ve mühendislik takımlarını büyütmektir. Teknoloji takımları hiçbir zaman yeterince hızlı değiller: ürünün yol haritası geliştirilmesi gereken özelliklerle ağzına kadar dolu oluyor ve şirketin her yerinden (satış, pazarlama, müşteri destek hattı vb.) başkan yardımcıları kendi isteklerinin listenin başında yer alması için kıyasıya mücadele ediyorlar. Bu savaşım CEO’yu zorlarken ürün müdürünü de dar boğaza sokmaktadır.

İlk bakışta verimlilik meselesi gibi dursa da – daha hızlı özellik geliştirmek için neler yapılabilir? – daha yakından bir inceleme ile bazı durumlar daha belirgin hale geliyor:

1. Geliştiriciler, kullanıcı ihtiyaçlarının tam olarak anlaşılmamasından ötürü, tamamlanmamış veya tutarsız özelliklerle uğraşarak gereğinden çok daha fazla zaman harcıyor.
2. Gelişim süreci boyunca değişikliklerin sıklıkla talep edilmesi yeni geliştirmelerin maliyetini arttırmakla beraber zaman israfına neden oluyor.
3. Özellikler belirlenirken önemli ayrıntıların ihmal edilmesi veya takımın işi yetiştirmek için acele ederken kusurları düzeltememesinden ötürü, geliştirmeler şirketin içindeki ve dışındaki kullanıcılar için sorunlar yaratıyor.
4. Tüm çabalara rağmen tatmin edici sonuçlar elde edilemiyor.

Aslında mesele teslimat (bilinen bir çıktıyı verimli bir şekilde elde etmek için insanları organize etmek) ile alakalı değil. Mesele keşif (daha iddialı olabilmek adına ürünü keşfetmek ve tanımlamak)  ile alakalı.

Yalın bize keşif ile ilgili ne öğretiyor?

DEĞERİ ANLAMAK

Keşif, yalın pencereden bakılırsa, öncesinde ürünün müşteri için nasıl değer yarattığını öğrenmek sonrasında da israfımızın maliyetini müşteriye yansıtmamak için tasarımın ve montajın ayrıntılarını belirlemekle alakalıdır.

Değer ve israfın yalnızca ana teknolojik ürün üzerinde değil, tüm değer zinciri boyunca değerlendirilmesi gerekir. Bunun sonucunda keşif, toplam ürünü – müşteri deneyiminden şirketin iç süreçlerine kadar – kapsamaktadır.

Örnek olarak bir taşıt paylaşma hizmetini göz önünde bulunduralım. Ana ürün yolculuğu ayırtmak için kullanılan uygulama veya yolcuları sürücülere atayan sistem olabilir. Buna karşın toplam ürün müşteri deneyimini belirleyen tüm sistemleri ve servisleri kapsamaktadır. Bu durumda müşterinin gözünden performansı belirleyen temel öğelerden biri araç için gerekli bekleme süresidir. Bu süre yolcuları atayan algoritmayla beraber herhangi bir zamanda yolda olan araç sayısına da bağlı. Bu şu anlama geliyor: kullanıcılara verilen sözün tutulduğu bir hizmet tasarlamak. Aynı zamanda toplam sürücü deneyimini de göz önünde bulundurmayı ve binlercesini platformu kullanmak için ikna etmeyi unutmamak gerekir. Bu da  sürücüleri işe almak için büyük ölçekli bir servisin yanı sıra bu servisteki günlük sorunlarla ilgilenmekle yükümlü bir çok insan ihtiyacı doğuruyor.

Ürünün başarılı olması için bir dizi ürün ve sürecin tasarlanması gerekir. Sonuç olarak ürün ile ilgilenen takım, şirketin tüm departmanlarından temsilciler barındırmalıdır.

Tüm bu insanların ortak bir hedefe doğru birlikte çalışmalarını sağlamak zordur. Genellikle farklı önceliklere sahip olan bu insanlar, yerel kararlarının “büyük resme” olan etkisini görmüyorlar. Hepsini hizaya sokmak için bir reçete mevcut değil. Geleneksel yöntemlerle organizasyonel bir mesele olarak ele alınan bu durumu yalın, öğrenme egzersizi olarak çerçeveliyor: “Ürünün başarılı olması için kimin ne öğrenmesi gerekiyor?”. Fakat farklı gündemleri takip eden böylesine kapsamlı bir grubun birlikte öğrenmesi ve aynı yönde ilerlemesi nasıl sağlanır?

BAŞ MÜHENDİS

Toyota bu sorunu Baş Mühendisi ürünün tüm boyutlarından sorumlu tutarak ele almaya çalışıyor. Baş Mühendisi bir girişimci – ürün ve müşterilere karşı tutkulu ve hırslı bir birey – olarak düşünün. Teknik sorunları eşeleyecek yeterli tecrübe ve bilgi birikimine sahip ve projenin politikalarını idare edebilecek yeterli liderlik yeteneklerine sahip bir insan. Steve Jobs, Apple’ın CEO’su olmasına karşın, bir Baş Mühendis olarak verilebilecek çok iyi bir örnektir.

Baş Mühendisin temel görevi çok farklı alanlarda çalışan uzmanların derinlemesine iş birliği yapabilecekleri koşulları oluşturmaktır. Baş Mühendisin, projeden projeye koşarken, diğerleri üzerinde hiyerarşik olarak otoritesi bulunmasa da ürünün büyük başarı elde etmesinde tam otoriteye sahiptir. Bu nedenle, insanlar onun vizyonunu takip edecekse, yetkisinin kabul görmesi ve yetkisine saygı duyulması oldukça önemlidir. Baş Mühendis, kendi bakış açısını insanlara dayatamayacağı için sağlam bir iş vakası (business case) oluşturmak için sıkı çalışmalı.

Baş Mühendislere enderlikle rastlanır ve birbirine benzeyen iki Baş Mühendis bulmak zordur. Tabi ki kendilerine özgü karakterlere sahipler fakat yıllar geçtikçe, geniş yetenek yelpazesine sahip olmak amacıyla şirket içerisinde birçok farklı aktiviteye katılarak, onlar da gelişiyor. Öğrenmeye devam ediyorlar ve belirli bir araçla (Obeya) takımın öğrenimini sürdürüyorlar.

OBEYA

Takeshi Uchiyamada’ya, doksanlı yılların başında Toyota’da Baş Mühendis iken zorlu bir görev verildi: 21. Yüzyılın arabasını – ulaşılması zor yakıt tüketim hedeflerine sahip – tasarlamak. Üç yıldan kısa bir sürede ilk hibrit araba (Prius) – rekabetten 15 yıl önce – pazara sürüldü. Böylesine bir başarıyı elde etmek için Baş Mühendisin aynı zamanda yeni bir ürün ve süreç geliştirme yöntemi icat etmesi gerekiyordu. Bu yöntem, sonrasında Toyota’nın mühendislik ofisleri arasında yayılacak ve “Obeya” olarak adlandırılacaktı.

Obeya, Japoncada “büyük oda” anlamına geliyor. Bu “büyük oda” duvarları bilgi (çizelgeler, çizimler, planlar vb.) ile kaplı genişçe bir ofistir.

Obeya başka bir proje yönetim aracı değildir. Amaç ne gelişimi değerlendirmek ne de özellikleri önceliklendirmektir. Burada amaç derinlemesine düşünmek, konuşmak ve projenin temel sorunları hakkında tartışmaktır. Keşif için düzenlenmiş bir mekandır aslında.

İnsanları hizaya sokmak için etkili bir yöntem olmasından dolayı Baş Mühendisler Obeya içerisinde malumatları ve bilgileri görselleştiriyorlar. Yanlış anlaşılmalar çabucak ele alınıyor ki insanlar bunlar hakkında konuşabilsin ve mevcut durum hakkında ortak bir anlayış geliştirebilsinler. Bunu gerçekleştirmek için uzun ve hararetli tartışmalara ihtiyaç duyulsa da bu tartışmalar insanların hemfikir olmaya başladığı ve beraber öğrendikleri süreçler olarak tanımlanabilir. İnsanları yola getirmek için erkenden harcanan bu zaman, projenin son aşamalarına doğru kendisini amorti ediyor.

Baş Mühendisin ve takımının duvarlarda neler sergilemeleri gerektiği konusunda bir dizi kural yok. Her obeya eşsizdir çünkü takımın olgunluğuna ve projenin aşamasına bağlıdır. Ancak ürün ne olursa olsun üzerinden geçilmesi gereken birkaç başlık var.

1. Çözmek istediğimiz sorun ne ve bunu kimin için yapıyoruz?

Başarılı bir ürün geliştirmek konstrüksiyon sorunundan çok problem çözme egzersizine benzer ve sorunlar genelde problem tanımı yapılmadan çözüme atlanmasından kaynaklanır. Yani “şu özelliği de ekleyelim” demektense “bu sonucu elde etmek için neler yapılması gerekiyor” sorusunun sorulması gerekir.

Yalın uygulayıcılar iş problemlerini çözmek için bilimsel bir yöntem olan PUKÖ (ing. PDCA Cycle) Döngüsünü kullanıyor. Ürün geliştirme bir istisna teşkil etmiyor, hatta ürün geliştirmek PUKÖ döngüsünü kendi içerisinde barındırıyor:

• Planla: çözülmesi gereken müşteri sorununu tanımla, durum hakkında derinlemesine bir anlayış geliştir ve hedef ürünün temel özelliklerini belirlemek.
• Uygula: ürünü imal etmek.
• Kontrol Et: neyin çalışıp neyin çalışmadığını görmek için iş sonuçlarını analiz etmek
• Önlem Al: sonraki ürün geliştirme döngüsünü iyileştirmek için dersler çıkarmak

İyi bir problem tanımı tutkulu bir hedefi tasvir eder. Örneğin Shinkansen’in hedefi beş yıldan kısa sürede Tokyo-Osaka arasındaki seyahat süresini üç saate indirmekti.

Obeyada öğrenilmesi ve keşfedilmesi gereken sonraki konu müşterinin değeri nasıl algıladığıdır. Bu çıktı müşterilerin hayatlarının içine dalmanın sonucunda ortaya çıkıyor. Müşteri şikayetleri ile başlayan süreç, mevcut çözümlerle ne yapmaya çalıştıklarını ve bu çözümlerin takımı nasıl yüz üstü bıraktığını anlamakla devam ediyor. Aynı zamanda bugün sorunlarını nasıl çözmeye çalıştıklarını daha iyi anlayabilmek için müşterilerle vakit geçirmek anlamına da geliyor.

Baş Mühendisin ve ürünü geliştiren takımın aşağıdaki maddeler hakkında birer fikir sahibi olmaları gerekir:

• Hedef müşteriler kim, yaşam tarzları ve zevkleri nedir?
• Kendi başlarına çözmeye çalıştıkları somut sorun nedir?
• Hangi bağlamda ve koşullarda bu sorunu çözmeye çalışıyorlar?
• Müşteriler istediklerini elde etmek için hangi alternatifler arasında seçim yapabiliyorlar?
• Neden bir alternatifi diğerine tercih ediyorlar?
• Mevcut çözüm hakkında sevdikleri ve sevmedikleri şeyler neler?
• Mevcut çözümle beraber hangi problemleri tecrübe ediyorlar?
• Müşterileri hayal kırıklığına uğratmamak ve tam anlamıyla tatmin edebilmek için nasıl tercihlerde bulunmamız gerekir?
• İnsanların dikkatini cezbedebilmek için hangi özelliği iyileştirebiliriz?

Örneğin bir taşıt paylaşma hizmetini kullanan bir müşteri A noktasından B noktasına varmak ister. Bu isteğine ulaşmak için birbiri ile rekabet eden hizmetler arasında seçim yapabiliyor olmasının yanı sıra tren ve otobüs hizmetleri de birer alternatif sunmakta. Müşterinin kararı çözüm fark etmeksizin bir dizi tercihe dayanacaktır:

• Kolay rezervasyon yapılabilmesi
• Bekleme süresinin çok uzun olmaması
• Yolculuğun rahat geçmesi
• Çok pahalı olmaması vb.

Aynı durum farklı alternatifler arasında seçim yapmak zorunda olan sürücüler için de geçerlidir. Ürünün vizyonunu taşıyacak belirleyici soru, müşterinin temel tercihinin ne olduğudur. Ürünün sonraki neslinde nasıl değişiklikler yapılabilir ki bu değişiklikler müşterinin temel tercihi ile uyumlu olsun. Ürün geliştirme çabalarının en çok önem arz eden meseleye odaklanabilmesi için bu sorular kilit önem taşımaktadır.

2. Şirket projeden ne kazanç bekliyor?

Birkaç yıl önce bir reklam şirketi ev içi iş akış yönetim sistemi geliştirmeye başladı. Projenin hedefi fotoğrafçılara, grafik tasarımcılara, ürün yöneticilerine ve baskıcılara – Excel dosyalarından ve             e-postalardan oluşan karmaşa nedeniyle vakit kaybetmemek adına – her şey dahil bir çözüm üretmekti. Projenin zor olmasının ana nedeni ürün takımının farklı departmanların temsilcilerine erişimlerinin olmamasıydı. İki yılın ardından ürün geliştirilmiş ve çalışır duruma gelmişti fakat lider takım beklenmedik bir sorunla karşılaştı. Şirketin gelirinin büyük bir kısmını bu araca yatırmışlardı ancak bu aracın işletmeye ne gibi katkılar sağladıklarını çözemediler.

“Projenin işletmeye sağlaması beklenen kazanımlar nelerdir?” Baş Mühendisin ve takımının, projenin başlarında cevaplamaları gereken ilk keşif sorularından bir tanesidir. Buradaki amaç:

• ihtiyaç duyulan tüm hissedarlar için öncelikli bir unsur haline getirmeye
• proje için doğru maliyet yapısını belirlemeye ve
• ürün çıktığı zaman kazanımların elde edilişini kontrol etmeye

yardımcı olacak, karşı konulmaz bir iş modeli oluşturmaktır.

Bu örnekte iş modeli, müvekkil takımlar ile daha keyifli etkileşimler sağlayarak müşteri kaybını azaltmaya yönelik olabilirdi. Aynı zamanda yeni reklam kampanyalarının teslim süresini yarıya indirmeye veya grafik tasarım takımlarının üretkenliğini – her ay kişi başı yönetilen tasarım projeleri sayısı olarak ölçülür – arttırmaya yönelik de olabilirdi. Aynı zamanda bahsi geçen ürün olmadan gerçekleştirilemeyecek satışların önünü açarak, işletmenin büyümesine katkı sağlayabilir.

3. Sağlam ve kârlı bir ürün geliştirmek için hangi teknik kararların verilmesi gerekiyor?

Baş Mühendis ve takımı ürün hakkındaki anlayışlarını, ürünün farklı fonksiyonlarının müşterinin algıladığı değere nasıl katkı yapıp yapmadıklarını ve bu fonksiyonların birbiriyle etkileşimlerini keşfederek geliştirir. Ürünün üretiminden önce hangi sorunların çözülmesi gerektiğini bulmaya çalışırlar.

Dalgalı fiyatlandırmayı örnek alın. Bu fonksiyon arzın yüksek olduğu zamanlarda daha fazla sürücüyü cezbederek yolcular için bekleme süresini kısaltır. Fakat bu, yolcu tecrübesini en çok ihtiyaç duyulan anda yüksek fiyatlar nedeniyle zedeler. Aynı zamanda sürücüler için fiyatlandırma politikasını da belirsizleştirir. Sürücüler burada arzın yüksek olduğu izlenimine kapıldıklarında gelirlerinde her hangi bir artış gözlemleyemezlerse aldatılmış hissedebilirler. Bu ölçekte bir servis için bu durumun anlamı yüzlerce veya binlerce ek müşteri hizmetleri araması ve işletme maliyetine büyük bir darbe anlamına gelir.

Bu ve benzeri sorunlar ortaya çıkmadan önce üzerlerine gitmek için Baş Mühendis, ürün fonksiyonlarının müşteri tercihleriyle olan ilişkisini saptamak ve değinilmesi gereken fonksiyon optimizasyonlarına (örn. Yukarıda belirtilen farklı saatlerde farklı ücretlendirmeler) dikkat çekmeleri için takımı görevlendirmekle işe başlar. Hedef, maliyeti yükseltmeden tercihlerin nasıl daha iyi karşılanacağını çözmektir. Takım ayrıca – ürünü karmaşıklaştıran, üretimini ve bakımını zorlaştıran uyuşmazlıkları bulmak için – ürün özelliklerinin birbiri ile olan ilişkisini anlamaya çalışmalıdır.

Takım birçok farklı kombinasyon deneyip performanslarını çözümlemenin yanı sıra obeyada öğrendiklerini özetleyerek, optimizasyonu sağlamanın yollarını öğrenebilir.

Bu evredeki  temel risklerden biri ürünün dokunulmaması gereken yönlerini – kalıtsal teknoloji (ing. heritage technology) –  değiştirerek gereksiz karmaşa yaratan ve inovasyonu önleyen yönleri – kültürel teknoloji (ing. legacy technology) – tutmaktır. İkisi arasındaki ayrımı yapmak her zaman kolay olmadığından ötürü bu durum takım için zorunlu bir mücadele teşkil eder.

Kalıtsal teknoloji ürünün özünü tanımlayan ve varlığını meşrulaştıran her şeydir. Yaygın bir örnek olarak 150 yıl önce daktilonun icadından beri değişmeyen QWERTY ve AZERTY klavyeleri verilebilir. Bu klavye düzenleri mekanik bir zorluğun – sık kullanılan tuşların birbirine karışması – üstesinden gelmek için tasarlandılar. Birkaç klavye şirketi daha verimli düzenlerle daha hızlı bir yazım tecrübesi sunmaya çalışmış olsalar da öykülerini anlatabilecek kadar uzun yaşayamadılar. Dünya genelinde insanlar ilk çıkan klavyelere o kadar alıştılar ki değişme karşı güçlü bir direniş gösterdiler. Kalıtsal teknolojinin özü budur.

Tam tersine tuşların geri sıçramasını sağlayan yay sistemi, yeni yaklaşımların daha sessiz ve daha hızlı yazım tecrübesi sağlamasından ötürü, kültürel teknoloji olarak düşünülebilir. Apple gibi şirketler kalıtsal düzeni koruyarak kültürel çözümleri geliştirmek için sürekli, teknolojinin farklı yönlerine (tuşların şekli ve aralıkları, düşey hareket mesafesi vb.) yatırım yapmaktalar.

Tuş düzeni de bir gün “kültürel” olarak düşünülebilir, özellikle ses tanımlama teknolojisi yazımı tamamen kaldıracak kadar güvenilir hale getirilirse. Takım arasında gerçekleşecek olan bu tartışma hiçbir zaman bitmeyeceği için obeyanın içerisinde gerçekleşmelidir.

4. Rekabetten galip ayrılmak için kaliteli bir ürünü zamanında yetiştirebilecek miyiz?

Keşif ürün geliştirme süreci için de geçerlidir. Baş Mühendis ve takımı:

• Proje boyunca kaliteyi nasıl tanımlayacakları ve kalitenin izini nasıl sürecekleri
• Ürünü zamanında teslim edebilmek için erişmeleri gereken kilometre taşları ve
• Maliyeti nasıl ölçecekleri üzerinde anlaşmalılar.

Kalite, ürünün kendisini ifade eder. Kalite ölçütleri ürün fonksiyonlarının güvenilirlik, performans ve kullanılabilirlik bağlamında müşterinin beklentileri ile ne kadar uyuştuğu üzerine bilgi sağlar. Ürünün ömür döngüsü boyunca rehberlik edecek doğru ölçütleri seçmek için Baş Mühendis ve takımının, hedef müşterileri ile empati kurarak kendilerine şu soruyu sormaları gerekir: “Neyin yanlış gitmemesi gerekir?”. Bir LED ampulü ele alalım: beklenen ömrü, parlaklığı ve rengi karşılaması, aşırı ısınmaması veya şoklara karşı direnci kalite ölçütleri olarak belirlenebilir. Bu nedenle bu ölçütleri tasarım ve gelişim evrelerinde takip etmek gayet akıl kârı bir iş olacaktır. Böylece takım kaliteli bir ürün geliştirirken başarısız oldukları tüm yolları keşfedebilir.

Kaliteye ek olarak Baş Mühendis ve takımı teslim süresini büyük ve görünür bir proje planı ile takip edecektir. Bu plan herkesi ana ürünün kilometre taşlarına uymaları ve her bir takımın eylemlerinin ve kararlarının diğer takımlara olan etkisini görmek için kullanılır. Proje planı, ürünün teslim süresinden taviz vermeden, takım üyelerine sorunları tahmin etmeye ve sorunların çözüm yollarını tartışmaya izin verir. Ancak tüm bunlardan öte proje planı, Baş Mühendise ve takımına şirketin içindeki ve dışındaki hisse sahipleri ve çeşitli takımlarla gerçekleştirilen işbirliğini pekiştirmek için yollar keşfetmeleri sağlayan bir araçtır.

Son olarak obeyalar genelde maliyetleri gözlemlemek için kullanılan ölçütleri içerisinde barındırır. Buna altyapı, destek takımları ve günlük operasyonlar da dahildir. Bir e-ticaret firması ele alınacak olursa sitelerine yeni bir ürün eklemek için ne kadar süre geçeceği, stokların yenilenmesi veya yeni bir promosyon önermek örnek olarak verilebilir. Buradaki amaç takımın verdiği mühendislik kararlarının sadece geliştirmeye değil tüm sürece nasıl etkilediğini keşfetmektir.

Son birkaç on yılda Agile, şelale metodolojilerine – ayrıntıların belirlenmesi, tasarım ve gelişimin ardından sadece aylar sonra ürünlerin gün yüzüne çıktığı – karşı önlem olarak geniş çapta yayıldı. Ürün geliştirme takımlarının projenin erken aşamalarında acele etme eğilimi göstermeleri bu paradigma değişikliğinden kaynaklanan beklenmedik bir sonuç oldu. Bir ekstremden diğerine geçerek, gelişim süreci boyunca artık iteratif sürecin normal bir parçası olarak düşünülen tekrar elden geçirme biçiminde, yeni maliyetler yaratılmış oldu.

Ürünün faydasını doğrulamak adına hızlı üretimin ve doğru hedefe ulaşana kadar sürekli elden geçirmenin, öğrenmek için çok masraflı bir yol olması sorun teşkil ediyor. Bir dizi start up, ürünleri için yeterince iyi bir Pazar bulamadan yatırım fonlarını bu yolla ziyan ettiler. Obeya ürünü geliştirmeye başlamadan önce bilinmeyen sayısını azaltan yenilikçi bir yaklaşım sağlıyor. Böylece çok geç olmadan bir fikirden vazgeçilebilir veya bir fikirle devam etme kararı alınarak ürün herkesten önce pazara sunulabilir. Bu manada obeya teslimattan çok bir keşif aracıdır.

Kaynak–

Yazarlar

Çeviri

Mehmet Talha Kurt

Araştırma Görevlisi

Yalın Enstitü