Jestem menadżerem Jak mogę poprawić relacje w pracy i komunikację z programistami? [Zamknięte]

Najpierw trochę tła. Jestem kierownikiem projektu w średniej firmie. Zaczynałem jako specjalizacja CS i miałem niewielkie doświadczenie w programowaniu, ale po kilku miesiącach wiedziałem, że to nie moja ścieżka, więc przeszedłem na zarządzanie. To była dobra decyzja, a po ukończeniu studiów pracowałem w zarządzaniu oprogramowaniem w różnych firmach (od 5 lat).

Niedawno mieliśmy bardzo bolesny projekt. To było najgorsze z najgorszych, z wieloma błędami zarówno po naszej stronie, jak i po stronie klientów i ledwo kończąc je bez strat. Doprowadziło to do wielu frustrujących sytuacji, z których jedna eskalowała do tego stopnia, że ​​jeden z naszych starszych programistów opuścił firmę po głośnym sporze z nami (zarządem). To była dla mnie czerwona flaga: zrobiłem coś strasznie złego. (dla przypomnienia, argument dotyczył kilku szacunków błędnego czasu)

Szukałem odpowiedzi w wielu miejscach, a przyjaciel wskazał mi tę stronę. Tutaj jest wiele pytań na temat frustracji związanych z zarządzaniem. Rozumiem, że ogólne złe doświadczenia prowadzą do ogólnej niechęci do „tych facetów w garniturach”.

Jestem tym facetem w garniturze. Może to nie wygląda, ale wszystko, czego chcę, to udany projekt i przy ograniczonych zasobach podejmuje bolesne decyzje. To moja praca. Jedną z rzeczy, na którą narzekał wspomniany starszy programista, był sprzęt roboczy. Szczerze mówiąc, nie miałem pojęcia, że ​​komputery, które mieliśmy, nie nadawały się do pracy. Po tym zapytałem wielu programistów i ogólny konsensus był taki, że potrzebujemy lepszych maszyn. Naprawiłem to od tego czasu, ale oczywiście istniała ogromna luka komunikacyjna między mną a programistami. Niektórzy z najbardziej błyskotliwych programistów to najbardziej nieśmiali i cichi ludzie. Wiem o tym i nigdy nie było problemu podczas wywiadu. Ludzie są różni i mają mocne strony w różnych obszarach.

Przypadek słabo wyposażonych komputerów jest tylko jednym z wielu, które skłoniły mnie do myślenia, że ​​istnieje problem z komunikacją. Jak mogę poprawić komunikację z programistami bez zastraszania i powtarzania się?

Mam nadzieję, że ludzie nie narzekają na dobre rzeczy. Jeśli kochasz swoje miejsce pracy i kochasz (a przynajmniej lubię :)) swojego kierownika, opowiedz mi o nich. Co oni robią dobrze? Podobnie, jeśli go nie znosisz, opisz szczegółowo dlaczego. Szukam odpowiedzi na temat poprawy komunikacji, ponieważ myślę, że to mój problem, ale mogę się mylić.

Łał! Dzięki, że pytasz. Technicznie, podobnie jak Ty, myślę, że zarządzam, ponieważ spędzam znacznie więcej czasu na komunikowaniu się i kierowaniu zespołami niż na pisaniu kodu ... ale oto moje zdanie z obu krańców horyzontu zarządzania. Bez względu na to, czy jestem programistą, czy menedżerem pracującym dla innego menedżera, oto kilka rzeczy, które pomagają w komunikacji z moim zarządem:

• Dlaczego? jest bardzo ważnym pytaniem - prawie każda faktyczna odpowiedź zawiera „dlaczego” i to „dlaczego” może być ważniejsze niż pytanie rzeczywiste. Jest w tym kilka stycznych:
  • Dlaczego deweloperzy - programiści będą mieli wiele odpowiedzi, które absolutnie nie mają sensu dla zarządzania. Z pewnością tak zrobiłem, a jednym ze sposobów, w jaki dostałem się do zarządzania, było bycie naprawdę dobrym w wyjaśnianiu zespołom „dlaczego” w kategoriach, jakie zarządzanie może zrozumieć. Jeśli nie masz pod ręką „mówcy dla maniaków”, możesz nauczyć się mówić maniakiem, powtarzając ich odpowiedzi na pytanie dlaczego w bardziej powszechnie rozumianych metaforach. Trzymaj się tego, dopóki oboje nie zrozumiecie i nie ustalicie, co się dzieje.
  • Zarządzanie Dlaczego- twoje „dlaczego” jest równie ważne. Dlaczego potrzebujesz oszacowań czasu? Do czego ich używasz? Jak mocno będziemy spieprzeni jako firma, jeśli będą za wysoko lub za nisko? Są to rzeczy, o których jako menadżer zapewne masz wnikliwy wgląd, ale to wszystko jest voodoo dla programisty. Sztuka polega na tym, że deweloper nie może zapytać. Zarząd poprosił go o coś, a on zrobi wszystko, co w jego mocy, by być dokładnym, terminowym i przemyślanym - ale jeśli nie wie „dlaczego”, może zoptymalizować w sposób, w jaki wolisz, nie zrobił tego. Podaj swoje powody i poproś, aby zrobił to samo - powtórz odpowiedź na własnych warunkach.

Mówiąc konkretnie o szacunkowych terminach - musiałem zrobić mnóstwo, i absolutnie skorzystałem z powiedzenia mojemu zespołowi programistycznemu: „Potrzebuję tego, ponieważ zamierzam poprosić o więcej pieniędzy na wypłatę pensji, zaufam temu, co mi powiesz, i Użyję twoich liczb ... to znaczy, że jeśli spuścisz na mnie piłkę, wszyscy jesteśmy w dupie, bo nie będę mógł prosić o pieniądze po raz drugi - musimy żyć z tym, co proponujemy ". W tym kontekście programiści zmienili się z niskich oszacowań, które próbowały mi pokazać, jak pewni siebie i błyskotliwi byli na wysokie oszacowania, które zbliżyły się do rzeczywistych oczekiwań.

• Nikt się nie myli - pytanie „dlaczego” idzie z długim następstwem - pytanie „dlaczego” zamiast mówić „to oburzające! Nie ma mowy!” podtrzymuje rozmowę. Czasami istnieje poważny rozdźwięk między tym, o co ktoś jest proszony, a tym, o co pytający pyta. Moje najlepsze zarządzanie zostało strasznie zaskoczone moimi odpowiedziami, a gdy są zaskoczone, mrugają ze zdziwienia, a następnie pytają „dlaczego to mówisz?”. Nie mówią (od razu) - „musisz to zmienić”. Zmniejszyłem liczbę wniosków dotyczących osiągnięcia celu konkurencyjnego, ale dopiero po intensywnym rozmowie o tym, jak możemy zmienić scenę i stworzyć inny kontekst dla pytania.

• słuchaj hałasu otoczenia, wyboru słów i odstępów między słowami - oto kilka rzeczy, które lubiłem i skradziłem, aby użyć siebie:

  • spędzać wolny czas w miejscu pracy, robić coś produktywnego (nie próbuj angażować się w pracę programistów, wiedzą, że nie jesteś programistą) i po prostu słuchaj. Jak zespół rozwiązuje problemy? Jakie są ich duże problemy? Nigdy nie usłyszysz prawdziwych chudych na temat ich bezpośredniej oceny ciebie lub kierownictwa, ale możesz naprawdę dobrze wiedzieć, gdzie są obszary problemowe. Upewnij się, że robisz coś własnego, co jest produktywne. Nikt nie lubi szpiegować, ale jeśli morale nie jest tak niskie, że nie można być blisko nich bez ewakuacji, produktywność w pobliżu powinna być do przyjęcia.
  • szukaj wyborów słów - często są one tak samo ważne jak same słowa. Kiedy używam szczególnie pozytywnych lub negatywnych słów, moje kierownictwo często pyta mnie, dlaczego wybrałem te słowa, gdy jest to sytuacja, której nie znają.
  • szukaj pauz, luk i mowy ciała. Jeśli między tobą a twórcami występuje dystans mocy (i wygląda na to, że tak jest), mogą nie chcieć ci zaprzeczyć lub skonfrontować się z tobą. Ale podstawowy instynkt powiedzenia „hej, mylisz się” zwykle objawia się gdzieś.

• otworzyć się na jak najwięcej mediów komunikacyjnych - być gotowym na czat osobiście, przez telefon, e-mail, komunikator - wszystko i wszystko, aby ustalić przepływ komunikacji. Ludzie są tak różnorodni, że jedna sztuczka nie zadziała. I uważam, że zadaniem menedżera jest komunikator w wielu formatach, a nie programista.

• warto z tobą porozmawiać Jeśli ktoś powie ci o problemie i być może możliwym rozwiązaniu, powinien i prawdopodobnie zaakceptuje to, że jesteś menedżerem i dlatego może zdecydować się na inne rozwiązanie lub w ogóle nie ma rozwiązania, ponieważ ty nie myślę, że warto. Ale po raz trzeci tak się dzieje, zwłaszcza jeśli dzieje się to bez wyjaśnienia, około 99% ludzi przestanie ci coś mówić.

A oto jeden, który jest dla mnie niesamowicie trudny, ale sprawdził się świetnie, kiedy mogę to zrobić - pamiętaj o różnicy między introwertykami i ekstrawertykami . Możliwe, że jesteś ekstrawertykiem - dlatego Twoja praca wydawała się dobra, a pozycja rozwojowa nie. Deweloperzy są w większości introwertykami. „Introvert” nie oznacza „nie może się komunikować”, ale oznacza, że ​​ich wzorzec, proces i prędkość są znacząco różne, a chęć ciągłej komunikacji praktycznie nie istnieje. Zaplanuj w czasie i spokojnej (ale skolokowanej) przestrzeni, aby wypłynęły myśli oparte na introwertyce. Wielu moich introwertycznych przyjaciół mówi mi, że po prostu czekają, aż „zamknę się na około 5 minut”, aby mogli zebrać myśli i odpowiedzieć. Tutaj'5 rzeczy, które ekstrawertycy powinni wiedzieć o introwertach i Rands in Repose on the Nerd Cave - szczególnie gustowny dla deweloperów przykład tego, co jest świetne dla introwertów . Nawiasem mówiąc, Rands jest całkiem fantastyczny. Sam jest maniakiem, więc skupia się na programistach, co może być odrażające, jeśli to nie w twoim stylu, ale jest zabawny i ma naprawdę dobre spostrzeżenia na temat rozwoju zespołu.

Myślę, że najważniejsze rzeczy, które pokochałem w moich ulubionych menedżerach:

• byli tak głęboko zaangażowani i podekscytowani projektem jak ja (jeśli nie bardziej)

• Nigdy nie miałem wątpliwości, że mają moje plecy - wiedziałem z pewnością, że kiedy staną przed wyższym poziomem władzy, że ja (lub moi rówieśnicy) nigdy nie będę kozłem ofiarnym. W przypadku awarii zawsze byłaby to awaria grupy.

• Otrzymałem wówczas własność czegoś znaczącego i odpowiedniego dla moich umiejętności, ale z wystarczającymi zasobami, aby rozwinąć swoje umiejętności i wykonać pracę.

• postrzegali mnie zarówno jako jednostkę, jak i jako część zespołu - aktywnie angażowali się w poznawanie moich mocnych i słabych stron oraz pracowali, aby pomóc mi grać w swoje mocne strony i wzmacniać moje słabości.

• byli świadomi moich osobistych celów i byli zainteresowani włączeniem ich w jak największym stopniu

• byli szczerzy, kiedy uczynienie mnie szczęśliwym nie mogło i nie byłoby priorytetem. Słuchanie „Wiem, że nienawidzisz tego rodzaju pracy, jest naprawdę ważne, ale musisz to zrobić - oto, jak nie będzie na zawsze ...”.

• w tygodniu zawsze był czas (może nie w tej chwili), aby wyjaśnić duży obraz

• była prawie stała informacja zwrotna i status bez wskazywania palcem, ale wiele uznania dla indywidualnej pracy.

• zawsze była prawda. Jeśli coś było wrażliwe i nie mogło być dyskutowane, powiedzieli, że są puste. Jeśli coś było niepewne, dawali pewien poziom pewności siebie.

Po pierwsze łatwa część: w twoim poście jest techniczna czerwona flaga: wzdrygam się na twoją wzmiankę o „błędnych szacunkach” - to jest szacunek, NIE MOŻE BYĆ POMYŚLNY , dlatego nazywa się to szacunkiem. To może być trochę wyłączone, może być dużo, dlatego nazywa się to szacunkiem. Jeśli przyjmujesz szacunki jako ewangelię, będzie to jeden z głównych problemów, które „Twoi” deweloperzy mają ze swoim stylem.

Jednak w 100% zgadzam się z tobą w sprawie trudności w komunikacji z programistami. Kilka lat temu miałem objawienie jako programista w szkoleniu z zakresu zarządzania projektami. Widziałem kilku moich kolegów programistów absolutnie szykujących się do zarządzania po stworzeniu otwartej atmosfery dyskusji (zarządzanie było tutaj obecne). Wszystko, co było nie tak, było winą menedżerów w oczach programistów. Najważniejsze było to, że kierownictwo nie miało pojęcia o prawie wszystkich ogromnych problemach poruszonych tego dnia. Deweloperzy zakładali, że wszystko było tak oczywiste, że kierownictwo nie mogło tego przegapić, a zarząd zakładał, że programiści powiedzą im, czego potrzebują.

Dlatego IMHO pierwszą częścią odpowiedzi musi być poinformowanie deweloperów, że nie masz zdolności parapsychologicznych, a nawet prawdopodobnie głupie, jeśli chodzi o stronę techniczną. Ufasz, liczysz i ufasz im, że przyjdą do ciebie w odpowiednim czasie. Jesteś tutaj, aby ułatwić im życie, a nie trudniej.

I cokolwiek zrobisz, NIE zadawaj im pytań, na które tak naprawdę nie chcesz znać odpowiedzi - odnosząc się do „błędnych szacunków” powyżej ;-). To jest kryptonit dewelopera.

Jest tu wiele dobrych rzeczy, ale wydaje mi się, że należy powiedzieć: .. Przepraszam, że jestem surowy .. Ale trzeba to powiedzieć:

• 5 lat na stanowisku premiera i nie wiedzieć, jakiego komputera potrzebuje programista, jest oburzające.
• Zwolnienie programisty z powodu złych warunków pracy jako pierwszej prawdziwej czerwonej flagi jest szalone.

To, co myślę, że masz, to kwestia zaufania , bardziej niż kwestia komunikacji. Nikt nie mówi, co jest nie tak, ponieważ nie ufa, co zrobisz z tymi informacjami, i może nawet obawiać się, że zostaną użyte przeciwko nim. Twórca, który powiedział ci o tych wszystkich sprawach, zrobił to, ponieważ nie miał żadnych konsekwencji, zrezygnował.

Osobiście nigdy nie zatrudniłbym premiera, który nie miałby doświadczenia w rozwoju w swoim otoczeniu. Myślę, że przy następnym projekcie powinieneś poświęcić niewielką część swojego czasu jako część twórcy. zespół . Powiedz 8 godzin tygodniowo, pracując jako programista Jr pod kierownictwem zespołu.

To naprawdę otworzy twoje oczy na dynamikę zespołu programistów, ponieważ teraz nie jesteś nawet częścią tego zespołu, jesteś osobą z zewnątrz. Dowodzi tego fakt, że rezygnacja z programu była dla ciebie szokiem. Wszyscy w zespole wiedzieli, że jest nieszczęśliwy. I żaden z nich nie powiedział ci:

„Stracimy naszego najlepszego faceta, jeśli czegoś nie zrobicie”

To powinna być czerwona flaga # 2.

Jako kierownik jestem pewien, że słyszałeś o kaizen , jednym z założeń Systemu Produkcyjnego Toyota, co oznacza ciągłe doskonalenie .

Przyznałeś, że masz problem, więc to dobry początek.

Kaizen ma pięć podstawowych elementów:

• Koła jakości : grupy, które spotykają się, aby omawiać poziomy jakości dotyczące wszystkich aspektów prowadzenia firmy.

• Lepsze morale : Silne morale wśród siły roboczej jest kluczowym krokiem do osiągnięcia długoterminowej wydajności i wydajności, a kaizen stawia to za fundamentalne zadanie utrzymywania stałego kontaktu z morale pracowników.

• Praca zespołowa : Silna firma to firma, która łączy siły na każdym etapie. Kaizen ma na celu pomóc pracownikom i kierownictwu patrzeć na siebie jak członków zespołu, a nie konkurentów.

• Dyscyplina osobista : Drużyna nie może odnieść sukcesu bez silnego siebie każdego członka. Zaangażowanie w dyscyplinę osobistą każdego pracownika gwarantuje, że zespół pozostanie silny.

• Sugestie dotyczące ulepszenia : kierując prośbę o opinię od każdego członka zespołu, kierownictwo zapewnia, że ​​wszystkie problemy zostaną przeanalizowane i rozwiązane, zanim staną się znaczące.

( Źródło )

Jeśli przyjrzysz się temu z długimi względami, stałym elementem tych elementów jest nacisk na pracę zespołową i opinie.

Na przykład, mówisz, że miałeś kłótnię w czasie. Czy jesteś odpowiedzialny za te oszacowania czasu? Czy rozmawiasz o tym z zespołem? Przepraszam, ale widziałem, jak menedżerowie po prostu wyciągają numer z ich… Jedna ważna rzecz: nigdy się nie targuj w czasie, które szacuje twój zespół. Wielu menedżerów wyobraża sobie, że jeśli uda im się dotrzymać krótszych terminów, jeśli ich zespół będzie ciężej pracował. To jest kłamstwo. Dziewięć kobiet nie może mieć dziecka w ciągu jednego miesiąca, pamiętaj o tym.

Moja pierwsza rada:

Słuchaj : zacznij od prostej wiadomości e-mail do zespołu: „Jaki jest najlepszy sposób, aby zespół programistów przekazał zarządowi informacje zwrotne na temat wyników zarządzania?”. Iteruj z zespołem i wdrażaj konsensus. Twoim zadaniem jest umożliwienie zespołowi tworzenia doskonałego oprogramowania, a nie gromadzenie go. Pamiętaj o tym.

Uczciwość i lojalność : jeśli nikt nie odpowie, kiedy o coś zapytasz, dzieje się tak dlatego, że nie wierzą, że będziesz słuchać lub, co najgorsze, wierzą, że za to ich ukarzesz. Więc bądź szczery. Jeśli ktoś mówi, że ssiesz, weź to jako informację zwrotną i nie mścij się. Zrozum ich powody, popraw je.

I w końcu, chociaż widziałem tu kilka krytyków, chciałbym polecić Ci przeczytanie książki zatytułowanej The Mythical Man-Month: Essays on Software Engineering . Książka opowiada o doświadczeniach Freda Brooksa w IBM podczas zarządzania rozwojem OS / 360. Kilka rzeczy tu i tam może być datowanych, ale jest to pierwszy krok do zrozumienia, jak działa proces tworzenia złożonego oprogramowania. S.Lott cytuje Manifest Agile , który nie bardzo mi się podoba, ale warto go również przeczytać.

Przeczytaj to:

http://agilemanifesto.org/

• Osoby i interakcje dotyczące procesów i narzędzi

• Działające oprogramowanie w obszernej dokumentacji

• Współpraca z klientami w zakresie negocjacji umów

• Reagowanie na zmianę po wykonaniu planu

W wielu przypadkach organizacja (tj. Szef) wymaga tego

• postępuj zgodnie z wyraźnie zepsutym procesem, aż do logicznego zakończenia prowadzącego do „marszu śmierci”. To z kolei prowadzi do kłótni i rezygnacji.

• tworzyć nadmierną, nieużywaną dokumentację o niskiej wartości.

• angażować się w kompleksową kontrolę zmian / negocjacji umowy. Każda zmiana użytkownika wymaga skomplikowanego rytuału „jakości” i „nadania priorytetu” zmianie. Naprawdę chodzi o „zamrożenie” - zapobieganie zmianom.

• postępuj zgodnie z planem niezależnie od konsekwencji. Niektóre organizacje cenią terminowe dostarczanie zepsutego (a nawet bezużytecznego) oprogramowania. Ceniony jest plan, a nie rozwiązanie problemu biznesowego.

Możliwe, że problemem nie są twoje osobiste umiejętności komunikacyjne.

Może się zdarzyć, że całe „środowisko” rozwoju lub „metodologia” zostanie śmiertelnie złamane, a złe uczucia są tylko objawem ogólnych złych praktyk.

Dla mnie brzmi to tak, jakbyś nigdy nie rozmawiał z deweloperami w łatwej atmosferze. Twoje rozmowy z nimi miały jedynie oficjalny charakter? Szkoda

Dlaczego nie poznasz ich osobiście, a tym samym nie wiesz, co jest dobre, a co złe w firmie, miejscu pracy i projektach? Szanuj ich i zdobywaj ich szacunek, okazując szczere zainteresowanie i uznanie dla ich pracy.

Jeśli ci zaufają i nie będą musieli się obawiać bycia lombardem, najprawdopodobniej powiedzą ci nieatrakcyjne prawdy.

Jestem liderem zespołu i mój zespół mi ufa. Chronię ich. Biorę na siebie całą winę i dzielę się z nimi sławą. Nasze kierownictwo mnie chroni. To podnosi morale. Mieliśmy naprawdę trudny projekt i prawie złego klienta, prawie niemożliwe do ukończenia, ale ostatecznie to zrobiliśmy, ponieważ rozmawiamy o wszystkim w bardzo szczery i otwarty sposób.

Klaskać! Klaskać! Klaskać! Z pewnością powinieneś być dobrym człowiekiem, ponieważ wyszedłeś na jaw, aby zobaczyć, co można zrobić, aby poprawić swoją pracę.

Poniżej znajduje się to, czego byłem świadkiem we wspaniałym menedżerze i osobiście przyjąłem, gdy kieruję zespołem jako starszy członek.

• M entor ponad zarządzać.
• A llow członkowie zespołu do wyrażania swoich myśli i obawy. Miejcie na to wszelkie uszy. Weź konstruktywne.
• N kiedykolwiek zdradzić członków zespołu grając polityczne podziały. To odpala wcześniej i po cichu.
• Nie NGER. Nigdy nie miej grymasów na twarzy, gdy jesteś ze swoim zespołem, przyjdź, co może. Ten jest naprawdę trudny.
• G bardzo i otwarcie doceni zwycięzcę za jego / jej dobrą pracę. W tym samym zakresie, bardzo łagodnie i taktycznie krytykuje pracę nie osoby za zło, wobec osoby odpowiedzialnej, w izolacji, a nie w otwartości.
• E ncourage własności i przywództwa w każdej jednostce. Zwiększa to morale i zaangażowanie osoby, ponieważ czułaby się szanowana.
• Od czasu do czasu przemierzaj swój zespół. To indukuje / zwiększa więź w obrębie członków zespołu.

Życzę powodzenia w szczerych staraniach :)

Ogólnie rzecz biorąc, faceci w okopach zaczynają buntować się, gdy czują, że ich uściski nie są słyszane przez ludzi, którzy potrafią i naprawią sytuację. Kiedy nawet nie czują, że mogą się przyczepić, nie ryzykując swojej pozycji w firmie, jest jeszcze gorzej.

Jestem facetem typu Teoria-Y, a większość „pracowników wiedzy” zwykle jest; Mając szansę, lubimy naszą pracę i chcemy robić to dobrze. Jednak wadą miejsca pracy Teoria-Y jest to, że może nie być od razu oczywiste, że jest problem, ponieważ ludzie, chcąc dobrze sobie radzić, a tym samym nie chcą tworzyć fal, znajdą sposoby na obejście tego problemu lub po prostu go zignorują. Prowadzi to do stłumionej frustracji, która ostatecznie wysadza się w twarz całego zespołu. Sklep prowadzony przez kierownika Teorii-X prawdopodobnie miałby facetów, którzy narzekaliby znacznie wcześniej; pracownicy są w nim tylko dla pieniędzy, więc jeśli praca będzie do bani bardziej niż zwykle, będą chcieli.

Jeśli chodzi o to, co możesz zrobić, w otoczeniu seniorów i potencjalnych klientów w pokoju, są najlepszym atutem. Porozmawiaj z nimi. Możesz zaplanować 30 minut tygodniowo na „dwukierunkowe”, w których potencjalni klienci informują Cię o aktualnych problemach i informują o nich, a także udzielasz im aktualizacji po stronie biznesowej i planujesz wspólnie z nimi rozwiązać problemy zanim staną się problemami, które poważnie wpływają na zespół.

W Agile pod koniec każdego „sprintu” lub „iteracji” (która jest jednostką prac rozwojowych trwających zwykle od jednego do trzech tygodni) cały zespół, od najmłodszych członków aż do premiera, ma „retrospektywę” „. Patrzą wstecz na to, co zrobili, co poszło dobrze, a co nie, i identyfikują rzeczy do zrobienia i rzeczy do zmiany. Istnieje kilka formatów i możesz wymyślić swój własny, ale efektem retro powinno być to, że ludzie czują, że ich głos został usłyszany, i że w rezultacie rzeczy się zmienią.

Mówiąc o Agile; moją pierwszą pracą była mała firma, a przez „małą” rozumiem, że cała firma nie mogła wystawić drużyny softballowej. Kiedy zacząłem, było czterech programistów, co zmniejszyło się do dwóch, zanim odszedłem. Założyciel, prezes, dyrektor generalny i 95% udziałowców w firmie rządził żelazną pięścią, a on był jedynym źródłem planowania w organizacji, co oznaczało, że niewiele. Szef był pracoholikiem i oczekiwał, że wszyscy też będą; Wszystko, co musiałeś dać, było mniej więcej niż jego oczekiwaniami, i za to zapłacił podstawową pensję ludziom, którzy pracowali dla niego przez dekadę.

Opuściłem tę firmę i zacząłem pracować dla innej firmy, która robi BARDZO inaczej; ćwiczyli podstawową metodologię SCRUM Agile, z codziennymi pojedynkami, programowaniem par, zespołami sprintu i retrospektywami. Przez jeden dzień co dwa tygodnie na początku każdego sprintu nie robiliśmy nic, tylko planowaliśmy pracę na następne dwa tygodnie. Przez większą część kolejnego dnia nie zrobiliśmy nic, tylko spojrzeliśmy wstecz na to, co zrobiliśmy i znaleźliśmy sposoby na ulepszenie się jako zespół. Obok mnie siedzieli programiści, którzy byli Microsoft MVP, wykonując zadanie oraz zachęcając i uzupełniając to, co robiłem.

Noc. I. Dzień. Podstawowa różnica? Po pierwsze, nie czułem się, jakbym miał się zabić za projekt; fundamentalną zasadą Agile jest zrównoważone tempo rozwoju. Po drugie, miałem głos przy podejmowaniu decyzji, w jaki sposób mam wykonywać swoją pracę. Musiałem wykonać tę pracę, ale gdybym miał „zgagę” w związku z tym, co miałoby się odbyć w następnym sprincie, mógłbym wyrazić tę opinię i usłyszeć ją i przytyć. Gdybym poczuł, że istnieje lepszy sposób, mógłbym to powiedzieć i byłoby to zabawne.

Jeśli chodzi o znajdowanie rozwiązań i rozwiązywanie problemów, musisz uważać, aby nie wyglądać, jakbyś pracował od góry do dołu. Do komputerów; powiedzmy, że RMR (powtarzające się miesięczne przychody) pozwala firmie tylko na aktualizację czterech komputerów co dwa tygodnie. Pierwsze cztery komputery nie powinny trafiać do potencjalnych klientów i seniorów; powinni iść do ludzi z najwolniejszymi komputerami. Jeśli dajesz zespołowi bonusy, nie daj ich po prostu „naszym cennym seniorom i liderom, bez których nie byłoby to możliwe”; KAŻDY w zespole deweloperów sprawił, że tak się stało. Jeśli junior ma skargę, wysłuchaj go; tylko dlatego, że jest młodszy, nie znaczy, że nic nie wie.

Poprawa relacji:
Właśnie miałeś trudny projekt? Daj im potem przerwę. Czas na odpoczynek i odpoczynek.
Karta praw Koderów Te rzeczy są pewne. Podstawowe rzeczy, które powinny być oczywiste. Jeśli je naruszysz, nadużywasz swoich kluczy kodowych.
Test Joela zgadzam się z większością z nich. Ale niektóre naprawdę zależą. Jeśli czegoś brakuje, prawdopodobnie utrudniasz życie programistom, to musi być.
Dług techniczny . Możesz więc naciskać na ukończenie, ale musisz zdawać sobie sprawę, że skracając rogi, zaciągasz dług techniczny, którego naprawienie zajmie więcej czasu w późniejszym terminie. Jeśli ta data nadejdzie PRZED końcem projektu, to naprawdę popsułeś.
Animacja RSA: MotywacjaTo fantastyczny kawałek, który naprawdę pokazuje, jak motywować pracowników wiedzy.
Darmowy dzień na kodowanie tego, czego chcą. Z wideo RSA. Nie pamiętam nazwy, ale firma, o której wspomina, ma krótkie wyjaśnienie na swojej stronie. To dla mnie dobry pomysł. W większości sklepów są rzeczy, o których wszyscy wiedzą, że zostały zniszczone, ale nikt nie ma czasu na naprawę i nie jest to wysoki priorytet. To pozwala im poradzić sobie z długiem technicznym. Pozwala im także pochwalić się genialnymi pomysłami.

I na miłość boską staraj się zachować 40-godzinny tydzień pracy. Również flextime. Flextime może nadrobić cały świat bzdur. Przynajmniej dla mnie.

Poprawa komunikacji między programistami i szefami
To dla mnie trudniejsze. Cała ta strzelanina to raczej umiejętność bossa niż skupienie programisty. Mógłbym powiedzieć, że niektóre podstawowe rzeczy, takie jak szacunki czasu, są jedynie szacunkami. Chodzenie po wodzie i spełnianie wymagań jest łatwe, jeśli są zamrożone. Może poprosić nieśmiałych programistów o przedstawienie prezentacji swojego projektu podczas przeglądu kodu lub czegoś takiego. Ćwiczenie czyni mistrza, tak? Ale skłoniłbym się do rad innych w tej sprawie.

„Podobnie, jeśli go nie znosisz, opisz szczegółowo dlaczego.”
To otworzy tu wrota. A gdybym nie używał identyfikatora openID, który oczywiście mógłby być ze mną powiązany, prawdopodobnie też bym powiedział. Jeśli naprawdę chcesz ogromną listę rzeczy do zrobienia, zapytaj na forum bardziej przyjaznym dla anonimowych postów.

Zawsze uważałem, że ludzie w ogóle nie będą cię traktować lepiej niż ty (chociaż mogą cię traktować gorzej). Ja osobiście (jestem programistą) odpowiadam na uczciwość z uczciwością, z szacunkiem, z szacunkiem, z zaufaniem i tak dalej. Powinieneś odbyć nieformalną rozmowę ze swoim zespołem w neutralnej atmosferze i powiedzieć im to, co właśnie powiedziałeś. W toksycznym otoczeniu „my kontra oni” zapomina się o tym, że wszyscy powinniśmy być „my”. Zarówno kierownictwo, jak i pracownicy muszą to wiedzieć, a przedsiębiorstwo musi to wspierać.

Powodzenia.

Masz teraz udokumentowany zapis nie tylko przyjmowania opinii, ale także działania na ich podstawie. Wykazałeś, że masz wpływ na osoby podejmujące wyższe decyzje i możesz załatwić sprawy dla swojego zespołu. To duża różnica. Programiści mogą być bardziej introwertyczni, ale lubimy rozmawiać o programowaniu. Nieformalne środowisko jest miłe, ale wszyscy muszą być profesjonalni. Pozwól ludziom odpowiedzieć, ale upewnij się, że dyskusje są produktywne, a nie tylko sesja dziwek.

Z mojego doświadczenia, najważniejszym czynnikiem, który lubię lub nie lubię mojego kierownika, jest to, że on / ona rozumie ogólnie rozwój i rozumie pracę, którą wykonuję. Oto niektóre pozytywne wyniki:

• Nie muszę tracić zbyt wiele czasu, aby uzasadnić, dlaczego zmiana potrwa tak długo lub nie może zostać wdrożona. Cóż, technicznie rzecz biorąc, każda zmiana może zostać wdrożona, a kierownictwo zazwyczaj wymaga wdrożenia w jakikolwiek sposób. Ale przynajmniej w takiej sytuacji twój bezpośredni menedżer jest po twojej stronie, prosząc o więcej czasu (zamiast wypychać cię lub wypalać).
• Wiem, że mam większą szansę na wsparcie w przypadku złej sytuacji (włamanie do WTF, problem z produkcją itp.). Zwykle osoba nietechniczna zwykle obwinia programistę za taką sytuację, a dobry menedżer rozumie, co się naprawdę dzieje, i wspiera swojego programistę (nie tylko wie lub chce wziąć to w ten sposób za bycie miłym).
• Wiem, że moja praca i wydajność powinny być ocenione przez właściwą osobę.

Moim zdaniem, jeśli nie będziesz już programować i zwykle napięty harmonogram projektu lub budżet, szanse na polubienie przez programistów są bardzo niskie. W takim przypadku lepiej szybko przejść na wyższy poziom i mieć kogoś innego, kto będzie bezpośrednim menedżerem. Przepraszam, w tym akapicie zabrzmiałem źle, ale tak to widzę. Twoja wydaje się być dobrą osobą i zasługuje na trochę prawdy.

Jestem także jednym z facetów w garniturze i jestem od ponad 15 lat. Byłem programistą, kiedy zaczynałem, i wciąż piszę kod, gdy mam szansę. Myślę więc, że mogę mówić po obu stronach i mam trochę doświadczenia w tych sytuacjach. Posiadam również referencje, takie jak „Pracownik roku”, wybrany przez pracowników, które dają mi pewność w radzeniu sobie z tymi sytuacjami.

Często obserwuję to, że istnieją znaczne różnice w systemach wartości i metodach operacyjnych / podejściach przyjętych między zarządem a deweloperami.

Dla wielu programistów szczerość, uczciwość i poza tym elastyczne środowisko pracy są bardzo wysoko na liście. Niestety te same wartości nie są bardzo wysokie na liście najwyższego kierownictwa. A to nieuchronnie prowadzi do wielkich starć, szczególnie jeśli kierownictwo średniego szczebla (ty i ja) zdecydujemy się całkowicie zająć najwyższe stanowisko kierownicze. Jedynym wyjściem z tego (z mojego punktu widzenia) jest zajęcie stanowczego stanowiska przed zespołem, wsparcie go przez całą drogę i budowanie relacji zaufania poprzez otwartą komunikację i, co najważniejsze, robienie tego, co mówisz (co często jest przeciwieństwem tego, co dostajesz od najwyższego kierownictwa, gdzie polityka całkowicie obezwładnia szczerość).

Jednocześnie musisz pozostać operacyjny, więc musisz znaleźć sposób komunikowania się z najwyższym kierownictwem w języku, który rozumieją i grają w swoją grę. To jest prawdziwe wyzwanie średniego kierownictwa.

Wierzę, że wraz ze szczęściem programistów produktywność sprowadza się do drobiazgów. Matematyka świetnie się sprawdza w zarządzaniu. Daj mi pączka (-25 centów) rano, a ja będę pracował dwa razy ciężej przez cały dzień (+ wiele dolarów). Nie chodzi o to, że aktywnie sabatogujemy rzeczy pracując powoli, gdy jesteśmy niezadowoleni, chodzi o to, że pracujemy na bardzo skomplikowanych systemach i niezwykle trudno jest się skupić, gdy jesteśmy sfrustrowani czymś. Naprawdę jest prawdopodobnie lepiej, że nie kodujemy tak dużo, kiedy jesteśmy źli.

Szacunki muszą jednak zostać rozwiązane samodzielnie. Każdy problem, który mam, można rozwiązać, wręczając mi pączka, z wyjątkiem nierealnych szacunków . Prawda czy fałsz tak postrzega to programista: kierownictwo ma wszystko do zyskania (jak nowa łódź) według krótszych szacunków, podczas gdy programiści mają wszystko do stracenia (np. Miesiąc snu). Za to odpowiada jednak zarządzanie, więc za każdym razem wygrywają wojnę szacunkową. Myślę, że system szacowania działa najlepiej, gdy programiści decydują o terminie (wystarczająco trudno jest nam podać dokładne oszacowanie, więc jak by to zrobił menedżer?), Ale kierownictwo pozytywnie motywuje ich do ambitności, przy założeniu, że żaden programiści nie jest na to gotowy być trochę zła.

Zastanów się, jaką reakcję dajesz programiście, który może mieć pytanie, komentarz lub obawy. Czy istnieje pytanie „Czego teraz chcesz ?” lub „Dlaczego przeszkadzasz mi tym ?” rodzaj odpowiedzi? Jak skutecznie zachęcasz programistów do wyrażania obaw i komentarzy? To jednak tylko punkt wyjścia.

Po drugie, uważaj na to, gdzie próbujesz prowadzić te dyskusje. Wątpię, czy byłbym bardzo otwarty, rozmawiając o mojej maszynie roboczej z kimś z następnej kostki, gdybym wiedział, że mój menedżer jest w zasięgu wzroku od usłyszenia całej sprawy. Jeśli chcesz, aby ludzie udzielali otwartej i uczciwej informacji zwrotnej, musisz mieć pewną prywatność, aby wiedzieć, że ich odpowiedzi nie będą publicznie transmitowane ani wykorzystywane przeciwko nim.

Po trzecie, zastanów się, jakie masz umiejętności inteligencji emocjonalnej . Inteligencja emocjonalna dla kierowników projektów: umiejętności ludzi, których potrzebujesz, aby osiągnąć znakomite wyniki Anthony Mersino byłaby rekomendacją książkową, którą otrzymałem wczoraj z lunchu i dowiedziałem się o EQ. Jeśli naprawdę chcesz zagłębić się w psychologię, możesz skorzystać z różnych narzędzi do profilowania osobowości, np. Enneagram, style społeczne i MBTI.

Na koniec zastanów się, jaka jest kultura Twojej firmy. Czy błędy są zamiatane pod dywan? Czy skargi są wielkim nie-nie, które mogłyby naprawdę łatwo wpędzić kogoś w kłopoty? Jakie zachowania są nagradzane lub wspierane, a które są tolerowane i akceptowane? Chociaż niektóre z tych obserwacji to niektóre, mogą one również wymagać pewnych rozmów, które powinny być prowadzone z dala od biura lub w pomieszczeniu, w którym prawdopodobnie nie będzie podsłuchiwania. Najprawdopodobniej będziesz powtarzał, próbując użyć tego na początku. Nie jest to złe, jeśli próbujesz ustanowić nową praktykę i zachęcić ludzi do zabrania głosu, jeśli kultura była przede wszystkim taka, w której wszyscy po prostu „ssali”. To może być bardziej drażliwe niż inne odpowiedzi, ale to właśnie ja

Czy deweloperzy uważają, że jesteś ich orędownikiem? Rozumiem przez to, że wiedzą, że mogą podzielić się z Tobą swoimi obawami / frustracjami bez bycia pobitym? Czy czują, że o nie walczysz? Czy uważają, że doceniasz ich pracę? Czy uważają, że naprawdę chcesz, aby odnieśli sukces w swojej karierze?

Jeśli poczują się doceniani, zapewne będziesz mieć lepszą komunikację.

Jako programista jestem wielkim kujonem i brakuje mi umiejętności społecznych i nie przepraszam za to. W końcu jestem talentem, a ty zatrudniłeś mnie do mojego talentu. Jeśli potrzebujesz pracy motyla społecznościowego, będziesz mieć pokój pełen kierowników projektów zamiast programistów.

Wiem, że niektórzy programiści są bardzo sprytni społecznie, ale myślę, że mediana skłania się do introwertycznego nerda.

Gdy ktoś prosi mnie o zrobienie czegoś, absolutnie nie wyciągam żadnych wniosków i robię DOKŁADNIE to, co jest wymagane. Wygląda na to, że u niektórych kierowników projektów zawsze mam problemy, ponieważ oczekują, że wyciągnę wnioski na temat ich projektu, czego absolutnie nie zrobię, więc czasami rzeczy nie kończą się tak, jak się spodziewają, nawet jeśli okazują się być dokładnie tym, czego oczekują poprosili. Myślę, że dzieje się tak z niektórymi kierownikami projektów, ponieważ nie dostarczają wysokiej jakości HLD, BRD i kładą zbyt dużą wartość na społeczny aspekt zarządzania projektami, a nie na czarno.

Myślę, że tutaj zderzają się światy. Myślę, że w świecie zarządzania projektami umiejętności społeczne i jakość osobistej szczerości są ważnymi czynnikami, ale dla programistów takich jak ja nie znaczy to absolutnie nic. Nie robi mi to wrażenia, że ​​zastanawiam się, jak ważne jest to zadanie. Nie chcę nawet wychodzić na lunch ani na piwo, jak sugerują tu niektórzy ludzie.

To, czego naprawdę chcę, to dobre, wysokiej jakości HLD i BRD. Chcę harmonogramów i terminów, które są osiągalne, a jeśli zostaną wprowadzone nowe projekty lub plany, chcę, aby harmonogram i terminy zostały ponownie dostosowane. Pracowałem nad projektami, w których wymagania wydają się zmieniać w locie - dla mnie to moja czerwona flaga, że ​​mam do czynienia ze słabym przywództwem w projektach. Jako programista najgorsze, co możesz zrobić, to codziennie przedstawiać mi nowe wymagania dotyczące projektu, zwłaszcza po tym, jak mamy już harmonogram lub poczyniliśmy zobowiązania dotyczące harmonogramu. Niedopuszczalne jest wprowadzanie nowych wymagań bez rekompensaty terminów. Pracuję więcej godzin, pracuję do późna, nie mam z tym problemu, ale nie zawsze jest to coś ilościowego w rozwoju. Niektóre zmiany mogą potrwać kilka dodatkowych godzin, niektóre zmiany mogą potrwać kilka tygodni, aby odpowiednie prace badawczo-rozwojowe, testy, kontrola jakości itp. ... Nie zawsze jest to upieczenie ciasta, czasami jedna zmiana wymagań może przypominać zmianę całego przepisu. Byłem świadkiem, jak menedżerowie projektów stapiają się i mają napady złości podczas połączeń konferencyjnych, ponieważ ich terminy nie pozwalają na dodatkowy rozwój, ale proszą o rozwój, który nie był w początkowych wymaganiach projektowych.

Mogę jedynie podać swoje osobiste nastawienie i doświadczenie jako przykład, więc proszę nie wnioskować, że mówię w imieniu wszystkich programistów. Widzę te rzeczy tylko w mikrokosmosie z mojej własnej kariery, ale ten post opisuje dokładne warunki, które skłoniły mnie do wrzucenia przysłowiowego ręcznika.

Jak często rozmawiasz ze swoimi programistami? Nie mam na myśli spotkań na temat statusu projektu, pytań na temat rezultatów lub innych tematów, które im przynosisz - jak często siadasz z jednym z programistów, pytasz, jak się sprawy mają, i po prostu słuchasz .

Wiele innych odpowiedzi jest naprawdę dobrych - powinieneś przyjrzeć się sprawnemu rozwojowi. Potrzebujesz programistów, aby uczyć się i rozwijać w swoich rolach. Ale jeśli tak naprawdę nie słuchasz tego, co mówią twoi programiści (lub nie!), Musisz najpierw się tym zająć.

Dobre referencje na temat jeden na jednego - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Krótkie i słodkie. Excel w tym, co robisz - spowoduje to komunikację.

Co znaczy excelling dla twoich programistów? .. Czytaj, czytaj ponownie, tak, nawet studiuj PeopleWare

Wszystkie świetne pomysły i komentarze w powyższych postach!

Oto pomysł: wyślij swoich pracowników IT na warsztaty komunikacyjne w lokalnej szkole społeczności - oczywiście opłacane przez firmę.

Upewnij się, że a) warsztaty mają dobrą reputację oraz b) nie wysyłają razem swoich pracowników. Będą mieli tendencję do trzymania się razem i nie mieszania się z innymi członkami klasy, nie tylko zmniejszając wartość warsztatów, ale powodując zakłócenia dla innych.

Wydajna komunikacja zorientowana na zespół to umiejętność, której każdy może się nauczyć, ale jest tematem, który moim zdaniem brakuje w większości ścieżek szkolnych.

Ten pomysł w żaden sposób nie jest magiczną kulą, ale jest dobrym fundamentem układanki. Twoi współpracownicy nie tylko nauczą się lepiej ze sobą komunikować, ale dodatkową korzyścią będzie to, że zaczną lepiej rozumieć i szanować TWOJĄ pracę (komunikacja jest istotą PM).

Tylko moje 2 bity :)

Tylko po to, aby udzielić odpowiedzi na podstawie rekomendacji, która pojawiła się już w kilku odpowiedziach . Michael Lopp (aka rands ) pisał o zarządzaniu programistami i „wchodzeniu im do głowy” na swoim blogu Rands in Repose oraz w książce Managing Humans ( źródła książkowe ). Książka zawiera głównie zredagowane treści z jego postów sprzed 2007 roku i stanowi dobry sposób na zapoznanie się z częściami blogu związanymi z zarządzaniem (mówi także o np. Hazardzie i czy chcesz przeczytać, to inna sprawa). Jego pisanie jest na ogół świetne i często humorystyczne, więc czytanie go jest niewielkie.

Zabierz drużynę na piwo (i kupujesz).

Spóźniłem się na przyjęcie, ale właśnie zobaczyłem to pytanie.

Jedną rzeczą, która nie wydaje mi się zbyt dobrze poruszona, jest:

Chrząknięcia nigdy nie mówią całej prawdy garniturom. Rands mówi to w DNA, ale nie zajmuje się tym bezpośrednio, zajmuje się innym tematem.

Nosisz garnitur i podpisujesz czeki. Reprezentujesz interes firmy. Nie reprezentujesz inżynierów. Gdybyś to zrobił, nie podpisalibyście czeków, oni podpisaliby wasze.

To oczywiście nie jest wiadomość dla ciebie ani inżynierów. Ale kiedy inżynier wie, że poruszenie pewnych problemów - problemów - z jego miejscem pracy spowodowałoby znaczny konflikt - kompromis ryzyko / nagroda nie sprzyja inżynierowi. Inżynierom płaci się za wytwarzanie produktu, a nie za rozpoczynanie walk kulturalnych w miejscu pracy. Zaangażowanie się w nich jest szybką drogą do złego wykonania pracy.

Tak więc częścią zadania zarządczego jest zapewnienie inżynierom sposobu na otwarcie się na problemy, bez narażania polityki korporacyjnej i luzu kariery. W końcu miło jest mieć podbicia, a są też inne firmy, jeśli ta nie wydaje się odpowiednia.

Dziwi mnie, że nikt nie wspomniał o tej wspaniałej książce, która dokładnie zajmuje się twoim pytaniem i tematem - „Peopleware: Productive Projects and Teams” autorstwa DeMarco i Lister . Od redakcji: główne problemy związane z tworzeniem oprogramowania są ludzkie, a nie techniczne . Pierwsze trzy recenzje amazonu z łatwością wystarczą, by przekonać mnie do zakupu tej książki, gdybym był w twojej sytuacji.

Wiele odpowiedzi tutaj ma bardzo dobre punkty, ale chciałbym po prostu wrzucić kilka zasobów, które mogą pomóc. Miałem kilka sytuacji, które albo same się zapadły w gigantyczny bałagan, albo zostały rozwiązane bardzo skutecznie dzięki komunikacji między zaangażowanymi ludźmi. Trzy książki pomogły mi osobiście poprawić moje umiejętności komunikacyjne, szczególnie w sytuacjach stresu, gdy na linii jest dużo:

• Trudne rozmowy: jak dyskutować o tym, co najważniejsze
• Kluczowe rozmowy: narzędzia do rozmowy, gdy stawki są wysokie
• Kluczowe konfrontacje: narzędzia do rozwiązywania złamanych obietnic, naruszonych oczekiwań i złego zachowania

Po przeczytaniu twojego pytania myślę, że widzisz wartość komunikacji. Osobiście uważam, że komunikacja jest ważniejsza dla menedżera lub lidera niż umiejętności biznesowe lub techniczne. Ludzie, których przewodzisz, powinni mieć twarde umiejętności, których potrzebujesz, aby zrealizować większość projektu. Dobry lider techniczny lub kierownik projektu powinien być w stanie skoncentrować się na komunikacji, niezależnie od tego, czy znajduje się ona w zespole, czy między zespołem a klientem lub zespołem i podmiotem gospodarczym (lub nawet kombinacją tych trzech).

Przeczytaj kilka świetnych powieści, które dają wgląd w perspektywy pracowników technicznych:

• Hakerzy, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Katedra i Bazar, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Są one tak samo ważne jak wszelkie typowe wspomnienia z zarządzania (Drucker i in.).

Przez wiele lat pełniłem różne role - programista, starszy programista, kierownik techniczny itp.

Z twojego pytania - to całkiem oczywiste, że twoi programiści nie mówią ci rzeczy, ponieważ nie sądzą, że możesz pomóc.

Może to wynikać z 2 powodów.

1. Nie sądzą, że masz moc, aby to naprawić. Jednak myślę, że jest to mało prawdopodobne, ponieważ wtedy prawdopodobnie będziesz o tym wiedział, a także programiści narzekaliby na twój temat.
2. Jesteś osobą, która gdy programista przychodzi do ciebie z problemem, wykonuje jedną lub więcej z następujących czynności
   • Kiedy przychodzą do ciebie z problemami, mówisz im - lubię rozwiązania, a nie problemy.
   • Ładnie ich słuchasz, a następnie zlecasz im rozwiązanie problemu. Dajesz im krótką rozmowę o tym, jaki zaszczyt jest dla nich ponoszenie odpowiedzialności za naprawienie problemu. Z czasem twoi faceci rozumieją, że kiedy pójdą do ciebie z problemem, skończy się dodatkowa praca, więc nie przychodzą do ciebie z problemami.
   • Zaprzeczasz, że to problem. Podajesz przekonujące powody tego. Ale gdy to się dzieje, z czasem twoi ludzie dowiadują się, że nie ma sensu zbliżać się do ciebie z problemem.
   • Mówisz „Tak, rozumiem”. Mówisz, że tego rodzaju rzeczy zdarzają się od czasu do czasu i nic nie można zrobić. Jeśli to jest wzór, to znowu zrozumcie go.

Jeśli jest to którykolwiek z powyższych elementów, musisz to naprawić.

Najbardziej nienawidzę ludzi, którzy wchodzą między mnie, programistę i użytkownika końcowego. Najlepsi menadżerowie pozwalają mi to zrobić i zmienić nasze rozwiązanie, aby pasowało do tego, co moim zdaniem użytkownik chce lub może zrobić.

Najgorszą praktyką jest dla mnie przebieranie się za „dobrą” - zazwyczaj kierownik ma siebie, licencjata lub kogoś, kto pisze specyfikacje, które twórcy muszą interpretować i wdrażać, z wcześniej ustalonymi harmonogramami.

Jeśli jest to zindywidualizowane rozwiązanie, często nawet programiści nie wiedzą, ile to zajmie, a klient zwykle nie ma pojęcia, co jest dla nich najlepsze. Właśnie dlatego rozwój iteracyjny jest świetny. Nie jest to jednak sposób na większość transakcji, więc dobry menedżer będzie walczył o pracę jak wyżej.

Wreszcie, niektórzy programiści nie są dobrzy w komunikacji i nie mogą odnosić się do klientów. Być może najlepiej nadają się do problemów z jasnymi wymaganiami, szczególnie wyraźnymi wymaganiami technicznymi. Być może potrzebujesz programistów, którzy są lepszymi komunikatorami i chcą pracować nad rozwiązywaniem problemów biznesowych, a nie czysto technicznych.

Bardzo łatwo jest utrzymać zespół szczęśliwy

Staraj się ich słuchać wiele razy, ich pytanie zawiera również odpowiedzi. zachęcam członka zespołu do zgłaszania problemów i prawdopodobnego rozwiązania.

Wycieczka zespołowa to dobry pomysł (może to być jakiś plan gry)

jeśli twój projekt wymaga późnych nocy i pracy w weekendy i uważasz, że tak naprawdę nie dodajesz wiele wartości zespołowi, to dobrze byłoby przyjechać z czymś do jedzenia i docenić zespół za jego wysiłki i, jeśli to możliwe zorganizować trochę PTO

rób co dwa miesiące 1: 1 z każdym członkiem zespołu, aby upewnić się, że jest im wygodnie.

Wreszcie może być dobrym pomysłem zrozumienie projektu pod względem funkcjonalnym i technicznym.

Daj mi znać, jeśli masz więcej pytań

Jestem także (francuski, wybaczcie mojemu angielskiemu) menedżerowi oprogramowania, który ma wykształcenie inżynieryjne, ale początkowo nie ma szczególnego doświadczenia w dziedzinie oprogramowania IT. Tak więc na początku nie mam żadnego szczególnego zamiłowania do kodowania, ale byłem inżynierem jakości statystycznej ze szkoły Deminga, która ma bardzo odmienne nauczanie w stosunku do każdej „nowoczesnej” szkoły, która potem, choć udaje, że dziedziczy po Demingu. Najgorszy jest 6 sigma, lean był lepszy, ale niestety to, co się stało, to http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

„Pierwotnie Six Sigma została opracowana przez Toyota Quality Management (TQM) przez Motorolę, aby osiągnąć sześć poziomów jakości, a następnie poprzez Allied Signal i GE przekształciła się w projekty Black Belts oparte na statystykach, aby stać się programem redukcji kosztów - każdy projekt potrzebuje wyraźnego zwrotu z inwestycji. Innymi słowy, oczerniamy program z filozofii przywództwa na szereg jednorazowych projektów w celu obniżenia kosztów. Było to całkowite zepsucie oryginału i rzadko prowadziło do trwałych, trwałych zmian, ponieważ brakowało przywództwa i kultury.

„Podobna sytuacja uległa odchyleniu, gdy została zredukowana do zestawu narzędzi (np. Mapowanie strumienia wartości, tablice KPI, komórki, kanban).

„Lean i Six Sigma w żaden sposób nie odzwierciedlają oryginalnego myślenia o znakomitych japońskich firmach lub ich nauczycielach, takich jak Deming”.

Dzisiaj ruch Agile jest jak chudy (patrz kurs Jeffa Sutherlanda i jego uhonorowanie Deminga http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the -century-of-scrum / ), jest lepszy niż Wodospad, ale nadal jest bardzo daleki od oryginalnego nauczania Deminga, ponieważ zamiast czytać Deminga w jego oryginalnym tekście, guru po prostu przepakowują go w przybliżeniu, nigdy nie cytując swoich 14 zasad zarządzania, i sprzedaje narzędzia i seminaria, które same w sobie mają niewielką wartość.

Jeśli chodzi o dziedzinę oprogramowania, problemami są ludzie z jednej strony, którzy znają ogólne zasady, ale nie mają prawdziwych pomysłów, jak je naprawdę zastosować, az drugiej strony ludzie, którzy piszą oprogramowanie, ale ignorują zasady, ponieważ po prostu słuchają fałszywi guru, którzy sprzedawali im narzędzia, nie zdradzając im prawdziwych zasad, i powinni zbudować własne narzędzia zarządzania.

Więc dla mnie kierownik projektu oprogramowania powinien starać się pogłębić codzienną operatywność kodowania oprogramowania, nie tylko planując w Microsoft Project (lub wykres awarii z Agile) lub ładną prezentację w Powerpoint dla wyższej kadry kierowniczej, ale mieć pewne wartości również dla zespół programistów. Gdy zespół programistów ma problemy, nawet jeśli są to problemy techniczne, kierownik projektu może pomóc zorientować diagnostykę zewnętrznymi oczami. Potrafi patrzeć na kod, nawet jeśli nie rozumie drobnych szczegółów, może zadawać naiwne pytania, które mogą sprawić, że programiści zdadzą sobie sprawę, że nie pomyśleli o tej wskazówce (mam wiele osobistych przykładów, ale jest ona zbyt długa, więc raczej napisz artykuł na moim blogu).

Inną sprawą jest to, że staram się mieć ogólną świadomość ewolucji w tej dziedzinie, takich jak nowe ramy, nowe paradygmaty architektury, czytając artykuły techniczne. Wezmę udział w testach integracyjnych, sami piszę dokumentację (rzeczy, których programiści nienawidzą, więc robię dla nich, oczywiście karmiliby mnie rdzeniem), wszystko, co jestem w stanie zrobić praktycznie, aby pomóc zespołowi.

Ogólnie rzecz biorąc, programiści czują, że wykonują ciężką pracę i to prawda, często mówię im, że robię łatwą część, pozostając w abstrakcji, niemniej jednak staram się pomóc konkretnie w razie potrzeby - ponieważ mikro-zarządzanie nie jest również dobre, ponieważ może powodować uczucia interferencyjne.

Podsumowując: wyeliminuj hasła z programistami (tak naprawdę jest to jedna z 14 zasad Deminga), pokaż im, że zależy Ci na konkretnym oprogramowaniu projektowym, a nie na dokumentach lub spotkaniu tylko z wyższym kierownictwem.