Jak stwierdzić, czy wasi programiści osiągają słabe wyniki? [Zamknięte]

60

Jestem liderem zespołu z ponad 5 programistami. Mam programistę (nazwijmy go A ), który jest dobrym programistą, który pisze dobry, czysty i łatwy do zrozumienia kod. Jest jednak nieco trudny w zarządzaniu i czasami zastanawiam się, czy naprawdę osiąga słabe wyniki, czy nie.

  1. Nasza firma wymaga od programistów wskazywania postępów pracy w używanym przez nas narzędziu do śledzenia błędów, nie tylko w celu monitorowania programistów, ale w celu informowania zainteresowanych stron o postępach. Chodzi o to, że A aktualizuje postęp zadania tylko wtedy, gdy jest on wykonywany (może 3 tygodnie po pierwszej pracy), a to sprawia, że ​​wszyscy zastanawiają się, co się dzieje w środku tygodnia programowania. Nie zmieniłby swojego nawyku pomimo wielokrotnych badań. (W porządku, programiści nienawidzą papierkowej roboty, ja też)
  2. W ciągu ostatnich 2-3 miesięcy często wyjeżdżał na urlop z powodu różnych wydarzeń - albo jest chory, albo musi uczestniczyć w wielu osobistych wydarzeniach itp. (W porządku, złe rzeczy zdarzają się w szeregu. To tylko zbieg okoliczności)
  3. Definiujemy sprinty lub mapy drogowe na każdy miesiąc. Na początku sprintu omówimy ilość pracy, jaką każdy z programistów musi wykonać w sprincie, a programiści mogą ustawić czas potrzebny na każde zadanie . Zwykle nie będzie w stanie ukończyć wszystkich z nich. (Jest OK, programiści regularnie nie dotrzymują terminów nie z powodu swojej winy).
  4. Mam siedzibę w Singapurze. Nie jestem pewien, czy to ma znaczenie. Tak, wiadomo, że Azjaci są powściągliwi, ale czy to ma znaczenie?

Jeśli zdarzy się tylko jedno lub dwa z powyższych zdarzeń, nie będę czuł, że A osiąga słabe wyniki, ale wszystkie one występują razem. Mam więc wrażenie, że A osiąga słabe wyniki, a może ... Boże, niech się nie rozluźni.

To tylko uczucie oparte na moim wieloletnim doświadczeniu jako programisty. Ale mogę się mylić.

Niezwykle trudno jest zmierzyć pracę programisty, biorąc pod uwagę, że nie wszystkie dwa zadania są takie same, i nie ma standardowego celu pomiaru zaangażowania programisty w Twoją firmę. Zupełnie niemożliwe jest ustalenie, czy programista wykonuje swoją pracę, czy zwalnia. Wszystko, co możesz zrobić, to zaufać im - tak, ufanie im i zapewnianie im autonomii jest najlepszym sposobem dla programistów do pracy, wiem to, więc nie zaczynaj wykładu, dlaczego musisz ufać swoim programistom, dziękuję wszystkim dużo - ale jeśli nadużywają twojego zaufania, możesz to wiedzieć?

Wynik:

Właśnie z nim rozmawiam na temat mojego postrzegania jego występu. Był oburzony, gdy zasugerowałem, że mam wrażenie, że nie gra na najlepszym poziomie. Czuł, że było to całkowicie niesprawiedliwe uczucie. Odpowiedziałem wtedy, że to moje uczucie i nie wiedziałem, czy moje uczucie było słuszne, czy nie. Nie miałby nic z tego i natychmiast zakończył dyskusję.

Przed odejściem powiedział, że „postarałby się dać firmie więcej” bardzo zimnym tonem. Byłem zaskoczony jego reakcją. Jestem pewien, że obraziłem go w pewien sposób. Nie jestem jednak pewien, czy to była właściwa rzecz dla mnie, aby być z nim tak szczerym.


Moje pytanie brzmi: w jaki sposób możesz stwierdzić, czy twoi programiści osiągają słabe wyniki? Na pewno są doświadczeni liderzy zespołów, którzy wiedzą o tym lepiej ode mnie? 


Dodatkowe uwagi:

  1. Nienawidzę mikrozarządzania. Tak więc wszystko, co mamy dla naszego procesu oprogramowania, to Sprint (gdzie zadania są traktowane priorytetowo i przypisywane, a pod koniec miesiąca przegląd ilości wykonanej pracy). Programiści będą musieli aktualizować zadania w miarę ich codziennego wykonywania.
  2. Nie ma spotkania standup ani niczego w tym rodzaju. Głównie dlatego, że mamy swobodę pracy w domu i wszyscy tę wolność cenią.
  3. Chociaż to ja ustalam ostateczny termin, ale programiści dostarczą oszacowanie dla każdego zadania, a ja zdecyduję - na podstawie oszacowania - zadania, które przejdą do określonego sprintu. Jeśli nie będą mogli ukończyć zadań pod koniec sprintu, popchnę je do następnego. Tak więc teoretycznie można wykonać tylko 1 lub 2 zadania podczas całego sprintu, a następnie przesunąć pozostałe 99 zadań do następnego sprintu i nadal będzie dobrze, dopóki to uzasadnia - w postaci codziennych aktualizacji postępu pracy
Kierownik zespołu
źródło
10
Co powiesz na zasugerowanie programowania w parach dla określonych zadań i wyjaśnienie, że jest to metoda dzielenia się wiedzą i robienia czegoś innego. To może dać wgląd w to, jak on działa i dać ci wiedzę z pierwszej ręki?
dreza
44
Czy zastanawiałeś się, że z tą osobą dzieje się coś zupełnie innego? Kiedy ktoś często wzywa chorych i musi uczestniczyć w wielu osobistych wydarzeniach, domyślam się, że w jego życiu prywatnym dzieje się coś, co odwraca jego uwagę w pracy. Dokuczanie mu o jego występie nie pomoże żadnemu z was. Porozmawiaj z facetem, dowiedz się, co dzieje się w jego życiu prywatnym, pomóż mu, jeśli możesz, daj mu trochę swobody, jeśli jest dla ciebie wystarczająco cenny - podziękuje ci i prawdopodobnie wróci z zainteresowaniem, gdy jego życie osobiste będzie uporządkowane.
Marjan Venema
4
@MarjanVenema, rozmawiałem z nim, czuł, że już dawał z siebie wszystko, a mianowicie, moje przeczucie było złe. Ponadto nie wszyscy chcą dzielić z Tobą swoje życie prywatne. Ryzykujesz, że zostaniesz uznany za kogoś zajętego, pytając o życie prywatne innych osób
Kierownik zespołu
3
Co inni programiści w zespole myślą o tej osobie?
MarkJ
5
Ponownie otwieram to pytanie. Nie ma to dla mnie sensu w Miejscu Pracy, które dotyczy spraw ogólnych i interdyscyplinarnych. Konkretny pomiar wydajności twórców oprogramowania różni się od pomiaru wydajności niektórych innych zawodów, więc nie rozumiem, w jaki sposób jest odpowiedni do migracji. Jednak @ATeamLead powinieneś zaktualizować to pytanie, dodając więcej informacji, o które pytano w komentarzach, takich jak lokalizacja geograficzna.
Thomas Owens

Odpowiedzi:

49

To powinien być zaskakująco łatwy problem do rozwiązania.

Umów się z nim na drugie spotkanie. Powiedz mu, że akceptujesz fakt, że prawdopodobnie przyczyną jest twoje postrzeganie rzeczywistości. Następnie zakwalifikuj to za pomocą „jednak jeśli tak jest, to musimy współpracować, aby poprawić moją percepcję”. Wreszcie rzuć mu wyzwanie, aby rozwiązał ten problem, aby nie czuł się mikro zarządzany.

Ta dokładna rzecz zdarzyła mi się dawno temu. Dla mnie problemem było to, że nie podoba mi się możliwość, że ktokolwiek mógłby pomyśleć, że szukam dodatkowego kredytu po prostu wykonując swoją pracę. I to było dość uczciwe, ale musi być regularna pętla zwrotna między każdym członkiem personelu a jego przełożonym.

Jeśli nie ma, masz problemy.

Regularne, planowane 1: 1 to świetny pomysł. I, jak zauważyli ludzie, pojedynki nie muszą być ortogonalne do pracy w domu. Ale muszą obejmować trzy pytania: co robiłeś wczoraj? Co planujesz dziś zrobić? I ta, o której większość ludzi zapomina ... Co cię powstrzymuje?

