Is dunyasini, tirnak icinde “kurumsal” yapan en sevimsiz kalemlerinden biri de departmanlasma oldugunu dusunuyorum. Ozellikle yeni dunya internet girisimlerinde, finansman ve zamanin kisitli, yasam dongulerinin ve yatirim turlarinin cok kisa oldugunu bu donemlerde sirketlerin her konuda cevik (agile) davranmasi gerekirken, kendi icinde yarattigi departmanlasma surecleriyle rekabet avantajlarini giderek kaybettiklerini gormek cok zor olmasa gerek.

Sirketlerin birincil sermayesi sahip olduklari insan kaynagidir, ne para ne de pul. Sirket iki kurucudan olussa bile bu boyle. Insan kaynagi ne kadar kaliteli, bilgili veya tecrubeli olursa olsun, organik bir guc oldugu icin devamli motivasyona ve gudume ihtiyac duyar. Her ne kadar maddi olanaklarla bunlari yuksek tutmaya gayret etseniz de insanlari yaptiklari islerle mutlu edemediginiz surece orta ve uzun vadede cuvallarsiniz. Hatta calisanlariniz calistigi isle mutlu edemiyorsaniz onlara playstation odasi, langirt turnuvasi vs. gibi sahte mutluluk ortamlari yaratmaya calismayin, bu onlara oforik (euphoric) bir ilac vermekle ayni sey. Bir bakima placebo etkisi yaratmak da diyebiliriz.

Cevremizde ayakta kalabilen bircok startup’ in temel gucu de buradan geliyor. Startup sirketlerinde calisanlarin cogu piyasa altinda ucretlerle ve imkanlarla calismakta. Ama onlari motive eden oyle birsey var ki o da kucuk bir takim halinde projeleri etrafinda bir sinerji olusturup yaptiklari isi severek yapmalari. Kafalarini calistirarak birseyler urettiklerini hissetmeleri ve en onemlisi ortaya sifirdan bir urun ortaya cikariyor olmalari. Yani ozetle calistiklari sirketi, yaptiklari isle beraber sahiplenmeleri.

Calisanlarinizda bu sekilde bir sahiplenme duygusu yaratabiliyorsa sirketiniz, basarisiz olma ihtimaliniz cok dusuktur. Bu konuda Turkiye’ den verecegim en iyi ornek ise muhtemelen lidyana.com’ dur. Neredeyse butun calisanlar sirketleri hakkinda o kadar cok PR yapti ki bundan daha buyuk dogal ve organik bir pazarlama olamayacagi gibi calisanlarin da sirketlerinde zaten ne kadar mutlu oldugunun gostergesiydi bu. Nitekim lidyana.com’ un bir sene icerisinde geldigi nokta ve aldigi oduller asikar. Bu durumun calisanlarin calistigi sirketi ve projeyi sahiplenmesinden baska daha net bir aciklamasi olamaz.

Asil konumuza geri donelim. Departmanlasma diye basladik sahiplenmeye geldik. Tabi ki buyuk bir iliski var benim icin ama iliski tamamen ters orantili. Sirketiniz buyudukce kurumsal dunyaya adim atma egiliminde olacaksiniz, departmanlar yaratip, departmanlar arasi burokrasi kopruleri insaa edeceksiniz. Her departman birden fazla proje ile ugrasacak, ortaya bir proje/departman matrisi cikacak. Herhangi bir proje amac olmaktan cikip, maas araci haline gelecek. Neden mi? Cunku o cok degerli projenizin etrafinda konumlandirdiginiz birlikte calisan bir takim artik olmayacak, sinerji kaybolacak, uzmanlasma ve tecrube azalacak, motivasyon eriyecek ve en onemlisi heyecan bitecek.

 En kotusu de, her departmanin sirket icinde atomik bir varlik sergilemesi nedeniyle, departmanlar arasi iletisim hep bir cekisme icerisinde olacak. Birbirlerinin islerini kolaylastirmaktansa, yokusa surmeleri ve devamli bir soguk savas ortaminin bas gostermesi de cabasi.

Bu konuda nacizane tavsiyem, her disiplin icin departmanlar yaratmak yerine, disiplinler arasi takimlar yaratmaniz. Yani projenizi onlarca kisilik bircok departmanla yonetmek yerine, farkli disiplinlerden minimum insan kaynagi ile olusturacaginiz bir takimla yonetin.

Onerim cok basit, ornegin orta olcekli bir e-ticaret projesinin IT takimi bir proje yonetici, bir sistem yoneticisi, bir veya iki tane onyuz gelistiricsi, bir kac tane de gelistiriciden, test uzmani ve belki bir surum yoneticisinden olusan yaklasik 10 kisilik bir ekip olmalidir ve hatta bu ekip mumkunse yanyana oturmalidir. Hele verimli ve kaliteli bir ekibi biraraya getirdiyseniz projenizin etrafinda kendiliginden bir sinerji ve sahiplenme olusmaya baslayacaktir bile. Gereksiz yere sistem yonetimi departmani, onyuz gelistirici takimi, yazilim gelistirme ekipleri, proje ofisi gibi sacma departmanlasmalara gitmeyin. Inanin bos konusmuyorum. Dusunun ki Youtube Google tarafindan satin alindiginda hepi topu 67 kisilik bir kadrosu vardi, keza 1 milyar dolarlik Instagram’ i Facebook satin aldiginda sadece 13 kisiydiler. Benim e-ticaret sitem cok buyuk, bu sekilde calisamam demeyin, oldukca fazla IT operasyonu olan Youtube’ dan daha buyuk bir IT organizasyonuna gereksiniminiz asla olamaz.

