Mustafa Sönmez

Önce “Niye?” Diye Sormak

Türkçedeki “mühendis” kelimesiyle İngilizcedeki “engineer”ın geçmişi arasındaki fark ilgimi çekiyor. Mühendis, Arapçada geometri anlamına gelen “hendese” ile ilişkili; kelimenin geçmişi Farsçadaki ölçü ve ölçme anlamlarına uzanıyor. Engineer ise engine ile aynı kökten geliyor. Buradaki engine yalnızca motor anlamında değil; geçmişinde mekanik düzenekler ve savaş makineleri var. Daha gerideki Latince “ingenium” ise yetenek, zekâ ve beceri anlamları taşıyor. Doğrudan “invent” kelimesinden türemiyor.

Birinde ölçmek ve hesaplamak, diğerinde bir düzenek tasarlamak daha belirgin bir çağrışım yapıyor. Buradan “Biz inşaat yaparız, onlar icat eder” sonucunu çıkarmak kolay ama haksızlık olur. Bizde modern mühendislik eğitiminin önemli başlangıçlarından biri gemi inşaatı ve deniz haritalarıyla ilgili. İngilizcedeki kelimenin tarihinde de askerî ihtiyaçlar bulunuyor. Gerçek hayat, kelimelerin çağrışımlarından daha karışık.

Yine de bu fark bana şunu düşündürüyor: Biz mühendisten ne bekliyoruz? Verilmiş bir işi doğru hesaplarla tamamlamasını mı? O işin neden yapılacağını da düşünmesini mi?

Bence mühendisliğe başlarken sormamız gereken ilk soru “Niye?”

Oysa aklımız çoğu zaman doğrudan “Nasıl?”a gidiyor. Hangi parçayı kullanacağız, hangi dilde yazacağız, bağlantıyı nasıl kuracağız, kaç günde bitireceğiz? Ben de kendimi bu soruların içinde buluyorum. Bir problem anlatılırken daha karşımdaki sözünü bitirmeden çözüm düşünmeye başlayabiliyorum. Bildiğim bir işe benziyorsa zihnim daha da hızlı ilerliyor.

Bunun iyi bir tarafı var; deneyim işe yarıyor. Ama o hızla birlikte bazı şeyleri de kabul etmiş oluyorum. Bana anlatılanın problemin tamamı olduğunu, istenen çözümün gerekli olduğunu, eksik bir bilgi bulunmadığını…

Doğrudan nasıl yapacağımıza geçtiğimizde, “Burada eksik bir şey var mı?” diye sormak zorlaşıyor. Artık bir yol seçmiş oluyoruz. Sonraki düşüncelerimiz de çoğunlukla o yolda ilerlemeye yarıyor.

Bir işletmenin yeni bir rapor istediğini düşünelim. Alanları belirler, sorguyu yazar, filtreleri ekleriz. Rapor da gayet düzgün çalışır. Fakat niye istendiğini biraz konuştuğumuzda, kullanıcının mevcut iki ekrandaki rakamlara güvenemediğini öğrenebiliriz. Asıl ihtiyaç üçüncü bir rapor değil, rakamların neden farklı olduğunu anlayabilmektir.

İstenen işi eksiksiz yapmış, sorunu olduğu yerde bırakmış olabiliriz.

Benim için özgün mühendisliğin başladığı yer biraz burası. Problemi kendi gözünle incelemek, anlatılanı anlamaya çalışmak, gerektiğinde yeniden tarif etmek. Her parçayı kendin icat etmen gerekmiyor. Hazır bileşenlerle, bilinen yöntemlerle de özgün bir çözüm geliştirebilirsin. Yeter ki neden o çözümü seçtiğini biliyor ol.

Yazılım, elektronik ve saha sistemleri arasında çalışırken bu ihtiyacı daha fazla hissediyorum. Bir cihaz veri gönderiyor, yazılım kaydediyor, ekranda bir sayı görünüyor. İlk bakışta her şey tamam. Ama veri yarım saat önce gelmişse? Bağlantı kesildiği hâlde ekranda hiçbir şey değişmemişse? Kullanıcı o sayıya bakıp karar veriyorsa?

