Web Uygulaması Bakımı Neden Daha Fazla Şey Olmalıdır?

Geleneksel yazılım geliştiricileri, açık bir şekilde bizden bir sır saklıyorlar. Tartışmalı bir gerçek bile değil. Bu onların iş modelinin bir parçası.

İster işlerimizde ister ücretsiz bir sistem günlüğü yöneticisi gibi işlerimizde her gün kullandığımız araçları yazan üst düzey kurumsal yazılım satıcılarından veya daha küçük yazılım evlerinden bahsediyor olmamız önemli değil. Tam orada ön ve orta. Saklamadıkları ve ödemeye alıştığımız ek maliyetler.

Peki nedir bu sır?

Pek çok geleneksel yazılım satıcısı , yazdıkları yazılımın bakımını yaparak ilk satıştan daha fazla para kazanıyor .

ikna olmadınız mı?

"Toplam Sahip Olma Maliyeti" terimi üzerinde hızlı bir arama, size Gartner'dan alınan buna benzer birçok benzer tanım sağlayacaktır (benimki vurgulanmıştır):

[TCO,] bir uygulamayı uygulama, çalıştırma, destekleme ve sürdürme veya genişletme ve kullanımdan kaldırma maliyetidir .

Ayrıca, Stanford Üniversitesi tarafından hazırlanan bu makale, bakımın normal olarak bir yazılım ürününün toplam sahip olma maliyetinin %60 ila %90'ına denk geldiğini ileri sürmektedir.

Bunun bir dakika için batmasına izin vermeye değer . Devam eden destek ve bakım planlarını satarak ilk satın alma fiyatının üzerinde para kazanıyorlar.

Bakımı Zorlamıyoruz

Gördüğüm kadarıyla sorun, web geliştirme endüstrisinde web uygulaması bakımının odaklandığımız bir şey olmaması. Aylık bir hizmetli fikrini sevdiğimiz için bunu tekliflerimize koyabiliriz, ancak bunlar muhtemelen basit temizlik görevlerini veya yeni özellik isteklerini kapsayacaktır.

Daha sonraki yinelemeler için tekliflerimizde temel yükseltmeleri ve optimizasyonları gizlemek duyulmamış bir şey değil çünkü müşterinin önemli iyileştirmeler olarak gördüğümüz şeyler için ödeme yapmak isteyeceğinden emin değiliz. Onları arka kapıdan içeri sokmaya çalışıyoruz. Veya başka bir deyişle, tıpkı daha geleneksel yazılımlar gibi bu uygulamaların da bakıma ihtiyacı olduğu konusunda açık ve şeffaf değiliz.

Sebep ne olursa olsun, gelecek için sorunları biriktirdiğimiz netleşiyor. İnşa ettiğimiz yazılım uygulamaları uzun vadeli burada . Geleneksel yazılım satıcıları gibi düşünmemiz gerekiyor. Yazılımımız bundan 10 veya 15 yıl sonra da çalışmaya devam edecek ve iyi durumda tutulmalıdır.

Peki, bunu nasıl değiştirebiliriz? Bir endüstri olarak, her şeyin güvenli ve güncel kalması için müşterilerimizin korunmasını nasıl sağlarız? Aynı şekilde, bakım pastasından nasıl pay alacağız ?

Bakım Nedir?

2012 tarihli Etkili Uygulama Bakımı makalelerinde, Heather Smith ve James McKeen bakımı şu şekilde tanımlamaktadır (vurgu bana aittir):

Bir uygulamayı yeni bir sunucuya taşımak, farklı bir işletim sistemiyle arabirim oluşturmak, daha yeni bir sürüme yükseltmek, vergi tablosunu değiştirmek veya yeni düzenlemelere uymak - bunların tümü uygulama - bakım gerektirir. Sonuç olarak bakım, bir uygulamanın verimli ve/veya uygun maliyetli kalmasını sağlamak için bir uygulamayı yükseltmeye odaklanır . Odak grubu tarafından tercih edilen uygulama bakımının tanımı şudur: - hataları düzeltmek için bir uygulamada yapılan herhangi bir değişiklik; performansı artırmak için; veya uygulamayı değişen bir ortama veya değişen gereksinimlere uyarlamak için. Bu nedenle, mevcut bir uygulamaya (yani geliştirme) yeni işlevler eklemek, kesinlikle bakım olarak kabul edilmez .

Başka bir deyişle, bakım, bir yazılım uygulamasının güvenilir ve güvenli bir şekilde çalışmaya devam edebilmesi için yapılması gereken temel bir iştir.

