Gerçek Uygulama Geliştirme Süreci: Fikirden Lansmana

On ajansa bir uygulamanın ne kadar sürede yapılacağını sorarsanız, on kendinden emin yanıt alırsınız ve hiçbiri doğru olmaz. Dürüst yanıt şudur: ilk gün kimse size tam olarak söyleyemez — ama gerçekten yazılım teslim etmiş herkes size işin şeklini anlatabilir: hangi aşamalar var, hangileri sessizce takvimi yiyor ve sizin kendi kararlarınız nerede işleri hızlandırıyor ya da tamamen durduruyor. İşte o şekil, açıkça yazıya dökülmüş hâli.

Birçok küçük işletme sahibinin bir uygulama projesine, eskizden App Store'a düzenli ve doğrusal bir yürüyüş bekleyerek girdiğini gördüm. Karşılaştıkları şey ise bir dizi durağanlık ve ani sıçrama gibi hissettiriyor. Hiçbir şey olmuyormuş gibi görünen haftalar, sonra her şeyin birden yerine oturduğu bir gün. Bunların hiçbiri bir şeyin yanlış gittiğinin işareti değildir. Yazılım böyle yapılır — ve aşamaları adlandırabildiğinizde, tüm süreç para döküp en iyisini umduğunuz bir kara kutu olmaktan çıkar.

Öyleyse gerçekçi beklentiler belirleyelim. Bir iş uygulamasının odaklı ilk sürümü için — devasa bir platform değil, tek bir işi iyi yapan bir ilk sürüm — genellikle ciddi bir başlangıçtan gerçek bir lansmana üç ila beş ay aralığında bir süreden bahsediyoruz. Bu aralığın neresinde olacağınızın teknolojiyle ilgisi, ne kadar net olduğunuz, kararları ne kadar hızlı verdiğiniz ve lansmandan önce ne kadar çok şeyi sığdırmaya çalıştığınızla olduğundan daha azdır. Hadi adım adım gidelim.

Size verilen tahminin neden büyük olasılıkla yanlış olduğu

Altı haftalık rakam tam olarak bir yalan değildir — herkesin gözünde canlandırabildiği kısmı yapmak için gereken süredir. Ekranlar. Düğmeler. Demosunu yapabileceğiniz şey. Bu rakamın sessizce göz ardı ettiği şey, görünür uygulamanın çevresindeki her şeydir: kararlar, veriler, zaten kullandığınız araçlarla entegrasyonlar, test, uygulama mağazası incelemesi ve kaçınılmaz “aslında, şunu da yapabilir mi?” turu.

Bunu düşünmenin yararlı bir yolu: kodlama nadiren darboğazdır. Darboğaz netliktir. Geliştiricinizin bir kararı beklediği her saat — hangi ödeme sağlayıcısı, bir rezervasyon iptal edildiğinde ne olur, kim neyi görebilir — zaman çizelgesinin kaydığı bir saattir. Hızlı biten projeler en iyi mühendislere sahip olanlar değildir. Sahibinin soruları iki hafta yerine bir günde yanıtladığı projelerdir.

Bu yüzden aşağıdaki aşamaları okurken, topun sizin sahanızda olduğu anlara dikkat edin. Bunlar bir projenin ya ivmesini koruduğu ya da bir e-posta yanıtsız kaldığı için üç hafta sessizce durduğu noktalardır. Zaman çizelgesi ortak bir sorumluluktur ve işin müşteriye düşen yarısı, insanların hafife aldığı yarıdır.

Aşama 1: Keşif ve kapsam belirleme (1–3 hafta)

Henüz tek bir ekran tasarlanmadan önce, ilerleme gibi görünmeyen ama her şeyi belirleyen bir aşama vardır: gerçekte ne inşa ettiğinizi ve daha da önemlisi neyi inşa etmediğinizi ortaya koymak. Burası belirsiz bir fikrin (“müşterilerim için bir uygulama”) ilk sürüm için somut ve bitirilebilir bir özellik listesine dönüştüğü yerdir.

İyi yapıldığında keşif çoğunlukla konuşma ve zor sorulardan oluşur. Bunu kim, hangi cihazda kullanıyor? Mükemmel yapması gereken o tek şey nedir? Neler ikinci sürüme kalabilir? İyi bir iş ortağı burada itiraz edecektir ve bunu istemelisiniz — şimdi çıkardığınız her özellik, geri kazandığınız haftalardır. Çıktı genellikle kısa bir yazılı kapsam ve kaba bir tel çerçevedir; elinize alıp evet, işte bu diyebileceğiniz bir şey.

Aşama 2: Tasarım ve prototip (2–4 hafta)

