Bu ne yazık ki son kullanıcılarla olan varsayımsal olmayan bu durumla nasıl başa çıkılır?

Orta ölçekli bir şirkette çalışıyorum ama çok küçük bir BT gücüyle.

Geçen sene (2011), çok sayıda son kullanıcı tarafından çok popüler olan bir uygulama yazdım. Geçen yılın sonunda son teslim tarihine ulaştık ve en sonunda istenen uygulamaya bazı işlevler (bundan sonra funcA diyeceğim) eklenmedi. Yani, bu uygulama 2011 yılının sonundan beri canlı / üretimde çalışıyor.

Dün bir grup son kullanıcı, uygulamada hiç bulunmayan funcA'nın artık çalışmadığından şikayet etmeye başladı. Bu şirkette önceliğimiz, bir başvuru bozulduğunda öncelikli projelerden önce bunun düzeltilmesi gerektiğidir.

Kod ve sorguları karşılaştırdım ve 2011'den bu yana hiçbir fark yok, ki bu kanıtı A. Son kullanıcılardan birinin asla prova çalışmadığını itiraf etmesini sağlayabildim, ancak o zamandan beri bu son kullanıcı geri döndü ve daha önce çalıştığını söyledi ... Son kullanıcıların sürüsünün özümsemiş olduğuna inanıyorum. ona. Ayrıca, “zaman kısıtlamaları nedeniyle elde edilemeyen funcA”, provaC gibi, özellikle proje ile ilgili gereklilikleri ve günlük güncellemeleri olan notlarımı da inceledim.

Birçoğuyla konuştum ve bir programlama geçmişinden çok uzakta oldukları için nerede kafalarının karışabileceğini görebiliyorum, ancak proje öncelik sırasını atlamak için grup halinde hareket edecek kadar akıllı olduklarını da biliyorum. İşlerini kolaylaştırmak istedikleri işlevsellik.

En kötüsü, şimdi grup düşüncesinin yerleştiği ve patronum ve BT yöneticisinin kod veya sorgu değişikliği olmasa da aslında onlara inanmaya başlaması. Mantığın durumu gözden geçirildiği sürece, 1 = 1 ise funcA çalışmaz.

Yani, bu senaryomun açıklamasının sonudur, ancak bu, aslında büyük olasılıkla devralacak olan bir üretim sorununu düzeltmek için harekete geçmeme neden olacak olan performans ölçütlerimden birkaç kez etkilenmemeye çalışıyorum. 1 ay.

Kolayca gözlenebilir gerçeklerle ilgili anlaşmazlıkları çözmek oldukça kolaydır: sadece gerçekleri gözlemleyin. "Evimin dışında mor odun olan bir ağaç var" dersem, evime gelebilecek herhangi biri, ifademin gerçeğini veya yanlışlığını kendileri için doğrulayabilir.

FuncA'nın eskiden sürümde çalıştığını ve eski bir sürümde çalıştığını ve şimdi işe yaramadığını ve üründe hiç bulunmadığını düşündüğünden şikayet ediyorlarsa, bunu ispatlamalarını isteyin. (Ya da daha nazik bir ifadeyle, "sorunu yeniden oluştururken sorun yaşıyoruz. Bize yardım edebilir misiniz?")

Hala bir sürümleri yoksa önceki sürümün bir kopyasını verin ve onları bir LiveMeeting'e alın ve size FuncA'yı nasıl kullandıklarını göstermelerini sağlayın. Bunu yapamazlarsa, (umarız), orada bulunmadığının farkına varırlar ve bunun hakkında davanızdan kurtulurlar ya da en azından uygulanmasını sağlamak için farklı bir taktik denerler. (Ve LiveMeeting’e yönetimden veya PM’den birinin girdiğinden emin olun.)

Bu, gerçeklerle ilgilenilebilecek bir konu değil - denerseniz, güvenilirliğini kaybedeceksiniz.

İlk olarak, yazılımın "bozulduğunu" kabul edin - kullanıcıların yapmak istediklerini yapmadığı için. Şimdi, kullanıcıların, yazılımın yapmasını istediklerini yapmalarına izin verme hakkına sahip olduğunu kabul edin - bu nedenle yazılım budur. Öyleyse elimizdeki kusurlu yazılım ve tamir etmeyi reddeden bir mühendis…

Sonuç olarak, öncelikleri belirlemek için çalıştırdığınız sistem, bu kullanıcılar yazılımlarını normal kanallardan geçerek sabitleyemezler, bu nedenle sistemi yönetmek için gıda zincirinde yükselen yan kanalları kullanıyorlar ve yarı gerçekleri tırmanıyorlar. KPI'nızın kötü görünmesini sağlamanın ortalama zamanı (asıl endişeniz KPI'nız değil müşteriler olmalıdır) - KPI'larınız, eğer sizi severse "teminatlı hasar" veya beğenmezlerse faydalı bir yan etki olarak kabul edilir. Ancak, ne kadar olacağı konusunda bazı kontrolleri var - en çok onlar senden hoşlanıyor.

Öyleyse, olan şey sistem bozuluyor ve herkes istediğini elde etmek için şeyleri manipüle etmeye çalışıyor. Bir özellik istiyorlar ve sen de lekesiz KPI'larını korumak istiyorsun.

Sistemi düzeltirseniz veya ofis politikalarını çok hızlı oynamayı öğrenmiyorsanız, oyun bitti: kaybedersiniz.

Not: Bu tartışmanın hiçbiri Ölü çizgileri, hata vs özellik tartışmaları, kimin parasını ödediğini vb. İçermez. Bunlar Gerçeklerdir - ve gerçekler önemli değildir (pekala, öyle yaparlar, ama birçok yönden manipüle edilebilirler ... ofis politikalarında.

Örgütsel bir problem hissediyorum.

BT şefini ve patronunuzu içeren bir hiyerarşi var. Kuruluşunuz gelenekselse (Çevik gibi görünmüyorsa), siz bir kaynağınız ve onlar kaynak yöneticileridir. Yazılım geliştirme denilen tam zamanlı bir iş var. Son kullanıcılar doğrudan özellik istiyorsa, önceliklerini belirliyorsa ve zamanınızı yönetmeye çalışıyorsa yöneticileriniz gereksizdir. Son kullanıcılara karşı sorumlu olabilirler, ancak işlerini yapıyorlarsa, onlara karşı sorumlu olursunuz ve sizi odaklanmış geliştirici modundan defansif geliştirici moduna geçmekten korumak zorundalar .

Cevabımın içeriğini belirlemek için birkaç nokta:

• Yazılım geliştiriciler zaman yolcusu değildir, bu nedenle sonuçların ne olabileceğine değil, oldukları gibi değerlendirilmesine ihtiyaç vardır.
• Bir özellik bir gereksinim belirtiminde, bir programda ve tamamlanmış olan işin üzerinde öncelikli ise meşru bir şikayet olabilir. Aksi takdirde, sizi sorumlu tutmak için gerekçe nedir?
• Cezanızın, eğer hak edilmişse, emir komuta zincirinizden gelmesi gerekiyor. Pazarlama ve satış, ürün geliştirme müşterileri azarlarsa beğenmeyeceği gibi, çoğu kuruluşun ürün yöneticileri var, müşteri gazabını almak (ve övmek) ve kanallar aracılığıyla iletmek.
• Ürün yöneticileri, projelerin başarılı kısımlarının sıcaklığına dayanırlarsa, ancak geliştiricilere karşı karşıya kaldıklarında kırbaçları kırarlarsa çok zor ilişkiler kurabilirler.
• Yıllarca çalışmaya değer işlevsel bir ürün teslim ettiyseniz ve sektörde gördüğümden, istenen özelliği eklemek bir ay (iki ay) alıyorsa, tahmininiz ortalamanın üzerinde idi.
• Sorunu adil ve verimli bir şekilde çözmek, kişilerin suçlama parmaklarını ceplerine sokmalarını ve ileriye dönük bir plan yapmalarını gerektirir.

BT başkanının sahip olması gereken bir süreçte keçi olmak yerine takdir edilirseniz, daha iyi motivasyonla çok daha kaliteli işler yapabileceksiniz. Adil ve üretken bir yol. Umarım bu şekilde yönetileceksin ve gelecekte bir zamanlar, umarım diğerlerini de bu şekilde yöneteceksin.

Böyle bir gerçeklik arızası durumunda, en iyisi ileriye gitmek. Geçmişi tartışmak yerine, çalışmasını sağlamak ve bunun ne kadar kolay ya da zor olacağı hakkında konuşun. Sorunun ilk defa düzeltilmesi ya da uygulanması sorun değil. Eğer yönetim A'nın B'den önce yapılmasını istiyorsa bunu yapın.

Bu projede çalışmış olan tek kişi siz misiniz? Projeyi yaparken birine cevap vermiş gibisiniz. Bütün bu insan nerede? Projenin belgeleri neyin teslim edildiğini söylüyor?

Belge kağıdı izi olmalı. Uygulamanın nasıl kullanılacağını gösteren bir eğitim dokümanı. Neyin geliştirildiğini gösteren işlevsel bir özellik. Bir özellik eklenmediyse, bunun hakkında da belgeler bulunmalıdır. Birinin bunu kabul ettiğini söyleyerek imza atması gerekiyordu.

Sözlerine karşı senin sözün olmamalı, hepsi belgelerde olmalı.

Bu belgelere sahip değilseniz ... o zaman korkarım bu şeyi ısırmanız gerekecek. Bunu bir hayat dersi olarak düşün. Günün sonunda, kullanıcılarınız sizin müşterileriniz ve demişler: müşteri her zaman haklıdır. Bu özelliğin nasıl ekleneceğini ve ne kadar süreceğini çizin. Bir toplantı yapın ve 'Şunlarımızda bir şeyler söyleyin' Kayıtlarımız bu özelliğin hiçbir zaman gerçekleşmediğini gösteriyor, ancak x haftada hayat alabiliyoruz. Başa mı gidelim? '

Ve kutsal olan her şeyin aşkı için .... onaylandığını göstermek için gereken belgeleri alın.