Menü Başlangıç

Ne iş yapar bu bilgisayarcılar? – 4

Tasarımcı

14

En mutlu yazılımcı kimdir biliyor musunuz? Yazdığı kod kimse tarafından kullanılmayan ve sadece makineler arası iletişimi sağlayan kod yazan yazılımcı, dünyanın en mutlu yazılımcısıdır. Çünkü böylece işin içine insan girmez ve bildiğiniz üzere bu amcalar, ablalar pek insan sevmezler. İşin şakasını bir tarafa bırakarak tekrar aytimenicir halı kilim tirevil için yazdığımız web mağazasına geri dönelim. En son bıraktığımızda yazılım ekibi harıl harıl çalışıp mağazanın kodunu yazıyordu. Entegre sistemlerle bağlantıları sağlıyorlar ve tüm teknik altyapıyı oluşturuyorlardı. Fakat henüz halletmedikleri bir iş daha var. Bu web mağazası sonuçta insanlar tarafından kullanılacak. Müşteriler bir web sitesine, ya da mobil uygulamaya girecek sağa sola tıklayarak ürün seçecek ve ödeme yapıp ürünlerini teslim alacaklar. Aynı şekilde firma çalışanları da verilen siparişleri görecek, onay verecek, kayıtları inceleyecek, kargo sürecini takip edecekler. Uzun lafın kısası bu web mağazası insanlar tarafından kullanılacak.

İşte insanlar tarafından bu yazılımı kullanmaya yarayan ekranlara User Interface yani kullanıcı arayüzü diyoruz. İşin sadece web kısmını düşünmeyin. Bilgisayarınızda kullandığınız programlardan, web sitelerine, cep telefonunuzda kullandığınız uygulamalardan, herhangi bir kiosk cihazında tıkladığınız uygulamaya kadar her yerde kullanıcı tarafından kullanılan ekrana kullanıcı arayüzü diyoruz. Yazılım kısmında dördüncü rolümüz olan UI Designer ya da Tasarımcı işte bu ara yüzleri yaratan insana deniliyor. Test-Kalite mühendisinde olduğu gibi burada da aslında iki adet birbiri içine geçmiş işten bahsediyorum. User Interface Designer yani Kullanıcı Arayüzü Tasarımcısı ve User Experience Designer yani Kullanıcı Deneyim Tasarımcısı aslında aynı ekip tarafından halledilen farklı işler. Bu işleri yazılım kısmında anlatıyorum çünkü yazılımla çok bağlantılı fakat bu insanlar yazılımcı değiller. UI Designer dediğimiz insan Photoshop gibi çeşitli araçlar kullanarak o uygulamanın ekranında gördüğünüz logolardan, renk paletlerine, butonlardan arka plana aklınıza gelecek tüm görsel altyapıyı hazırlayan insanlardır. UX Designer dediğimiz ise tasarımı bir bütün olarak şekillendiren insandır. UX Designer’ın esas görevi uygulamayı kullanacak insanların her işlemi kolayca ve sezgisel olarak yapmalarını sağlayacak dizayn temelini oluşturmaktır. Hani bazı uygulamaları açarız böyle 10 dakika boyunca ekrana bakarız, en basit iş için bile dakikalarca uğraşırız ya işte bu tarz uygulamalar ya bir UX Designer tarafından yaratılmamıştır ya da UX Designer’ı çok kötüdür. Ama bazı uygulama ya da web sitelerinde de ilk kez kullanmaya başladığımız andan itibaren yapmak istediğimiz her iş için sanki elimiz otomatik yönlendirilir. Her şeyi kolayca buluruz, kolayca işimizi hallederiz. İşte bunu sağlamak UX Designer’ın görevidir. Uzun lafın kısası UI Designer işin tasarım kısmıyla uğraşırken UX Designer işin kullanıcı deneyimi yaratma kısmıyla uğraşır.

Bu arada bu insanlar yazılımcı değillerdir dedik ama yazılım kısmında anlatıyoruz. Çünkü bu amcalar ya da ablalar da yazılım ekibinin bir parçası olarak çalışırlar. Tee uygulamanın ilk fikir aşamasından itibaren yazılım ekibiyle yakın çalışarak onların kod olarak yazdıkları şeyin kullanılabilir bir uygulama olmasını sağlarlar. Derinlemesine yazılım bilgisine sahip olmaları gerekmese de sürecin nasıl işlediğini bilmelidirler. Böylece tasarımcı rolünün de sonuna geldik ve son rol olarak teknik yazara geçiyorum.

Teknik Yazar

15

