Ana içeriğe atla

Yazılım Projesinde Yeni Teknolojiye Geçmek

Yeni çıkan bir programlama dilinin, javascript kütüphanesinin, veri tabanı teknolojisinin ya da proje yönetim tekniğinin mevcut bir projede kullanılması hem yazılımcının kariyerine hem de yazılımı üreten şirkete değer katan ve riskli bir karardır. Bu kararı alırken nelere dikkat etmeliyiz, kimi nasıl ikna etmeliyiz?




Monolitik masaüstü yazılımdan mobile uzanan oradan da bulutlara çıkan yeni teknolojileri takip etmek zor iken bir de bu yeni teknolojileri mevcut bir projede kullanmak biz yazılımcıların bu hayattaki heyecanı ve imtihanı olsa gerek.

Blockchain, AI (yapay zeka), siber güvenlik, IoT, sanal gerçeklik gibi yeni alanların yanı sıra Agile gibi yeni proje yönetimi tekniklerinden otomatik ölçeklenebilir bulut sistemlerine kadar bir çok yenilik var. Her gün yenisi çıkan JavaScript kütüphanelerinden, hibrit yazılım geliştirme araçlarından hangisini takip edeceğimizi şaşırıyoruz. (Ben bunları bu yazıda teknoloji diye ifade edeceğim.) "Cool" olanı kovalamak, "hype" akımına kapılmak, konferanslarda ve eğitimlerde (eğer gidebiliyorsak ne mutlu) duyduklarımızı gördüklerimizi yapmak istemek sanırım tüm iyi yazılımcıların ortak özelliği.

Yazılımcı olarak yeni çıkan teknolojiler ağzımızı sulandırır, bu teknolojileri öz geçmişimize eklemek isteriz. Mevcut projede kullandığımız teknolojiler eskidir ve hantaldır. Ama yeni teknolojiler öyle mi? Ah şu yeni teknolojiye geçsek her şey nasıl da bir anda düzelecek! Proje yönetici ise her yeni teknolojiyi risk olarak görür, yeni kaynaklar için yönetimi nasıl ikna edeceğini düşünür. Ve daha neler neler, işte aklıma gelen bazıları:

Yeni teknolojinin kullanımı için ekiple beraber karar vermek gerekir. Hatta şirketteki diğer teknik olmayan bölümlerin bile fikri alınmalıdır. İnsanlar değişim sürecinin bir parçası olmadıklarında bu sürecin karşısında olabilirler. Yeni teknolojiyi savunan kişiler sunum yapsınlar, avantajlarını dezavantajlarını anlatsınlar. Bazı kişiler ise muhalefet olsunlar ve bu yeni teknolojiye karşı çıksınlar. Bakalım kim kazanacak? 

Yeni teknoloji kullanıcının ihtiyacını ya da bizim ihtiyacımızı çözmede ne gibi katkılar sağlayacak? Kullanıcının farkına bile varmayacağı veri tabanı teknolojisinin değişmesi teknik ekibe nasıl bir fayda sağlayacak ya da yük getirecek?  Teknik ekip yükü kaldırabilecek mi? Dikkatimizi dağıtmamız gereken yazılım sektöründe yeni bir şeyler öğrenirken kullanıcının ihtiyacı hep birinci önceliğimiz olmalıdır. Yeni teknoloji daha az hata oluşmasını, kodun bakımının kolaylaşmasını ve yeni özelliklerin daha kısa sürede geliştirilmesini sağlıyorsa, kullanıcı için kullanımı sadeleştiriyorsa tercih edilmelidir.

Kullanıcının kullanım alışkanlıkları değişecek mi? Örneğin kullanıcı bir Excel belgesi yükleyerek işini hallederken, Excel'e olan bağımlılığı kaldırmak adına kullanıcıdan CSV (yine Excelden alınabilen bir dosya türü)  dosyası yüklemesini istersek kıyamet kopar mı? Kullanıcılara bir anda masaüstü uygulamaları terk ettiğinizi artık kullanıcının her şeyi web tarayıcısı ile yapacağını söylediğinizde kullanıcı bunu nasıl karşılayacak? Değişimi planlarken işin insani boyutunu göz önünde tutun.

