Ofisten Kaçan Bir Robot Ekip Çalışmasına Ne Öğretti?

Bir robotun ofisten kaçması, kulağa kötü bir iş günü başlangıcı gibi geliyor.

Hele robot altı bacaklıysa ve sizi masanızın etrafında kovalamaya başladıysa.

Ama 1990’ların başında Cambridge, Massachusetts’te yaşanan bu tuhaf olay, yıllar sonra dünyanın dört bir yanında kullanılan bir çalışma yönteminin hikâyesine dönüşecekti.

Robotun adı bile önemli değil.

Hikâyenin asıl başrolünde Dr. Jeff Sutherland var.

Sutherland’in 2014 tarihli Scrum kitabı “yarı zamanda iki kat iş” vaadiyle tanınıyor. Bu vaadin izini sürünce, bir ofiste kontrolden çıkan altı bacaklı bir robottan batmak üzere olan bir FBI projesine kadar uzanan oldukça tuhaf bir hikâye çıkıyor.

Her Bacağın Kendi Beyni Olan Robot

Sutherland, Vietnam’da keşif uçağı uçurmuş eski bir pilot. Savaştan sonra Stanford Üniversitesi’nde istatistik okumuş, Colorado Üniversitesi Tıp Fakültesi’nde Biyometri doktorası yapmış. Robotla tanıştığında şirketlerde mühendislik yöneticiliği yapıyor ve ofisi MIT’ye birkaç sokak mesafedeki bir binada.

Kedi büyüklüğündeki robot, aynı binada yer kiralayan genç bir robot şirketinin laboratuvarından kaçıyor. Sutherland 2005’te yazdığı bir blog notuna göre şirket binaya 1990’da taşınmış ve robotların kaçması birkaç günde bir tekrarlanan bir hadise haline gelmiş.

Bir cuma akşamı Sutherland, robot şirketinin kurucularından Prof. Rodney Brooks ile konuşuyor. MIT’de robotik üzerine çalışan Brooks, ona robotun nasıl yürüdüğünü anlatıyor.

İşin ilginç tarafı şu: Robotun merkezi bir beyni yok. Altı bacağın her birinin kendi beyni var.

Her biri birkaç basit kurala göre hareket ediyor. Robot çalıştırıldığında yürümeyi yeniden öğreniyor.

Çünkü Brooks’un ifadesiyle, “dünya onun veri tabanı.”

Sutherland’in aklına o anda başka bir soru geliyor: İnsan ekiplerini de böyle çalıştırabilir miydik?

Herkese uzun uzun ne yapacağını anlatmak yerine, birkaç basit kural verip insanların kendi kararlarını vermesini sağlayabilir miydik?

Brooks’un cevabı kısa:

“Bilmiyorum. Neden denemiyorsun? Nasıl sonuçlandığını bana da haber verirsin.”

Sutherland gerçekten deniyor.

Bu konuşma, yıllar sonra 2014’te yayımlanan SCRUM: İki Katı İşi Yarı Zamanda Yapma Sanatı (Scrum: The Art of Doing Twice the Work in Half the Time) kitabının ikinci bölümüne giriyor.

Kitabın adı zaten iddialı:

Yarı zamanda iki kat iş.

Ben bu kitabı 2020’de, pandeminin ortasında okudum, aslında çıkış tarihine bakılırsa bi hayli de geç okumuşum. Bugün dönüp bakınca robot hikâyesi daha anlamlı geliyor. Çünkü mesele daha hızlı çalışan ekipler değil, birbirlerinin yoluna çıkmadan çalışabilen ekipler.

Yarı Zamanda İki Kat İş mi? 451 Milyon Dolarlık Proje Nasıl Kurtarıldı?

FBI 2005’te Sentinel adlı yeni vaka dosyası sistemini duyurduğunda bütçe 451 milyon dolardı. Sistemin 2009’da çalışır hale gelmesi planlanıyordu.

Mart 2010’da tablo şöyleydi: Yüklenici Lockheed Martin 405 milyon doları (450.000.000$) harcamıştı. Projenin ancak yarısı tamamlanmış, teslim tarihi de bir yıl geriye kaymıştı. Bağımsız bir analiz, kalan işin altı ila sekiz yıl (yanlış görmediniz 6 ile 8 yıl ve 350.000.000 $) ve en az 350 milyon dolar daha gerektirdiğini hesaplıyordu.

Yani paranın neredeyse tamamı gitmişti, işin yarısı ortada yoktu.

FBI’ın yeni bilgi işlem yönetimi projeyi yükleniciden alıp kurum içine taşıdı. Sutherland’e göre ilk iş, o güne kadar birikmiş 1100 gereksinimi masaya koymaktı. Kâğıda dökülünce birkaç santim kalınlığında bir yığın çıktı.

Bu yığına bakan çoğu ekip ilk maddeden başlar. Onlar başlamadı.