To powiedziawszy, powinieneś starać się odradzać sytuacje, w których członkowie zespołu nigdy nie pracują razem. Pracowałem już wcześniej w tej sytuacji, co spowodowało brak zaufania w zespole i poza nim. Miej regularny dzień, kiedy wszyscy przychodzicie do biura. Odbywaj regularne spotkania, na których ludzie mogą wyrazić pomysły na usprawnienie procesów lub coś w tym rodzaju.

Nie rób z tego zdarzenia raportowania liniowego. Zrób to po prostu porozmawiać. Będziesz zaskoczony tym, czego się nauczysz. Jeśli to możliwe, zmień to w wydarzenie towarzyskie, idź na drinka w czasie pracy jako ćwiczenie integracyjne.

pdr
źródło
3
we need to work together to improve my perception- Dokładnie to, o czym myślałem, kiedy czytałem pytanie, zwłaszcza część „Rezultaty”.
Robert Harvey
2
Moje sympatie do dewelopera. Jeśli dostarczy to, o co prosi, na czas, to „uczucia” kierownika projektu są nie tylko bezpodstawne i nieistotne, ale także obraźliwe.
Steven A. Lowe
4
@ StevenA.Lowe: Czy coś mi brakuje? Pytanie mówi, że programiści mogą ustalić własne oczekiwania, a on wciąż je tęskni. Nie wspominając, że nie byłem winny przeceniania własnych umiejętności (a PO robi to samo ustępstwo), ale staram się zobaczyć, gdzie czytasz, że „dotrzymuje terminów”.
pdr
@pdr: lol być może źle przeczytałem, choć to pytanie wydaje się być edytowane codziennie. twórcy, o którym mowa, brakuje jego szacunków, ale najwyraźniej nie bardziej niż inni twórcy w zespole. podejrzewają o brak szkolenia i / lub przywództwa;)
Steven A. Lowe
2
+1 - problemem nie jest to, że osiąga słabe wyniki. Ponieważ PO powiedział, że nie wiem , że to, czy nie, i to jest problem, że zarówno on, jak i deweloper trzeba rozwiązać.
Zibbobz
12

Jest tu wiele świetnych porad i nie chcę z nich rezygnować, więc zamieszczam to jako osobną odpowiedź.

Po pierwsze, dla mnie (i najwyraźniej innych) jest oczywiste, że nie odkryłeś źródła problemu . Patrzysz na objaw i próbujesz go wyleczyć. Musisz dowiedzieć się, co powoduje tak duże tarcie między tobą a tym deweloperem. Być może jesteś zbyt autorytatywny (moja Właścicielka produktu niedawno opisała siebie jako posiadającą „Nieskończoną Moc” nad projektem i było to dla mnie obraźliwe, mimo że się śmiała, kiedy to powiedziała). Być może ma poważne problemy rodzinne (tłumaczyłby cały czas bez pracy). Występuje tutaj główny problem i dopóki go nie znajdziesz, nie zostanie to naprawione.

Good Catch!

Jeśli jego wydajność mogłaby być lepsza, to świetnie, że to ustaliłeś. Pamiętaj jednak, że jeśli jego słaba wydajność jest nadal dobra w porównaniu, musisz ostrożnie stąpać, aby nie stracić dobrego programisty. Trudno znaleźć dobrych programistów, a dobrzy programiści wymagają bardzo specyficznego zestawu rzeczy. Być może spójrz na test Joela, aby sprawdzić, czy jego potrzeby są zaspokojone.

Znajdź źródło problemu

Jeśli jest niezadowolony z czegoś związanego z pracą, którą wykonuje, możesz to naprawić tylko poprzez określenie źródła problemu. Pozwólcie, że wyjaśnię, że programista napisał dobry kod. Oznacza to, że uwielbia programować. Jest bardziej niż oczywiste, że jest sfrustrowany w pracy (z twojego opisu spotkania) i prawdopodobnie masz rację, że jego wydajność jest poniżej tego, gdzie powinna być, ale nie zakładaj . Pamiętaj, że wielu programistów po prostu nie ma umiejętności społecznych.

Albo nie jesteś idealny

Pamiętaj, że czasami będziesz mieć konflikty osobowości, szczególnie z introwertykami . Jeśli okaże się, że jest to konflikt osobowości, zastanów się, jak daleko jesteś gotów się posunąć, aby uzyskać wzrost wydajności (patrz 1)

