Bir geliştirici gereksiz veya zararlı özelliklere karşı mı tartışmalı?


32

Yeni özellikleri ve yani kritik olmayan / sorgulanamayan özellikleri tartışırken geliştiricilerin iyi bir tutumu nedir?

Dil gibi bir tür Java geliştirdiğinizi ve patronun dediği gibi: "Geliştiricilerin doğrudan nesne belleğiyle başa çıkabilmeleri için işaretçilere ihtiyacımız var!"

Geliştirici, düşünülemez bir karmaşıklık ve güvenlik açıkları eklediği için fikri aşağı çekmeli mi, yoksa sorulan şeyi mi yapmalı?

Bu iyi bir örnek olmayabilir, fakat iş akışını kesen düğmeler eklemek veya programın iç yapısına ters düşmek gibi gri bir alanda daha fazla olan şeyler hakkında ne düşünüyorsunuz?

Normal bir programcı için en iyi "yapabilecek" ile "yapamayan" dağılım nedir?

EDIT: Soru kötü bir patron hakkında değil: D

İnsanların farkedilir miktarda sorun ekleyen yeni sorunlara nasıl yaklaşırken, belki de marjinal olarak yararlı olurken daha çok ilgilendim.

Genel tutum şöyle olmalı:

  1. evet yapacağız, karmaşıklığı boşver
  2. olabilir
  3. hayır, genel yeniden işleme ve imalar değişikliği haklı çıkarmaz

İyi bir geliştiricinin tepkisi ne olmalı?


1
"mimarlığın ilkesi" - Hangi ilke bu? Bu örnek o kadar kötü ki, sorunuzu çözerdim.
Jeremy

@ Jeremy: Haklısın, ben anadili değilim, sabit.
Coder

1
Herkes, fikir birliğine varılıncaya kadar gereksiz veya zararlı olduğunu düşündüğü özelliklere karşı tartışmalıdır. Bir UX tasarımcısı veya arka uç geliştiricisi veya bunun önemi ne olursa olsun. Özellik tasarımı zor. Hepimiz (müşteriler dahil) bunu emiyoruz, çünkü hepimizin yazılım konusunda çok özel beklentileri var.
back2dos

Yanıtlar:


26

En iyisi bir toplantı yapmak ve artılarını ve eksilerini grup olarak ortaya koymak ve en iyi çözümü tartışmak. Bir ekibiniz varsa, çözüm konusunda hemfikir olmalarını sağlayın. Bir takım bir şeyi kabul ettiğinde, yöneticiler ve "patronlar" çözümle ilgilenme eğilimindedir.

Patronunuz hala aynı fikirde değilse, o zaman yapabileceğiniz her şeyi yaptınız: takımınızı ve yöneticilerinizi bir araya getirdiniz ve artılarını ve eksilerini ele aldınız ve patronunuz potansiyel olarak düşük bir çözüm seçti.

Bunun anahtarı, artıları ve eksileri bir grup olarak tartışmaktır. Bunu yaparak, ekibinizle en iyi çözümün ne olduğunu tartışıyorsunuz ve aynı zamanda patronunuzun kararını (o karar vermeden önce), patronların neden karar verdiğini düşündüğünüzü anlattıktan sonra ortaya çıkacak siyasi bir tepki olmadan işaret ediyorsunuz. yanlış olanıydı.

Bu, çalışma politikalarını içeren hassas bir durumdur, ancak dostça ele alınabilir.


10
Her şeyden önce, patronlarınız zaten güçlü bir fikir oluşturduysa, artıları ve eksileri ortaya koymak yardımcı olmayacak veya ayrıntıları gerçekten bilmeden yön belirlemekten hoşlanan bir insan olacak. Bir pozisyonun arkasında kalmanız ve zaman zaman bunun için tartışmanız gerekebilir. İkincisi, etrafta herkese daha iyi bir fikriniz olduğunu söylerseniz ve sonra haklı olduğunuz ortaya çıkar, muhtemelen patronunuzun dikkatini çeker. Adil değil, ancak performans inceleme zamanında size yardımcı olmasını beklemeyin. Bu cevap, gerçek dünyanın işleyişiyle uyuşmuyor.
PeterAllenWebb

4
Patronunuz, size karşı daha iyi bir çözüm elde edeceğiniz şekilde size karşı koyacak kadar kibarsa, iş arkadaşlarınız için istifa ettiğinizi ve neden olduğunu belirten bir fotokopi ile istifa mektubu yazmalısınız. Bazen fakir yöneticilerin terfi ettiği doğru, ancak alternatif yollara sahip olduğunuzda birinin altında çalışmak sorunu sadece devam ettiriyor.
Jeff Welling,

2
@Jeff Welling Müdürünüzün size karşı size daha iyi bir çözüm bulmasının önemsiz olduğuna katılıyorum, ancak X'e söylediğinize etrafa yaymak aptalca bir şey ama bunun yerine Y yaptıklarını, yetersiz olduklarını ima ederek / dilsiz. Konuşma sizinle müdürünüz arasında olmalı. Herkese “Ona böyle söyledim” diyerek kararlarımı sürekli olarak baltalamaya çalışan bir raporum olsaydı, hiç eğlenmezdim ve bunun beni kötü bir yönetici yapabileceğini düşünmüyorum.
PeterAllenWebb

1
@Jeff Welling Ve ayaklarınızla oylama konusunda size daha fazla katılamamıştım. :) Ve ben bu cevabı orjinalinden daha çok düzenlenmiş haliyle kabul ediyorum, ancak şimdi farklı bir cevap olduğunu düşünüyorum.
PeterAllenWebb

1
@PeterAllenWebb Ne söylediğinizi görüyorum (neye mal olursa olsun cevabı bu tartışmayı tartışmalı kılıyordum), ama bence patronunuz da dahil olmak üzere bir grup olarak, artıları ve eksileri ele alıyorsanız ve patron açıkça daha düşük bir çözüm seçerse , bunun için çağrılmalıdır. Ortak ihtiyaç yöneticilerinin muhalif görüşlerini susturmaları gerektiğini biliyorum, ancak bana göre bu bir yöneticinin yanlış olduğunu kabul etmek istemeyen bir durum gibi görünüyor - herhangi bir IMO yöneticisinde bir kusur .
Jeff Welling,

14

Patronunuz size aptalca işler yapmanızı söylerse, neden aptalca olduğunu (nazikçe) açıklamanız gerekir.

Eğer o kişi anlamadıysa, o zaman aptalca şeyler yapmak zorundasınız. Bu kadar. O patron. Bu durumda ne diyorsa yapabilir, patronuyla konuşabilir veya işini değiştirebilirsiniz.


Patronla ilgili bir sorun yok, buzdağının gizli bir parçası olan özelliklerle ilgili.
Kodlayıcı

3
@Coder: Bu durumda, geliştirme işlemine başlayabilmeniz için önce bu analizin gerekli olacağını yönetime bildirmeniz gerekir.
SinirliFormsDesigner'la

1
Hayal kırıklığına uğramışFormsDesigner ile aynı fikirdeyim. Analiz süresi için bu istek çoğu zaman makuldür ve gerçekte gerekmedikçe arka brülöre itilen bir özellik elde etmek için genellikle yeterlidir.
PeterAllenWebb

9

Patronun teknik olarak mümkün olmasına rağmen , analiz için, tasarımda, mevcut kodu yeniden yazmak, test etmek, regresyon testi yapmak için harcadığı zaman ve harcanan paraya X maliyeti olacağını söyleyebilirim. . Bazen cevap "evet! Biz buna sahip olmalıyız" olur, bazen "hayır sanırım olmaz" olur.

İstenilen özellik, uygulamanın bazı temel ilkelerini ihlal ederse (örneğin "mavi düğme ekle!" Gibi belirtilmiş ve müşterinin isteğine göre yalnızca kırmızı düğmelere sahip olacak şekilde tasarlanmış bir kullanıcı arayüzüne) sormak "neden?" ve önceden belirlenmiş tasarıma aykırı olduğunu belirtin.

Sonunda, hemen hemen her şey bir "yapabilir" dir ( sadece mavi olan bir kullanıcı arayüzüne kırmızı bir düğme eklemek teknik açıdan zor olmayabilir ), bu daha çok "yapmalı mı?" Sorusudur.


Düzenlenmiş sorunuzu cevaplamak için, cevabın daha fazla araştırma ve analiz yapılmasını bekleyen 2 numaralı "Belki" olması gerektiğini düşünüyorum.

1 numaralı "Evet, koşulsuz" cevabını vermek istemezsiniz, çünkü verilen zaman diliminde sunamayacağınız bir şeyi yapmakta zorlanabilirsiniz.

# 3 "Hayır, çok fazla iş" cevabını vermek istemiyorsunuz çünkü o zaman işbirliği yapmıyor ve gereksiz yere zorlanıyorsunuz.


6

Bir geliştiricinin perspektifinden: ASLA kimseye faturalarını ödediklerini istediklerini alamadıklarını söyleme. Bunun yerine, onlara bu fiyat için sahip olamayacaklarını veya tam olarak tasarladıkları şekilde sahip olamayacaklarını söyleyebilirsiniz.

"İşaretçi" örneğinize; Bir yönetilen kod ortamı olan .NET'te işaretçiler bulunur. Yönetilmeyen kodlarla birlikte çalışabilirlik için kritik önemdedirler. Ancak, bunların "güvenli" kullanımı sıkı bir şekilde düzenlenir ve "güvensiz" kodda kullanılırsa, bu kod çalışma zamanında daha yüksek güvenlik izinleri gerektirir. İşaretçilerle doğrudan belleğe erişmeyi de gerektiren yönetilen bir dil geliştiriyorsanız, otomatik olarak mareşal olamayacağınız ve otomatik olarak marşal olamayacağınız salt okunur yönetilen işaretçileri kullanarak, yapabileceğiniz sahnelerin ardında benzer bir marşaling şeması ile karşılaşabilirsiniz. " true "yalnızca kod tabanının en güvenilir bölgelerinde bulunan işaretçiler.

GUI örneklerinize: yeni bir özelliğin mevcut kod akışını "kıracağını" biliyorsanız, bunun için test edebilir ve iş akışı tarafından yapılan önceki işleri geri almak için daha sağlam şekilde geliştirebilirsiniz. Müşterileriniz ve hatta bazen yöneticiniz bile programın yapısına ilişkin hiçbir ipucu veya ilgiye sahip değildir; Eğer programı yapılandırma şekliniz nedeniyle istedikleri bir şey zorsa, tanım gereği yapı yanlıştır çünkü müşterinin istediğini yapmanıza izin vermez.

Her durumda, bu yeni özellik müşterinin düşündüğünün ötesinde gereken işin kapsamını artırabilir. Bunun için ya programın uzatılması, daha fazla para ve / veya planlanan diğer çalışmaların azaltılması gerekecek.

Bununla birlikte, aynı temel sonucu daha kolay ya da daha mantıklı bir şekilde elde etmenin bir yolunu biliyorsanız, müşteriye önerilebilir. Kesinlikle var olmalarına rağmen, neyse ki, kategorik olarak, geliştiricilerin girdilerini dinlemeyi reddeden bir müşteriyi görmedim, özellikle tek işi, ihtiyaç duyulan çeşitli detaylar üzerinde gelişmeye açık olan “ürün sahibi” olan Çevik bir ortamda. bunlar.


Bu çok iyi bir cevap. Ne yazık ki, bazı özelliklerin kabul edilmesinin güvenli olmayan kodlara yol açtığını gördüm - "hata denetimi yok", "köşe kılıfları kullanılmıyor", vb. onlar için ödemek için.
Kodlayıcı

3
Tamamen aynı fikirde değilim. İhtiyaç duydukları şey yerine insanlara istediklerini veren bir geliştirici (veya ihtiyaç duydukları şeyi elde etmelerinin zararına), korkunç bir geliştiricidir.
David Schwartz

