Konuk Yazılar

  • Yazı Büyüklüğü A(-) A(+)
  • Paylaş

İstanbul Üniversitesi Elektronik Mühendisliği Bölümü’nden 1999 yılında mezun oldu. Yüksek lisansını tamamladığı Gebze Yüksek Teknoloji Enstitüsü Bilgisayar Mühendisliği Bölümü’nde doktora eğitimini sürdürmektedir. 2003-2009 arasında Sağlık Bakanlığı’nın Aile Hekimliği Bilgi Sistemi, Merkezi Hastane Randevu Sistemi ve Ulusal Sağlık Bilgi Sistemi (Sağlık-NET) gibi bilişim projelerinde danışman ve proje yöneticisi olarak çalıştı. Ardından sağlık sigorta sektöründe uluslararası bir şirkette (CGM) 5 yıl boyunca Ar-Ge Direktörü olarak görev yaptı. Çalışma alanları veri madenciliği, insan-bilgisayar etkileşimi ve yazılım mühendisliğidir. Halen Medipol Üniversitesi Teknoloji Transfer Ofisi Direktörü olarak görev yapan ve aynı üniversitede dersler veren Köse, evlidir ve bir çocuk babasıdır.

Tüm Yazıları İçin Tıklayınız

Mühendislerin sağlık ile imtihanı: Sağlık alanında mühendis yönetme sendromu