Yazılım kısmının son rolü olan teknik yazarı aslında dürüst konuşmak gerekirse birçok organizasyonda göremezsiniz. İş gerçekten büyük değilse bu görev genelde yazılım ekibi içerisinde halledilir. Fakat yapı görece büyük ve çalışılan projeler çeşitli ve karmaşık ise bu rolde uzmanlaşmış birileri mutlaka olmalıdır. Yine bu rolümüz de aslında yazılımla direk bağlantılı olmasa da yazılım kısmında anılır çünkü yazılım ekipleriyle sıkı çalışmaları gerekir. Rolü anlatmak için tekrar yazdığımız web mağazası örneğine dönersek, kodu yazdırdık, dizaynı yaptık bitirdik. Mağazayı yakında açacağız. Fakat bir sorunumuz var. Web mağazasında kategori isimlerinden tut da ödeme onaylandığında çıkacak mesaja kadar birçok yazılı öğeye karar veremiyoruz. Bir şeyler yazdık ama profesyonel durmadı ve karmaşık. Bir diğer sorunumuz da bu web mağazasının sipariş yönetim kısmına bakacak iç ekiplerin bu mağazada neyi nasıl kullanacaklarını bilmeleri gerekiyor. Onlara kullanma kılavuzları hazırlamamız lazım. Ve son olarak projenin şu anki kısmına kadar yaptığımız tüm işi dokümante etmek istiyoruz ki bizden sonra bu projede çalışacak elemanlar da o dokümanları okuyarak ne nasıl yapılmış görebilsin.

İşte bu üç işi de yapan adama teknik yazar diyoruz. Teknik yazarlar yazılımcı ya da sistemci değillerdir. Teknik bilmek, yazılım süreçlerinden anlamak zorunda olsalar da bu insanların mühendis olması beklenmez. Esas işleri projenin a’dan z’ye dokümantasyonunu ve kullanıcı kullanım kılavuzları gibi yazın kısmını halletmektir. Dile hâkim olmaları gerekir. Özetle esas işleri yazılımın ortaya çıkartılması değil de ortaya çıkan ürün ve sürecin açıklanmasıdır. Az önce de dediğim gibi birçok organizasyonda bu rol yazılım ekibi içerisinde halledilir ve ek bir insan bulunmaz.
Evet böylece yazılım kısmının da sonuna gelmiş bulunuyoruz. Sırada ağ sistemleri var fakat hemen öncesinde yazılım ve sistem rollerinin her ikisine de değen fakat tam olarak her ikisinde de sayılmayan bir rolden daha bahsetmek istiyorum.

DevOps Mühendisi

Screen_Shot_2014-05-02_at_2.11.39_PM

Bahsedeceğim rolün adı devops mühendisi. Devops, developer ve operation yani yazılımcı ve operasyoncu kelimelerinden türetilmiş bir kavram. Şimdi bu kavramı ve rolü anlayabilmek adına biraz yazılım geliştirme süreçlerinden kısaca bahsedelim. Yazılım geliştirme eskiden “ki eski de diyemeyiz hala birçok yazılım bu şekilde dağıtılıyor” bir yazılım ekibi tarafından bir takvim ve özellik listesi dahilinde geliştirilir ve nihai ürün cd gibi bir medyaya aktarılarak ya da internet üzerinden müşteriye gönderilirdi. Daha sonra müşterinin sistem ekibi bu yazılımı alır bir sunucu üstüne kurar ve kendi kullanıcıları tarafından kullanılmasını sağlarlardı. Yazılım firması daha sonra müşterilerden gelen geri bildirimler ve hata raporları ile yeniden bir takvim oluşturur, mevcut yazılımda gerekli güncellemeleri yapar, yeniden paketler, müşteriye gönderir, müşteri ekipleri bu yeni paketlerle sistemlerini günceller ve hayat bu döngü içerisinde devam ederdi. Fakat bugün ki sunumun konusunu olmayan bazı gelişmeler sayesinde bu paket program yapısı birçok uygulama için software as a service denilen bir yapıya geçti.

16

Yeni yapıda yine yazılım geliştirme ekipleri ürünü ortaya koyuyorlar. Fakat bu sefer nihai ürün müşteriye gönderilmiyor. Ürün öncelikle test sistemlerine aktarılarak test ekipleri tarafından kontrol ediliyor. Test ekiplerinin hataları ayıkladıkları ve onay verdikleri değişiklik bu sefer firma tarafından yönetilen production sunucularına aktarılıyor ve artık son kullanıcı bu ürüne direk yazılım firması tarafından yönetilen sunucular üzerinden erişiyor. Böylece firma yazılım hizmetini kendi sistemleri üzerinde sunarak “software as a service – SaaS” dediğimiz bir model üzerinden çalışmış oluyor.
Bunu daha rahat anlamak adına şöyle düşünebilirsiniz. Önceden Apple iTunes üzerinden albüm alır albüm başına 10 dolar para öder ömrümüzün sonuna kadar bu şarkıya sahip olurduk. Artık bunun yerine Apple Music var. Tüm şarkılar Apple Music sunucuları üzerinde duruyor ve biz aylık 10 dolar para ödeyerek Apple müzik sunucuları üzerinden istediğimiz şarkıyı dinleyebiliyoruz. Anlattığım model buna çok benziyor.

17