Yeni teknolojinin öğrenilmesi ne kadar çaba gerektirecek? Ekipteki herkes yeni şeyler öğrenmeye hevesli mi? Çözülecek hatalar varken yeni bir şeyler öğrenmek için şirket kaynak harcamaya hevesli mi? Algoritma mantığını çözememiş, kodlamanın bir çözüm aracı olduğu anlayamamış yazılımcılar yeni bir geliştirme ortamında sudan çıkmış balığa dönebilirler. Şirket içindeki birçok kişi yaptığı işin değişmesini istemez. Yeni teknolojilerden konuşmak hoş iken iş bu teknolojiyi uygulamaya geldiğinde insanlar sorumluluk almaktan kaçabilirler.

Yeni teknolojiyi sadece bir kişinin bilmesi kötüdür. Bu teknolojinin ekip tarafından nasıl öğrenileceği planlanmalıdır. Bazı insanlar (kötü yazılımcılar) boş zamanlarını yeni şeyler öğrenmek için kullanmazlar. Onları unutmayın. Onlar sizi yeniliklerden uzak tutmasınlar, siz onların canını sıkın.

Yeni teknolojiyi bilen yeni personel bulunabilir mi? Bu teknolojinin adını duyunca insanlar kaçar mı yoksa koşa koşa şirkete mi gelirler? Yazılımcı çalıştığı yerden para ve tecrübe kazanır. Yazılımcı için tecrübe kalemine bu yeni teknolojiyi eklemek çekici geliyor mu? Ekip büyüdükçe kullanılan teknolojiyi değiştirmek zorlaşır. Ayrıca yeni teknolojiye geçerken birkaç kişi eski kodların bakımı için feda edilir. Şimdi mi yeni teknolojiye geçilmeli yoksa yeni personel geldikten ve işi öğrendikten sonra mı?

Şirkette teknik ekibin diğer ekiplerden daha çok söz sahibi olması yeni teknolojiye geçişteki acıyı azaltır. Değişim istemeyen ekiplerin (satış, üretim ekipleri gibi) ikna edilmesi gerekir. Yönetimin teknik ekibe yeni teknolojiye geçiş için destek olması gerekir. 

Aşırı soyut kod yazmaktan gerçek ile bağını kaybeden yazılımcılar görürseniz onları ürkütmeden projedeki gerçek hataları çözmeye yöneltin. İşin teorik tarafına kaçma eğilimi bulunan bu arkadaşlar bazen pembe bir dünyada yaşayabiliyorlar. Yeni teknolojileri yaptıkları küçük proje denemeleri ile test eden bu arkadaşlar bu teknolojinin fanatiği olabiliyorlar. Eğer böyle biri projenin yöneticisi ise kimsenin bilmediği bir teknolojiyi bir sabah kodlarda görebilirsiniz. Her şeyi bilen ve en iyisini bilen iletişimsiz bu tür insanlar yazılımcıları yeni teknolojiden soğuturlar. Bu tür kişilerden olmayın. Bu tür kişileri yazılım takımının havasını bozmadan doğru yola çekmeye çalışın. Bunlara karşı en iyi silahınız onların savundukları konuları onlardan daha iyi öğrenmeye çalışmaktır.

Yeni teknolojiler genel sorunları çözmek için ortaya çıkarılırlar. Ya sizin özel ihtiyacınıza uymuyorsa bu teknoloji? Yama mı yapalım, takla mı atalım, daha yeni bir şeyin çıkmasını mı bekleyelim? Yoksa kervan yolda dizilir deyip başlayalım mı? Özel ihtiyacınızı tam olarak çözecek bir teknoloji bulamayabilirsiniz, ki genelde durum böyledir. Bu durumda neler yapmanız gerektiğine ekipteki herkesin görüşü alınarak karar verilmelidir.