Bu sekilde kazanacaginiz faydalar sayisiz, Herseyden once yarattiginiz takimin odak noktasini bire dusurerek, konsantrasyonlarini olabildigince arttiracaksiniz. Insanlarin proje uzerindeki uzmanliklari ve tecrubeleri artacak, uzerinde kafa patlatmaya baslayacaklar, uretecekler, katma deger saglayacaklar. Faydali oldukca motivasyonlari artacak, projeyi sahiplenecekler ve onunla gurur duymaya baslayacaklar. Sonunda herkes kazanacak, bir yandan mutlu, gururlu ve projenin bir parcasi olmakla boburlenen arkadaslarla calisirken bir yandan da cok daha verimli ve basarili bir projeye dogru kosacaksiniz.

Evet bir tl;dr’ e daha hosgeldiniz. Sirketinizi, departmanlar yaratarak uzerinde meydan muharabeleri yapilan verimsiz corak bir araziye cevirmek yerine, yag satarim bal satarim oynayan cocuklar misali projelerinizin etrafinda toplanmis iyi anlasan, projesini ve sirketini sahiplenmis, mutlu takimlarla donatin. Yani savasmayin, sevisin!

Turkiye e-ticaret sektorundeki en buyuk handikaplardan biri de genel gecer yazilim gelistirme sureclerinin isletilememesinden kaynaklanan kalitesiz projeler, spagetti kod tabanlari ve hata dolu uygulamalar ile karsi karsiya kalinmasidir. Ozellikle kulucka surelerini cok hizli atlatan startup sirketlerinde siklikla karsilasilan ve agresif buyumeden kaynaklanan bu kontrolsuz ve bilincsiz yazilim gelistirme, sirketin buyumesine paralalel bir sekilde belirli surecler ile kontrol altina alinmaz ise kod yazma, test etme, surum cikma vs. gibi konularda o sirketin devamli problemler yasayacagi asikardir.

Ustune basa basa sunu belirtmekte fayda var; Belirli bir aktiviteyi kontrol altina almak, belirli regulasyonlar ve burokrasi gerektirir. Startup sirketlerinin finans yonetimi ve rekabet avantaji bakimindan bu burokrasi gereksiz para ve zaman kaybina yol acacaktir. O yuzden isletilecek sureclerin dozu sirket buyumesine paralel ayarlanmali ve minimum burokrasi ile kurgulanmalidir.

Ister geleneksel (waterfall) ister cevik (agile) bir metodoloji calisin, bunlardan bagimisiz benim siddetle izlemenizi onerecegim belli basli temel is akislari mevcut. Klasik bir e-ticaret sitesi ornegini ele alirsak, is taleplerinin canli ortama alinana kadar izleyecegi yol bence su akisa olabildigince yakin olmalidir. 

1. Proje yoneticisi is sponsorlarindan topladigi ham is gereksinimlerini analistlerin de yardimi ile teknik gereksinimlere cevirerek proje yonetim aracinda ilgili is taleplerini yaratir ve onceliklendirir.
2. Ilgili yazilim ekibinin lideri Isin tahmini gelistirme suresini kendi tecrubesine de dayanarak bir tahminde bulunur. Bu kisi analist de olabilir, gelistirmeyi yapacak gelistirici arkadas da olabilir.
3. Ilgili yazilim ekibinin lideri isin kaynak planlamisini da yaparak isi uygun nitelikteki bir gelistirici arkadasa yonlendirir.
4. Gelisitirici, kod tabanindan bir dal (branch) cikarak gelistirmesini ilgili birim testleri ile beraber bitirir. Gelistirme suresi boyunca siklikla dalini ana dal ile gunceller (Integrate early, integrate often) Gelistirmenin CI araclari (build automation tools) ile gelistirmenin mevcut kod tabani konvansiyonlarini ve birim testlerini kirmadigindan emin olur.
5. Gelistirici gelistirme suresini, yani harcadigi vakti proje yonetim aracina not eder.
6. Gelistiricinin yazdigi kodu diger gelisitiriciler, en azindan ekip lideri gozden gecirir.
7. Test ekibi gelistirmenin tek basina kara kutu (black box) testlerini yapar, gelistirmenin fonksiyonel olarak is gereksinimleri karsilayip karsilamadigini kontrol eder.
8. Proje yoneticisi, surum yoneticisi ile beraber islerin onceliklerini gozeterek tamamlanmis islerden bir surum plani yapar. Surumu proje yonetim aracinda olusturarak hangi isleri kapsadigini belirler.
9. Surum yoneticisi ana daldan bir surum dali cikarak, gelistirmesi ve testi tamamlanmis isleri bu dal ile birlestirir. Yine CI araclarini kullanarak (build automation) birim testleri calistirir ve belirli kontrolleri isletir. Sonrasinda bu surum dalini bir surum numaralandirmasi yaparak paketler ve sistem yoneticilerine teslim eder.
10. Sistem yoneticileri surumu test ortaminda devreye alir. Test ekibi bu sefer munferit islerini birbirini kirmadigindan emin olmak icin entegrasyon testlerini yapar.
11. Entegrasyon testlerinin ardindan sistem yoneticileri surumu canli ortamda devreye alir ama son kullaniciya henuz sunmaz. Bu asamada yine test ekibi kabul edilebilirlik testlerini yapar. Bu adimda  bir yandan islerin canli ortamda saglikli, birbiriyle uyumlu calistigi test edilirken bir yandan da uygulamanin genel gecer test senaryolari isletilir. Test ekibi uygulamanin son kullaniciya hazir oldugunudan emin olur.
12. Sistem yoneticileri gerekirse kendi yuk testlerini uygular ve surumu son kullanicinin kullanimina acar.
13. Surum yoneticisi surumun canli ortamda devreye alinmasindan bir sure sonra surum dalini ana dal ile birlestirir.
14. Proje yoneticisi proje yonetim aracinda acilan isleri kapatir, Surumu canli ortama alindi olarak isaretler ve surum yoneticisi ile beraber gerekli duyurulari yapar.

Onerdigim akis 14 maddelik uzun bir liste gibi gorunse de bu akisi sirketinizin buyuklugune, is modeline ve kulturune en uygun sekilde degistirebilirsiniz.

