Tahminlerden gerçeklere

16 Apr

Günümüz tartışmalarından bir tanesi değişen iş yaşamı standartları ile beraber evden esnek çalışma ile standart ofis saatleri çerçevesinde ofisten çalışmanın çatışması. Fransa’da daha geçtiğimiz hafta çıkan yasa ile beraber çalışanların mesai bitimi ile beraber e-maillerine bile bakmalarının işverenleri tarafından zorlanamayacak olması.
Bununla beraber pek çok global firmanın 0 fazla mesai uygulmasını benimsediğini zaten gözlemliyorduk. Tabi ki çalışma zamanının mesai saatleri ile sınırlanmasının çalışanlar açısından insani bir boyutu var.
Pek çok işveren halihazırda zamanı harcarken bir kaynak olarak görmezken, fazlasının da çok kolay bir şekilde fazla mesai ile yaratılabileceğini düşünüyor. Tabi ki bu bakış açısı kolay elde edilen zamanın değersizleştirilmesi anlamına geliyor ve ölçümden git gide uzaklaşıyor.

Neden uzaklaşmasın ki? Çalışanlara yapmaları gereken işi söyleyin, ve deadline sıkıştırdığında fazla mesai yapmalarını söylemenize gerek bile kalmadan deadline baskısı ile çalışan kendi kişisel zamanından elinden geldiğince verecektir.
Ancak zaman içinde oluşacak algının günü verimsiz kullanmak ve nasıl olsa mesaiye kalıyorum yaklaşımı olacağından emin olmak gerekiyor.

Peki asıl sorun mesai saatlerine uymak mı? Yoksa işverenlerin zamanın verimli kullanıldığı kaygısı mı?

Bizzat gözlemlediğim örnekleri göz önüne aldığımda, özellikle emek yoğun işlerde kısıtlı zaman dilimleri ile çalışıyor olmak uzun vadede verimliliği artırıcı bir etken. Tabi ki konuyu sadece kısıtlı zaman dilimleriyle sınırlamak sorunun sadece bir kısmına dokunmak anlamına geliyor. Burada masaya konması gereken bir diğer değişken de sabit iş yükü.

İş = Zaman * Efor
denklemi üç aşağı beş yukarı emek yoğun işlerde bizim performans ölçümümüzün temelini oluşturuyor. Ancak yapılan işlerde genelde iş ölçümlenirken bizim efora (buna yapabilirlik de diyebiliriz) odaklanmamız gerektiğini düşünüyorum.

Çünkü efor kavramını ekibiniz içinde öngörebildiğiniz zaman, temelde uzun vadeyi daha iyi planlama ve ekipten neyi isteyebileceğinize daha rahat karar verme yetiniz oluyor. Bu da beklenti yönetimi ile doğru deadline’ları zorlayabileceğiniz ve her iki tarafı da mutlu edebileceğiniz anlamına geliyor. Şunu kabul edelim, bir müşteriye bir işin ne zaman yapılacağını net bir şekilde ifade ettiğinizde müşteri her zaman daha mutlu oluyor, tek sorun bu deadline’ı aşıyor olmanız. Doğru efor ölçümü ile bu deadline’ları doğru belirleme şansı gayet yüksek.

Bunun için uygulamada çok güzel örneklerden bir tanesi yazılım ekipleri için scrum. Scrum bu soruna 3 değişik (ama tamamlayıcı) açıdan yaklaşıyor:

Scrum’ın kanla yazılmış kurallarından bir tanesi sprint, yani öngörülebilecek kadar yakın zaman aralıkları ile çalışmak. Sprint’lerin özelliği ekibin bir projenin alt işlerinden bir kısmı için belirli bir zaman aralığını rahatsız edilmeden kullanabilmelerini sağlaması. Temel nokta, 2 haftalık bir sprint var ise, bu aralıkta ekibi rahatsız edecek herhangi bir faktöre izin verilmez, örneğin araya giren yeni müşteri istekleri gibi. Takımın sprint başında belli bir işi bitirmeye söz vermesi istenir ve takım bu hedefi gerçekleştirmek için o sprint süresini kullanır.

Bu bizi bir diğer faydaya getiriyor: Sorumluluk (ya da Accountability). Scrum ekipleri her sprint başında yapacakları işin belirli bir zaman aralığında yapmak üzere sorumluluğunu alırlar. Buradaki kritik nokta, işi yapmanın sorumluluğu ile işi belirli bir sürede yapmanın sorumluluğu arasındaki farktır.