Yazılımdan para kazanan bir kişi veya şirket teknik yatırım yapmak zorundadır. Kazanılan parada yeni çıkacak teknolojinin de hakkı (kul hakkı gibi) vardır. Eski teknolojide kalan kaybeder. Eski teknoloji ile yeni özellikler geliştirmek giderek zorlaşır, atılan taklalar işe yaramamaya başlar. Eski kodların bakımını yapacak personel bulamamaya başlarsınız. Eski bir teknoloji ile yeni iş bulamazsınız. Yenilikleri takip edin. Yeni teknolojilerle küçük çaplı deneme projeleri yapın.

Teslim tarihi yaklaşırken yeni bir teknolojiye geçmeye karar vermek riskli bir durumdur. Teslim tarihine yetişemeyeceği ortaya çıkan bir projeyi yeni teknoloji ile yazmak sihirli bir değnek değildir. Bu durum ekibin yeteneği, kalan zaman ve yeni teknolojinin avantaj ve dezavantajları göz önüne alınarak detaylı olarak değerlendirilmelidir. Böyle bir durumda yeni teknolojiden daha çok çözüme en uygun teknolojiyi kullanmak tercih edilmelidir.

Henüz olgunlaşmamış bir teknolojiye yatırım yapmak bir çok açıdan tehlikelidir. Yeni teknolojinin olgunlaşması zaman alabilir. Bu teknoloji daha olgunlaşmadan terk edilebilir. Sorunların çözümsüz kalabilir. Güvenlik açığı çıkabilir. Bu teknolojiyi çıkaran insanlar ile bu teknolojiye farklı bir yön vermek isteyen insanlar arasındaki anlaşmazlıklardan dolayı bu yeni teknoloji kopyalanarak ve adı değiştirilip farklı özellikler konularak başka bir teknoloji ortaya çıkabilir. (Özellikle açık kaynak kodlu teknolojilerde) Siz bu durumda teknolojinin eski haliyle baş başa kalabilirsiniz. Ayrıca olgunlaşmamış teknolojilerde aynı kod parçası ilerleyen zamanlarda farklı davranışlar sergileyebilir, desteklenen bazı özellikler terk edilebilir.

Eski kodların bakımının devam edeceği gerçeği unutulmamalıdır. Bu süre planlanmalı ve uzatılmamalıdır. Bu göreve feda edilecek personelin uzun süre eski teknoloji ile uğraşması onların motivasyonunu düşürecektir. Hatta bu durum onların işten ayrılmalarına bile sebep olacaktır. Hem eski kodları hem de yeni kodları idame ettirmek kaynak tüketimini artıracak ve kullanıcı memnuniyetini de azaltacaktır.

Yeni teknoloji için test yazmak, davranışı henüz bilinmeyen bir şeyin nasıl davranacağını tahmin etmek üzerine kurulu bir oyundur. Bu konuda çok söze gerek yok: Oyunu iyi olan kazansın. 

Şirket içinde hackathon etkinlikleri yapılabilir, Cuma günleri öğleden sonraları ya da personelin zamanın beşte biri gibi bir süre yazılımcıların kendilerini geliştirmelerine ayrılmalıdır ve bu süre proje teslim tarihi hesaplanırken toplam süreye eklenmelidir. Şirket bunu teknik yatırım olarak görmelidir. Bu hem personelin hem de kodların kalitesini artırır.

Yeni teknoloji ile geliştirilmiş yazılım parçaları kademeli olarak canlıya çıkarılmalıdır. A/B testi, yük dengeleme yapılarak yeni sistemin davranışı gözlemlenmelidir. Yeni teknolojiler projenin sadece bir katmanında kullanıldıktan sonra diğer katmanlara sıra geçmelidir. Örneğin önce veritabanı teknolojisi değiştirilmeli ardından kullanıcı arayüzünde kullanılan teknoloji değiştirilmelidir.

Şimdi aklınızda daha mı çok soru var? Yağmurdan kaçarken doluya tutulmamak dileğiyle.

Yorumlar

Bu blogdaki popüler yayınlar