Sirketinizin bu akisi kullanmasi halinde bir cok fayda saglamaya baslayacaksiniz. Bunlardan bir kaci

• Kod tabaninizin ana dali (trunk, master) daima canli ortamda calisan kod ile ayni olacaktir, ne eksik ne fazla. Bu durum, surum yonetimi, sistem yonetimi ve hata ayiklama surecleri icin oldukca onemlidir. Canli ortamda calisan kodunuz bi hayalet olmaktan cikar, satir satir hangi kodun calistigindan emin olusunuz.
• Canli ortamda bir sorun ile karsilastiginizda bir onceki versiyona donmek cocuk oyuncagi olacaktir. Sistem yoneticisinin bir onceki surumun arsiv paketini devreye almasi yetecektir. Bu kolaylik size acil durumlarda hatanin kaynagini bulmak gibi vakit kayiplarindan kurtarir.
• Hangi islerin hangi surumde cikacagina proje yoneticisi karar verebilir. Islerin kritiklik ve oncelik durumuna gore istedigi islerden istedigi gibi surum planlamasi yapabilir, yani hangi isin hangi surumde devreye alindigi veya alinacagi hic bir zaman surpriz olmaz.
• Gelistirmeler ana dala girmeden once munferit olarak test edilir ve kodu gozden gecirilebilir. Eksik, test edilmemis, kodu gozden gecirilmemis kod canli ortama hicbir sekilde gitmez.

Gordugunuz gibi bir kac surec duzenlemesi ile kod kalitenizi kontrol altina alacak ve surum planlama & yonetme kabiliyetiniz artacak, eksik veya henuz test edilmemis gelistimelerin onune gececeksiniz. Bu akis genel olarak feature branching denilen bir modeli temel almaktadir. Karsi model olarak CI (Continuous Integration) metodolojilerine de goz atabilirsiniz ama ben bu baglamda bu modeli sadece baslangic asamasindaki startup’ lara ancak onerebilirim. Buyudukce mutlaka feature branching modelini tercih etmeliler, en kotu ihtimalle ilk surumu ciktiktan sonra baslamalari gerekir.

Feature branching modeli ile kod tabaninizda, kod versiyonlama araciniz ile dallar ile siklikla calismak durumundasiniz. O yuzden kod versiyonlama araci olarak dallarla rahat calisabileceginiz ve istediginiz kod versiyonlama akisini kolaylikla kurgulayabileceginiz GIT veya HG gibi dagitik kod versiyonlama araclarini secmenizde cok fayda var. Ayrica surumlerinizi ve is akis sekillerinizi kolaylikla yoneteceginiz ve kurgulayacaginiz jira, trac, redmine gibi bir proje yonetim aracina, surum otomasyonu icin de jenkins, bamboo, hudson veya continuum gibi bir sunucuya ihtiyaciniz olacak.

Onerdigim bu gelistirme is akisina yakin modelleri gecmiste calistigim Markafoni ve Rocket Internet gibi agresif buyume gosteren e-ticaret sirketlerinde basari ile uyguladik. Bu sirketler gelistiricilerin canli ortama dogrudan kod gonderdikleri bir anlayistan siyrilip, surum yonetimi ve planlamasi yapan sirketlere donustuler.

Cok uzun bir yazi oldu, olabildiginice kisa tutmaya calistim ama aslinda bu konu cok daha uzun bir yazinin konusu inanin, belki de bir kitabin. Belirli surecler isletmek belki sikici olabilir, bazi burokratik duvarlar orebilir ama bunun dozunu ayarlamak, eglenceli bir hale getirmek ve departmanlasmalara gitmeden kurgulamak sizin elinizde. Burada gozetmeniz gereken en onemli konu, surecleri belirli yaptirimlarla dayatmak yerine, sirketinizin kulturu haline getirmektir, bunu sakin unutmayin.

Neredeyse cogu e-ticaret sirketinde yapilan gelistirmeler canli ortama alinmadan once bir sekilde test edilir. Iyi veya kotu, her sirketin kendine ozgu test prosedurleri vardir ama surecleri az biraz gelismis olanlarin cogunda yapilan gelistirmeler en az bir kere kara kutu (black box) testine tabi tutulur. Vauv terime bak demeyin, aslinda bu test metodu kabaca, test ekibinin yapilan herhangi bir gelistirmenin belirli senaryolar altinda gereksinimlerini karsilayip karsilamadigina kontrol etmesidir ve genelde de fonksiyonel testlerdir.

Bircok e-ticaret firmasinda genelde operasyonel onceliklerden ve zaafiyetlerinden dolayi fonksiyonel test ortamlari basi bos, bakimsiz, eskimis verilerle beslenen bir yer olmaktan oteye gitmez. Canli ortama surdugunuz yazilimin kalitesi, test ortamlarinizin canli ortamlariniza ne kadar yakin oldugu ile yakindan ilgilidir. Oyle ki, test ortaminiz kalitesiz ise test ekibinizin kaliteli veya kalitesiz olmasi birsey degistirmez. Hatta test ortaminda yakalanamayip, gercek ortamda ortaya cikan hatalarin akabinde test ekibinden “Test ortamlarimiz cok kotu, o yuzden” gibi laflar dahi isitebilirsiniz.

Yine uzattikca uzatiyorum, bu konu uzerine edilecek cok sozum var, ilerleyen gunler icin bol bol blog malzemesi olur. Simdilik konunun ozeti; test ortamlariniza olabildigince emek, vakit ve mesai harcamaniz, onlari gercek ortamlariniza olabildigince yakin tutmaniz gerektigidir. Bu mesai, urettiginiz yazilimin kalitesini ve kararliligini haliyle huzurlu, mutlu ve sadik musterleri arttiracak en onemli etken olacaktir, bana guvenin.

Uygulamanizin kostugu ekosistemi sistem, yazilim ve veri olarak uce ayirirsak, test ortamlari ile ilgili iyilestirmeler yaparken en cok sorunla karsilasacagimiz kisim ‘veri’ ayagi olacaktir ki bu ayak genelde veritabani ve statik icerik verilerinden olusur. Duzenli olarak veritabani kopyasi alip verileri maskelemek ayri bir dertken, statik icerikeri canli ortamdakiler ile esitlemek baska bir dert olur. Ozellikle terabaytlarca olcubilecek statik icerigi duzenli olarak ortamlar arasi esitlemek gercekten cok zahmetlidir. Genelde bu sorunu asmak icin dosya sistemi esitlemek yerine statik icerik sunucusu olarak gercek ortam sunucusu gosterilir ama bu sefer de test ortaminda eklenecek olan statik iceriklere (ornegin urun resimi) ulasilamaz.

Statik iceriklerle ilgili bu sorunlar aslinda kolayca asilabilir. Yapmaniz gereken tek sey, test statik sunucunuza gelen statik icerik istegini akillica islemeniz olacaktir. Eger test statik sunucunuza gelen istek herhangi bir fiziksel dosyaya karsilik gelmiyorsa, istegi canli ortam statik sunucusuna yonlendirebilirsiniz. Boylece bir birincil ve ikincil bir geri dusus (fallback) mekanizmasi olustursunuz. Yani, herhangi bir statik icerik istegi icin once test sunucusuna bakar, eger yoksa gercek sunucuya bakarsiniz. 

Bu teknigi, eger `nginx` kullaniyorsaniz cekirdek modullerden olan `try_files` (http://wiki.nginx.org/NginxHttpCoreModule#try_files) modulunu, eger `apache` kullaniyorsaniz dosya varligi notasyonunu ile `mod_rewrite` (http://httpd.apache.org/docs/current/mod/mod_rewrite.html) modulunu kullanarak uygulayabilirsiniz. Eminim baska web sunucularinda da ayni isi yapan baska yontemler mevcuttur.

Sonucta bu ipucunu ile test ortamlarinizdaki statik iceriginizi zahmetiz bir sekilde yonetebilirsiniz. Test ekibiniz, artik bos urun resimleri ile veya, bos icerik yonetimi gorselleri ile calismak zorunda kalmaz, cok daha kaliteli bir test ortamina kolayca sahip olursunuz.

Ilk duydugumda “O ne ki?” demistim, aklimin ucundan bile gecmemisti Istanbul’ da bir javascript etkinliginin olabilecegi (neden acaba?). Farkina vardigimda ise cok sevindim, ustelik javascript uzerine bir konferans olmasi beni iki kat daha mutlu etti. 28 - 29 Temmuz tarihlerinde Bahçeşehir Üniversitesi’nde düzenlenecek bu harika etkinligin detaylarina su sayfadan ulasabilirsiniz http://jstanbul.org/2012/

Maalesef Turkiye’ de yazilim uretmekte, zor bela uretilen kaliteli yaziliminlarin etrafinda sinerji yaratmakta, onlara gereken degeri vermekte ve haklarinda bu tip organizasyonlar ve etkinlikler duzenlemekte cok geriyiz. Onca emek verilen Pardus projesine sahip cikamayan, en onemli organizasyonlari “Ozgur Yazilim Gunleri” ve Devrim Gunduz’ in bu sene 2. sini duzenledigi “PostgreSQL Konferansi” etkinliklerinden ibaret olan bir ulkede bir kac arkadasin ozverili gayreti sonucu boyle bir organizasyona kavusuyor olmak gercektende cok olumlu bir gelisme. Umarin bu guzel etkinligi her sene aksatmadan, heyecanini kaybetbeden duzenlemeye devam ederiz. Hatta python etrafinda toplanan PyIst grubundan da ayni performansi bekledigimi belirtmeden gecemeyecegim.

Bu arada javascript uzerine iki cift lafim olacak. Javascript’ i sadece web onyuz gelistirmek icin bir betik zanneden, bunca zaman hep html bloklari arasinda gordugu kotu yazilmis javascript kodlariyla karsilasip onyargiyla javascript’ e cok “boktan” bir dil diyen, hatta CV’ lerine javascript becerisi cok iyi yazip da ”prototype” nedir diye soruldugunda “bilmem?” cevabini veren sozum ona javascript’ i “jQuery” den ibaret sanan bagnaz IT’ cilere sesleniyorum; yanlis yoldasiniz :) Size tavsiyem en azindan Crockford amcanin su unlu “JavaScript: The World’s Most Misunderstood Programming Language” makalesini okuyup, bir de Flanagan amcamizin “JavaScript: The Definitive Guide” kitabini edinmenizdir.

“Node, Connect ve Meryl ile Web Uygulama Geliştirme” adli bir sunum ile konusmacilari arasinda benim de yer alacagim jstanbul konferansinda bulusmak uzere. Ayrica etkinlik logosuna bayildigimi itiraf etmeden yazimi bitirmeyecegim. Emegi gecen herkesi eline saglik, tesekkurler.

Surum, cogu e-ticaret firmasinda cok gelismemis bir kavram olmakla beraber haliyle gelismemis bir kavrami nasil yonetileceginden bihaber bircok yonetici bulunmakta. Peki surum nedir? Surum, en genel anlamda, mevcut yaziliminizin varsa ortaya cikan hatalari giderilerek, yeni ozellikler eklenerek, gerekli konfigurasyonlari yapilarak ve sunuculari uzerinde guncellenerek son kullanicisina ulastirilmis halidir. Surum yonetimi ise surumun son kullanicya ulasmasina kadar gecen bu surecin organizasyonunu, planlamasini ve supervise edilmesini kapsar. Surumu nihai bir urun gibi dusunmekle beraber, bu yonden bakildiginida yonetilmesi gereken bir surec olarak da degerlendirebiliriz. Yonetilmedigi durumlarda ise IT icerisindeki herhangi bir problemde, normalde surum yoneticisinin gorevleri arasinda yer alan sorumluluklarin kimin ustelenecegi konusundaki belirsizlikler ve kavgalar sonucu kaos ortamlari olusur. Boylesi koas durumlarinda olusan operasyon zaafiyerlerinde ise genelde patron(!) veya IT yoneticisi tuttugunu oper :)

