Jibble’ın Hikayesi
Öne çıkan, üst düzey ve etki yaratacak bir zaman takip programı oluşturmak kolay değildir. Pek çok ekip bu saydıklarımdan bir ya da iki tanesini sağlayan bir yazılım oluşturabilir ancak nadiren bir ekibin bir araya gelip bu sayılanların üçünü birden sağlayan bir yazılıma imza attığını görürüz.
Jibble tam olarak bunun bir örneği.
Basit bir Google araması beni doğruluyor; şirketin yazılımı GetApp ve Capterra’da 4.8 ve Apple App Store’da 4.7 puana sahip, ki bunlar oldukça etkileyici. Şirketin geliştirebileceği pek çok yön olduğundan eminim ancak bu puanları aldığına göre ekip bir şeyleri doğru yapıyor demektir.
Ben de tam olarak ne yaptıklarını anlamak istiyordum, bu yüzden şirketin bu etkileyici sonuçlara nasıl ve neden ulaştığını incelemeye karar verdim.
Bir zaman takibi ya da zaman çizelgesi uygulaması üzerinde çalışmanın o kadar da cazip görünmediğinin farkındayım; yeni Örümcek Adam oyununu geliştiren Activision gibi bir oyun şirketinde çalışmakla kesinlikle aynı şey değil.
Bununla birlikte, Jibble kendisini “Zaman Takibinde Yeni Standart” olarak tanıtıyor. Bu oldukça cesur ancak gerçeklere dayandığını gördüğüm bir iddia. Bu, sıradan ama önemli bir şeyi ilginç hale getirmek için gösterilen yorucu çabaların bir sonucu.
Gördüğünüz gibi, büyük yeniliklerin gerçekleştirildiği düşünüldüğünde, çoğu yeni girişimin değiştireceği şey eski sektörlerdir. İşte bu nedenle Jibble’ın, genç kurucular ve deneyimli risk sermayedarları tarafından uzun süredir ihmal edilen bir pazarı ele geçirme konusunda eşsiz bir konumda olduğuna inanıyorum.
İlk bakışta Jibble, “Tamam, bir sorun buldunuz, hadi biraz kod yazalım, bir kullanıcı arayüzü oluşturalım, bir ödeme ağı ekleyelim ve bunu dünyaya sunalım” şeklinde ilerleyen sıradan bir konsept gibi görünebilir. En azından ekibe katılmadan önce benim anlayışım buydu. Ancak kısa sürede öğrendiğim üzere, zaman çizelgesi yazılımı gibi karmaşık ürünler geliştiren SaaS (Hizmet Olarak Yazılım) şirketleri farklı çalışıyor.
En iyi zaman takip programını oluştururken yürütülmesi gereken ÇOK sayıda süreç var ve Jibble bir Google olmasa da, işlerin geliştirme tarafını yöneten çok etkileyici bir ekibe sahip. Bunlar fark edilmeyen kahramanlar diyebiliriz.
Yazılım Mühendislerinin iyi iletişimciler olmadıklarını duymuş olabilirsiniz; evet, genellikle içe dönüktürler, kendi alanlarında ustalardır ve genelde insanlarla etkileşimden kaçınırlar. Bu klişe bir dereceye kadar doğrudur.
Çoğu mühendis, işlerinde iyi olabilmek için loş ekranlarının başında sürekli klavyelerini tıkırdatarak sayısız saatler geçirmek zorunda ve Jibble’daki ekibimiz de bundan farklı değil.
Şirketin işleyişinin her iki tarafında, müşteriye dönük tüketici rolünde ve geliştiriciye dönük ürün oluşturma rolünde bulunmuş biri olarak, kendimi burada işlerin neden yolunda gittiği ve bu girişimi takip etmenin neden zaman ayırmaya değer olduğu konusunda yorum yapabilecek yetkinlikte görüyorum.
Geliştirme Sürecimiz
Ekibimiz, zaman takibinde yeni standart için aşağıda bahsettiğim geliştirme süreçlerinin her bir noktasını daha iyi hale getirebilmek için sayısız saat harcıyor:
1. Fikir Aşaması: Olası Bir Sorun Noktasını Öngörmek
Ekibimiz, kodun ilk satırı yazılmadan önce, sonrasında olası eksiklikler ve sorunlarla çok daha fazla zaman kaybetmeme hususuna dikkat ederek oldukça dikkatli davranıyor. Abraham Lincoln’ün dediği gibi:
“Bir ağacı kesmem için bana altı saat verin, ilk dört saatimi baltamı bileyerek geçiririm.”
2. Dış Faktörlerin Araştırılması
Zaman takip programımızın etki alanı içinde bir sorun noktası belirlendikten sonra ekip, doğru bir karar vermek için gerekli verilerin hazırlanmasına yardımcı olacak ortak noktaları bulmak amacıyla mevcut müşteri geri bildirimlerini, öngörülen pazar eğilimlerini ve ilgili teknolojileri hızlı bir şekilde karşılaştırır.
3. İç Araştırma: Ekip ile Görüşmeler
Veriler toplandıktan sonra, Ürün Sahipleri, Ürün Müdürleri, Baş Teknoloji Yöneticileri (CTO), Baş Tasarımcılar ve tüm bölümlerden Ekip Liderleri dahil olmak üzere ilgili paydaşlar bir araya gelir.
Ekip, almak üzere olduğumuz kararın artıları ve eksileri, kaynaklara karşı zaman ve beklenen yatırım getirisi hakkında bir iç tartışma yaptıktan sonra, herkesten endişelerini dile getirmek için zaman ayırması ve ne gibi kararlar almamız gerektiği yönünde fikirlerini ifade etmeleri istenir.
4. Karar Verme: Şimdi ya da sonra? Bu, işi nasıl etkileyecek?
Görüşler neticesinde bir sonuca ulaşıldıktan sonra ekip, şirket vizyonu ve acil ya da beklenen hedefleriyle uyumlu olan kararı seçer. Eğer netice belirlenen kriterleri karşılamıyorsa, karar alınmaz.
Kararlar genellikle (ancak her zaman değil) mevcut özelliklerin iyileştirilmesi veya yepyeni özelliklerin geliştirilmesiyle ilgilidir. Bunlardan herhangi birine yeşil ışık yakıldıktan sonra, yol haritasında nereye yerleştirileceği meselesi ortaya çıkar; şimdi mi, gelecek ay mı, gelecek çeyrekte mi hayata geçireceğiz, ya da tamamen bekletecek miyiz?
Burada, kararımızın mevcut müşteriler, gelecekteki potansiyel müşteriler ve mevcut kapasite üzerinde nasıl bir etki yaratacağına bakar ve buna göre karar alırız.
5. Tasarım Araştırmaları
Özellik zaman çizelgesine karar verildikten sonra, bunun nasıl görüneceğine dair fikirler üretmemiz gerekir. Bu, pek çok yeni girişimcinin ve yazılım ürünü sahibinin eline yüzüne bulaştırdığı bir konudur. Tüm özelliklerin genel resimde birbirine uymasını sağlamakla ilgilenmeleri gerekirken nasıl çalışması gerektiğine çok fazla odaklanırlar.
6. Teknik Özelliklerin Belgelendirilmesi
Bir sonraki adım, Yazılım Geliştiricilerin baş belası olan şartname oluşturma sürecidir. Genel anlamda belgelendirme, geliştirilmekte olunan projenin kapsamını yazmayı tanımlar. Fikrin; geliştirme, test ve hata kontrolleri için somut bir belge olacak biçimde bir kağıda yazıldığı ve geliştirildiği süreci ifade eder.
Ortaya konan belge, ürünün tüm özelliklerini belirtir, nasıl çalışacağını açıklar ve nihai hedefi tanımlar (şu anda metriklerle pek ilgilenmiyoruz). Ayrıca geliştiricilerimiz tarafından yazılan teknik belgeler de var. Şu anda şartnameleri şu şekilde yazıyoruz:
- Proje Yöneticisinden gelen ilk taslak
- Ekip liderlerinin ilk teknik özellikleri gözden geçirmesi ve teknik fizibilite ya da alternatif önerilerle ilgili yorumlar
- Proje Yöneticisi tarafından yapılan düzenlemeler
- Gerekirse başka bir görüşme (projenin karmaşıklığına bağlı olarak 2-3. adımlar birkaç kez tekrarlanabilir)
Ekip, bu süre zarfında tüm ekstrem durumların da dikkate alındığından emin olur. Ancak tasarım kesinleşmişse, belgelendirme tartışmalarını sonuçlandırırız. O zamana kadar yineleme görüşmeleri ve düzenlemeleri yapılması mümkündür.
7. Ürün Tasarımı
Üst düzey tasarımcılarımız, çeşitli görüntüleme seçenekleriyle çeşitli örnek tasarımlar oluşturur. Bu tasarımlar, Jibble’ın renk paleti göz önünde buluşturularak oluşturulur.
Bu aşamada mobil, web kullanımı, tablet ve akla gelebilecek her türlü ekran boyutu göz önünde bulundurulur.
8. Arka Uç Uygulama ve Birim Testleri
Çoğu özellik Arka Uçtan başlar. İstemci tarafında kullanıcı arayüzü ile mantık eklemeden ve API’mize eklemeden önce arka ucumuzun özelliği desteklemesi gerekir. Bu nedenle, teknik özelliklere dayalı talepleri ve görevleri iyileştirmek amacıyla BE ekibiyle eğitim oturumları yapılır ve ardından Backend sprint planlaması sırasında taleplerin ataması yapılır.
BE ekibi, tüm işlevlerin beklendiği gibi çalıştığından emin olmak amacıyla yazdıkları kod için birim testleri geliştirmekten de sorumludur. Bu noktada özellik mimarisi oluşturulur. İyi bir özellik modeli, müşteriler için geliştirme sürecini kolaylaştıracaktır.
9. İstemci Uygulaması ve Birim Testleri
Artık BE’miz uygulandığına göre, mobil ve web geliştirme ekipleri kendi FR uygulamalarına başlayacaklar. Süreç BE ile hemen hemen aynıdır, ancak taleplerin rafine edilmesi esas olarak planlama çağrılarının dışında gerçekleştirilir.
Müşteriler kodlarını uygulamak için temel olarak teknik özelliklere, tasarımlara ve özelliğin BE model yapısına başvururlar. Mobilde, ortak bir mantık setini takip eden kullanıcı arayüzü için iki farklı ekibimiz var; bu, teslimatı optimize etmeye ve fazlalığı azaltmaya yardımcı oluyor. İlk testler geliştirme ekibi tarafından yürütülüyor ve ardından manuel kontroller için KG’ye aktarılıyor.
10. QA (Kalite Kontrol) Testleri
Özellikler geliştirildikçe, QA (Kalite Kontrol) ekibinin titiz testler yürüttüğü süreç başlar. Bu, zaman takip programını geliştirilen özelliklerinin beklentilere göre çalıştığından emin olmak için gerçekleştirilen bir süreçtir. Sorunlar tespit edilirse, revizyonlar ve iyileştirmeler için yeniden çalışmalar yapılır.
11. QA (Kalite Kontrol) Regresyon Testleri
Tüm özellikler amaçlandığı gibi çalışırsa, daha sonra bir kez daha test edildikleri üretime gönderilirler. Bunun amacı da mevcut düzeltmelerin daha önce çalışan herhangi bir şeyi bozmadığından emin olmaktır.
Regresyon Testi, yakın zamanda yapılan bir program veya kod değişikliğinin mevcut özellikleri olumsuz etkilemediğini doğrulamak için yapılan bir yazılım testi türü olarak tanımlanır.
Burada, Jibble’da iki tür Regresyon Testi gerçekleştiriyoruz: Birincisi, sorunları olan ve yeniden düzeltilmesi gereken Kabul Testi talepleri kapsamında yapılan gayri resmi veya küçük Regresyon Testidir. Diğeri ise, seçilen özelliklerin kritik yol programlaması odaklı daha fazla kapsama sahip, döngü olarak bilinen Sprint’in sonuna doğru gerçekleştirilen tam döngü yineleme Regresyon Testidir.
Şu anda bunu, Otomasyon komut dosyaları tamamen hazır olmadan önce manuel olarak uyguluyoruz.
12. Keşif Testleri
Ekibimiz, zaman çizelgesi yazılımı geliştirme konusunda oldukça becerikli olduğundan, yukarıdakilerin tümü iki haftalık döngüler halinde gerçekleştirilir. Bu döngülerin dışında veya iş yükünün nispeten düşük olduğu dönemlerde ekip, her şeyin takibinin gerçekleştirildiği ve düzeltilmesi gereken noktaların belirtildiği keşif testlerine odaklanıyor.
Ayrıca, talebin kendisinin genişletilmiş kapsamını sunan Kabul Testi taleplerini test ederken de keşif testleri gerçekleştiriyoruz.
13. Yazılımın Piyasaya Sürülmesi
Nihayet, tüm bu özverili çabalardan sonra, ürünümüz piyasaya çıkıyor. Bir zaman çizelgesi yazılımı yapmanın bu kadar uzun bir süreç olmasını beklemiyordunuz, değil mi?
Genel Düşünceler
Mükemmel bir ürün yaratmak için mükemmel bir vizyona sahip olmanız ve rüzgar değiştiğinde dahi yönünüzden sapmamanız gerekir. Jibble’ın zaman takip programı ekibi, trendlere çok hızlı teslim olmama gerekliliğinin farkında; sadece amaca yönelikler ve ürünü daha iyi hale getirme amacıyla sürekli iyileştirmeler yapıyorlar.
Aynı zamanda, “Zaman Takibinde Yeni Standart” tanımına uyması gereken vizyonlarına bağlı kalmak amacıyla stratejiler uyguluyorlar. Son dönemdeki başarılarında bunun büyük payı olduğunu düşünüyorum.
Jibble’ın zaman takibinde yeni standart başarısını örnek almayı amaçlayan ekipler için çıkarılacak netice şudur: Karar vermeden önce veri odaklı araştırma yaparak zaman geçiren hızlı, üst düzey ve amaca yönelik ekipler oluşturun ve saat gibi özellikler oluşturmak, test etmek, iyileştirmek ve göndermek için en iyi uygulamaları kullanan ve küresel iş birliğinden faydalanan parlak mühendisler istihdam edin. Ardından tek yapmanız gereken arkanıza yaslanmak ve sihrin gerçekleşmesini izlemek!