Bir Uluslararası Yazılım Şirketinin Batış Hikayesi

 Güzel başlamıştı hikaye. Yazılımcılar mutlu, kullanıcılar memnundu. Sonra pandemi başladı. Sorun para değildi. Olmayan şey huzurdu… Durdurun hype trenini, inecek var kırık kalpler durağında  — Photo by Kelly Sikkema on  Unsplash Gerçek olamayacak kadar güzeldi çalışma ortamı. Yazılımcılara istedikleri eğitim ve donanım alınıyordu, personel arası hiyerarşik bir yapı yoktu, sorumluluğun yanında yetki de veriliyordu, esnek çalışma saatleri yazılımcılara göre esnekti, izin isteyen hiç kimse geri çevrilmiyordu, pandemiden önce bile uzaktan çalışma vardı. Ne oldu bu şirkete? Nazar mı değdi? Şirketin yazılım ürünü Türkiye’de doğmuştu. Ürün birçok ülkede hem kamu tarafından hem de özel sektör tarafından kullanılıyordu. Yazılım geliştirme ekipleri hem Türkiye’de hem de diğer ülkelerde bulunuyordu. Yazılımın argesi için gelen geri bildirimlerin çoğu Türkiye’den geliyordu. Yazılımın kalbi Türkiye’de atıyordu.  Koronavirüs pandemisi nedeniyle Türkiye’de kamu kuruluşları hizmet alımı ile aldıklar

Uluslararası Yazılım Firmasında Çalışmak

Türkiye merkezli 5 ülkede ofisi olan 50’den fazla mühendisi bulunan ve müşterileri hariç 8 farklı milliyetten kişiler bulunan bir yazılım firmasında yaklaşık 11 aydır çalışmaktayım. Bu süreç boyunca hem çalıştığım şirkette hem de iletişimde bulunduğum diğer uluslararası şirketlerde gözlemlediğim noktaları paylaşmak istedim. Buradaki görüşlerim tamamen kişiseldir ve firmadan firmaya değişebilir. Eleştiriyi önce en günahsız olanınız yapsın! Photo by Kyle Glenn on Unsplash İşe giriş ve mülakat süreçleri zor. İş ilanlarını mantıklı ve açıklayıcı olarak açılıyorlar. Öyle her şeyden anlayan süper yazılımcı aramıyorlar. Şirketin ihtiyacını göz önüne alarak ve her yazılımcının şirkette kullanılan teknolojileri bilemeyeceğini göz önüne alınarak iş ilanını açılıyor. Özgeçmişimde yazan her kelime ile ilgili sorguya çekildim. Başvurduğum pozisyon için gereken yeteneklerle ilgili zor sorular soruldu. Nasıl yaptılar bilmiyorum ama şirket kültürüne uyumumu ve iletişim yeteneğimi de ölçmüşler. Açık

Kamuda Yazılımcı Ol(ma)mak

Yazılımcı olarak 8 yıl kamuda, 2 yıl özel sektörde çalıştım. Bir yandan da freelance olarak çalıştım. Yurtdışındaki firmalarla da güzel yurdumun esnafıyla da çalıştım. En garip manzara bence kamudaki yazılım manzarası. Şu anda bir kamu kurumu için geliştirilen yazılım projesini yönetiyorum. Girdiğim toplantılarda, aldığım e-postalarda, yaptığım telefon konuşmalarında eski kamu anılarım depreşti. Kağıtların arasında hayalleri yıkılmış bir yazılımcı bulabilirsiniz Kamuda çalışırken hem benim hem de arkadaşlarımın başına gelen olaylardan ve şu anda kamuda çalışmaya devam eden tanıdıklarımdan aldığım bilgilerle, kamudaki yazılım dünyasını size sanayi diliyle aktarmaya çalışacağım. Bu yazı şahsi görüşlerimi içerir. Yine de kamuda 8 yılın yeterince objektif bir bakış açısı sunacağını düşünüyorum. Kamuya yazılım projesi geliştirirken karşılaşabileceğiniz durumlar: Bir kamu kurumu ile görüşmeye başlamak için bağlantı gerekir. Kamu kurumuna “sizin şöyle bir ihtiyacınız var ben bunu çözen yazılı