Akliniza hemen bu sureci yonetmek proje yoneticilerinin goreviymis gibi gelebilir, fakat surum yonetimi teknik bir yetkinlik ister. Proje yonetimi disiplinleri, surumu yonetebilecek teknik bilgilere sahip degildirler. Neden mi? Cunku surum yoneticisinin yazliminizin kod tabanina, uzerinde kostugu sunuculara ve sistemlere, 3uncu parti entegrasyonlara ve uygulama mimarisine hakim olmasi gerekir. Surum yoneticisi bu yonleriyle yetkin bir teknik insan kaynagi olmak zorundadir. Proje yonetim disiplinleri bu konulari kapsamaz. Ustelik proje yoneticileri genelde is (business) seviyesinde planlama ile mesgul olurken, surum yoneticileri cok daha fazla gunluk teknik operasyonlarla mesgul olabilmektedir. Bu konuyu belki soyle ozetlemek belki kafi gelebilir. Proje yoneticisinin isinin bittigi noktada surum yoneticisinin, surum yoneticisinin isinin bittigi noktada ise urun yoneticisinin gorevi baslar.

E peki bu surum yoneticisi dedigimiz kisi ne yer, ne icer? Soyle ozetleyelim;

• Proje yoneticisi ve varsa yazilim analisti veya yazilim lideri ile beraber onceden onceliklendirilmis islerin surum planlamasini yapar. Ayni surume girmemesi gereken isleri belirler. Risk unsuru fazla olan isler icin ozel surumler planlanir. Surum takvimi olusturulur.
• Gorev tanimina eklendiyse, kod versiyonlama araclarini (git, svn) kullanarak kod tabaninda ayri dallarda yapilan gelistirmelerin birlestirme islemini yapar. Gerektiginde eklenen kodlari gozden gecirir. Herhangi bir cakisma (conflict) durumunu duzeltir veya yazilim ekibine duzelttirir. Kod versiyonlama aracinda olusturdugu her surumu numaralandirir, etiketler ve duyurusunu yapar.
• Surume dahil olacak gelistirmelerin, analiz, yazilim, test ve devreye alim safhalarini supervise eder. Ornegin test ekibinden donen bir yazilim gelistirmenin, tekrar duzeltilmesi icin gerekli organizasyonu ve baglantilari saglar. Duzeltilebilmesi ve tekrar test edilebilmesi icin gereken sureyi goz onunde bulundurarak risk analizi yapar, o gelistirmeyi surumden cikarma kararini alabilir.
• Yine risk analizi yaparak kiritk surumlerin devreye alimlari icin en uygun zaman belirler. Proje teslim tarihi kisitlarini goz onunde bulundurarak yazilim, test, sistemi yonetimi bolumlerinden fazla mesai isteyebilir.
• Canli ortamda olusabilecek hatalar (bug, defect) icin alarm seviyeleri belirler. Gerekirse hatanin duzeltilmesi icin bir HOTFIX organize eder. Gerekirse bir onceki surume geri donulmesini isteyebilir. Surumleri planlarken, bir onceki surume minimum kayipla donebilme kosulunu goz onunde bulundurur, gerekeni yapar.
• Surum notlari hazirlar, bunu rapor eder. Hangi surumde hangi hatanin giderildigini hangi ozelligin devreye alindigini bilir.
• Geri bildirilen canli ortam hatalarini ilk olarak sistem yoneticileri ile beraber gogusler. Sistemsel olmayan bir durum ise risk degerlemesi yaparak gerekli aksiyonu alir.
• Surumlerin bir CI (Continous Integration) sunucusunda otomatik test ve yapilandirmalarinin yapilmasini saglamak, raporlarini incelemek ve sonuclarina gore aksiyon almak.
• Surumun 3uncu parti kutuphanalerin surumlerine olan bagimliliklarini bilir, takip eder, yonetir ve gerektiginde yeni versiyonlari ile gunceller ya da guncellenmesini saglar.

Gordugunuz gibi bir surum yoneticisinin bir baskasinin ayni anda yapamayacagi kadar cok gorevi var :) Boylesine ciddi gorevleri olan surum yoneticisinin haliyle karsilastigi pek cok zorluk da mevcut. Bunlardan birkaci;

• Test ortamindan veya canli ortamdan cok fazla geri donen hatali gelistirmeler.
• Eksik gerceklesen test senaryolari.
• Bilincsiz, patron odakli talep onceliklendirme, proje yoneticilerinin baskisi.
• Onceden planlanmis surum icin ekleme cikarma yapma istekleri.
• Sorumluluklarini yerine getirmesine engel olacak eksik yetkilendirme.

Surumlerin sagligi icin mutlaka bu durumlari en aza indirgemek veya tamamen bertaraf etmek gerekiyor.

Eger hatiri sayilir bir e-ticaret sirketi iseniz ve musterilere ulastirdiginiz yazilimin kararliligina onem veriyorsaniz mutlaka bir surum yoneticisi atamaniz veya istihdam etmeniz gerekir cunku surum yoneticiniz mutlu musterileriniz gorunmez kahramani olacaktir.

Gectigimiz haftalarda e-ticaret sektorunde cogu kisinin hizla yayilan dedikodularla “Rocket Batiyor” seklindeki yorumlari hepimizin kulagina calindi. Rocket’ in Turkiye ayaginda bir iki girisimini kapattigini, uzerine bir takim isten cikarmalar yaptigi konusunu bilmeyen kalmadi. Bir de zaten bilindigi uzere cesitli medyanin ve guclerin devamli olarak yuruttugu karalamalarla kotu bir unu de olunca herkesin kotu kahkalari arasinda “Hahaha biz dememismiydik, batiyor isteee” nidalarini duyar gibi olduk. Rocket Internet tabi ki batmiyor. Rocket Internet bugun 400’ e yakin calisani ile inanamayacaginiz kadar guclu sermayesi ile Turk e-ticaret pazarinin en guclu rekabetcilerinden.