O noktada küçük görünen bir teknik ayrıntı, bir başkasının işini etkiliyor. Bizim sistemin nasıl çalıştığını biliyor olmamız yetmiyor. Kullanan kişinin de neye güvenebileceğini anlayabilmesi gerekiyor.

Bu yüzden mühendisten ne beklendiği, benim için sosyolojik bir mesele de. Bir kurumda sürekli işi yetiştirmek ödüllendiriliyor, sorunun nedenini araştırmak vakit kaybı sayılıyorsa insanlar buna göre çalışmayı öğreniyor. “Niye böyle yapıyoruz?” sorusu her seferinde huzursuzluk yaratıyorsa, bir süre sonra daha az soruluyor.

Sonra aynı insanlardan yenilikçi olmalarını bekliyoruz.

Birinin fikrini söylemesi için o fikrin hemen kabul edilmesi gerekmiyor. Ama dinleneceğini bilmesi gerekiyor. Gördüğü eksiği dile getirdiğinde başına iş alacağını düşünüyorsa, susmayı seçebilir. Dışarıdan bakınca ilgisiz görünür. Belki de daha önce yeterince uğraşmış, karşılık bulamamıştır.

Bence mühendislik kültürünü değerlendirirken buraya bakmalıyız. Hangi kelimeyi kullandığımız kadar, soru soran kişiye nasıl davrandığımız da önemli. Mühendise yalnızca uygulama sorumluluğu mu veriyoruz, kararın oluşmasına da katılmasını mı istiyoruz? Bir deneme sonuç vermediğinde ne öğrendiğimizi konuşabiliyor muyuz?

Elbette aynı soruları kendimize de sormamız gerekiyor. Başkasının talebindeki eksiği görmek, kendi fikrimizdekini görmekten daha kolay.

Bir tasarıma emek verince insan ona bağlanıyor. Neden öyle yaptığını, hangi güçlükleri aştığını biliyor. Birisi gelip eksik tarafını gösterdiğinde bazen ilk tepki savunmak oluyor. Söyleneni dinlemek yerine, ne kadar uğraştığını anlatmak istiyorsun.

Bunu insani buluyorum. Ama o duyguyla teknik karar vermek sorun çıkarabiliyor. Bir çözüm için çok uğraşmış olmamız, onun doğru olduğuna kanıt olmuyor.

Mühendislikte olgunlaşmayı biraz da burada görüyorum. Kendi kararına yeniden bakabilmekte. “Ben bunu niye böyle yaptım?” diye sorabilmekte. İhtiyaç bunu gerektirdiği için mi, alışık olduğum yöntem bu olduğu için mi? Elimde ölçüm mü var, yoksa güçlü bir tahmin mi?

Hata çıktığında da aynı dikkat gerekiyor. Sistemi yeniden başlatınca sorun kaybolabilir. Ama neden kaybolduğunu bilmiyorsak içimiz rahat etmemeli. Hangi koşulda ortaya çıktı, neyi yanlış varsaydık, tekrar ederse bunu nasıl anlayacağız? Her şeye hemen cevap bulamayabiliriz. En azından bildiğimizle tahmin ettiğimizi ayırabiliriz.

Bir de işin başkasına kalan tarafı var. Bir sorun çıktığında herkes beni aramak zorundaysa, sistemin bir kısmı hâlâ yalnızca benim kafamda duruyor demektir. Başka birinin anlayabileceği kod yazmak, kararları kaydetmek, işe yarayan hata mesajları bırakmak gerekiyor. Bazen bunlarla uğraşmak yeni bir özellik geliştirmek kadar keyifli gelmiyor. Ama bir gün o sorunun başına oturacak kişinin bunlara ihtiyacı olacak.

Ben hâlâ bir şeyin ilk kez çalıştığı anı seviyorum. Devreden cevap gelmesini, verinin doğru okunmasını, günlerdir uğraştığın işlevin sonunda beklediğin gibi davranmasını. O rahatlamayı biliyorum.

Şimdi o anın öncesine biraz daha dikkat etmek istiyorum. Çözümü bulma hevesiyle soruyu kaçırmamaya. Bir işi yapabildiğimi göstermek için hemen başlamamaya.

Önce niye ihtiyaç duyulduğunu anlayalım. Bir şey eksikse konuşalım. Nasıl yapacağımıza ondan sonra karar verelim.

← Tüm mühendislik yazıları