KOBİ'lerin Sürekli Yaptığı 8 Pahalı Uygulama Geliştirme Hatası

Yolundan çıkan uygulama projeleriyle ilgili rahatsız edici bir gerçek var: kod yanlış görünmeye başladığında proje aslında haftalar önce çoktan kaybedilmiştir. Küçük işletme uygulama geliştirmesindeki pahalı hatalar neredeyse hiçbir zaman klavye başında olmaz. Gündelik sohbetlerde olur — hiç yazılmamış brief, birinin 'hazır başlamışken' eklediği özellik, bir arkadaş tavsiye ettiği için seçilen geliştirici. O an hiçbiri karar gibi hissettirmez. Hepsi sonradan size pahalıya patlar.

Pek çok küçük işletmenin ilk uygulamasını sipariş edişini izledim ve iş işten geçtikten sonra epeyce projeyi kurtarmaya çağrıldım. Sahipleri nadiren dikkatsiz insanlardır. Zekidirler, dikkatlidirler, iş yönetmekte iyidirler. Ama yazılımın, çalışma hayatlarının başka hiçbir yerinde olmayan kendine has tuzakları vardır ve kimse onları uyarmamıştır. Böylece her seferinde aynı sekiz tuzağa, aşağı yukarı aynı sırayla doğruca düşerler.

Bu, keşke her işletme sahibi tek kuruş harcamadan önce elinde olsaydı dediğim listedir. Teori değil — gerçek, tekrarlanan hatalar ve her projeyi kurtaracak küçük rota düzeltmeleri. Bir uygulama yaptırmak üzereyseniz ya da yapımın ortasındaysanız ve bir şeyler ters geliyorsa, önce bunu okuyun. Erken yakalarsanız bunların çoğu hâlâ düzeltilebilir.

Hata 1: Birinin istediğini kanıtlamadan inşa etmek

En pahalı hata aynı zamanda en yaygın olanıdır: uygulamanın insanların para ödeyeceği ya da kullanacağı bir sorunu çözdüğüne dair gerçek bir kanıt olmadan tam çapta bir yapıma söz vermek. Fikir sahibine bariz gelir — elbette müşteriler bunu isteyecek — ve işte tam da o kesinlik tehlikelidir. Kesinlik, doğrulama gibi hissettirir. Ama değildir.

Doğrulama, on arkadaşa fikri beğenip beğenmediğini sormak değildir; herkes kırmamak için evet der. Mümkün olan en küçük sürümü gerçek bir durumda gerçek kullanıcıların önüne koyup ne yaptıklarını izlemektir. Tıklanabilir bir prototip, kayıtları ölçen bir açılış sayfası, otomasyonu elinizle taklit ettiğiniz manuel bir 'konsiyerj' sürümü — bunların herhangi biri, bir önseziyle inşa edilmiş bitmiş bir uygulamadan daha çok şey söyler. Sıra önemlidir: talebi ucuza kanıtlayın, sonra pahalıya inşa edin. Bunu tersine çevirin, tüm bütçenizi kimsenin iki kez açmadığı bir şeyi cilalamaya harcayabilirsiniz.

Hata 2: Hırs kılığına girmiş kapsam kayması

Her uygulama yalın ve derli toplu başlar. Sonra 'hazır başlamışken'ler başlar. Rezervasyon ekranını yaparken hediye çeklerini de halletsek? Ya sadakat puanlarını? Ya bir tavsiye sistemini? Her ekleme kendi başına makul görünür. Hepsi bir arada takvimi ve faturayı sessizce üçe katlar — ve lansmanı öyle ileri iter ki başlangıçtaki ivme ölür.

Çözüm, iyi fikirlere hayır demek değildir. Onları beklemeye almaktır. Her parlak fikrin sırasını beklemeye gittiği görünür bir 'ikinci sürüm' listesi tutun. Bu, pratik olduğu kadar psikolojik bir şey de yapar: insanlar fikirleri için ileride gerçek bir yer olduğuna güvendiklerinde, özellikleri ilk sürüme tıkıştırmak için savaşmayı bırakırlar. İlk sürümünüz on şeyi vasat değil, tek bir şeyi gerçekten iyi yapmalı. Tek bir iş akışını mükemmel yapan uygulama kullanılır. Her şeyi yarım yamalak yapan uygulama terk edilir.

Hata 3: Yazılı brief yok — yalnızca paylaşılan zihinsel bir resim

Bu hata, ısırana kadar görünmezdir. Sahibinin kafasında net bir uygulama vardır. Geliştiricinin kafasında net bir uygulama vardır. Açılış toplantısında herkes başını sallar. Kimse doğru dürüst yazmaz — ve iki resmin aslında hiçbir zaman aynı resim olmadığı ortaya çıkar. Bunu yolun yarısında, inşa edilen şey hayal ettiğiniz şey olmadığında ve kimin ne dediğine dair bir tartışma çıktığında keşfedersiniz.

Yüz sayfalık bir şartnameye ihtiyacınız yok. Yeni gelen birinin okuyup anlayabileceği birkaç sayfaya ihtiyacınız var: bu uygulamayı kim kullanıyor, onunla yapması gereken üç dört şey ne, başarılı bir sonuç neye benziyor. Temel ekranların kaba bir eskizini ekleyin. Hepsi bu. Brief'in amacı bürokrasi değil — bellek ve gerçeklik birbirinden uzaklaşmaya başladığında, ki hep başlar, ikinizin de işaret edebileceği ortak bir referanstır.

Hata 4: Geliştiriciyi yanlış yöntemle seçmek

Çoğu sahip ilk geliştiricisini iki cılız sinyalden birine göre seçer: en düşük teklif ya da farklı bir sektörden birinin kişisel tavsiyesi. İkisi de şans eseri işe yarayabilir. Hiçbiri, işletmenizin geleceğinin birkaç ayını ve hatırı sayılır miktarda parayı emanet edeceğiniz birini seçmenin güvenilir bir yolu değildir.

En düşük teklif yazılımda özellikle aldatıcıdır, çünkü teklifle bitmiş maliyet arasındaki uçurum devasa ve görünmezdir. Üç tur yeniden çalışmaya ihtiyaç duyan, iki hafta ortadan kaybolan ve size başkasının bakım yapamayacağı bir kod bırakan ucuz bir geliştirici, işi ilk seferde doğru yapan biraz daha pahalı birinden çok daha pahalıya gelir. Fiyat gördüğünüzdür; toplam maliyet ödediğinizdir.

Aslında neyi kontrol etmeli

Yayına aldıkları ve hâlâ çalışan işleri görmek isteyin ve mümkünse o müşterilerle geliştirici odada yokken konuşun. Proje ortasındaki değişiklikleri nasıl ele aldıklarını sorun, çünkü değişiklikler olacak. İş bittiğinde kodun ve hesapların kime ait olacağını sorun — cevap her zaman siz olmalı. Ve size de iyi sorular sorup sormadıklarına dikkat edin. Yalnızca emir alan bir geliştirici, tam da yanlış şeyi çok verimli biçimde inşa eder. İyileri ise itiraz eder, düşüncenizdeki boşlukları gösterir ve brief'i sabit bir alışveriş listesi değil, bir sohbetin başlangıç noktası olarak görür.

Hata 5: Yapıma bütçe ayırıp gerisini unutmak

Bir uygulama, basılı bir broşür gibi tek seferlik bir alım değildir. Beslenmesi gereken canlı bir şeydir. Sahipler rutin olarak yapıma ve başka hiçbir şeye bütçe ayırır, sonra sonradan gelen maliyetler onları gafil avlar: barındırma, uygulama mağazası ücretleri, telefon işletim sistemi güncellemelerine ayak uydurmak için bakım ve gerçek insanlar kullanmaya başlayınca kaçınılmaz olan bir tur düzeltme ve küçük iyileştirme.

Mantıklı bir genel kural: yapım ne kadara mal olduysa, onun hatırı sayılır bir dilimini ilk yıl çalıştırması için yeniden ayırın. Kesin rakam değişir ama hata evrenseldir — lansman gününü, aslında başlangıç çizgisiyken bitiş çizgisi sanmak. Bakımına bütçe olmadığı için yayına alınıp sessizce terk edilen uygulama, bu alanın en hazin ve en yaygın sonlarından biridir ve önceden dürüst bir planlamayla tamamen önlenebilir.

Hata 6: Kullanıcınız yerine kendiniz için tasarlamak

İşinizi iyiden iyiye bilirsiniz, bu da uygulamanızın kullanımının kolay olup olmadığına karar verecek en kötü kişi yapar sizi. Size bariz gelen şeyler — jargon, işleri yapma sıranız, düşünmeden kullandığınız kısayollar — ilk kez kullanan biri için şaşırtıcıdır. Sahibine kusursuz mantıklı gelip diğer herkesi şaşırtan bir uygulama, ne kadar zekice olursa olsun başarısız olmuştur.

Çare ucuz ve biraz da gururu kıran cinstendir: lansmandan önce gerçek insanların onu kullanmasını izleyin. Nasıl çalışması gerektiğini zaten bilen ekibiniz değil — onu hiç görmemiş gerçek müşteriler ya da çalışanlar. Uygulamayı verin, bir görev verin ve hiçbir şey söylemeyin. Tereddüt ettikleri, yanlış yere dokundukları ya da iç geçirdikleri yerler, tasarım geri bildiriminizdir. En kötü sorunları ortaya çıkarmak için beş kişi yeter. Bu adımı atlamak, uygulamaların kimsenin bulamadığı bir 'gönder' düğmesiyle ve deneyenlerin yarısını yitiren bir kayıt akışıyla yayına çıkmasının nedenidir.