2
@David Schwartz - Neye ihtiyaç duyduklarını ve ne istediklerini belirlemeye çalışan ince bir çizgi var. Müşterinize bir şeylerinin olmadığını söyleyemezsiniz, çünkü kesinlikle çevrede kodlanabilecek bir soruna neden olabilir.
Ramhound

10
100 üzerinden 99 kez, her zaman belirtilen bir WANT arkasında İHTİYACI VAR. WANT'ın tam olarak karşılanmadığı halde, bu İHTİYACI her zaman bulup karşılamalısınız. Üstelik, ASLA onlara GERÇEKLEŞTİRECEKLERİN ne yapılmadıklarını söyleyemezsiniz, çünkü onlara GERÇEKLERİ gerekenleri veremeyeceğinizi duyacaklar. Size sağlaması için iyi para ödüyorlar ve bu da sizi kolayca kolayca kesebilir ve şifreyi, istediklerini, mektuba tam olarak vereceklerini başkasına verebilir ve bu işlevsellik ile ilgili herhangi bir sorunu suçlarlar. .
KeithS

2
@KeithS: Kesinlikle! Benden daha iyi söylediğin için teşekkür ederim.
David Schwartz

5

Büyük uygulamaları programlamak için uzun yıllar harcıyorsanız ve yol boyunca eleştirel düşünürseniz, bir özelliğin faydalarından ağır basan sorunlara neden olacağı konusunda ince ayarlanmış bir anlayış geliştireceksiniz. Bunun için bir başka kelime de bilgeliktir ve tıpkı diğer bilgelik türlerinde olduğu gibi, değerlerini görmeden yapmak zor olabilir.

Diğer posterler, problemli bir özellik tarafından ortaya çıkacak problemin maliyetini ölçmeye çalışmanız gerektiğini ve bunun mümkün olduğunda iyi bir fikir olduğunu, ancak genellikle mümkün olmadığını savundu. Genellikle hemen uygulama maliyetlerini tahmin etmek mümkündür. Bu bile daha büyük özellikler için genellikle zordur. Gelecekteki maliyetlere gelince, zor bir durumdasınız. Başka hangi özelliklerin gerekli olacağını veya ürünün ne kadar süre bakım altında kalacağını kesin olarak bilmiyorsunuz. Maliyet genellikle, gerçeklere dayanan bir tahminde bulunacağınızdan çok daha yüksek olacaktır.

Geçmişte göstermiş olduğunuz yetenek ne kadar fazlaysa, bir özelliği kötü bir fikir olarak açıklamanız gerekecek. Bu sadece zamanla ve kanıtlanmış bir başarı kaydıyla gelebilir. Bununla birlikte, müşterinizin istediği şey olduğu için isteği yerine getirmek için her zaman istekliliğinizi ifade etmeniz gerekir. Tecrübelerinize dayanarak çekinceleri ifade etmelisiniz ve bir kez yaptıktan sonra, bu olayların% 90'ında sorun olmaz, çünkü sorunun köküne inen bir sohbet başlatacaksınız. Bu özellik ilk etapta? Bu noktada alternatifler sunabilir veya belki de istenen özellik sorun çıkarsa da, bunun hala gerekli olduğunu kabul edersiniz.

Tabii ki yanılıyor olmanız da mümkün. Yazılım mühendisliği eğlenceli değil mi?


3

Soru oldukça belirsiz olduğu için, cevabımı biraz gözden geçireceğim.

Her zaman onları sorgulayın, ama akıl yürütmelerini dinleyin. Bazen insanlar sadece bir özelliğin uygulanabilirliğini veya ne kadar zaman alacağının programlanmasını unuturlar. Kapak tarafında, bazen verimli olma / fırfırlama / vb olma programcı zihniyetine kilitleniriz ve bir proje için gerekli olmayan şeylerin gerçekten müşteri için olmadığını unuturuz.

