Apollo ve sistem yönetimi

Sahadan bir an

Perşembe sabahı, satın alma ofisi. Gülşen, yeni giriş kontrol alanı için sipariş ettiği tablet duvar askılarının faturasına bakıyor. Ilgın içeri giriyor; elinde telefonu.

Ilgın: Gülşen, Onur yazdı. Tablet modelini değiştirmiş, yenisi daha ucuz ve daha hafifmiş.

Gülşen: Ne zaman değiştirdi? Duvar askıları dün geldi, eski modelin ölçüsüne göre.

Ilgın: Geçen hafta. Bana sadece "daha ucuz buldum" dedi.

Gülşen: Yeni tablet askıya oturmuyorsa askıları iade ederiz, ama kılıflar da sipariş edildi. Eldivenle kullanılacak kalın kılıflar.

Ilgın: Bir de şarj yeri var. Bakım, prizleri eski tabletin kablosuna göre çekti.

Gülşen: Yani bir şey ucuzladı, üç şey bozuldu.

Onur'un kararı kendi açısından doğruydu: daha ucuz, daha hafif bir tablet buldu. Ama tablet tek başına bir parça değildi; duvar askısına, kılıfa ve şarj noktasına bağlıydı. Bir parçadaki değişiklik, haberi olmayan üç parçayı bozdu. Bu sorun Ilgın'ın küçük programına özgü değil; aynı soru, 1950'lerin ve 1960'ların dev füze ve uzay programlarında çok daha büyük bir ölçekte soruldu. Bu ders, o programların bu soruya verdiği cevaba, sistem yönetimine bakıyor.

Kavram

Bir program binlerce parçadan oluştuğunda ve bu parçalar farklı ekipler, farklı firmalar, hatta farklı ülkeler tarafından yapıldığında, en büyük risk tek bir parçanın kötü yapılması değil, iyi yapılmış parçaların birbirine uymamasıdır.

Sistem yönetiminin en somut araçlarından biri, değişiklikleri izlemektir.

Parçaların birbirine değdiği yerlerin de bir adı var: arayüz. Askının tabletle buluştuğu yer, kılıfın eldivenle, şarj kablosunun prizle buluştuğu yer birer arayüzdür. Büyük programlarda arayüzler ayrı ayrı yazılır, çünkü iki ekibin her biri kendi parçasını mükemmel yapıp yine de arayüzde anlaşamayabilir. Bir arayüzün iki tarafı vardır ve her iki tarafın sahibi de onun nasıl tanımlandığını bilmelidir; birinin değiştirdiği şeyi öbürü duymazsa sorun tam orada ortaya çıkar.

Ilgın'ın tablet sorunu, konfigürasyon yönetiminin yokluğunun küçük bir örneği. Tablet modeli değiştiğinde, ona bağlı askı, kılıf ve şarj noktası güncellenmedi, çünkü değişikliğin kime etkisi olduğunu soran bir düzen yoktu. Onur'un bir hatası yoktu; hatası olan, değişikliğin yalnızca bir kişinin kararı olarak kalmasıydı.

Sistem yönetimi bir de aşama fikrini öne çıkardı: büyük bir programı, her biri bir inceleme ve bir kararla biten aşamalara bölmek. Tasarım bitince bir inceleme, üretime geçmeden bir inceleme, kullanıma geçmeden bir inceleme. Her inceleme, bir sonraki aşamaya hangi bilgiyle geçildiğini sabitler. Bugün birçok kurumda kullanılan aşama kapıları bu fikrin akrabasıdır; onları yönetişim modülünde ayrıca işleyeceğiz.

Bir belediye kültür merkezinin açılışını düşün. Sahne ekibi, son hafta sahneyi yirmi santim yükseltmeye karar veriyor; daha iyi görünecek. Ama ışık direkleri eski yüksekliğe göre ayarlanmış, ses sisteminin hoparlörleri sahnenin kenarına göre konmuş ve tekerlekli sandalye rampası eski yükseklik için yapılmış. Sahneyi yükselten karar, haberi olmayan üç ekibin işini geçersiz kılıyor. Konfigürasyon yönetimi burada basit bir soruyla başlar: "Bu değişiklik kime dokunuyor?"