Wszystko to powiedziane

Napisałem wpis na blogu o zarządzaniu programistami. Myślę, że powinieneś to przeczytać.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Nie mogę wystarczająco podkreślić ostatniej części tego postu.

Jeśli twoi programiści są w ogóle dobrzy, chcą kodować.

Twój programista, nawet jeśli zwalnia, nie chce się zwalniać. Musisz znaleźć źródło tego problemu, a może się okazać, że jest to coś, czego po prostu nie da się naprawić i trzeba go puścić, ale cokolwiek to jest, nie możesz podjąć świadomej decyzji, nie określając go.

deltree
źródło
10

Kiedy wydaje Ci się, że ktoś jest „nieco trudny w zarządzaniu”, tak jak to opisujesz, aby lepiej zrozumieć, jak się wykonuje i czy występują problemy (obiektywne lub subiektywne) wpływające na wydajność członków zespołu programistów, zastanów się nad ustanowieniem praktyki regularnych 1: 1 z twoimi członkowie zespołu, jak pokazano w doskonałym artykule Aktualizacja, The Vent i The Disaster :

... Nie sugeruję, że każdy 1: 1 jest krętą sprawą, by odkryć głęboko ukryte katastrofy, ale chcesz stworzyć cotygodniowe miejsce, w którym może pojawić się niezadowolenie. 1: 1 to szansa na wykonanie cotygodniowych przeglądów profilaktycznych przy jednoczesnym zrozumieniu stanu zdrowia zespołu.

... Dźwięk otaczający udany reżim 1: 1 to cisza. Całe słuchanie, zadawanie pytań i dyskusja, które mają miejsce w czasie 1: 1, to kierownicze utrzymanie prewencyjne. Zobaczysz, kiedy zainteresowanie projektem zacznie słabnąć i podejmij działania, zanim stanie się ono niezadowoleniem z pracy. Usłyszysz o napięciu między dwoma pracownikami i moderujesz dyskusję, zanim stanie się ona krzykiem na spotkaniu. Nagrodą za kulturę zdrowych 1: 1 jest wyraźny brak dramatu .


Bardzo mocną stroną wspomnianego artykułu jest to, że jest samowystarczalny , w tym sensie, że oprócz wyjaśnienia korzyści, zapewnia również zestaw praktycznych zaleceń, w zasadzie pozwalając zacząć ćwiczyć regularne 1: 1 bez zagłębiania się w inne źródła (chociaż szuka się dodatkowe informacje nie zaszkodzą, wiesz).

komar
źródło
Nie rozumiem, jak to się ma do mojego pytania.
Kierownik zespołu
@ATeamLead Zaktualizowałem odpowiedź, aby wyjaśnić połączenie. Zasadniczo, gdy masz regularne 1: 1, jest o wiele mniej tajemnic i trudności, które opisujesz. Przynajmniej takie było moje własne doświadczenie
komara
1
+1 to wiąże się z pytaniem, ponieważ jeśli zastosujesz się do tej praktyki, problemy takie jak to pytanie będą mniej prawdopodobne na pierwszym miejscu, a łatwiej je rozwiązać na drugim miejscu.
MarkJ
7

Oczywiście istnieje tutaj poważny problem z komunikacją. Być może wykonuje fantastyczną pracę, ale jeśli masz wrażenie, że nie wiesz, co on robi, to samo w sobie stanowi problem. A jeśli nie wiesz, co on robi, prawdopodobnie jego współpracownicy też tego nie wiedzą. Może to powodować problemy, gdy sprawdza swój dwutygodniowy kod. Zwłaszcza, jeśli ktoś pracował w podobnym obszarze.

Zawsze możesz zasugerować, aby sprawdzał / zapewniał aktualizacje częściej, aby zminimalizować tego rodzaju konflikty. Może to pozwolić ci rozpatrzyć twoją prośbę pod względem pomocy zespołowi zamiast „nie wiem, co robisz”.

Wiem, że pojedynki budzą nienawiść, ale tak naprawdę nie muszą się odbywać w tym samym pokoju. Szybka rozmowa lub grupowa aktualizacja Skype raz dziennie jest bardzo szybka i utrzymuje wszystkich na tej samej stronie.