İyi bir nedenleri varsa, uygulama sırasında ne kadar süre alabileceklerini ve uygulama sırasında karşılaşacağınız tüm olası tümsekleri ve bu programa devam etmek isteyip istemediklerini görmelerini sağlayın. Aksi takdirde, bunun neden iyi bir fikir olduğunu düşünmediğinizi belirtin ve tepkilerinin ne olduğunu görün. Durulayın ve tekrarlayın.


2

Çoğu zaten söylendi, ancak mevcut çalışma ortamımda vurgulayacağım bir şey var. Diğer şirketler için yüklenici olan bir şirket için çalışıyorum ve başvurular iş süreciyle ilgili (satışları ve müşteri iletişimini sağladıkları adil bir miktarda).

Ürünle birlikte verilen iş süreçleri (en azından şirket yeterince büyükse) çok karmaşık olabilir. Belirli bir dereceye kadar, eğer karmaşık bir şeyi modelliyorsanız, ortaya çıkan uygulama ilişkili bir karmaşıklığa sahip olacaktır. İş adamlarının çoğu, sürecin sadece bir kısmını görüyorsa, tüm başvuru / süreç, sadece bir kullanıcının görebildiğinden daha büyük bir karmaşıklığa dayanıyor.

Demek istediğim şu ki, yeni bir iş gereksinimi ortaya çıktığında, iş adamları için işe yarayacak, çünkü karmaşıklığı çok daha yükseğe yükseltmiyor, ancak tüm sistem üzerinde daha büyük bir etkisi olabilir. Kanımca bu değişime karşı çıkmak için bir sebep değil. Çabaları (ve harcamaları) müşteriyle tartışmak doğru bir noktadır. Muhtemelen müşterinin bu özelliği oluşturmasını engellemeyecek, ancak zaman içinde uygulamalar ve "uuh, sen bu kadar pahalı!" çok daha az seçici olacak.

Karşılaştırılabilir bir durumda olup olmadığınızı bilmiyorum, ancak paydaşın durumunun mutlaka bilişim sistemi geliştiricilerinin ve mimarlarının karşılaştığı gibi yakın bir zamanda aynı karmaşıklığa neden olmadığını öğrendim. Bu durumda iletişim her iki tarafa da yardımcı olur.


2

Afedersiniz, ama bu soru küçük bir babadan yardım istemek gibi görünüyor. Bu durumda, iyi geliştiricinin şu emirleri benimsemesi gerekir:

  • Kendine sadık kal. Bağırsaklarınız bir özellikten rahatsızlık duyuyorsa, endişelerinizi duyulabilir bir şekilde dile getirin. Şanslar takımın yeni bir açılış beklemesi iyi.
  • Tecrübeyi, tecrübe edilen kişinin kuralları ile değiştirmeye çalışmayın. Senin için her durum farklı, her özellik yeni. Bu yaşlıların sahip olmadıkları bir artı.
  • Yazılım geliştirme kesin bir bilim değildir, asla olmayacak. Bu nedenle, bilgeliği biriktirin, davranışı değil.
  • Yenilgiyi kabul et. Eğer takım başka bir şekilde anlaşırsa, endişelerinizi ve reklamlarınızı tekrar etmeyin.
  • Olumlu düşün. Eğer fikir gerçekten 'onu vurmak' için yalvarıyorsa, eksikliklerini listelemeden önce olumlu yönleri bulmaya ve adlandırmaya çalışın.
  • İnsanlarla nasıl etkileşime gireceğini öğrenin. Biz geliştiricileri sık sık sosyal yetkinlik üzerine teknik bilgi yerleştiririz. Teknik yetenekler hayatın başlarında zirve yapar, ancak sosyal yeterlilik emekliliğe kadar büyümeye devam edebilir.

2

Kötü şartların geri itilmesine inanıyorum. Ama aynı zamanda, neden kötü olduklarını ve hala onları istediklerini açıklamak için elinizden geleni yaptığınıza, o zaman hemfikir olduğunuzu ve işinizi yaptığınıza inanıyorum.

