Geliştiricilerin ürün sahiplerine özellik fikirleri önermesi normal midir? [kapalı]


16

Daha önce sistem yöneticisi olarak çalışarak oldukça yakın zamanda geliştirici olarak çalışmaya başladım.

Agile işlevlerini kullanan bir yazılım geliştirme ekibinin "uygulamamız gereken şey" iletişiminin, ürün sahibinden geliştiricilere kadar çoğunlukla tek bir yönde gerçekleştiğine dair anlayışım. Geliştiriciler, teknik borç konusunda ürün sahibine endişelerini ifade edebilirler, ancak özellik fikirleri bulmak ana sorumluluklarından biri olmamalıdır.

Çalıştığım şirketin farklı bir görüşü var. Onlara göre, geliştiriciler sadece özellik fikirleri önermek için kendi ekiplerinin ürün sahiplerine değil, aynı zamanda o ekibin ürününe katkıda bulunacak bir şeyleri olduğunu düşünürlerse diğer ekiplerin ürün sahiplerine de gitmelidir. Fikir, hepimizin büyük bir <şirket adı> Ekibi olduğumuz ve tüm geliştiricilerin uzmanlıklarını, yararlı olacağını düşündükleri özellikleri itmek için kullanmaları gerektiğidir.

Daha iyi bir kelime olmaması nedeniyle böyle bir yaklaşım "normal" midir? Çok pasif miyim, inisiyatif almalı ve fikirleri ürün sahiplerine aktarmaya başlamalı mıyım? Tersine, şirket tamamen yanlış mı yaptı ve başka bir yerde iş aramalı mıyım?


15
Elbette, programcılar genellikle ürün sahibinin hiç duymadığı birçok şeyi biliyorlar. Web geliştirme, hizmetler, apis, herhangi bir miktarda kütüphane ve eklenti ve kullanıcı arayüzü öğeleri var. Sık sık ne yapmak istediklerine dair kaba bir fikirden çok daha fazlasına sahip olmayan müşterilerle çalışıyoruz, ancak bunları uygulamanın ortak yollarının ne olduğu veya hangi ek özelliklerin mümkün olabileceği konusunda hiçbir bilgi sahibi değiliz.
thorsten müller

1
Özellik önermemek için herhangi bir kızgınlık veya olumsuz sonuç hissediyor musunuz? Şirketiniz uygulamayı teşvik etmek ve yapmayanları cezalandırmak istemiyor gibi görünüyor.
JeffO

Çalıştığım iki şirkette bu normal bir süreç. İş adamlarının, geliştiricilerin çözüm / problem çözme becerilerinde ne kadar değerli olduğuna dair bir ipucunun olmadığını fark etmeye başladım. Atlama aynı sorunla karşılaşma olasılığını gemi. Ürün insanlarına yeni bir çözüm varmış gibi çözüm önerileri, yöneticileri yönetme olarak adlandırılır ve iyi çalışır. Tek sorun, fikirleriniz için kredi alamayacağınız, ancak en azından özelliklerinizin uygulandığı anlamına geliyor.
Jason

IMO bu çok iyi bir şey ve çok sağlıklı. Ürün sahipleri işletme alanında uzman olabilirler, ancak mevcut her yeni teknolojinin veya teknik yaklaşımın farkında olmayabilirler. Buna ek olarak, geliştiriciler, doğrudan kodla farklı çalışma perspektifinden gelen sistem hakkında bilgi sahibi olabilirler. Rolü ne olursa olsun, kesinlikle herkesin fikirlerini karşılayan bir şirketle kalmak istersiniz. Bu, sahiplerin clueless olduğu anlamına gelmez, herkesin fikirlerine açık oldukları anlamına gelir.
Ken Liu

Yanıtlar:


2

Özellik fikirleriyle ne demek istediğinize bağlı.

Planlama oyununda, geliştiricilerin yinelemeyle sonuçlanabilecek bir hikaye hakkında girdi sağlaması nadir değildir. Ancak, bu kendi başlarına hikayeler geliştiren geliştiricilerden çok farklı.

Yetişkin sistemlerde, geliştiriciler, bilinen bir sorunu yinelemeye dönüştürebilecek bir yol önerebilir.

Geliştirmeler tamam olabilir, örneğin bir rapor için grafik eklemek, ancak geliştiriciler iyi niyetli yeni hikayeler buluyorlarsa alarm zilleri benim için çalardı. Bunda gerçek bir değer olsaydı, bunun için neden varolan bir uygulanmayan hikaye olmadığını ya da neden geriye dönük olarak hiç gelmediğini soruyorum.


1
Şirketimin felsefesini, geliştiricilerden hikayeler bulmalarını istemek olarak yorumlamıyorum ve bunun gerçekleştiğini hatırlamıyorum. İstediklerini düşündüğüm şey, bir fikir yayıldığında ve bir geliştirici yürütmenin sahipliğini aldıktan sonra, bu fikri sonuna kadar savunmak geliştiricinin sorumluluğundadır.
louniks

1
Yani bir geliştirici bir ürün sahibinin düşünmediği bir fikir düşündüğünde alarm zillerinin çaldığını mı söylüyorsunuz? Neden bu kadar kötü bir şey olsun ki?
Stefan Billiet

1
Fikirleri atmak iyidir - planlama oyununun bir parçası ve parselidir. Yeni bir hikaye olsaydı, bunu sorgulardım. Hikayeler, normalde geliştiricilerin değerlendirmek için normalde en iyi şekilde konumlandırılmayan (alan adı uzmanları olmadıkça) müşteri değeri sağlar. Yinelemede bir şeyin görünüp görünmeyeceği, planlama oyununda hikaye değeri ve geliştirici çabası ile belirlenir. Geliştiricinin hikaye oluşturmaya dahil olması, burada potansiyel bir çıkar çatışmasına neden olabilir. Bu gerçekleşemeyeceği anlamına gelmez - sadece ürün sahibinin onu şampiyona alması gerekir, aksi takdirde köpeği sallayan kuyruktur.
Robbie Dee

47

Birçok geliştiricinin "pasif" olmasının nedeni, koyduğunuz gibi, iyi ürün fikirleri size gelmeden önce belirli bir alan bilgisi ve deneyimi gerektirmesidir. Ama eğer gelirlerse, onları önermemek ve onları savunmak için bir neden yok.

Unutmayın - geliştiriciler, ürün sahipleri, satış elemanları, vb., Hepsi aynı ekipte, aynı hedefle: başarılı bir ürün oluşturmak. Mümkün olduğunca bu hedefe doğru çalışın.


Sanırım çivilenmişsiniz - çok az deneyime sahip olduğum teknolojilerle çalışan bir ekibe indim, bu nedenle proaktif olmak benim için zor. Pasif kaldığım bir öğrenme dönemi olmalı. Daha sonra, teknoloji ile rahat hissetmeye başladığımda, proaktif olmaya başlayabilirim.
louniks

1
@louniks hayır noktayı kaçırıyorsun. Teknoloji önemli değil. Önemli olan iş. İş adamları ne kadar şeffaf? İşletmenin nasıl para kazanmayı planladığını biliyor musunuz? Üzerinde çalıştığınız ürünün şirketteki diğer ürünlere nasıl uyduğunun farkında mısınız? Değilse işvereniniz size haksızlık ediyor. İş planını bilmiyorsanız özellikler öneremezsiniz.
RibaldEddie

3
@RibaldEddie Son bölüme katılmıyorum. Herkes özellikleri önermekte özgür olmalıdır. Yönetim ve ürün sahipleri, özelliğin herhangi bir yere gidip gitmediğini belirlemekte hala özgürdür. Yeterli etki alanı ve teknik bilgiye sahip bir geliştiricinin tamamen orijinal iş planının dışında olan büyük, para kazanma özelliğine sahip olma olasılığını göz ardı etmeyin. Bir ürün sahibi, sınırlı teknik bilgi nedeniyle asla aynı fikre sahip olamaz.
Dan Lyons

1
Kulağa tehlikeli bir durum gibi geliyor: bu, çalıştığınız iş adamlarının ne yaptığını bilmedikleri anlamına geliyor. Bu alanda uzman olmak onların işi. Aksi halde neden oradalar? Ciddi anlamda. Geliştiriciler bu tür bir içgörü sağlıyorsa, geliştiriciler de şirketi yönetebilir. Başka bir şey israftır.
RibaldEddie

Teknik gelişmeler önermek için her zaman ayrıntılı alan bilgisine ihtiyacınız yoktur ...
Robbie Dee

5

Geliştiriciler ve ürün sahipleriyle ilgili konuşmanızla birlikte, bana göre kuruluşunuzdaki özelliklerden sorumlu hiçbir ortağınız yok.

Organizasyonumda, ben o kişiyim. Gereksinim mühendisiyim, iyi özellikler yapmayı ve kullanıcı dostu etkileşim tasarımı ile yüksek kaliteli bir yazılımla sonuçlanan özellikleri seçmeyi öğrenen kişiyim. (Diğer kuruluşlarda aynı işi yapan UX kişidir, bu terime daha aşina olabilirsiniz).

Ve size şunu söyleyebilirim: İyi bir şartname almak zor. Tabii ki, geliştiriciler bunu yapmaktan nefret ediyor. Bu onlar için bir yük - paydaşlar arasındaki güç oyunları ve tembel kullanıcıların zihinsel modelleri hakkında düşünmek için değil, bir yazılım oluşturmak için oradalar. Ama biliyor musun? Ürün sahipleri için de bir yüktür. Yazılımlarının hangi özellikleri içermesi gerektiğini geliştiricilere veya kullanıcılara göre daha iyi bilmiyorlar. Geçerli bir şartname oluşturmak öğrenilmiş bir beceridir ve daha önce hiç öğrenmediyseniz, bu konuda iyi olamazsınız. Elbette, bunu yapabilen birçok geliştirici ve ürün sahibi var, çünkü önceki projelerde yapmak zorundaydılar. Ancak ortalama bir ürün sahibi veya geliştiricisi bununla mücadele eder, çünkü bunu yapmak doğal olarak onların işi değildir. Araba kullanabilen herkes araba tasarlayamaz; benzer şekilde,

Gereksinim mühendisi olmadan yazılım geliştirebilir misiniz? Tabi ki yapabilirsin. Ancak, spesifikasyonun tüm ağırlığını ürün sahibinin omuzlarına koymak adil değildir ve proje sonucu için iyi değildir. Özellikle kendisi için alışılmadık derecede zor bir görevle karşı karşıya olduğu için, başkalarından girdi ve destek almak çok yararlıdır. Eğer böyle bir durumdaysanız, zavallı ürün sahibinize bakmayın ve "bana sizin için ne yapacağımı söyle, seni yapacağım" demeyin, gerçekten neye ihtiyacı olduğunu bilmiyor. Ancak sizinle bir tartışma, düşüncelerini ifade etmesine ve fikirlerini keşfetmesine yardımcı olacaktır.

Proje yapısında herhangi bir gereksinim mühendisi yoksa, başka bir sorun daha vardır: moderatör yoktur. Tüm geliştiriciler teknik tarafta, tüm ürün sahipleri iş tarafında. İki kültür çatıştığında, her iki tarafın diğerini aptal ve mantıksız olarak yargılamasıyla çatışmalar ortaya çıkabilir (çünkü yargılamak için kendi değer sistemini kullanır). Bu nedenle, ürün sahibinizle olası özellikler hakkında konuşun, ancak hak etmediğini düşündüğünüzde bile kibar ve sabırlı olun; projenin başarısı, ikinizin ne kadar iyi geçinebileceğine bağlıdır ve bazen en düşük kararı almak, çatışma nedeniyle hiçbir karar vermekten daha iyidir. Bir hiyerarşi oluşturmak ve ikinizden birine son kelimeyi vermek yararlı olabilir, çünkü bu kilitlenmemiş çatışmaları önler. Eğer son sözü alırsa, haksız olduğunu hissetseniz bile buna erteleyin.

