Önce küçük bir arka plan. Orta ölçekli şirkette proje yöneticisiyim. Bir CS majör olarak başladım ve programlamaya biraz maruz kaldım, ancak birkaç ay sonra bunun benim 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 şirketlerde (5 yıldır) yazılım yönetiminde çalıştım.
Son zamanlarda çok acı verici bir projemiz vardı. Hem bizim tarafımızda hem de müşterilerimiz tarafında birçok hata ile en kötüsüydü ve kayıp olmadan zar zor sona erdi. Birçok sinir bozucu duruma yol açtı, bunlardan biri üst düzey geliştiricilerimizden birinin bizimle (vokal) bir sesli tartışmadan sonra şirketten ayrıldığı noktaya yükseldi. Bu benim için kırmızı bir bayraktı: Çok yanlış bir şey yaptım. (kayıt için, argüman birkaç yanlış zaman tahminiyle ilgiliydi)
Birçok yerde cevap aradım ve bir arkadaşım beni bu siteye yöneltti. Burada yönetimle ilgili hayal kırıklıkları hakkında birçok soru var. Genel kötü deneyimlerin "takım elbiseli adamlara" karşı genel bir isteksizliğe yol açtığını anlayabiliyorum.
Takım elbiseli adamım. Öyle görünmeyebilir, ancak tek istediğim başarılı bir proje ve sınırlı kaynaklarla acı verici kararlar alıyor. Bu benim işim. Sözü edilen kıdemli geliştiricinin şikayet ettiği şeylerden biri iş ekipmanıydı. Açıkçası, sahip olduğumuz bilgisayarların çalışmaya uygun olmadığı konusunda hiçbir fikrim yoktu. Bundan sonra birçok programcıya sordum ve genel fikir birliği daha iyi makinelere ihtiyacımız olduğu yönündeydi. Bunu o zamandan beri düzelttim, ama açıkçası ben ve programcılar arasında büyük bir iletişim boşluğu vardı. En parlak geliştiricilerin bazıları en utangaç ve sessiz insanlar. Bunu biliyorum ve bir röportaj 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üşündüren birçok bilgisayardan sadece biri. Göz korkutucu ve tekrarlayıcı olmadan programcılarla iletişimi nasıl geliştirebilirim?
Umarım insanlar iyi şeylerden şikayet etmezler. İşyerinizi ve müdürünüzü (ya da en azından gibi :)) seviyorsanız lütfen bana onlardan bahsedin. Ne yapıyorlar doğru? Benzer şekilde, ondan nefret ediyorsanız, lütfen nedenini ayrıntılı olarak açıklayın. İletişimi geliştirmeyle ilgili cevaplar arıyorum çünkü bunun benim sorunum olduğunu düşünüyorum, ama yanlış olabilirim.
Vaov! Sorduğunuz için teşekkürler. Teknik olarak, sizin gibi, sanırım ben yönetimim, çünkü ekipleri iletişim kurmak ve liderlik etmek için kod yazmaktan çok daha fazla zaman harcıyorum ... ama işte yönetim ufkunun her iki ucundan da benim almam. İster başka bir yönetici için çalışan bir geliştirici, ister yöneticiyim, işte yönetimimle iletişimime yardımcı olan bazı şeyler:
Özellikle zaman tahminleri hakkında - bir ton yapmak zorunda kaldım ve geliştirme ekibime kesinlikle bundan fayda sağladım "Buna ihtiyacım var çünkü maaşlarımızı ödemek için daha fazla para isteyeceğim, bana söylediklerine güveneceğim ve Rakamlarınızı kullanacağım ... bu demektir ki, eğer bana topu düşürürseniz, hepimiz berbatız çünkü ikinci kez para isteyemeyeceğim - teklif ettiğimiz şeyle yaşamak zorundayız ". Bu bağlamda, geliştiriciler bana gerçek beklenti ortamına çok daha yakın olan yüksek tahminlere ne kadar kendinden emin ve parlak olduklarını göstermeye çalışan düşük tahminlerden değişti.
Kimse yanlış değil - "Neden" sorusu uzun sürüyor - "bu çok çirkin! Olmaz!" konuşmayı akıcı tutar. Bazen birisine sorulan şey ile askerin istediği arasında ciddi bir kopukluk vardır. Benim en iyi yönetim benim cevaplarım tarafından korkunç bir sürpriz oldu ve şaşırdıkları zaman, şaşkınlık içinde yanıp söner ve sonra "neden bunu söylüyorsun?" Diye sorarlar. (Derhal) demiyorlar - "değiştirmeniz gerekiyor". Rekabetçi bir hedefe ulaşmak için tekliflerdeki sayıları azalttım, ancak yalnızca sahneyi nasıl değiştirebileceğimiz ve soru için farklı bir bağlam oluşturabildiğimizden yoğun bir şekilde konuştuktan sonra.
ortam gürültüsünü, Kelime seçimini ve kelimeler arasındaki boşluğu dinleyin - İşte kendimi kullanmaktan hoşlandığım ve çaldığım bir sürü şey:
olabildiğince çok iletişim aracına kadar açın - yüz yüze, telefonda, e-posta ile, IM ile her şeyi ve kurulacak her şeyi konuşmaya hazır olun iletişim akışı. İnsanlar o kadar çeşitlidir ki, sadece bir numara işe yaramaz. Ve bunu yöneticinin işi olarak geliştiricinin değil, çok formatlı iletişimci olarak görüyorum.
sizinle konuşmaya değer kılın Birisi size bir sorundan ve belki de olası bir çözümden bahsediyorsa, yönetici olduğunuzu ve muhtemelen Farklı bir çözüm lehine karar verin, ya da hiç çözüm bulunmayın çünkü zahmete değmeyeceğini düşünüyorsunuz. Ancak üçüncü kez bu olur, özellikle de açıklama yapmadan gerçekleşirse, insanların yaklaşık% 99'u size bir şey söylemeyi bırakacaktır.
Ve işte benim için inanılmaz derecede zor olan, ancak bunu yapabildiğimde harika çalıştı - içe dönükler ve dışa dönükler arasındaki farkın farkında olun . Şansınız, dışa dönük olmanızdır - bu yüzden işiniz iyi görünüyordu ve bir gelişim pozisyonu olmadı. Geliştiriciler çoğunlukla içe dönüktür. "İçine kapanık" demek, "iletişim kuramıyor" anlamına gelmez, ancak bunların desen, süreç ve hızlarının önemli ölçüde farklı olduğu ve kesintisiz iletişim kurma isteğinin neredeyse hiç olmadığı anlamına gelir. İçine kapanık düşüncelerin ortaya çıkmasına izin vermek için zaman ve sessiz (ama birlikte konumlandırılmış) alan planlayın. İç içe geçmiş arkadaşlarımın birçoğu bana sadece "5 dakika kadar susmamı" beklediklerini söylüyorlar, böylece bir düşünce oluşturabilir ve cevap verebilirler. İşte aynı şey hakkında birkaç harika makale - dışa dönüklerin içe dönükler hakkında bilmesi gereken 5 şey ve Nerd Mağarası üzerinde Saklanan Rand'lar - içe dönükler için harika olanın özellikle geliştirici-tastik bir örneği =. Rands bu arada oldukça harika. Kendisi bir inek, bu yüzden geliştiricinin odağından geliyor, bu sizin tarzınız değilse koymaktan vazgeçebilir, ama komik ve takım gelişimi hakkında gerçekten iyi fikirlere sahip.
Favori yöneticilerimle ilgili sevdiğim # 1 şeyin:
proje hakkında benim kadar derinden kararlı ve heyecanlıydılar (daha fazla değilse)
Sırtıma sahip olduklarından hiç şüphe etmedim - bir sonraki otorite seviyesinin önündeyken ben (ya da akranlarımın) asla keçi keçisi olmayacağını kesin olarak biliyordum. Başarısızlık her zaman bir grup başarısızlığı olurdu.
O zaman becerilerim için önemli ve uygun bir şeyin sahibi oldum, ancak becerilerimi genişletmek ve işi yapmak için yeterli kaynağa sahiptim.
beni hem birey olarak hem de ekibin bir parçası olarak gördüler - güçlü ve zayıf yönlerimi bilmekle ve güçlü yönlerimle oynamama ve zayıf yönlerimi artırmama yardımcı olmak için aktif olarak meşgul oldular.
kişisel hedeflerimin farkındaydılar ve ellerinden geldiğince onları birleştirmekle ilgilendiler
beni mutlu ederken bir öncelik olamazdı ve olmazdı. "Bu tür bir işten nefret ettiğini biliyorum, ama bunu yapmana ihtiyacım var - işte sonsuza kadar olmayacak ..." diye duymanın gerçek bir değeri var.
büyük resmi açıklamak için her zaman bir haftada (belki şu anda değil) zaman vardı
hiçbir parmak işaret ancak bireysel çalışma için bol tanıma ile neredeyse sürekli geri bildirim ve durum vardı.
her zaman gerçek vardı. Eğer bir şey hassas olsaydı ve tartışılamazsa, boş olduğunu söylediler. Bir şey belirsiz olsaydı, bir miktar güven verdiler.
Önce kolay kısım: yayınınızda teknik bir kırmızı bayrak var: "Yanlış tahminlerden" bahsettiğinizde titriyorum - bu bir tahmin, o MISTAKEN OLAMAZ, bu yüzden tahmin denir. Biraz kapalı olabilir, çok fazla kapalı olabilir, bu yüzden tahmin denir. Tahminleri müjde olarak alıyorsanız, bu, geliştiricilerinizin tarzınızda yaşadığı ana sorunlardan biri olacaktır.
Bununla birlikte,% 100 geliştiricilerle iletişim kurmanın zorluğu konusunda size katılıyorum. Birkaç yıl önce bir proje yönetimi eğitiminde geliştirici olarak bir vahiy aldım. Açık bir tartışma atmosferi oluşturulduktan sonra birkaç geliştirici arkadaşımın yönetime kesinlikle korktuğunu gördüm (yönetim burada mevcuttu). Yanlış olan her şey, geliştiricilerin gözünde yöneticilerin hatasıydı. En önemlisi, yönetimin o gün ortaya çıkan büyük sorunların neredeyse tamamı hakkında hiçbir fikri olmadığıydı. Geliştiriciler, yönetimin bunu kaçıramayacağının çok açık olduğunu varsayıyorlardı ve yönetim, geliştiricilerin onlara neye ihtiyaçları olduğunu söyleyeceğini varsayıyordu.
Bu nedenle, IMHO cevabın ilk kısmı, geliştiricilerinize psişik olmadığınızı ve teknik açıdan söz konusu olduğunda muhtemelen aptalca olduğunu 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ız, zor değil.
Ve ne yaparsanız yapın, onlara cevabı bilmek istemediğiniz soruları sormayın - yukarıdaki "yanlış tahminlere" atıfta bulunarak ;-). Bu bir geliştiricinin kriptoniti.
Burada çok iyi şeyler var ama aşağıdakilerin söylenmesi gerektiğini hissediyorum .. ..Koruk olmak için üzgünüm .. Ama bu söylenmeli:
Ne var bir iletişim sorunu daha = bir [ Güven sorunu olduğunu düşünüyorum. Kimse neyin yanlış olduğunu söylemez çünkü bu bilgi ile ne yapacağınıza güvenmezler ve onlara karşı kullanılacağından korkabilir. Tüm bu konular hakkında size söyleyen geliştiriciler dolayısıyla bunun bir sonucu olmadığı için istifa ediyordu.
Şahsen ben asla bir PM onun arka planında bazı geliştirme deneyimi yoktu işe. Ben bir sonraki projenizi düşünüyorum, zamanınızın küçük bir bölümünü bir parçası olarak ayırmak gerekir Geliştirme ekibi. Takım liderliğinde Jr geliştiricisi olarak çalışarak haftada 8 saat söyleyin.
Bu gerçekten gözlerini bir geliştirme ekibinin dinamiklerine açacak, çünkü şu anda o ekibin bir parçası bile değilsin, bir yabancısın. Bıraktığınız şey size bir şok geldi, bunu kanıtlıyor. Takımdaki herkes onun 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ı.
Yönetici olarak eminim ki kaizen, Toyota Üretim Sisteminin ilkelerinden biri sürekli iyileştirme.
Bir sorununuz olduğunu itiraf ettiniz, bu harika bir başlangıç.
Kaizen beş ana unsura sahiptir:
Kalite Çevreleri : Bir şirketin işleyişinin tüm yönleriyle ilgili kalite seviyelerini tartışmak için toplanan gruplar.
Geliştirilmiş Moral : İşgücü arasında güçlü moral, uzun vadeli verimlilik ve üretkenlik elde etmek için çok önemli bir adımdır ve kaizen bunu sabit tutmak için temel bir görev olarak belirler. çalışan morali ile temas.
Takım Çalışması : Güçlü bir şirket, yolun her adımını bir araya getiren bir şirkettir. Kaizen, çalışanlara ve yönetime rakiplerinden ziyade bir ekibin üyeleri olarak bakmalarında yardımcı olmayı amaçlamaktadır.
Kişisel Disiplin : Bir takım, takımın her üyesi kendi içinde güçlü olmadan başarılı olamaz. Her çalışanın kişisel disipline olan bağlılığı, ekibin güçlü kalmasını sağlar.
İyileştirme Önerileri : Takımın her bir üyesinden geri bildirim talep ederek, yönetim tüm sorunların önem kazanmadan önce ele alınmasını ve ele alınmasını sağlar.
( Kaynak )
Buna uzunca bakarsanız, bu unsurlar üzerinde bir sabit, ekip çalışması ve geri bildirime vurgu yapmaktır.
Bir örnek olarak, zaman tahminleri üzerinde bir tartışmanız olduğunu söylersiniz. Bu zaman tahminlerinden siz sorumlu musunuz? Takımla bunun hakkında konuşur musun? Üzgünüm ama yöneticilerin sadece as- dan bir numara çıkardıklarını gördüm. Önemli bir şey: ekibinizin size verdiği tahminler asla pazarlık. Bir çok yönetici, eğer takımları daha çok çalışırsa, daha kısa süreleri karşılayabileceklerini düşünüyor. Bu bir yalan. Dokuz kadının bir ay içinde bebeği olamaz, unutmayın.
İlk tavsiyem:
Dinleyin : ekibe 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? ?". Ekiple tekrarlayın ve fikir birliğini uygulayın. Göreviniz, ekibin onları sürmek için değil, harika yazılımlar geliştirmesine izin vermektir. Bunu aklında tut.
Dürüstlük ve Sadakat : Bir şey sorduğunuzda kimse cevap vermezse, bunun sizin dinleyeceğinize inanmadıkları veya daha da kötüsü, sizin bunun için onları cezalandır. Dürüst olun. Eğer birisi emdiğini söylüyorsa, bunu bir geri bildirim olarak al ve intikam almayın. Sebeplerini anlayın, geliştirin.
Ve sonunda, burada bazı eleştiriler görmeme rağmen, Efsanevi Adam-Ay: Yazılım Mühendisliği Üzerine Denemeler adlı bir kitap okumanızı tavsiye ederim. Kitap, OS/360'ın geliştirilmesini yönetirken Fred Brooks'un IBM'deki deneyimi hakkında. Burada ve tarihte birkaç şey olabilir, ancak karmaşık yazılım geliştirme sürecinin nasıl çalıştığını anlamak için başlangıç adımıdır. S.Lott, Agile Manifesto 'a atıfta bulunuyor, bu da özellikle meraklı değilim, ama aynı zamanda okumaya değer.
Oku bunu:
Bireyler ve süreçler ve araçlar üzerindeki etkileşimler
Kapsamlı belgeler üzerinde çalışan yazılımlar
Sözleşme görüşmesi üzerinden müşteri işbirliği
Bir planın ardından değişime tepki vermek
Çoğu durumda, organizasyon (yani, patronunuz) sizden
"ölüm yürüyüşü" ne yol açan mantıksal sonucuna açıkça açık bir süreç izleyin. Bu da argümanlara ve istifalara yol açar.
aşırı, düşük değerli, kullanılmayan belgeler oluşturmak.
karmaşık değişim kontrolüne girmek a/k/a sözleşme görüşmesi. Her kullanıcı değişikliği, "kalite" ve değişikliği "önceliklendirmek" için ayrıntılı bir ritüel gerektirir. Gerçekten, her şey "donma" ile ilgilidir - değişimi önler.
sonuçlarına bakılmaksızın planı takip edin. Bazı kuruluşlar, kırık (hatta yararsız) yazılımların zamanında teslimine değer verir. Bir iş sorununun çözümü değil, değer verilen plan.
Sorun kişisel iletişim becerileriniz olmayabilir.
Tüm gelişim "çevre" veya "metodolojisi" ölümcül bir şekilde kırılmış olabilir ve kötü duygular sadece genel kötü uygulamaların bir belirtisidir.
Bana göre bu, kolay bir atmosferde geliştiricilerle hiç konuşmadığınız gibi geliyor. Onlarla yaptığınız görüşmeler sadece resmi nitelikteydi? Bu çok kötü.
Neden onları kişisel olarak tanımıyorsunuz ve böylece şirket, işyeri ve projeleri hakkında neyin iyi neyin kötü olduğunu öğrenmiyorsunuz? Çalışmalarına içten ilgi ve takdir göstererek onlara saygı gösterin ve saygılarını kazanın.
Sana güveniyorlarsa ve piyon teklifleri olmaktan korkmaları gerekmiyorsa, büyük olasılıkla size çekici olmayan gerçekleri bile söyleyeceklerdir.
Ben bir Takım Lideri ve ekibim bana güveniyor. Onları koruyorum. Tüm suçu üstleniyorum ve şöhreti onlarla paylaşıyorum. Yönetimimiz beni korur. Bu morali artırır. Gerçekten zor bir projemiz ve neredeyse kötü bir müşterimiz vardı, bitirmek neredeyse imkansızdı ama sonunda yaptık, çünkü her şey hakkında çok açık ve açık bir şekilde konuşuyoruz.
Clap! Clap! Clap! Kesinlikle iyi bir insan olmalısınız, çünkü işinizde daha iyi olmak için neler yapılabileceğini görmek için açık bir şekilde çıktınız.
Aşağıda büyük bir menajerde şahit olduğumu ve ekibi kıdemli üye olarak yönettiğimde şahsen benimsediğimi aşağıda bulabilirsiniz.
Samimi çabalarınızda iyi şanslar dilerim :)
Genel olarak, siperlerdeki adamlar, durumlarını düzeltebilen ve düzelten insanlar tarafından kavramalarının duyulmadığını hissettiklerinde kendilerini mutsuz hissetmeye başlarlar. Şirketteki konumlarını riske atmadan kavrayabileceklerini bile hissetmediklerinde, bu daha da kötüdür.
Ben bir Teori-Y türüyüm ve çoğu "bilgi çalışanı" olma eğilimindedir; Bir şans verildiğinde, işimizi seviyoruz ve iyi yapmak istiyoruz. Bununla birlikte, bir Theory-Y işyerinin dezavantajı, bir sorun olduğu hemen belli olmayabilir, çünkü iyi yapmak isteyen ve böylece dalga yapmak istemeyen insanlar, bu problemin yollarını bulacaktır veya sadece görmezden gelecektir. Bu, sonunda tüm ekibin yüzüne patlayan bastırılmış hayal kırıklığına yol açar. Bir Theory-X yöneticisi tarafından işletilen bir dükkanın muhtemelen daha önce şikayet eden adamlar olacaktır; çalışanlar sadece para için, bu yüzden iş her zamankinden daha fazla berbat ise, kavramak olacaktır.
Ne yapabileceğinize gelince, işi yapan odada yaşlılar ve olası satışların bulunduğu bir ortamda, en iyi varlığınızdır. Onlarla konuş. Potansiyel müşterilerin size projenin günlük durumu hakkında güncellemeler ve hava kaygıları verdiği ve iş tarafında güncellemeler verdiğiniz ve endişeleri çözmek için onlarla planladığınız "iki yol" için haftada 30 dakika planlayabilirsiniz. ekibi ciddi şekilde etkileyen sorunlar haline gelmeden önce.
Agile'de, her bir "sprint" veya "yineleme" nin sonunda (genellikle bir ila üç hafta süren bir geliştirme çalışması birimidir), en genç üyelerden Başbakan'a kadar tüm ekibin bir "geriye dönük değerlendirmesi" vardır. ". Yaptıklarına, neyin doğru gittiğine, neyin yapmadığına bakarlar ve yapmaya devam edecekleri ve değişecekleri tanımlarlar. Birkaç biçim vardır ve kendinizinkini icat edebilirsiniz, ancak retro'nin sonucu, insanların seslerinin duyulduğunu hissetmesi ve sonuç olarak şeylerin değişmesi olmalıdır.
Çevik Hakkında Konuşma; ilk işim küçük bir şirket içindi ve "küçük" ile bütün firma bir softball takımı kuramadı. Başladığımda dört programcı vardı ve ben gitmeden önce ikiye düştü. Şirketin kurucusu, Başkanı, CEO'su ve% 95 paydaşı demir bir yumrukla yönetti ve organizasyondaki tek planlama kaynağıydı, yani fazla bir şey yoktu. Patron işkolikti ve diğer herkesin de olmasını bekliyordu; Vermek zorunda olduğunuz her şey beklentisinden az ya da çok değildi ve bunun için on yıl boyunca onun için çalışan insanlara giriş düzeyinde bir maaş ödedi.
Bu şirketten ayrıldım ve çok farklı şeyler yapan başka bir firma için çalışmaya başladım; günlük standup'lar, çift programlama, sprint takımları ve retrospektiflerle SCRUM Agile temel metodolojisini uyguladılar. Her sprint'in başlangıcında her iki haftada bir gün için, önümüzdeki iki haftalık çalışmayı planlamaktan başka bir şey yapmadık. Başka bir günün büyük bir parçası için, yaptığımız şeylere geri dönüp bir takım olarak gelişmenin yollarını bulmaktan başka bir şey yapmadık. Yanımda oturan, Microsoft MVP'leri olan, işi yapan ve yaptığım işi cesaretlendiren ve tamamlayan geliştiriciler vardı.
Gece. Ve. Gün. Ana fark? Birincisi, proje için kendimi öldürmem bekleniyormuş gibi hissetmedim; Çevik bir temel ilke sürdürülebilir kalkınma hızıdır. İkincisi, işimi nasıl yapmam bekleneceğine karar vermede bir sesim vardı. İşi yapmak zorunda kaldım, ama bir sonraki sprint'te çekmem beklenecek şey üzerinde "mide ekşimesi" olsaydı, bu görüşü söyleyebilirdim ve duyulur ve kilo verilirdi. Eğer daha iyi bir yol olduğunu hissettiysem, bunu söyleyebilirdim ve eğlenirdi.
Çözüm bulmak ve sorunları çözmek için yukarıdan aşağıya çalışıyormuş gibi görünmemeye dikkat etmelisiniz. Bilgisayarlar için; RMR'nizin (yinelenen aylık geliriniz) yalnızca şirketin iki haftada bir dört bilgisayarı yükseltmesine izin verdiğini varsayalım. İlk dört bilgisayarın hepsi liderlere ve yaşlılara gitmemelidir; en yavaş bilgisayarlara sahip insanlara gitmeliler. Takıma bonus verirseniz, onları sadece "onsuz bunun mümkün olmayacak olan değerli yaşlılarımıza ve potansiyel müşterilerimize" vermeyin; Geliştirme ekibinizdeki HERKES bunu gerçekleştirdi. Eğer bir gencin şikayeti varsa, onu dinleyin; sadece genç olması hiçbir şey bilmediği anlamına gelmez.
İlişkileri geliştirmek:
Zor bir projeniz mi vardı? Daha sonra onlara bir ara verin. Tatil zamanı gevşemek, nefeslerini almak.
Haklar kodunu yazar Bu şeyler verilir. Söylemeden geçmesi gereken temel şeyler. Bunları ihlal ederseniz, kod anahtarlarınızı kötüye kullanırsınız.
Joel testi Birçoğuna katılıyorum. Ama bazıları gerçekten bağımlı. Bazılarını kaçırıyorsanız, muhtemelen programcılarınız için hayatı zorlaştırıyorsunuzdur.
Teknik borç . Tamamlamak için zorlayabilirsiniz, ancak köşeleri keserek bunu fark etmelisiniz. düzeltmek için daha sonraki bir tarihte daha fazla zaman alacak teknik borca maruz kalmak. Bu tarih projenin bitiminden ÖNCE ortaya çıkarsa, gerçekten berbat ettiniz.
RSA animasyonu: Motivasyon Bu gerçekten bilgi çalışanlarını nasıl motive edeceğini gösteren harika bir bit.
İstediklerini kodlamak için serbest gün. RSA videosundan. Adı hatırlamıyorum, ancak bahsettiği şirketin sitesinde kısa bir açıklaması var. Bana iyi bir fikir gibi geliyor. Çoğu dükkanda herkesin yakalandığını bildiği şeyler vardır, ancak kimsenin düzeltmek için zamanı yoktur ve bu yüksek bir öncelik değildir. Bu onların teknik borçla başa çıkmalarını sağlar. Ayrıca parlak fikirlerini göstermelerine izin verir.
Ve tanrı sevgisi için haftada 40 saat çalışmayı deneyin. Ayrıca, esnek zaman. Flextime bütün bir saçmalık dünyasını telafi edebilir. En azından benim için.
Programcılar ve patronlar arasındaki iletişimi geliştirme
Bu benim için daha zor. Bütün bu utanç verici şey, bir programcının odağından çok bir patron becerisidir. Zaman tahminleri gibi bazı temel şeylerin sadece tahmin olduğunu söyleyebilirim. Suda yürümek ve dondukları takdirde gereksinimleri karşılamak kolaydır. Belki utangaç programcılardan projeleri hakkında bir kod incelemesi ya da başka bir şey hakkında sunum yapmalarını isteyebilirsiniz. Pratik mükemmelleştirir, ya? Ama bu konuda başkalarının tavsiyelerine boyun eğerim.
"Benzer şekilde, ondan nefret ediyorsanız, lütfen nedenini ayrıntılı olarak açıklayın."
Buradaki baraj kapılarını açacak. Ve açık bir şekilde bana bağlanabilecek bir openID kullanmasaydım, muhtemelen ben de dışarı atardım. Gerçekten ne yapmamanız gerektiğinin dev bir listesini istiyorsanız, anonim gönderime daha uygun bir forum isteyin.
Her zaman insanlar genel olarak size onları tedavi daha iyi tedavi olmaz bulundu (onlar daha kötü tedavi olsa da). Şahsen ben (geliştiriciyim) dürüstlüğe dürüstlükle, saygı duymaya, güvene güvenmeye vb. Tarafsız bir atmosferde ekibinizle gayri resmi bir sohbet etmeli ve bize ne söylediğinizi söylemelisiniz. Zehirli “bizlere karşı biz” ortamlarında unutulan nokta, olmalı hepsinin “biz” olması. Hem yönetim hem de işçilerin bunu bilmesi gerekir ve işletme bunu desteklemelidir.
İyi şanslar.
Artık sadece geri bildirimi kabul etmekle kalmayıp aynı zamanda bu konuda hareket ettiğinizi kanıtlamış bir kaydınız var. Daha yüksek karar vericiler üzerinde etkiniz olduğunu gösterdiniz ve ekibiniz için işleri halledebilirsiniz. Bu büyük bir fark yapar. Programcılar benim daha içine kapanık, ama biz programlama hakkında konuşmayı seviyoruz. Gayri resmi bir ortam güzel ama herkesin profesyonel olması gerekiyor. İnsanların biraz hava almasına izin verin, ancak tartışmaların sadece bir orospu oturumu değil, üretken olduğundan emin olun.
Deneyimlerime göre, yöneticimi sevmem veya sevmemem için en önemli faktör, genel olarak gelişimi anlaması ve yaptığım işi anlamasıdır. Bazı olumlu sonuçlar burada listelenmiştir:
Bence, artık programlama yapmıyorsanız ve genellikle sıkı bir proje çizelgesinde veya bütçesinde, geliştiricilerinizin beğenme şansı çok düşüktür. Bu durumda, hızlı bir şekilde yukarı çıkıp doğrudan yönetici olmak için bir başkasına sahip olsanız iyi olur. Üzgünüm, bu paragrafta kulağa kötü geliyordum ama böyle görüyorum. İyi bir insan gibi görünüyorsun ve bazı hakikatleri hak ediyor.
Ben geliştirici mutluluk verimliliği ile tüm küçük şeylere inandığını düşünüyorum. Matematik yönetimi için oldukça harika çalışıyor. Sabah bana bir çörek (-25 sent) ver ve bütün gün iki kat daha fazla çalışacağım (+ birçok dolar). Memnun olmadığımızda yavaşça çalışarak bir şeyleri aktif olarak sabatolamak 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ğumuz zaman kodlamamamız gerçekten daha iyidir.
Ancak tahminler kendi başlarına ele alınmalıdır. Gerçekçi olmayan tahminler hariç, sahip olduğum her sorun bana bir donut vererek çözülebilir. Doğru ya da yanlış bir geliştirici bunu görür: Yönetim daha kısa bir tahminle kazanacak her şeye sahiptir (yeni bir tekne gibi), geliştiriciler kaybedecek her şeye sahiptir (bir aylık uyku değerinde gibi). Yönetim yine de sorumlu, bu yüzden her seferinde tahmini savaşı kazanıyorlar. Tahmin sistemi, geliştiriciler son teslim tarihine karar verdiğinde en iyi sonucu verdiğini düşünüyorum (doğru bir tahmin vermemiz için yeterince zor, bu yüzden bir yönetici nasıl olur?), Ancak yönetim, hiçbir geliştiricinin demiryoluna alınmadığı anlayışıyla onları iddialı olmaya motive eder. biraz uzakta olmak.
Ben de takım elbiseli adamlardan biriyim ve 15 yıldan fazla süredir. Başladığımda bir yazılım geliştiricisiydim ve bir şansım olduğunda hala kod yazıyorum. Bence her iki taraf için de konuşabiliyorum ve bu durumlarda biraz tecrübem var. Ayrıca, personel tarafından seçilen "yılın çalışanı" gibi, bu durumlarla başa çıkmam konusunda kendime güven veren kimlik bilgilerim var.
Çok sık şahit olduğum şey, yönetim ve geliştiriciler arasında alınan değer sistemlerinde ve operasyonel yöntemlerde/yaklaşımlarda önemli farklılıklar olmasıdır.
Birçok geliştirici için samimiyet, dürüstlük ve diğer türlü esnek bir çalışma ortamı listede çok yüksektir. Ne yazık ki üst yönetim listesinde aynı değerler ç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 yol açar. Bundan kurtulmanın tek yolu (benim açımdan) ekibinizin önünde sağlam bir tavır almak, onları tamamen desteklemek ve açık iletişim yoluyla ve en önemlisi söylediklerinizi yaparak güven ilişkisi kurmaktır. (bu genellikle politikanın samimiyeti tamamen aştığı üst yönetimden aldığınızın tam tersidir).
Aynı zamanda kendiniz de operasyonel kalmanız gerekir, bu nedenle üst yönetim ile anladıkları ve oyunlarını oynadıkları bir dilde iletişim kurmanın bir yolunu bulmanız gerekir. Orta yönetimin asıl zorluğu budur.
Soru, yorum veya endişeniz olabilecek bir programcıya ne tür bir tepki verdiğinizi düşünün. "Şimdi ne istiyorsun ?" veya "Neden beni bu ile rahatsız ediyorsun?" nasıl bir cevap? Geliştiricileri endişeleri ve yorumları dile getirmeye ne kadar teşvik ediyorsunuz? Bu sadece bir başlangıç noktası.
İkinci olarak, bu tartışmaları nerede yapmaya çalıştığınıza dikkat edin. Müdürümün her şeyi duymak için olduğunu bilseydim, iş makinemi bir sonraki küpte biriyle tartışmaktan çok açık olacağımdan şüpheliyim. İnsanların açık ve dürüst geri bildirimde bulunmalarını istiyorsanız, yanıtlarının herkese açık olarak yayınlanmayacağını veya onlara karşı kullanılmayacağını bilmek için biraz gizlilik sağlanmalıdır.
Üçüncüsü, ne tür Duygusal Zeka becerileriniz olduğunu düşünün. Proje Yöneticileri için Duygusal Zeka: Üstün Sonuçlar Elde Etmek İçin İhtiyacınız Olan İnsan Becerileri Anthony Mersino, dün bir öğle yemeğinden ve EQ hakkında bilgi edinin. Gerçekten psikolojiye derinlemesine girmek 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 süpürüldü mü? Şikayetler, birisinin gerçekten başını belaya sokabilecek büyük bir hayır mı? Hangi davranışlar ödüllendirilir veya teşvik edilir ve hangileri tolere edilir ve kabul edilir? Bunların bir kısmı gözlem olsa da, bazıları da ofisten uzakta veya gizli dinleme olasılığı olmayan bir odada yapılması gereken bazı konuşmalar gerektirebilir. Başlangıçta bunu kullanmaya çalışırken muhtemelen tekrarlı olacaksınız. Eğer kültür öncelikle herkesin “emmeyi” bildiği bir kültürse, yeni bir uygulama kurmaya ve insanları konuşturmaya çalışmak kötü bir şey değildir. Bu, diğer cevaplardan daha dokunaklı olabilir, ancak çalıştığım yerde bu konuda bana sorulursa bir cevap için vereceğim şey bu olurdu.
Bir geliştirici olarak büyük bir inekim ve sosyal becerilerim yok ve bu konuda özür dilemiyorum. Sonuçta, ben yetenekim ve sen benim yeteneğim için beni işe aldın. İşi yapmak için sosyal kelebeğe ihtiyacınız varsa, geliştiriciler yerine proje yöneticileriyle dolu bir odanız olurdu.
Bazı geliştiricilerin sosyal açıdan çok zeki olduklarını biliyorum, ama medyan içe dönük ineklere doğru eğildiğini düşünüyorum.
Birisi benden bir şey yapmamı istediğinde kesinlikle hiçbir çıkarım yapmam ve tam olarak ne istediğimi yapıyorum. Bazı proje yöneticilerinde her zaman sorunla karşılaşıyorum çünkü kesinlikle yapamayacağım projeler hakkında çıkarımlar yapmamı bekliyorlar, bu yüzden bazen işler tam olarak ne olduğu ortaya çıksa da bekledikleri gibi çıkmıyor talep ettiler. Bazı proje yöneticilerinde bunun olmasının sebebi, yüksek kaliteli HLD'ler, BRD'ler sunmamaları ve siyah beyaz olanlardan ziyade proje yönetiminin sosyal yönüne çok fazla değer vermemeleridir.
Bence dünyalar burada çarpışıyor. Proje yönetimi dünyasında kişisel becerilerin sosyal becerileri ve kalitesi önemli faktörler olduğunu düşünüyorum, ancak benim gibi geliştiriciler için kesinlikle hiçbir şey ifade etmiyor. Bu ya da bu görevin ne kadar önemli olduğu konusunda beni şaşırtmak beni etkilemez. Burada bazı insanların önerdiği gibi öğle veya bira için dışarı çıkmak bile istemiyorum.
Gerçekten istediğim iyi, kaliteli HLD'ler ve BRD'ler. Ulaşılabilecek zaman çizelgeleri ve son tarihler istiyorum ve yeni tasarımlar veya planlar getirilirse, zaman planının ve son tarihlerin yeniden ayarlanmasını istiyorum. Gereksinimlerin anında değiştiği projeler üzerinde çalıştım - bana göre bu, düşük kaliteli proje liderliğiyle uğraştığım kırmızı bayrağım. Bir geliştirici olarak yapabileceğiniz en kötü şey, özellikle zaten bir programa sahip olduktan veya zamanlama taahhüdü verdikten sonra bana günlük olarak yeni proje gereksinimleri getirmektir. Yeni şartlar getirildiğinde, son teslim tarihlerine tazminat ödenmek dayanılmaz. Daha fazla saat çalışıyorum, geç saatlere kadar çalışıyorum, bununla ilgili bir sorunum yok, ama bu her zaman gelişim ile nicel olan bir şey değil. Bazı değişiklikler birkaç saat daha sürebilir, bazı değişiklikler uygun Ar-Ge, test, QA vb. İçin haftalar sürebilir ... Her zaman bir pasta yapmak gibi değildir, bazen gereksinimlerde tek bir değişiklik tüm tarifi değiştirmek gibi olabilir. Proje yöneticilerinin erimiş olduklarına ve konferans görüşmelerinde öfke nöbetleri yaşadığına şahit oldum çünkü son tarihleri ekstra gelişime izin vermeyecek, ancak başlangıç proje gereksinimlerinde olmayan geliştirme talep ediyorlar.
Sadece kendi kişisel önyargımı ve deneyimimi örnek olarak verebilirim, bu yüzden lütfen tüm geliştiriciler adına konuştuğumu anlamıyorum. Bunları sadece kendi kariyerimin mikro kozmosundan görüyorum, ancak bu yazı benim meşhur havluya atmamı sağlayan kesin koşulları açıklıyor.
Geliştiriciler sizin onların savunucusu olduğunuzu düşünüyor mu? Bununla, endişelerini/hayal kırıklıklarını dayak yemeden sizinle paylaşmakta özgür olduklarını bildiklerini mi söylüyorum? Onlar için savaştığını hissediyorlar mı? İşlerini takdir ettiğinizi düşünüyorlar mı? Kariyerlerinde başarılı olmalarını gerçekten istediğinizi düşünüyorlar mı?
Takdir edilirlerse, muhtemelen daha iyi iletişim kuracaksınız.
Kısa ve güzel. Yaptıklarınızda Excel - bu iletişim yaratacaktır.
Mükemmel olmak geliştiricileriniz için ne anlama geliyor? .. Oku, yeniden oku, evet hatta ders PeopleWare
Geliştiricilerinizle ne sıklıkta konuşuyorsunuz? Proje durumu toplantıları, teslim edilebilir şeyler veya onlara getirdiğiniz diğer konulardan bahsetmiyorum - programcılarınızdan biriyle ne sıklıkta oturuyorsunuz, işlerin nasıl gittiğini sorun ve sadece dinle .
Diğer cevapların birçoğu gerçekten iyi - çevik gelişmeye bakmalısınız. Geliştiricilerinizin rollerini öğrenmek ve büyümek için ihtiyacınız var. Ancak, geliştiricilerinizin söylediklerini gerçekten dinlemiyorsanız (veya söylemiyorsanız!), Önce o konuya dikkat etmeniz gerekir.
Bire bir iyi referans - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html
Sadece gelen bir öneriye cevap vermek için birkaçcevaplar zaten. Michael Lopp (aka rands ) geliştiricilerini yönetme ve blogunda "kafalarına girme" hakkında yazıyor, Rands in Repose ve bir kitapta, İnsanları Yönetmek ( kitap kaynakları ). Kitap, 2007'den önce yayınlarından çoğunlukla düzenlenmiş içerikler içeriyor ve blogunun yönetimiyle ilgili bölümlerini yakalamak için iyi bir yol sunuyor (ayrıca kumar ve ayrıca okumak isteyip istemediğinizi de konuşuyor). Yazısı genellikle harika ve genellikle esprili, bu yüzden onu okuma riski çok az.
Partiye geç kaldım, ama sadece bu soruyu gördüm.
Çok iyi hitap etmediğim bir şey:
Grunts hiçbir zaman takım elbise için tüm gerçeği söylemez. Rands bunu DNA olarak söylüyor ama kafa kafaya değinmiyor, farklı bir konuda.
Takım elbise giyiyorsun ve çekleri imzalıyorsun. Şirketin çıkarlarını temsil ediyorsunuz. Mühendisleri temsil etmiyorsunuz. Eğer yapmış olsaydınız, çeklerini imzalamazdınız, onlar sizinkini imzalamış olacaklardı.
Bu elbette size veya mühendislere haber değil. Ancak bir mühendis, işyerindeki bazı sorunları - sorunları - önemli bir çatışmaya yol açacağını bildiğinde - risk/ödül ödünleşimi mühendisin lehine değildir. Mühendislere, işyeri kültürü kavgalarını başlatmak yerine ürün üretmeleri için ödeme yapılır. Bunlara dahil olmak işi yanlış yapmanın hızlı bir yoludur.
Bu nedenle yönetim görevinin bir kısmı, mühendislerin kurumsal politika ve kariyer tepkisine maruz kalmadan sorunlara açık olmalarını sağlamaktır. Ne de olsa yükselişe sahip olmak güzel, ve orada diğer diğer şirketler, eğer bu kendiliğinden hissetmiyorsa.
Takımı bira için çıkar (ve satın alıyorsun).
Yukarıdaki yazılarda tüm harika fikirler ve yorumlar!
İşte bir fikir: I.T. Tabii ki şirket tarafından ödenen yerel topluluk kolejinizdeki iletişim atölyelerine personel.
A) Çalıştayların iyi bir itibara sahip olduğundan ve b) çalışanlarınızı birlikte göndermemekten emin olun. Birbirine bağlı kalmaya ve diğer sınıf üyeleriyle karışmaya değil, sadece atölyelerin değerini düşürmekle kalmayıp, diğerlerine de bozulmaya neden olacaklar.
Üretken takım odaklı iletişim, herkesin öğrenebileceği bir beceridir, ancak çoğu skolastik yolda eksik olduğunu düşündüğüm bir konudur.
Bu fikir hiçbir şekilde sihirli bir mermi değildir, ancak bulmacanın iyi bir temel parçasıdır. Ortaklarınız birbirleriyle daha iyi iletişim kurmayı öğrenmekle kalmayacak, aynı zamanda işinizi daha iyi anlamaya ve saygı duymaya başlayacakları bonusu da olacaktır (iletişim PM'nin merkezinde yer almaktadır).
Sadece 2 bitim :)
Kimse tam olarak sorunuzu ve konunuzu ele alan bu harika kitaptan bahsetmediğine şaşırdım - "Peopleware: Üretken Projeler ve Takımlar", DeMarco ve Lister . Editörden: yazılım geliştirmenin ana konuları teknik değil insandır . Durumunuzda olsaydım Amazon hakkındaki ilk üç inceleme beni bu kitabı almaya ikna etmek için yeterli olurdu.
Uzun yıllar boyunca çeşitli roller yaptım - geliştirici, üst düzey geliştirici, teknik lider vb.
Sorunuzdan, geliştiricilerinizin size bir şey söylemediği açıktır, çünkü yardımcı olabileceğinizi düşünmezler.
Bunun 2 nedeni olabilir.
Yukarıdakilerden herhangi biri veya tümü ise, düzeltmeniz gerekir.
Buradaki cevapların çoğunun çok iyi noktaları var, ama sadece yardımcı olabilecek birkaç kaynak atmak istiyorum. Ya devasa bir karmaşaya karışan ya da ilgili insanlar arasındaki iletişimden dolayı çok verimli bir şekilde çözülen birkaç durumda bulundum. Üç kitap, özellikle hatta çok fazla şeyin olduğu yüksek stresli durumlarda iletişim becerilerimi kişisel olarak geliştirmeme yardımcı oldu:
Sorunuzu okuduğunuzda, iletişimin değerini gördüğünüzü düşünüyorum. Şahsen iletişimin bir yönetici veya lider için iş veya teknik becerilerden daha önemli olduğunu hissediyorum. Lider olduğunuz kişiler, projenin çoğunu yapmak için ihtiyaç duyduğunuz zor becerilere sahip olmalıdır. İyi bir teknik lider veya proje yöneticisi, ister ekip içinde ister ekip ile müşteri veya ekip ve işletme tüzel kişiliği (hatta bu üçünün birleşimi) arasında olsun, iletişime odaklanabilmelidir.
Teknik iş gücünün perspektifleri hakkında fikir veren birkaç harika roman okuyun:
Bunlar yönetim ile ilgili herhangi bir tipik anı kadar önemlidir (Drucker ve ark.).