Ben menajerim. İş ilişkilerini ve programcılarla iletişimi nasıl geliştirebilirim? [kapalı]

Önce küçük bir arka plan. Orta ölçekli bir şirketin proje yöneticisiyim. Bir CS uzmanı olarak başladım ve programlamaya biraz maruz kaldım, ancak birkaç ay sonra yolum olmadığını biliyordum, bu yüzden yönetime geçtim. Bu iyi bir karar olduğunu kanıtladı ve mezun olduktan sonra çeşitli firmalarda (şimdi 5 yıl) yazılım yönetiminde çalıştım.

Son zamanlarda çok acı veren bir projemiz vardı. En kötüsünün en kötüsüydü, hem bizim tarafımızda hem de müşteri tarafında birçok hatalar vardı ve sadece zarar vermeden sona erdi. Biri, üst düzey geliştiricilerimizden birinin bizimle aramızda çıkan bir tartışmadan sonra şirketten ayrıldığı noktaya kadar yükselen birçok sinir bozucu duruma yol açmıştır (yönetim). Bu benim için kırmızı bir bayraktı: Çok yanlış bir şey yaptım. (kayıt için, argüman birkaç hatalı zaman tahminiyle ilgiliydi)

Cevap için pek çok yer aradım ve bir arkadaşım bu siteye beni işaret etti. Burada yönetimle ilgili hayal kırıklıklarıyla ilgili birçok soru var. Genel olarak kötü deneyimlerin "davadaki adamlara" karşı genel bir isteksizlik yarattığını anlayabiliyorum.

Ben takım elbiseli o adamım. Öyle görünmeyebilir, ama tek istediğim başarılı bir proje ve sınırlı kaynaklarla acı verici kararlar alıyor. Bu benim işim. Bahsedilen kıdemli geliştiricinin şikayet ettiği şeylerden biri iş ekipmanıydı. Açıkçası, sahip olduğumuz bilgisayarların çalışmaya uygun olmadığı hakkında hiçbir fikrim yoktu. Bundan sonra birçok programcıya sordum ve genel görüş birliği daha iyi makinelere ihtiyacımız olduğu idi. O zamandan beri bunu düzelttim, ancak açıkçası ben ve programcılar arasında büyük bir iletişim boşluğu vardı. En parlak geliştiricilerden bazıları en utangaç ve sessiz insanlardır. Bunu biliyorum ve görüşme sırasında hiçbir zaman sorun olmadı. İnsanlar farklıdır ve farklı alanlarda güçlü yanları vardır.

Güçsüz PC'lerin durumu, bir iletişim sorunu olduğunu düşünmeme yol açan birçok kişiden sadece biri. Korkutucu ve tekrarlayıcı olmadan programcılar ile iletişimi nasıl geliştirebilirim?

Umduğum şey, insanların iyi şeyler hakkında şikayet etmemeleridir. Eğer iş yerinizi seviyorsanız ve (ya da en azından :)) menajerinizi seviyorsanız , lütfen bana onlardan bahsedin. Ne doğru yapıyorlar? Benzer şekilde, ondan nefret ediyorsanız, lütfen nedenini ayrıntılı olarak açıklayın. İletişimi geliştirmekle ilgili cevaplar arıyorum çünkü bunun benim sorunum olduğunu düşünüyorum ama yanılıyor olabilirim.

Vaov! Sorduğunuz için teşekkürler. Teknik olarak, senin gibi, sanırım ben yönetim yapıyorum, çünkü ekiplerle iletişim kurmak ve liderlik yapmak için kod yazmaktan çok daha fazla zaman harcıyorum ... ama işte yönetici ufkunun her iki ucundan da benim isteğim. Bir geliştirici veya başka bir yönetici için çalışan bir yönetici olun, yönetimim ile iletişimimde yardımcı olacak bazı şeyler:

• Neden? bu çok önemli bir sorudur - hemen hemen her gerçek cevabın arkasında “neden” vardır ve “neden” de asıl sorudan daha önemli olabilir. Bunun için birkaç teğet var:
  • Geliştirici Neden - Geliştiricilerin yönetime kesinlikle bir anlam ifade etmeyen birçok cevabı olacaktır. Kesinlikle yaptım ve yönetime girme yollarımdan biri, yönetimin anlayabileceği bağlamda "neden" ekiplerini açıklamakta gerçekten iyi olmaktı. Elinizde "meraklılar için konuşmacı" yoksa, daha sık anlaşılan metaforlarda neden soruya verdiklerini cevaplayarak geek konuşmayı öğrenebilirsiniz. Neler olup bittiğini anlayana ve kabul edene kadar devam edin.
  • Yönetim Neden- "Neden" in senin kadar önemli. Neden zaman tahminlerine ihtiyacınız var? Onları ne için kullanıyorsun? Çok yüksek veya çok düşük bir şirket olarak ne kadar berbat olacağız? Bu, bir yönetici olarak sizin muhtemelen merak ettiğiniz içgörülerle ilgili şeylerdir, ancak bunların hepsi geliştirici için vudu. İşin püf noktası, geliştirici sormayabilir. Yönetim ondan bir şey istedi ve doğru, zamanında ve düşünceli olmak için elinden gelenin en iyisini yapacak - ama eğer "neden" ini bilmiyorsa, yapmamasını istediğin şekilde optimize edebilir. Nedenini söyle ve aynı şeyi yapmasını isteyin - cevabı kendi terimleriyle tekrar yazın.

Özellikle zaman tahminleri hakkında - Bir ton yapmak zorunda kaldım ve geliştirme ekibime kesinlikle "Ben buna ihtiyacım var çünkü maaşlarımızı ödemek için daha fazla para isteyeceğim, bana söylediklerinize güveneceğim" Sayılarınızı kullanacağım ... bu, eğer bana düşük gelirseniz, hepimiz mahvolmuş olacağız çünkü ikinci kez para isteyemeyeceğim - önerdiğimiz şeyle birlikte yaşamak zorunda kalacağız ". Bu bağlamda, geliştiriciler, gerçek beklenti ayarına çok daha yakın olan yüksek tahminlere ne kadar güven verici ve parlak olduklarını göstermeye çalışan düşük tahminlerden değişti.

• Kimse yanlış değil - "Neden" sorusu bir sonuç ile uzun sürer - "Neden" diye sormak yerine "Bu çok çirkin! Olmaz!" konuşmanın akmasını sağlar. Bazen, bir şeylere ne sorulduğu ile sorucunun ne sorduğu arasında ciddi bir kopukluk olabilir. En iyi yönetim cevaplarımdan çok şaşırdı ve şaşırdıklarında şaşkınlıkla yanıp sönmeye başladılar ve “neden böyle söylüyorsunuz?” Diye sordular. (Hemen) - "değiştirmen gerekiyor" demiyorlar. Rekabetçi bir hedefe ulaşmak için teklifler üzerindeki sayıları azalttım, ancak yalnızca sahneyi nasıl değiştirebileceğimizi ve soru için farklı bir bağlam yaratabileceğimizi konuştuktan sonra.

• ortam gürültüsünü, sözcük seçimini ve kelimeler arasındaki boşluğu dinleyin - İşte kendimi kullanmaktan hoşlandığım ve çaldığım bir sürü şey:

  • Çalışma alanında takılın, kendiniz için üretken bir şey yapın (geliştirici işine girmeyin, geliştirici olmadığınızı bilirler) ve sadece dinleyin. Takım problemleri nasıl çözer? Büyük problemleri neler? Doğrudan sizi ya da yönetimleri genel değerlendirmelerine dair gerçek sıskaları asla duymayacaksınız, ancak sorunlu alanların nerede olduğu hakkında gerçekten iyi bir fikir edinebilirsiniz. Üretken bir şey yaptığınızdan emin olun. Kimse casusluktan hoşlanmaz, ancak moral o kadar düşük değilse, herkesin tahliyesi dışında yanlarında olamazsınız, yakınlıktaki verimlilik tolere edilebilir olmalıdır.
  • sözcük seçimlerini araştırın - genellikle sözcüklerin kendisi kadar önemlidir. Özellikle olumlu veya olumsuz kelimeler kullandığımda, yönetimim sık sık bana aşina olmadıkları bir durum olduğunda neden bu kelimeleri seçtiğimi soruyor.
  • duraklamalar, boşluklar ve beden dili arayın. Kendinizle geliştiriciler arasında bir güç mesafesi varsa (ve olduğu gibi geliyorsa) sizinle çelişmek ya da yüzleşmek istemeyebilirler. Ancak "hey, yanılıyorsun" deme temel içgüdüsü genellikle bir yerde kendini gösterir.

• mümkün olduğu kadar çok iletişim aracısı açın - şahsen, telefonda, e-postayla, anlık mesajlaşarak sohbet etmeye hazır olun - iletişim akışını sağlayacak her şey ve her şey. İnsanlar çok çeşitlidir, sadece bir numara işe yaramaz. Ve geliştiricinin değil, çok formatlı iletişimci olmanın yöneticinin işi olduğunu görüyorum.

• Sizinle konuşmanın faydası olun Birisi size bir sorun ve belki de olası bir çözüm hakkında bilgi verirse, o sizin yöneticiniz olduğunuzu kabul etmeli ve muhtemelen kabul etmelidir ve bunun için farklı bir çözüm lehine karar verebilir veya hiç çözüm bulamazsınız çünkü sorun olduğunu düşünüyorum. Ancak üçüncü kez geçtikten sonra bu gerçekleşir, özellikle de açıklama yapılmadan gerçekleşirse, insanların% 99'u size bir şey söylemekten vazgeçecektir.

Ve işte benim için inanılmaz derecede zor olan, ancak yapabildiğimde harika çalıştı - içe dönükler ve dışa dönüklükler arasındaki farkın farkında olun . Muhtemel bir dışa dönük olmanızdır - işte bu yüzden işiniz iyi görünüyordu ve bir geliştirme pozisyonu gelmedi. Geliştiriciler, çoğunlukla, içe dönük olanlar. "İç içe geçme", "iletişim kuramayacağı" anlamına gelmez, ancak kalıplarının, işlemlerinin ve hızlarının önemli ölçüde farklı olduğu ve sürekli olarak iletişim kurma dürtüsünün neredeyse olmadığı anlamına gelir. İçsel düşüncelerin ortaya çıkmasına izin vermek için zaman içinde ve sessiz (ancak birleştirilmiş) alanı planlayın. İç içe geçmiş arkadaşlarımın birçoğu beni sadece "5 dakika susmam" için beklediklerini söylüyorlar, böylece bir araya gelip cevap verebilirler. İşte'5 şey dışadönükçüler , Nerd Mağarası'nda Repose'daki içe dönükler ve Rand'lar hakkında bilmelidir - özellikle içe dönükler için neyin harika olduğuna dair geliştirici bir örnek . Rands, bu arada oldukça harika. Kendisi bir inek, bu yüzden tarzınıza uygun değilse geliştirici odağından geliyor, ancak sizin tarzınız olmasa da eğlenceli olabilir ve takım gelişimi hakkında gerçekten iyi fikirleri var.

Sanırım favori yöneticilerim hakkında sevdiğim 1 numaralı şey şuydu:

• proje konusunda benim kadar derinden bağlı ve heyecanlandılar (eğer daha fazla değilse)

• Geri döndüklerine dair hiçbir şüphem yoktu - bir sonraki otorite seviyesindeyken (veya akranlarımın) asla keçi keçesi olamayacağından eminim. Başarısızlık olsaydı her zaman bir grup başarısızlığı olurdu.

• O zamanki becerilerime uygun ve anlamlı bir şeyin mülkiyeti verildi, ancak yeteneklerimi genişletmek ve işi yapmak için yeterli kaynağa sahip oldum.

• beni hem bir birey olarak hem de ekibin bir parçası olarak gördüler - güçlü ve zayıf yönlerimi bilmek ve güçlü yönlerimi oynamama ve zayıf yönlerimi arttırmama yardım etmek için çalışıyorlardı.

• kişisel hedeflerimin farkındaydı ve ellerinden geldiğince onları dahil etmekle ilgilendiler

• beni mutlu ederken açık sözlüydüler, öncelik olamazlardı. “Bu tür bir işten nefret ettiğini biliyorum, ama bunu yapmana ihtiyacım var - işte sonsuza dek böyle olmayacak…”.

• Büyük resmi açıklamak için her zaman bir haftada bir zaman (belki de anında)

• sürekli bir geri bildirim ve statüye yakındı; parmakla işaret etmiyor, bireysel işler için çok fazla tanınıyordu.

• her zaman gerçek oldu. Bir şey hassas olsaydı ve tartışılamazsa, boş olduğunu söylediler. Eğer bir şey belirsiz ise, bir güven seviyesi verdiler.

İlk önce kolay olan kısım: Görevinizde teknik bir kırmızı bayrak var: "Hatalı tahminler" derken bahsettiğinizde titremiyorum - bu bir tahmin, bu bir tahmin değil , MISTAKEN olamaz . Biraz kapalı olabilir, çok fazla olabilir, bu yüzden tahmin olarak adlandırılır. Müjde olarak tahminler alıyorsanız, bu sizin "geliştiricilerinizin" tarzınızla ilgili yaşadığı en temel sorunlardan biri olacak.

Ancak,% 100 geliştiricilerle iletişim kurmanın zorluğu konusunda size katılıyorum. Birkaç yıl önce bir proje yönetimi eğitiminde bir geliştirici olarak vahiy aldım. Açık bir tartışma ortamı yaratıldıktan sonra geliştiricilerin çoğunun kesinlikle yönetime karşı korktuğunu gördüm (burada yönetim vardı). Yanlış olan her şey yöneticilerin geliştiricilerin gözünde hatasıydı. Toplayıcı, yönetimin o gün ortaya çıkan büyük sorunların neredeyse tümü hakkında hiçbir fikri olmadığıydı. Geliştiriciler, yönetimin onu kaçıramayacağının çok açık olduğunu varsayıyordu ve yönetim, geliştiricilerin ihtiyaç duyduklarını onlara söyleyeceğini varsayıyordu.

Bu nedenle, IMHO cevabın ilk kısmı, geliştiricilerinize psişik olmadığınızı ve aslında teknik tarafa geldiğinde muhtemelen düpedüz aptal olduğunuzu bildirmek olmalıdır. Zamanında size gelmeleri için onlara güveniyor, güveniyor ve güveniyorsunuz. Hayatlarını kolaylaştırmak için oradasın, zor değil.

Ve ne yaparsanız yapın, onlara cevabını bilmek istemediğiniz sorular sormayınız - yukarıdaki "yanlış tahminlere" atıfta bulununuz ;-). Bu bir geliştiricinin kriptoniti.

Burada çok iyi şeyler var ama şunu söylemeliyim sanırım .. .. sert olmak için üzgünüm .. Ama bunun söylenmesi gerekiyor:

• Başbakan olarak 5 yıl ve bir geliştiricinin ne tür bir PC'ye ihtiyacı olduğunu bilmemek çok çirkindir.
• Bir geliştiricinin ilk gerçek kırmızı bayrakınız olarak kötü çalışma koşulları nedeniyle istifa etmesi delilik.

Benim sahip olduğumun , bir iletişim sorunundan çok , bir Güven sorunu olduğunu düşünüyorum . Kimse neyin yanlış olduğunu söylemez çünkü bu bilgilerle ne yapacağınıza güvenmezler ve hatta onlara karşı kullanılacağından bile korkabilirler. Bütün bu meseleleri size söyleyen dev böyle yaptı çünkü bunu yapmanın bir sonucu olmadı, istifa etti.

Şahsen ben onun geçmişinde bazı gelişim deneyimi olmayan bir Başbakan asla işe almazdım. Bir sonraki projenizde, zamanınızın küçük bir bölümünü Dev'in bir parçası olarak ayırmanız gerektiğini düşünüyorum . Takım . Haftanın 8 saati, takım lideri olarak Jr geliştiricisi olarak çalışarak söyleyin.

Bu, gözlerinizi bir geliştirme ekibinin dinamiğine açacaktır, çünkü şu anda, o ekibin bir parçası bile değilsiniz, siz bir yabancısınız. İşini bırakmanın sana bir şok gelmesi gerçeğini kanıtlıyor. Takımdaki herkes mutsuz olduğunu biliyordu. Ve bunlardan biri size söylemedi:

"Bir şey yapmazsan en iyi adamımızı kaybedeceğiz"

Bu kırmızı bayrak # 2 olmalı.

Bir yönetici olarak , kaizen hakkında bir şeyler duyduğuna eminim , Toyota Production System'ın ilkelerinden biri, sürekli gelişim anlamına geliyor .

Bir sorunun olduğunu kabul ettin, bu harika bir başlangıç.

Kaizen beş ana unsurdan oluşur:

• Kalite Çemberleri : Bir şirketin faaliyet gösterdiği tüm yönleriyle ilgili kalite seviyelerini tartışmak için toplanan gruplar.

• İyileştirilmiş Moral : İşgücü arasında güçlü bir moral, uzun vadeli verimlilik ve üretkenlik elde etmek için çok önemli bir adımdır ve kaizen, çalışanların moraliyle sürekli iletişimde kalmanın temel bir görevidir.

• Takım çalışması : Güçlü bir şirket, her adımda bir araya gelen bir şirkettir. Kaizen, çalışanların ve yönetimin kendilerini rakiplerden çok bir ekibin üyeleri olarak görmelerine yardımcı olmayı amaçlamaktadır.

• Kişisel Disiplin : Bir takım, ekibin her üyesi kendi içinde güçlü olmadan başarılı olamaz. Her bir çalışan tarafından kişisel disipline bağlılık, ekibin güçlü kalmasını sağlar.

• İyileştirme Önerileri : Ekibin her bir üyesinden geri bildirim talep ederek, yönetim, tüm sorunların önemli hale gelmeden önce ele alınmasını ve ele alınmasını sağlar.

( Kaynak )

Buna uzun süre bakarsanız, bu unsurların üzerinde bir sabit olmak ekip çalışmasına ve geri bildirime vurgu yapar.

Bir örnek, zaman tahminleri üzerinde bir tartışma olduğunu söylemiştin Bu zaman tahminlerinden siz mi sorumlusunuz? Bunun hakkında takımla konuşur musun? Üzgünüm ama yöneticilerin sadece bir numara çıkardıklarını gördüm. Çok önemli bir şey: Asla pazarlık etmeyin, ekibinizin size verdiği tahmini. Birçok yönetici, eğer ekipleri daha fazla çalışırsa daha kısa sürelere ulaşabilirlerse hayal ederler. Bu bir yalan. Dokuz kadının bir ayda bebeği olamaz, hatırla.

Öyleyse ilk tavsiyem:

Dinle : takıma basit bir e-posta ile başlayın: "Geliştirme ekibinin yönetime yönetim performansı hakkında geri bildirim vermesinin en iyi yolu nedir?". Ekip ile yineleyin ve fikir birliğini uygulayın. Görevin ekibin sürüleri değil harika yazılım geliştirmelerini sağlamak. Bunu aklında tut.

Dürüstlük ve Sadakat : Bir şey sorduğunuzda kimse cevap vermezse, bunun nedeni, dinleyeceğinize inanmadıkları ya da en kötüsü, onları bunun için ceza vereceğinize inanmalarıdır. Dürüst ol. Biri emdiğini söylerse, bunu geri bildirim olarak al ve intikam alma. Sebeplerini anlayın, geliştirin.

Ve en sonunda, burada bazı eleştiriler görmeme rağmen, Efsanevi Adam Ayı: Yazılım Mühendisliği Üzerine Denemeler adlı bir kitabı okumanızı tavsiye ederim . Kitap, OS / 360'ın gelişimini yönetirken IBM'deki Fred Brooks deneyimi hakkında. Burada ve burada bazı şeyler olabilir, ancak karmaşık yazılımın gelişim sürecinin nasıl çalıştığını anlamak için başlangıç ​​adımıdır. S.Lott, özellikle merak etmediğim Çevik Manifestosu'na atıfta bulunuyor, ancak okumaya değer.

Oku bunu:

http://agilemanifesto.org/

• Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

• Kapsamlı dokümantasyon üzerinde çalışan yazılım

• Sözleşme müzakere konusunda müşteri işbirliği

• Bir planı takip etmeyi değiştirmeye cevap vermek

Çoğu durumda, kuruluş (yani patronunuz) sizden

• “ölüm yürüyüşüne” yol açan mantıklı bir sonuca varılması için açıkça kırılmış bir süreci takip edin. Bu da argümanlara ve istifalara yol açar.

• aşırı, düşük değerli, kullanılmayan belgeler yaratın.

• karmaşık değişim kontrolü a / k / a sözleşmesi müzakeresi yapmak. Her kullanıcı değişikliği, değişikliği "kalite" ve "önceliklendirmek" için ayrıntılı bir ritüel gerektirir. Gerçekten, hepsi “donma” ile ilgilidir - değişimi önlüyor.

• sonuçları ne olursa olsun planı takip edin. Bazı kuruluşlar zamanında (hatta işe yaramaz) yazılımın teslim edilmesine değer verir. İş sorununun çözümü değil, değerli olan plan budur.

Mesele sizin kişisel iletişim becerileriniz olmayabilir.

Tüm gelişim "çevre" veya "metodoloji" nin ölümcül bir şekilde kırılması ve kötü duygular genel kötü uygulamaların sadece bir belirtisi olabilir.

Bana göre bu, devlerle hiç kolay bir atmosferde konuşmadığınız gibi geliyor. Onlarla görüşmeleriniz yalnızca resmi nitelikte miydi? Bu çok kötü.

Neden onları kişisel olarak tanımıyorsunuz ve böylece şirket, işyeri ve projeleri hakkında neyin iyi ve neyin kötü olduğunu biliyorsunuz? Çalışmalarına içten ilgi ve takdir göstererek, onlara saygı gösterin ve saygılarını kazanın.

Size güvenirlerse ve rehin teklifleri olmaktan korkmazlarsa, size muhtemelen çekici olmayan gerçekler söyleyecektir.

Ben bir Takım Lideriyim ve ekibim bana güveniyor. Onları korurum. Bütün suçu ben alıyorum ve şöhreti onlarla paylaşıyorum. Yönetimimiz beni koruyor. Bu morali arttırır. Gerçekten zor bir projemiz ve neredeyse kötü bir müşterimiz vardı, bitirmesi neredeyse imkansızdı ama sonunda yaptık, çünkü her şeyi çok açık ve net bir şekilde konuşuyoruz.

Alkışla! Alkışla! Alkışla! Kesinlikle iyi bir insan olmalısın, çünkü işinde daha iyi olmak için neler yapılabileceğini görmek için açıklığa kavuştun.

Lütfen harika bir menajerde tanık olduğum şeyleri aşağıda bulabilirsiniz ve takımı kıdemli bir üye olarak yönettiğimde şahsen benimsedim.

• M, yönetmekten daha çok şey ifade ediyor.
• Bir llow ekip üyeleri düşüncelerini ve kaygılarını dile getirmek. Bütün kulaklara kulak ol. Yapıcı olanları alın.
• Hiçbir zaman bölücü siyaset oynayarak ekip üyelerine ihanet etmeyin. Bu daha erken ve sessizce geri ateşlenir.
• Bir nger değil. Ekibiniz ile birlikteyken, yüzünüze asla yüzünüze dokunmayın; Bu gerçekten zor.
• G, iyi ve açık bir şekilde kazandığından dolayı açıkça ve açıkça takdir eder. Aynı genişlikte, çok yumuşak ve taktiksel olarak, herhangi bir yanlışlık yapılmayan işi, sorumlu olan kişiyi, yalıtılmış ve açık olmayan bir şekilde eleştirir.
• E her bireyde ncourage mülkiyet ve liderlik. Bu, kişinin moralini ve bağlılığını arttırır, çünkü saygı duymuş hissedecektir.
• R Arada bir ekibinizle etrafında Oam. Bu, ekip üyeleri içindeki bağı arttırır / arttırır.

İçten çaba içinde size iyi şanslar diliyorum :)

Genel olarak, siperlerdeki adamlar, tutuşlarının durumları düzeltebilecek ve çözecek kişiler tarafından duyulmadığını hissedince kendilerini mutsuz hissetmeye başlarlar. Şirketteki duruşlarını riske atmadan kavrayabileceklerini bile hissetmiyorlarsa, bu daha da kötü.

Ben bir Teori-Y tür biriyim ve çoğu "bilgi işçileri" olma eğilimindedir; Bir şans verildiğinde işimizi seviyoruz ve iyi yapmak istiyoruz. Bununla birlikte, bir Teori-Y işyerinin dezavantajı, bir sorunun olduğu hemen anlaşılmayacağıdır, çünkü iyi yapmak isteyen ve böylece dalgalar yapmak istemeyen insanlar, bu sorunun etrafında yol bulabilir veya basitçe görmezden gelirler. Bu, sonunda tüm ekibin yüzünde patlayan bastırılmış hayal kırıklığına yol açar. Bir Theory-X yöneticisi tarafından işletilen bir dükkanda muhtemelen daha önce şikayet eden adamlar olacaktır; çalışanlar sadece para için var, bu yüzden iş normalden daha fazla emerse, yakınlar.

Yapabileceklerinize gelince, odadaki yaşlılar ve liderlerin olduğu bir ortamda, işi yapanlar, sizin en iyi varlığınızdır. Onlarla konuş. Müşteri adaylarının size projenin gününe ilişkin güncellemeler ve hava kaygıları verdiği haftada 30 dakika programlayabilirsiniz ve onlara iş tarafında güncellemeler verir ve kaygıları gidermek için onlarla birlikte planlama yaparsınız. Takımı ciddi şekilde etkileyen sorunlar haline gelmeden önce.

Agile'de, her "sprint" veya "yinelemenin" (genellikle bir ila üç hafta süren bir geliştirme çalışması birimidir) sonunda, en küçük üyelerden başbakana kadar olan tüm ekip "retrospektifine sahiptir. ". Neyi yaptıklarına, neyin doğru gittiğine, neyin olmadığına ve yapmaya devam edecekleri ve değişecekleri şeylere tekrar bakıyorlar. Birkaç format var ve kendinizinkini icat edebilirsiniz, ancak retroun sonucu, insanların seslerinin duyulduğunu hissetmeleri ve sonuçların değişeceği şeklinde olmalı.

Çevik hakkında konuşmak; ilk işim küçük bir şirketti ve "küçük" derken demek istediğim, bütün firma softball takımı kuramazdı. Başladığımda dört programcı vardı ve bu ayrılmadan önce ikiye düştü. Şirket kurucusu, Başkanı, CEO ve% 95 hissedarı bir demir yumrukla karar verdi ve organizasyonda tek planlama kaynağı oldu, yani fazla bir şey yoktu. Patron bir işkolikti ve herkesin de olmasını bekliyordu; Vermek zorunda olduğunuz her şey beklentisinden az ya da çok fazlaydı ve bunun için on yıl boyunca kendisi için çalışan insanlara giriş düzeyinde bir maaş verdi.

O şirketten ayrıldım ve işleri çok farklı yapan başka bir firma için çalışmaya başladım; SCRUM Agile temel metodolojisini günlük standup'lar, çift programlama, sprint takımları ve retrospektiflerle uyguladılar. Her sprintin başlangıcındaki iki haftada bir gün, sonraki iki haftanın çalışmasını planlamaktan başka bir şey yapmadık. Başka bir günün büyük bir bölümü için, hiçbir şey yapmadık, neler yaptığımıza ve takım olarak gelişmenin yollarını aradık. Yanımda oturan, Microsoft MVP'leri olan, işimi yapan ve yaptığım şeyi cesaretlendiren ve tamamlayan geliştiriciler vardı.

Gece. Ve. Gün. Ana fark? İlk olarak, proje için kendimi öldürmem beklendiği gibi hissetmedim; Çevik'in temel ilkeleri, sürdürülebilir kalkınmanın hızıdır. İkincisi, işimi nasıl yapmam gerektiğine karar vermekte bir sesim vardı. İşi yapmak zorunda kaldım, ancak bir sonraki sprintte çıkacağımı umduğum şeyin "mide ekşimesi" olsaydı, bu görüşü seslendirebilirdim ve duyulur ve ağırlık verilirdi. Daha iyi bir yol olduğunu hissedersem, bunu söyleyebilirdim ve eğlenceliydi.

Çözüm bulma ve sorunları çözme konusunda, yukarıdan aşağıya çalışıyormuş gibi görünmemek için dikkatli olmalısınız. Bilgisayarlar için; RMR’nizin (tekrar eden aylık gelir) yalnızca şirketin iki bilgisayarı iki haftada bir yükseltmesine izin verdiğini söyleyin. İlk dört bilgisayar, liderlere ve yaşlılara gitmemelidir; en yavaş bilgisayarlara sahip insanlara gitmelidirler. Takıma bonus verirseniz, onları sadece "mümkün olmayan kimselerimiz olmadan" değerli yaşlılarımız ve liderlerimiz için vermeyin; Dev ekibinizde HERKES, bunu gerçekleştirdi. Bir çocuğun bir şikayeti varsa, onu duyun; Sadece küçük olduğu için hiçbir şey bilmediği anlamına gelmez.

İlişkilerin iyileştirilmesi:
Zor bir proje mi oldu? Daha sonra onlara bir mola verin. Gevşemek için tatil zamanı, nefeslerini alın.
Kodlayıcılar haklar bildirimi Bu şeyler verilmiştir. Söylemeden devam etmesi gereken temel şeyler. Bunları ihlal ederseniz, kod tuşlarınızı kötüye kullanıyorsunuzdur.
Joel testi çoğuyla aynı fikirdeyim. Fakat bazıları gerçekten bağımlı. Bazılarını kaçırıyorsanız, muhtemelen programcılarınız için hayatı zorlaştırıyorsunuz, o zaman olması gerekiyor.
Teknik borç . Böylece tamamlanması için zorlayabilirsiniz, ancak köşeleri keserek daha sonra düzeltmek için daha fazla zaman alacağınız teknik borcu doğurduğunuzu anlamalısınız. Bu tarih projenin bitiminden ÖNCE ortaya çıkarsa, gerçekten batırdınız.
RSA animasyonu: MotivasyonBu, bilgi çalışanlarını nasıl motive edeceğini gösteren harika bir parça.
İstediklerini kodlamak için ücretsiz gün. RSA videosundan. Adı hatırlamıyorum, ancak bahsettiği şirketin sitelerinde kısa bir açıklaması var. Bana iyi bir fikir gibi geliyor. Çoğu dükkanda herkesin yakalandığını bildiği şeyler var, ama kimsenin tamir etmeye vakti yok ve bu yüksek bir öncelik değil. Bu, teknik borçlarla baş etmelerini sağlar. Aynı zamanda onların parlak fikirlerini göstermelerini sağlar.

Ve tanrı aşkına, haftada 40 saatlik bir çalışma yapmaya çalışın. Ayrıca, esnek zaman. Flextime bir saçmalık dünyasını telafi edebilir. En azından benim için.

Programcılar ve patronlar arasındaki iletişimi geliştirmek.
Bu benim için zor. Tüm bu shmoozing şey bir programcı odağı daha sonra bir patron beceri kümesidir. Zaman tahminleri gibi bazı temel şeylerin yalnızca tahmin olduğunu söyleyebilirim. Suda yürümek ve donmuşsa gereken şartları yerine getirmek kolaydır. Belki de utangaç programcılardan kod incelemesi ya da bir şey hakkında projeleri hakkında sunum yapmalarını istemek. Alıştırma mükemmelleştirir, ya? Ama bu konuda başkalarının tavsiyelerine boyun eğdim.

"Benzer şekilde, ondan nefret ediyorsanız, lütfen nedenini ayrıntılı olarak açıklayın."
Buradaki taşkın kapılarını açacak. Ve açıkçası benimle bağlantılı olabilecek bir açık ID kullanmıyor olsaydım, muhtemelen ben de havalandırırdım. Yapılmaması gerekenlerin gerçekten büyük bir listesini istiyorsanız, anonim gönderim için daha uygun bir foruma sorun.

Her zaman, genel olarak insanların size, tedavi ettiklerinden daha iyi davranmayacaklarını buldum (ancak daha kötü davranabileceklerse de). Ben şahsen (geliştiriciyim) dürüstlüğe, saygıya saygı duymak, güvene güvenmek vb. Tarafınızla tarafsız bir ortamda gayrı resmi bir sohbet yapmanız ve onlara ne söylediğinizi söylemeniz gerekir. Toksik “bize karşı biz onlara” ortamlarında unutulan nokta, hepsinin “biz” olması gerektiğidir . Hem yönetim hem de çalışanlar bunu bilmeli ve işletme bunu desteklemeli.

İyi şanslar.

Artık yalnızca geribildirimleri kabul etmekle kalmayıp, aynı zamanda hareket etmeyi de kanıtlamış bir sicile sahipsin. Daha yüksek karar vericilerde etkiniz olduğunu ve ekibiniz için bir şeyler yapabileceğinizi kanıtladınız. Bu büyük bir fark yapar. Programcılar benim daha iç içe olmama rağmen programlama hakkında konuşmayı seviyoruz. Gayri resmi bir ortam güzel, ancak herkesin profesyonel olması gerekiyor. İnsanların biraz hava almasına izin verin, ancak tartışmaların üretken olduğundan ve yalnızca bir kaltak seansı olmadığından emin olun.

Tecrübelerime göre, yöneticimden hoşlanmam veya hoşlanmamamın en önemli faktörü, genel olarak gelişmeyi anlaması ve yaptığım işi anlamasıdır. Bazı olumlu sonuçlar burada listelenmiştir:

• Bir değişikliğin neden bu kadar uzun sürdüğünü veya uygulanamayacağını doğrulamak için fazla zaman harcamak zorunda değilim. Teknik olarak, herhangi bir değişiklik uygulanabilir ve üst yönetim genellikle uygulamayı herhangi bir şekilde talep eder. Ancak en azından böyle bir durumda, doğrudan yöneticiniz sizin tarafınızdadır, daha fazla zaman ister (sizi zorlamak veya yakmak yerine).
• Kötü bir durumda (WTF hack, üretim sorunu, vb.) Desteklenme konusunda daha iyi bir şansım olduğunu biliyorum. Genellikle teknik olmayan bir kişi böyle bir durum için geliştiriciyi suçlama eğilimindeyken, iyi bir yönetici gerçekte neler olup bittiğini KENDİNE KABUL EDER ve geliştiricisini destekler (sadece iyi olması için bu şekilde davranmaya istekli değildir).
• İşimin ve performansımın uygun bir kişi tarafından değerlendirilmesi gerektiğini biliyorum.

Benim düşünceme göre, eğer daha sık ve genellikle sıkı bir proje programı veya bütçesinde programlama yapmazsanız, geliştiricilerin beğenme şansı çok düşüktür. Eğer durum buysa, daha hızlı bir şekilde hareket etmeli ve doğrudan yönetici olarak bir başkasına sahip olmalısınız. Üzgünüm bu paragrafta kulağa kötü geliyordu ama bu böyle görüyorum. Sizin iyi bir insan gibi görünüyorsunuz ve bazı gerçekleri hak ediyor.

Ben de takım elbiseli erkeklerden biriyim ve 15 yıldan fazla süredir. Ben başladığımda bir yazılım geliştiricisiydim ve bir şansım olduğunda hala kod yazıyorum. Bu yüzden iki taraf için de konuşabileceğimi ve bu durumlarda biraz deneyimim olduğunu düşünüyorum. Ayrıca, personelin seçtiği ve bu gibi durumları ele almam konusunda kendimi güvene taşıyan “Yılın Çalışanı” gibi bilgilerim de var.

Çok sık tanık olduğum şey, değer sistemleri ve yönetim ile geliştiriciler arasında alınan operasyonel yöntem / yaklaşımlarda önemli farklılıklar olduğudur.

Birçok geliştirici için, samimiyet, dürüstlük ve esnek bir çalışma ortamı listede çok yüksektir. Maalesef, aynı değerler üst yönetim listesinde çok yüksek değil. Ve bu, kaçınılmaz olarak, özellikle orta yönetim (siz ve ben) üst yönetim tarafını tamamen ele almaya karar verirse, büyük çatışmalara neden olur. Bundan kurtulmanın tek yolu (benim açımdan) ekibinizin önünde sağlam bir duruş sergilemek, onları tamamen desteklemektir ve açık iletişim yoluyla ve en önemlisi, söylediklerinizi yaparak güven ilişkisi kurmaktır. (bu, çoğu zaman üst yönetimden elde ettiğinizin, politikaların samimiyeti tamamen altüst ettiği şeylerin tam tersidir).

Aynı zamanda operasyonel kalmaya ihtiyacınız var, bu yüzden üst yönetim ile anladıkları ve oyunlarını oynadıkları bir dilde iletişim kurmanın bir yolunu bulmalısınız. Orta yönetimin asıl sorunu budur.

İnanıyorum ki, geliştirici mutluluğu ile üretkenlik küçük şeylere bağlı. Matematik yönetimi için oldukça harika çalışıyor. Bana sabah bir donut verin (-25 cent) ve bütün gün iki kat daha fazla çalışacağım (+ birçok dolar). Memnun değilken yavaş çalışarak şeyleri aktif olarak sabato etmemiz değil, son derece karmaşık sistemler üzerinde çalışıyoruz ve bir şey hakkında hayal kırıklığına uğradığımızda odaklanmak son derece zor. Kızgın olduğumuzda kod yazmamamız muhtemelen daha iyi.

Bununla birlikte, tahminler kendileri tarafından ele alınmalıdır. Sahip olduğum her konu, gerçekçi olmayan tahminler dışında, bana bir çörek göndererek çözülebilir . Doğru veya yanlış, geliştiricinin nasıl gördüğüdür: Yönetim, daha kısa bir tahminle kazanacak her şeye (yeni bir tekne gibi) sahipken geliştiricilerin kaybedecek her şeye sahip olması (bir aylık uykuya değer) gibi. Yönetim sorumlu olsa da, her zaman tahmin savaşını kazanırlar. Geliştiricilerin sürenin belirlenmesine karar verdiğinde tahmin sisteminin en iyi şekilde çalıştığını düşünüyorum (doğru bir tahmin vermemiz bizim için ne kadar zor, peki bir yönetici nasıl olur?) Ancak yönetim, hiçbir geliştiricinin demiryoluna kapılmadığı anlayışıyla, onları iddialı olmaya olumlu bir şekilde motive ediyor. biraz kapalı olmak.

Soru, yorum veya kaygıları olabilecek bir programcıya ne tür bir tepki verdiğinizi düşünün. Bir "Ne istiyorsun, var mı şimdi ?" ya da "Neden beni rahatsız ediyorsun bu ?" nasıl bir cevap? Geliştiricileri endişeleri ve yorumları dile getirmeleri için ne kadar iyi teşvik ediyorsunuz? Bu sadece bir başlangıç ​​noktasıdır.

İkincisi, bu tartışmaları nerede yapmaya çalıştığınıza dikkat edin. Yöneticimin her şeyi duymaktan haberdar olduğunu bilsem iş makinemi bir sonraki küpte biriyle tartışırken çok açık olacağımdan şüpheliyim. İnsanların açık ve dürüst geri bildirimde bulunmalarını istiyorsanız, cevaplarının halka açık yayınlanmayacağını veya onlara karşı kullanılamayacağını bilmek için verilen bazı mahremiyetler bulunmalıdır.

Üçüncüsü, ne tür Duygusal Zeka becerilerine sahip olduğunuzu düşünün. Proje Yöneticileri için Duygusal Zekâ: Anthony Mersino'nun Üstün Sonuçlarına Ulaşmak İçin İhtiyacınız Olan İnsan Becerileri Burada gerçekten psikolojiye dalmak istiyorsanız, kullanılabilecek çeşitli kişilik profili araçları vardır, örneğin Enneagram, sosyal stiller ve MBTI.

Son olarak, şirketinizdeki kültürün ne olduğunu düşünün. Hatalar halının altına bir şey mi girdi? Şikayetler, birinin başını gerçekten kolay belaya sokabilecek kadar büyük bir hayır mıdır? Hangi davranışlar ödüllendirilir veya teşvik edilir, hangileri hoş görülür ve kabul edilir? Bunların bir kısmı gözlem olsa da, bazıları da ofisten uzakta ya da gizli dinleme olasılığı olmayan bir odada yapılması gereken bazı konuşmalar gerektirebilir. Muhtemelen başlangıçta bunu kullanmaya çalışırken tekrarlayan olacaktır. Yeni bir uygulama oluşturmaya ve kültürün öncelikle herkesin "onu emmeyi" bildiği yerlerden biriyse, konuşarak insanlarla konuşmaya çalışıyorsanız, bu kötü bir şey değildir. Bu, diğer cevaplardan daha dokunaklı olabilir ama ben de öyle olurdum.

Devs onların savunucusu olduğunu düşünüyor mu? Demek istediğim, onlar da, dövülmeden endişelerini / hayal kırıklıklarını sizinle paylaşmakta özgür olduklarını biliyorlar. Onlar için savaştığını düşünüyorlar mı? İşlerini takdir ettiğinizi düşünüyorlar mı? Gerçekten kariyerlerinde başarılı olmalarını istediğinizi düşünüyorlar mı?

Eğer takdir edilirlerse, muhtemelen daha iyi iletişim kuracaksınız.

Bir geliştirici olarak ben büyük bir ineğim ve sosyal becerilerim yok ve bu konuda özür dilemiyorum. Ne de olsa, ben yeteneğim ve sen de yeteneğim için beni işe aldın. Sosyal kelebeğin işi yapması için geliştiriciler yerine proje yöneticileriyle dolu bir odanız olacaktı.

Bazı geliştiricilerin sosyal olarak zekice olduklarını biliyorum, ancak medyanın içe dönük ineğe dayandığını düşünüyorum.

Biri benden bir şey yapmamı istediğinde, kesinlikle çıkarımda bulunmaz ve tam olarak ne istenirse onu yaparım. Görünüşe göre bazı proje yöneticileriyle her zaman sorun yaşıyorum, çünkü projeleri hakkında kesinlikle yapamayacağım çıkarımlar yapmamı bekliyorlar, bu yüzden bazen tam olarak ne olduğu ortaya çıksa da, işler bekledikleri gibi çıkmıyor talep ettiler. Bunun bazı proje yöneticilerinde gerçekleşmesinin nedeni, yüksek kaliteli HLD'ler, BRD'ler sunmadıkları ve proje yönetiminin sosyal yönüne siyah beyaz olandan çok fazla değer vermedikleri içindir.

Bence burası dünyanın çarpıştığı yer. Proje yönetimi dünyasında kişisel becerilerin sosyal becerilerinin ve kalitesinin önemli faktörler olduğunu düşünüyorum, ancak benim gibi geliştiriciler için kesinlikle hiçbir şey ifade etmiyor. Bunun ya da bu görevin ne kadar önemli olduğu konusunda beni etkilemiyor. Hatta bazılarının önerdiği gibi öğle yemeği ya da bira içmek için dışarı çıkmak bile istemiyorum.

Gerçekten istediğim şey iyi, kaliteli HLD'ler ve BRD'ler. Ulaşılabilen programları ve son başvuru tarihlerini istiyorum ve yeni tasarımlar veya planlar sunulduysa, zamanlamanın ve son tarihlerin yeniden ayarlanmasını istiyorum. İhtiyaçların anında değişmekte olduğu projeler üzerinde çalıştım - bana göre bu benim düşük kalitedeki proje liderliği ile uğraştığım kırmızı bayrak. Bir geliştirici olarak yapabileceğiniz en kötü şey, günlük olarak yeni proje gereklilikleri getirmektir, özellikle bir program yaptıktan veya program taahhütleri verdikten sonra. Yeni şartlar getirildiğinde, son teslim tarihlerine tazminat ödenmesi kabul edilemez. Daha fazla saat çalışmak, geç çalışmak, bununla ilgili bir sorunum yok, ama bu gelişme ile her zaman nicel olan bir şey değil. Bazı değişiklikler birkaç saat sürebilir, Bazı değişiklikler uygun Ar-Ge, test, KG vb. için haftalar sürebilir ... Her zaman bir pasta pişirmek gibi değildir, bazen gereksinimlerdeki tek bir değişiklik bütün tarifin değiştirilmesi gibi olabilir. Proje yöneticilerinin erimesine tanık oldum ve konferans görüşmelerinde sinir krizi geçirdim, çünkü son başvuru tarihleri ​​ekstra gelişime izin vermeyecek, ancak başlangıçtaki proje gereksinimlerinde olmayan bir gelişme istiyorlar.

Örnek olarak yalnızca kişisel önyargılarımı ve deneyimimi verebilirim, bu yüzden lütfen tüm geliştiriciler adına konuştuğumu çıkarmayın. Bunları sadece kendi kariyerimin mikro kozmosuyla görüyorum, ancak bu yazı, meşhur havluya atmamı sağlayan kesin koşulları anlatıyor.

Geliştiricilerinizle ne sıklıkla konuşuyorsunuz? Proje durumu toplantıları, teslim edilebilirler hakkında sorular veya onlara getirdiğiniz diğer konular demek istemiyorum - programlayıcılarınızdan biriyle ne sıklıkta oturuyorsunuz, onlara işlerin nasıl gittiğini soruyorsunuz ve sadece dinliyorsunuz .

Diğer cevapların çoğu gerçekten iyidir - çevik gelişime bakmalısınız. Geliştiricilerinizin rollerini öğrenmeleri ve yetiştirmeleri gerekir. Ancak, geliştiricilerin ne söylediklerini dinlemiyorsanız (ya da söylemiyorsunuz!), O zaman önce bununla ilgilenmeniz gerekir.

Bire birler için iyi referans - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Kısa ve güzel. Excel ne yaparsanız yapın - bu iletişimi kolaylaştıracak.

Dışlama, geliştiricileriniz için ne anlama geliyor? .. Okuyun, tekrar okuyun, evet bile PeopleWare çalışın

Yukarıdaki yazılarda tüm harika fikirler ve yorumlar!

İşte bir fikir: BT personelinizi, yerel topluluk kolejinizdeki iletişim atölyelerine gönderin - tabii ki şirket tarafından ödenir.

A) çalıştayların iyi bir üne sahip olduğundan ve b) çalışanlarınızı bir araya getirmemeye dikkat edin. Sadece atölye çalışmalarının değerini düşürmekle kalmayıp aynı zamanda diğerlerinin de bozulmasına neden olacak şekilde diğer sınıf üyelerine karışmaya ve birleşmeye meyilli olacaklar.

Üretken ekip odaklı iletişim, herkesin öğrenebileceği bir beceridir, ancak çoğu skolastik yoldan yoksun olduğunu düşündüğüm bir konudur.

Bu fikir hiçbir şekilde sihirli bir mermi değildir, ancak bulmacanın temel bir parçasıdır. Ortaklarınız sadece birbirleriyle daha iyi iletişim kurmayı öğrenmekle kalmayacak, aynı zamanda bonus da, SİZİN çalışmalarınızı daha iyi anlamaya ve saygı göstermeye başlayacakları olacak (iletişim PM'nin özünde olacak).

Sadece benim 2 bit :)

Sadece içinde geliyor edilmiş bir öneri cevap vermesini sağlamak için bir kaç yanıtlar zaten. Michael Lopp (aka rands ), geliştiricileri yönetmek ve “başlarına girmek” hakkında blogundaki Rands , Repose'daki Rands ve İnsanları Yönetme kitabında ( kitap kaynakları ) yazıyor . Kitap, çoğunlukla 2007'den önceki yayınlarındaki yazılardan düzenlenmiş içerik içeriyor ve blogunun yönetimle ilgili bölümlerini yakalamak için iyi bir yol sunuyor (ayrıca kumar oynamaktan bahseder ve bunun başka bir mesele olup olmadığını okumak isteyip istemediğiniz). Yazısı genellikle harika ve genellikle esprilidir, bu yüzden onu okuma riski yoktur.

Takımı bira için çıkar (ve satın alıyorsun).

Partiye geç kaldım, ama sadece bu soruyu gördüm.

Çok iyi hitap etmediğim bir şey şudur:

Grunt'lar asla gerçeği takım elbiselere söylemez. Rands bunu DNA’da söylüyor ama kafa kafaya ele almıyor, farklı bir konuda.

Takım elbise giyiyorsun ve çekleri imzalıyorsun. Sen şirketin çıkarını temsil ediyorsun. Mühendisleri temsil etmiyorsunuz. Eğer, onların çek imzalama yapılmamasını tercih yaptıysak, onlar ediyorum senin imzalanması olmak.

Bu elbette size veya mühendislere haber değil. Ancak bir mühendis belli meseleleri ortaya çıkardığını - problemleri - işyerinde önemli bir çatışmaya yol açacağını - bilirse, risk / ödül tradeoffu mühendis lehine değildir. Mühendislere ürün üretmek için ödeme yapılır, işyeri kültürü savaşlarından vazgeçmezler. Bunlara karışmak işi yanlış yapmak için hızlı bir yoldur.

Bu nedenle yönetim görevinin bir parçası, mühendislerin şirket politikaları ve kariyer boşluklarına maruz kalmadan, sorunlara açık olmaları için bir yol sağlamaktır. Her şeye rağmen, yükseltir olması güzel ve orada vardır bu bir hoş gelmiyor ise, diğer şirketler.

DeMarco ve Lister'in "Peopleware: Üretken Projeler ve Ekipler" konuyla ilgili olarak sorunuzu ve konunuzu ele alan bu harika kitabından kimsenin bahsetmediğine şaşırdım . Editörden: Yazılım geliştirmenin ana sorunları teknik değil insandır . Amazon'daki ilk üç inceleme, sizin durumunuzdaysa beni bu kitabı satın almaya ikna etmek için yeterliydi.

Buradaki cevapların çoğunun çok iyi noktaları var, ancak yardımcı olabilecek birkaç kaynağa atmak istiyorum. Birkaç durumda ya kendi başlarına dev bir karmaşaya daldım ya da katılan insanlar arasındaki iletişim nedeniyle çok verimli bir şekilde çözüldüm. Üç kitap, özellikle hatta çok fazla olduğu stresli durumlarda, iletişim becerilerimi kişisel olarak geliştirmeme yardımcı oldu:

• Zor Konuşmalar: En Çok Neyin Önemli Olduğunu Tartışmak
• Önemli Konuşmalar: Miktar Yüksek Olduğunda Konuşmak İçin Araçlar
• Önemli Yüzleşmeler: Kesin vaatlerin çözülmesine yönelik araçlar, beklentilerin ihlali ve kötü davranış

Sorunuzu okuduğunuzda iletişimin değerini gördüğünüzü düşünüyorum. Şahsen iletişimin bir yönetici veya lider için ticari veya teknik becerilerden daha önemli olduğunu hissediyorum. Liderlik ettiğiniz insanlar, projenin büyük bir kısmını gerçekleştirmek için ihtiyaç duyduğunuz zor becerilere sahip olmalıdır. İyi bir teknik lider veya proje yöneticisi, ekip içinde veya ekip ile müşteri veya ekip ile işletme arasında (veya bu üçünün bir kombinasyonu) olup olmadığı iletişimine odaklanabilmelidir.

Teknik işgücünün bakış açıları hakkında fikir veren birkaç harika roman okuyun:

• Hackerlar, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Katedral ve Çarşı, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Bunlar, yönetim ile ilgili tipik bir anı kadar önemlidir (Drucker et al).

Uzun yıllardır çeşitli roller üstlenmiştim - geliştirici, kıdemli geliştirici, teknik lider vb.

Sorunuzdan - geliştiricilerinizin size bir şey söylemediği açıktır çünkü yardımcı olabileceğinizi düşünmezler.

Bu 2 nedenden dolayı olabilir.

1. Bir şeyleri düzeltecek gücün olduğunu sanmıyorlar. Ancak, bunun olası olmadığını düşünüyorum, çünkü o zaman muhtemelen bunu biliyor olacaksınız ve geliştiriciler de size bunun için sızlandı.
2. Bir geliştirici size bir sorunla geldiğinde, aşağıdakilerden birini veya birkaçını yapan kişi sizsiniz.
   • Size problemlerle geldiklerinde, onlara söyleyin - ben problem değil, çözümleri severim.
   • Onları güzelce dinlersin ve sonra sorunu çözsün. Onlara ne şeref duyduklarını, onlara problemi çözme sorumluluğunun verilmesi konusunda konuşmaları. Zaman geçtikçe, çocuklarınız size bir problemle gittiklerinde ekstra işle sonuçlanacağını anlarlar, bu yüzden size problemlerle gelmezler.
   • Bir problem olduğunu inkar ediyorsun. Bunun için ikna edici nedenler veriyorsunuz. Ancak bu devam ederse, zamanla çocuklarınız size bir sorunla yaklaşmanın bir anlamı olmadığını öğrenir.
   • "Evet, anlıyorum" diyorsun. Bu tür şeylerin ara sıra gerçekleştiğini söylüyorsunuz ve yapılabilecek hiçbir şey yok. Bu bir kalıpsa, o zaman yine çocuklarınız onu anlar.

Yukarıdakilerin herhangi biri veya tümü ise, düzeltmeniz gerekir.

En çok nefret ettiğim şey, insanların ben, geliştirici ve son kullanıcı arasına girmesi. En iyi menajerler bunu yapmama izin veriyor ve çözümümüzü kullanıcının istediğini veya yapabileceğini düşündüğüm eşleşecek şekilde değiştiriyor.

Bana göre en kötü uygulama genellikle "iyi" olarak giyiniyor - genellikle menajerin kendileri var veya bir BA veya birisi daha önceden kararlaştırılan zaman çizelgelerinde yorumlamaları ve uygulamaları gereken özellikleri yazıyor.

Özelleştirilmiş bir çözümse çoğu zaman geliştiriciler bile ne kadar zaman alacağını bilmeyeceklerdir ve genellikle müşteri onlar için en iyisinin ne olduğu konusunda hiçbir ipucu yoktur. Bu yüzden yinelemeli gelişim harika. Çoğu anlaşmanın yapılma şekli bu kadar değil, bu yüzden iyi bir yönetici yukarıdaki gibi çalışmak için savaşacak.

Sonunda, bazı geliştiriciler iletişimde iyi değildir ve müşterilerle ilişki kuramazlar. Belki de net gereksinimleri olan problemlere, özellikle de net teknik gerekliliklere en uygun olanlardır. Belki de daha iyi iletişim kurucu olan ve saf teknik sorunları olan iş problemlerini çözmek için çalışmak isteyen geliştiricilere ihtiyacınız var.

Takımı mutlu etmek çok kolay

Onları birçok kez dinlemeye çalışın, sorularının içinde de cevapları var. Ekip üyesini sorunlar ve olası çözümler ile gelmeye teşvik ediyorum.

Takım gezisi iyi bir fikirdir (bazı oyun planları olabilir)

Projeniz biraz geç gece ve hafta sonu çalışması gerektiriyorsa ve gerçekten de ekibe çok fazla değer katmadığınızı düşünüyorsanız, ekibin çabalarını ve mümkünse ekibini takdir edecek bir şeyle zaman geçirmek iyi bir fikir olabilir. biraz PTO düzenlemek

rahat olmalarını sağlamak için her ekip üyesine iki ayda bir 1: 1 yapın.

Son fakat en az değil, projeyi işlevsel ve biraz da teknik olarak anlamanız sizin için iyi bir fikir olabilir.

Daha fazla sorunuz varsa lütfen bana bildirin

Ayrıca (Fransızca benim ingilizce affet) bilimsel bir mühendislik geçmişine sahip, ancak özellikle de BT yazılım altyapısı olmayan bir yazılım yöneticisiyim. Bu yüzden başlangıçta kodlama ile özel bir ilgim yok ama Deming'den devralmış gibi davranan her "modern" okula çok farklı bir öğretimi olan Deming okulundan istatistiksel bir kalite mühendisi oldum. En kötüsü 6 sigma, yalın daha iyiydi ama ne yazık ki bu oldu http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

“Aslen Altı Sigma, Motorola tarafından altı sigma kalite seviyesini elde etmek için Toyota Kalite Yönetiminden (TKY) elde edildi ve daha sonra Allied Signal ve GE aracılığıyla maliyet düşürücü bir program haline gelmek için istatistiklere dayanan Kara Kuşaklar tarafından yürütülen projelere harcandı - her proje net bir yatırım geri dönüşüne ihtiyacı var. Başka bir deyişle, programı bir liderlik felsefesinden maliyetleri düşürmek için bir iki seferlik projeye kadar inkar ettik. Orjinalin tam bir bastarizasyonuydu ve liderlik ve kültürün eksik olması nedeniyle nadiren sürdürülebilir bir değişime yol açtı.

“Benzer bir şey, bir araç setine indirgendiğinde zayıfladı (örneğin, değer akışı eşlemesi, KPI panoları, hücreler, kanban).

“Yalın ve Altı Sigma hiçbir şekilde mükemmel Japon şirketlerinin veya Deming gibi öğretmenlerinin orijinal düşüncesini yansıtmıyor.”

Bugün Çevik hareketler yalın gibidir (Jeff Sutherland kursuna ve Deming onuruna bakınız http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -centrum-of scrum / ), Waterfall'dan daha iyidir, ancak hala Deming'in orijinal öğretisinden çok uzaktır çünkü orijinal metinde Deming'i okumak yerine, gurular sadece Yönetimin tüm 14 ilkesinden alıntı yapmadan onu yeniden paketlerler. ve kendileri tarafından çok az değeri olan araçlar ve seminerler satıyor.

Şimdi, yazılım alanına gelince, problemler bir yandan genel ilkeleri bilen, ancak gerçekte nasıl uygulanacağı konusunda gerçek fikirleri olmayan, diğer yandan yazılımları yazan, ancak ilkeleri görmezden gelen insanlar olduğu için insanlar var. kendilerine gerçek ilkeleri söylemeden araçları satan sahte gurular ve aslında kendi yönetim araçlarını oluşturmaları gerekir.

Bu yüzden benim için yazılım proje yöneticisi, yalnızca Microsoft Project'te planlama yapmak (ya da Agile ile yükleme çizelgesi) yapmak ya da Powerpoint'te üst yönetime güzel sunum yapmak için yazılım kodlama işleminin günlük işleyişine daha derinden gitmeye çalışmalıdır. geliştirici ekibi. Geliştirici ekibi teknik sorunlar olsa bile sorun yaşarsa, proje yöneticisi tanıyı harici gözlerle yönlendirmeye yardımcı olabilir. Koduna bakabilir, ufak ayrıntıyı anlamadığı halde, geliştiricilere bu ipucunu düşünmediklerini fark etmeleri için tetikleyebilecek bazı saf sorular sorabilir (çok sayıda kişisel örneğim var, ancak çok uzun olacak. blogumda bir makale yazmak yerine).

Diğer bir konu da teknik çerçeveler okuyarak yeni çerçeveler, yeni mimari paradigmalar gibi alandaki evrim hakkında genel bir farkındalığa sahip olmaya çalışıyorum. Bazı entegrasyon testlerine katılacağım, bazı dökümanları kendim yazacağım (programcıların nefret etmelerini sağlar, bu yüzden onlar için yaparlar, tabii ki beni çekirdekli beslerler), ekibe yardımcı olmak için yapabileceğim her şeyi.

Genel olarak geliştiriciler çok sıkı çalıştıklarını hissediyorlar ve bu doğru, sık sık onlara soyutlamada kalarak kolay kısmı yaptığımı söylüyorum, yine de gerektiğinde somut olarak yardım etmeye çalışıyorum - çünkü mikro-yönetim girişim duyguları üretebileceği için iyi değildir.

Sonuç olarak: geliştiricilere yönelik sloganları ortadan kaldırın (aslında Deming'in 14 ilkesinden biridir), onlara belgelerle değil, yalnızca üst yönetimle görüşmenizle ilgili proje somut yazılımları ile ilgilendiğinizi gösterin.