Jak pomagasz innym programistom się rozwijać?

Jako lider zespołu, jak możesz pomóc swoim programistom w rozwoju?

Powód, dla którego o to pytam, jest fakt, że pracuje ze mną kilku programistów i naprawdę chcę „odwrócić ich uwagę”, aby wykorzystać ich maksymalny potencjał i zapewnić im szczęście.

Ale nie bardzo wiem, jak to zrobić, czy muszę

1. Czy wchodzisz w interakcje z nimi często, czy dajesz im spokój, zostawiasz im spokój?
2. Poproś, aby postępowali zgodnie ze wskazówkami dotyczącymi kodowania, takimi jak egzekwowanie testów jednostkowych, stylów kodowania, czy też pozwolili im robić, co uznają za stosowne?
3. Bądź wobec nich łagodny. Takich jak nie obchodzi mnie, czy naprawdę wchodzą na urząd na 8 godzin, czy 4 godziny, czy też muszą egzekwować pewne „dyscypliny” w miejscu pracy?

Zgadnij co, każda pozycja ma swoje własne punkty, a różni ludzie opowiadają się za różnymi rzeczami. Takie zamieszanie utrudnia zarządzanie ludźmi w nieskończoność.

Co myślisz?

To bardzo cienka linia, którą musisz chodzić.

Ostatecznie wszelkie podejmowane przez ciebie decyzje techniczne są decyzjami, z którymi nie będziesz musiał żyć. Dokonaj ich jak najmniej, pozwól ludziom, którzy muszą z nimi mieszkać, dokonywać własnych wyborów. Ale prowadź ich, jeśli uważasz, że idą złą drogą.

Z drugiej strony wybory procesu są twoje. Podejmując decyzje, pozwól zespołowi poprowadzić Cię, ale ostatecznie musisz je podjąć. Przynajmniej na początku.

Zapoznaj się z trzema etapami dojrzałości zespołu programistów Roya Osherovego i sprawdź, czy możesz dowiedzieć się, na jakim etapie jest obecnie Twój zespół. Powinno to wpłynąć na sposób działania. Im bardziej chaotyczny, tym bardziej musisz wprowadzić kontrolę. na przykład. W niezwykle chaotycznym zespole musisz zacząć od przejrzenia całego zatwierdzonego kodu. Ale kiedy to robisz, poświęć trochę czasu, aby nauczyć ich wzajemnego sprawdzania kodu.

A jeśli uda ci się przeciągnąć drużynę z Chaosu do średniowiecza, zmień swoje zachowanie w tym momencie, w przeciwnym razie nie posuną się dalej (to ostatnie z osobistego doświadczenia).

Tak, zarządzanie ludźmi jest nieskończenie trudniejsze niż zarządzanie komputerami lub oprogramowaniem, właśnie dlatego, że każda osoba jest inna i możemy się zmieniać nawet z dnia na dzień. Więc nie ma uniwersalnej odpowiedzi. Uważam, że musisz dużo komunikować się ze swoimi programistami, aby ich poznać i zrozumieć ich indywidualne mocne i słabe strony, ich podejście do pracy i nauki itp. W ten sposób możesz dowiedzieć się o każdym z nich, czy preferuje dużo komunikacji i warsztatów lub samodzielnej nauki w cichym zakątku.

Programiści IMHO w normalnych okolicznościach mają naturalną potrzebę uczenia się (chyba że zostali wypaleni lub zmęczeni przez wcześniejsze złe doświadczenia zawodowe). Wszystko, co musisz zrobić, to zrozumieć, czego i jak chcieliby się uczyć, oraz zapewnić im narzędzia i czas, aby to zrobić (oczywiście w rozsądnych granicach).

Na przykład w naszym zespole możemy dowolnie definiować zadania edukacyjne, o ile są one (bezpośrednio lub pośrednio) związane z projektem. Zadania te trwają zwykle kilka godzin do jednego dnia na sprint (choć nie w każdym sprincie). (Niedawny przykład: otrzymałem zadanie uczenia się i eksperymentowania ze Scalą zaakceptowane na podstawie tego - i ogólnie funkcjonalne podejście - może pomóc uprościć złożoną część naszego kodu Java). Następnie są one traktowane priorytetowo i planowane w Sprint, podobnie jak zwykłe zadania. Zachęca się również i oczekuje się przeprowadzania pokazów / wykładów na temat tego, czego się nauczyliśmy, przekazywania wiedzy innym członkom zespołu (a potencjalnie nawet programistom w różnych zespołach).

