Yöneticim, müşterinin taleplerine göre değişikliğe devam etmemi istiyor.

Soru

Nasıl ilerlemeliyim?

Değişikliği müşterinin taleplerine göre devam etmelisiniz.

Görünüşe göre müşteri bu değişikliği istiyor. Görünüşe göre müdürünüz de aynı fikirde. Görünüşe göre müşteriyi mutlu etmek için teknik etkiyi özümsemeye istekli görünüyor.

Açıkça açıklamış olmanıza rağmen yöneticinizin sizi anladığını düşünmüyorsanız, bunu tekrar açıklamanın bir anlamı yok. Görünüşe göre anladı ama kabul etmiyor).

Açıkçası, burada neyin gereksiz olduğuna siz değil müdürünüz karar verir.

Müşterinin talebi karşılandığında , müdürünüzle konuşmak için sakin bir zaman bulmak isteyebilirsiniz. Böyle bir tartışmada amacınız yöneticinizi haklı olduğunuza ikna etmek olmamalıdır. Bunun yerine, amacınız yöneticinize kararı sormak olmalıdır, böylece şirketinizdeki müşteri talep sürecini daha iyi anlayabilirsiniz. Açıkçası müşteriler hakkında anlamadığınız şeyler var.

Ya da belki başka bir iş mi arıyorsunuz?

Bulunduğunuz bir işe ihtiyacınız varsa Müşteriniz ve müdürünüz zaten karar vermiş olsa bile müşterinin ne alıp almayacağına karar vermek için yeni bir iş aramalısınız.

Belki de bir yönetim pozisyonu aramalısınız. hangi özelliklerin teslim edilip hangilerinin teslim edilmediği konusunda daha fazla etkiye sahiptir. Veya belki de müşterilerle daha yakından etkileşime gireceğiniz, ürün özelliği zaman çizelgesini etkileyeceğiniz ve hangi müşterinin tatmin etmek veya reddetmek istediğine karar vermenize yardımcı olabileceğiniz bir müşteri hizmetleri veya ürün yönetimi rolü aramalısınız.

Veya, @IsmaelMiguel'in doğru bir şekilde işaret ettiği gibi, bireysel müşteri taleplerinin nadiren talep edildiği veya yerine getirildiği bir ürün şirketi için çalışın. (Elbette hala yöneticinizin uğraşmak için talimatları olacaktır.)

Ya da yöneticime, bu kadar basitse yardım etmesi gerektiğini söylemeliyim?

Patronunuzla ancak işinize gerçekten değer vermezseniz alay etmelisiniz.

Sorunuz, kullanıcıların talebinin geçerliliğini ve doğruluğunu sorgulamaya ve yöneticinizin bunu kabul edip işleme koyma seçimine dayanmaktadır. Kullanıcının talebi geçerlidir ve yöneticinizin kararı geçerlidir.

Yapmak için çalıştığınız iş budur .

Sizden istenen, işlevsel olmayan bir gereksinimin uygulanmasıdır.

Sizden bir işlevsellik genişletmesi değil, bir kullanılabilirlik iyileştirmesi isteniyor.

Bir sistemin işlevsel olmayan gereksinimleri hâlâ gereksinimlerdir .

Bu durumda, bu kullanılabilirlik düzeltmelerinin kullanıcının üretkenliğini artırması ve hata oranlarını düşürmesi amaçlanmıştır.

Kullanılabilirlik düzeltmelerinin uygulanması önemsiz olmayabilir. Bu, ikinci sınıf endişeler olarak ele alınmaları gerektiği anlamına gelmez. Bir geliştirici olarak, kolay olanı değil önemli olanı yaratmak için oradasınız.

Kullanılabilirliği bir anahtar olarak anlamanıza yardımcı olacak mükemmel bir kitap, temel, mühendislik sorunu,
"The Design of Everyday Things", Donald Norman (bağlantı).

Özellik tamamlanmış ve kullanıcı kontrollerinin daha da geliştirilmesi gereken bir sisteme iyi bir örnek Model T Ford'dur. Bir araba olarak gider. Yönlendirir. O durur. Yolcuları taşır.

Şimdi kullanıcı kontrollerine bir göz atın (bağlantı). Artık kimse onları böyle yapmıyor - iyi nedenlerle.

Başlamak zordur (ve hataya, yani yaralanmaya eğilimli).

Gaz kelebeği bir çifttir Direksiyon kolonunun zıt taraflarında bulunan çubuklar ve bağımsız olarak ve bazen aynı anda çalıştırılmaları gerekir.

Her iki durumun da işe yarayabileceği bir çözüm bulmaya çalışın.

Bu işlevsellik zaten mevcutsa, görünüşe göre Kullanıcı Arayüzü açısından düzgün şekilde yapılmamış demektir. Belki kontrolleri veya navigasyonu yeniden tasarlar? Akıllıca bir yöntemle tıklama miktarını azaltmaya çalışın.

Ayrıca, yöneticiniz size tamamen katılmadığınız bir şeyi yapmanızı söylediğinde istifa mı edersiniz?! İş aramayı gerçekten seviyor olmalısınız çünkü bu oldukça yaygın.

Sorunuz tam bir karmaşa; bu büyük bir çelişki. Ya zaten ürünün içindedir, o zaman yapacak bir şey yoktur. Ya da değildir ve üstesinden gelmeniz gereken teknik sorunlar vardır. Ama ikiside değil. Tekerleği yeniden icat ettiğinizde teknik zorluklarla karşılaşmanız imkansızdır.

Özellik henüz üründe değilse, aşağıdaki şekilde ilerleyin:

Yapmadıysanız yine de yaptınız, endişelerinizi yazılı olarak müdürünüze açıklayın. Bir e-posta yeterli olmalıdır. Endişeleri ve bunları çözmek için üstesinden gelmeniz gereken teknik zorlukları ve mümkünse kaba bir zaman tahminini içermelidir. Nasıl çözeceğinizi bilmediğiniz yerleri açıkça işaretleyin ve ondan yardım isteyin.

Ayrıca ona özelliğin çabaya değip değmediğini sorun ve ona daha önemli özellikler gösterin biriktirme listesinde beklemek. Artık ona bir zaman çerçevesi ("çözülen her şey için 5 hafta ve tamamen çözülmemiş 4 sorun") ve insan gücünüzün olası alternatif kullanımlarını sağladığınıza göre, bilinçli bir karar verebilmelidir.

"Evet, ileri gidin" yanıtını verirse, yapabileceğiniz her şeyi uygulayın ve çözemediğiniz her şeyi iletin . Özelliği istedi ve size sorunları çözmeniz için bir zaman çerçevesi sağladı. Diğer her şey sizin maaş derecenizin üstünde.

Öncelikle, özelliğin varlığı, eğer yoksa, müşteriye iletilmelidir. Sadece uygulandığı için bunun farkında oldukları veya özelliği nasıl kullanacaklarını bildikleri anlamına gelmez. Bu, müdürünüz olabilecek müşteriyle birincil irtibat kişisi olan kişi tarafından yapılmalıdır. Bu özellik hakkında bilgi sahibi olmak, ihtiyaç duydukları tek şey olabilir. Ancak, uygulamanın yararlı olmadığını anlarlarsa, özelliğin uygulanma şeklinin yine de değiştirilmesi gerekir.

Temas noktası yöneticiniz ise ve yöneticiniz bunu gündeme getirdiyse ve müşteri hala değişikliği istiyor veya müdürünüz bunu gündeme getirmek için gerekli hissetmiyorsa, yapabileceğiniz her şeyi yaptınız. Tartışmayı siz yaptınız ve bu tür kararlardan sorumlu kişi tarafından bir karar verildi. Şimdi kararı verme zamanı.