Rocket pazarda hizli bir sekilde yer almak isteyen butun sirketler gibi agresif bir sirkettir. Butun bu sirketler karliligi dusuk olan girisimlerini sonlandirabilir, gerektiginde kuculebilir, ihtiyac halinde isten cikarmalar yapabilir. Buna ben de dahil. Bunlari yazdiktan bir hafta sonra ben de bir sekilde isten ayrilabilirim. Bunlarin yaninda Rocket’ in ustune yapistirilan “kloncu” lakabini da baska bir karalama olarak goruyorum. Donup calistiginiz sirkete ya da cevrenizdeki diger e-ticaret sirketlerine bir bakin. Kac tanesi bir “klon” degil. E-ticarette basarili her model yerellestirilip klonlanmistir. Bunu global bir sirket butun dunyada yapiyor diye “kloncu” damgasini yemesi bence abesle istigaldir. Tabi ki boyle bir sirketin kendi ulkesine gelip bir is modeli klonlamasi hakli olarak o ulkenin yerlilerini kizdiracak ve korkutacaktir. Ve haliyle kotulemeler kacinilmaz olacaktir.

Rocket’ de gercekten akilli, bilgili ve becerikli insanlarla beraber calisiyoruz. Cogu cok iyi universitelerden mezun, cok iyi yerlerde calismis kisiler. Global bir firma olmanin getirdigi avantajlari kullaniyoruz. Iceride yazismalarimizi yabanci dille yapiyor, baska ulkelerden gerektiginde yardim aliyor, gerektiginde yardim ediyoruz. Tanidigim cogu firmaya gore cok daha gelismis surecleri var ve bir de onlari devamli olarak iyilestirmeye calisanlar tabi ki.

Partileriyle, oyun odasiyla, happy hour’ lariyla, samimi ve sicak ortamiyla Rocket Internet gercekten eglenceli ve bir o kadar da profesyonel bir sirket. En guzeli devamli taze demlenmis cayiyla, turk kahvesiyle bir cay ocagimiz var, daha ne olsun :)

Butun bunlari herhangi bir kaygi veya guduleme ile yazmiyorum, tamamen kendi dusuncelerim. Olabildigince kendi adima calistigim sirketi tanitmaya, hakkindaki dedikodularin asilsiz oldugunu anlatmaya calistim, becerebildiysem ne mutlu.

“Premature optimization is the root of all evil” demis Donald Knuth amcamiz. Kucuk bir ornekle ozetlemek gerekirse; eger ilk etapta gelistirdiginiz yazilimi toplamda 5 kisi kullanacaksa, 10,000 kisinin ayni anda  kullanmasini saglayacak bir mimariyle ise baslarsaniz hem yaziliminizi gereksiz yere komplekslestirirsiniz hem de proje teslim tarihinizi uzatirsiniz. Gunumuzde bu onerme sadece yazilimda degil yazilimin uzerinde kostugu butun sistemler icin gecerli. Eger e-ticaret formunda yeni bir startup sirketi iseniz, ilk uc ay icin anlik tahmini kullanici sayiniz 50-150 civari ise, yuk dengeleyeci (load balancer) olarak bir netscaler kullanmaniza gerek olmayacaktir. Hem lisans hem de operasyon ve operator maliyetleri belinizi bukebilir, is modeliniz tutmazsa da bunlarin hepsi elinizde patlayabilir. Netscaler yerine projenizin ilk donemlerinde cok daha ucuz hatta bedava acik kaynak cozumler uygulamak mumkun.

Peki, ya is modeliniz cok tutararsa, ya birden e-ticaret sitenize gelen fazla talebi karsilayamaz duruma duserseniz? E-ticaret kelimesi ile hitap ettigim kitleyi kisitladigimi dusunmeyin, sagladiginiz hizmet bir IaaS, SaaS veya bir PaaS servisi de olabilir. Boyle bir durumda dikey ve, veya yatay olceklendirmeye gitmeniz gerekecektir. Dikey olceklendirme ile uygulamanizin bulundugu sunuculardaki donanimi ve yazilimi iyilestirip optimize etmeniz, yatay olceklendirme ile de uygulamanizi birden fazla sunucu uzerinde kosar hale getirip sunucu sayini arttirmaniz gerekecektir. Tabi ki oncelikle dikey olceklendirmeye basvurmak en sagliklisi olacaktir.

Aslinda uzattikca uzatiyorum. Gelmek istedigim nokta farkli. Butun bu olceklendirme carelerine basvursaniz bile bu surecte olceklendiremeyeceginiz, genelde darbogaz (bottleneck) ya da kirilma noktasi diye cevirdigim SPOF (single point of failure) sistem elemanlari ile karsilasma ihtimaliniz cok yuksek. Bunlar genelde replikasyon mimarileri tam olgunlasmamis veritabani sunuculari veya sanal pos gibi ucuncu parti (3rd party) entegrasyonlari olarak karsiniza cikacaktir. Peki boyle bir durumla karsi karsiya kaldigimizda neler yapabiliriz? Tabi ki careyi yazinin ileriki bolumlerinde kisaca MQ diye bahsedecegim mesaj kuyrugu (Message Queue) sunucularinda bulacaksiniz. MQ sunuculari yapmak istediginiz her islemi bir siraya sokarak gerceklestirmenizi saglar. Bu ayni bir gise gorevlisinin, onunde yigilan binlerce konser izleyicisine, kafayi yemeden bilet kesebilmesi icin onlari bir turnike sistemi ile siraya sokup isini rahatca yapabilmesini saglamaya benzer. Bu yapi size, sisteminizin ayni anda kaldirabilecegi kadar is yuku gelmesini garanti edecektir. Tabi ki talep fazlalastikca kuyruk uzayacak, haliyle kuyruk sonundakilerin bekleme suresi uzayacaktir. Ama bu durum sisteminizin talebi karsilayamayarak tamamen cevap veremez hale gelmesi ve cokmesi durumundan alternatif maliyeti cok daha dusuk bir durumdur.

