Jak zarządzać programistą, który ma słabe umiejętności komunikacyjne

Zarządzam małym zespołem programistów aplikacji, która znajduje się w połowie cyklu życia, w dużej firmie. Niestety oznacza to, że zadania programistyczne są zwykle dzielone w proporcji 30/70 do „innych prac technicznych”. Ta praca obejmuje:

• Praca z zespołami DBA / Unix / Network / Loadbalancer przy różnych zadaniach
• Składanie zamówień na sprzęt lub infrastrukturę i zarządzanie nimi w różnych regionach
• Uruchamianie testów, które nie zostały jeszcze zmigrowane do CI
• Analiza
• Wsparcie / dochodzenie

Można śmiało powiedzieć, że wszyscy programiści woleliby kodować, zamiast wykonywać te bardziej przyziemne zadania, dlatego staram się rozdzielać zabawne zadania programistyczne równomiernie w zespole.

Większość zespołu została zatrudniona, ponieważ chociaż mogą nie mieć elitarnych umiejętności programowania, aby napisać własny kompilator / silnik gry / system handlu o wysokiej częstotliwości itp., Są dobrymi komunikatorami, którzy „potrafią załatwić sprawę”, współpracują z innymi zespołami i nieco poruszaj się tutaj po złożonej biurokracji. Są dobrymi programistami, ale są także dobrym personelem technicznym.

Jednak jeden członek zespołu prawdopodobnie ma ponadprzeciętne umiejętności kodowania, ale poniżej średniej umiejętności komunikacyjne. Tradycyjnie poprzedni Kierownik ds. Rozwoju zwykle dawał mu zadania związane z programowaniem, a nie bardziej przyziemne zadania wymienione powyżej. Nie uważam jednak, aby było to uczciwe dla reszty zespołu, który wykazał się umiejętnością rozwijania dobrze zaokrąglonego zestawu umiejętności, który jest zwykle wymagany w dziale IT dużych firm.

Co powinienem zrobić w tej sytuacji? Jeśli nadal będę mu dawać więcej pracy programistycznej, wiem, że będzie to zrobione szybciej (i odwrotnie, spodziewałbym się, że ukończy drugą pracę wolniej). Jest to jednak sprzeczne z moimi zasadami i promuje ideę, że możesz stworzyć dla siebie „wygodną niszę”, po prostu źle wykonując zadania, których nie lubisz.

Chcę wyjaśnić, że nie próbuję rozwiązać tego problemu z powodu urazy lub że mam „chip na ramieniu”, jak wspomniano. Szukam porady, jak utrzymać zgrany zespół, który jest szczęśliwy i zmotywowany. Obserwując różnorodność odpowiedzi na to pytanie, wydaje się, że istnieje wiele różnych opinii na temat tego, jak to osiągnąć.

Wygląda na to, że wkładasz zbyt wiele wysiłku w posiadanie dobrze zaokrąglonych osób, a zbyt mało wysiłku w posiadanie dobrze zaokrąglonej drużyny .

Nie ma nic złego w byciu dobrym w czymś - w rzeczywistości prawdopodobnie dlatego został zatrudniony! Powinieneś być wdzięczny, że na początku masz kogoś, kto jest dobry w programowaniu.

Powiedziałeś:

... jest to niezgodne z moimi zasadami i promuje ideę, że możesz stworzyć dla siebie „wygodną niszę”, po prostu źle wykonując zadania, których nie lubisz.

Gdyby był miernym programistą, zgodziłbym się. Ale tego nie powiedziałeś. Powiedziałeś, że był dobrym programistą. Nie jest zły na inne zadania, aby się z nich wydostać - po prostu koncentruje swoje wysiłki na zostaniu lepszym programistą. Nie ma w tym nic złego.

Jako menedżer nie jesteś odpowiedzialny za to, aby każdy był „dobrze zaokrąglony”. Twoim zadaniem jest upewnić się, że s *** zostanie zrobione. I ty tego nie robisz. W rzeczywistości podejmujesz decyzje, które uniemożliwiają załatwienie sprawy.

Niezależnie od tego, jaki masz problem, musisz sobie z tym poradzić - zmniejszasz produktywność swojego zespołu.

Łapiesz trochę ciepła w innych odpowiedziach na twoją decyzję, by „zrobić coś” z tym facetem, ale w pełni rozumiem, co mówisz. Jeśli inni członkowie zespołu „wszyscy woleliby kodować, zamiast wykonywać te bardziej przyziemne zadania”, będą zirytowani, że nagradzasz słabą wydajność słabego komunikatora , dając mu tylko zadania, których wszyscy chcą.

Wyobraź sobie, że jesteś jednym z „dobrych komunikatorów” w zespole, którego umiejętności są porównywalne z danym twórcą. Obsługujesz połączenia, współpracujesz z innymi pracownikami spoza działu IT, którzy ledwo znają mysz na klawiaturze, spisujesz plany wylogowania użytkownika i wiele więcej, wszystko dlatego, że szef tak mówi. Tymczasem zrzędliwy twórca, ponieważ ma „słabe umiejętności komunikacyjne”, cały dzień siedzi w swojej kostce, ignorując użytkowników pracujących tylko nad „zabawnymi” rzeczami.

Teraz powiedziałeś, że zrzędliwy twórca ma umiejętności „ponadprzeciętne”, ale nie powiedziałeś, że był najlepszy. Oznacza to, że może 1/3 twojego zespołu, ci dobrzy deweloperzy komunikacyjni, którzy są na poziomie umiejętności złego dewelopera lub wyższym, wszyscy czują się wkurzeni.

Czy warto tracić produktywność od NAJLEPSZYCH PRACOWNIKÓW, ponieważ są zirytowani złym humorem? Musisz zdecydować.

Chyba że chcesz zwolnić faceta, sugeruję zastosować jedno z następujących podejść:

1) Mentor go, aby był lepszym komunikatorem. Tylko Ty możesz stwierdzić, czy jest to wykonalne. Może się okazać, że trzymanie go za rękę może trochę pomóc. Niektórzy ludzie są po prostu przerażeni formalnymi interakcjami biznesowymi i wyrażają to poprzez wkurzenie, gdy są o to poproszeni.

2) Zachęcaj do „dobrej komunikacji” za pomocą pieniędzy lub innych korzyści. Wyjaśnij, że naprawdę cenisz dobrych komunikatorów, a wtedy twoi twórcy nie będą tak zirytowani, ale nagroda musi być prawdziwa i znacząca. „Lunch z dyrektorem dzielnicy” nie da rady. Nagroda „star player / kudos / attaboy” nie będzie też kawałkiem papieru. Muszą to być dodatkowe pieniądze, dodatkowy urlop, trochę czasu na zmianę, poważne uznanie u wyższych urzędników, którzy kontrolują podwyżki itp.

Po pierwsze, obwinianie członków zespołu ... oznacza słabe umiejętności kierownicze.

Mam na myśli to, że jeśli naprawdę ma słabe umiejętności komunikacyjne, bardzo mi przykro z powodu jego życia towarzyskiego, ale tak naprawdę w pracy to nie tyle jego problem, co twój . I spójrzmy prawdzie w oczy, może tak naprawdę znudzić cię nudne środowisko pracy, problemy prywatne z jego wpływami na wyniki lub potajemne spisek, by zabić was wszystkich.

Komunikacja wymaga co najmniej dwóch, a przecież osobą o słabych umiejętnościach ludzi możesz być ty. Bez względu na to, że reszta członków zespołu radzi sobie całkiem nieźle, wszyscy oni mogą kompensować (nawet nieświadomie) pewne niedociągnięcia w komunikacji, które masz i błogo ignorujesz.

W każdym razie nie chodź pytać w Internecie o ludzi siedzących przed tobą trzy biurka, idź do faceta i zapytaj go, czy naprawdę coś jest nie tak i czy można to rozwiązać. (lub coś nudnego, co można zoptymalizować lub ulepszyć)

Może po prostu nienawidzi swojej pozycji na biurku (czy stoi przed toaletami?), Co wprawia go w zły nastrój.

Wskazówka: słuchaj odpowiedzi, jakby był czującym człowiekiem, a nie zasobem ludzkim.

(np. spróbuj wyjaśnić mu szczegółowo potrzebę pewnych praktyk i znaczenie niektórych decyzji, niektórzy ludzie wykopują szczegóły, ponieważ dają im poczucie kapitana, który nie wjeżdża statku w skały)

Ludzie są inni. Jako menedżer musisz traktować ludzi inaczej (ale uczciwie!), Aby jak najlepiej wykorzystać swój zespół.

To powiedziawszy, prawdopodobnie jest to dobre dla programisty ze słabymi umiejętnościami miękkimi do pracy nad nimi. Dowiedziałbym się, jaką niekodującą rzecz cieszy się deweloper (lub chciałby zrobić), która wiąże się z większą liczbą tych miękkich umiejętności. Zaangażuj ich w to zadanie, a najlepiej poprawią umiejętności miękkie jako efekt uboczny.

Ludzie często nie są źli, jeśli chodzi o wyjście z pracy; są w tym źli, ponieważ im się to nie podoba lub mają do tego predyspozycje. Nie możesz pomóc drugiemu, więc pracuj nad pierwszym.

Podział 30/70 może być początkiem wszystkich problemów. Nigdy nie widziałem programistów zadowolonych z takiego podziału.

Widziałem, jak programiści czują się komfortowo przy 10, 15% innej pracy (i sam jestem szczęśliwy, ponieważ fajnie jest, gdy dawka jest odpowiednia), ale 30% to za dużo. Wolę myśleć, że inni członkowie zespołu wolą nie mówić o nich, niż tylko ten, kto nie lubi „30% innej pracy”.

Uważam również, że ważne jest dostosowanie „matematyki produktywności” do bardziej realistycznych liczb. Nigdy nie sumuje się do 100% z powodu nieuniknionych strat przy „przełączaniu kontekstu”.

• ^{30 + 70, sumując do 100% wydajności przy przełączaniu między programowaniem a inną pracą , nigdy nie nastąpi w prawdziwym życiu; jest bardziej prawdopodobne około 20 + 50 lub nawet 20 + 40. Przełączniki kontekstu są szczególnie bolesne dla twórców oprogramowania - jeśli jesteś zainteresowany, zapoznaj się z tym artykułem, aby uzyskać ładne wyjaśnienie, dlaczego: NIE OBUDŹ PROGRAMATORA!
  Programiści, którzy cenią swoją wydajność, byliby naturalnie niezadowoleni z takich strat.}

Jeśli chodzi o przeprowadzanie testów w ramach zadania, czy zastanawiałeś się nad przekazaniem go testerom? Fakt, że programiści mogą to zrobić (myślę, że każdy doświadczony programista powinien być w stanie to zrobić) nie oznacza, że powinni . Testerzy też mogą to zrobić i robią to lepiej, i nie poniosą strat wydajności przy „przełączaniu kontekstu”.

Kolejną kwestią, która sprawia, że ​​zastanawiam się, w jaki sposób wykorzystujesz zasoby kontroli jakości, jest twoja wzmianka o wsparciu / dochodzeniu . Profesjonalni testerzy, z którymi kiedyś pracowałem, mają tendencję do „mówienia” w takich sprawach.

• ^{Jako ex-tester rozumiem je całkiem dobrze - problemy z produkcją były dla mnie (jako testera) nieocenionym źródłem danych do nauki o zasięgu testowania („czy ten problem został odpowiednio uwzględniony w moich testach?”) I dla priorytetyzacja defektów („w porządku, że zostało to przetestowane i zgłoszone przed wydaniem, ale czy wtedy ustawiłem odpowiedni priorytet / ważność?”).}

Dobry tester może z łatwością dowiedzieć się, kiedy przekazać dochodzenie w sprawie pomocy technicznej programistom, co nie zdarza się często. Powody, dla których programiści przeciążają się tym, po prostu uciekają mi z głowy. Jak już napisałem, z pewnością mogą to zrobić (generalnie oczekuję, że starszy programista będzie wiedział, jak zrobić wszystko, co robi QA), ale to nie znaczy, że powinni .

Mam 2 rzeczy do powiedzenia na ten temat

1. Czy zwerbowałeś programistę lub programistę?
   Gdy rozważasz programistę, wszystkie wymienione przez Ciebie rzeczy są nieodłączną częścią tworzenia oprogramowania. Nie możesz ich zignorować, dopóki nie zwerbujesz tylko do określonego zadania. IMO 50% całego oprogramowania tworzy kodowanie, a wszystko to projektowanie, analiza, testowanie, dokumentacja itp.

2. Nikt nie rodzi się idealny.
   Nie może być tak, że można znaleźć osobę, która jest dobra we wszystkim. Musisz zmusić ich do walki i sprawić, by się uczyli.

Jako menedżer musisz wyciągnąć z nich to, co najlepsze, zgadzam się, ale na dłuższą metę możesz napotkać problemy. Przydziel im lekkie zadania, aby mogli się z tym pogodzić. Uwolnij ich od poczucia, że nie jestem w tym dobry / nie stać mnie na to . Przede wszystkim traktuj wszystkich jednakowo, co zapewni najbardziej efektywną wydajność twojego zespołu.

Jeśli wszyscy pracownicy mają ten sam tytuł / opis stanowiska, a opis stanowiska zawiera wszystko, co wymieniłeś, wówczas ten programista musi wyostrzyć te inne umiejętności poprzez przydzielenie większej liczby zadań innych niż programista. Podobnie twoi pozostali pracownicy nie będą mieli wyostrzonych umiejętności programistycznych, jeśli będą musieli nieustannie pracować nad zadaniami nieprogramowymi (wykorzystaj je lub stracisz).

Ale nadal uważam, że twoim głównym priorytetem powinno być prawdopodobnie dotrzymywanie terminów (co nadal możesz zrobić, rozdzielając pracę równomiernie).

EDYCJA: Jeśli masz mały zespół, prawdopodobnie ma sens, aby wszyscy członkowie mogli nosić wiele czapek. Jeśli masz wystarczająco duży zespół, prawdopodobnie warto mieć grupy specjalizujące się w różnych obszarach. Z twojego postu wygląda na to, że nie masz wystarczająco dużego zespołu, aby mieć grupy specjalistów.

Z twojego oryginalnego postu nie jest jasne, czego dokładnie brakuje w umiejętnościach komunikacyjnych tego dewelopera. Brak zainteresowania chodzeniem na spotkania lub wykonywaniem prac planistycznych / koordynacyjnych (na przykład) niekoniecznie oznacza słabe umiejętności komunikacyjne. Może deweloper po prostu uważa, że ​​ten rodzaj pracy jest pracą menedżera i ogranicza jego produktywność jako dewelopera? A może uważa, że ​​jest zbyt wiele kosztów organizacyjnych i jest to forma protestu przeciwko temu, co według niego jest po prostu marnowanym czasem? W końcu przeciwny problem, w którym ludzie rozmawiają przez cały dzień i nigdy nic nie robią, jest również dość powszechny w biurze.

Ważne jest, aby porozmawiać z tym deweloperem w sposób niekonfrontacyjny i spróbować dowiedzieć się, dlaczego unika on zadań niezwiązanych z programowaniem. Prawdopodobnie nie jest to jeden powód, może mieć tyle różnych powodów, ile jest różnych rodzajów zadań. Upewnij się, że rozumie, że celem rozmowy jest to, abyś mógł nauczyć się, jak skutecznie zwiększać produktywność zespołu i satysfakcję z pracy dla wszystkich członków zespołu (nie możesz go zdobyć). To jest czas, abyś posłuchał i nie kłócił się ani nie próbował rozwiać swoich obaw reakcjami szarpiącymi kolana. Prawdopodobnie powinieneś również spotkać się z innymi członkami zespołu, być może są w porządku, pozwalając temu facetowi wykonać ciężką pracę programistyczną, podczas gdy skupiają się na bardziej dyskretnej stronie zawodu.

Po tym spotkaniu poświęć trochę czasu na myślenie o rozmowach, które przeprowadziłeś, i spróbuj z otwartymi umysłami spojrzeć na perspektywę tego pracownika. Być może twoje początkowe uczucia były prawidłowe i brakuje mu ważnych umiejętności, które powinieneś popchnąć do rozwoju. A może podjął pewne ważne wyzwania w stosunku do twoich założeń. Może możesz współpracować z innymi zespołami, aby sformalizować niektóre procesy i zmniejszyć potrzebę redundantnej komunikacji. Być może inne zespoły nie są pociągnięcie ich wagi i trzeba mieć miłą pogawędkę z ich zarządzaniem. Istnieje wiele możliwości, których możesz nie brać pod uwagę.

Na koniec, i co najważniejsze, należy przeprowadzić dalszą rozmowę z osobami lub spotkanie zespołu, jeśli jest to właściwe. Jeśli zidentyfikowałeś rzeczywiste problemy organizacyjne, które mogą wpłynąć na Twoją sytuację, poinformuj swoich pracowników o działaniach, które zamierzasz podjąć w celu poprawy ich sytuacji w pracy. Jeśli nadal uważasz, że poszczególny pracownik jest w błędzie, usiądź z nim i wyjaśnij, jakich zmian potrzebujesz od niego i dlaczego. Twórcy zazwyczaj dobrze reagują na logiczne / praktyczne wyjaśnienia. „To niesprawiedliwe dla twoich rówieśników, aby dać ci całą zabawę. Chcielibyśmy, abyście wszyscy byli czystymi deweloperami, ale taka sytuacja nie jest realna, więc musimy dzielić ciężar bzdurnej pracy”.

Oczywiście, jeśli ten facet jest po prostu zrzędliwym palantem, nie chce powiedzieć, dlaczego jest niezadowolony, nie zareaguje na rozum i nie jest dobrze szanowany przez swoich rówieśników ... no cóż ... czas na plan poprawy wydajności.

Chociaż próbujesz zarządzać zespołem i chcesz utrzymać motywację wszystkich (poczucie uczciwości pomaga), ale czy poświęcasz projekt, nie mając najlepszego programowania dla programistów? Chodzi mi o to, że nie o to chodzi.

Czy nie boisz się niepełnego wykorzystania i / lub zaryzykowania utraty swojego najlepszego programisty? Twoim zadaniem jest uwolnienie się od tego rodzaju obowiązków od wszystkich.

Równe traktowanie nie oznacza, że ​​traktujesz wszystkich tak samo. Jeśli inni chcą zwolnić się z obowiązków niezwiązanych z programowaniem, aby otrzymać więcej zadań programistycznych, czy nie ryzykują, że nie będą w tym dobrzy?

EDYCJA: Poza osobistymi odczuciami nie zidentyfikowałeś problemu. W pewnym momencie brak komunikacji utrudnia programistom. Inni okażą niechęć, a ich praca może ucierpieć. Jak dotąd wydajesz się mieć jedyny problem. Chyba że jest coś jeszcze, czego nie udostępniasz?

EDYCJA 2 W końcu wszyscy będą prosić o specjalną przysługę. Ta osoba robi mniej komunikacji i więcej koduje (co powinien zrobić według wszystkich kont). Ktoś inny chce przyjść trochę później. Inny będzie musiał pominąć spotkanie, aby dotrzymać terminu. Osoba graficzna otrzymuje większy monitor. Kiedy przykładasz zbyt dużą wagę do utrzymywania wyniku, zapominasz, co jest ważne.

Jestem zrzędliwym administratorem Linuksa, który wykonuje dużo skryptów i zauważyłem, że mam słabe umiejętności komunikacyjne. Bardzo przypominam twojego faceta. W rzeczywistości jest to jedyny obszar, w którym zagłębiam się w recenzjach wydajności. Z drugiej strony stale przewodzę mojemu zespołowi w zakresie innowacji i rozwiązywania problemów oraz stworzyłem i poprowadziłem drogę do nowej platformy, którą wdrażamy, i zaoszczędziłem zespołowi dużo czasu, a mojej firmie dużo pieniędzy, ponieważ mogę być sobą.

Poproszono mojego byłego szefa, jego rodzinę / żonę ORAZ kierownictwo naszej firmy o opuszczenie stanowiska .... jednocześnie. Pracował niestrudzenie, aby sprawiedliwie zrównoważyć obowiązki i sam wziął na siebie spory ciężar. Jeśli podczas jakiejkolwiek interakcji z kimkolwiek spoza wydziału, doszło do nieporozumienia w komunikacji, szybko je naprawił, karno. Był kiepski w „zarządzaniu w górę”, więc nasz zespół jako ostatni pozyskiwał zasoby, dopóki nie było to nagłe zagrożenie, a następnie firma przepłaciła sprzedawców zręcznymi planami sprzedaży niesprawdzonego sprzętu bez konsultacji z zespołem, który będzie korzystał z tych narzędzi. Starając się stworzyć „dobrze wyważony” zespół, zarządzał mikromanizacją naszych list zadań i próbował wyrównywać zadania, aby członkowie zespołu mogli doskonalić swoje umiejętności w obszarach, w których nie byli świetni, co spowodowało DUŻO zepsutego kodu lub źle zaprojektowanych implementacji. Podczas gdy osobom innym niż autor przypisano zadania wsparcia dla tego zepsutego kodu, aby mogli się „nauczyć” - źle zaprojektowane implementacje, kod i testy stworzyły wiele złej dobrej woli między członkami zespołu i faktycznieczęstsze występowanie „gry obwinianej”, która jest szybką drogą do toksycznego stanu drużyny.

Mój obecny szef jest spokojną, zebraną osobą, która przyszła z roli młodszego administratora i wspięła się. Podejmuje dobre decyzje i w dużym stopniu polega na członkach zespołu, którzy ustalają własne priorytety. Jest doskonałym komunikatorem i reaguje spokojnie i w porozumieniu ze swoim przełożonym na wszelkie problemy komunikacyjne, pomysły lub potrzeby wyrażone przez mój zespół. „Pracuje w górę” niestrudzenie. Powoli wprowadza poważne zmiany w architekturze i konsultuje się dokładnie z całym zespołem, zanim wprowadzi zmiany w naszym otoczeniu, i czuje się komfortowo, polegając na specjalnościach członków naszego zespołu.

Pod nowym menedżerem przestoje spadły prawie do zera (co również zmniejszyło procent czasu, który spędzamy na zadaniach wsparcia z około 40% do około 10%), zadowolenie naszego zespołu poszło na marne i jesteśmy na dobrej drodze do przejścia od „rozbicia banku na nowym sprzęcie co trzy do pięciu lat” na ciągły plan przejęć, który powinien zaoszczędzić firmie około fajnego miliona rocznie przez pięć lat. Ten plan był oddolnym programem, który nigdy by się nie wydarzył za poprzedniego menedżera, ale został aktywnie skierowany do wyższej kadry kierowniczej przez nowego menedżera i polegał na znalezieniu DUŻEJ synergii w zestawach umiejętności zespołu. CIO poinformowało nas nieformalnie, że jesteśmy teraz jedynym zespołem w firmie, który naprawdę „ma swoje gówno razem” i że „ zamierzamy w jak najmniejszym stopniu ingerować w nasze środowisko pracy i kierować jak najwięcej zasobów w kierunku obszarów problemowych, które zidentyfikujemy w możliwie największym stopniu. Utrzymało się to prawdą i powoduje, że nasz koszt wsparcia jest jeszcze niższy, chociaż zakłócił obciążenia niektórych innych zespołów - ale obniżył również „koszt” wsparcia tych zespołów.

Spójrz, miejsce, w którym programiści mogą doskonalić swoje umiejętności, znajduje się w szkole lub w ich własnym czasie. Miejsce, w którym mogą produkować różne rzeczy, to czas twojej firmy. Najlepszym sposobem na wytwarzanie rzeczy jest wytwarzanie tego, co wiedzą najlepiej. Pracując w obszarach, w których jeden programista nie czuje się komfortowo, powinien przyciągnąć drugiego programistę, który jest wyspecjalizowany i pracuje jako zespół, lub specjalista programista powinien napisać kod oraz opracować dokumentację i diagramy. Kieruj zadania pomocy technicznej do osób, które napisały kod. Tak, zwiększa to, co nazywamy „czynnikiem autobusowym” - prawdopodobieństwo, że Twój oddział uderzy w próg zwalniający, jeśli autobus zostanie potrącony przez specjalistę. (Lub zwolnij się, albo zmień pracę, albo ...) Prawda jest taka, że ​​Twoja strata produktywności z tego strachu jest o rząd wielkości większa niż faktyczna strata, gdy „zdarzenie autobusowe” dzieje się. To, co zwykle dzieje się podczas „wydarzenia autobusowego”, polega na tym, że spadkobierca pracy specjalisty przekształca go na swój własny obraz, aby mógł jak najskuteczniej go wesprzeć, na ogół rozwiązując wiele problemów i skracając czas poświęcany na wsparcie jeszcze bardziej, a życie toczy się dalej. na.

Przypisuj rzeczy osobom, które potrafią to najlepiej. Niech wspierają i dokumentują swoją pracę. Wspieraj ich kreatywność i pozwól im się skupić bez rozpraszania uwagi i mikrozarządzania. Cała reszta to szkoła zarządzania BS, co niestety brzmi jak Twoja firma. Nie oznacza to, że Twój zespół też musi w niej pływać.

Z punktu widzenia firmy dobry menedżer promuje wartości firmy podczas wykonywania zadań zgodnie z tymi wartościami. Z punktu widzenia pracownika IT dobry menedżer pozwala zespołowi robić to, co należy, tak szybko i czysto, jak to możliwe, i działa jak bariera kałowa przeciwko kierownictwu wyższego szczebla, wypychając wartości, których nauczyli się podczas weekendowych zajęć MBA w gardle podwładnych. Jesteś pracownikiem firmy, co może nie być najlepsze dla twojego zespołu. Osoby z „dobrymi” umiejętnościami komunikacyjnymi są zbyt grzeczne, by to powiedzieć.

• Upewnij się, że pracownik wie, jak ważne są umiejętności komunikacyjne w opisie jego stanowiska. Współpracuj z nim / nią, aby poprawić.
• Nie nalegaj, aby byli tak dobrzy jak inni członkowie zespołu w takich zadaniach.
• Przypisuj zadania zgodnie z zasadami, w które wierzysz. Znajdź równowagę między efektywnym przypisaniem zadań do umiejętności a uczciwością / zabawą.

To tylko podsumowujące pomysły, mam nadzieję, że ktoś ukradnie te punkty i złoży je w jedną z pozostałych odpowiedzi. ;-)

Wydajność jest wszystkim. Daj mu zadania programistyczne. Porozmawiaj o tym z resztą działu. Opcjonalnie zaproś kogoś do wykonywania zadań com lub zadania tylko dla zadań com. Nie myśl o programowaniu zabawy. Wszystko jest „zabawne” z twojego POV.

Jeśli tego nie zrobisz, stworzysz sytuację, która jest wyjątkowo trudna do opanowania i mniej skuteczna niż mogłaby być.

Cóż za wspaniałe pytanie, jest to rodzaj rzeczy, o których powinni myśleć wszyscy kierownicy zespołu, przełożeni i menedżerowie technologii. Podoba mi się twoje podejście, każdy powinien mieć „zabawne” zadanie. Dalsze posiadanie zespołu, który może podnosić różne zadania i jest przeszkolony, zapobiega siejącej spustoszenie zasadzie Peterbilt'a „niezastąpiony członek zespołu opuszcza zespół, a nawet łapie oddech ”.

Teraz, jak podkreśla wiele postów, praca jest niesprawiedliwa i nie powinna być. Menedżerowie mierzy się, ile cennej pracy wykonuje.

• Menedżerowie dopasowują zadania do poszczególnych osób na podstawie umiejętności.
• Dobrzy menedżerowie dopasowują zadania w oparciu o umiejętności, wzrost, zainteresowanie i budowanie produktywności zespołu.
• Wielcy menedżerowie zachęcają swój zespół do zrobienia tego z niewielką pomocą i poradą. Tj. Bez menedżera spędzającego nad tym cały dzień.

Porozmawiaj ze swoim dobrym programistą, zapytaj go, czy jest coś, czego chce się nauczyć. Jakie inne zadania przyjąłby ... nawet to, co najmniej mu się podoba. Czy może pomóc innym członkom zespołu w ich programowaniu ... mentorować ich. Tak, wiem, że komunikacja jest problemem, więc może powinien nad tym popracować.

Innym sposobem na spakowanie tego jest posiadanie listy zadań i umożliwienie każdemu pracownikowi wybrania czegoś. Niech twój dobry programista wybierze pierwszy. Jeśli wcześniej go ostrzeżesz i jeszcze lepiej pokażesz mu listę zadań.

Jeśli otrzymujesz opór, który prawie zawsze robisz ze zmianą, znajdź punkt sprzedaży, coś dla niego wartościowego, dlaczego on skorzysta. Na koniec możesz po prostu powiedzieć mu, żeby zrobił to dla zespołu.

Spodziewaj się również, że zaczną się błędy i niższa wydajność, to znak, że ludzie się uczą. Ten projekt może ucierpieć, ale następny będzie lepszy.

Na zakończenie Twoim zadaniem jest dopilnowanie, aby wszystko zostało zrobione, ale rośnie też liczba pracowników i jeśli możesz zaangażować ich w proces jeszcze lepiej. Niektórzy mogą powiedzieć, że najlepszym sposobem na zapewnienie wykonania zadań jest zespół, który wie, co należy zrobić, i jest właścicielem wyników.

Edytuj: Och, próbuj dalej, powyższe porady pochodzą z lat popełniania błędów, ale zawsze wiedziałem, że chcę pomóc mojemu zespołowi się rozwijać, i wiedziałem, że produktywność jest królem, więc próbowałem nowych rzeczy, gdy ostatnia próba się nie udała.

Najlepsza odpowiedź została już zaakceptowana, ale jestem zaskoczony, że nikt nie zauważył, że „przydzielanie zadań” nie jest jedyną rzeczą, z którą menedżer może pracować. Posiadanie „powyżej średniego programisty”, który ma również „powyżej średnich umiejętności komunikacyjnych”, powinno (wszystkie inne rzeczy są równe) być lepiej płatnym / wyższym programistą niż ktoś o podobnych umiejętnościach programistycznych i słabych umiejętnościach komunikacyjnych. Może to pomóc zrównoważyć wszelkie postrzegane „faworyzowanie” zespołu. (W niektórych organizacjach posiadanie powyżej średnich umiejętności w „Analizie wymagań” i poniżej średnich w innych obszarach może być warte dużo więcej dla firmy ze względu na rodzaj wykonywanej pracy. Jako menedżer musisz zdecydować, jak sobie z tym poradzić .)

Jeszcze jedna rzecz, na którą należy zwrócić uwagę: pozostawienie danej osobie niczego poza zadaniami programowymi doprowadzi do izolacji w perspektywie długoterminowej. Pamiętaj, aby nadal dawać im niektóre inne zadania (ale te, które mogą zrobić dobrze, nie ustawiaj ich na negatywne opinie !!), aby były zarówno widoczne, jak i widoczne dla innych działów / zespołów.

Wreszcie ... sprawdzić się z innymi członkami zespołu, jeśli widzą żadnej nierówności w zadaniach zespołu okresowo. To może być dla ciebie dużym problemem, ale # 15 na liście wszystkich innych.

Ponieważ według twojej oceny ten jeden programista jest najlepszy w zespole, w pewnym sensie „sprawiedliwe” jest zapewnienie tej osobie pożądanej pracy (w wyniku wykazania, że ​​najlepiej ją wykonuje). W końcu prawdopodobnie byli ludzie, którzy chcieliby pracować w tej firmie, ale w ogóle nie zostali zatrudnieni - ale nikt nie powie, że to „niesprawiedliwe” wobec nich, że nie robią tego kodowania.

Myślę, że uczciwym podejściem byłoby powiedzenie innemu, mniej wykwalifikowanemu członkowi zespołu, który chce więcej kodować: „Pozwalamy (tak i tak) przejąć inicjatywę w tym. Być może możesz przejąć inicjatywę następną rzeczą, która się pojawi, jeśli możesz wykazać, że nauczyłeś się umiejętności x i y.

Podobnie jak niektórzy inni, którzy odpowiedzieli, rozumiem twoje stanowisko i miałbym podobne ambicje.

Chociaż można powiedzieć, że sensowne jest przydzielanie zadań osobom najlepiej przygotowanym do ich wykonania, sensowne jest również poszerzanie umiejętności ludzi w celu zapewnienia dynamicznego i elastycznego zespołu.

Jeśli ten facet jest zobowiązany do wykonywania niekodujących elementów w swojej roli, ale jego umiejętności komunikacyjne są gorsze niż są naprawdę potrzebne, musi się poprawić. Zakładając, że masz jakiś system oceny / oceny rozwoju, nadszedł czas, aby poruszyć ten problem.

Kluczowymi kwestiami są jasne określenie, czego od niego wymagasz, ocena, czy ma umiejętności, aby się do niego zastosować, i opracowanie planu szkolenia, aby to umożliwić. Trening niekoniecznie musi być formalny, ale musisz pomóc mu zdobyć wymagane umiejętności.

Jeśli po prostu nie będzie mu przeszkadzać, ostatecznie dojdzie do kwestii dyscyplinarnej. Jeśli nie ma takiej zdolności, pomimo prób i wsparcia ze strony ciebie, mogą istnieć środki dyscyplinarne (które, jak twierdzę, byłyby surowe i przyniosły skutek przeciwny do zamierzonego), ale równie dobrze możesz po prostu zaakceptować, że nie jest wycięty do niektórych zadań.

Rozmowa z facetem będzie jednym z twoich pierwszych portów zawinięcia . Może się okazać, że brakuje mu pewności siebie lub wglądu. Może się również okazać, że jest bardzo responsywny i doceni możliwość poprawy.

Powinieneś zatrudnić juniora, aby wykonał całą chrząknięcie i dał wszystkim znać, że muszą mu pomóc we wszystkim, o co prosi o pomoc.

Będą bardziej skłonni niepokoić „ponadprzeciętnego” programistę ze względu na ich umiejętności, a reszta zespołu otrzyma nowego lokaja. Junior uczy się od podstaw, a na końcu firma ma dobrze zaokrąglonego pracownika.

Oczekiwanie, że wszyscy będą mieli takie same umiejętności komunikacyjne, jest równie racjonalne, jak oczekiwanie, że nauczysz kalekiego mężczyznę, by biegł tak szybko, jak reszta drużyny.

Ludzie są różni, mają różne umiejętności i różne słabości. Zwolnienie świetnego programisty tylko dlatego, że nie potrafi dogonić innych umiejętności komunikacyjnych, byłoby jak zwolnienie kalekiego mężczyzny, ponieważ nie może chodzić tak szybko, jak inni. Byłoby niesprawiedliwe z etycznego punktu widzenia i byłoby sprzeczne z własnymi interesami gospodarczymi - wykonanie pracy.

Na początku powinieneś, jeśli nie zrobiłeś tego w przeszłości, przeczytać o zespole Aspergera . Słabe umiejętności społeczne są głównym wskaźnikiem tego zespołu.

Po drugie, możesz zatrudnić i zwolnić kogo chcesz, ale jeśli nie poradzisz sobie z silnymi i słabymi stronami swoich pracowników, skończysz z grupą przeciętnych programistów, ponieważ najlepsi odejdą (jeśli nie zostaniesz zwolniony jako pierwszy) .

Jest film, Adam , w którym genialny programista zostaje zwolniony tylko dlatego, że napisał coś, czego się nie spodziewał. Jego pomysł mógł przynieść pracodawcy dużo pieniędzy, ale nie mógł wykorzystać tej szansy, ponieważ skoncentrował się na swoich „zasadach”.