"Pasif" kısım hakkında: fikirleriniz yoksa, sadece etkinlik göstermek için bir şey bulmaya çalışmayın. Ürün sahibi zaten güvensizse ve fikirlerini değerlendirmek için iyi bir kriter bilmiyorsa, garip fikirler “sadece bir şeye sahip olmak” zaten zor bir durumu daha da zorlaştıracaktır. İyi özellik fikirleri ile gelmek sihir değildir, ancak bilgi gerektirir. Ders kitaplarından öğrenmediyseniz, özellikle de beyniniz kalıpları kendisi için ayırmadan önce kullanıcılara veya kullanıcı tarafından oluşturulan kullanılabilirlik verilerine (analitik, memnuniyet ölçümleri) maruz kaldığınız projelerde muhtemelen birkaç yıllık geliştirici deneyimine ihtiyacınız olacaktır. ve fark etmeye başlarsınız: burada çözebileceğimiz bir sorun var. Kullanıcılar bu sayfada bir şey eksik gibi görünüyor, Ne olabilir? O zaman paylaşmak için iyi fikirleriniz olacak.

Sonuç 1: Gereksinim mühendisi olmayan projelerde, sahip olduğunuzda önerilerde bulunmak iyidir. Hassasiyet ve incelikle yapın - iyi fikrinizin tomurcuk içinde sıkıştığı anlamına gelse bile çatışmayı önlemek zorunludur.

Ve bir gereksinim mühendisi olan bir ekipte iseniz?

Ben herkesin özellik fikirleri duymayı seviyorum! Evet, bazen geliştiricilerin fikirleri korkunçtur (kullanıcı arayüzünü programlama mantığını takip etmek istediklerinde). Ürün sahiplerinin fikirleri de genellikle korkunçtur (güneşi ve ayı parayla bütçede istiyorlarsa - oh ve kullanıcının kişisel bilgi sayfalarını en yüksek veri kalitesinde, karşılığında hiçbir şey almadan girmesi gerekiyor). Ama benim işim, takımdaki herkes için iyi bir şartname bulmak. Ve fikriniz asla işe yaramayacak olsa bile, duymak beni bir endişeniz olduğunu fark eder. Önermek için yanlış çözümü seçmiş olabilirsiniz, ancak bu endişenizi daha az geçerli kılmaz. Tespit ederseniz, muhtemelen ele alınması gerekir (veya bunun bir tehdit olmaması için bir neden bulmam gerekir). Şartnameden sorumlu bir gereksinim mühendisiniz varsa, onlara önerilerle gitmekte tereddüt etmeyin. Sizi duymazlarsa, yanlış bir şeyler yapıyorlar ("düşün" ün "kabul" anlamına gelmediğini unutmayın).

Bir gereksinim mühendisi projeyi her paydaşın bakış açısından ayrı ayrı (ve bazen aynı zamanda) izlemek zorundadır. Biz sadece insanız ve sık sık başarısız oluruz. Gerçek bakış açınızı sağlamak için oradaysanız, sahip olduğumuzu düşündüğümüz bakış açısı yerine, girdiniz çok değerlidir.

Burada davranışlarınızda daha özgür olabilirsiniz. Hassasiyet dansı yapmak benim işim. Açıkça saldırgan olmayın, bu işimi engelliyor, ancak daha az özdenetim ve kültürel / iletişim bilincine ihtiyacınız var, çünkü boşluğu kaldırabilirim. Ayrıca, iki çelişkili fikrin olduğu ve kimsenin hangisinin daha iyi olduğuna karar veremediği bir durumda da yüzemezsiniz. Bunu bilmem gerekiyor ve eğer işe yaramazsa, ilmekteki kafam budur.