Obecnie pracuję z Indii z zespołem w Irlandii i nie wyobrażam sobie, aby nie komunikować się z każdym z nich na co dzień i albo wiem z grubsza, na czym one są, albo mogę bardzo szybko się dowiedzieć.

Eoin
źródło
Więc kiedy robiłeś codzienny standup?
Kierownik zespołu
1
Robimy to o 9:30 GMT, która obecnie działa o 15:00 czasu indyjskiego. Mamy siebie i zespół, którzy prowadzą rozmowę konferencyjną, która nigdy nie trwa dłużej niż 15 minut i zwykle kończy się za 10. Jest kilku deweloperów z Irlandii, którzy pracują z domu i również mogą zadzwonić.
Eoin
7

Bezcelowy

Codzienne aktualizacje statusu są bezcelowe. To, że ludzie zgłaszają, że „dzisiaj mam ukończone 2,5%”, „dziś mam ukończone 3,74%” jest śmieszne.

Nie zapewnia żadnej wartości interesariuszom i denerwuje osoby wykonujące pracę.

Pozostaw je w spokoju.

Bezpodstawny

Jak przypuszczasz, na jakiej podstawie programista A „osiąga gorsze wyniki”? Jeśli jego praca jest wykonywana na czas, powinno to wystarczyć.

Mówisz, że nie znosisz zarządzania mikromaniami, ale dokładnie to opisałeś.

Nasza firma wymaga od programistów wskazywania postępów pracy w używanym przez nas narzędziu do śledzenia błędów, nie tylko w celu monitorowania programistów, ale w celu informowania zainteresowanych stron o postępach. ... Programiści będą musieli aktualizować zadania w miarę ich codziennego wykonywania.

To bez sensu (patrz wyżej) nonsens. Twój zespół nie rzuca burgerami, oni opracowują rozwiązania techniczne. Postęp nie jest liniowy, nie można go łatwo zmierzyć ani nawet oszacować. Nawet gdyby tak było, takie codzienne pomiary lub szacunki nie mają żadnej wartości.

Niebezpieczny

Przeanalizuj ponownie podstawy swojego „odczucia”, że programista A „osiąga gorsze wyniki”. Myślisz, że on / ona mogłaby zrobić lepiej, ale na podstawie jakich dowodów?

Nieszczęśliwy! = Słabe wyniki

Kontynuuj zgodnie z opisem, a w pewnym momencie programista A prawdopodobnie zdecyduje, że jest niedoceniany, dał wystarczająco dużo firmie i znajdzie inną firmę. Wyciśnięcie ostatnich 0,01% wysiłku pracowników jest o wiele mniej ważne niż utrzymanie ich na dłuższą metę.

Steven A. Lowe
źródło
Jak więc zarządzałbyś programistami? Daj im zadania do wykonania przez pewien czas, pozwól im robić, co chcą, nie zawracaj sobie głowy ich postępami, a pod koniec miesiąca z rezygnacją zaakceptuj, że tylko część wyznaczonych zadań zostanie wykonana?
Kierownik zespołu
Wymaganie% ukończenia rzeczy jest głupie, ale codzienne awarie, IMO, są wielkim dobrodziejstwem, gdy są krótkie, nieformalne i więcej o komunikowaniu potrzeb / wyzwań i priorytetów w momencie, gdy masz uwagę całego zespołu.
Erik Reppen
1
Nie zarządzam programistami, zarządzam projektami. Jeśli programista zobowiązuje się do wykonania zadania A w X dni, zamelduję się po X / 2 dniach, aby zobaczyć, jak sobie radzi jako formalność, ale moi programiści wiedzą, że natychmiast powiadomią mnie, jeśli napotkają cokolwiek, co spowoduje, że poślizgną się ostateczny termin. Po X dniach dostarczają. Jeśli masz ludzi, którzy chronicznie przewyższają obietnice i nie osiągają wyników, poproszenie ich o wymyślenie procentowej liczby postępów każdego dnia nie zrobi nic, aby zmienić podstawową kwestię (może to być oszacowanie, narzędzia, szkolenie itp.). Procesy i liczby! = Zarządzanie.
Steven A. Lowe
1
@ErikReppen: Zgadzam się z rodzajami wymienianych informacji, ale głęboko wierzę, że takie informacje powinny być przekazywane natychmiast po ich odkryciu i tylko zainteresowanym stronom, zamiast rozpraszać cały zespół codziennie bez wyraźnego powodu. Kluczem jest terminowa komunikacja, a nie rytuały;)
Steven A. Lowe
1
Pracowałem w zbyt wielu środowiskach, w których po prostu nie można polegać, nawet jeśli wszystkie strony byłyby tak odpowiedzialne, jak tylko mogły. Zainteresowany czy nie, każdy członek zespołu powinien być świadomy przeszkód, na jakie natrafiają jego członkowie drużyny. Nie chodzi o menedżera dla pracowników, chodzi o zespół współpracujący ze sobą. W scenariuszach, w których tak nie jest, zgodziłbym się, że to tylko kolejna bezużyteczna rozrywka.
Erik Reppen
5