Yeni özellikler eklemiyor. Günlük dosyalarını kontrol etmiyor veya yedeklemelerin çalıştığından emin olmuyor (bunlar temizlik görevleridir). İşlerin güncel olmasını, kullanıcılarının beklediği gibi çalışmasını ve ışıkların açık kalmasını sağlamak için kod ve temel platform üzerinde çalışıyor.

İşte birkaç örnek:

• Teknoloji ve Platform Değişiklikleri
  Üçüncü taraf kitaplıklarının güncellenmesi gerekiyor. Temel dil bir güncelleme gerektirir, örneğin PHP 5.6'dan PHP 7.1'e Modern işletim sistemleri düzenli olarak güncellemeler gönderir. Bunun üstesinden gelmek bakımdır ve bazı şeyleri yapmanın eski yolları kullanımdan kaldırıldığı için zaman zaman kod tabanında da değişiklikler yapılması gerekebilir.

• ölçekleme
  Uygulama büyüdükçe, kaynak sorunları olacaktır. Günde 10.000 işlemle iyi çalışan kod içindeki rutinler, saatte 10.000 işlemle mücadele eder. Uygulamanın izlenmesi gerekir, ancak uyarılar tetiklendiğinde önlem alınması da gerekir.

• Hata düzeltme
  Açık ama açıklığa kavuşturmaya değer. Yazılımda hatalar var ve bunların düzeltilmesi gerekiyor. Bir projeyi gönderdikten sonra küçük bir dönem ücretsiz hata düzeltmeleri ekleseniz bile, bir noktada müşterinin bunlar için ödeme yapmaya başlaması gerekecektir.

Satmak Zor mu?

İlginç bir şekilde, bunu yaşıtlarımla tartıştığımda, müşterileri bakıma ihtiyaçları olduğuna ikna etmenin zor olduğunu düşünüyorlar. Müşterilerinin bütçelerinin olmamasından endişe duyuyorlar ve çok pahalı görünmek istemiyorlar.

Şey, işte olay: aslında oldukça kolay bir satış. İş insanlarıyla uğraşıyoruz ve onlarla sadece ticari anlamda bakım hakkında konuşmamız gerekiyor. İş adamları, varlıkların bakım gerektirdiğini, yoksa yükümlülük haline geleceğini anlarlar. Bu sadece başka bir standart devam eden aylık ek yük. İş yapmanın maliyeti. Sadece bunu tekliflerimize koymamız ve bunu takip ettiğimizden emin olmamız gerekiyor .

Son derece etkili bir yöntem, özünde bakımı içeren ama aynı zamanda müşteri için aşağıdakiler gibi pek çok ekstra değeri bir araya getiren bir hizmet sağlayıcı sunmaktır:

• İlerleme ve KPI'lar (ör. trafik, dönüşümler, arama hacimleri) hakkında raporlama
• Sitede küçük değişiklikler için her ay sınırlı 'boş' zaman
• Kesinti süresi, sunucu güncellemeleri veya tamamlanan geliştirme çalışmaları hakkında raporlama
• Soruları yanıtlamak için size veya ekibinizin belirli üyelerine telefonla erişim

Gerçekten de, hizmetlinin müşteriye para kazandırmasını ve kendisi için ödeme yapmasını sağlayabilirsiniz. Buna iyi bir örnek, bir müşterinin çevrimdışı işleme için her ay basit bir rapor alma veya veritabanından dışa aktarma gereksinimi olabilir.

Muhtemelen başlangıçta varsayıldığından daha karmaşık olan bir raporlama kullanıcı arayüzü oluşturmak için birkaç geliştirme günü için teklif verebilir veya alternatif olarak müşteriyi hizmet sağlayıcınıza yönlendirebilirsiniz. Bir geliştiricinin aynı verileri manuel olarak sağlamak için önceden ayarlanmış bir SQL sorgusunu manuel olarak çalıştırması için her ay buna bir görev ekleyin.

Sizin veya ekibiniz için önemsiz bir görev; müşteriniz için çok fazla değer.

Pratik Bir Örnek

Elbette, kendi önerilerinizi yazma yönteminiz olacak, ancak burada örnek konuşmadan birkaç küçük parça var.

Gelecek için vizyonunuzu çizebileceğiniz teklifinizin bölümünde bakım hakkında bir şeyler ekleyebilirsiniz. Bunu, uzun vadeli bir ilişki kurma konusunda tohum ekmek için bir fırsat olarak kullanın.