Ancak, kuruluşunuz içinde sorunlar var gibi görünüyor. Kodun zaman içinde azalması alışılmadık bir durum değildir. Teknik borç oluşur ve bir sistemdeki değişiklikler yalnızca tasarım bütünlüğünün bozulmasına ( yazılım entropisi) neden olur. Sonunda, bu sorunların üstesinden gelinmesi gerekir veya yazılım bakımının maliyeti, bir sistemde değişiklik yapmanın son derece maliyetli hale geldiği noktaya kadar yükselebilir. Süreçte kaliteyi test etmek ve geliştirmek için zaman eksikliği de bir sorundur.

Bu kurumsal sorunlar uzun vadeli sorunlardır. Bu bir "kuruluşunuzu değiştirin" durumudur. Ya bu sorunları çözebilir ya da daha uygun olan yeni bir organizasyon görmeye başlayabilirsiniz.

Müşteriye ne yapılması gerektiğine dair bir doğrulama sağlayın. İsteği anladığınızdan emin olmak için bir resim çizin, adım adım talimatlar verin vb. Bu, müşteriye şimdi işlerin nasıl yapıldığını açıklamıyor, işinizi doğru yaptığınızdan emin olmak içindir. Hatta değişikliklerinin size göründüğü kadar basit olduğunu doğrulamak için bunu özelliğin şimdi nasıl çalıştığıyla bile karşılaştırabilirsiniz.

DÜZENLEME:

Müşteriye veya yöneticiye sahip olabilirsiniz bu değişikliği onaylayın. Müdürünüze, müşteriye teslim edildiğinde, değişimin ne kadar küçük olduğunu fark etmesi durumunda "imzalaması" için sunulmasının yardımcı olabileceğini söyleyebilirsiniz. Bununla birlikte, buradaki nokta iletişimdir ve yöneticiniz bunu imzalarsa, en azından iş sizin için açıktır ve istenen şeyi sağladığınız ve çözümü hile yapmadığınız ya da manipüle etmediğini gösteren belgeleriniz var.

DÜZENLEMENİN SONU

Müşterinizin "mevcut" bir özelliği istemesi ve bunun farkında olmaması mümkündür. Müşterinizin bunun daha az adımda / daha az tıklamayla yapılmasına ihtiyaç duyması da mümkün olabilir. "Daha fazla tıklama" nedeniyle kullanıcılar için "kabul edilebilir" olmayan birçok sisteme aşinayım.

Gereksiz değişikliklere karşı kendinizi korumaya çalışmak veya zaten var olan özellikler için müşterilerden ücret almak sizin için iyidir. Bir müşteriyi kendi isteğine göre yargılamak veya aşırı korumacı bir ebeveyn gibi davranmak ve müşterilerin paradan tasarruf etmelerine veya başka bir yol yapmak istediklerinde işleri "kendi yöntemleriyle" yapmalarına yardımcı olmaya çalışmak sizin için iyi değildir.

İşi yapmak istemiyorsanız veya yapamıyorsanız, yöneticiniz bunu bilmelidir. Ama o zaman muhtemelen başka bir iş aramalısın.

Senin için hissediyorum. Her zaman işlevsel gereksinimler olmadan detaylı tasarım elde ediyorum. Mevcut veri tasarımı ve sunucu çağrıları konusunda hiçbir takdirleri yoktur. İki tıklama temiz ve genişletilebilir olabilir ve tek tıklama veri modelinde bir değişikliğe neden olur. Önemsemediklerini söylüyorlar ama bozulduğunda veya veriler bozulduğunda bu sizin sorununuz. Çalıştırsanız bile, kırılgan bir kod tabanınız var ve bir sonraki değişiklik daha da zor. Bir programcının tasarımcı olarak değil de kodlayıcı olarak görülmesi çok sinir bozucu.