Diğer bir nokta ise, bahsettiğimiz bu sprint’ler checkpoint görevi görür. Böylece bir sprint’te ekibin ne kadar iş bitirebildiği verisine çok rahat ulaşılır ve örneğin birkaç sprint’ten sonra önümüzdeki sprint’te ne kadar iş biteceğini öngörebilirsiniz. Ve scrumda bu kavrama Velocity denir, tam da bizim az önce efor diye bahsettiğimiz kavramın karşılığı.

Burada kritik olan nokta, çalışanların fazla mesai yapmalarını engelleyip, doğru velocity değerine ulaşıyor olmak. Böylece tahmin edilebilirlik hem işveren hem de çalışan tarafında maksimum seviyeye ulaşıyor.

Esneklikte kayıp yaşanmazken, tahmin edilebilirlikten kazanılıyor.

Free w/ Dignity

6 Dec

Çocukluğumuzun ana motiflerinden brittanica’nın, wikipedia ile girdiği ölüm kalım savaşını anlatmanın çok da anlamı olduğunu düşünmüyorum. Bu konuda tarafsız olmak zor olsa da, wikipedia’nın bile bir rakibe ihtiyacı olduğunu ve bilgiye erişim konusunda ne kadar alternatif yaratılırsa o kadar iyi olacağı da bariz.

Peki bu savaşta brittanica ne kadar doğru hamlelerle ilerliyor? Brittanica’nın temelde seçebileceği 2 yol vardı, premium bir service (ya da limitli free bilgi ile freemium bir servis) ya da free bir servis ve free üzerinden yaratabileceği bir para modeli.

İkincisinin doğruluğunu kanıtlayan onlarca örnek olmasına rağmen (Youtube – batıyor dense de), brittanica’nın birincisini seçmesini organizasyonun mevcut kültürel yapısından ötürü geliyor. Yıllarca onlarca kiloluk ansiklopediyi parayla kapıdan satan bir kurum, bilgiyi bedava vereceğim kararını kolay veremez.

Ancak uygulamadaki sıkıntılar gerçekten bu tip organizasyonların karar almada ne gibi bir kibir ya da cehalete sahip olduğunu gösteriyor (Kibir / cehalet yanyana çok anlamlı olmasa da aşağıda bahsedeceğim örnekte 2 büyük günahtan en az birini işledikleri aşikar).

Sadece merak için girdiğim brittanica modelini belli ki freemium olarak belirlemiş, bedava bir servis ama sınırlı; fazlası için üyelik. Ancak aynı güzel insan (Socrates) üzerinden yaptığım basit bir karşılaştırmada brittanica’nın UX (ya da UE – user experience) anlamında neyi atladığı açık; neden atladığı merakım.

Brittanica

Dizi sitesi benzeri bir reklam bombardımanı, URL’de yazan global lafına pek yakışmamış. Bunun dışında reklamların seçimindeki, eğer bir seçim varsa, saçmalık; beni yarın Socrates’i araştırmak isteyen bir çocuğun önüne viagra reklamı çıkar mı diye korkutuyor.

Diğer yandan wikipedia’nın tamamen free olmasına rağmen sahip olduğu sadelik bana tek bir söz bırakıyor, free with dignity.

Projeyi dokunarak yönetmek

12 Jan

Kişisel olarak proje yönetiminde şu ana kadar gördüğüm metodolojiler arasında en verimli olanının scrum olduğunu düşünüyorum. Ancak scrum gibi metodolojilerin en büyük handikapı sorumluluğun büyük çoğunluğunu belirli bir bireyden alıp takımın üzerine kaydırması. Bunu bir handikap gibi görmek doğru olmayabilir, aslında bu bir avantaj. Tek bir istisna hariç, o da ekibin belirli bir bilinç düzeyinin altında olduğu durumlar.

Konu yazılım geliştirmek olduğunda tabi ki teknolojinin bize sunduklarından maksimum seviyede yararlanmak istiyoruz ancak an geliyor ki bir yerde bir eksiklik var. Ekibimiz uzun süre boyunca Atlassian’ın çok iyi denilebilecek olan aracı Jira ve Grasshopper’ı kullandı proje yönetiminde. Ancak her seferinde bir yerlerde bir şeyler gözden kaçtı ve ekip ile projenin arasındaki bağ koptu.

Bizim günlük işimiz bir projeyi geliştirmek, sigara içerken yemek molalarında dahi bunu konuştuğumuz olabiliyor. Pek çok kararı ve tartışmayı hatta bu tip durumlarda bile çözümlediğimizi söyleyebilirim. Karşılıklı olarak koltuk takımına kurulup elimizde çayımız kahvemiz pek çok konuyu çok daha rahat bir şekilde tartışıyoruz.

Bu durumda işimizi kolaylaştırması gereken yönetim araçları bizim gerçekten çalışmak istediğimiz ortama biraz uzak kalmıyor mu?