Bu yazıyı okumadan önce, dergimizin yine bu sayısında Prof. Dr. Sabahattin Aydın Hocamızın “Sağlığın Bilişimle İmtihanı” başlıklı yazısını da incelemenizi öneririm. Sabahattin Hocamız, sağlık bilişimi ile ilgili kavramsal yapıyı elden geçirip sağlık sisteminde bilişimin yeri ve sistemsel problemleri detaylı şekilde ele alıyorken, bendeniz de bu yazımda mesleki ve davranışsal açıdan mühendislerin sağlık bilişimi alanında yaşadıklarını irdelemeye ve somut bazı önerilerde bulunmaya gayret ettim. Mühendislerin davranış modelini, düşünme yapılarını ve çalışma ortamlarını incelemeye mühendisliğin ne olduğunu açıklayarak başlayalım…
Mühendislik nedir?
SD Dergisi’nin 25.sayısında “Sağlık Sistem Mühendisliği” başlıklı bir yazı kaleme almıştık. Bu yazıda sağlık, sistem ve mühendislik kavramlarını ve bunların yönetimin nasıl ayrılmaz bir parçası olduğunu detaylıca incelemiştik. O yazıda yaptığımız mühendislik tanımını tekrar hatırlayalım: “…Amerikan Mühendisler Konseyi’nin tanımına göre mühendislik; “bilimsel prensiplerin tek başlarına veya bir arada, alet, malzeme, yapı, makine, süreç ve sistem tasarlamak ve geliştirmek için uygulamaya geçirilmesi ve yine bu prensiplerin, sistemsel davranışlarının belirli şartlar altındaki davranışlarının tahmin edilmesi (modellenmesi) ve tahmin edilmesi suretiyle, süreçlerin daha ekonomik, insan hayatı ve eşyanın daha güvenli hale getirilmesi için kullanılmasıdır” (http://www.abet.org). Mühendislik, yüzyıllardır bilimsel prensiplerin insan hayatına faydalı olabilmesi için çok sayıda çıktı üretmiştir. Yaşadığımız evden, kullandığımız araca; kıyafetimizden, yediğimiz gıdaların üretimine, bilgisayarımızdan, cep telefonumuza ve Internete kadar hayatımızın her alanında mühendislik ürünleri ve süreçleri vardır. Tüm bunların geliştirilmesinde mühendisliğin temel fonksiyonu, yeni teknolojilerin geliştirilmesi, var olan teknoloji ve bilimsel prensiplerin yeni sistemler üretilmesi için uygulamaya geçirilmesinde aracı olmaktır. Bu açıdan, “hangi alanda bilimsel prensiplerden yararlanılmak isteniyorsa, o alanda mühendislik çalışmasına ihtiyaç vardır diyebiliriz.”
Kısaca, yaşamın her alanında mühendislerin ürettiği ürünleri veya teknolojileri kullanıyoruz. Peki, bu meslek grubu üyeleri nasıl düşünür? Aldıkları eğitim, kişiliklerini, düşünce yöntemlerini ve sosyal ilişkilerini nasıl etkiler? Bu konu akademik açıdan da incelemeye değer bir konu olsa da, ben burada sadece gözlemlerimi aktarıyor olacağım.
Mühendisler nasıl düşünür
Mühendisler, mesleklerinin kapsamı gereği bir şeyleri üretmek ve inşa etmek için çalışırlar. Üretmek ve inşa etmek için de hemen her mühendislik branşında geçerli olmak üzere öncelikle analiz yaparlar, elde ettikleri bilgilerle bütüne dair bir model elde etmeye çalışırlar; ardından tasarım ve geliştirme yaptıktan sonra elde ettikleri çıktıyı test eder ve devreye alırlar. Bu süreçler, işin kapsamına göre kimi zaman tahminsel ve sezgisel yöntemleri de barındırıyor olsa da, sürecin tamamı deterministik ve sonuçları kesine yakın kabul edilebilir. Bu nedenle bir mühendis, uzmanı olduğu bir alanla ilgili konulurken genellikle sezgisel ve tahminsel parametreleri belirttikten ve beklenen koşulların sağlandığını varsaydıktan sonra işin geriye kalanı ile ilgili çok kesin ifadeler kullanmaktan hiç çekinmez. Çünkü bu işin öyle işleyeceğinden adı kadar emindir. Mühendislerle çalışırken göz ardı edilmemesi gereken bu davranış modelinden ileride biraz daha bahsedeceğim.
Teknolojinin hızının mühendisler üzerindeki etkisi
Hızla gelişen bilim ve teknolojinin branşlaşma konusunda en çok etkilediği meslek gruplarının başında sanıyorum mühendislik gelir. Mühendislik branşları içinde de daha çok bilişimle ilgilenen elektronik, bilgisayar vb. alanlar bu hızdan daha çok etkilenirler. Okul hayatı boyunca bile yeni teknoloji ve yöntemlerin çıktığına şahit olan mühendisler, bir yandan teknolojiyi takip etmeye ve kopmamaya gayret ederken, bir yandan da piyasanın kendilerinden beklentilerini karşılamaya çalışırlar. Problem şu ki, iş dünyasındaki diğer kişiler, teknolojinin çıktılarına kem kendi hayatlarında hem de iş hayatlarında bu kadar sık görmeye ve değiştirmeye eğilimli değillerdir. Bu nedenle mühendislerin sürekli yeni çıkan ve hayatı kolaylaştıran bir şeylerden bahsederken; onları dinleyen yöneticilerin de mühendislerin hayali işlerle, yaygın deyişiyle “entel dantel işlerle” meşgul olduğunu, gerçek hayattan koptuklarını ve gerçekçi olmadıklarını düşünebilirler. Mühendis kendince bir şeyleri daha iyi hale getirmekle ilgili öneriler sunduğunda, yöneticilerin “bu ne işimize yarayacak” ya da “bu maliyete girmeye değer mi, bir süre sonra da daha iyisi çıkacak” gibi kimi paradoksal, kimi direnç ifade eden cevaplarına sıkça rastlarız. Bu durumu mühendis gözüyle düşünmeye çalışalım. Mühendis, bir yandan meslektaşlarının ürettiği teknolojiye ve mesleğine hayranken, diğer yandan bu teknolojiyi hemen almakta direnç gösteren yöneticilerinin ya da piyasanın bu davranışını anlamlandırmaya çalışır. Aslında her iki davranış da kendi perspektifinden gayet sağlam gerekçelere sahiptir; ancak bu düşük yoğunluklu çatışma hali, mühendis üzerinde her zaman bir stres unsurudur.
Bilişim mühendisliğinde meslek odaları ve yetkinlik ölçümü
Mühendislik branşlarında meslek içi branşlaşma ve uzmanlaşma konusu, meslek örgütlerinin kontrolünden tamamen çıkmış durumdadır. Hatta ülkemizdeki bilişimle ilgili branşların meslek örgütlerinin meslektaşlarının hak ve hukukunu savunmaktan bile tamamen kopmuş olduğunu söylemek yanlış olmaz. Şöyle örnek verelim: Elektrik, elektronik, kontrol, haberleşme, vb. branşların bağlı olduğu oda, Elektrik Mühendisleri Odası’dır (EMO). EMO’ya kayıtlı olmak, sadece inşaat planlarındaki elektrik projelerine imza atma yetkisi olan elektrik mühendisleri açısından anlamlıdır. Bu odaya kaydolmayan diğer mühendislerin mesleki hayatlarında oda ile hiçbir ilişkisi olmaz, odanın da onlarla... Farklı grupların meslek odası seçimi mücadelesinin mevziisi durumuna düşmüştür. Bilgisayar mühendislerine gelince… Onlar da 2 yıl öncesine kadar EMO’ya bağlı kabul edilmişlerdi ve ancak 2012’de kendi odalarını kurabildiler. Şu var ki, onlar da sadece lisans diploması bilgisayar mühendisi olanları odalarına kabul ediyorlar. Yani bilişimle uğraşan ve hatta yüksek lisans veya doktorasını bilgisayar mühendisliğinde yapmış olan elektronik, haberleşme, vb. mühendislerini bile odalarına kabul etmiyorlar!
Şimdi soru şu? Siz yabancı bir firmasınız ve Türkiye’de bilişim firması kurmak üzere yatırım yapmak istiyorsunuz. Peki, aradığınız branşlarda ve uygun niteliklerdeki mühendisleri nasıl seçeceksiniz? Onların lisans mezuniyeti sonrasında edindikleri yeni yetenekleri veya unuttukları şeyleri nasıl ve neye göre ölçeceksiniz? Hemen cevap vereyim: Meslek odalarının bilişimle ilgili mühendislerin etkin ve etkinlikleriyle ilgili hiçbir faaliyeti ve denetimi mevcut değildir. Bu ölçüm konusunda tek başınasınız ve sadece bir takım mesleki sertifikalarla, iş tecrübesi ve iş görüşmesi sırasında kendi yapacağınız ölçümlerle karar vermek durumundasınız. Tabi firmaya alınacak mühendisin seçiminde iş görüşmesinde yer alan ve ölçümü yapan kişinin de bir başka mühendis olması bilişimci olmayan yöneticiler için tedirgin edici bir durumdur.
Uzmanlık ve genel pratisyenlik ikilemi
Uzmanlık ve genel pratisyenlik ikilemi tıp alanında çok daha bildik bir konu olsa da, mühendislikteki durum tıptan hiç de aşağı değildir. Hatta tıptaki branşlaşmayı motive eden bilimsel ve teknolojik gelişimin önemli bir kısmını mühendislik bilimleri çalışmaları oluşturduğundan, buradaki gelişme ve branşlaşma hızı motive ettiği bilimlerden daha fazla diyebiliriz. Bunun üstüne, eğitim kurumları ve meslek odalarının bu branşlaşmayı yönetemiyor olmasını eklersek, hangi konuda hangi mühendisin sözünü referans alacağımız konusu kolaylıkla bir problem haline gelebilir. Yani bir yönetici için sorun bir mühendisi sadece işe alırken onun yetkinliğini ölçmekle kalmaz, işe aldığı mühendislerin hangi alanda sözlerinin ve eylemlerinin referans olması gerektiği de sürekli dikkate alınması gereken bir ölçme ve karar verme problemidir. Bu durumu hemen hepimiz bir doktora hasta olarak gittiğimizde bir ölçüde yaşarız. Aldığımız cevabı ve teşhisi başka bir doktora daha sormak (ya da sorma ihtiyacı hissetmek) yaygın karşılaşılan bir durumdur. Ama mühendislikte uygulama pek öyle olmuyor. Bir mühendise güveniyorsanız beraber çalışırsınız ve söylediklerini her defasında sorgulamazsınız. Problem, mühendisin söylediklerinin farklı da olabileceğini geç de olsa sonuçlarını gördüğünüzde anlarsınız ve belki bir süre sonra yolunuzu ayırırsınız. Ancak yine ölçmekte zorlanacağınız başka bir mühendis ile çalışmaya devam edersiniz.
Bu başlık altında “uzmanlaşma mı iyidir, yoksa genel pratisyenlik mi?” tartışmasına değinmeden geçemeyeceğim. Malum uzmanlaşma paradoksunu ifade etmek için şöyle denir: “Uzman, giderek daha az konu hakkında daha fazla şey bilen kişidir. Öyle ki sonunda hiçbir şey hakkında her şeyi bilir.” Buna karşın, genel pratisyenlik için de şu ifade türetilir: “Genel pratisyen giderek her şey hakkında daha az şey bilen kişidir. Öyle ki, sonunda her şey hakkında hiçbir şey bilir”. Kişisel olarak bir mühendis gözüyle bu tür klişe ifadelerin herhangi birine sarılmayı ve ardından bir grubun “daha iyi” olduğuna dair sonuç çıkarmayı mühendisliğin temeli olan analitik yaklaşıma aykırı buluyorum. Bilimsel ve analitik düşünce bize önermelerin kendi sınır koşulları içerisinde doğru kabul edilebileceğini öğretir. Dolayısıyla kimi koşullarda uzman, kimi koşullarda da genel pratisyen daha faydalı ve doğrudur. Bununla birlikte hemen her meslekte bu iki grup arasında bu tür bir çatışma olduğu da maalesef bir gerçektir.
Sağlık bilişimi ve bilişimcinin sağlıkla imtihanı
Buraya kadar, bilim ve teknolojinin mühendislik üzerindeki etkisini, mühendislerin düşünme tarzını, ülkemizde bilişimle ilgili mühendisliklerin meslek örgütlerinin durumunu, uzmanlıklarının ve yetkinliklerinin ölçümündeki zorluklarını ve uzmanlık ile genel pratisyenlik arasındaki ikilemi kısaca ifade etmeye çalıştım. Bütün bu yazdıklarımızdan, “bilişimci olmayan” yöneticiler için bilişimcilerle çalışmanın zor ve bir miktar öngörülemez bir süreç olduğu, aynı unsurların mühendisler için de bir stres sebebi olduğu anlaşılmıştır diye düşünüyorum. Bütün bu saydığım koşullar, çalışma alanı sağlık olduğundan birkaç derece daha zorlaşmaktadır. O yüzden şimdi bütün bu koşullarla birlikte ülkemizdeki sağlık bilişimindeki şartları inceleyip, hem mühendisler hem de onları yöneten ve genellikle mühendis olmayan yöneticiler için kolaylaştırıcı bazı öneriler üretmeye çalışacağım.
Sağlıkta mühendislerle çalışmanın zorlukları
Mühendisliğin ve bilişimin en çok kullanılması gereken alanlar arasında bilginin en çok kullanıldığı sağlık sektörü üst sıralardadır. Ancak bu yoğun etkileşim gereksinimi, beraberinde bazı yapısal ve yöntemsel zorlukları da getiriyor. Bunlara ana başlıklar halinde değinmeye çalışacağım:
Kamu şartları kaynaklı zorluklar
Sağlıkta hizmeti veren ve ödeyici kurumların önemli bir kısmı kamu kurumudur. Bu nedenle istihdamın da önemli bir kısmını kamu yapmaktadır. Kamunun aşağıda belirttiğim bazı koşulları mühendislerden yeterince yararlanmanın önünde ciddi bir engel teşkil ediyor:
1. Ücret politikası: Kamunun ücret politikası, özel sektörde çalışan nitelikli mühendislerin kamuda çalışması önünde önemli bir engeldir.
2. Bilişime verilen önem: Kamu kurumlarının teşkilat yapısında bilişimle ilgili daire ve genel müdürlüklerin isimleri, görev tanımları ve yaptıkları işler ile olması gereken arasında ciddi uçurumlar var. Çalıştığı kurumun bilgiye ve bilişime dayalı bir politika yürütmesi halinde neler yapabileceği konusunda fikir ve ufuk sahibi olan bir mühendis için, kurumunun bilişimi “teknik servis” seviyesinde algıladığını görmek ya da yaptığı önerilerin “hayali” olarak görülmesi ve küçümsenmesi delirtici bir durumdur. Nitelikli bir mühendis bu ortamda uzun süre kalmaz.
3. Sürdürülebilirlik: Mühendisler üretmeye ve geliştirmeye şartlandıkları için sürekli altyapıya, yeni projelere yoğunlaşırlar. Yapılan her yeni projenin daha önceki çalışmalarla uyumu, kendi emeğinin korunmasına da hizmet ettiği için sürdürülebilirlik ve geriye dönük uyum konusunda son derece hassastırlar. Ancak bunları sağlamak kamuda son derece zordur. Nitekim bir yönetici değiştiğinde daha önce yapılanların büyük ölçüde atıl kalması, mükerrer ya da uyumsuz yeni çalışmaların yapılması sıkça rastlanan bir durumdur. Mühendis, bir yandan kendi emeğinin heba olduğuna, diğer yandan da kamu kaynağının israf edildiğine şahit olur. Yeni projeler için şevki azalır, üretkenliği düşer. Bu konuda şahsen önemli bir tecrübe edindim. Altı yıl Dünya Bankası danışmanı olarak görev yaptığım Sağlık Bakanlığı’nda, mükerrer projelerin yapılmaması, altyapının sürdürülebilir olması için çok ciddi mücadele verdik. Bir ölçüde de başarılı olduk. Bakanlıktan ayrılacağım günlerde dönemin Sağlık Bakanı Sayın Recep Akdağ ile yaptığım görüşmede, yapılan çalışmaların bizden sonra heba olmaması adına önerilerde bulunurken, kamuda klişe olan bir ifadeyi biraz revize ederek şöyle demiştim: “Kamuda süreklilik esastır sözü, sürekli söylenen ama esası olmayan bir sözdür”. Hakikaten, makro düzeyde devlet hep bâki ve ayakta; ancak mikro düzeyde farkında olunamayan israfın, yanlış yatırım oldukça fazla. O dönemde Sayın Bakanımız ve müsteşarlık yöneticilerinin bu konuda olabildiğince hassas olduğunu hakkıyla teslim etmem lazım. Ancak buna rağmen ülke olarak hala alınacak çok yolumuz olduğunu da söylemeliyim.
4. Mesleki tatmin: Kamudaki bilişim projeleri oldukça büyük gövdeli ve mühendisleri cezbeden yeni teknolojilerin kullanıldığı projeler olsa da etkinlik, verimlilik ve çalışma metodolojileri açısından özel sektörün oldukça gerisindeler. Bu durum, bu alanda uzun süre çalışan bir mühendisin özel sektördeki rakiplerinin gerisinde kalmasına yol açabiliyor. Bu nedenle iyi bir projede çalışıyor olsa da, özel sektöre dönmeyi düşünen bir mühendis uzun süre kamuda kalmayı istemez.
Disiplin farklılığı kaynaklı zorluklar
Bir tarafta hepimizin hayatında yeri olan doktorlar; diğer tarafta hayatın her yerinde olan mühendisler... Yaygınlık ve saygınlık açısından her iki meslek grubunun da egosu oldukça yüksek. Bu iki grubun birlikte çalışması gerektiğinde, haliyle bazı yeni sorunlar ortaya çıkabiliyor. Karşılaşılan bazı zorlukları şöyle sıralayabiliriz:
1. Bilişimci olmayan yöneticiler: Hemen tüm kamu kurumlarındaki bilişim departmanlarına baktığımızda idari görevlerde kurumun asli görevi itibariyle barındırdığı kadroların hâkimiyetini görürüz. Sağlık Bakanlığında bir doktoru, Maliye Bakanlığında bir maliyeciyi, Diyanet’te bir ilahiyatçıyı bu birimlerin başında görebiliriz. Bu yöneticilerin hepsinin “yönetici” olarak ehil insanlar olduğunu düşünsek bile, eğitimini almadıkları bir alanda yöneticilik yapmanın ve dahası başka bir meslek grubunu yönetmelerinin ne kadar zor olacağını tahmin etmek zor değil. Bence bu örneklere göre daha normal bir durum olsa da hastanelerin ve dolayısıyla kendilerinin başına doktor olmayan profesyonel yöneticileri istemeyen doktorlar bu durumu iyi anlayacaklardır diye düşünüyorum. Bilişimci bir yöneticinin gayet kolay anlayacağı ve hemen kabul edeceği hususları, bilişimci olmayan bir yöneticiye anlatmak gerçekten zordur. Basit benzetmeler yaparsanız, uzun uzun ve fakat bu arada bilgiçlik taslamadan ve karşıdakine bu konudan bazen hiç anlamadığını belli etmeden nazikçe ikna etme yoluna giderseniz çatışmayı en az seviyeye indirebilirsiniz. Bu psikolojiyi anlamaları için doktorlara şöyle bir öneride bulunabilirim: Tedavi etmeye çalıştığınız hastanızın sizin yöneticiniz olduğunu düşünün. Ya da hastanenin başına bir finansçıyı ya da insan kaynakları yöneticisini koyduğunuzda başınıza gelenleri hayal edin. Çok farklı bir durum değil. Ne var ki mühendisler, hastanelerinde doktor olmayan bir yöneticiyi barındırmamayı başarabilen doktorlar kadar şanslı değildir. Bir defa çalıştıkları yerler genellikle tamamen teknoloji şirketi olan ve ağırlıkla mühendislerin çalıştığı ve yönettiği yerler değildir. Bu nedenle azınlıktırlar. Çalışma yeri sağlık kurumu olduğunda bir de karşılarında müşteri ya da yönetici konumunda olan ve egosu yüksek bir doktor grubu vardır. Bu tür durumlarda bilgi ve bilişime yeterince saygı duymayan, üstelik yöneticilik yanı da iyi olmayan doktorlara rast gelen mühendisler için hayat gerçekten çekilmezdir. Doktorlar için de…
2. Terminoloji sorunu: Halkın anlamadığı tıp jargonu, hekimlerle hastalar arasındaki bilgi asimetrisinin aşılmaz bir zırhı durumundadır. Mühendislerde de benzer bir durum vardır. Kullanılan teknik terimleri mühendis olmayanlar büyük oranda anlamazlar. Dolayısıyla daha başlangıçta doğru iletişim kurabilmek için bile bir teknik altyapı ihtiyacı hemen göze çarpar. Bu durum benzer bir jargonu kendileri de kullanıyor olsalar da doktorları çoğu zaman rahatsız eder. Başkaları ve özellikle hastaları onları daha anlaşılır olmaya zorlayamadığı halde, onlar mühendislere daha anlaşılır olmaları için baskı yapabilirler. Bir noktadan sonra daha anlaşılır olamamak, işin doğasına mâl edilmez ve genellikle mühendisin iletişim beceriksizliğine mâl edilir (Gerçekten iletişim faciası olanlar da yok değildir tabi). Diğer taraftan daha anlaşılır olmak için elinden geleni yapan bir mühendis de zaman zaman ukalalık yaptığı algısından ve bunun davranışlara yansıyan yan etkisinden kolay kurtulamaz.
3. Ego çatışması: Diğer pek çok sorunda bir payı olan ego çatışması ayrıca da ele alınmalı aslında. Sağlık alanı dışında çalışan bilişim mühendisleri, çalıştıkları yerde büyük ölçüde bilirkişi ve değerli insan olarak kabul edilirken, sağlık alanında bu değer öyle kolayca elde edilemez. Genellikle alınacak paye, çalışılan yerdeki yegâne hâkim otorite olan (yönetici ya da kullanıcı) doktorun elindeki erkin bir kısmından feragat etmesini gerektirir. İşin kötü yanı, mühendisler de öyle kolay kolay kendi bildiklerinden vazgeçmezler. Vazgeçerlerse de işlerini yanlış yaptıklarını düşünüp başka türlü mutsuz olurlar. Her iki tarafın da iş ve sonuç odaklı olduğu, karşılıklı saygıya dayalı bir ilişki tesis edebildiği ortamlarda bu ikili çok başarılı işler yapabiliyorken, bunlardan uzak kalındığı durumlarda süreğen bir stres hep var olur.
4. Çekiç-çivi sendromu: Diğer pek çok meslekte olduğu gibi, mühendislikte de bazı ana branşlar kişinin tüm problemlere çözüm üretme yaklaşımında baskındır. Bu ana branşlardan bazıları sistem mühendisliği, güvenlik mühendisliği, yazılım mühendisliği, veri mühendisliği, kullanılabilirlik mühendisliğidir. Eğer bir yöneticiyseniz ve bilişim konusundaki danışmanınızın uzmanlığı güvenlik ise, atılacak her adıma paranoyakça bakıp bilişim imkânlarının kullanımını azaltacak şekilde öneriler vermesi doğaldır. Ya da bir sistem yöneticisi ile çalışıyorsanız, size sürekli haberleşme altyapısı, sunucu sistemleri, donanım havuzu, vb. konulardan yatırımlara sevk edecektir. Yazılım mühendisinin de her ihtiyaç için bir yazılım geliştirmek gerektiğini söyleyip dışarıdan yazılım almanıza engel olması sıkça karşılaşılan davranış şeklidir. Kullanılabilirlik uzmanı da size uygulamaların kullanışsızlığından bahsedip çoğunun yeniden yazılmasının şart olduğunu söyleyebilir. Eğer kendinizi “kandırılmış” hissetmek istemiyorsanız neyi kime soracağınız konusunda kötü tecrübe edinmeden bilgi sahibi olmalısınız.
Mesleki formasyon kaynaklı zorluklar
“Fuzzy” bir dünyada “binary” bakış sendromu
Mühendisler, başlangıçta da belirtiğim üzere analitik ve gerçekçi bir süreç izlerler. Kullandıkları parametreler kesine yakın, süreçler de deterministiktir. Sonuç bir ya da sıfırdır. Sürprizlere yer yoktur. Eğer bir hata alındıysa, onun da mutlaka çok anlamlı bir açıklaması vardır ve gözden kaçmasının sebebi, analiz aşamasında gündeme gelmemesidir. Hatanın kaynağını bulan mühendis, sistemde dikkate alması gereken yeni bir parametreyi daha keşfettiğini düşünür ve genellikle bunu da hem kendisinin bir başarısı; hem de başlangıçta ihtiyacını iyi anlatamamış olan kullanıcının eksikliği olarak algılar. Hâlbuki diğerleri bu durumu çoğunlukla mühendisin beceriksizliği olarak değerlendirir. Hangi hatada kimin ne kadar payının olduğu sürekli bir muammadır. Gerçekte ise çoğu zaman her ikisi de geçerlidir.
Önermeler mantığı ile günlük hayat problemlerini konuşmak
Mühendislerin eğitim hayatı boyunca sıkça gördükleri teoremler vardır. Bir teoremde birçok aksiyom (kabul) vardır. Eğer matematiksel olarak bir teoremde yer alması gereken aksiyomları belirttiyseniz ve bu aksiyomlar “imkânsız” değilse, onların gerçekleşme olasılığının düşük olması sizin önermenize bir halel getirmez. Çünkü “kabul” ederek ilerlemişsinizdir ve zaten aksiyomun olmadığı durum için de teoreminizin doğru olduğunu iddia etmiyorsunuzdur. Matematiksel ifadelerde anlamlı olan bu önermeler mantığı, günlük hayatta iletişimde ve karar süreçlerinde kullanıldığında sorunlara neden olur. Örneğin mühendislere farklı nedenlerden dolayı zor görünen bir konuda “şunu yapmak mümkün mü” diye sorduğunuzda çoğunlukla size şöyle cevap verdiklerini görürsünüz: “Eğer… olursa ve eğer… olursa mümkündür!” Mühendise göre kendisine düşen görevi yerine getirmiş, gayet anlaşılır, matematiksel bir önermede bulunmuştur. Gerisi onu anlaması ve karar vermesi gereken kişiye kalmıştır. Aslında bir iletişim kazasına neden olan bu tür durumlarda şu iki durumu sıklıkla gözlemlemişimdir:
1. Yönetici aldığı cevaptaki eğer ile başlayan şart ifadelerine değil, sonundaki mümkündür ifadesine odaklanıverir ve hatta mühendisin ona “bu iş gayet kolay” dediğini düşünür. Hemen o işin yapılması için talimat verir. Bir süre sonra eğer koşullu cümlelerindeki şartlar yerine gelmediğinde ya da kısmen geldiğinde çıkan sorunlardan mühendisi sorumlu tutar veya onun kendisini kandırdığını düşünür.
2. Yönetici, eğer koşullu cümlelerine dikkat kesilir ve aslında bu koşulların yerine gelmesindeki zorlukları hemen algılayıp, bu defa da “Bu koşulların olması neredeyse imkânsız, bana neden doğrudan bu işin olmayacağını söylemiyorsun?” diye mühendisi suçlar. Hakikaten, yöneticilerin beklediği cevaplar kısa ve nettir. Hâlbuki “katıksız” bir mühendisin jargonunda imkânsız diye bir şey yoktur, gerekli koşullar sağlanırsa neden olmasın diye düşünür ve kendini koşulları ifade etmeye zorlar. Bu mantığın çok baş ağrıttığını gören ve bir şekilde kendini değiştirebilen mühendisler yönetimle daha uyumlu çalışabilirler. Ancak sayıları az olan bu mühendisler, bu uğurda mühendislikten biraz uzaklaşmak, biraz da yönetici perspektifine yaklaşmak durumundadırlar.
Sonuç
Hepimiz mutlu ve başarılı olmak isteriz. Ancak bunu elde edebilmek için içinde bulunduğumuz ortamı iyi tanımamız ve olabildiğince uyum sağlamamız gerekiyor. Özellikle sağlık alanındaki gözlemlerimden yola çıkarak, hem mühendislere, hem de onlarla çalışan kullanıcı ve yöneticilere bir dizi öneride bulunmak istiyorum:
Bilişimci olmayan yöneticiler için öneriler
1. Bilişimcilere hak ettikleri saygıyı mutlaka gösterin.
2. Ancak kendi disiplini dışındaki disiplinlere saygı göstermeyen, değişime ve gelişime kapalı olan mühendislerden uzak durun.
3. Ekibinizi kurarken öncelikle işiniz için gerekli olan uzmanlık alanlarını iyi belirleyin. Bu arada size yakın çalışacak mühendislerle, uzak ve sadece belirli alanda çalışacak mühendislerde farklı özellikler arayacağınızı unutmayın.
a. Size yakın mühendislerde iş tecrübesi yüksek genel pratisyenlik (genel uzmanlık da denebilir) özelliğini daha çok ararken, size uzak olanlarda spesifik uzmanlık özelliğini önemseyin.
b. Bu ikisi arasındaki farkı ayırt etmek için yeterli teknik bilginiz yoksa görüşünde çok iddialı ve ısrarlı olan kişilerin genel pratisyen olamayacağını ve size yakın çalışamayacağını aklınızda tutun. Bunlar ya gerçekten sadece bir alanın uzmanıdırlar ve size uzak da olsa çalışabileceğiniz kişilerdir; ya da çok az şey bildiğini gizlemeye çalışa kişilerdir. Bunu ölçmenin bir yolunu arayın.
4. Önemli bir konuda karar alacağınız zaman, doğru uzmanlıktaki kişilere sorduğunuzdan emin olmaya çalışın. Farklı uzmanlıkların az ya da çok mesleki deformasyonu olacağını unutmayın ve aldığınız cevapları size yakın çalışan tecrübeli genel uzmanlarla teyit edip olgunlaştırın.
5. Mühendise sorduğunuz ve “…mümkün mü?” şeklinde biten cümlelerin, onlar için bir çeşit meydan okuma olduğunu unutmayın. Bu sorunun muhatabı mühendis tüm şartları zorlayacak ve bir sürü “Eğer… olursa...” cümlesi kurarak sizin sorunuza “Mümkündür” demeye çalışacaktır. Bu soru kalıpları yerine “Sen olsan yapar mısın?” diyebilirsiniz. Ya da mümkünse kendi sınır koşullarınızı açıklayarak “Kaynaklar, zaman ve diğer şartlar şu şekilde olduğunda yapmak optimal midir?” gibi bir soru sorabilirsiniz. O zaman yelkenleri indirip koşul cümlelerindeki zorlukları daha çok vurgulayarak size dönüş yapacaktır.
6. Mühendislerin verdiği cevaplarda yer alan koşullu cümleleri önemseyin.
7. Mühendislerin cevaplarında yer alan koşullu cümleleri çok kullanan veya hiç kullanmayan profilleri ayırt edin.
a. Bu koşullu cümlelerin fazla kullanılması sizin onlara zor işler yüklüyor olduğunuzun ya da “Hayır cevabını kabul etmediğinizin” belirtisi olabileceği gibi mühendisin sadece kendi paradigmasına göre cümle kurma ısrarından kaynaklanıyor da olabilir.
b. Koşullu cümle hiç kullanmayan ve kısa cümlelerle hayatın doğrularını ve yanlışlarını tanımlayan mühendisten uzak durun. İşini bilmeyen ya da farklı parametrelerin olabileceğini göz ardı eden biri olması kuvvetle muhtemeldir.
Bilişimci olmayan yöneticiler ile çalışan mühendisler için öneriler
Şüphesiz etkileşimin diğer tarafında da bilişim mühendisleri var ve onların da dikkat etmesi gereken hususlar çok fazla. Özellikle sağlık bilişimi alanındaki hayatı kolaylaştıracağına inandığım bazı önerilerim şunlar:
1. Yöneticinize mutlaka gereken saygıyı gösterin.
2. Yöneticinin isteklerinde, sorularında veya kararlarında kaçınılmaz olarak ortaya çıkacak ve bilişimle ilgili “bilgi eksikliği kaynaklı” durumları yönetime karşı saygınlığınızı kazanma aracı olarak kullanmayın. Bu eksikliklerin güzel bir şekilde kapatılması için iletişim halinde olun.
3. Kullandığınız jargonun anlaşılmaz olmasını ya da belirli konularda sadece sizin bildiğiniz bilgileri kendi güç alanınızı oluşturmak için asla kullanmayın. Daha anlaşılır konuşmaya ve bilgiyi paylaşmaya gayret edin.
4. Kısa ve net cevap bekleyen yöneticiyle, ikna edilmesi seven ve gerekçeleri anlamak isteyen yöneticileri ayırt edin, her ikisine de beklentisine yetecek şekilde cevaplar vermeye gayret edin.
5. Bilişimle ilgili size her sorulan soruya tatmin edici cevap vermek zorunda değilsiniz. O bilgiye nasıl ulaşacağınızı, nasıl teyit edeceğinizi ve nasıl uygulayacağınızı söyleyebilmeniz de önemli bir katkıdır. İyi mühendis her şeyi bilen değil; neyi bilmediğini iyi bilendir. Gerektiğinde ehlinden danışmanlık almaktan imtina etmeyin, yöneticinizin almak istediği danışmanlıklara karşı koymayın.
6. Her işin sizin söylediğiniz gibi yapılmasını beklemeyin. Çalıştığınız kurumda sizin etkinizin bileşke kuvvete etki eden kuvvetlerden sadece biri olduğunu; diğer kuvvetlerin de anlamlı ve gerekli olduğunu unutmayın.
7. İddialı olmayın. İddialı olmak, doğrunun/hakkın sizin bildiklerinizden ibaret olduğu varsayımına dayandığı için bizzat hakka saygısızlıktır. Kendinizce çok doğru olduğunu düşündüğünüz şeyler, aslında ilerlemenizin önündeki engeller olabilir.
8. Sabit fikirli olmayın. Ama görüşünüzü değiştirmek için hakkınız olan rasyonel açıklamalardan da feragat etmeyin.
9. Başka bir mühendisin görüşü size aktarıldığında burun kıvırmayın. Bu görüşü hangi koşullarda hangi durum için söylediğini, mühendisin bilgi seviyesini anlamaya çalışın, sonra sadece kendi görüşünüzü ifade edin. Farklı düşünmek, küçümsemeyi veya görmezden gelmeyi gerektirmez.
10. Bilişim projelerinde ferdi başarı ya da başarısızlık yoktur. Ürettiğiniz şeylerde ortaya çıkan hatalar, sadece son kullanıcının ihmali olamaz. Hatadan kendi payınıza düşeni alın, ama fark ettiğiniz kadarıyla yöntem ve iletişim konusunda diğer aktörlere düşen görevleri de paylaşın.

 

SD (Sağlık Düşüncesi ve Tıp Kültürü) Dergisi, Aralık-Ocak-Şubat 2014-2015 tarihli 33.sayıda, sayfa 68-73'de yayımlanmıştır.

Bu yazı 2093 kez okundu

Yorum yazabilmek için üye girişi yapınız

  • SON SAYI
  • KARİKATÜR
  • SÖYLEŞİ
  • Şehir hastaneleri hakkında düşünceniz nedir?