Sonuç 2: Takımda bir gereksinim mühendisi varsa, ürün özellik önerileri ile onlara gidin. Bu sefer kadife eldivenlere ihtiyacınız yok.

Son olarak, gereksinim mühendisi yoksa, ürün sahibi bunalmış ve fikirler için mücadele ediyorsa, patron sivri bir şekilde size bakıyor ve sunacak hiçbir fikriniz yok mu?

Birkaç seçeneğiniz var. Biri, sizin de belirttiğiniz gibi, bırakmaktır. Tüm kuruluşlar bu şekilde çalışmaz ve bu ortam sizin için uygun değilse daha iyi bir ortam bulun. Uzun vadede sizin için iyi olacak.

Bekleyebilir ve herhangi bir şeyin değişip değişmediğini görebilirsiniz. Bir sonraki proje daha deneyimli bir ürün sahibine (veya daha fazla liderliğe sahip) sahip olabilir. Ama sonsuza dek duramazsın.

Üçüncü seçenek, aslında bazı gereksinim mühendisliğini kendiniz öğrenmektir. Bu, günümüzde çok aranan bir beceridir. Tam zamanlı bir gereksinim mühendisi olduğunuz pozisyonları üstlenmeyi planlamasanız bile, bu beceriye sahip olmak, ekibinizdeki (ve kullanıcılarınız) diğer üyeleri daha iyi anlamanıza ve geliştirmenize izin verdiği için, bir geliştirici olarak değerinizi artırır. geliştirme süreci daha sorunsuz gider. Ve tüm derinliğine girmenize gerek yok. Görevleri, iş akışlarını, zihinsel modelleri ve kullanıcı merkezli veri modellerini açıklayan bir giriş seviyesi ders kitabı, bir işadamları ve geliştiriciler ekibi tarafından tasarlanan bir yazılımda çok sayıda iyileştirme fırsatını belirlemenize izin verecektir. Don' Akademisyenler için referans olarak kullanılan en kalın kitaplara gitme (son zamanlarda Pohl'un İngilizce'ye çevirisi gibi) - bunlar aslında nasıl yapılacağına dair bir açıklama olmadan her küçük adım için olası tüm yöntemlerin bir listesidir. Uygulama odaklı bir şey seçin.

Eğer denemek ve bölgede hiçbir kişisel ilgi olmadığını bulursanız, bu hala iyi. Kendinizi sevmediğiniz bir şey yapmaya zorlamayın. Ama muhtemelen farklı bir ekip yapısına sahip bir organizasyonda iş aramalısınız.

Sonuç 3: Sezgisel bir anlayış elde etmek için yıllarca beklemek yerine, bir ya da iki kitap okuyun;


+1 Bu çok kapsamlı bir cevap. "Sonuçlar" bir iyi olarak çalışır TL;DR.
James Khoury

4

Evet, oldukça normal.

Bilinen% 80 iş var - zamanlarının% 20'sinin sevdikleri bir şeye adadığı google'da% 20 yenilik modeli. Bu şekilde, sadece yeni özellikler değil, tamamen yeni bir ürün ve hizmet alırlar.

Çok pasif miyim, inisiyatif almalı ve fikirleri ürün sahiplerine aktarmaya başlamalı mıyım?

Bu kişiliğinize bağlıdır. Gerçekten tutkulu insanlarla çalıştım, aynı zamanda 8 saatlerini değiştiren ve eve giden duyguları olmayan insanlarla da çalıştım.


Google'da geliştiriciler, zamanlarının bir kısmını bir ürün sahibi olarak geçiriyor gibi görünüyor.
JeffO

Başka bir girişimden bahsetmedikçe kendi projelerinde çalışan Google çalışanları aynı şey değil mi?
Robbie Dee

@RobbieDee Evet, doğru. Projeleri üzerinde çalışıyorlar, ancak google projelerden çıkan hizmetleri satıyor.
BЈовић

Demek istediğim, bu tür projelerin varolan çevik bir proje alanında olması gerekmiyor. Tamamen özerk olabilirler.
Robbie Dee
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.