Poproś, aby postępowali zgodnie ze wskazówkami dotyczącymi kodowania, takimi jak egzekwowanie testów jednostkowych, stylów kodowania, czy też pozwolili im robić, co uznają za stosowne?

Podczas pracy w zespole koniecznością jest przestrzeganie tego samego procesu rozwoju. Oczywiście proces ten powinien być najprostszą rzeczą, która mogłaby ewentualnie działać, a nie czymś opisanym w 600-stronicowym podręczniku. I proces ten powinien być określony i stale dostosowywane do sytuacji same drużyny . Więc jeśli zespół zgodził się na standard kodowania i TDD, muszą go przestrzegać.

Bądź wobec nich łagodny. Takich jak nie obchodzi mnie, czy naprawdę wchodzą na urząd na 8 godzin, czy 4 godziny, czy też muszą egzekwować pewne „dyscypliny” w miejscu pracy?

Jeśli nie znasz programisty, uważniej śledzisz jego działania, dostawy, rytm pracy itp. Można również przejrzeć jej kod (sam lub doświadczony i zaufany zespół) członek). Po zdobyciu zaufania może stopniowo zyskać więcej swobody. Ale najpierw trzeba zdobyć zaufanie. Jeśli chodzi o godziny pracy, z mojego doświadczenia wynika, że ​​elastyczne godziny są świetne do limitu, tzn. Dobrze jest mieć wspólne uzgodnione minimum, na przykład codziennie między godziną 11:00 a 14:00, kiedy (zwykle) programistów można znaleźć w miejscu pracy, aby można zadawać pytania lub zapraszać na spotkania. Ale poza tym nie ma sensu być surowym.

OK, jako lead, Twoim zadaniem jest wyciągnięcie projektów z domu. Musisz być tym, który egzekwuje standardy, recenzje kodu, prosi o raporty postępu i wszystkie te rzeczy, gdy programiści wolą, abyś zostawił je w spokoju. Te rzeczy są tylko wymaganiami zarządzania i oprócz recenzji kodu tak naprawdę nie rozwijają umiejętności pracowników.

Chcesz jednak pomóc im się rozwijać, co jest świetną cechą lidera.

Recenzje kodu są z pewnością pierwszym krokiem, pomogą ci zobaczyć, kto ma mniej niż gwiezdne umiejętności i potrzebuje poprawy, aby nawet uzyskać satyfikację. Pomogą deweloperom zobaczyć inne sposoby robienia rzeczy i zrozumieć inne części bazy kodu niż te, nad którymi osobiście pracowali. Moim zdaniem, recenzje kodu najlepiej przeprowadzać osobiście w sali konferencyjnej z deweloperem i recenzentem (kto powinien być innym programistą, jeśli to możliwe, nie zawsze prowadzi, sprawdzanie kodu innej osoby to także umiejętność, którą należy rozwinąć), a Ty jako moderator. Powinieneś robić notatki o tym, co trzeba zmienić, aby zidentyfikować trendy. To, czego tak naprawdę szukasz, to nie błędy lub zmiany (każdy może poprawić kod), ale konsekwentny brak uczenia się na błędach. Nie mów wyższemu kierownictwu, że przechowujesz te notatki, w przeciwnym razie będziesz zmuszony je wykorzystać jako pomiary w procesie przeglądu wyników, co szczerze przeczy celowi. Jeśli kilku programistów popełnia te same błędy, sesja szkoleniowa lub wpis wiki dotyczący wykonywania X może być w porządku.

Teraz rośnie namadło, które osiąga minimalny poziom. Po pierwsze, musisz wiedzieć, jakie zestawy umiejętności mają programiści i jakie zestawy umiejętności byłyby przydatne, i co mogliby być zainteresowani poznaniem. Musisz z nimi porozmawiać i przejrzeć ich CV oraz zrozumieć, co oni lubią i nie lubię tego robić.

Nie oddawaj wszystkich interesujących zadań tylko najbardziej wykwalifikowanym. To nie pomaga innym przyśpieszyć nowych problemów i technologii. Nie możesz przejść od bycia młodszym facetem, który ma tylko najmniejsze i najmniej ważne zadania, do starszego faceta, chyba że ktoś zaryzykuje i powierzy ci trudniejszą pracę. To powiedziawszy, mniej doświadczeni mogą potrzebować najpierw przypisać program do seniora, aby uzyskać bardziej zaawansowane umiejętności. Włączenie juniorów w przeglądy kodu wystawi ich również na bardziej zaawansowane techniki.

Najpierw daj im szansę samodzielnego rozwiązania problemu. Ale czasami ludzie utknęli i nie wiedzą, od czego zacząć (umiejętność, którą musisz rozwinąć, szczególnie u nowych programistów) lub co zrobić, aby rozwiązać problem.

Jeśli dasz im kilka dni na zbadanie czegoś, a oni nadal nie mają pojęcia, w jaki sposób zamierzają coś zrobić, być może będziesz musiał interweniować z pewnymi sugestiami. Jeśli jesteś specjalistą technicznym, możesz dać im kilka pomysłów na rozwiązanie problemu. Jeśli nie, spotkanie z kilkoma osobami podczas burzy mózgów może pomóc, jeśli dana osoba utknie. Lub poproś bardziej doświadczoną osobę o sugestie. To, czego nie chcesz robić, to zabrać im problem i rozwiązać je samodzielnie. Ale musisz zrównoważyć realizację projektu z ego programisty i czasami musisz wysłać go w określonym kierunku. Jeśli ma złe rozwiązanie i musi zostać naprawione, najgorsze, co możesz zrobić, to dać to komuś innemu, chyba że zamierzasz zwolnić programistę.

Widziałem kodowanych złych programistów, gdzie ktoś inny musi naprawić prawie wszystko, co robią. Inni programiści są urażeni tym i po prostu chcą, aby dana osoba wyszła z życia. Coddling złego programisty prowadzi do wyjścia dobrych programistów. Musisz znaleźć granicę między umiejętnościami kodowania i rozwijania. Jeśli dasz komuś kilka szans, a on lub ona nigdy nie wyzdrowieje, odetnij go.

Dla seniorów, którzy są już kompetentni w swoich obecnych zestawach umiejętności, jest łatwiej. Zwykle musisz dać im szansę zrobienia czegoś nowego, a oni wskakują i uczą się tego. Po prostu upewnij się, że interesujące możliwości się rozprzestrzeniają i nie wszyscy idą do Joe the Wonder Programmer, który może wszystko naprawić. Chcesz skończyć z dziesięcioma Joes, a nie tylko jednym.

Innym sposobem rozwijania umiejętności jest cotygodniowa 1-godzinna sesja treningowa. Niech każdy devloper będzie odpowiedzialny za konkretny temat. Pomoże to im lepiej komunikować się, sprawi, że zaczną coś dogłębnie badać i da wszystkim korzyści z ich badań. Niektóre tematy powinny być przypisane osobom, które nie są z nimi związane, aby zmusić je do poszerzenia wiedzy na ten temat, a niektóre powinny być przypisane osobom, o których wiesz, że są lokalnymi ekspertami w tym temacie. Tematy powinny być kombinacją rzeczy, w których potrzebujesz ludzi, którzy są dobrzy w zbliżaniu się do przyszłości lub w tej chwili, a także pewnej liczby nowych nadchodzących technologii, z których obecnie nie korzystasz, ale ludzie są zainteresowani tym, czy mogą się przydać. Ale wszystkim, w tym młodszym, należy przypisać temat.

W zależności od sposobu naliczania czasu dla programistów (jest to trudniejsze w przypadku fakturowania przez klientów), zwykle warto, aby programiści mieli 4-8 godzin tygodniowo na pracę nad osobistymi projektami. Będą podekscytowani, aby to zrobić. Najlepsi ludzie będą chcieli tam pracować i nauczą się dużo, które przydadzą się w przyszłości. Licznik fasoli nie jest w stanie zrozumieć potrzeby tego, ale tym razem wiele razy zwróci się satysfakcja pracowników, nowe funkcje lub oprogramowanie, którego nikt nie potrzebował (lub który pomoże zautomatyzować część znoju) i szybszy rozwój z powodu wyuczone nowe techniki. Niektórzy programiści wykorzystają ten czas wyłącznie na osobiste projekty niezwiązane z tym, co robisz (i to dobrze, nadal będą zdobywać umiejętności i cieszą się z okazji), ale wielu innych wykorzysta go do rozwiązania trwałych problemów, które ze względu na charakter zarządzania projektami, nikt wcześniej nie miał czasu naprawić. Możesz więc otrzymać refaktoryzacje, które przyniosą korzyści wszystkim; niektóre osoby mogą pisać testy, aby poprawić zasięg testów, aby ułatwić refaktoryzację; inni mogą odkrywać nowe funkcje, które mogą uczynić twoje oprogramowanie bardziej przydatnym dla jego klientów. Ogólnie rzecz biorąc, jeśli potrafisz przekonać liczniki fasoli, nie ma sposobu, aby stracić, pozwalając im na tę swobodę.

Musisz nauczyć się balansować, pozwalając ludziom na odrobinę rozciągnięcia swoich umiejętności i utrzymując projekt na właściwym poziomie. Im mniej doświadczony jest programista, tym bardziej ktoś musi sprawdzać postęp, szczególnie na wczesnych etapach, kiedy łatwiej jest zmienić kierunek. Niedoświadczeni mogą walczyć i bać się mówić. Ci ludzie zwykle wyjeżdżają tuż przed uruchomieniem, a okazuje się, że ich część projektu nie jest bliska ukończenia. Zachowaj szczególną ostrożność, aby sprawdzić postępy u każdego, kto często zmieniał pracę (chyba że był to wykonawca, ponieważ taka jest natura zawierania umów).

Bardziej doświadczonym można ogólnie zaufać, gdy powie ci, kiedy mają problemy ze znalezieniem rozwiązania i potrzebują pomocy kogoś z większą wiedzą w tej dziedzinie, lub też poszuka tej osoby i uzyska transfer wiedzy. Nie muszą więc być tak dokładnie monitorowani w początkowych fazach uczenia się nowego zestawu umiejętności dla projektu. Znajdą sposób na dostarczenie projektu. Ci, którzy mają doświadczenie w dostarczaniu, zwykle mogą zostać pozostawieni w spokoju, z wyjątkiem raportów z minimalnymi postępami (zwykle musisz również zgłosić się do kierownictwa, a zatem potrzebujesz pewnych informacji).

1. Daj zespołowi trudną pracę i narzędzia do ich rozwiązania. Nawet jeśli uważasz, że twoja praca jest przyziemna, ponieważ popierasz tylko system starszego typu, popchnij wszystkich, aby było lepiej.
2. Twój zespół powinien opracować standardy kodowania. Twoim zadaniem jest pomóc im w egzekwowaniu i dostosowaniu standardów.
3. Współpracuj ze swoim zespołem, aby opracować system szacowania. Twoim zadaniem jest koordynowanie tych wysiłków z zespołem i zapewnienie egzekwowania prawa. Siły zewnętrzne oczekują wysokiej jakości kodu w odpowiednim czasie i nie zawsze mają uzasadnienie lub logikę dla swoich żądań. Nie możesz uciec przed tym, ale musisz zarządzać obiema stronami. Gdy Twój zespół zyska reputację w zakresie wykonywania zadań, wszyscy będą bardziej akceptować twoje oszacowania czasu. Muszą wiedzieć, że będziesz ich wspierać, jeśli podejmą wysiłek.

Kiedy mówię, że twoim zadaniem jest egzekwowanie, nie mam na myśli jakiegoś drakońskiego stylu przywództwa. Kiedy grupa zdolnych osób ma wpływ na to, jak się zachowają, muszą również zgodzić się na konsekwencje nieprzestrzegania zasad. Ktoś ostatecznie dowodzi, a ponieważ jesteś liderem zespołu, to ty.

Czy wchodzisz w interakcje z nimi często, czy dajesz im spokój, zostawiasz im spokój?

Często z nimi współpracuj. Oczywiście nie chodzi o to, żeby ich denerwować, ale jako ich menedżer powinieneś regularnie z nimi rozmawiać o tym, jak się sprawy mają, i bardziej rozmawiać na temat genitaliów. Mniej więcej raz na kilka godzin brzmi odpowiednia częstotliwość, ale odtwarzaj ją ze słuchu.

Poproś, aby postępowali zgodnie ze wskazówkami dotyczącymi kodowania, takimi jak egzekwowanie testów jednostkowych, stylów kodowania, czy też pozwolili im robić, co uznają za stosowne?

Powinieneś oczekiwać, że będą pracować dokładnie według tych samych standardów, co Ty. Jeśli wykonujesz testy jednostkowe i postępujesz zgodnie z wytycznymi, powinny to zrobić. Muszą nauczyć się dobrze kodować, a Twoim obowiązkiem jest ich nauczyć.

Bądź wobec nich łagodny. Takich jak nie obchodzi mnie, czy naprawdę wchodzą na urząd na 8 godzin, czy 4 godziny, czy też muszą egzekwować pewne „dyscypliny” w miejscu pracy?

Na początku byłbym bardziej zdeterminowany, ale uspokoiłem się, gdy udowodnią, że można im ufać. Dawanie ludziom zaufania do pracy przez 4 godziny od samego początku wymaga kłopotów, jednak pozwolenie cennemu pracownikowi, który regularnie pracuje do późna, mieć pewien luz między projektami, jest w porządku.

Związane z trzema punktami:

Czy wchodzisz w interakcje z nimi często, czy dajesz im spokój, zostawiasz im spokój?

Powiem, że to naprawdę zależy od rodzaju osoby, z którą pracujesz. Niektórzy wolą dyskutować w ustalonym czasie przy kawie (powiedzmy około 10 rano) i inaczej pracować samemu, bez zakłóceń. Z nimi (OK, przyznaję, jestem dokładnie taki), generalnie wysyłam e-maile (nawet gdy są blisko mnie, na przykład 2-3 metry dalej), abyś mógł pozostawić im wybór, kiedy czytają twoje informacje . A tak przy okazji, nie pytaj ich, czy „dostali twoją notatkę” :-) I oczywiście, niektórzy „potrzebują” więcej wskazówek, więcej interakcji.

Poproś, aby postępowali zgodnie ze wskazówkami dotyczącymi kodowania, takimi jak egzekwowanie testów jednostkowych, stylów kodowania, czy też pozwolili im robić, co uznają za stosowne?

Jeśli chodzi o przestrzeganie wytycznych, jest to dla mnie całkiem jasne. Jeśli ustawisz wytycznych dotyczących stylu kodowania, zawsze dostarczać-test-case reguła, etc wtedy mają egzekwować je, jeśli są głównym programistą. W przypadku projektu, którym zarządzasz, każdy programista powinien przestrzegać twoich wskazówek, bez wyjątku, nawet w przypadku „ gwiazd ”.

Bądź wobec nich łagodny. Takich jak nie obchodzi mnie, czy naprawdę wchodzą na urząd na 8 godzin, czy 4 godziny, czy też muszą egzekwować pewne „dyscypliny” w miejscu pracy?

Jeśli już wiesz, jak ludzie pracują i są pewni siebie, to nie złamią twojej pewności siebie, możesz rozluźnić dyscyplinę. Myślę jednak, że w tym punkcie reguła (lub brak reguły), którą zdefiniujesz, powinna obowiązywać wszystkich. Ważne jest, aby nie było wyjątku. Obecnie bardzo cieszę się, że pracuję dla kierownika projektu, który po prostu mówi „tak długo, jak wykonasz 40 prac tygodniowo i praca zostanie wykonana, wszystko będzie w porządku”. W ten sposób możesz spóźnić się pewnego ranka, pracować tylko 6 godzin, a następne dwa dni pracować przez 9 godzin. Nie ma znaczenia „dopóki praca jest wykonywana”. Podoba mi się ta zasada.

Powiedziałbym, że ilość doświadczenia (nie tylko programowania, ale także w środowiskach biznesowych) twoich programistów jest kluczowym elementem w ilości czasu spędzanego z nimi. Obecnie pracuję z niektórymi programistami, którzy dopiero co wyszli ze szkoły, i stwierdzam, że potrzebują więcej wskazówek, jak pracować z innymi, nie tylko w zakresie dokumentowania / testowania / standardów, ale także w sposób interpersonalny (kiedy zadzwoń przez telefon lub spotkaj się osobiście, zamiast wysyłać e-maile). Kluczowa jest także znajomość naszej firmy, ponieważ wiele takich samych słów jest używanych w naszym kontekście biznesowym inaczej niż w kontekście tworzenia oprogramowania. I to jest zanim przejdziemy do akronimów ...

Ale nie bardzo wiem, jak to zrobić, czy muszę

1. Czy wchodzisz w interakcje z nimi często, czy dajesz im spokój, zostawiasz im spokój?
2. Poproś, aby postępowali zgodnie ze wskazówkami dotyczącymi kodowania, takimi jak egzekwowanie testów jednostkowych, stylów kodowania, czy też pozwolili im robić, co uznają za stosowne?
3. Bądź wobec nich łagodny. Takich jak nie obchodzi mnie, czy naprawdę wchodzą na urząd na 8 godzin, czy 4 godziny, czy też muszą egzekwować pewne „dyscypliny” w miejscu pracy?

Sugeruję, aby przeprowadzić kilka rozmów na temat tego, który styl najlepiej pasuje do tej indywidualnej osoby i z czasem dostosować. Niektóre osoby mogą chcieć spotykać się raz dziennie, aby sprawdzić, jak się sprawy mają, podczas gdy inni mogą uznać, że raz na kwartał jest to nadmierne. Niektóre osoby mogą chcieć formalnej oceny wyników co miesiąc, a inne mogą po prostu porozmawiać o wydajności. Kluczem jest doprowadzenie związku do etapu, na którym można dowiedzieć się, co działa, a co nie.

Drugą stroną tego byłoby studiowanie filozofii rozwoju osobistego, choć może to być trudna droga, jeśli ktoś zostanie niepoprawnie przeanalizowany. Jeśli chcesz kilka przykładów takich filozofii, możesz spojrzeć na Myers-Briggs, Enneagram i Strengths Finder 2.0 na kilka przykładów.

Pytasz ich, jak woleliby pracować.
Co chcieliby zmienić i tak dalej.

Nie wszystko na raz. Po prostu ... jak rzeczy się pokazują.
Pozostań naturalny. (albo poczują strach)

A potem ... możesz nawet nauczyć się od nich różnych rzeczy . Jeśli nie sądzisz, że tak się kiedykolwiek stanie (zbyt duży dystans w edukacji i doświadczeniu) tak naprawdę nie zawracaj sobie głowy staraniem się, by dorastali, to tylko ich zdezorientuje.

(W tym szczególnym przypadku zrezygnuj z niego i rządzisz żelazną pięścią , jest to bardziej uczciwe niż udawanie , że ich nie interesujesz )

Ustanowienie procesu demokratycznego , głosowanie, omawianie kwestii.

Jak każdy prezydent, dotrzymujesz ostatniego słowa: weto .
Reszta należy do grupy.

Jednym ze sposobów, aby pomóc swoim ludziom rosnąć, jest pozwolić im robić to, co robią najlepiej.

Jeśli będziesz miał szczęście, będziesz miał jednego lub dwóch programistów, których osobiste standardy „testowania” są surowsze niż w całym dziale. W takim przypadku możesz umieścić je w „systemie honoru” w odniesieniu do tych kwestii lub nawet zastosować ich metody.

Dzięki „elastycznemu czasowi” możesz pozwolić sobie na większą swobodę pracy dla bardziej produktywnych pracowników. Tak długo, jak wykonują robotę, mniej martwię się o ich godziny. Niektóre osoby przychodzą, spędzają 5-6 „nieprzerwanych” godzin i osiągają więcej niż inni, którzy spędzają 10 wolnych godzin.

Ale jednym z twoich zadań jako menedżera jest poprawianie SŁABYCH. Oznacza to, że będziesz musiał BEAR DOWn na niechlujnych programistach, których standardy testowe są nieodpowiednie, lub na ludziach, którzy nie są wystarczająco produktywni - ponieważ nie tracą czasu.