Önce her gereksinimi yaratacağı değere göre sıraladılar. En çok değer üreten iş en üste, daha az önemli olanlar aşağıya gitti. Scrum’ın ürün iş listesi (product backlog) dediği şey tam olarak bu: yapılacak her şeyin aynı önemde olmadığı fikrini görünür hale getirmek.

Sonra işi iki haftalık sprintlere böldüler.

Kural basitti; her sprintin sonunda bir görev listesi değil, kullanıcıya gösterilebilecek ve gerçekten çalışan bir ürün parçası olacaktı.

Fark burada.

Büyük projelerde “işin yüzde 80’i tamamlandı” cümlesini herkes duymuştur. Ama bu cümlenin gerçekte ne anlama geldiğini kimse tam olarak söyleyemez. Kalan yüzde 20 bazen iki hafta, bazen iki yıldır.

Çalışan bir ürün parçası ise pazarlık kabul etmez. Ya çalışıyordur ya çalışmıyordur. Ve kullanıcı onu kendi gözüyle görür.

ABD Adalet Bakanlığı Genel Müfettişliği’nin Ekim 2010 raporu bu plana açıkça kuşkuyla baktı. FBI, projedeki yüklenici çalışanı yaklaşık 220’den 40’a, kendi personelini 30’dan 12’ye indirip işi kalan yaklaşık 20 milyon dolarla on iki ayda bitirmeyi hedefliyordu.

On iki ay yetmedi. Kodlama on sekiz ay sürdü, sistemi bütün kuruma yaymak iki ay daha aldı ve Sentinel Temmuz 2012’de açıldı. Projeden sorumlu Jeff Johnson’a göre ekiplerin verimliliği bu süreçte üç katına çıktı. Johnson’ın en etkili bulduğu şey ise her iki haftada bir çalışan ürünü onu kullanacak insanlara göstermekti. Bu toplantılarda zaman zaman FBI direktörü de oturuyordu.

Kitapta aktarılan sözleri şöyle: “Scrum geliştiricilerle ilgili değil. Müşterilerle ve paydaşlarla ilgili.”

Kâğıttaki Plan Sahaya İnerse

Sutherland’in Gantt şemalarıyla ilgili eleştirisini okurken en çok şu kısmın altını çizdim.

Çünkü bir projenin başında plan yapmak kolaydır.

Henüz herkes aynı masadadır, tarihler mantıklı görünür, bağımlılıklar kontrol altındadır. Hangi işin ne zaman başlayacağını, ne zaman biteceğini, kimin yapacağını yazarsınız. Gantt şeması da bütün bunları güzelce bir araya getirir.

Bir süreliğine proje gerçekten kontrolünüzdeymiş gibi hissedersiniz.

Sonra proje başlar.

Bir iş beklenenden uzun sürer. Müşteri önceliğini değiştirir. Bir onay gecikir. Başka bir ekibin teslimini beklersiniz. Daha önce görünmeyen bir bağımlılık çıkar.

Ve o ilk gün yaptığınız plan, yavaş yavaş gerçekle arasındaki mesafeyi açmaya başlar.

Sutherland bu şemalar için tek cümle kuruyor: “Tek sorunları, her zaman, ama her zaman yanlış olmaları.”

Proje yönetirken bence kritik nokta tam burada.

Çünkü planın bozulması zaten beklenmedik bir şey değil. Asıl problem, plan bozulduktan sonra ne yaptığınız.

Sutherland, ziyaret ettiği pek çok şirkette tek işi o Gantt şemasını her gün güncellemek olan insanlar bulunduğunu yazıyor. Plan gerçekle karşılaşınca dağılıyor. Ama yöneticiler planı sorgulamak yerine, planın işliyormuş gibi görünmesini sağlayacak insanlar tutuyor. Raporlar, anlatmaları gereken gerçeklikten daha önemli hâle geliyor.

Bu kısmı okuyunca insanın aklına ister istemez şu geliyor:

Bir noktadan sonra projeyi mi yönetiyorsunuz, yoksa projenin raporunu mu?

Sutherland bunun için çok daha sert bir ifade kullanıyor: “Aslında insanlara kendilerine yalan söylemeleri için para ödüyorlar.”

Sutherland, Easel’da CEO’ya kariyeri boyunca kaç Gantt şeması gördüğünü soruyor. “Yüzlerce.” Kaçı doğru çıktı? Kısa bir duraksama: “Hiçbiri.”

Önerisi plansızlık değil, ölçüm. Ekibin bir sprintte gerçekte ne kadar iş bitirdiğine bakıyorsunuz, buna “hız” diyorsunuz ve tarihi o hıza göre veriyorsunuz. Dijital projelerin neden battığı sorusunun bir cevabı da bu: plan ile saha arasındaki farkı çoğu zaman kimse yüksek sesle söylemiyor.

Küçük Ekip, Normal Mesai, Kahraman Yok

Proje ekibi kurulurken genelde aynı refleks çalışır.

İş büyükse ekip de büyük olmalı.

