Programcı arkadaşlarınızın büyümesine nasıl yardımcı oluyorsunuz?


20

Bir ekip lideri olarak, programcılarınızın büyümesine nasıl yardımcı olabilirsiniz?

Bunu sormamın nedeni, benimle çalışan birkaç programcı olması ve gerçekten "potansiyelini açmak", maksimum potansiyellerini gerçekleştirmek ve onları mutlu etmek istiyorum.

Ama bunu nasıl yapacağımı tam olarak bilmiyorum, yapmak zorunda mıyım

  1. Onlarla sık sık etkileşim kurun veya sessiz zaman tanıyın, rahatsız edilmeden bırakın?
  2. Onlardan birim testleri, kodlama stilleri uygulama gibi kodlama yönergelerini izlemelerini isteyin veya uygun gördüklerini yapmalarına izin verin?
  3. Onlara karşı nazik olun. Gerçekten 8 saat mi yoksa 4 saat mi işe başladıkları ya da işyerinde bazı “disiplinleri” zorunlu kılmaları gerekmiyor mu?

Tahmin edin, her pozisyonun kendine özgü noktaları vardır ve farklı insanlar farklı şeyler için tartışırlar. Bu tür karışıklıklar insanları yönetmeyi süresiz olarak zorlaştırır.

Ne düşünüyorsun?


21
Çöreklerle besleyin.
SK-logic

1
Her programcı farklı çalışır. Bize neyi başarmak istediklerini anlatmalısınız. Bunu biliyorsanız, yapmanız gereken tek şey onlara ihtiyaç duydukları araçları sunmak, diğer ekiplere neler üzerinde çalıştıkları hakkında konuşmak ve herkesi birbirlerine yardım etmeye teşvik etmektir. Bu, ekibinizin hedefi zaten tanımlanmış olsa bile geçerlidir, çünkü bu durumda bile, bu hedefe nasıl ulaştıklarına dair özgürlüğü korurlar. Öte yandan, Scrum bu tür davranışlarla iyi oynamaz.
Thaddee Tyl

@ SK-logic: Çalıştığım yerde yuvarlak, pizza tercih edilen yöntemdir.
Donal Fellows

Yanıtlar:


9

Yürümeniz gereken çok ince bir çizgi.

Sonunda, verdiğiniz teknik kararlar yaşamak zorunda kalmayacağınız kararlardır. Bu yüzden mümkün olduğunca azını yapın, onlarla yaşamak zorunda olan insanların kendi seçimlerini yapmasına izin verin. Ama kötü bir yolda ilerlediklerini düşünüyorsanız onlara rehberlik edin.

Öte yandan, süreç seçenekleri sizindir. Bu kararlarda, ekibin size rehberlik etmesine izin verin, ancak nihayetinde bunları yapmanız gerekir. En azından ilk başta.

Roy Osherove'un Bir Yazılım Ekibinin Üç Olgunluk Aşaması'nı okuyun ve ekibinizin şu anda hangi aşamada olduğunu anlayıp anlayamayacağınızı görün. Bu, davranış biçiminizi etkilemelidir. Daha kaotik, kontrolleri daha fazla yerine koymak zorundasınız. Örneğin. Son derece kaotik bir ekipte, taahhüt edilen tüm kodları gözden geçirerek başlamanız gerekir. Ancak bunu yaparken, birbirlerinin kodlarını incelemelerini öğretmek için zaman ayırın.

Ve eğer bir takımı Kaos'tan Orta Yaş'a çekmeyi başarırsanız, o noktada davranışınızı değiştirin, aksi takdirde daha fazla ilerlemeyeceklerdir (bu son kişisel deneyimden).


6

Evet, insanları yönetmek, bilgisayarları veya yazılımları yönetmekten kesinlikle daha zordur, çünkü her insan farklıdır ve her geçen gün değişebiliriz. Yani evrensel bir cevap yok. Onları tanımak ve bireysel güçlü / zayıf yönlerini, çalışma ve öğrenme tutumlarını, vb. Anlamak için geliştiricilerinizle çok fazla iletişim kurmanız gerektiğine inanıyorum. çok fazla iletişim ve atölye çalışması ya da sessiz bir köşede kendi kendine öğrenme.

IMHO geliştiricileri normal şartlar altında doğal bir öğrenme dürtüsüne sahiptirler (daha önce kötü bir iş tecrübesi tarafından yakılmadıkça veya bitmedikçe). Tek yapmanız gereken, neyi ve nasıl öğrenmek istediklerini anlamak ve onlara bunu yapmak için gerekli araçları ve zamanı sağlamaktır (elbette makul sınırlar dahilinde).

Örneğin ekibimizde, proje ile bir şekilde (doğrudan veya dolaylı olarak) ilgili olduğu sürece, kendimiz için öğrenme görevlerini özgürce tanımlayabiliriz. Bu görevler genellikle sprint başına birkaç saat ile bir gün arasındadır (yine de her sprintte değil). (Son bir örnek: Scala ile öğrenmek ve denemek için bir görev aldım, bunun temel olarak - ve genel olarak işlevsel bir yaklaşım - Java kodumuzun karmaşık bir bölümünün basitleştirilmesine yardımcı olabilir.) Bunlara öncelik verilir ve Sprint, tıpkı normal görevler gibi. Ayrıca öğrendiklerimiz hakkında demolar / dersler yapmak, bilgiyi diğer ekip üyelerine (ve hatta potansiyel olarak farklı ekiplerdeki geliştiricilere) aktarmak teşvik edilir ve beklenir.

Onlardan birim testleri, kodlama stilleri uygulama gibi kodlama yönergelerini izlemelerini isteyin veya uygun gördüklerini yapmalarına izin verin?

Bir ekip içinde çalışırken, aynı geliştirme sürecini takip etmek şarttır. Tabii ki, bu süreç 600 sayfalık bir kılavuzda tarif edilen bir şey değil, muhtemelen çalışabilecek en basit şey olmalıdır. Ve süreç takımın kendisi tarafından tanımlanmalı ve sürekli olarak duruma uyarlanmalıdır . Eğer takım bir kodlama standardı ve TDD'yi kabul etmişse, bunu izleyeceklerdir.

Onlara karşı nazik olun. Gerçekten 8 saat mi yoksa 4 saat mi işe başladıkları ya da işyerinde bazı “disiplinleri” zorunlu kılmaları gerekmiyor mu?

Bir geliştiriciyi bilmiyorsanız, ne yaptığını, teslimatlarını, çalışma ritmini vb. Daha yakından takip etmek normaldir. Kodunu (kendiniz veya deneyimli ve güvenilir bir ekip) gözden geçirmek de uygundur. üyesi). Güven kazandıktan sonra, giderek daha fazla özgürlük elde edebilir. Ancak önce bu güven kazanılmalıdır. Çalışma saatleri hakkında, tecrübelerime göre esnek saatler bir sınıra kadar büyüktür, yani geliştiricilerin işyerlerinde (genellikle) bulundukları günlerde her gün 11:00 ile 14:00 arasında ortak bir mutabık kalınan minimum değere sahip olmak iyidir. sorularla yaklaşılabilir veya toplantılara davet edilebilir. Ama bunun dışında katı olmanın bir anlamı yok.


3

Tamam bir ipucu olarak projeleri kapı dışarı almak sizin işiniz. Bu nedenle, standartları uygulayan, kod incelemelerini uygulayan, ilerleme raporları isteyen ve geliştiricilerin bunları yalnız bırakmayı tercih ettiği tüm şeyleri siz olmalısınız. Bunlar sadece yönetim gereklilikleridir ve kod incelemeleri dışında çalışanların becerilerini gerçekten geliştirmezler.

Bununla birlikte, bir liderin büyük bir özelliği olan büyümelerine yardımcı olmak istersiniz.

Kod incelemeleri kesinlikle ilk adımdır, kimin yıldızlardan daha az beceriye sahip olduğunu ve tatmin edici performansa sahip olmak için iyileştirmeye ihtiyacı olduğunu görmenize yardımcı olacaktır. Geliştiricilere, bir şeyler yapmanın ve kod tabanının kişisel olarak çalıştıklarından farklı bölümlerini anlamalarının başka yollarını görmelerine yardımcı olacaklar. Bence, kod incelemeleri en iyi geliştirici ve gözden geçiren ile bir konferans odasında şahsen yapılır (kim her zaman lider değil, başka bir geliştirici olmalı, başkalarının kodunu gözden geçirmek de geliştirilmesi gereken bir beceridir) ve siz bir moderatör. Trendleri tanımlamak için nelerin değiştirilmesi gerektiğine dair notlar tutmalısınız. Gerçekten aradığınız şey hatalar veya değişikliklerdir (herkesin kodu geliştirilebilir), ancak hatalardan öğrenmede sürekli başarısızlıktır. Üst yönetime bu notları tuttuğunuzu söylemeyin, aksi takdirde bunları, performansı gözden geçirme sürecinde amacı açıkça alt eden ölçümler olarak kullanmak zorunda hissedeceksiniz. Birkaç geliştirici aynı hataları yapıyorsa, X'in nasıl yapılacağı konusunda bir eğitim oturumu veya wiki girişi olabilir.

Şimdi asgari seviyeye ulaşan büyüyen yardımcısı. İlk olarak, geliştiricilerin hangi beceri setlerine sahip olduklarını ve sahip oldukları beceri setlerinin ne olduğunu ve neleri öğrenmek istediklerini bilmeniz gerekir. Onlarla konuşmanız ve özgeçmişlerini gözden geçirmeniz ve neyi sevdiklerini anlamanız ve yapmaktan hoşlanmıyorum.

Tüm ilginç ödevleri sadece en yetenekli kişilere vermeyin. Bu, diğerlerinin yeni problemleri ve teknolojileri hızlandırmasına yardımcı olmaz. Birisi size bir şans tanımazsa ve size daha zor işler atamazsa, sadece en küçük ve en az önemli görevleri üstlenen en genç adam olmaktan çıkamazsınız. Bununla birlikte, daha ileri beceriler elde etmek için daha az deneyimli olanın bir kıdemli ile programı eşleştirmesi gerekebilir. Çocukları kod incelemelerine dahil etmek de onları daha gelişmiş tekniklere maruz bırakacaktır.

Önce onlara sorunu kendileri anlama fırsatı verin. Ancak bazen insanlar sıkışıp kalırlar ve nereden başlayacaklarını (özellikle yeni programcılarda da gelişmeniz gereken bir beceri) veya bir sorunu çözmek için ne yapmaları gerektiğini bilmezler.

Onlara bir şeyi araştırmaları için birkaç gün verirseniz ve yine de bir şeyleri nasıl yapacaklarına dair bir yönleri yoksa, bazı önerilere müdahale etmeniz gerekebilir. Kendiniz teknik iseniz, onlara sorunun nasıl çözüleceğine dair bazı fikirler verebilirsiniz. Değilse, fikirleri beyin fırtınası yaptığınız birkaç kişiyle toplantı, kişi sıkışmışsa yardımcı olabilir. Ya da daha deneyimli bir kişiden bazı önerilerde bulunmasını istemek. Yapmak istemediğiniz şey sorunu onlardan alıp kendiniz çözmektir. Ancak projenin programcı ego ile yapılmasını dengelemek zorundasınız ve bazen belirli bir yönde göndermeniz gerekir. Kötü bir çözümü varsa ve düzeltilmesi gerekiyorsa, programcıyı ateşlemek istemediğiniz sürece yapabileceğiniz en kötü şey başka birine vermek.

Başkalarının yaptıkları hemen hemen her şeyi düzeltmesi gereken kötü programcıların kodlanmış olduğunu gördüm. Diğer programcılar buna kızar ve sadece kişinin hayatından çıkmasını ister. Kötü bir programcı kodlamak iyi programcıların ayrılmasına yol açar. Kodlama ve geliştirme becerileri arasındaki çizgiyi bulmak zorundasınız. Birine birkaç şans verirseniz ve hiç iyileşmezse, onu gevşetin.

Mevcut beceri setlerinde zaten yetkin olan yaşlılar için işler daha kolaydır. Genellikle onlara yeni bir şeyler yapma fırsatı vermeniz gerekir ve onlar atlayıp öğrenirler. Sadece ilginç fırsatların yayıldığından emin olun ve hepsi bir şeyleri düzeltebilecek olan Wonder the Joe Programmer'a gitmeyin. Sonunda sadece bir tane değil on tane Joes elde etmek istersiniz.

Beceri geliştirmenin bir başka yolu da haftalık 1 saatlik eğitim seansına sahip olmaktır. Her geliştiriciyi belirli bir konudan sorumlu tutun. Bu, iletişim kurma konusunda daha iyi olmalarına yardımcı olacak, derinlemesine bir şey araştırmalarını sağlayacak ve herkese araştırmalarından fayda sağlayacaktır. Bazı konular, bu konuda bilgi sahibi olmaya zorlamak için konuyla ilgili familair olmayan kişilere atanmalı ve bazıları bu konuda yerel uzmanlar olduğunu bildiğiniz kişilere atanmalıdır. Konular, insanların furture yakınında veya şu anda iyi olmaları için ihtiyaç duyduğunuz şeyler ve şu anda kullanmadığınız yeni gelecek teknolojilerin bir kısmı için bir kombinasyon olmalıdır, ancak insanlar faydalı olup olmadıklarını öğrenmek için araya girmiştir. Ancak en genç olanlar dahil herkese bir konu verilmelidir.

Geliştiricilerinizin zamanının nasıl faturalandığına bağlı olarak (bu, bir müşteri faturalandırma durumunda daha zordur), geliştiricilerin kişisel projelerde çalışması için haftada 4-8 saat olması genellikle buna değer. Bunu yapmaktan heyecan duyacaklar. En iyi insanlar orada çalışmak isteyecek ve gelecek için yararlı olacak çok şey öğrenecekler. Fasulye sayaçlarının bunun ihtiyacını anlaması zordur, ancak bu kez çalışan memnuniyeti, kimsenin ihtiyaç duymadığı (veya angaryaların bir kısmını otomatikleştirmeye yardımcı olacak) yeni özellikler veya yazılımlar ve daha hızlı gelişme nedeniyle birçok kez geri ödenecektir. yeni teknikler öğrenildi. Bazı geliştiriciler bu zamanı kesinlikle yaptıklarınızla ilgili olmayan kişisel projeler için kullanacaktır (ve bu iyi, yine de yetenek kazanacak ve fırsattan memnun kalacaklar), ancak birçoğu bunu, projelerin nasıl yönetildiğinin doğası gereği herkesin önceden düzeltmek için zamana sahip olduğu kalıcı problemleri çözmek için kullanacaktır. Böylece herkese fayda sağlayan yeniden düzenlemeler alabilirsiniz; bazı insanlar yeniden düzenlemeyi kolaylaştırmak için test kapsamını iyileştirmek için testler yazabilir; bazıları ise yazılımınızı müşterileri için daha kullanışlı hale getirebilecek bazı yeni özellikleri keşfedebilir. Genel olarak, fasulye sayaçlarını ikna edebiliyorsanız, bu özgürlüğe izin vererek kaybetmenin bir yolu yoktur.

İnsanların becerileri için biraz gerilmesine izin vermek ve projeyi takip etmek için nasıl denge kuracağınızı öğrenmelisiniz. Geliştirici ne kadar az deneyimli olursa, özellikle yön değiştirmenin daha kolay olduğu ilk aşamalarda bir kişinin ilerlemeyi kontrol etmesi gerekir. Deneyimsiz olanlar mücadele etmekte ve konuşmaktan korkmaktadırlar. Bu insanlar lansmandan hemen önce ayrılma eğilimindedir ve projenin bir kısmının yapılmaya yakın bir yerde olmadığını görürsünüz. İşlerini sık sık değiştiren herhangi bir kişinin ilerlemesini kontrol etmeye özellikle dikkat edin (müteahhit olmadıkları sürece sözleşmenin niteliği olmadığı sürece).

Daha deneyimli olan, genellikle çözümü bulma konusunda sorun yaşadıklarını ve bölgede daha fazla bilgiye sahip birinden biraz yardıma ihtiyaç duyduklarını söylemek için güvenilir olabilir veya o kişiyi arayacak ve bilgi transferini alacaktır. Bu yüzden, bir proje için yeni bir beceri seti öğrenmenin başlangıç ​​aşamalarında yakından izlenmelerine gerek yoktur. Projeyi teslim etmenin bir yolunu bulacaklar. Teslim geçmişine sahip olanlar, asgari ilerleme raporları dışında genellikle yalnız bırakılabilir (genellikle yönetiminize de rapor vermeniz gerekir ve bu nedenle bazı bilgilere ihtiyaç duyarsınız).


1
Takım lideri olarak iyi bir iş yapmak ve bir takımın büyümesine yardımcı olmak arasında bir ayrım yapma konusunda +1. Ekleyeceğim tek şey, her üyenin kuruluş dışındaki diğer profesyonellerle etkileşim kurma fırsatına sahip olmasını sağlamaktır. Bu, atölye çalışmaları, konferanslar veya diğer buluşmalar yoluyla yapılabilir. Bir takım lideri bunu doğrudan gerçekleştiremeyebilir, ancak kesinlikle izin verme gücüne sahip olanı etkileyebilir.
Angelo

2
  1. Ekibinize zorlu işleri ve bunları çözecek araçları verin. İşinizi sıradan görüyor olsanız bile, sadece eski bir sistemi destekliyorsunuz, daha iyi hale getirmek için herkesi itin.
  2. Ekibiniz kodlama standartları geliştirmelidir. İşiniz, standartları uygulama ve uyarlamalarına yardımcı olmaktır.
  3. Bir tahmin sistemi geliştirmek için ekibinizle birlikte çalışın. İşiniz bu çabayı ekiple koordine etmek ve uygulama sağlamaktır. Dış kuvvetler kalite kodunu zamanında bekler ve her zaman makul değildir veya istekleri için herhangi bir mantık sağlamazlar. Bundan kaçamazsın, ama her iki tarafı da yönetmelisin. Ekibiniz işleri halletmek için bir üne kavuştuğunda, herkes zaman tahminlerinizi daha fazla kabul edecektir. Eğer çaba gösteriyorlarsa onları destekleyeceğinizi bilmeleri gerekir.

İşinizin zorlamak olduğunu söylediğimde, bir çeşit Draconian liderlik tarzını üstlenmek istemiyorum. Bir grup yetenekli birey, nasıl davranacaklarına dair girdi elde ettiğinde, kurallara uymamaları için sonuçları da kabul etmelidirler. Birisi eninde sonunda sorumlu ve o takım lideri olduğunuzdan, sizsiniz.


1

Onlarla sık sık etkileşim kurun veya sessiz zaman tanıyın, rahatsız edilmeden bırakın?

Onlarla sık sık etkileşim kurun. Açıkçası onları rahatsız etme noktası değil, menajeri olarak işlerin nasıl gittiğiyle ilgili daha düzenli görüşmeler yapmalı ve daha genel chit chat yapmalısınız. Kabaca birkaç saatte bir doğru frekansı çalar, ancak kulaktan çalar.

Onlardan birim testleri, kodlama stilleri uygulama gibi kodlama yönergelerini izlemelerini isteyin veya uygun gördüklerini yapmalarına izin verin?

Onların tam olarak aynı standartlarda çalışmasını beklemelisiniz. Birim testleri yaparsanız ve kılavuz çizgileri takip ederseniz, bunlar yapılmalıdır. Bunları iyi kodlamayı ve onlara öğretmek sizin sorumluluğunuzu öğrenmeleri gerekir.

Onlara karşı nazik olun. Gerçekten 8 saat mi yoksa 4 saat mi işe başladıkları ya da işyerinde bazı “disiplinleri” zorunlu kılmaları gerekmiyor mu?

İlk başta daha disiplinli olurdum ama güvenilir olduklarını kanıtladıklarında rahatlarlar. İnsanlara 4 saatten daha uzun süre çalışma konusunda güven vermek, sorun istemektedir, ancak düzenli olarak geç saatlerde çalışan değerli bir çalışanın projeler arasında biraz gevşek olmasına izin vermek iyidir.


5
"Kabaca birkaç saatte bir doğru frekans geliyor" - Eğer yöneticim sık sık beni sıkmaya devam ederse kişisel olarak nefret ediyorum ...
Péter Török

1
@ Péter Török Bu yüzden kulaktan oyna dedim. Bu benim için doğru seviye ama eminim bir sürü insan daha az tercih eder
Tom Squires

0

Üç noktanızla ilgili:

Onlarla sık sık etkileşim kurun veya sessiz zaman tanıyın, rahatsız edilmeden bırakın?

Bunun gerçekten birlikte çalıştığınız kişinin türüne bağlı olduğunu söyleyeceğim. Bazıları sabit kahve saatinde (sabah 10 civarında) tartışmayı ve başka türlü yalnız çalışmayı, rahatsız edilmeyi tercih ediyor. Onlarla (Tamam, itiraf edeceğim, aynen böyle olduğumu), genellikle e-postaları gönderiyorum (yakınımdayken bile, 2-3 metre uzakta gibi), böylece bilgilerinizi okuduklarında seçiminizi bırakabilirsiniz . Ve bu arada, onlara "notunuzu alıp almadıklarını " sormayın :-) Ve tabii ki, bazı "daha fazla rehberlik, daha fazla etkileşim" gerekir.

Onlardan birim testleri, kodlama stilleri uygulama gibi kodlama yönergelerini izlemelerini isteyin veya uygun gördüklerini yapmalarına izin verin?

Aşağıdaki yönergelere gelince, bu benim için oldukça açık. Eğer kodlama stili ile ilgili kurallar ayarlarsanız, her zaman sağlamak test durum kuralı, vb o zaman var sen kurşun geliştirici iseniz bunları uygulamak için. Yönettiğiniz proje için, her geliştirici " süperstarlar " için bile bir istisna olmamak üzere kurallarınıza uymalıdır .

Onlara karşı nazik olun. Gerçekten 8 saat mi yoksa 4 saat mi işe başladıkları ya da işyerinde bazı “disiplinleri” zorunlu kılmaları gerekmiyor mu?

İnsanların nasıl çalıştığını zaten biliyor ve güveninizi kırmayacaklarından daha eminseniz disiplini rahatlatabilirsiniz. Ancak bu nokta için tanımladığınız kuralın (veya kuralsızlığın) herkes için geçerli olduğunu düşünüyorum. Önemli olan istisna olmamasıdır. Şu anda "haftada 40 işinizi yaptığınız ve işiniz bittiği sürece sorun yok" diyen bir proje yöneticisi için çalışmaktan çok mutluyum. Bu şekilde bir sabah geç gelebilir, sadece 6 saat çalışabilir ve sonraki iki gün 9 saat çalışabilirsiniz. "İş yapıldığı sürece" önemli değil. Bu kuralı seviyorum.


0

Geliştiricilerinizin sahip olduğu deneyim miktarının (sadece programlama değil, aynı zamanda iş ortamlarında da) onlarla ne kadar zaman geçirdiğinizde kilit bir unsur olduğunu söyleyebilirim. Şu anda okuldan yeni çıkmış bazı geliştiricilerle çalışıyorum ve sadece dokümantasyon / test / standartlar yolunda değil, aynı zamanda kişiler arası yollarla (ne zaman sadece e-posta göndermek yerine telefonla arayın veya yüz yüze görüşün). Aynı kelimelerin birçoğu iş bağlamımızda bir yazılım geliştirme bağlamından çok farklı kullanıldığı için, işimizin bilgisi de öğrenilmesi gereken önemli bir şeydir. Ve bu kısaltmalara gelmeden önce ...


0

Ama bunu nasıl yapacağımı tam olarak bilmiyorum, yapmak zorunda mıyım

  1. Onlarla sık sık etkileşim kurun veya sessiz zaman tanıyın, rahatsız edilmeden bırakın?
  2. Onlardan birim testleri, kodlama stilleri uygulama gibi kodlama yönergelerini izlemelerini isteyin veya uygun gördüklerini yapmalarına izin verin?
  3. Onlara karşı nazik olun. Gerçekten 8 saat mi yoksa 4 saat mi işe başladıkları ya da işyerinde bazı “disiplinleri” zorunlu kılmaları gerekmiyor mu?

Benim önerim, o birey için hangi stilin en iyi şekilde çalıştığı ve zaman içinde ince ayar hakkında bazı konuşmalar yapmaktır. Bazı insanlar işlerin nasıl gittiğini gözden geçirmek için günde bir kez buluşmak isterken, diğerleri çeyrek kez aşırı olabilir. Bazı insanlar her ay resmi bir yazılı performans incelemesi isteyebilir ve diğerleri sadece performans hakkında bir sohbet isteyebilir. Kilit nokta, biriyle neyin işe yarayıp neyin işe yaramadığı konusunda dürüst olabileceğiniz sahne ile ilişki kurmaktır.

Bunun ters tarafı, kişisel gelişim felsefelerini incelemek olacaktır, ancak birisi yanlış analiz edilirse bu zor bir yol olabilir. Bu tür felsefelerin birkaç örneğini istiyorsanız, birkaç örnek için Myers-Briggs, Enneagram ve Strengths Finder 2.0'a bakabilirsiniz.


0

Onlara nasıl çalışmayı tercih edeceklerini soruyorsunuz .
Neyi değiştirmek istedikleri vb.

Hepsi aynı anda değil. Sadece ... her ţey göründüđünde.
Doğal kalın. (ya da korku kokusu duyarlar)

Ve sonra ... onlardan bir şeyler bile öğrenebilirsiniz . Durumun böyle olacağını düşünmüyorsanız, (eğitim ve deneyimde çok fazla mesafe) onları büyütmeye çalışmaktan gerçekten rahatsız etmeyin, sadece onları karıştırır.

(O özel durumda, pes ve demir bir yumrukla kural bu, ilgi taklit daha dürüst sen onları yok)

Demokratik bir süreç kurun , işleri oylayın, sorunları tartışın.

Dışarıdaki her cumhurbaşkanı gibi, son sözü saklıyorsun : veto .
Gerisi gruba kalmış.


0

İnsanlarınızın büyümesine yardımcı olmanın bir yolu, en iyi yaptıkları şeyi yapmalarına izin vermektir.

Eğer şanslıysanız, kişisel "test" standartları bölümün standartlarından daha katı olan bir veya iki programcıya sahip olacaksınız. Bu durumda, bunları bu konular için "onur sistemine" koyabilir, hatta yöntemlerini benimseyebilirsiniz.

"Esnek zaman" ile daha üretken çalışanlarınıza daha fazla zaman ayırabilirsiniz. İşi yaptıkları sürece çalışma saatleri konusunda daha az endişe duyarım. Bazı insanlar gelir, 5-6 "kesintisiz" saat koymak ve 10 yavaş tempolu saat koymak diğerlerinden daha fazla elde.

Ancak yönetici olarak işlerinizden biri ZAYIFLIKLARI düzeltmektir. Yani, test standartları yetersiz olan özensiz programcılara veya yeterince üretken olmayan insanlara zaman ayırmadıkları için BEAR DOWn gerekir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.