“Özel yazılım şirketleri” teknik borçlarla nasıl başa çıkıyor?

"Özel yazılım şirketleri" nedir?

"Özel yazılım şirketleri" ile, paralarını öncelikle özel, bir kerelik yazılım parçaları oluşturmaktan kazanan şirketler kastediyorum. Örnek olarak ajanslar veya orta eşya şirketleri veya Redify gibi yükleniciler / danışmanlar verilebilir .

"Özel yazılım şirketleri" nin tam tersi nedir?

Yukarıdaki iş modelinin tersi, konuşlandırılabilir masaüstü / mobil uygulamalar veya SaaS yazılımı olsun, uzun vadeli ürünlere odaklanan şirketlerdir.

Teknik borç oluşturmak için kesin bir ateş yolu:

Bir dizi SaaS ürününe odaklanmaya çalışan bir şirkette çalışıyorum. Bununla birlikte, bazı kısıtlamalar nedeniyle bazen belirli müşterilerin iradesine eğiliyoruz ve sadece bu istemci için kullanılabilecek özel yazılım parçaları oluşturuyoruz.

Bu, teknik borca ​​girmenin kesin bir yangın yoludur. Şimdi, temel ürünümüze hiçbir şey katmayacak bir yazılımımız var.

Özel işler teknik borç oluşturmanın kesin bir yangın yolu ise, ajanslar bunu nasıl ele alır?

Bu beni düşündürdü. İş modellerinin merkezi olarak temel bir ürünü olmayan şirketler, her zaman özel yazılım işi yapıyorlar. Teknik borç kavramıyla nasıl başa çıkıyorlar? Onları teknik iflasa nasıl itmez ?

Kullanıcıya özel gereksinimleri herkes için yararlı olacak bir şeye bükebiliyorsanız, harika. Müşteri, özellik için devam eden destek ücretlerini ödemeye hazırsa, bu da harika. Ancak küçük bir ekipseniz ve kendinizi tüm özelliklerinizi desteklemeye çalışırken bulursanız, bunun için en az ihtiyacınız olan özellikler hakkında bazı zor kararlar almaktan ve bunları kod tabanınızdan köklendirmek için biraz zaman ayırmaktan başka bir şey yoktur.

SaaS, kullanım istatistiklerini toplamak için sizi iyi bir konuma getirir. Kimin neyi kullandığını takip edebilmeniz için henüz yapmadıysanız özelliklerinize bakmalısınız. Deneyimlerimiz, en deyimsel müşterilerin genellikle aynı zamanda en işlevsiz olduğu; ayağını mühürleyen ve siz ona MS-Access'e aktar düğmesi verene kadar nefesini tutan o adam muhtemelen bir yıldan fazla bir süredir kullanmadı. Sadece bir müşteri onları kullanıyor olsa da bazı özellikler canlı tutulur, çünkü bu müşteri gürültülüdür ve her şey tatmin edici olmadığında işini başka bir yere götürmekle tehdit eder. Özelliğin kullanımdan kaldırılması artık bir müşteriye mal olabilir, ancak bu özelliği desteklemek için harcanan zaman yıllar boyunca düzinelerce müşteriye mal olabilir. Yönetim ekibinizin kalitesinin bir ölçüsüdür,

Bir özelliği bıraktığınızda, altı ay ila üç yıl arasında herhangi bir yerde, kararınızı müşterilerinize (veya en azından etkilenenlere) önceden duyurduğunuzdan emin olun. Aslında, kullanıcıya özgü özellikler oluşturmayı kabul ederseniz, satış personelinizin başlangıç ​​tarihinden itibaren bir son kullanma tarihi oluşturmasını sağlayabilirsiniz. Ona "destek ömrü" deyin ve ne kadar uzun isterse o kadar çok paraya mal olacağını açıkça belirtin. İstemcileriniz için geçici çözümler sağlamaya çalışın, böylece bir özellik gittiğinde akılda kalmazlar; örneğin, dışa aktarılan XML dosyalarınızı MS erişim biçimine dönüştüren bir komut dosyası veya daha iyi bir RDBMS seçme konusunda biraz tavsiye.

Önleyici bir önlem olarak bizim için çalışan bir şey, satış ekibimizden, geliştirme ekibimize ve yönetimimize aylık olarak gönderilen bir rapor almaktır. Bu rapor müşterilerden gelen geri bildirimleri kapsar - en popüler özellikler, en çok talep edilen özellikler, önerilen özellikler en fazla vızıltı yaratır. Bir geliştiriciyseniz bu ilginçtir, ancak asıl fayda, sonsuz özellik istekleri akışı göndermek ve önceliği temel almak yerine, daha büyük resim bağlamında her özellik hakkında biraz daha fazla düşünen satış ekibidir. hangi müşterinin en gürültülü olduğu. Buradaki etki, pazarlıktaki yeni özellik talepleri söz konusu olduğunda satış personelimizi daha zor hale getirmek oldu, çünkü her özelliğin ürünümüzün genel değer teklifine nereden sığabileceğinin bilincindeler.

Çok sayıda otomatik test içeren modüler koda sahip olmak, özellikleri ürününüze ve tekrar tekrar hacklediğinizde size yardımcı olacaktır, ancak sonuçta bu bir programlama sorusu değil, bir yönetim sorusudur. Satış yapmak için kod yazmak aptalın oyunudur.

Özel geliştirme istekleriyle karşı karşıya kaldığımda, bunları 3 kazığa ayıran serin filtreden geçiriyorum:

1. herkes için yararlı olacak ve uygulanması nispeten kolay harika şeyler
2. herkes için yararlı olacak ve uygulaması zor olan harika şeyler
3. sadece bu müşteri için gerçekten ihtiyaç duymayan aptalca şeyler

• Kategori 1, geçerli geliştirme döngüsünde uygulanır.
• Kategori 2, bir sonraki geliştirme döngüsünde uygulanır.
• Kategori 3, çoğu müşterinin talebinin buna değmediğini fark etmesinden sonra 1 adam dev dev fiyat teklifi alır.

Dürüst olmak gerekirse, bu asla başarısız olmadı ve kategori 3 özelliklerinden herhangi birini uyguladığımızı sanmıyorum. Ve elbette müşterilerin hiçbiri yürümedi (satışlar bunu başka türlü çekmeme izin vermezdi :)

(bu deneyim bir ISV şirketinde idi)

Bazı kısıtlamalar nedeniyle bazen belirli müşterilerin iradesine eğiliyoruz ve sadece bu istemci için kullanılabilecek özel yazılım parçaları oluşturuyoruz.

Sorununuz, yalnızca bir istemci için kullanılan kod oluşturmak değil. Sorun, yalnızca bir istemci için kullanılan kodu, bu işlevselliğe ihtiyaç duymayan diğer birçok istemciye sattığınız bir ürüne dahil etmenizdir.

İş modellerinin merkezi olarak temel bir ürünü olmayan şirketler, her zaman özel yazılım işi yapıyorlar. Teknik Borç kavramıyla nasıl başa çıkıyorlar? Onları Teknik İflas'a nasıl yönlendirmez?

Ürünü teslim ederler. Ve sonra devam ediyorlar. Sözleşmeli bir ürün geliştirirken, bu projede yaptığınız her şey tek bir müşteri içindir. Geliştirme sırasında tahakkuk etmiş olabilecek herhangi bir teknik borç, sözleşme bittikten sonra müşterinin sorunu haline gelir ve geliştirici başka bir müşteri için başka bir projeye geçer.

Bu tabii ki berbat bir iş yapmanın uygun olduğu anlamına gelmez. Bir numaralı hedefiniz, müşterinizin sizinle çalışmaya devam etmek istemesini sağlamaktır ve kaliteli iş yapmak oraya ulaşmanın yoludur. Ayrıca, teknik borcun sözleşme geliştiricileri için bir sorun olmadığı anlamına da gelmez. Kendinize sürekli olarak temiz kod yazsanız bile, bir noktada bir yığın borç tahakkuk eden bir proje üzerinde çalışmak için bir işe alınma şansınız vardır. Bu iyi olabilir (müşteri dağınıklığı temizlemek için size ödeme yapmak ister) veya değil (müşterinin kodun ne kadar kötü olduğu hakkında hiçbir fikri yoktur ve neden "sadece" birkaç özellik daha eklemek çok uzun süreceğini anlamıyor ).

Teknik borcun üretilmesi için özel işlerin garanti altına alındığı fikrine katılmıyorum. Teknik borçtan kaçınmak, belirli işlevsellik türlerinden kaçınmak anlamına gelmez - gereksiz katılıktan, bağımlılık sorunlarından ve kod tabanını değiştirmeyi zorlaştıran (yani pahalı) şeylerden kaçınmak anlamına gelir. Özel işlevsellik bunların hiçbirini ima etmez - işlevsellik için sadece dar bir temel anlamına gelir. Bu nedenle, anahtar, uygulamadan mümkün olduğunca yaygın, yeniden kullanılabilir mantığı hesaba katmak ve talep eden müşteri için dağıtılabilen kendi tek modülünü kendi bağımsız modülü olarak bırakmaktır.

Örneğin, müşterilerinizin bir intranete yükleyeceği dahili bir web uygulaması olan bir çıktıya sahip olduğunuzu varsayalım. Bir gün, bir müşteri gelir ve tarayıcı arayüzü yerine "zengin istemci" masaüstü uygulaması olan bir sürüm yaparsanız, şirketinize para dolu bir damperli kamyonu sürmeyi teklif eder. Sisteminiz iyi tasarlanmışsa ve bağımlılıklarınız iyi yönetiliyorsa, bu yalnızca yeni bir sunum bileşeni oluştururken alan adını, veri erişimini ve hizmet bileşenlerini yeniden kullanma meselesidir. 1999'a geri dönmek ve bunun için bir masaüstü uygulamasına sahip olmak isteyen tek bir müşteriniz olsa bile, teknik borç dikkate alınmaz.

Bu, cevaplanması biraz karmaşık bir sorudur çünkü projenin koşullarına gerçekten bağlı olan birçok şey gibi, sözleşmeli şirketin sahip olduğu kontrol düzeyi, özel yazılımın sözleşmeli şirket tarafından tüm yaşam döngüsü boyunca yönetilip yönetilmediğine, miktar kod tabanına erişimi olan diğer insanların “müdahalesinin”, katılan herkesin tutumunun, projenin karmaşıklığının ve kullanılan metodolojilerin ... Gerçekten devam edebilirim.

Tüm sistemlerin bir dereceye kadar teknik borcu vardır. Bazı durumlarda bu, geliştiricilerin her zaman temiz bir kod tabanını korumaya yönelik gayretli çabaları nedeniyle özellikle fark edilmeyebilir, ancak hiçbir sistem mükemmel değildir ve büyük bir yeniden tasarım, görünüşte masum ama uzun süredir devam eden bir sorunu belirgin hale getirebilir. Peki anlaşmalı şirketler bunu nasıl ele alıyor?

Çoğu durumda yapmazlar. Genellikle yazılım bir firma tarafından yazılır, daha sonra başka bir şirket tarafından değiştirilir ve sözleşme altındaki her şirket sıkı bir süre için çalıştığından ve kodu temiz tutma zamanını haklı çıkarmayacağından kod tabanının gerçekten dağınık olduğunu görmek olağandışı değildir ( ve bazen zar zor test edilir).

Diğer durumlarda, sadece sözleşmeli projelerini iyi yöneten değil, aynı zamanda mevcut kod tabanını bulduklarından daha iyi bir durumda bırakma zamanını da bulan şirketler bulabilirsiniz. Bunu sıklıkla dikkatli bir planlama, teknik borç kaynaklarını - genellikle en çok yeni işi en çok etkileyecek olanları - belirleyerek yaparlar ve teknik borcun yönetilmesine katkıda bulunan test senaryoları ve değişiklikler ve bunların tümünün proje programına katılması için stratejiler geliştirirler. .

Özel bir yazılım olmak, merkezi bir ürün yazmak yerine teknik borcu garanti ediyor mu? Kısa cevap hayır, ancak aktif olarak ele alınmadığı takdirde teknik borcun tahakkuk etmesi muhtemeldir. Bu, diğer herhangi bir yazılım projesiyle aynıdır. Projeyi tamamen yaşam döngüsü boyunca kontrol ederseniz, teknik borçlarla başa çıkmak için daha iyi bir fırsatınız olur. Değilse, bir önceki şirketin geride bıraktığı koddan tahakkuk etmiş olabilecek teknik borçlarla uğraşmanız gerekecektir.

Öte yandan, sorunuz iş modelinizden bağımsız olarak yazılım yazmanın teknik borç garantisi olup olmadığını sormaktıysa. Cevap kesinlikle olurdu. Asıl soru, herhangi bir şirketin teknik borcu nasıl ele aldığıdır. Planlı bir zamanda tahakkuk edip onunla başa çıkmasına izin verin veya teknik borca ​​en kısa sürede ödeme yapmak için temiz bir kod tabanını sürekli olarak yönetin mi? Bu cevap, şirketin bireysel önceliklerine ve ortaya çıkan teknik borcun mali açıdan anlamlı olup olmadığına bağlıdır.

Özel yazılım teknik borç garantisi değildir, ancak iki master hizmet vermektedir.

Özel bir yazılım şirketi, eldeki göreve tam olarak uyan bir yazılım parçası oluşturacak, teslim edecek ve gerektiğinde bunu koruyacaktır. Gerçekten özel yazılımlar genellikle çok sık eklenen yeni özelliklere ihtiyaç duymaz.

Bu soruda açıklanan sorun, ürün şirketlerinin başka türlü genel bir ürüne özel özellikler oluşturmasıdır. Ürün tamamen özel olsaydı, yalnızca bir müşterinin gereksinimleri değiştiğinde hareket ederdi. Ürün tamamen genel olsaydı, yalnızca daha çekici olması için yeni özellikler eklendiğinde hareket ederdi. Ancak, aksi halde genel bir üründe özel bir özelliğiniz olduğunda, yakın temasta, farklı hızlarda hareket eden iki kod parçanız olur. Depremlere neden olan tektonik plakalar gibi, bu kod parçaları arasındaki arayüz problemlere uygun bir "sıcak nokta" dır.