Şimdi uygulama, gerçek bir kod satırı sizi herhangi bir şeye bağlamadan önce görebileceğiniz ve tıklayabileceğiniz bir şeye dönüşür. Tasarımcılar tel çerçeveyi gerçek ekranlara dönüştürür — renkler, akış, kullanmanın gerçek hissi — genellikle kendi telefonunuzda dokunarak gezebileceğiniz etkileşimli bir prototip olarak.

Bu aşama tek bir nedenden ötürü altın değerindedir: bir tasarımı değiştirmek ucuzdur, inşa edilmiş yazılımı değiştirmek pahalıdır. Bir prototipte bir düğmeyi taşımak beş dakika sürer. Özellik kodlanıp test edilip verilerinize bağlandıktan sonra taşımak bir gün sürebilir. Yani bu, seçici olmanın, birkaç gerçek müşteriye ya da çalışana göstermenin ve “ah, bunu kimse anlamaz” sorunlarını henüz acısızca düzeltilebilirken yakalamanın anıdır.

Bu aşamanın uzamasının en yaygın yolu tasarımcı değildir — sizin tarafınızdaki kararsızlıktır. Bitmek bilmeyen küçük ayar turları ya da asla anlaşamayan, veto yetkisine sahip üç kişi. Onayı kimin vereceğine erken karar verin, geri bildirimi damla damla değil toplu olarak verin, böylece bu aşama kısa kalır.

Aşama 3: İnşa (6–12 hafta)

Bu, “bir uygulama yapmak” deyince herkesin gözünde canlandırdığı kısımdır ve tek bir süreçte en uzun olanıdır — ama ilk iki aşama düzgün yapıldıysa nadiren en öngörülemez olanıdır. Geliştiriciler uygulamayı parçalar hâlinde, genellikle üç ay ortadan kaybolup bitmiş bir ürünle yeniden belirmek yerine her bir iki haftada bir çalışan parçalar gördüğünüz kısa döngülerde inşa eder.

Bu ritim önemlidir. Bir durum raporuna değil, gerçek ve çalışan yazılıma erkenden tepki vermek istersiniz. Dördüncü haftada rezervasyon akışını gerçekten kullanabildiğinizde, hiçbir spesifikasyonun yakalayamayacağı şeyleri fark edersiniz — ve bunları dördüncü haftada düzeltmek, onuncu haftada düzeltmekten çok daha ucuzdur. İyi bir inşa süreci, uygulamayı yalnızca sonda değil sürekli olarak görünür kılar.

İnşayı sessizce uzatan şeyler

İki şey bir inşayı her şeyden çok genişletir. Birincisi entegrasyonlardır — uygulamanın konuşması gereken her dış sistem (ödeme sağlayıcınız, mevcut rezervasyon aracınız, muhasebe yazılımınız, bir teslimat hizmeti) iş ekler ve her biri kendi sürprizlerini çıkarabilir. İkincisi kapsam kaymasıdır: her biri minik gibi hissettiren ama topluca lansmanı bir ay öteleyen küçük eklemelerin istikrarlı damlaması. İkisi de yönetilebilir, ama yalnızca geldiklerini görürseniz.

• Her dış entegrasyon günler, bazen haftalar ekler — bunları açıkça bütçeleyin, bedava olduklarını varsaymayın.
• “Sadece bir küçük özellik daha”, kaçırılan lansman tarihinin en yaygın tek nedenidir.
• Gerçek veriler test verilerinden daha karmaşıktır; elektronik tablonuzun sessizce hoş gördüğü uç durumlarla başa çıkmak için zaman planlayın.
• Kullanıcı hesapları, ödemeler ve bildirimler aldatıcı şekilde derindir — her zaman göründüklerinden daha pahalıya mal olurlar.
• Ekibe borçlu olduğunuz onaylar ve içerikler (logolar, metinler, hukuki metinler) bir inşayı en az bir hata kadar kesin durdurabilir.

Aşama 4: Test ve düzeltme (2–4 hafta)

İşte insanların var olduğunu unuttuğu, sonra ortaya çıkınca rahatsız olduğu bir aşama. Uygulama inşa edildiğinde, sınanması gerekir — farklı telefonlarda, kötü internetle, onu inşa etmemiş ve kimsenin öngöremeyeceği şeyler yapacak kişilerce. Test bir formalite değildir. Müşterilerinizin güvendiği bir uygulama ile ilk çökmeden sonra sildikleri bir uygulama arasındaki farktır.

Burada bir hata ve pürüz listesinin ortaya çıkmasını bekleyin. Bu, inşanın kötü gittiğinin işareti değildir; aşamanın bütün amacı budur. Bazıları hızlı düzeltmelerdir, bazıları yeniden gözden geçirilmesi gereken bir kararı açığa çıkarır. Bunu iyi yöneten ekipler, işin normal ve planlı bir parçası olarak ele alır — bir acil durum değil ve lansman yaklaşıyor diye atlanacak bir şey değil. Testi atlamak zaman kazandırmaz. Sadece hataları test telefonunuzdan, düzeltmenin on kat pahalıya mal olduğu müşterilerinizin telefonlarına taşır.