Perde arkası

Sistem yönetiminin tarihini, onu Amerikan ve Avrupa uzay programlarında karşılaştırmalı olarak inceleyen bir kitap anlatır.

Johnson'ın "yenilik için bir bürokrasi" ifadesi, sistem yönetiminin iki yüzünü bir arada taşır. Bir yandan, binlerce parçanın birbirine uymasını sağlayan disiplin olmadan aya gidilemezdi. Öbür yandan, bu disiplin kâğıt, onay ve toplantı demekti ve onu yaratan mühendislerin çoğu bu bürokrasiyi istemezdi. Bugün proje yönetimindeki birçok tartışma, denetim ile esneklik arasındaki bu gerilimin devamıdır. İleride çevik yaklaşımları işlerken bu gerilimle yeniden karşılaşacağız: ağır denetime bir tepki olarak doğan yöntemler de, parçaların birbirine uymasını sağlamanın kendi yollarını bulmak zorunda kaldı. Soru değişmedi; cevaplar değişti.

Yaygın yanılgılar

İki sürüm

Gülşen'le konuştuktan sonra Ilgın, tablet değişikliğinin nasıl yapılması gerektiğini Onur'a yazıyor. Aynı değişiklik, iki yol.

Zayıf sürüm

Onur: Tablet modelini değiştirdim, daha ucuz ve hafif.

Ilgın: Tamam, güzel olmuş.

Gülşen: Askılar, kılıflar ve şarj yeri eski modele göre; şimdi ne olacak?

Güçlü sürüm

Değişiklik önerisi: Tablet modeli A'dan B'ye; B daha ucuz ve daha hafif. Öneren Onur.

Dokunduğu parçalar: Duvar askısı (Gülşen, sipariş edildi), eldivenli kılıf (Gülşen, sipariş edildi), şarj noktası (bakım, prizler çekildi), form ekranı (Onur, ekran boyutu değişiyor).

Etkisi: Askı ve kılıf iadesi ve yeniden sipariş; bakımın yarım günlük işi; tasarruf bu maliyetleri karşılıyor mu, hesaplanacak.

Karar: Ilgın, Gülşen ve Onur birlikte; onaylanana kadar eski model geçerli.

Zayıf sürümde değişiklik bir haber gibi iletiliyor ve Ilgın onu bir haber gibi karşılıyor. Sorun, Gülşen'in sorusunda ortaya çıkıyor, ama artık askılar gelmiş ve prizler çekilmiştir. Güçlü sürüm aynı değişikliği bir öneriye çeviriyor ve sistem yönetiminin temel sorusunu soruyor: bu değişiklik kime dokunuyor? Dokunduğu dört parçayı ve her birinin sahibini yazıyor, etkisini maliyetiyle birlikte görünür kılıyor ve kararı tek kişiden alıp parçaların sahiplerine veriyor. En önemli satır sonuncusu: onaylanana kadar eski model geçerli. Bu, herkesin aynı güncel tasarım üzerinde çalışmasını sağlayan konfigürasyon yönetiminin en küçük hâli.

Bağlam notu

Sistem yönetiminin disiplini, ölçeğine uygun kullanılmazsa Johnson'ın andığı bürokrasiye dönüşür. Her küçük değişikliği yazılı bir öneriye, bir kurula ve bir imza zincirine bağlamak, iki kişilik bir projede yeniliği öldürebilir. Bir tablet kılıfının rengini değiştirmek için bir değişiklik kurulu toplamak, sistem yönetimi değil, onun karikatürüdür.

