Destek rutinden çıkmak ve teknik borcu geri ödemeye nasıl başlayabilirsiniz!


13

Ben bir arkadaşım var". Evet iyi bir başlangıç ​​biliyorum ama dürüst olmak gerekirse bu ben değilim!

Temel olarak yaklaşık 4 yıldır başarılı bir proje üzerinde çalışıyor, zorluk teknik borcun yakalanmış olması ve ürünü desteklemeyi (bunu ve bunu değiştirmeyi) durdurmayı ve aslında gerçek gelişime devam etmeyi neredeyse imkansız buluyor .

Çeşitli önerilerde bulundum, tüm zamanlarınızı kaydedin, bilet oluşturun, e-postalara cevap vermeyin vb. Buradaki sorun, yalnızca "yararlı" bir şey elde etmediğini hatırlatmak gibi görünüyor.

Teknik borç büyük ölçüde meydana geldi, çünkü ilk etapta, kullanıcılardan talep ve telefon görüşmeleri almak ve bunları hızlı bir şekilde uygulamak, ürüne büyük bir fayda sağladı.

Bilmek istediğim, herkesin bu ruttan nasıl çıkabileceğine dair herhangi bir önerisi var mı, büyük bir kısmı kullanıcıların algılarını değiştirecek, böylece sadece zil çalabileceklerini ve bir şeyler bekleyebileceklerini düşünmeyecekler o zaman orada yapılsın.

Her şey çok iyi söyleyerek planı daha iyi söylüyor, ancak destek gereksinimi ve kullanıcıların göreceli baskıları göz önüne alındığında gerçek gelişimi planlamanın çok zor olduğunu anlıyorum (yukarıya bakın).


2
Sorunuzu doğru bir şekilde anlarsam, arkadaşınız kodu düzenlemek için kullanıcı desteği / değişiklik isteklerini yerine getirmekle çok meşgul. Sonuç olarak kullanıcıların bekledikleri yeni özellikler var mı?
Larry Coleman

@larry coleman, oh evet bu viskoz bir daire, sürekli destek kadar iç karartıcı olan yeni istekler gecikiyor.
MrEdmundo

Yanıtlar:


13

Arkadaşınızın organizasyonu umutsuzca değişim yönetimi için birine ihtiyaç duyar. Bu kişi veya grup, değişiklik talepleri ve hata düzeltmeleri alıp bunları iş etkisi ve gereken çaba miktarına göre önceliklendirir. Bu şekilde, şu anda arkadaşınızı rahatsız eden herkes için daha önemli olan görevlerin aksine, bir bütün olarak kuruluş için daha önemli olan görevler yapılacaktır.

DÜZENLEME: Bunun nasıl işleyeceğine örnek olarak çoğu kuruluşun önem derecesi ölçeği vardır. En yüksek önem derecesi, işe yaramayan, iş açısından kritik bir uygulama veya işlevdir. İşletmenin sorunun üstesinden gelmek için yapabileceği bir şey varsa, bu, ciddiyeti bir sonraki seviyeye düşürür. Uygulama iş açısından kritik değilse, bu önem derecesini daha da düşürür. Yeni geliştirme taleplerine normal olarak ayrı ayrı öncelik verilir.


Anlaşıldığı üzere, bu, prensipte yapılması gereken ve yerine getirilen herhangi bir önceliklendirmeyi ortadan kaldırmış gibi görünen günlük görevlere nasıl yardımcı olur.
MrEdmundo

2
Sorunuzdan, onları yapıştıracak yetkiye sahip öncelikleri belirlemekten sorumlu tek bir kişi veya grup olmadığını tahmin ediyorum. Bu büyük bir problem. Hatta arkadaşınızın çözülemezse yeni bir iş aramasını önerecek kadar ileri gideceğim.
Larry Coleman

Hmmmm, ne demek istediğini anlıyorum, yine de çalıştığı görevlerin çoğunun bir öncelik olduğu düşünüldüğünde, bu durumun işletme algısını değiştirmeye nasıl yardımcı olduğundan emin değilim. Bir kişinin talebinin her zaman en öncelikli olduğu ancak artık o kişinin işitilmemesi fikrini nasıl değiştirirsiniz? Belki de daha fazla personele ihtiyacı vardır.
MrEdmundo