Deweloperzy mogą nienawidzić wysiłku dokumentowania tego, co robią i aktualizowania statusów - ale to część bycia profesjonalnym programistą. Sugerowałbym, abyś mógł wskazać mu, że jego późne aktualizacje dziennika problemów powodują niepotrzebne negatywne postrzeganie jego pracy. Jeśli nie widzi, że jego brak komunikacji stanowi problem z wydajnością - jesteś liderem jego zespołu; powiedz mu, że tak.

Jeśli chodzi o szacowanie - to klasyczny problem. Polecam przeczytanie „Oszacowania oprogramowania - odsłanianie czarnej sztuki” Steve'a McConnella. W tym przypadku sprawiasz wrażenie, że większość programistów nie docenia. Jest to, co ciekawe, normalne i rzadko podejmowane. Sugerowałbym, że masz problem z samym procesem szacowania, a nie z tą jedną osobą.

Spróbuj „zamknąć pętlę” oceny i oceny szacunków i poprawić. Następnie, jeśli twoi programiści przychodzą na czas częściej, a ta jedna osoba nie jest, możesz zastanowić się, co z nim zrobić.

Na koniec zorganizuj spotkanie stand-up. Nawet jeśli jest to wiadomość błyskawiczna. Wszystko, czego chcesz, to żeby wszyscy wiedzieli „co zrobiłem, co robię dzisiaj, wszelkie problemy”. A jeśli pojawią się problemy, wyłącz je do późniejszej dyskusji. Tak robiłem wcześniej i było to skuteczne dla tego zespołu.

Andy Burns
źródło
4

Po pierwsze, dlaczego twoje sprinty są tak długie? Sprinty nigdy nie powinny przekraczać dwóch tygodni. Myślę, że większość twojego problemu leży właśnie tam. Poleciłbym skrócić czas sprintu na zasadzie próbnej, a następnie ponownie przeanalizować pytanie.

Co z odprawą kodu? Czy cały czas sprawdza swój kod? Osobiście uważam, że programiści nie są tak naprawdę menedżerami, a im więcej próbujesz zarządzać, tym bardziej będą sfrustrowani. W rzeczywistości nienawidzę wykonywać tych zadań aktualizacji i prawdopodobnie dlatego są po to PM i Leads. Ale jednocześnie zapewniam status podczas spotkań scrumowych lub za każdym razem, gdy się spotykamy. Teraz, kiedy przypisujesz zadanie, czy przypisują się do osi czasu, czy to ty przypisujesz im oś czasu?

Dlatego jedynym sposobem, w jaki mogę stwierdzić, czy ktoś nie wykonuje, jest mapowanie zatwierdzonej osi czasu na% wykonanej pracy. Oczywiście, jeśli ktoś powie, że napisanie metody sumującej dwie liczby zajmie mu dwa dni, wiesz, że jest problem, więc harmonogram powinien być realistyczny i uzgodniony przez obie strony.

Weź to w ten sposób - jeśli możesz napisać fragment kodu w ciągu godziny, daj mu godzinę + bufor. Jeśli dostarczy ci to w tak krótkim czasie, myślę, że dobrze sobie radzisz. Jeśli nie, zapytaj go, a potem to Ty decydujesz, czy dostarczy rozsądne wyjaśnienie, czy nie.

Jedną rzeczą, którą możesz zrobić, to zintegrować coś takiego jak XPlanner z narzędziem do kontroli wersji.