Kitap tersini söylüyor: ideal ekip yedi kişi, artı eksi iki. Yazılım araştırmacısı Lawrence Putnam’ın 491 projeyi incelediği çalışmaya göre üç ila yedi kişilik ekipler aynı işi, dokuz ila yirmi kişilik ekiplerin harcadığı eforun yaklaşık yüzde 25’iyle bitiriyor.

Gerekçe basit bir hesap: n kişilik ekipte iletişim kanalı sayısı n(n-1)/2.

5 kişide 10 kanal var. 10 kişide 45.

Proje yönetirken sık gördüğüm şey de bu. Ekibe yeni biri katıldığında toplantı biraz uzar, yazışma zinciri biraz büyür.

Mesai için de benzer bir şey geçerli. OpenView Venture Partners’ın kurucusu Scott Maxwell, daha fazla saatin daha fazla iş getirmediğini görmüş. Kitaptaki eğriye göre verimliliğin zirvesi haftada kırk saatin biraz altında. Maxwell insanları erken eve göndermeye başlamış: geç saate kadar çalışmak bağlılık değil, başarısızlık işaretiymiş.

Projeyi kendi kahramanca çabasıyla kurtaran kişi genelde alkışlanır. Sutherland bunu sürecin temel bir kusuru sayıyor: “Kahramanca çaba, bir planlama başarısızlığı olarak görülmeli.”

Bence kahraman gerektiren her teslim, planda görülmemiş bir şeyin işaretidir.

Toyota’dan gelen ilke de bu: yönetimin temel işlerinden biri, akışın önündeki engelleri kaldırmak. Yanlış yeri hızlandırmak işe yaramıyor.

Aynı Anda Beş Proje Yürütmenin Bedeli

Aynı kişinin üç, dört projeye birden yazılması proje dünyasında olağan bir durum.

Kâğıtta herkes tam dolu görünür.

Sutherland, Gerald Weinberg’in Quality Software Management kitabındaki bir tabloya dayanıyor. Aynı anda iki projeye bakan biri zamanının yüzde 20’sini işler arasında geçiş yaparken kaybediyor. Üç projede kayıp yüzde 40, beşte yüzde 75. Sutherland’in ifadesiyle: “İşinizin tam yüzde 75’i hiçbir yere gitmiyor.”

Kitaptaki örnekte üç projesi olan bir ekip hepsine biraz biraz çalışırsa işi temmuz sonunda bitiriyor. Projeleri tek tek bitirirse aynı iş mayıs başında bitiyor.

Projeler küçülmüyor. İş değişmiyor.

Değişen tek şey sıra.

Proje yönetirken bence en zor kararlardan biri de bu: bir işi bekletmek. Bekleyen her işin bir sahibi, bir beklentisi var. Ama hesap ortada. Her şeyi aynı anda ilerletmeye çalışmak hepsini geciktiriyor.

Hızlı Bir Ekibin Bile Yöne İhtiyacı Var

Küçük bir ekip kurdunuz. Mesaiyi normale çektiniz. İşleri tek tek bitiriyorsunuz.

Geriye bir soru kalıyor: Önce hangisi?

Sentinel’deki 1100 maddelik yığını değere göre sıralamak da bir karardı. Kitap bu kararı “ürün sahibi” denen role veriyor. Sekizinci bölümün özetindeki ifadeyle: “Lider patron değildir. Ürün sahibi neyin yapılması gerektiğini ve nedenini ortaya koyar. Bunun nasıl ve kimin eliyle yapılacağı ekibe kalmıştır.”

Proje yönetirken bu ayrımı çok değerli buluyorum. “Ne” ve “neden” netse, “nasıl” sorusunu ekibe bırakmak kolaylaşıyor.

Brooks’un robotunda da bacaklar kendi kararını veriyordu, ama başındaki çip bütün parçalar için hakemlik yapıyordu.

Kitapta yarı zamanda iki kat iş, daha hızlı koşmanın değil, daha az boşa koşmanın sonucu olarak anlatılıyor. Ekip küçük kalıyor. İşler tek tek bitiyor. Plan her sprintte gerçekle karşılaştırılıyor.

Scrum adını ragbiden alıyor. Sutherland’in anlattığı benzetmede oyuncular yalnızca hızlı koşmuyor; aynı zamanda topun nereye gideceğini biliyor.

Çünkü sahada altı kişi birbirinden bağımsız ne kadar hızlı koşarsa koşsun, takım olarak hiçbir yere varamayabilirsiniz.

Robotun altı bacağının da kendi beyni vardı.

Ama hepsi aynı robotun parçasıydı.

Belki iyi ekiplerin sırrı da bu: Herkesin ne yapacağını söylemek değil, herkesin neden aynı yöne gittiğini bilmesini sağlamak.

Ve belki “yarı zamanda iki kat iş” denen şey de aslında daha hızlı çalışmak değil.

Boşa koşmamaktır.