Şimdi tekrar bu 2 farklı modele geri dönersek, yazılım camiası adına aradaki en büyük farkın önceden yazılımın kurulduğu yer müşteri sunucuları iken şimdi kendi sunucuları olması olduğunu görebiliriz. Demek ki eski sistemde bu sunucuların ayakta kalma sorumluluğunu müşteri sistem ekipleri alırken artık bu sorumluluk yazılım firmasının sistem ekiplerinde. Bunu bilgiyi cebe atalım ve diğer bir önemli farka geçelim.
Önceden yazılım paketlenir ve müşteriye ulaştırılır demiştik. Daha sonra müşteriden geri bildirim toplanır ve sürüm güncellemeleri yapılarak yeniden yayınlanır da dedik. Fakat bu yeni yapıda tüm kullanıcılar bizim sistemlerimize bağlı olduğu için geri bildirim meselesi günlerden saniyelere düşmüş durumda. Ayrıca önceden hataların bulunup bize bildirilmesini beklerken şimdi sistem bizim yönetimimizde olduğu için hatayı de biz tespit edip çabuk şekilde gidermek durumundayız. Bu da şu manaya geliyor. Önceden 3 ayda bir yeni sürüm yayınlayıp yeni özellikler yayınlarken şimdi bu işi saatler içerisinde yapabilmeliyiz ve zaten yapıyoruz da. Sürekli yazılıma yeni özellik ekliyor, hataları düzeltiyor, yeni sürüm yayınlıyor, bu sürümü test sistemlerine aktarıyor, test ediyor, onaylanan sürümü alıp kesinti olmadan son kullanıcının eriştiği sistemlere geçiyor ve bunu bir döngü halinde sürekli yapıyoruz.

Fakat burada bir sorun var. Yazılımcı dediğimiz insanlar kodu yazar dedik. Sistemci dediğimiz adamlar da sistemi kurup ayakta tutar dedik. Bunlar 2 farklı ekip. Ve maalesef bu iki ekibin bu yeni düzende çıkarları çatışıyor. Yazılımcı istiyor ki günde 10 tane yeni sürüm yayınlasın ve bu sürümler hemen test edilerek production sistemlere aktarılsın. Ama sistemci de “ayti’nin ilk kuralı olan çalışan sisteme dokunma ki çalışmaya devam etsin” mottosundan yola çıkarak sistemde bu kadar değişiklik yapılmasını istemiyor. Ayrıca sistemcinin görevi zaten sistemin üstünde uygulamayı alıp sürekli kurmak sürekli güncellemek sürekli performansını ölçmek ve çeşitli araçlarla bu anlattığım süreci otomatize etmek de değil. İşte bu çıkar çatışması ve eksik görev tanımı nedeniyle bu yeni yapıda zaman içerisinde birçok problem çıktı ve bu problemleri firmalar DevOps denilen bir yaklaşım biçimiyle ortadan kaldırmak istediler. DevOps dediğimiz şey bu yazılım ekibiyle sistem ekibi arasındaki çıkar çatışmasını elemine etmek için, daha çevik ve bariyerlerin ortadan kalktığı bir yapı kurabilmek. Bunu sağlamanın da tek bir yöntemi var, bu iki ekip arasındaki paylaşılan işleri otomatize edecek süreçler oluşturmak.

İşte DevOps mühendisi dediğimiz insanların yaptığı iş bu. Kodun yazıldığı ortamdan alınarak önce test ortamına aktarılması daha sonra test süreçlerinden geçen ve onaylanan kodun production dediğimiz son kullanıcı tarafından erişilen sistemlere aktarılarak sistemin işlemesinin sağlanması. DevOps ekipleri bunu yerine göre manuel şekilde yaparken yerine ve yapının büyüklüğüne göre bu iş için özel sistemler kurarak bu sistemler üzerinden süreci yönetiyorlar. Bu adamlar ne sistemci ne de yazılımcılar dedik. İkisinin de karışımı durumundalar. Bu insanlar yaptıkları işi yapabilmek için her iki tarafın da işleyişini bilmeleri gerekiyor. Sektörde uzun zamandır bu insanlar için sistemden anlayan yazılımcılar deniyor. Fakat bana göre bu tam tersi. Bu insanların yaptığı iş daha çok sistem tarafıyla alakalı, fakat işin içinde kod derlemesi de olduğu için ayrıca bu yapıyı otomatize edecek kod yazmaları da gerekeceği için kodlama becerileri de olması gerekiyor. Kısacası kodlama bilen sistemciler diyebilirim. Son dönemde özellikle revaçta olan bir bölüm ve iş ilanlarında sıkça karşımıza çıkıyor diyelim ve bu yazının da sonuna gelelim. Böylece Yazılım kısmını da tamamlamış olduk. Bir sonraki yazıda Ağ Sistemleri ile devam edeceğim.

Kategoriler:Genel

Tagged as:

Özgür ÖZTÜRK

Fani bir aytimenicir. Berlin'den bildiriyor, sizleri bilgiye boğmadığı zamanlarda bir şeyleri kapatıp açarak çalışmasını sağlıyor.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

w

Connecting to %s

%d blogcu bunu beğendi: