Bu yazıda, ürünlerimizin işlevselliğinin geliştirilmesi için fikir seçme konusundaki deneyimimi paylaşacağım ve ana geliştirme vektörlerini nasıl tutacağınızı anlatacağım.
Otomatik bir ödeme sistemi (ACS) - faturalandırma geliştiriyoruz. Terim
Ürünümüzün ömrü 14 yıldır. Bu süre zarfında sistem, endüstriyel bir derecelendiricinin ilk versiyonlarından birbirini tamamlayan 18 üründen oluşan modüler bir komplekse geçmiştir. Programlar için uzun ömürlülüğün en önemli yönlerinden biri sürekli gelişimdir. Ve gelişme için fikirlere ihtiyaç vardır.
Fikirler
kaynaklar
5 kaynak var:
- Kurumsal bilgi sistemleri geliştiricisinin ana arkadaşı müşteri. Ve müşteri, karar vericilerin, proje sponsorlarının, süreçlerin sahipleri ve yürütücülerinin, kurum içi BT uzmanlarının, sıradan kullanıcıların ve farklı derecelerde ilgilenen çok sayıda insanın kolektif bir görüntüsüdür. Müşteri temsilcilerinden her birinin potansiyel olarak bir fikir tedarikçisi olması bizim için önemlidir. En kötü durumda, sadece sistemdeki sorunlar hakkında olumsuz geri bildirim alırız. En iyi ihtimalle, müşteri tarafında, müşterinin ihtiyaçları hakkında yapılandırılmış bilgi sağlayan, iyileştirme için sürekli bir fikir kaynağı olan bir kişi vardır.
- Bizim satıcılar ve hesap yöneticileri iyileştirme için ikinci en önemli fikir kaynağıdır. Sektör temsilcileriyle çok fazla iletişim kurarlar ve aktif olarak potansiyel müşterilerden faturalandırma işlevi için ilk elden talepler alırlar. Tüccarlar ve hesaplar, işlevlerindeki tüm önemli değişikliklerden ve rakiplerin en son yazılım güncellemelerinden haberdar olmalı, farklı çözümlerin artılarını ve eksilerini gerekçelendirebilmelidir. Bazı faturalandırma özelliklerinin fiili bir standart haline gelip gelmediğini ilk hissedenler bu çalışanlarımızdır ve bu özellikler olmadan yazılımın tamamlanmış sayılması mümkün değildir.
- Ürün sahibi üst düzey yöneticilerimizden biri veya çok deneyimli bir proje yöneticisidir. Şirketin stratejik hedeflerini göz önünde bulundurur ve ürün geliştirme planlarını bunlara göre ayarlar.
- mimar, seçilen / kullanılan teknolojik çözümlerin olanaklarını ve sınırlamalarını ve bunların ürün geliştirme üzerindeki etkisini anlayan kişi.
Geliştirme ve test ekipleri. Ürün geliştirmeye doğrudan dahil olan kişiler.
İsabetlerin sınıflandırılması
Kaynaklardan - mektuplar, biletler, sözlü talepler - ham veriler alıyoruz. Tüm
itirazlar sınıflandırılır:
- Danışmalar "Nasıl yapılır?", "Nasıl çalışır?", "Neden çalışmıyor?", "Anlamıyorum..." anlamlarıyla. Bu tür aramalar 1. Seviye Destek Hattına gider. İstişareyi diğer temyiz türlerine göre yeniden eğitmek mümkündür.
- olaylar "Çalışmıyor" ve "Hata" anlamı ile. 2 ve 3 destek hattı tarafından idare edilir. Bir yamayı hızlı bir şekilde düzeltmek ve yayınlamak gerekirse, destekten doğrudan geliştirmeye aktarılabilir. Bunu bir değişiklik talebi olarak yeniden sınıflandırmak ve bekleme listesine göndermek mümkündür.
- Değişiklik ve geliştirme talepleri. Destek Hatlarını atlayarak ürün biriktirme listesine girin. Ancak onlar için ayrı bir işleme prosedürü vardır.
İsabetlerle ilgili bu tür istatistikler var - yayınlandıktan hemen sonra, isabet sayısı kısa bir süre için% 10-15 artıyor. Çok sayıda kullanıcısı olan yeni bir müşteri bulut hizmetlerimize geldiğinde de arama patlamaları oluyor. İnsanlar yeni yazılım özelliklerini kullanmayı öğreniyorlar, tavsiyeye ihtiyaçları var. Küçük bir müşteri bile sistemde çalışmaya başlarken ayda 100 saatten fazla istişareyi kolayca yakar. Bu nedenle, yeni bir müşteriyle bağlantı kurarken her zaman ilk istişareler için zaman ayırırız. Çoğu zaman belirli bir uzmanı bile seçeriz. Kira maliyeti, elbette, bu işçilik maliyetlerini karşılamaz, ancak zamanla durum düzelir. Uyum süresi, kural olarak, 1 ila 3 ay sürer ve bundan sonra danışmanlığa duyulan ihtiyaç önemli ölçüde azalır.
Önceden, aramaları depolamak için kendi kendine yazılan çözümleri kullanıyorduk. Ancak yavaş yavaş Atlassian ürünlerine geçti. Önce Agile üzerinde çalışmayı kolaylaştırmak için geliştirme, ardından destek aktarıldı. Artık tüm kritik süreçler Jira SD'de yaşıyor ve ayrıca Jira için çeşitli eklentiler ve Confluence ile birlikte sunuluyor. Kendi kendine yazılan çözümler, yalnızca şirketin faaliyetleri için kritik olmayan süreçlerde kaldı. Görevlerimizin artık uçtan uca olduğu, bir sistemden diğerine atlamadan destek ve geliştirme arasında aktarılabileceği ortaya çıktı.
Bu paketten, tüm görevler, planlanan ve fiili işçilik maliyetleri hakkında veriler alabilir, müşteriler için çeşitli faturalandırma seçeneklerini kullanabilir ve dahili ihtiyaçlar için belgeler ve müşterilere bir rapor oluşturabiliriz.
Değişiklik İsteklerini İşleme
Tipik olarak, bu istekler özellik gereksinimleri şeklinde gelir. Analistimiz talebi inceler, bir spesifikasyon ve üst düzey bir Görev Tanımı oluşturur. Spesifikasyonu ve Görev Tanımını bu talebi onay için gönderen kişiye aktarır - müşteri ile aynı dili konuştuğumuzdan emin olmalıyız.
Müşteriden birbirimizi doğru anladığımıza dair onay alan analist, talebi ürün biriktirme listesine girer.
Ürün özellik yönetimi
Biriktirme listesi, alınan değişiklik ve geliştirme isteklerini biriktirir. Direktör, bakım, geliştirme, satış ve sistem mimarından oluşan teknik konsey altı ayda bir toplanır. Tartışma formatında, konsey birikmiş iş listesinden başvuruları analiz eder ve öncelik sırasına koyar ve bir sonraki sürümde uygulanmak üzere 5 geliştirme görevi üzerinde anlaşmaya varır.
Aslında teknik konsey, başvurularda kaydedilen ihtiyaçları göz önünde bulundurarak sektörün ve pazarın gereksinimlerine cevap vermektedir. Alaka düzeyi düşük olan her şey birikmiş iş listesinde kalır ve gelişmeye ulaşmaz.
Değişiklik Taleplerinin ve Finansmanının Sınıflandırılması
Geliştirme pahalıdır. Bu nedenle, bir çalışandan değil, bir müşteriden bir değişiklik talebi gelirse, hangi seçeneklere sahip olabileceğimizi size hemen söyleyeceğiz.
Değişiklik talepleri şu şekilde sınıflandırılır: sektöre özgü ihtiyaçlar veya işletmenin bireysel özellikleri; önemli miktarda yeni işlevsellik veya küçük bir düzeltme. Küçük düzeltmeler ve bireysel istekler herhangi bir gösteriş olmadan işlenir. Bireysel talepler, onunla yapılan proje çalışmasının bir parçası olarak belirli bir müşteri için hesaplanır ve uygulanır.
Bu, büyük bir endüstri ihtiyacı değilse ve işlevsellik miktarı büyükse, ana işlevselliğe ek olarak satılacak yeni bir ayrı modül geliştirmeye karar verilebilir. Müşteriden böyle bir talep gelmesi durumunda, modülü geliştirme masraflarını karşılayabilir, müşteriye modülü ücretsiz veya kısmi ödemeli olarak sağlayabilir ve modülü kamuya açık bir şekilde satışa sunabiliriz. Böyle bir durumda, müşteri metodolojik yükün bir kısmını üstlenir ve aslında modülün pilot uygulamasını yürütür.
Bu çok büyük bir endüstri ihtiyacıysa, temel ürüne yeni işlevler eklemek için bir karar alınabilir. Bu durumda masraflar tamamen tarafımıza aittir ve yeni işlevsellik, programların mevcut sürümünde görünür.
Eski müşterilere bir güncelleme sağlanır.
Birkaç müşterinin benzer bir ihtiyacı olabilir, ancak bu, toplu bir ürünü çekmez. Bu durumda, spesifikasyonu bu müşterilere gönderebilir ve geliştirme maliyetlerini aralarında paylaşmayı teklif edebiliriz. Sonunda herkes kazanır: Müşteriler işlevselliğin uygulanmasını düşük bir maliyetle elde eder, biz ürünü zenginleştiririz, bir süre sonra diğer piyasa katılımcıları da kendi kullanımları için işlevselliği alabilirler.
DevOps
Geliştirme, yılda iki büyük sürüm hazırlar. Her sürümde teknik konseyden alınan 5 görevin uygulanması için süre ayrılmıştır. Böylece cironun arkasında, ürünün gelişimini asla unutmuyoruz.
Her sürüm, uygun bir dizi test ve belgelemeden geçer. Ayrıca, bu sürüm ilgili müşterinin test ortamına kurulur ve o da sırayla her şeyi titizlikle kontrol eder ve ancak bundan sonra sürüm üretime aktarılır.
Sürüm sistemine ek olarak, müşterilerin altı ay boyunca hatalarla yaşamaması için bir hızlı hata düzeltme formatı vardır. Bu ara biçim, birinci öncelikteki olaylara hızla yanıt vermenize ve belirtilen SLA'yı yerine getirmenize olanak tanır.
Yukarıdakilerin tümü, öncelikle kurumsal sektör ve şirket içi çözümler için geçerlidir. KOBİ segmentine odaklanan bulut hizmetleri için, müşterilerin ürün geliştirmeye katılmaları için bu kadar geniş fırsatlar yoktur. SMB için kiralama formatı bunu önermez bile. Kurumsal bir tarafın açık gereksinimleri şeklinde bir değişiklik talebi yerine, hizmet için yalnızca olağan geri bildirimler ve dilekler vardır. Dinlemeye çalışıyoruz, ancak ürün çok büyük ve bir müşterinin eski tarihsel sisteminden tanıdık bir şey getirme arzusu, bir bütün olarak sistemin geliştirme stratejisiyle çelişebilir.
Kaynak: habr.com