Örneğin, uygulamanın zaten yaptığı bir şeyi karşılıklı olarak dışlayan gereksinimler isteyen insanlara sahibim. Bunu yaparsam, o zaman bu% 100 garantili, kırılacak. Bu yüzden gereksinimi geri gönderiyorum ve onlara bunun zaten yürürlükte olduğumuz diğer iş kurallarını bozacağını ve bu kuralı değiştirmek istediklerini mi söylüyorum? Genelde, belirli bir gereksinimle karşılaşan küçük grup, uygulamanın geri kalanının neler yapabileceğinin büyük resmine erişemez. Bunlardan birini geri gönderdiğimde, müşteri intial kuralının daha kritik olduğunu fark etti ve istedikleri değişimin buna değmediğine karar verdi. Değişikliği yapmaya karar verdiklerinde, ilk şartı zorlayan kişilere danıştıktan sonra bunu yaptılar.

Bazen sadece netleştirme soruları sormak, konunun sandıkları kadar basit olmadığını görmelerini sağlar. Bazen neden bir şey istediklerini sormak ve değişime neden olan asıl ihtiyaca ulaşmak istersiniz. Bunu bir kez anladığınızda, geliştirici olarak sizin için çalışan ve gereksinimlerini karşılayan alternatif bir çözüm görmek daha kolaydır. Bu çözümü, gerekliliklerini normal öneriden daha iyi karşılayacak şekilde sunabilirseniz, değişikliğinizin kabul edilme ihtimalini büyük ölçüde artırdınız.

Bazen bir değişiklik tasarımınızdaki temel düzeyde hasara yol açacaksa, onlara sadece değişikliklerin harcayacağı saatlerin yeni tahmininin verilmesi, kapatılması için yeterlidir. Bunu, hangi kritik işlevselliklerin onlara yeni hatalar getirebileceğini belirten bir risk değerlendirmesiyle birleştirirseniz, 3 kişinin 6 haftaya ayırdığı çabayı göstereceğini ve birdenbire artık çok önemli olmadığını söyledi.

Ama bazen onlara bunun iyi bir fikir olmadığını ve neden “Çok ihtiyaç duyduğumuza çok kötü” diyorlar. Biraz kazanırsın, biraz kaybedersin ve bazen iş ihtiyaçları gerçekten değişir ve uygulama buna uymalıdır. Karar bir kez kesinleştikten sonra, artık ne yaptığınızı sorgulamanın zamanı geldi ve bunu yapmanın vakti geldi. İtirazlarınızı belgelemişseniz, bütçenizi aşarak yeni ve daha heyecan verici hatalara neden olduğunda kişisel olarak hala iyi bir yerde olmalısınız. Üstelik bir dahaki sefere bu tür şeylerin tam olarak doğru olduğuna dair bir kayıt yaptığınızda bile sizi daha fazla dinlemeye istekli olabilirler.

Bu tartışmaların çoğunu kazanmanın anahtarı (hiç kimse kazanmaz) ilk olarak neden bahsettiğinizi bilmek için bir kayıt oluşturmak. Daha sonra, neyin endişelendiğini belirten yazılı bir belge gönderin (birçok yönetici risk açısından olumsuzdur, birisinin daha sonra yanlış olduğunu kanıtlayan bir belgeye sahip olmasını istememe olasılığı daha yüksektir, bu nedenle yazdıklarınıza daha fazla dikkat ederler) ve sonunda Değişikliği yapmanın tüm masraflarını (yalnızca saatler değil, güvenlik riskleri, yeni hatalar, eksik tarihler vb. getirerek) anlamalarını sağlamak. Değişim özgür değildir ve bunu anlamaları gerekir. Bir sonraki anahtar bunu bir yetişkin gibi yapmak ve sızlanan bir çocuk gibi değil yapmaktır ("ama kullanmak istemiyorum ... çünkü hoşuma gitmiyor"). Bunu yapmadığınız için bir iş davası yapın ve kötü bir şartı geri çekmede çok daha fazlasını elde edersiniz.


1