Uzun vadeli riski en aza indirmeye çalışıyorsunuz.

Uygulamanızın iyi performans gösterdiğinden, güvenli kaldığından ve üzerinde çalışmanın kolay olduğundan emin olmak istiyorsunuz.

Ayrıca, herhangi bir işletme varlığı için bakımın ne kadar önemli olduğunu da anlıyorsunuz.

Daha sonra, çıktılar bölümünde, tek başına bir seçenek olarak veya devam eden bir hizmetli ile birlikte paketlenmiş olarak bakımla ilgili bir bölüm ekleyebilirsiniz.

Aşağıdaki örnekte, bunu basit tutuyor ve ön ödemeli bir geliştirme hizmetlisi ile bir araya getiriyoruz:

Tüm müşterilerin, bakımı web siteleri için önemli bir ek yük olarak görmelerini şiddetle savunuyoruz. Modern web uygulamaları bakım gerektirir ve tıpkı eviniz veya arabanız gibi; Daha sonra yükümlülük haline gelmelerine ilişkin somut riski azaltmak için varlığınızın bakımını üstlenirsiniz.

Uygulamanın bakımının yanı sıra yeni özelliklerin eklenmesi konusunda makul bir şekilde istekli olan bir müşteri olarak, genel bakım ve geliştirme hizmeti için ayda N gün (başlangıç ​​noktası olarak) öneriyoruz.

Bir geliştiricinin sisteminizde en az [haftada/ayda bir süre] çalışması için her şeyi yayardık, size [aynı dönemde] sorunlar ortaya çıkarsa bir geliştiricinin daha önemli bir şeye geçebilmesi gibi belirgin bir avantaj sağlar . Önceliklerinize bağlı olarak, zamanın tamamı yeni özellik çalışmasına veya bakıma bölünebilir, bu sizin kararınız. Normalde yeni özellikler ve önemli bakım arasında %75/%25 oranında bir ayrım yapmanızı öneririz.

Daha önce de belirtildiği gibi, bu aynı zamanda performans raporlaması, yedeklemeleri kontrol etme gibi temizlik görevlerini yerine getirme ve belki de ilerleme ve öncelikleri tartışmak için aylık bir çağrı gibi diğer katma değerli devam eden hizmetler ile bakımı bir araya getirmek için harika bir fırsattır.

Muhtemelen bulacağınız şey, işi indirdikten sonra hizmetliden tekrar bahsedilmeyeceğidir. Bir projenin başlangıcında sizin ve müşterinizin düşünmesi gereken çok şey olduğu için bu anlaşılabilir bir durumdur, ancak proje sona eriyor olduğundan, projeden ayrılma sürecinizin bir parçası olarak onu yeniden tanıtmak için harika bir zaman.

Bu ister 2. aşamadan bahsediyor olsun, ister sadece nihai faturaların sunulması ve teslim edilmesi olsun, onlara bakımı hatırlatın. Onlara sürekli eğitim, raporlama ve destek için hazır olduklarını hatırlatın . Aynı ticari terimlerle konuşmayı hatırlayarak bir hizmetli için baskı yapın: yeni varlıklarının parlak kalması için sürdürülmesi gerekiyor .

Bakım Can Sıkıcı Olabilir mi?

Yaygın bir yanlış anlama, bakım görevlilerinin ek bir yük olabileceğidir. Buradaki endişe, müşterilerin sizi sürekli arayacak ve hizmetlinizin bir parçası olarak küçük ince ayarlar isteyecek olmasıdır. Bu, daha küçük ekipler veya yalnız danışmanlar için özel bir endişe kaynağıdır.

Yine de durum genellikle böyle değildir. Belki başlangıçta, müşteri üzerinde çalışılması gereken engellerin bir listesine sahip olacaktır, ancak bu kurs için eşittir; eğer deneyimliysen, o zaman bunu bekliyorsun. Bunlar, iletişim kanallarını geliştirerek (bir sorun izleyici kullanın) ve tüm istekleri bir araya toplayarak, yani tek bir vuruşta üzerinde çalışarak kolayca yönetilebilir .

Uygulama olgunlaştıkça, geçiş moduna geçeceksiniz. Bu, hizmetlinin her iki taraf için de özellikle değerli hale geldiği yerdir. Açıkça, hizmetliyi nasıl yapılandırdığınıza bağlı, ancak sizin bakış açınızdan, müşteriye her ay ne kadar değerli olduğunuzu hatırlatmaya çalışıyorsunuz. Onlara aylık raporunuzu gönderebilir, bu rutinde bir yavaşlamayı nasıl düzelttiğinizi ve sunucunun bu haftaki küresel işletim sistemi istismarı için yamalandığını söyleyebilirsiniz.