Çoğunlukla sizin yazılımcılarınız da o tartışmanın / brainstorming seansının ardından JIRA’yı güncellemeyi külfet olarak görmüyor mu?

Sonunda pek çok ekip bunu başarmış olabilir. Doğru şekilde anlattıysanız eğer, iş yükünün dağılımının ve darboğazların tespiti açısından böyle bir aracın ne kadar önemli olduğunu yazılımcılara kabul ettirmiş olabilirsiniz. Ancak yine de, orada bir yerlerde ekibinizin aklında “ya ben bu jirayı neden güncelliyorum?” sorusu dönebilir.

Fiziksel araçlar belki de bu anlamda bizi bir adım geri götürüyor gibi görünebilir ancak daha iyisi yapılana kadar benim fikrimce hala en iyisi bu. Daha iyisinden kastımsa Minority Report tadında mükemmel dokunmatik yüzeyler.

Örneğin task board’unuzu bir beyaz tahta üzerinde post-it’lerle takip etmek, proje yönetiminizi sanal, sadece açtığınızda gördüğünüz saçma sapan bir yer yerine odanızın içine getirecektir.

Ve tutup bir işi tahtanın DONE bölümüne yapıştırmak, emin olun ki bir drag and drop hareketinden çok daha fazla gerçek olacaktır.

Bir işi gerçekten yapıyorsak, ona 1-2 saatimizi harcıyorsak, neden yönetimini de gerçek bir şekilde yapmayalım ki?

İleriye dönük olarak derler ya, bir gün yemekleri de haplar şeklinde yiyeceğiz. Ben nasıl o gün de şimdiki gibi gerçek bir yemeği tercih edeceksem, şu anda da gerçek bir task board’u tercih ediyorum.

Programming

5 Apr

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning.

Kardeş bu boş mu dolu mu?

16 Dec

Herhangi bir string değeri boş mu değil mi diye birkaç koşul yazıp kontrol eden arkadaşlara bir noel hediyesi olarak Apache’nin StringUtils’ini verelim. Mutlu noeller.

Bulut bilisim, sen nelere kadirsin…

5 Nov

Teknolojide son bir iki yilin gundem maddesi, bulut bilisim. Orjinali, herkes bilir cloud computing’dir. Isin ilginc yani yazilim yapan da bilir yapmayan da bilir. Cloud dendiginde, (bulut dediginizde o kadar havali olmuyor) guzel bir seyler canlanmis olmali ki son kullanicilarin aklinda, mesela pek cok uygulama da gitti bunu kendine isim edindi. Mac’te iCloud var yeni, OSX Lion ile geldi. Sonra Cloud diye bir uygulama daha var, dosya paylasimina yariyor. Eminim daha pek cogu vardir piyasada ki, cloud terimi tuttu.

Zaten son kullanici gormezse populer olmaz, o yuzdendir ki Steve Jobs oldukten sonra milyonlar goz yasi doktu de, Dennis Ritchie’nin ardindan taziyeler sunulmadi (Su anda Dennis Ritchie’yi Google’a yazdiysaniz tespitim dogru demektir).

Buluta geri donersek, biz de dustuk teknoloji onderlerimizin pesine ve hemen Bulut diye cevirdik ve yerlerstirdik dilimize. Bu arada kim bulut ismini hop diye araya soktu bilmiyorum, ama tebrikler, cok hizli davrandi. Pek cok kisinin dilinde simdiden, ornegin okuldaki hocalarimin cabalari bu kadar basarili sonuc vermemisti (Register yerine kutuk gibi).

Bulut kavraminin populerlesmesinin bir diger sebebi de teknoloji ile alakali sirketlerib yonetim kademelerinin de bu kelimeyi diline pelesenk etmis olmasi. Aslinda bulut kavrami cok uzun zamandir geyik noktasina gelmis olan scaling (olcekleme) olayindan bikmis olanlara ilac gibi geldi. Mesela benim eski sirketlerden birinde sunum yapilirdi, denirdi ki sunum esnasinda: Yazilimimizi olcekleyerek 1 milyar kullaniciya ayni anda hizmet verebiliyoruz. Sonra yonetimden hemen bir soru gelirdi: 1 milyar kullanici mi? Yani sinirli sayida kullaniciya hizmet veriyoruz(Hmm, sounds like a limitation to me. – true story). Simdi ise keyifle bulutun tadini cikariyorlar ve diyorlar ki nasil olsa bulutumuz var istedigim kadar kaynak eklerim. Moore yasasi sizinle olsun dostlarim, ama lutfen yazilimdaki performans sikintilarini bulutla mulutla ortebileceginizi sanmayin.