Yapabilecekleriniz konusunda. 1) Sorunu açıklayın. 2) Daha sonra itirazınıza hem yazılı hem de sözlü olarak itiraz edin. Bu değişikliğin ve daha uzun vadeli etkinin zamanını belirleyin. 3) Ve sonra sadece yapın. Programlama 3 hafta ve test için 2 hafta sürüyorsa öyle olsun.

İstifa her zaman son seçenektir, ancak bu devam ederse iş daha da kötüye gidecektir. Kod daha kırılgan hale gelecek ve patron anlayamayacak. Bir kod maymunu muamelesi görmesi aşağılayıcı. Bununla birlikte, elinizden gelenin en iyisini yapın ve becerilerinizi geliştirin. Bir sonraki performans incelemenizde hala hayal kırıklığına uğruyorsanız, o zaman planlayın. Belirli bir değişiklikle ilişkili olmayan süreci gündeme getirirseniz, umarım patron konumunuzu daha ciddiye alır. Patron sürecin değişmeyeceğini söylüyorsa, o zaman nerede durduğunuzu bilirsiniz. Bırakma. Onunla yaşayıp yaşayamayacağına karar ver. Onunla yaşayamazsan, bir sonraki işe nasıl geçeceğine dair bir plan yap. Mevcut işi önemsemeyi bıraktığınızda, daha tolere edilebilir hale gelecektir.

Buradaki cevap "açıklama alın!"

Müşteri, özelliğin zaten daha modern bir şekilde var olduğunun farkında mı, yoksa değil mi?

Aksi takdirde ... muhtemelen bundan bahsedilmedikleri için üzülürler ve daha sonra zaten mevcut bir özelliğin işlevselliğini kötüleştirmek için daha fazla saat ödeyeceklerdir . Bu konuda tıklanacağımı biliyorum ... proje müdürüne "X özelliği istiyorum" dediğimde, onun zaten orada olup olmadığını bilmek onların lanet işi ve bunu bana bildirin, böylece proje hakkındaki kararımdan emin olabilirim Ben bilgilendirildim.

Eğer öyleyse ... o zaman müşterinin proje için istediği şeydir. Gereksinimler gereksinimlerdir, nedenleri vardır ve bunları size açıklamak zorunda değildirler. Örneğin, fazladan tıklamanın işleri için bazı tuhaf olumlu şeyler yaptığına dair somut verilere sahip olabilirler ve bunu istiyorlar. Ya da sadece aptal oldukları için bile ... tercih etmeleri halinde aptallıkları için size fazladan ödeme yapma hakkına sahipler. Bu kararı tamamen bilgilendirdikleri ve sizin tarafınızdan aldıkları saatler için ödeme yaptıkları sürece sorun değil.

Sonuç: Bu sadece proje yöneticiniz müşteriyi gerektiği gibi bilgilendirmiyorsa o zaman bu bir sorun. Müşteri, özelliğin daha iyi bir sürümünün zaten mevcut olduğunu bildiği halde gerçekten aptalca bir gereksinim istiyorsa ... o zaman aptal olsa bile bu hala bir müşteri gereksinimidir.

Doğru işlemi yapamazsınız. Hangisinin geçerli olduğunu anlayana kadar ... ya da en azından durumun hangisi olduğunu anlamaya çalışarak biraz çaba harcayın, böylece yöneticinin işini yapmadığı ortaya çıkması ihtimaline karşı poponuz korunur.

İşyeri yığınındaki herkesin etik ve profesyonellik hakkında konuşmasına bayılıyorum, burada yaptığımız şeylerin çoğu ilgi alanlarının ve siyasi oyunların bir sonucu. Buradaki durum oldukça açık ve cevap oldukça kısa:
Müşteri para bağışlamak istiyor (yani, cehaletleri zaten sahip oldukları şeyler için boşa harcamalarına neden oluyor), yöneticinin bununla bir sorunu yok. Bu para maaşınızı öder. O parayı aldığınız için mutlu olun ve müşterinizden daha akıllı olduğunuz için mutlu olun. Kar.