Bir dusunun; musterinize satis islemini gerceklesitrdiginiz aksiyonun icinde hem veritabani hem de sanalpos islemi var. Sisteminiz, ayni anda 10 kisiye cevap verebiliyorsa, kuyrukta bekleyen 100 kisi biraz daha bekleyerek islemini gerceklestrebilecektir. Bu da daha az da olsa mutlu musteri ve kayipsiz ciro demek. Ama 100 kisinin ayni anda istek yapmasi ile sisteminizin sadece az bir kismina cevap verebildikten sonra kilitlenerek veya cokerek bakim calismasina girmek zorunda kalmasi mutsuz ayni zamanda kuskun musteri ve satis kaybina ugrayacaginiz icin dusuk ciro demek olacaktir.

Iyi hos ama bu yapinin getirdigi zorluklar yok mu, elbette var. Herseyden once, musteri deneyimini dusunmeniz gerekir. Biraz fazla bekletmek zorunda kaldiginiz musteriyi kullanici arayuzunde onu her sekilde bilgilendirecek ve bilinclendirecek bir duzen saglamaniz sart. Ona isleminin basladigini, sona ermeden ekrani kapatmamasi gerektigini, belirli bir sure daha beklemesi gerekebilecegi gibi bilgileri saglikli bir sekilde aktarmak gerekecektir. Bu bir son kullanici deneyimi (UX) sorunudur ve cozulmesi gerekir.

Teknik bir sorun olarak ise kuyruga aldiginiz her islemin musteri ile olan baglantisini (http connection) uzun sure korumak zorunda olmaniz sisteminizin ayni anda kaldirabilecegi baglanti sayisi ile ilgili sizi sikintiya sokacaktir. MQ ugulamalari asenkron calisabilen yazilimlardir. Siz islemi kuyruga gonderirsiniz, MQ uygulamasi o islemin isi bittiginde sizin yaziliminizi uyarir. Boyle bir durumda musterinin satis islemi icin yaptigi baglantiyi korumak zorunda kalmadan Javascript/AJAX polling metodlari ile siparisin durumunu sunucuya belirli periyodlarla (2-3 saniyede bir) sorabilirsiniz. Herhangi bir sonuc dondugunde ise son kullaniciyi bilgilendirebilirsiniz. Daha fazla teknik detaya girerek yaziyi uzatmak istemiyorum.

Sonuc olarak dikey ve yatay olceklendirme metodolojilerin yaninda artik MQ sistemlerini kullanmak, onlari benimseyerek icsellestirmek ve haklarinda uzmanlasmak gerek. E-ticaret sirketlerinde IT kanadinin yazilim ve sistem mimarilerini yapilandirirken bu uygulamalarin hali hazirda alet cantalarinda oldugunu bilmeleri ve akillarinda tutmalari oldukca faydali olacaktir.

Calisan bir grup gelistirici uzerinde homojen bir is yuku dagilimi saglamak gercekten cok zor zanaat. Farkli alanlarda uzmanlasmalar, farkli motivasyon seviyeleri, farkli is beceri hizlari, farkli uretim kaliteleri, farkli ikili iliskiler ve sosyal duruslar nedeniyle gruptaki herkese esit bir is yuku paylastirmak cok zorlasiyor. Askerde soyle bir motto vardi: “Bir isi iyi yaparsan, o is hep senin uzerine kalir”. Bu gercekten de dogru :) Bu onerme sadece askerde degil her yerde gecerli emin olun. Bu dengesizlikler kaynak planlamasini yapan kisinin problemi olsa da, nasrettin hoca’ nin fikrasinda oldugu gibi soyle sorasim geliyor; hirsizin hic mi kabahati yok? Elbette var. Insanlarda karaktarlerinden veya icinde bulundugu calisma kosullarindan gelen farkli dozlardaki motivasyon eksikligi kaynak planlamasini yapan kisiyi gunluk islerin verimliligini korumak adina ister istemez isi iyi yapan kisiye yonelmeye itiyor.

Bu dengesizlikler ile kafa patlatirken aklima gelen fikirlerden birisi su oldu. Herkes o an kimin hangi isle ugrastigini gorebilseydi, insanlarin kendilginden motive olmasini saglayacak otomatik bir sosyal gudumleme ve yaptirim mekanizmasi olusurdu. Aynen havalimanlarindaki ucus bilgisi ekranlari gibi, herkesin gorebilecegi bir yerde ve buyuklukte, su an kim nereye ucuyor ekrani :)

Fikrimi hayata gecirirken lojistik yonden cok zorlanmadim. Sistem yoneticisi arkadaslarin saga sola yerlestirdigi, sistem monitoru olarak kullanidigmiz 102 ekran led televizyonlardan, goz onunde, herkesin rahatlikla gorebilecegi bir yerde olanini rica ettim, sagolsun kirmadilar. Isin gerisi zaten bana kaldi. Proje yonetim araci olarak kullanidigimiz JIRA ile konusan kucuk bir uygulama yazdim. Teknik ayrintilara cok fazla giremeyecegim, uygulamanin kaynak koduna buradan ulasabilirsiniz https://github.com/kadirpekel/hodri . Uygulamanin yaptigi is sadece JIRA’ dan herkesin o an uzerinde calistigi isi alip, buyuk puntolu, renkli ve eglenceli kutularla gostermek oldu.

Y U NO WORK? Olaya biraz da eglence katmak icin bu unlu internet mimi olan resimi o an uzerinde hic bir is olmayan arkadasin panelinde esprili bir sekilde gostermeyi de ihmal etmedik.