Değer kimin için? Bir değişiklik denetiminin değeri, değişikliğin dokunduğu parçaların sayısına ve geri almanın maliyetine bağlıdır. Tablet modeli dört parçaya dokunuyor ve geri almak pahalı; öneri yazmaya değer. Kılıfın rengi hiçbir şeye dokunmuyor; Onur'un tek başına karar vermesi yeter. Konfigürasyon yönetimini her şeye aynı ağırlıkla uygulamak yerine, değişikliğin kime dokunduğuna göre ölçeklemek gerekir. Bu ayrımı baştan yazılı bir kurala bağlamak, her seferinde yeniden tartışmaktan daha ucuzdur ve ekibe neye tek başına karar verebileceğini söyler.

Uygulama

Retro sorusu

Pilot projende, başka bir parçaya dokunduğunu düşünmeden yapılmış bir değişiklik oldu mu ve bedelini kim ödedi?

Kapanış

1. Büyük programlarda en büyük risk, iyi yapılmış parçaların birbirine uymamasıdır; sistem yönetimi parçaları birbirine bağlı bir bütün olarak yönetir.
2. Konfigürasyon yönetimi, bir değişikliğin etkisi bilinmeden ve onaylanmadan uygulanmasını önler ve herkesin aynı güncel tasarım üzerinde çalışmasını sağlar.
3. Sistem yönetimi Soğuk Savaş füze programlarında doğdu ve uzay programlarına geçti; ölçeğine uygun kullanılmazsa "yenilik için bir bürokrasi"ye dönüşür.

Beş soru

1. Onur'un tablet değişikliği neden üç parçayı birden bozdu?
2. Konfigürasyon yönetiminin amacı değişikliği engellemek midir?
3. Johnson'a göre sistem yönetimi nerede doğdu ve nereye yayıldı?
4. Bir derneğin bağış kampanyasında tasarımcı, broşürün boyutunu son anda büyütüyor; zarflar, posta ücreti ve standlardaki broşür kutuları eski boyuta göre hazırlanmış. Hangi soru sorulmadı?
5. Güçlü sürümdeki "onaylanana kadar eski model geçerli" satırı neden önemlidir?

Yanıtlar

1. Çünkü tablet tek başına bir parça değildi; duvar askısına, kılıfa ve şarj noktasına bağlıydı. Değişiklik, bu bağlı parçaların sahiplerine sorulmadan yapıldı ve onlar eski modele göre çalışmaya devam etti.
2. Hayır. Amacı, değişikliğin etkisi bilinerek ve ilgili sahiplerin haberiyle yapılmasını sağlamaktır. Çekici yanlış cevap "denetim yeniliği yavaşlatır, bu yüzden küçük projelerde gereksizdir" olurdu; denetimin ağırlığı ölçeğe göre ayarlanır, ama soru her ölçekte geçerlidir.
3. Amerikan Hava Kuvvetleri'nin Soğuk Savaş dönemi kıtalararası balistik füze programlarında doğdu; oradan NASA'ya ve Avrupa Uzay Ajansı'na yayıldı.
4. "Bu değişiklik kime dokunuyor?" Broşürün boyutu zarflara, posta ücretine ve stand kutularına bağlıydı; değişiklik bu parçaların sahiplerine sorulmadan yapıldı.
5. Çünkü herkesin aynı güncel tasarım üzerinde çalışmasını sağlar. Bir değişiklik tartışılırken bazı ekipler yeni, bazıları eski modele göre çalışırsa, uyumsuzluk büyür; kararın verildiği ana kadar tek bir geçerli tasarım vardır.

Sonraki derse köprü

Sistem yönetiminin araçları, füze ve uzay programlarında bir avuç uzmanın bilgisi olarak doğdu. 1960'larda bu bilgiyi paylaşan, standartlaştıran ve öğreten meslek kuruluşları ortaya çıkmaya başladı. 2.5, proje yöneticiliğinin bir meslek olarak kurumlaşmasını, kuruluşları ve standartlarıyla birlikte anlatıyor.