Neyse bilen bilir, Turkiye’de internetten, teknolojiden Ulastirma Bakanligi sorumludur. Ben pek anlatmadim bulut kavraminin ne oldugunu ki, sayin bakanimiz anlatsin, onun bulundugu yerde soz bana dusmez:

alt: herkes bilir kimse uygulamaz

31 Mar

Garanti mail - kotu kullanim ornegiHemen her tasarimci <img> etiketindeki alt ozelliginin ne ise yaradigini bilir. Ama uygulamaya geldiginde cogunlukla ya bos birakilir ya da kopyala-yapistir tasarimcilikla tum imajlar ayni alt metniyle dolar. Bu cogunlukla promosyon maillerinde gorunuyor. Yanda bir tane ornek var, Garanti’nin gonderdigi mail gmail tarafindan bloklanmis ve normalde erisilebilirlik amacli kullanilan alt ozelligi acik bir sekilde yanlis kullanilmis.

Web genelinde internet sitelerinin erisilebilirlige onem vermedigi zaten bir gercek. Ancak bunun bir de diger boyutu var. Bu tip basit dokunuslari yapmadiginizda gorme engellilerin web sitelerini kullanma ihtimalini ortadan kaldirmis oluyorsunuz. Denemek icin tarayicinizi seceneklerden imajlari ve flash icerikleri gostermeyecek sekilde ayarlayin. Ve birkac saat interneti bu sekilde kullanmayi deneyin.

Community WIN

24 Mar

jenkins logoAs some of you know, Jenkins was introduced after Oracle claimed the rights on the name “Hudson”. You can see the story here, from the first hand. The one interesting thing is, it is not a surprise, the new Jenkins community is growing rapidly, while Hudson is losing power.

I think it is an important thing that the opensource community may reacted so fast, since some people had “concerns” about the famous purchase. This is a clear community WIN.

Here are some observations about the community movement.

UE: Acilimi “user experience”

16 Mar

ntvmsnbc screen shotTurkiye’nin en cok ziyaret edilen haber sitelerinden birinde yeni bir reklam kampanyasi gordum. Kampanya kariyer.net’e ait. Ekran goruntusunden de anlasilacagi gibi siteye gomulu bir is arama formu koyulmus. Guzel bir fikir, cok muhtemel ilk de degil. Ama gordugum anda aklimda bir soru belirdi.

Arama yapilacak kelimeler alaninda kullanicilara yardimci olmak icin su yazilmis:

Anahtar Kelime (Örneğin java, flash, grafiker)

Aklima ilk gelen su oldu: Ornek kelimeler neden java, flash ya da grafiker? Eger ki kariyer.net’in en cok aranan kelimeleri bunlarsa anlarim, benim hatam, ozur dilerim.

Bir de diger tarafindan bakalim. Bunlar bana daha cok bu reklam formunu tasarlayan kisinin arayabilecegi seyler gibi geldi. Yani biraz “geek” isi. Soyle bir durum mu soz konusu? “Yazilimci Hasan, gel buraya, bize bir reklam formu yap bakalim.” Ben Hasan olsam, ben de bu tip kelimeler koyarim. Java’yi ornegin kesin koyarim.

UE, Turkce’de “kullanici deneyimi” (ya da en azindan oyle bir sey). “UE tasarimi” da herhangi bir urun tasarlarken kullanicilari neyin mutlu edecegini ya da ornegin reklamsa kullanicilari nasil cekecegini goz onunde bulundurarak yapilan tasarim.

Oncelikle tesekkur edelim kariyer.net’e bizim gibileri kullanici olarak sectigi ve bize ozel bir deneyim hazirladigi icin. Sonra soralim. Gercekten de bu 3 kelime mi en cok araniyor? Yoksa UE tasarimini yazilimciya birakanlardan misiniz?

Note to the non-turkish followers of the blog: Sorry to post this all in Turkish. But the whole story is based on a Turkish website, so won’t mean too much even if I translate.

Shipping code

16 Feb

facebook screenshotWe always had the discussions of when software is actually ready. Developers usually want the software should be shipped earlier than the QA wants. It is a matter of balance, but as you know it is never tested enough. You can always do more tests to say that the package is “safe”, even then the software can surprise you with an evil bug.

Facebook is one of the companies that I admire, which the rule “if you break it, fix it” applies. See this for more.

Anyway this screenshot is from the new chat and messages implementation, see the bottom images of myself appearing multiple times.

What?

Images of the user appears as contacts?!!?!

Multiple times?!?!?

So you expect an outcome of this bug, right? You cannot deliver a buggy piece of software.

No! You don’t need to take software this seriously. Ok, well, Facebook has a bug like this, nobody says their code sucks or stop using Facebook.

We JUST laugh about it.

Be cool!

Follow

Get every new post delivered to your Inbox.

Join 123 other followers

%d bloggers like this: