Uygulama yayına çıktı, şimdi ne olacak? Bakım ve sonraki sürüm

Uygulama yayına çıkınca iş bitmez; iki ayrı iş başlar. Birincisi bakımdır: uygulamanın çalışmaya devam etmesini sağlar. İkincisi geliştirmedir: uygulamaya yeni bir şey ekler. Yazılım bakımı nedir diye soruyorsanız cevap şu: değişen dünyaya karşı, yaptığınız şeyi ayakta tutmak. Bu yazı ikisini ayırıyor ve teklif aşamasında neyi sormanız gerektiğini anlatıyor.

Kısa cevap: yayın bir başlangıçtır

Bir uygulamayı yayına almak, bir dükkânı açmaya benzer. Kapıyı açmak işin sonu değildir; raflar, ışıklar ve kasa hâlâ ilgi ister. Uygulamada da iki ayrı ihtiyaç doğar:

• Bakım: Uygulama bugün çalıştığı gibi yarın da çalışsın.
• Geliştirme: Uygulama kullanıcılardan öğrendiklerinize göre değişsin.

İkisini karıştırmak, bütçe ve beklenti tartışmalarının sık görülen nedenlerinden biridir. Bu yüzden ayrı düşünmek ve anlaşmaya ayrı yazmak yararlıdır.

Bakım neyi kapsar?

Uygulamanız kendi başına eskimez, ama çevresi değişir. Bakım bu değişime ayak uydurmaktır. Tipik kalemler:

• İşletim sistemi ve tarayıcı değişiklikleri: iOS, Android ve tarayıcılar yeni sürümler çıkarır. Uygulamanın bunlarla uyumlu kalması gerekir.
• Mağaza kuralı değişiklikleri: App Store inceleme yönergeleri ve Google Play geliştirici politikaları zaman içinde güncellenir. Uygulamanın yeni kurallara uyması gerekebilir.
• Güvenlik güncellemeleri: Kullanılan kütüphanelerde açık bulunabilir. OWASP'ın 2021 tarihli Top 10 listesi, güvenlik açığı bulunan ve eski bileşenlerin kullanılmasını web uygulamalarının bilinen risk kategorileri arasında sayar. Güncelleme çıkınca uygulamaya alınmalıdır.
• Kütüphane güncellemeleri: Eski sürümler desteklenmeyi bırakabilir.
• Yedek: Verilerin düzenli yedeklenmesi ve geri yüklenebildiğinin denenmesi.
• Hata düzeltme: Kullanımda ortaya çıkan, testte görünmemiş hataların giderilmesi.

Bu işlerin hiçbiri yeni özellik değildir. Kullanıcı bunları fark etmez; ama yapılmazsa bir gün uygulama çalışmaz.

Bakımı somutlaştırmak için kendi uygulamanız için şu tabloyu doldurun:

Boş kalan satır, teklif görüşmesinde sorulacak soru demektir.

Geliştirme: yeni özellik ayrı bir kapsamdır

"Şu butonu da ekleyelim" bir bakım işi değildir. Yeni özellik, kendi kapsamı olan yeni bir iştir. Yeniden bir ihtiyaç tanımı, tasarım, geliştirme ve test gerektirir.

Pratik kural: bir istek, mevcut uygulamanın çalışmasını korumaya yönelikse bakımdır. Uygulamaya yeni bir yetenek katıyorsa geliştirmedir. İkisi ayrı değerlendirilir, çünkü ölçüsü ve sorumluluğu farklıdır. Anlaşmada da ayrı yazın.

Birkaç örnek sınıflandırmaya yardım eder:

• Bakım: Yeni telefon sürümünde ekranın bozulması, bir kütüphanenin güvenlik güncellemesi, yedeğin geri yüklenememesi.
• Hata düzeltme: Sipariş formunun belirli bir durumda hata vermesi gibi, yazılımın söylenen şekilde çalışmaması.
• Geliştirme: Uygulamaya ödeme eklemek, yeni bir kullanıcı rolü tanımlamak, yeni bir rapor ekranı yapmak.

Sınırda kalan istekleri yazılı olarak sınıflandırın. "Bu bakım mı, yeni iş mi?" sorusu ilk anlaşmazlıkların sık görülen kaynaklarından biridir; cevabı önceden yazmak ikinize de kolaylık sağlar.

İlk kullanıcı geri bildirimini okumak

İlk sürümün asıl işi, bir soruya cevap vermekti. Yayından sonra gerçek kullanıcılar bu cevabı vermeye başlar. Geri bildirimi okurken üç şeye bakın:

1. Ne yapıyorlar? Hangi ekranı kullanıyor, nerede takılıyorlar?
2. Ne istiyorlar? Sık tekrarlanan istek, tek seferlik istekten daha değerlidir.
3. Neyi söylemiyorlar? Hiç kullanılmayan ekran da bir cevaptır.

Burada işe yarayacak bir araç var: ilk sürümde kestiğiniz özelliklerin "şimdilik yok" listesi. Her satırın yanında "ne zaman tekrar bakarız" yazıyordu. Şimdi bakma zamanı. Listeyi nasıl yazacağınız bir MVP'de neyi kesersiniz yazısında anlatılıyor. Kullanıcı bir özelliği defalarca istiyorsa listenin başına çıkar. Kimse sormuyorsa listede kalabilir.

Geri bildirimi düzenli okumak için basit bir yöntem yeter:

1. Tek bir yerde toplayın. Gelen mesajlar, yorumlar ve destek yazışmaları tek bir tabloda dursun.
2. Her satıra tür yazın. Hata mı, istek mi, soru mu? Hata ise bakım kuyruğuna, istek ise "şimdilik yok" listesine gider.
3. Aynı konuyu sayın. Beş farklı kişinin yazdığı aynı sorun, tek bir güçlü geri bildirimden önemlidir.
4. Sonraki sürüm için üç madde seçin. Hepsini birden yapmaya kalkmayın; ikinci sürümün de küçük ve kapsamlı olması gerekir.

İkinci sürümün kapsamını yazarken Kapsam Sihirbazı işinize yarar: aynı yedi adımla yeni kapsamı da çıkarabilirsiniz.

Bakımı anlaşmaya yazmak: neyi sormalı?

Bakımı konuşmak için teslimi beklemeyin; teklif aşamasında sorun. Şu soruların yazılı cevabı olsun:

• Bakım kapsama dahil mi, ayrı anlaşma mı? Çoğu zaman ayrı bir anlaşmadır. Önemli olan bunun baştan bilinmesidir.
• Neler bakım sayılıyor? Güvenlik güncellemesi, hata düzeltme ve yedek yazılı bir listede olmalı.
• Hata bildirimini nasıl yapacaksınız? Hangi kanaldan yazacaksınız, cevap nasıl gelecek?
• Yeni özellik nasıl istenir? Her istek ayrı bir kapsam ve teklifle mi ilerliyor?
• Hesaplar kimin adına? Sunucu, alan adı ve mağaza hesabı sizin adınıza olmalı.

Süre ve fiyat vaatlerine dikkat edin. "Hemen düzeltilir" gibi bir cümle, yazılı koşulu olmadan bir söz olarak kalır. Kapsamı net olan bir anlaşma, rakamı güzel olan bir anlaşmadan çoğu zaman daha işe yarar.

Teslimden sonra bir hata düzeltme dönemi tanımlanıp tanımlanmadığını da sorun. Bu dönem, teslim edilen işte çıkan ve söylenen şekilde çalışmayan yerlerin hangi koşulla düzeltileceğini belirler. Dönemin uzunluğu, neyi kapsadığı ve bittikten sonra ne olacağı yazılı olmalıdır. Dönem bittikten sonraki işler genellikle ayrı bakım anlaşmasına girer.

Teklifteki bakım maddesini okurken şu üç cümleyi arayın:

• Bakım kapsamının listesi ("güvenlik güncellemesi, hata düzeltme, yedek").
• Kapsam dışı işlerin nasıl teklif edileceği.
• Anlaşmayı bitirmek isterseniz belgelerin ve erişimlerin nasıl devredileceği.

Başka ekiple devam etmek isterseniz

İleride ekip değiştirmek isteyebilirsiniz; bu meşrudur. Yeni ekibin işe başlayabilmesi, ilk ekibin bıraktığı belgelere bağlıdır. Kurulum adımları, karar kayıtları, kullanılan bileşenlerin listesi ve erişimler ne kadar eksiksizse devir o kadar kolay olur.

Bunun için teslimde belge ve erişimlerin yazılı gelmesini isteyin. Sahiplik tarafı ayrı bir konudur; teklifte yazılı olduğundan emin olun. Çalışma düzenimizdeki yazılı devir mantığını nasıl çalışıyoruz sayfasında görebilirsiniz.

Bizde nasıl?

Pixenzo'da teslimden sonrası şöyle işler. Uygulama geliştirme sayfamızda şu yazıyor: "Belgeleri ve erişimleri size devrederiz. Bakım ve yeni özellikler için ayrıca anlaşabiliriz." Yani bakım ve yeni özellik, teslimden ayrı bir anlaşmadır.

MVP geliştirme sayfamızda ise şöyle: "İlk kullanıcı geri bildirimine birlikte bakar, sonraki sürümü planlarız." Mağaza başvurusu da sizin geliştirici hesabınızla yapılır. Her aşamanın sonunda ne yapıldığını ve neyin onay beklediğini yazılı paylaşırız; teslim ve yayın yalnızca kurucu Fatih Özpolat'ın onayıyla olur.

Ayrıntılar için uygulama geliştirme ve MVP geliştirme sayfalarına bakabilirsiniz. Bakım için süre ya da ücret sözü vermiyoruz; kapsam konuşulduktan sonra yazılı teklifle belirlenir.

Özet

• Yayın bir başlangıçtır: bakım ve geliştirme iki ayrı iş olarak başlar.
• Bakım; işletim sistemi ve mağaza kuralı değişikliklerini, güvenlik ve kütüphane güncellemelerini, yedeği ve hata düzeltmeyi kapsar.
• Yeni özellik ayrı bir kapsamdır; bakımla karıştırmayın.
• İlk kullanıcı geri bildirimini "şimdilik yok" listenizle birlikte okuyun.
• Bakımı teklif aşamasında sorun ve anlaşmaya yazdırın.
• Başka ekiple devam etmek istediğinizde belgeler ve erişimler belirleyici olur.

İlk sürümünüzden sonra ne yapacağınızı konuşmak isterseniz, sonraki sürümü birlikte planlamak için teklif alabilirsiniz.