2
Bu işin tek yolu, işletmeden gelen bir sıralama görevlisinin öncelikleri belirlemesi. Örneğin, iş birimi başkanı öncelikleri belirlerse, işin geri kalanına, işlerine değer vermeleri halinde işin geri kalanı da eşlik eder. Onlar hoşuna gitmeyebilir, ama bu arkadaşınızın sorunu olmayacak.
Larry Coleman

10

Birinin çağrıları almasını sağlayın ve hattın

Bunu hemen halledeceğiz.

için

Çok iyi bir öneri. En kısa zamanda üzerinde çalışmaya başlamak için bir özellik isteği oluşturacağım. İsteğinizdeki ilerlemeyi izlemek isterseniz, buradan izleyebilirsiniz: [vaka takipçisi biletine bağlantı]. Gelecekte, ben de burada olduğum şekilde futures taleplerini gönderebilirsiniz: [vaka izleyiciye bağlantı]

Bu muhtemelen bence bunu yapmanın en basit ve etkili yoludur. Son bit, zaman içinde çağrıları cevaplayan bu kişinin stresini azaltmaya çalışır.

Mevcut 'öncelik' sistemi ile karşılaştığınız sorun , her şey öncelik olduğunda hiçbir şeyin öncelik olmamasıdır . Bunun için, arkadaşınızın umutsuzca, değişiklik isteklerini yöneten gelişimden ayrı olan @Larry Coleman'ın tavsiyelerine dikkat etmesi gerekiyor. İdeal olarak, arkadaşınız bir özellik isteği hakkında bile bilgi sahibi olmamalı, bu ayrı grup işe öncelik verilmesini kabul edene kadar. Bu, şu anda çağrıları cevaplayan ve işi anladıkları ve gelişmeyi anladıkları sürece bu yeni kişi bile olabilir.


3
+1 "her şey öncelik olduğunda, hiçbir şey öncelik değildir"
Larry Coleman

2

Ben de benzer bir durum yaşadım. Ürün ayakkabı telleri üzerine inşa edildi ve piyasaya sunulduğu ilk pazar oldu. Başlangıçta başarılıydı (solo-öncü bir işletme için), ancak sanırım 2003-2007'den beri işe yarayan bir şey. Ben personel aradı ama iyi personel işe pahalı ve hiçbir şekilde kolay zor yoldan öğrendim. Arkadaşınızın da benzer bir durumda olduğunu düşünüyorum.

Benim durumumda, şeylerin bir noktada yokuş aşağı gideceği konusunda erken anlaşıldı. İş hala büyüyordu, ancak rekabet başını çekiyordu, piyasa küçülecekmiş gibi görünüyordu, ekonomik bir yavaşlamanın ortaya çıktığı gibi erken işaretler (2006'nın ortası) vardı. ürünün sonunda öleceğine karar vermem; daha sonra, daha iyi (müşteriler ve kendim için).

Geçmişe baktığımda, muhtemelen kötü kararlar aldığım kadar iyi kararlar aldım, ama işte kısa bir paket:

  1. Düzgün ve erken Çalışanlar. İhtiyacınız olursa fon alın. (Hiçbirini aramamak benim en büyük hatamdı.) Satış yaparsan para bulacaksın.

  2. Sürüm kontrolü / birim testleri / en iyi uygulama ile ilgili tüm hooplaları kullanın. Hepsi üniversitede öğretildiğinde aptal / gülünç / ilgisiz görünüyorlar, ancak genellikle iyi nedenlerle en iyi uygulamalardır.

  3. Özellikle teknoloji odaklıysanız, en az bir satış / pazarlama görevlisi işe alın. (Çünkü eğer öyleyse, bir satış ortağı ağınız olsa bile, teknoloji konularında pazarlamaya göre daha fazla zaman harcamaya doğal bir eğiliminiz olacaktır).

  4. Kalabalık kaynağı desteğiniz. Kullanıcıların kendilerine yardımcı olabilmesi için bir forum oluşturun. Bir bilet sistemi kurun ve uzman kullanıcılarınızı (genellikle sık forum kullanıcıları) sanal asistanlar olarak özel bir bölüme dalmaya davet edin. Birkaç dolar için bu küçük göreve ihtiyaç duyan çok sayıda müşteriyle ilgilenmelerine izin verin, böylece daha büyük resme odaklanabilirsiniz.

  5. Verdiğiniz destek miktarını azaltma çabalarınızı en üst düzeye çıkarın. Ne kadar az desteğiniz olursa, daha ilginç şeyler yapmak için o kadar fazla zamanınız olacaktır. Ürünün kukla kanıtı olduğu zaman, müşteriler minnettar olacaktır ve satışlarınız ve destek personeliniz de olacaktır.

  6. Gerçek geliştiricilerin desteğin bir kısmını yapmasını sağlayın (günde bir veya iki saat, bu yüzden gerçeklikle iletişim kurmazlar) ve eğer varsa ürünü yeniden tasarlama / değiştirme (kullanıcı arayüzü, işlevsellik) için ücretsiz bir el verin destek için daha az zaman harcamalarını sağlayacak her şeyi tanımlayın. Fikir şu ki, kullanıcılar aynı nedenlerle tekrar tekrar yönetiliyorsa, destek çağrılarından kurtulmak için işleri en kısa sürede düzeltmek isteyeceklerdir. Ve daha akıllı olanlar aslında bunu yaparlar ve tam olarak istediğiniz budur.

  7. Ürünün öleceğini düşünüyorsanız, orada ve orada öldürmeye karar verin ve bir sonraki adım üzerinde çalışın. Bırak ölsün, gerçekten. Bir nakit inek bir nakit inek; amacına hizmet ettiğinde, kasaplara yollayın. Bunu nazikçe yapın (müşteriler için), ancak bakım yükü, rekabetiniz, geç kalanlar ve bazı teknik borç biriktirmiş olmanızla rekabetiniz öyle ise, uzatılmış hayatta kalma süresinin çok fazla zaman kaybetmesine izin vermeyin. , yeni özellikleri zaten yapabileceğinizden daha hızlı uygulayacaktır.


1

Her seferinde bir satır. Her düzeltme için biraz daha fazla zaman ayırın, saldırıları temizleyin ve giderken otomatik testler ekleyin. Çoğu zaman, doğru bir şey yapmak, başka bir düzeltme eklemekten çok daha hızlı olur. Yönetim, arkadaşınızı daha hızlı çalışmaya zorlarsa, yönetim sıkça sevdiği gibi, daha kalın bir cilt büyütmeli ve "bittiğinde" moduna geçmelidir.


0

Anahtar, onu bir dereceye kadar korumak için etrafında ne tür bir geliştirme yöntemi var? Örneğin Scrum'da hangi işin sprint sırasında genellikle değişmeyeceği fikri vardır. Dolayısıyla, ne yapılacağı ve hemen yapılmayabilecek bazı kurallar vardır. Diğer soru, yönetimin bir destek rutinde olmamasını ne ölçüde desteklediğidir. Kayıtsız bir yönetim arkadaşınızın projesi için bir ölüm patlaması olabileceğinden bu da önemli olabilir.


0

Yapılacak en iyi şey otobüsü durdurmak ve geriye bakmaktır. Arkadaşın

  • Sistemdeki her sorunun ve neden kötü olduklarının ardındaki mantığın bir raporunu hazırlayın. Tasarım problemleri ve gerekli yeniden düzenleme miktarı vurgulanmalıdır.
  • Sorunları çözmek için kaba zaman çizelgeleri verilmelidir
  • Rapor yöneticilerine ve daha sonra sistemdeki pay sahiplerine verilmelidir
  • Tespit süresi boyunca tüm özellik gelişmeleri durdurulmalıdır.

Birçok proje bunu yapıyor. Eğer yönetim ikna edilemezse, bu kayıp bir durumdur, ancak kabul ederse, sistem uzun vadede yeniden şekillenebilir.


Teoride kulağa hoş geliyor, ancak uygulama kritik öneme sahipse, özellik dondurma seçeneği olmayabilir.
tdammers

Sonra bakım yapmak için başka bir geliştirici dallamak ve eklemek için iyi bir zaman olabilir.
Tjaart
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.