Bytekoder
źródło
Co z odprawą kodu? Czy cały czas sprawdza swój kod? Nie, nie robi - melduje się tylko wtedy, gdy skończy z jakąś funkcją, i może to być tydzień przerwy w kwestii odprawy. czy przypisujesz zadanie do osi czasu, czy to ty przypisujesz im oś czasu? Są do tego zobowiązani.
Team Lead
1
To znowu problem! Co jeśli coś stanie się z jego maszyną? Myślę, że powinien sprawdzać swój kod codziennie. Rozumiem, że kompilacja nocna może zostać zerwana, jeśli jego kod zawiera błąd, ale jednocześnie nie jest trudno naprawić błędy czasu kompilacji, chyba że koduje w notatniku lol.
Bytekoder
Ponadto istnieje wiele nietrywialnych zadań programistycznych, których nie da się tak łatwo oszacować. I oczywiście każdy programista - z definicji - wykonuje tego rodzaju zadania zamiast zadań programistycznych, które wykonali wcześniej (Dlaczego miałbyś przerobić coś, co można łatwo ponownie wykorzystać?). To sprawia, że ​​oszacowanie jest bardzo, bardzo trudne i nie będę ich winić, nawet jeśli ich oszacowania nie zostaną przeskoczone
A Team Lead
2
@Bytekoder, istnieją tysiące błędów środowiska wykonawczego / błędów logicznych, które spowodują uszkodzenie aplikacji. Twój kod kompiluje się nie oznacza, że ​​jest stabilny.
Kierownik zespołu
2
-1. Długość sprintu nie stanowi problemu. A częste sprawdzanie kodu w jedynej dostępnej gałęzi będzie służyło jedynie do przerwania kompilacji.
Amadeus Hein
4

Nie sądzę, aby zawód programisty z natury różnił się od innych zawodów, jeśli chodzi o identyfikację kogoś, kto zwalnia. Być może będziesz musiał iść z jelitami.

Osobiście uważam, że to dziwne, że A odmawia aktualizacji przez kilka tygodni. Jestem programistą pracującym w domu i istnieje domniemana umowa między mną a moim pracodawcą, że muszę codziennie aktualizować swoje postępy. To nie są „oficjalne” aktualizacje, to tylko krótki e-mail lub wiadomość błyskawiczna informująca go o tym, co się dzieje z oprogramowaniem, za które mam płacić. Aktualizacja trwa mniej niż minutę lub dwie i oferuje zamknięcie dla nas obu. W przypadku poprawek błędów oznaczam bilet jako rozwiązany w naszym narzędziu do śledzenia błędów do końca dnia. Nie są to dla mnie trudne procedury, chociaż lubię zrelaksowane środowisko pracy z bardzo małą ilością formalności.

Jestem pewien, że nawet codzienne aktualizacje będą mile widziane. Brzmisz bardzo, bardzo łagodnie w swoim poście. Jeśli podejrzewasz, że zwleka od dłuższego czasu, nie potrzebujesz innej wymówki, aby się z nim skontaktować.

UndergroundHero
źródło
0

Codzienne awarie, nawet jeśli przez Skype lub w pokoju czatu, są na drodze do tego, ale nie, jeśli traktujesz to jako aktualizację dla interesariuszy. Kiedy raz dziennie cały zespół zamelduje się, aby powiedzieć, nad czym pracują, jakie wyzwania napotykają i co planują robić dalej, otrzymasz kilka zwycięstw:

  • Niezależnie od tego, czy marnujesz czas z dobrych czy złych powodów, to, że coś trwa zbyt długo, będzie bardziej przejrzyste, zachęcając twoich twórców do proszenia o pomoc, kiedy będą jej potrzebować, i nie przesadzaj z badaniami, które prawdopodobnie nie musiały się wydarzyć lub rozwiązanie problemu związanego z wyzwaniem, gdy wkład reszty zespołu pomógłby im znacznie szybciej go wyeliminować.

  • Ty, jako menedżer, widzisz, gdzie ludzie najczęściej napotykają przeszkody, co pomaga lepiej oszacować i ewentualnie rozwiązać podstawowe problemy, które marnują czas / pieniądze.

  • IMO naprawdę pomaga zespołowi lepiej nauczyć się nie doceniać szacunków, gdy widzą, ile czasu zwykle zajmuje każdemu, aby czasami zrobili nawet stosunkowo proste rzeczy.

  • Często przypomnisz sobie o rzeczach, które należy przekazać w ramach zmiany priorytetów, gdy członkowie Twojego zespołu powiedzą ci, co planują robić dalej.

