İyi bir proje lideri veya patronu ile ne zaman karşılaşılmalı

Proje başımız bir dahi yazılım mimarı, genel olarak nazik ve düşünceli biri, doğası gereği bir inek ve sesiyle hassas. Ancak zaman zaman biz (takım arkadaşlarım ve ben) liderimizle özellikle yazılım mimarisi sorunları, sistem tasarımı sorunları, kullanıcı arayüzü sorunları vb.

Düşüncelerdeki farklılığı ne zaman ve nasıl (eğer hiç)?

Patronunun yanlış olduğunu düşündüğünü varsayalım. Üç seçeneğin var

• Ne diyorsa yap ve aptalca bir şey yaptığını düşünerek hayal kırıklığına uğradın - çok iyi değil
• salak olduğunu söyle - ya görmezden gelir ya da iletişim sorunları yaşarsın - sana hiçbir şey almaz ya da seni incitir.
• Ona önerdiği fikirler hakkında özel endişeleriniz olduğunu ve bu endişeleri açıkladığını söyleyin - herhangi bir iyi patron pozisyonunu açıklar ve ardından iş için iyi bir karara varabilirsiniz. Onun fikrinin sizinkinden daha iyi olduğunu ve çok önemli bir şeyi görmezden geldiğinizi göreceksiniz.

Her zaman sonucu düşünün. Çoğu durumda, doğru olma uğruna haklı olmak istemezsiniz, sadece iyi bir iş yapmanız gerekir. Üçüncü seçenek bunu başarmaya yardımcı olur.

Ona aynı şekilde davranın - muhalifleri dile getirirken nazikçe ve saygıyla.

Profesyonel olmak, meslektaşlarınıza ve üstlerinize saygılı olmak anlamına gelir, bu aynı fikirde olmayacağınız anlamına gelmez, sadece kibar ve doğada saygılı olması gerektiği anlamına gelir.

Ekibimin yönlerim hakkında bir şüphe veya muhalif görüşü olduğunda, hem kendim hem de ekip üyelerim için ona eğitim fırsatı olarak bakıyorum.

Bu eski ya agresif ya da pasif yanıltmaya örnek değil midir?

Klasik üçüncü seçenek, yapıcı eleştiriye ve kibar anlaşmazlıklara izin veren atılganlıktır .

Aynı derecede önemli - yapıcı eleştiriyi kabul etmek (zorunlu olarak kabul etmeden) ve makul anlaşmazlıkların kabul edilmesi (kimin doğru, kimin yanlış olduğu konusunda bir saplantının olmaması).

http://en.wikipedia.org/wiki/Assertiveness

Ve günün sonunda, üstünüze erteleyen bir çeşit pasiflik her zaman gerekli olacaktır. Karar için nihai sorumluluğa sahip olan o - yetenek, yetki ve sorumluluk aynı şey değil, ama en azından birlikte gitmeleri gerekiyor .

BTW - Robert Bolton tarafından "İnsan Becerileri" böyle şeyler için iyi (ve oldukça ucuz) bir kitaptır - dinleme becerileri, atılganlık ve daha fazlası.

http://www.amazon.com/People-Skills-Yourself-Resolve-Conflicts/dp/067162248X

Ona saygı duyuyor görünüyorsun ve akıllı biri gibi gözüküyor, neden ona şu şekilde sormuyorsun:

"Yöntem / yöntem / mimari x sorununu nasıl ele alıyor?" Olmazsa, şöyle bir şey söyleyin: "Peki bu şekilde yapmaya ne dersiniz, bu şekilde x sorunu ele alınır?"

Bu yolla, zaten "x problemi" hakkında düşünüp düşünmediğini ve bir şeyler öğrenip öğrenmediğini öğrenebilirsiniz. Ya da o düşünmediyse düşünecek ve belki çözümünüzü kullanacak ya da başka bir tane düşünecek (belki birlikte çalışacaksınız).

Keşke daha somut bir örnek bulabilsem, ama fikri anlayabilmelisin.

İlk başta patronunuza gidecek bir şey elde edeceğinizi sanmıyorum, özellikle de programcı değilse veya böyle bir şeyse.

Ve yolunun kötü olduğunu söylememe gerek yok, ancak bazı durumları nasıl ele aldığını sorarak, bir sorunu fark edebileceğini ya da neden bir sorun olmadığını size söyleyebilir.

Umarım bu yardımcı olur.

CONFRONT kelimesini kullanarak, soruna doğru zihniyetle yaklaşmadığınızı gösterirsiniz.

Bu bir çatışma değil. Bu düşmanca değil. Öfkeli ya da kızgın değil. Farklı yaklaşımların ve maliyetlerin ve faydaların bir tartışması.

Yanan altı silahla içeri girmeyin. Ona düşündüğün bir şey söyle. "Ya böyle yapsak?" Kim bilir, onu ikna edebilirsin.

Ve eğer bilmiyorsanız - ve bazen olmaz - hatırlamıyorsunuz, bilmediğiniz şeyleri, bütçeleri, programları, gereksinimleri, diğer öncelikleri vb. İyi bildiğini unutmayın. Sadece seninle aynı fikirde olmadığı için aptal olması gerekmez.

Herhangi bir karardan veya belirli bir tasarım / yazılım mimarisinden şüphe etmek yanlış değildir. İlk işinize yeni başladığınız sürece, bu durumda zamanın% 99'u yanlış olacaksınız çünkü daha büyük resmin bazı bölümleri eksik .

Siz (ve / veya takım) görüşlerinize göre farklılık gösterdiğinde, proje liderine tartışmak için vakti olup olmadığını sorun, hatta belki küçük bir toplantı planlayın (15-30 dakika). Düşüncelerinizi saygılı bir şekilde yayınlayın ve kararını neden verdiğini dinle. Onu nasıl tanımladığınızı görürsem, tartışmaktan ve sorunla ilgili görüşlerini paylaşmaktan mutluluk duyacaktır. "Çünkü ben öyle söyledim" demez (bu insanlar ne yazık ki var olur). Bu durumda, işinizi sürdürmek ya da havalandırmak ve başka bir iş için ayrılmak istiyorsanız mutsuz olacağınız için kendi fikrinizi yok sayın.

İyi bir tartışma birkaç şekilde sonuçlanabilir:

• Proje lideri, çözümünüzü sorunu çözmenin daha iyi bir yolu olarak kabul edecektir (ve belki de henüz fazla tecrübesi olmayan yeni bir teknoloji, desen öğrendi).
• Siz ve takım resmin daha büyük bir bölümünü görürsünüz ya da neden bu şekilde yapmanız gerektiğini iyi bir şekilde açıklayabilirsiniz. Yeni bir şey öğrenecek ve ilk çözümün doğru olduğunu anlayacaksınız ya da belki de yeni bilgilerle geliştirmenin bir yolunu bulmaya başlayacaksınız (bir noktada hemfikir olmalısınız).
• Tartışma yardımcı olmuyor ve hala aynı fikirde değilsiniz. Onu emip çözümünü uygulayın (çünkü büyük olasılıkla daha fazla deneyime sahip olacaktır) veya ayrılın.

Her neyse, bunu öğrenmek için bir fırsat olarak görmelisiniz ve uygar ve saygılı tuttuğunuz sürece, bu tartışmalarla ilgili büyük deneyimleriniz olacaktır.

Sadece getirin!

Yapabileceğim en sivil ve net şekilde, tipik olarak "Bu yönden endişeliyim, bu potansiyel sorun hakkındaki düşünceleriniz neler?" Diyeceğim.

Beni eğitmek için topu mahkemeye koyacağım.

Olgun bir geliştirici ve yöneticinin 1 numaralı işareti, yanlış olduklarını kabul edebilmeleridir. Öncelikle patronunuza, hepinizin hatalı olduğunuzda yanıldığınızı kabul etmeye istekli olduğunuzu ve patronunuzun aynı nezaketten onlardan beklediğinizi açıkça gösterdiğini gösterin.

Eğer iyi bir patronunuz varsa (ve öyle diyorsunuz), bu genellikle hiç sorun olmaz! Yapıcı bir tartışma yapabileceğinizi ve hepiniz için en iyi çözüme ulaşabileceğinizi göreceksiniz.

Dikkat etmeniz gereken bir şey: önerilen tasarımdan şüphe etmek için çoğu zaman asıl teknik, sağlam temelli nedenlere sahip olduğunuzdan emin olun. "Yanlış hissettiriyor" genellikle yeterli değil ve yapıcı bir tartışmaya katkıda bulunmayacak. Bu çok sık gerçekleşirse, patronunuzun “tartışma” yı kısa devre yapmaktan başka bir seçeneği olmayacak (gerçek-aydınlık, bu yüzden gerçekten bir tartışma değil) ve “üzgünüm beyler” diyebilirsiniz. Başka bir fikrin neden açıkça daha iyi olduğunu gösteren gerçeklerle göster. "

Bu yüzden patronunuz patrondur - geliştiricilerin zor bulduğu kararları vermek için.

Bence ve genel olarak patronumla nasıl davrandığımı düşünüyorum:

Her zaman fikrinizi verin ve konu sıcakken en kısa sürede yapın. İdeal olarak, cesaretinizi topladığınızda ve kararlarınızı çoktan verdikten sonra yapmak yerine, yeni bir konu veya proje konusunda titizlik gösterdiğiniz zaman.

Düşüncelerinizi, endişelerinizi, meselelerinizi açıkça önermeli ve bu şekilde yapılması gerektiğini empoze etmekten ziyade öneri veya endişe kaynağı olarak ortaya çıkmalarını sağlamalısınız.

Bundan alışkanlık edin ve daha iyi bir iletişimci, ekip üyesi ve daha iyi bir ekip olun. İyi bir ekip, olumsuz şeyler hakkında açıkça olumlu şeyler hakkında konuşacaktır. İyi bir takım lideri, ekibini dinler ve verilen bilgileri dikkate alarak karar verir.

İyi şanslar.

Tanımladığınız kadar iyi bir mimar ise, endişelerinizin mantıklı ve özel nedenleriyle ona sadece eğitimli bir şekilde yaklaşın.

Zamanınız / kaynaklarınız varsa, haklı olduğunuzu kanıtlayacak senaryolar üzerinde bazı testler yapmaya çalışın, yanınızda bazı veriler olması çok büyük bir artı.

Onunla bir kez konuştuğunda sadece şunları yapabilir:

a) Sizinle aynı fikirde: Problem çözüldü!

b) Onları reddet ve nedenini açıkla: belki de sonuçta sen yanlış olan sensin.

c) Onları sebepsiz olarak reddetmek: mantıksız davranıyorsa ve tamamen eminseniz, endişenizi projeye karşı sorumlu olarak belirtin, bu durumda gerçekten soğuk verilere ihtiyacınız var ve eğer mümkünse ekibin diğer üyelerinin desteğini alın. Mimarı çok mutlu etmeyecek, ama yapılacak etik şey (bir bina tasarladığını ve yapıdaki bir kusur gördüğünü hayal et ...)

Sorum şu: Görüşlerdeki farklılıkları ne zaman ve nasıl (ister?

Kesinlikle evet cevap. Kontrolden çıkmış nadir bir durum yoksa, nadirTürbülans ve hatta işini kaybetme ihtimalinin çok büyük olduğu durumlarda durum yoksa, farklı görüşleriniz olduğunda başkalarıyla yüzleşmelisiniz.

Buradaki asıl anahtar, Ne Zaman ve Nasıl.

1. “Ne Zaman”: Her ortam farklı ancak bazı yerlerde haftalık toplantı veya açık / yuvarlak masa tartışmaları yapılıyor; burada bazı konular bu konu için uygun bir ortam haline geliyor. Yapmak istemediğiniz asıl şey, sizin aşağı yukarı bakıyorsunuz ya da sadece 1 ya da 2 kişi arasında olan bazı kişisel tasarım argümanlarını kamuoyuna açıklamak ya da kamuya açmak. Meydan okuduğun insanlar, meydan okunduğunu ve belki de halktan utandığını takdir etmeyecekler. Bu durumlar için, düşüncelerinizi ayrıntılandırmak için söz konusu kişi (ler) ile 1'i 1'de bir toplantı planlamaya çalışın.

2. “Nasıl”: Kıdemli bir kişiye gidecekseniz, düşüncelerinizi desteklerken tüm ördeklerinizin üst üste olduğundan emin olun. "Tüm web formları durdurulmalı ve MVC yapmalıyız!" Diyen üst düzey bir insan ofisine giremezsiniz. "Neden?" Ve “Eh, herkes böyle yapıyor ve tüm dergilerde öyle” diyorsunuz, çok ileri gitmeyecek. İleri geri tartışmaya hazırlıklı olun ve mimarlık, kodlama, tasarım, en iyi uygulamalar vb. Hakkındaki düşüncelerinizi haklı çıkarma hakkında sorular sorulmasını isteyin. de yardım. Buradaki önemli şey, bir ego savaşına girmemek veya duyguların yükselmesine izin vermemektir.

Sonunda sağlam, haklı ve mantıklı önerileriniz varsa o zaman dikkate alınmalıdır. Bununla birlikte, bu dünyada kendisinden başkasını dinlemek istemeyen sadece mantıksız bazı insanlar olduğuna da hazırlıklı olun. Umarım bu tür bir kişiliğe sahip bir köşeye dönmezsiniz.

İyi şanslar!

Hata yapmadan ve onlar hakkında sorgulanmadan nasıl mükemmel bir yazılım mimarı olacağınızdan emin değilim. Daha önce bu durumda olduğunu varsaymanın güvenli olduğunu düşünüyorum.

Akıllı, olgun, profesyonel insanlar daha iyi fikirlerin cazibesine uzun süre dayanamazlar. İlk başta fikirlerini sorgulayarak üzülse bile, sonunda gelmeli ve buna saygı duyacaksınız. O ne olgun ne de profesyonel olursa daha büyük bir problemin var ve belki de bunun üzerinde bir ışık parlar.

Profesyonel bir mimar ise, ikinci bir görüşe saygı duyacak ve kabul edecektir. Bununla birlikte, her durumda, alternatifi gerçeklere / uzmanlığa dayanarak hazırlamanız ve iyi bir şekilde sunmanız gerekir. Ayrıca, mimarlıkla ilgili olarak bu tür konular için temelde iki farklı olasılık bulunduğunu da unutmayın:

1. Bir yaklaşım / tasarım matematik 2 + 2 = 4'teki gibi beş değil de basitçe doğru veya yanlış olabilir. Yanlış olması durumunda, gerçek itirazlara dayanarak en kısa sürede doğru çözümü bulmanız gerekir.
2. Bugüne kadar sistem tasarımındaki en konu başlıkları münhasır olmayan olası yaklaşımlardır. Seçmek, deneyime, lezzet, önyargı, genel tabloya vb. Bağlı olarak seçilmesi gereken başka alternatifler de var. Ancak, akılda tutulması gereken, tartışmalar için dönemler ve uygulama için dönemler vardır, çevik programlarda bu aşamalar iyi tanımlanmıştır.