Sizi doğru okursam, asıl soru bilinmeyen karmaşıklıkla ilgilidir. Başlangıçta sorunuzu "Aşırı karmaşıklık ihtimalinin çok yüksek olduğunu düşünüyorum ama patron değil" diyorsunuz. Ancak patronun bir sorun olmadığını söylüyorsunuz. kabul edilemez bir karmaşıklık ekleyerek vardır.

Bu durumda, bir çeşit risk azaltma stratejisi öneririm. API’nize WCF / web servisleri eklemeyi düşündüğünüz, ödünsüz olarak harika veya çok karmaşık bir görüntü olabilir:

  • özelliği bir dalda ekleyin. Eğer işe yararsa, birleştir. Fareler yuvasına dönerse, onu öldürün.
  • yeni bir sayfalık bir proje başlatmak ve kavramın bir kanıtı yapmak. Kısa sürede bir kavram kanıtı yapamıyorsanız, o zaman bırakın. Eğer kavramın kanıtı işe yararsa, onu büyütün ve onunla bütünleştirin
  • Bu özellik veya teknoloji hakkında bilgi sahibi olan insanlar için web'i araştırın. Çok fazla zorlanmanın olduğu yerde, bir teknoloji aşırı karmaşıklık için bazı gerçek riskler olabilir. Java Beans ve COM + muhtemelen, eskidir, ancak karmaşıklığı gerçekten arttıran ve denklemin faydaları tarafında sağlanmış olabilecek veya olamayacak özelliklerin iyi örnekleridir.

1

Tartışma hayır. Muhtemelen evet tartışın. Ancak, spekülasyona ilave olarak değerlendirilmeli ve diğer özelliklerle önceliklendirilmelidir. Talebin makul olmayan bir süre ve uygulanacak karmaşıklık katacağını biliyorsanız, bunu önceden belirtin. Talebi yerine getirmeye karşı değil, uygulamanın ne yapacağını düşündüğünüz bir açıklama gibi.

İsteğe çok bağlı. İşaretçi uygulaması, bütün bir projeyi etkileyecek kadar büyüktür, bu nedenle, eğer bir seçenek verilirse, değerleri tartılmalıdır.

Akışı kıran bir düğmeye basmak. Form düğmenin isteğe bağlı olabileceği şekilde oluşturulabilirse, belki de büyük bir anlaşma değil. Aslında bunu çok yaptım. Düğmeyi ekledim ancak elden önce düğmenin isteğe bağlı olduğu konusunda yeterince bilgi topladım. Orada olmasını bekleyen kullanıcılar onu kullandı ve farkına varanlar sadece gereksizdi.

Her şey denge ve savaşları ne zaman alacağınızı bilmekle ilgili. Bazı şeyleri, uygulamamanın sosyal yönleriyle uğraşmak yerine yine de uygulamak kolaydır.


1

Gördüğüm sorun, argüman kelimesini kullanımınız.

Tasarım konularını ve bunların arkasındaki mantığı ortaya çıkarmalısınız, ancak dikkatli olun, çünkü programcılar, aldıkları pozisyonlar konusunda savunmaya eğilimlidirler ve sadece tartışma uğruna noktaları tartışırlar (Bazen). Kendimi biraz tartışmaktan alıkoymam gerekiyor - ve her zaman başarılı olamam. Ayrıca yaşlandıkça eskisinden daha sık yanlış olduğumu görüyorum - ya da daha kötüsü yanlış olduğumu ne kadar sık ​​tanıdığımı bilmiyordum :)

Gereklilikleri açıkça belirtmişseniz (dil güvenli olmalıdır, eski rutinlere erişmek için işaretçilere ihtiyacımız var), o zaman iki gereksinimin nasıl çakıştığını ve hangisinin daha önemli olduğunu sorabilirsiniz. Gereksinimlere ve bunların arkasındaki nedenlere sahip olduğunuzda, her iki gereksinimi de destekleyen tamamen farklı bir çözüm bulabileceksiniz (JNI - tür).

Olmazsa, belki de onları kodlamanın zamanı geldi!


1
  1. Her şeyi bilmediğinizi ve her şeyi yapamayacağınızı fark edin.

  2. Bunun kötü bir fikir olduğundan eminseniz, kötü olanı söyleyin.

  3. Sizi itmeye çalışırlarsa, ya da söyleyin - Analiz etmek için daha fazla zamana ihtiyacınız var, daha fazla zamana ihtiyacınız varsa veya bu soruna iyi bir çözüm bulamadığımızı söyleyin.

  4. Eğer hala kötü fikri uygulamakta ısrar ediyorlarsa, nedenleriniz de dahil olmak üzere bu konuda tavsiye ettiğiniz onlardan bir onay alın. Hatta bir kopyası ile birlikte tartışmayı özetleyen bir e-postayı yöneticinize gönderebilirsiniz. Bu, daha sonra bir ** kurtarabilir.


0

İdeal bir senaryoda, teknik açıdan son kararları veren bir Lider Geliştirici ve işletme tarafında son kararları veren bir İş Liderine sahip olacaksınız. Bu iki ana soruya cevap verecektir:

1 Ne? Müşteri ne istiyor?

2) Nasıl? Bunu teknoloji açısından nasıl başarabiliriz?

Müşterinin istediği şey, faturayı ödeyenlerin olduğu gibi nihai karar vericiydi.


0

Bir geliştirici olarak, hangi gereksinimlerin uygulanması istendiği ile ilgilenmemelisiniz.

Ancak, bir şeyin gerçekçi olup olmadığını ve daha iyi yollar olup olmadığını açıklamalısınız.


Bu benim önceki işimde ("gerçekten umursamaması gereken") olduğum türden bir geliştirici. Bir projeyi gerçekten önemsiyorsanız, çok daha iyisini yapabileceğinizi düşünüyorum, bu durumda proje yöneticisinin kendisi için programcı olmadığı için kötü bir şeyin olmasına izin vermezsiniz.
Attila O.

@Attila Yanlış anladınız. "Proje
yürütmemek

0

Bazen gerçek müşteri talebi (müşteri iç politikadan geliyor). Sonra umutsuz ve yapılması gereken (ancak yönetim aynı zamanda böyle bir projeye devam edip etmeyeceğini veya fiyat konusunda pazarlık yapıp yapmamalarını da düşünmeli.)


0

Bu benim için neredeyse günlük bir iş, ve aslında, sevindim.

Belli bir gerekliliğin başvurunun bir parçası olması gerekip gerekmediği konusunda fikrinizi değiştirecek değişikliğe sahipseniz, teknik olmayan kişiler sizin teknik bilginizi doldurmanızı bekler (örneğin, “işaretçiler kullanmak uygulamayı dengesiz hale getirir” veya “ X amaçlı bir GET parametresi güvenlik riskidir "). Teknik elemanlar, aklınıza gelmeyen bazı özel avantajlar veya dezavantajlar hakkındaki görüşlerinizi de takdir edecektir.

Tabii ki, herkes X özelliğini istiyor ve sonunda "iyi olmayabilir" derken zor, ama sonuçta herkes güvenli, sağlam ve istikrarlı bir uygulama (çabuk, esnek, vb.) Yapmaya çalışıyor. ) ve her ses sayılmalı.

Sorunuza cevap vermek, bir geliştiricinin işinin bir parçası değildir (ki bu geliştirmek için), ancak kalite ve ekip çalışması sunan bir "ekstra" dır.


0

Bunu yapmanın eksilerini (karmaşıklık, kullanılabilirlik eksikliği vb.) Anlama pozisyonundaysanız, o zaman yeteneğinizin en iyisini açıklamanız herkesin yararınadır. Genellikle geliştiriciler, yeni özellikler eklemenin sorunlarını anlamıyor. Onlar için kolay, çünkü hiçbir şey yapmak zorunda değil, hatta düşünmek zorunda kalmıyorlar.

Ancak, yeni özelliğin ekleneceğine karar verecek güçler varsa, mümkün olan en iyi işi yapmalısınız. Bu bir meydan okuma.

Ve eğer yeni özellik çok aptalsa veya çalışma ortamı çok berbatsa, başka bir iş bulma zamanı.

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.