Elbette, ayrıca ücretli olan bir dizi yeni istenen özellik üzerinde çalışmaya da hazırdınız. Müşterinizin bakış açısından, orada olduğunuzu görürler, ilerlemeyi görürler ve “web sitesi hakkında endişelenmeyi” listelerinden çıkarırlar. Açıkçası, 'bu müşteriler' var, bu yüzden en önemli şey, hizmetli ifadenizi doğru kullanmak ve beklentileri buna göre yönetmek.

Müşteriniz düşük bir aylık ücret karşılığında ay'ı bekliyorsa, geri çekin veya yeniden pazarlık yapın. Aylık bir rapor ve diğer yardımcı görevler arasında ayda iki saat bakım ve temizlik yapmanız için size ödeme yapmak tam olarak budur; birçok geçici değişiklik yapmak için boş bir kontrol değildir. Onlara neyin dahil olduğunu ve neyin olmadığını hatırlatın.

Bakımı Nasıl Kolaylaştırıyoruz?

Son olarak, müşterileriniz için en iyi değeri sağlamak ve hayatınızı kolaylaştırmak için uygulamalarınızı oluştururken bu taktiklerden bazılarını kullanın.

Uzun Vadeli Destek (LTS)

• İyi belgelenmiş LTS sürümlerine ve yükseltme yollarına sahip teknoloji platformlarını kullanın.
• Devam eden işletim sistemi, dil, çerçeve ve CMS yükseltmeleri beklenmeli ve tüm projeler için hesaba katılmalıdır, bu nedenle bir LTS sürümünün izlenmesi zahmetsizdir.
• Her şey desteklenen bir sürümde çalışıyor olmalıdır. Durum böyle değilse, büyük alarm zilleri çalıyor olmalıdır.

İyi Proje Hijyeni

• Özellik biriktirme listenizde veya sorun izleme sisteminizde herkese açık olarak bakım görevleri yapın ve müşterinizle öncelikler üzerinde anlaşın. Bakım görevlerini saklamayın.
• Kod düzeyi ve işlevsel testler, özellikle sorunlu kodlara göz atmanızı sağlar ve modülleri yeniden düzenleme için çıkarırken yardımcı olur.
• Uygulamayı izleyin ve darboğazların ve hataların nerede olduğunu anlayın. Herhangi bir sorun, geliştirme biriktirme listesine eklenebilir ve buna göre önceliklendirilebilir.
• Destek taleplerini izleyin. Son kullanıcılar size bakım gereksinimlerini gösterebilecek faydalı geri bildirim sağlıyor mu?

Uygulama Taşınabilir Olmalı

• Herhangi bir geliştirici, sistemi yerel olarak kolayca kurup çalıştırabilmelidir - sadece siz değil! Uygulamaların geliştirme sürümlerinin üretimle aynı olduğundan emin olmak için sanal sunucuları veya kapsayıcıları kullanın.
• Başvuru iyi belgelenmelidir. En azından, sağlama ve devreye alma iş akışları ve canlı olarak devreye almak için gereken özel teşvikler yazılmalıdır.

Bakım Gerçek Bir Kazan-Kazandır

Bakım, güvenli bir şekilde durabilmesi için bir uygulamada yapmamız gereken iştir. Standart bir işletme maliyetidir. Bir yazılım uygulamasının ömrü boyunca toplam sahip olma maliyetinin ortalama %75'i.

Profesyoneller olarak, en başından itibaren müşterilerimizi bakım konusunda eğitmekle yükümlüyüz. Müşterilerinize somut değer sağlarken ek gelir için burada büyük bir fırsat var. Devam eden bir ticari ilişkiyi sürdürürsünüz ve yeni gereksinimleri olduğunda başvuracakları ilk kişi siz olursunuz.

Hizmet sağlayıcınız aracılığıyla değer sağlamaya devam etmek, müşteri ile güven oluşturacaktır. Geliştirmeler veya yeni özellikler önermek için bir platform elde edeceksiniz. Kazanma şansınızın yüksek olduğu çalışın. Müşteriniz ömür boyu maliyetlerini düşürür, risklerini azaltır ve performans veya güvenlik konusunda endişelenmeyi bırakır.

Kendinize, müşterinize ve tüm sektörümüze bir iyilik yapın: web uygulaması bakımının daha önemli hale gelmesine yardımcı olun.