• Test eden kişiye bir tur değil, gerçek bir görev verin — 'önümüzdeki salıya bir randevu al' deyin, sonra susun.
• Sadece sonunda başarıp başarmadığına değil, ellerine ve yüzüne bakın.
• Her tereddüdü not edin; bir duraklama, içeriden göremeyeceğiniz bir tasarım sorunudur.
• Açıklama yapma dürtüsüne direnin — açıklamak zorundaysanız, açıklamayı uygulama yapmalıydı.
• Beş kişiyle test edin, bariz aksaklıkları düzeltin, sonra tekrar test edin.

Hata 7: Gerek yokken native iOS ve Android geliştirmek

İlk günden, büyük markaların yaptığı gibi hem iPhone hem Android için tamamen native, 'gerçek' bir uygulama yapma refleksi vardır. Çoğu küçük işletme için bu, kullanıcılarınızın asla fark etmeyeceği bir fayda uğruna iki ila üç kat maliyet ve karmaşıklık demektir. Daha kötüsü, artık sonsuza dek iki ayrı kod tabanının bakımını yapıyor, her gelecekteki düzeltmeyi ikiye katlıyorsunuz.

Çoğu zaman doğru ilk hamle native bir uygulama hiç değildir. Herhangi bir telefonun tarayıcısında çalışan iyi yapılmış bir web uygulaması ya da tek bir kod tabanından her iki mağaza sürümünü üreten platformlar arası bir yaklaşım, sizi pazara daha hızlı ve daha ucuza ulaştırır — ve gerçek kullanım değdiğini kanıtlarsa her zaman sonradan tamamen native'e geçebilirsiniz. Sorulacak soru asla soyut anlamda 'native mi web mi' değildir. Şudur: gerçek kullanıcıların temel işi yapmasını sağlayan en küçük, en ucuz şey nedir? Onu inşa edin, ondan öğrenin, sonra büyük parayı varsayımla değil kanıtla harcayın.

Hata 8: Lansmanı işin sonu sanmak

Sekizinci hata, uygulama yayına girdiğinde projenin bittiğine inanmaktır. Bitmemiştir — asıl proje işte o zaman başlar. Kullanıcıların eline ulaştırmak için planı, ne düşündüklerini duymak için yolu ve öğrendiklerinize göre iyileştirme niyeti olmayan bir uygulama, aylar içinde sönüp giden bir uygulamadır. Yapım kolay kısımdı. Benimsetme zor kısımdır ve neredeyse hiç kimse onu planlamaz.

Lansmandan önce üç şeyi bilin: insanlar uygulamanın varlığını nasıl öğrenecek, gerçekten kullanıp kullanmadıklarını nasıl ölçeceksiniz ve size söylediklerini nasıl toplayacaksınız ki bir sonraki tur tahminler değil gerçeklik tarafından yönlendirilsin. Bunların hiçbiri pahalı değil. Sadece farklı bir zihniyet — uygulama bitirip arkanızı dönüp gittiğiniz bir şey değil, sürdürdüğünüz bir ilişkidir. Bunu kavrayan sahipler, zamanla daha kullanışlı hale gelen uygulamalar elde eder. Kavramayanlar bir lansman günü sıçraması ve uzun, sessiz bir düşüş elde eder.

Sekizinden aynı anda nasıl uzak durulur

Birlikte okunduğunda bu hatalar tek bir kök paylaşır: kanıta dayanarak yavaş gitmek yerine varsayımlara dayanarak hızlı gitmek. Her biri, dikkatli adımı atlamanın daha ucuz hissettiği bir yerdir. Ve her biri, yapımdan sonra değil önce ele alındığında çok daha ucuzdur. İşte sekizinden de sessizce kaçınan sıra.

1. 1
   İnşa etmeden önce talebi kanıtlayın

   Bir prototip, bir açılış sayfası ya da manuel bir sürüm. Bütçeyi bağlamadan önce birinin bunu istediğine dair gerçek kanıt edinin.
2. 2
   Brief'i ve ikinci sürüm listesini yazın

   Herkesin anlayabileceği birkaç net sayfa, artı her 'hazır başlamışken' fikrinin v1'i raydan çıkarmaması için bir bekleme alanı.
3. 3
   Geliştiriciyi fiyata göre değil sicile göre seçin

   Yayına alınmış işler, referans görüşmeleri, kod ve hesapların net sahipliği ve size de iyi sorular soran biri.
4. 4
   Sadece yapıma değil, tüm ilk yıla bütçe ayırın

   Barındırma, bakım, düzeltmeler ve destek. Lansman günü başlangıç çizgisidir, o yüzden işin işletilmesini de fonlayın.
5. 5
   İşi yapan en küçük platformu seçin

   Çoğu durumda önce web ya da platformlar arası. Tamamen native'e sonra, kanıtla, yalnızca kullanım gerektiriyorsa geçin.
6. 6
   Gerçek kullanıcılarla test edin, sonra lansmanı planlayın

   Beş yabancının onu kullanmasını izleyin, bariz aksaklıkları düzeltin ve insanların onu nasıl bulacağına ve kullanımı nasıl ölçeceğinize önceden karar verin.

Sık sorulan sorular