Aşama 5: Lansman ve uygulama mağazası beklemesi (1–2 hafta, artı inceleme)

Lansman tek bir andan çok, dikkatli bir devreye almadır. Bir web uygulamasıysa zamanlamayı tamamen siz kontrol edersiniz — hazır olduğunuzda düğmeye basarsınız. Apple'ın App Store'una ya da Google Play'e gidiyorsa, takvimin bir kısmını onlara devredersiniz: inceleme süreçleri bir günden bir haftadan fazlasına kadar uzayabilir ve ara sıra düzeltilecek bir şeyle geri gönderirler. Bunu müşterilere söz verdiğiniz bir lansman tarihini baskına uğratmaması için önceden bilmekte fayda var.

Akıllıca lansman, tüm müşteri kitlenize büyük bir tantanayla açılış değildir. Önce küçük bir gruba sessiz bir sürümdür — bir avuç dost müşteri ya da kendi çalışanlarınız — böylece gerçek dünya sorunlarını herkes görmeden yakalarsınız. Sonra kapıyı genişletirsiniz. Sıkıcı derecede olaysız hissettiren bir lansman, iyi giden bir lansmandır.

1. 1
   Küçük bir gruba yumuşak lansman yapın

   Önce bir avuç dost kullanıcıya ya da çalışana sürün. Gerçek kullanım, riskler en aza indirilmişken testin kaçırdığını bulur.
2. 2
   Uygulama mağazalarına gidecekseniz erken gönderin

   İnceleme saatini Apple ve Google kontrol eder, siz değil. Yavaş bir inceleme ya da bir ret, söz verdiğiniz tarihi sarsmasın diye bir tampon bırakarak gönderin.
3. 3
   İlk haftayı yakından izleyin

   Hızlı tepki vermek için birini hazır tutun. İlk hafta, hiçbir test ortamının asla bulamadığı gerçek dünya uç durumlarını açığa çıkarır.
4. 4
   Lansmandan önce ertesi gün işini planlayın

   Bir uygulama lansmanda asla 'bitmiş' değildir. Kaçınılmaz küçük düzeltmelerle ve ilk geri bildirim turuyla kimin ilgileneceğini önceden kararlaştırın.

Tüm zaman çizelgesini bir araya getirmek

Uçtan uca üst üste konduğunda, bu aşamalar size gerçekçi bir resim verir. Hiçbiri egzotik değildir; insanları tökezleten şey, gösterişsiz olanların — keşif, test, uygulama mağazası beklemesi — yuvarlama hatası değil, takvimde gerçek zaman olduğunu unutmaktır. İşte odaklı bir ilk sürümün aylara kabaca nasıl dağıldığı.

Toplayın ve gerçek bir ilk sürüm için neden üç ila beş ayın dürüst aralık olduğunu, altı hafta vadedenlerin ise neden “bir uygulama” kavramını sessizce yeniden tanımladığını görürsünüz. Bu karamsarlık değildir — gerçekten tutturacağınız bir tarihle, proje boyunca özür dileyeceğiniz bir tarih arasındaki farktır.

Süreci gerçekten nasıl hızlandırırsınız (ve nasıl hızlandırmazsınız)

Daha hızlı ilerleyebilirsiniz ama gerçek kaldıraçlar insanların başvurduğu kaldıraçlar değildir. Yarı tanımlanmış bir projeye daha çok geliştirici atmak genellikle onu hızlandırmaz, yavaşlatır. Dürüst hızlandırıcılar gösterişsizdir: neyi dışarıda bırakacağınıza karar verin, soruları hızlı yanıtlayın ve inşa ortasında bir şeyler ekleme dürtüsüne direnin.

Bunların en büyüğü acımasız kapsamdır. İlk sürümünüz ne kadar küçük ve net olursa o kadar erken lansman yapar — ve hak ettiğini kazanan, yayınlanmış bir uygulama size iki haftada, iki ay daha planlamanın asla öğretemeyeceğinden fazlasını öğretir. Her zaman ekleyebilirsiniz. Kimsenin istemediği ortaya çıkan özellikleri inşa ederek geçirdiğiniz ayları geri alamazsınız.

Yüksek sesle söylemeye değer ilgili bir gerçek var: her şeyin özel bir uygulama olması gerekmez. Bazen gerçek sorun, bir parça otomasyonun hiçbir uygulamaya gerek olmadan sessizce halledebileceği bir dizi elle yapılan iştir. İyi bir iş ortağı, size daha büyük inşayı satmak yerine durumun böyle olduğunu söyleyecektir — çünkü en ucuz uygulama, yapmanız gerekmeyen uygulamadır.

Sık sorulan sorular