Isin daha guzel tarafi, bu uygulama ile beraber gunluk scrum toplantilarina basladik. E-ticaret sirketlerinde, is modeli nedeniyle farkinda olmasakta zaten kendiliginden scrum’ a benzer yazilim gelistirme metodolijileri uygulanir ama genelde bu gunluk scrum toplantilari yapilmaz, atlanir. Scrum’ in ne oldugunu su adresten inceleyebilirsiniz http://en.wikipedia.org/wiki/Scrum_(development) Artik her sabah ekip olarak toplaniyor ve o gun kim hangi isle ugrasiyorsa birbirimize anlatiyor, yorumluyor ve tartisiyoruz. Bu da ekip ici iletisimi, farkindaligi ve motivasyonu olumlu yonde etkiledi. Herkes kendi kapisinin onunu daha dikkatli supurmeye basladi.

Benim icin fikrin verim olarak geri donusu ilk etapta oldukca olumlu oldu. Herkes, hangi is ustunde oldugunu gostermek icin ozen gostermeye basladi ve bu, gunluk scrum toplantilariyla beraber ekip olarak verimliligimize yansidi ve fazlasiyla da yansimaya devam edecektir diye dusunuyorum.

Son yillarda, dunyada ve onu takiben Turkiye’ de olaganustu bir buyume gosteren E-ticaret sektoru yapisi geregi cevirimdisi (offline) ticaret mecralarinda faaliyet gosteren sektorlere oranla buyuk farkliliklar gostermekte. Dijital bir mecra olmasi nedeniyle geleneksel ticaret mecralarindan farkli olarak kendi icinde bir cok yeni disiplinini ve sureci barindiran E-ticaret, disaridan yonetimi cok basit gibi gorunse de aslinda oldukca kompleks onlarca problemi beraberinde getiren bir is modelidir.

Gunumuzde milyonlarca lira hacmi ve musterisi olan bir sektorun haliyle bir cok rekabetci girisimcisi mevcut. Boylesine agresif bir rekabet ortaminda E-ticaret sirketlerinin birinci faz onceligi oldukca fazla musteri kazanmak, ikinci faz onceligi ise oldukca fazla satis ve kar elde etmektir. Bu amaclari yerine getirmek icin sirketler, kizisan bu yaris ortaminda musteriye hizli, kaliteli ve guvenilir urun ve servisler sunmalidir ki bunu ancak kendi icinde cevik ama kaliteli isler cikararak yapabilir.

Fakat burada sikintilar, musteriye cesitli urun ve hizmetleri servis ettigimiz, onlarla interaktif bir sekilde iletisime gectigimiz zeminin bir web sitesi, yani bir uygulama, yani bir yazlim olmasi noktasinda basliyor. Hatta oyleki urun ve hizmetlerin vitrine konulup satisinin yapildigi bu web uygulamasinin yaninda arka planda calisan kaynak planlama, musteri iliskileri, tedarikci zinciri, is zekasi gibi bir cok farkli yazlim cozumleri uretiliyor ve yonetiliyor. Haliyle pazarlama, is gelistirme, operasyon, lojistik, finans, musteri hizmetleri gibi bir duzine departmandan gelen taleplerin hepsi IT tarafinda toplaniyor ve E-ticaret sirketlerinde bu bolum tam anlamiyla bir darbogaz haline geliyor. Bu da demek oluyor ki IT’ nin verimliligi, sirketin verimliligini buyuk olcude etkiliyor. Ustelik IT’ nin bir cok zor teknik disiplin ile ugrasmasi ve bu disiplinler uzerine uzmanlasmis personel bulma konusunda oldukca zorlanmasi gibi kendisinden kaynaklanan bir cok sorunu var ki onlar da isin tuzu biberi.

Bugune kadar ki is hayatimda yasadigim tecrubelere dayanarak, IT ustune yagan bunca talep ve beklenti baskisi altinda ortaya cikan problemleri konu basliklarina gore su sekilde siralayabilirim.

• Talepleri onceliklendirme
• Eksik surum, proje ve degisim yonetimi
• Personel verimliligini olcme zorlugu
• Is teslim zamanlamasi ve tahmini
• Operasyonel islerin yogunlugu ve baskisi
• Belirlenmemis surecler
• Yeterince test edilemeyen gelistirmeler
• Uzman IK darligi
• Yanlis yapilanma ve departmanlasma sonucu sahiplinme eksikligi

Basliklar oldukca genel olmakla beraber her biri kendi bir cok teknik zorlugu ve problemi barindirmakta. Ilerleyen gunlerde bir coguna detayli olarak deginmeye calisacagim. Burada gelmek istedigim nokta, E-ticaret sirketlerinin birinci onceligi, organizasyonuyla, yapisiyla, IK butcesiyle ve surecleriyle IT olmalidir. Yukarida saydigim bu problemlerin uzerine gitmeli, kayda deger iyilestirmeler yapmalidir. Dusunun ki, donusum oranlarini (conversion rate) yukseltecek son kullanici deneyimini (UX) iyilestirme faaliyetlerinden, siteye ayni anda akin eden yuz binlerce musterinin yarattigi servis yukunu karsilamak icin yapilan optimizasyonlardan, musteri gizliligini saglamak icin yapilan guvenlik kontrollerinden tutun da herhangi bir siparisin sahibine hizli ve eksiksiz sekilde ulasmasini saglayacak logistigi yoneten yapay zeka sistemlerine kadar hersey IT’ nin sorumlulugunda. Boyle genis bir uzmanlik yelpazesi ile sirketin marsandizi olan bir unsur o sirketin agirlik merkezini olusturmalidir.

Butun bu argumanlar goz onune alindiginda IT sureclerinin iyi planlaniyor ve yonetiliyor olmasi kar topu etkisiyle sirketin diger butun birimlerinde verimlilik artisina yol acacaktir ki bence bu durum, sermayenin yaninda E-ticaret sirketlerinin rekabet gucunu artiracak en onemli etkendir.