Yazılım geliştirme gitgide çevik yöntemlere daha uygun hale geldi. Web ‘in gündelik hayata inmesiyle yazılım üretiminin artması ve son kullanıcının doğrudan ürünü belirleyebilir hale gelmesi bunda etkili oldu. İteratif geliştirme yöntemleri ile web uygulamalarında birçok katmana yayılmak birçok karmaşıklığa yolaçtı. Bu yazıda işte böyle verimsizliklere etkili çözüm getirmeye çalışan bir şirketin çıkardığı bir kitabı anlatacağım. 37Signals, Ruby on Rails platformunun yaratıcısı. Ayrıca Basecamp, Campfire, Backpack, Writeboard ve Ta-da List gibi web tabanlı yazılım servis ürünlerinin geliştiricisi. Getting Real ile kendi yaşadıkları deneyimleri özellikle web tabanlı ürünler geliştirmek isteyenlere sunuyorlar. Herhangi bir çevik yaklaşımın adını anmasalar da “gerçek hayat” deneyimleri onları çağrıştırıyor. Kitaplarını kendi deneyimlerinden yazdıkları için daha gerçekçiler. Yirmi dilde yayınlamaları da tanıtım amacı için gösterdikleri eforu belli ediyor.
Getting Real ‘ın ana fikri daha küçük bir ürünü, daha hızlı ve daha iyi bir biçimde üretmek. Başlangıç için kullandıkları prensiplerden biri, daha azını yapmanın rekabetten sıyrılmanın pek akla gelmeyen ancak olası bir yolu olduğu. Yazılımı kendiniz için yapmanız tutku ve enerji katacaktır. Dışarıdan para bulmaktansa kendi kendinize olmanız ekstra stresi azaltır. Zamanı ve bütçeyi sabitleyip kapsamı değişken yapmak kolaylık sağlayacaktır. Ürününüzün nasıl olacağını bulmak için nasıl olmayacağından faydalanabilirsiniz. Mesela 37Signals şirketi proje yönetimi için yola çıktığında Microsoft Project gibi büyük ve hantal olmamayı seçmişler ve ortak paylaşılan mesajların ana fikir olduğu Basecamp ‘i yaratmışlar. Eğer bir geliştirme sizi heyecanlandırmıyorsa ortada bir hata vardır.
Akabinde hantal olmamanın yöntemlerinden bahsediyorlar. Mesela üründe ne kadar az özellik olursa değişmesi o kadar kolay olacaktır. Değişim web dünyası için elzemdir, dolayısı ile değişim kolaylığı ve değişim maliyetinin düşüklüğü en önemli kriterdir. İlk versiyon için üç kişilik bir takımdan fazlası israftır. Bir kişi kodlar, bir kişi grafik tasarım yapar ve biri de iki dünyayı da anladığı için süpürür. Limitasyonları engel olarak değil yaratıcı çözümlere ulaştıran fırsatlar olarak düşünün demişler. Mesela 37Signals Basecamp ürününü ortaya çıkardığı zaman işletmek zorunda oldukları bir tasarım firması, bu firmanın mevcut müşteri işleri, Danimarka ‘da David isimli 7 saat fark ile çalışan bir iş arkadaşları, çok küçük bir ekipleri ve iç kaynaklar ile fonlama gibi birçok kısıtlamaları varmış. Bir önemli özellik de kendinizi büyük firmalardan ayrı bir yere koymak ve bu sayede daha kişisel ve arkadaşça olabilmektir.
Daha sonra öncelikleri ortaya koymuşlar: Ürününüz için tek noktayı vurgulayan bir cümlelik bir vizyonunuz olsun. Detayları daha en başta gözardı edin ve büyükten küçüğe doğru çalışın. Olmayan problemleri çözmeye çalışmayın, önce problemin ortaya çıkmasını bekleyin (daha bugün yemekte Emre Bey ve Alev Hanım ile konuştuğumuz şey). Doğru müşterileri işe alın, yani doğru pazarı bulun ve sadece onlara yönelin. Herkesi memnun etmeye çalışırsanız kimseyi memnun edemezsiniz. Ölçekleme gibi problemleri daha sonra çözün, önce böyle bir probleminiz olsun. Taraf tutan ve belirli yönlerde tercihleri olan vizyonlu bir ürününüz olsun ve vizyonunuzdan ayrılmayın.
Ürünümüze özellik eklerken nelere dikkat etmeliyiz? İki özelliği yarım yamalak yapacağına bir tanesini düzgün yapsın. Neyin önemli olduğunu düşünüyorsanız onları yapın ve diğerlerini dışarıda bırakın. Bazı özelliklerin neden olmadığını soran veya isteyen olursa, bunların o kadar da önemli olmadığını belirtin. Yeni özellik taleplerine öncelikle hayır deyin. Gelmeye devam ediyorlarsa ancak o zaman düşünmeye başlayabilirsiniz. Her bir ekstra özelliğin çığ gibi büyüyecek etkilerini düşünmeden geçmeyin. Mesela her bir yeni özellik aşağıdaki yaşam döngüsüne girecektir:
1.Hayır deyin,
2.Yeni özelliği değerini ispat etmesine zorlayın,
3.Eğer yine “hayır” ise iş burada biter. Eğer “evet” ise devam eder…
4.Ekran(lar)ı çiziktirin/ui,
5.Ekran(lar)ı tasarlayın/ui,
6.Kodlayın,
7-15. Test edin, değiştirin, test edin, değiştirin, test edin, değiştirin, test edin, değiştirin…
16. Yardım dokümanının değiştirilip değiştirilmeyeceğini kontrol edin,
17. Ürün turunu güncelleyin (gerekiyorsa),
18. Pazarlama materyalini güncelleyin (gerekiyorsa),
19. Servis şartlarını güncelleyin (gerekiyorsa),
20. Herhangi bir verilmiş sözde kopukluk var mı diye bakın,
21. Fiyatlandırma yapısında etkilenme olmuş mu kontrol edin,
22. Ürünü tekrardan sürün,
23. Nefesinizi tutun.
Önceliklerden bir tanesi de yönetebileceğiniz bir ürün sahibi olmaktır. Herkese 1GB alan sağlamak mümkün olacak mıdır? Ödemeler gibi operasyonel durumları yönetebilmek mümkün müdür? Genel konseptler üzerine bir ürün yaratın ve insanların kendilerine özel çözümler üretmelerine fırsat tanıyın. Yeni özellik taleplerini kayda almayın ve çöpe atın. Müşterileriniz önemli olanları size hatırlatacaklardır. Kullanıcılara hangi özelliği istediğini değil hangi özelliği kullanmadıklarını sorun mesela. Hiçbir zaman daha fazla özellik koymak cevap olmayacaktır.
Süreç açısından da çok önemli noktaları vurgulamışlar: Biran önce gerçek ve çalışan bir yazılım elde edecek şekilde ilerleyin. İteratif olarak ilerleyin. Beyin fırtınasından, taslak çizime, oradan HTML sayfaya ve sonra da koda gitmek şeklinde, fikirden çabucak uygulamaya ulaşın. Özellikler, ayarlar gibi ekranlardan uzak durun. Küçük detayları siz düşünün ki müşteriniz düşünmek zorunda kalmasın. Fazla analizden felç olmayın. Unutmayın bu bir web uygulaması, beyin ameliyatı değil 🙂 Uygulamanızı gerçek dünyada, gerçek insanlarla ve gerçek data ile test edin. Release ve beta diye iki ayrı sürümünüz olmasın. Zamanı bölerek kısaltın. 12 haftalık bir projeyi 12 tane haftalık proje olarak düşünün ve işleri de buna göre bölerek ilerleyip sadece bir birimlik işler üzerine yoğunlaşın.
Organizasyon açısından da değerli katkılarda bulunmuşlar: Bir olun, fazla işbölümü amaçlı bölünmeyin. Çoğu firma tasarım, geliştirme, reklam, destek ve pazarlama gibi bölünmelere gider. Bu özelleştirme yüzünden bütünü kavrayamayan ve sadece kendi açısından bakabilen ekipler ortaya çıkar. Mümkünse bunları birbiri ile çalıştırarak kaynaştırın. Ve hatta eğer mümkünse birden fazla şapkayı giyebilecek kişilerden oluşan bir organizasyon oluşturun. Bir sonraki özellik benim çok değer verdiğim bir şey. İnsanlara yalnız kalabilecekleri ve rahatsız edilmeyecekleri alanlar tasarlayın. Mesela sabah ile öğlen arasındaki süre genellikle yaratıcılık ve konsantrasyon açısından çok önemlidir. Bu periyotta insanların birbirlerini rahatsız etmesine ve telefon, vs. gibi dikkat dağıtıcılara bulaşmasına engel olun. Bir diğer önemli husus da toplantılardır. Toplantılar zehirleyicidir, mümkünse yapmayın. Yaparsanız da gündemli ve sınırlı süreli olsun ve bunlara kesinlikle uyun. Gereksiz insanları toplantıya çağırmayın. Küçük başarıları dahi önemseyin ve kutlayın. Mesela sürüm çıkmıştır, hemen kutlayın.
Ekip kurma ve yönetmek ile ilgili 37Signals ‘in deneyimleri de şöyle: Ürün geliştirmenin başında az sayıda kişiyi işe alın. Eğer gerekiyorsa daha sonra alırsınız. Birisi işten ayrılırsa hemen yerine birini almayın, önce ekibin adaptasyonunu gözlemleyin. Çalışan adaylarıyla önce test amaçlı olarak çalışın, beğenirseniz sonra devam edebilirsiniz. Yeni elemanlarınızı open source dünyasındaki önceki işlerinden tanımaya çalışın. Özelleşmiş bilgi birikimine sahip olanlardansa genel bilgisi olup çabuk öğrenebilenlere yönelin. Averaj olup da coşkulu ve mutlu olanları, konusunda çok iyi ancak mutsuz olanlara tercih edin. Ayrıca yazma yeteneği iyi olanları işe alın çünkü iyi yazmak iyi iletişim yeteneği, düşünmenin, empatinin ve organize olmuş bir aklın belirtisidir.
Kullanıcı arayüzü tasarımı hakkında da ilginç gözlemleri var: İlk yapılması gereken şey kullanıcı arayüzüdür, göreceli olarak maliyeti düşüktür, kağıt üzerine çiziktirilmiş şekilde bile başlanabilir. Kod ise değiştirmesi en zor şey olduğundan, en son o kısmı geliştirin. Sayfanın merkezinden ve çekirdeğinden başlayıp dışa doğru tasarlayın. Üç durum için tasarım çözümünüz olsun: Normal işleyiş hali, data dolmamış iken kullanıcının karşılaşacağı boş ilk hali ve hata olması durumundaki hali. İlk çalıştığındaki deneyimi iyi yöneterek uygulamanız hakkında iyi bir algı oluşturabilirsiniz. Ayrıca işler ters gittiğinde kullanıcıyı madur etmeyecek defansif bir tasarım yaklaşımı kullanın. Tutarlı olmaya çalışmakta ısrar etmektense kontekste doğru oturacak şekilde akıllı bir tasarım kullanın. Kendinizi kullanıcının yerine koyun yazılan her cümle, kelime ve hatta her harfin önemli olduğunu daha iyi algılarsınız. Admin ekranları için ayrıca tasarım yapmayın, onları public ekranların içerisine koyun.
Kod açısından da 37Signals işte şunları söylemiş: Kodu mümkün olduğunca basit tutun. Kod miktarı arttıkça ürününüzün karmaşıklığı da eksponansiyel olarak artacaktır. Daha az koda ulaşabilmek de daha az özellik tasarlamak ve dolayısı ile daha az israf etmek demektir. Takımınızı heyecanlandıran araç ve teknolojileri kullanın. Kod size konuştuğu zaman dinleyin. Nerelere dikkat etmeniz gerektiği, nerelerde sıkıntı oluşabileceği gibi fikirleri kod size oluşmadan önce söyleyecektir. “Eğer programcılar kod eklemek için değil de çıkarmak için para alıyor olsaydı, o zaman yazılımlar çok daha iyi olacaktı” demiş MIT ‘den Profesör Nicholas Negroponte. Arasıra şişirme kod yazarak geçiştirdiğiniz noktalara geri dönün ve onlar sizden faiz almaya başlamadan önce ana parayı geri ödeyerek düzeltin. Dış dünyaya RSS, API ve benzeri bilgilendirme ve açıklık sunarak müşterilerinizi bilgilendirin veya sizin ürününüze katkıda bulunacak başka ürünler ve ekosistemler oluşturmalarına imkan tanıyın.
Yazılı spesifikasyon ve tanımlamalar hakkında da şunları söylemişler: Fonksiyonel spesifikasyonlar yazmayın. Bunların fonksiyonel olmaları mümkün değildir ve daha çok fantezilerdir; yatıştırma işlevi ve uzlaşma yanılsaması yaratırlar; sizi en önemli kararları en az bilgili olduğunuz zamanda vermeye zorlarlar; aşırı özellik yüklemesine sebep olurlar; evrimleşmeye, değişime ve tekrar değerlendirmelere izin vermezler. Fonksiyonel spesifikasyonlardan başka diğer aşırı kağıt kürek işlerini de engelleyin. Gerçek bir şeye dönüşmeyecek bütün dokümanları üretmeyi durdurun. Yazmayın, inşa edin. Bir şeyi açıklamak isterseniz mock edin (taklit edin) veya prototip oluşturun. Gerçek bir arayüz ya da prototype, ürün olmaya doğru gitme yolundadır, halbuki bir doküman çöp sepetine doğru meyillidir 🙂 Kendinizi yeni bir özelliği anlatacak kelimeler ararken bulursanız teknik ya da tasarım detaylarına girmeyin, sadece insani bir dille basit bir öykü anlatın. Detaylara takılmayın, stratejik düşünün taktik değil. Taktik detaylar o özelliği inşa ederken ortaya çıkacak ve konuşulacak. Lorem ipsum dolor tarzı standart kullanıcı arayüzü doldurma metinleri değil gerçek metinler ve datalar kullanın. Ekranları denerken alelade dfjsjlsdjs gibi şeylerle alanları doldurmak yerine anlamlı datalar tuşlayın ki kullanıcının gerçek deneyimini anlayabilesiniz. Ürününüzü bir insan gibi düşünün ve ona bir karakter atfedin. Bundan sonra da bu karakter ile tutarlı olun.
Kitapta ayrıca ürünün promosyonu, destek stratejisi, piyasaya sürüm sonrası yaşamı gibi konulardan da bahsediyor ancak bu konular için kitaba başvurmanızı öneririm. Yaşanmışlıktan süzülen bu kitabı dikkatle inceleyip kendi doğrularımızı ve fırsatlarımızı tespit etmekte kullanmalıyız.
Sabri Büyüksoy
Not: Kitabın orjinali http://gettingreal.37signals.com/ adresindedir.
Leave a Reply