Więc zapomnij o „% ukończenia”. Po prostu wykonaj proces o tym, aby wszyscy byli wobec siebie tak samo szczerzy, jak wobec wszystkich innych, robiąc lepsze / bardziej wiarygodne szacunki, gdy zdobywają w tym więcej doświadczenia i dając ludziom więcej motywacji do zgłaszania postępów bez zmieniania ich w umysł -numeralne ćwiczenie polegające na umieszczaniu numeru na czymś, czego tak naprawdę nie można.

Wygląda na to, że wyższe kierownictwo rozumie, że terminy nie zawsze są przestrzegane. Robienie codziennych pojedynków da ci więcej amunicji na tym froncie, ponieważ będziesz miał znacznie bardziej szczegółowe pomysły na to, dlaczego nie zostaną trafieni.

I nie rób ich z góry. Zawsze pomyłka IMO. Ludzie potrzebują czasu, aby zatopić zęby z powrotem w problemie, zanim będą mogli bardziej niezawodnie informować o wszystkich problemach, IMO.

Szybkie standupy, które bardziej dotyczą komunikacji niż rozliczalności i po prostu wyznaczają cele, bardziej niż cokolwiek innego, sprawiają, że zwinna praca moim zdaniem. Resztę mogłem wziąć lub odejść, szczególnie Scrum, który uznałem za olej węża wykonawczego / interesariusza.

Erik Reppen
źródło
0

Niewystarczające?

Intensywność odpływa i przepływa podczas kariery danej osoby. Jeśli jest wart więcej niż kosztuje, porozmawiaj z nim i spróbuj ułatwić mu pracę. Albo zacznij szukać zamiennika.

Porozumiewanie się

Nie polegaj na cotygodniowych spotkaniach. Większość ludzi nie zrobi kompletnego braindumpa. Zaplanuj więcej 1: 1. Zapytaj ich, jak się sprawy mają, co możesz zrobić lepiej i co według ciebie mogą zrobić lepiej. Czasami nie będzie o czym rozmawiać, ale to jest w porządku. Mając więcej 1: 1, zwiększasz prawdopodobieństwo, że będą pamiętać o czymś.

Mają bardziej trwałe środki komunikacji

Możesz uzyskać więcej informacji od ludzi, jeśli nie sprawi, że poczujesz się jak dodatkowy obowiązek. Jeśli wszystkie są zdalne, niech używają programu do czatowania z funkcjami rejestrowania, takimi jak Hipchat lub IRC. Posiadanie bardziej wytrwałych środków komunikacji zachęca ludzi do większej rozmowy. Dawaj przykład i często mów, aby zachęcić innych do zrobienia tego samego. Przynajmniej raz dziennie, niech ludzie mówią, gdzie są przy swoich projektach. Czasami, po prostu patrząc na czat, możesz poczuć, jak postępują.

Kontrola źródła

Niech każdy codziennie sprawdza swój kod. Jeśli używasz git, poproś, aby wypchnęli do swojego oddziału w repozytorium firmy. Patrząc na zatwierdzenia, możesz stwierdzić, jak sobie radzą.

Oddziel środki od końców

Interesariusze chcą być na bieżąco? Sami zajmuj się interesariuszami. Częścią twojej pracy jako menedżera jest bzdura, aby Twoi koderzy mogli skupić się na swojej pracy. Przejrzyj dzienniki czatu i zatwierdzenia, a następnie napisz podsumowanie, jak się sprawy mają.

Rog182
źródło
-7

Oto moje sugestie:

  1. Innowacja: wyobraźnia i kreatywność wykorzystywane do obniżania kosztów i poprawy obecnej sytuacji.

  2. Korporacja: Chęć pomocy innym w osiągnięciu ich celów

  3. Inicjatywa: próba nietypowych zadań i zadań.

  4. Frekwencja: nieobecności lub spóźnienia, poniżej standardów.

  5. Czujność: umiejętność szybkiego zrozumienia nowych informacji i sytuacji

  6. Dokładność i jakość: przeglądy kodu, terminowość, wskaźnik emisji).

Ahmed Essawy
źródło