Mądrzejszy człowiek ode mnie powiedział „Możesz zmusić ludzi do pozostania w biurze przez 80 godzin tygodniowo, ale nie możesz zmusić ich do pracy więcej niż 40 godzin tygodniowo”.

W tym problem napotkasz i nic nie możesz zrobić.

Ludzie przychodzą do biura, ponieważ im płacisz. Pracują, bo chcą. I wiesz, dlaczego ci ludzie nie mają motywacji do pracy.

Sposób, w jaki pracodawca traktuje ludzi, nie przynosi żadnych korzyści. Mogą otrzymywać nieodpłatne nadgodziny od swoich pracowników, ale może to skutkować słabym morale, niską jakością pracy i dużą rotacją personelu (wraz z kosztami / czasem wymaganymi do przeszkolenia zastępców).

Na dłuższą metę termin, myślę, że musisz naciskać, aby zmienić sposób myślenia pracodawcy. Jest mało prawdopodobne, aby doświadczyli nagłego oświecenia, więc będziesz musiał to odrzucić. Pukaj dalej do drzwi, wskazując na zagrożenia i problemy związane z ich podejściem, aż w końcu możesz gdzieś dojść. Uważaj jednak - będziesz musiał podchodzić do tego subtelnie, ponieważ nie chcesz być postrzegany jako drażniący. (Ponadto - nie znam wielkości ani struktury firmy - być może będziesz musiał przejść przez swojego bezpośredniego przełożonego i poprosić go, aby wnieśli go za Ciebie po drabinie).

( Jeśli firma jest w trudnej sytuacji finansowej, więc musisz odpowiednio dostosować swoje żądania. Jest więcej rzeczy niż pieniędzy - być może dodatkowy coroczny urlop, czas zastępczy, możliwość wcześniejszego zwolnienia w piątek, darmowe owoce / napoje bezalkoholowe mogą sprawić, że cała różnica )

Na krótką metę można wiele spróbować, aby poprawić wyniki zespołu.

• Firma może nie doceniać ich wysiłków - ale nic Cię przed tym nie powstrzyma. Mówiąc „dziękuję” za dobrze wykonaną pracę, chwaląc dobrą pracę i naprawdę okazywanie wdzięczności, gdy ktoś robi wszystko, co więcej, pokaże, że docenisz jego ciężką pracę. (Również przynoszenie od czasu do czasu pudełka pączków może zdziałać cuda!)
• Bądź elastyczny. Ponownie, nie wiem, jaki rodzaj pracy wykonujesz, ale jeśli próbować ułatwić życie ludziom. Pozwól im wymknąć się wcześniej, jeśli mają spotkanie lub chcą odebrać swoje dzieci. Uważam, że jeśli dasz trochę luzu w takich sytuacjach, odzyskasz to dwukrotnie, gdy terminy są napięte lub plecy są pod ścianą. Chodzi o dawanie i branie.
• Pomoc dotycząca kariery. Porozmawiaj na czacie z członkami zespołu. Dowiedz się, gdzie chcą być za 5 lat. Spróbuj (nie zawsze jest to możliwe), aby dać im kontakt z tego rodzaju pracą. Może to uczenie się nowej umiejętności lub technologii, może to podjęcie innego rodzaju pracy (sprzedaż, wsparcie, zarządzanie projektami). Jeśli ludzie się uczą i czują, że ich praca stanowi dla nich wyzwanie, prawdopodobnie będą nad nią ciężej pracować.
• Bądź adwokatem. Wszystkie poprzednie punkty należą trochę do tej kategorii. Musisz wiedzieć (a przynajmniej czuć), że chociaż firma chce, żebyś nimi zarządzał, to ty też walczysz w ich kącie. Powiedz, że doceniasz pozycję, w jakiej się znajdują - ale także powiedz im, że próbujesz ją zmienić. Powiedz im, czego próbowałeś i jakie postępy robisz.
• Komunikuj się. Kontynuując powyższe, informuj o swoich postępach. Jeśli usłyszysz coś od kierownictwa, zdecyduj, co jeśli cokolwiek, możesz podzielić się z zespołem. Jeśli czują się zaangażowani, poczują się zaangażowani, a tym samym bardziej zaangażowani.
• Dokładniej monitoruj. Powyższe nie będzie działać dla wszystkich. W takich przypadkach należy je uważniej monitorować. Wiedz, nad czym pracują. Poproś ich, aby zobowiązali się do terminu dostawy (musisz wiedzieć, czy jest to rozsądne lub czy jest wypełnione), a następnie regularnie sprawdzaj, aby upewnić się, że dotrzymali tego terminu. Jeśli nie, dowiedz się dlaczego. Nie dążysz do konfliktu, powinna to być dyskusja typu „no cóż, jak mogę pomóc ci dotrzymać terminu następnym razem” - może proces wymaga usprawnienia, może zostały przerwane lub ponownie przydzielone, może coś poszło nie tak . Jeśli terminy są nieustannie przekraczane, prawdopodobnie musisz przejść ścieżką dyscyplinarną.

Twoim zadaniem jako lidera / menedżera zespołu jest chronienie członków swojego zespołu przed śmieciami pochodzącymi z góry, aby byli produktywni.

Musisz dowiedzieć się, DLACZEGO muszą Praca w nadgodzinach. Czy są one generalnie nieproduktywne, czy też ramy czasowe są nierealne? Jeśli są nierealne, należy podjąć kroki, aby były one realistyczne… Zaangażuj zespół w dokonywanie szacunków dla skal czasowych; a jeśli kierownictwo naciska na nierealistyczne skale czasowe, musisz naciskać na więcej zasobów.

Kierownictwo nie lubi, gdy to mówisz… nikt nie lubi, gdy ludzie się cofają; ale w końcu mogą wolą, gdy wzrasta produktywność, ludzie są szczęśliwsi, a terminy są dotrzymane.

Problem kulturowy

Myślę, że odpowiedź Karla Bielefeldta jest najlepsza, ale chciałbym to powiedzieć jeszcze mocniej: masz problem kulturowy, który nie ma nic wspólnego z Chinami. Twój szef chce naprawić błędy w twoim oprogramowaniu? Niesamowite!!! W mojej karierze zdarzały się niezliczone okresy, kiedy chciałem nadać priorytet naprawianiu błędów, ale kierownictwo potrzebowało większej ilości funkcji.

Prawdziwym problemem jest podejście Twojego zespołu do jakości kodu . Ostatecznie jest to problem z dojrzałością. Większość zespołów kończy z błędnym, zepsutym kodem z kilku częstych, powtarzających się powodów:

• Za mało czasu / zasobów spędzonych na testowaniu
• Za mało czasu spędzonego na dokumentowaniu + sprawdzaniu kodu
• Zbyt duże skupienie się na dostawie
• Gotowość do narastania nieograniczonego długu technicznego

Naprawianie tych problemów nie jest zadaniem twojego szefa. To nie są problemy organizacyjne ani korporacyjne. To są problemy programisty i programiści muszą przyjąć odpowiednie podejście i strategię, aby sobie z nimi poradzić.

Przeczytaj na zimno

Bez wiedząc coś więcej o Twojej firmie, zespole lub praktykach biznesowych, zamierzam poczynić kilka przewidywań:

• Twoja baza kodu ma niewiele testów jednostkowych lub nie ma ich wcale (pokrycie kodu < 20%)
• Twój zespół bierze udział w testowaniu ręcznym (niewiele lub nie ma zautomatyzowanych testów integracji / funkcjonalnych / akceptacyjnych)
• Twój zespół wkłada niewielki wysiłek w przegląd kodu (albo traktuje to jako pieczątkę, okazję do nieuzasadnionego dziurkowania lub całkowicie pomija)
• Twój zespół rzadko dokumentuje kod lub dodaje trywialne komentarze (// następna linia drukuje wiadomość do pliku dziennika)
• Twój zespół nie zajmuje się regularną refaktoryzacją lub tylko 1 lub 2 inżynierów, którzy uważają, że refaktoryzacja jest nawet pożyteczna.
• Twój zespół uwielbia pisać nowy kod zielonego pola i stara się unikać utrzymywania istniejącego kodu, takiego jak plaga
• W Twoim systemie brakuje automatycznych wskaźników sukcesu (liczba udanych transakcji / żądań w porównaniu z próbami, liczba błędów na transakcję, liczba przekroczeń czasu, błędy napotykane przez użytkowników itp.)

Wychodzenie z dziury

Nawet jeśli mam rację tylko w przypadku połowy przewidywań, to wystarczy, aby wyjaśnić Twoje kłopoty. Rozwiązaniem nie jest więcej nadgodzin ani próba przekonania szefa, żeby się wycofał. Częściowo problem polega na tym, że w swoim zespole brakuje silnego technicznego przywództwa. Twój zespół naprawdę potrzebuje starszego inżyniera lub pięciu, którzy mogą promować dojrzałe praktyki tworzenia oprogramowania, które ograniczają liczbę defektów na jak najwcześniejszym etapie.

Jak możesz sobie wyobrazić, zalecane poprawki będą bezpośrednio usuwać defekty, które przewidziałem powyżej , wraz z krótką notką o tym, dlaczego warto zainwestować w to ćwiczenie:

• Testy jednostkowe - myślę, że 80% to absolutne minimum dla długoterminowej bazy kodu, którą można konserwować. Dążę do 98% + i prawie zawsze jest to osiągalne. Nie chodzi o zaznaczenie jakiegoś pola na masochistycznej liście kontrolnej SDLC. Po pierwsze, nie cały kod można łatwo przetestować jednostkowo. Pisanie testów na taki kod zmusza programistę do ponownego przemyślenia projektu i organizacji kodu. Umożliwienie testowania jednostki kodu czyni to lepszym . Mówię to jako absolutną prawdę, ponieważ wierzę, że tak jest i nigdy nie widziałem kontrprzykładu. Co więcej, testy jednostkowe ujawniają wiele błędów, które ostatecznie ujawniają się w środowisku produkcyjnym i często w podstępny, trudny do odtworzenia sposób. Wreszcie, testy jednostkowe służą jako rodzaj dokumentacji zamiarów programistów, gdy pierwotny koder przeniósł się do innego projektu, a opiekun próbuje wywnioskować, co chciał osiągnąć. Twierdzę, że testy jednostkowe zawsze oszczędzają więcej czasu niż kosztują, dlatego dojrzali deweloperzy zainwestują czas w ich napisanie. Niestety, założyłbym się, że mniej niż 20% deweloperów na całym świecie uważa się za „dojrzałych” według tego wskaźnika. : / Nie możesz powiedzieć, jak dobrze sobie radzisz z testami jednostkowymi, dopóki nie zaimplementujesz analizatora pokrycia kodu w procesie kompilacji i nie umieścisz wyników na „panelu chłodnicy”, który będzie widoczny dla całego zespołu przez całą dobę.
• Testy akceptacyjne - Twój zespół ma wiele błędów do naprawienia, ponieważ zleciłeś użytkownikom wykonanie odpowiednich testów, co jest zrozumiałe, że twój szef jest zły. Twoi programiści są leniwi i uważają, że ktoś inny powinien przeprowadzać testy (np. Dedykowani testerzy) i najwyraźniej nie obsługują zestawu testów automatycznych. Potrzebujesz testów, które są uruchamiane przy każdym scalaniu, przy każdej kompilacji produkcyjnej, przy każdym wdrożeniu w każdym środowisku testowym i przy każdym wdrożeniu produkcyjnym. Chcesz szerokiego zasięgu poprzez generowanie losowych testów i obszerną walidację danych w swoim kodzie. To jest cały temat sam w sobie, ale jest również rdzeniem twojego problemu. Nie musisz pisać tysięcy przypadków testowych, aby mieć przydatny zestaw testów akceptacyjnych. Ale musisz znaleźć dobry framework do testowania, poczuć się z nim bardzo komfortowo i uczynić z niego swojego nowego najlepszego przyjaciela.
• Przegląd kodu - wielu programistów nie uzyskuje łatwo dostępnej wartości z przeglądu kodu. Po pierwsze, przegląd kodu powinien pomóc w utrzymaniu spójnego stylu i podejścia w całym zespole. Nie sądzę, aby programiści musieli pisać kod tak, jakby wszyscy byli klonami, w stylu a la XP. Ale pomaga egzekwować pewne wspólne standardy, bez angażowania się w formowanie wojen. Obejmuje to wzorce projektowe i idiomy kodowania, które często występują w Twojej przestrzeni problemowej. Po drugie, przegląd kodu jest okazją do nauki, zarówno dla autora, jak i dla recenzentów. Jest to szczególnie dobry sposób dla młodszych programistów, aby uczyć się dobrych praktyk od starszych programistów (zakładając, że seniorzy są w rzeczywistości dobrymi programistami). Recenzenci powinni zadawać wiele pytań, gdy kod nie jest jasny, a proces powinien być oparty na współpracy, a nie na konfrontacji. Po trzecie, dobrzy recenzenci często mogą wykryć błędy po prostu czytając kod. Nie będzie się to zdarzać przez cały czas i nie zastąpi testów. Ale jest to fajny bonus , który otrzymujesz „za darmo” tylko dlatego, że zadałeś sobie trud poproszenia dwóch innych osób o przeczytanie Twojego kodu. Każde scalenie powinno mieć przegląd kodu .
• Pisanie dobrej dokumentacji jest pomijane przez około 95% wszystkich programistów, biorąc pod uwagę mój wysoce nienaukowy osąd. Nie potrzebujesz dokumentacji na poziomie NASA, aby ulepszyć swoją bazę kodu, ani każdy kod nie wymaga tego samego poziomu dokumentacji. Ogólnie rzecz biorąc, im więcej kodu jest wykorzystywanych ponownie, tym więcej powinien zawierać dokumentacji. Dlatego każdy rodzaj współdzielonych bibliotek / klas / modułów powinien otrzymać dodatkową dokumentację, szczególnie dotyczącą takich rzeczy, jak bezpieczeństwo wątków, bezpieczeństwo wyjątków, zamierzone użycie, szczegółowe funkcje API, obsługa wartości zerowych itp. Kod aplikacji na zamówienie powinien być bardziej przejrzysty i samodzielny dokumentowanie. Ponownie, nie możesz stwierdzić, jak dobra jest twoja dokumentacja, dopóki nie wygenerujesz jej jako części procesu budowania i nie opublikujesz na lokalnym serwerze WWW. Wiele błędów pojawia się z powodu niezgodnych założeń i oczekiwań między inżynierami (dotyczące prawidłowych wartości pól, miejsc sprawdzania poprawności itp.). Dokumentacja pomaga złagodzić ten tryb awarii.
• Refaktoryzacja - to jedna z najcenniejszych rzeczy, jaką możesz zrobić dla baz kodów crufty, które nabrały dużego zadłużenia technicznego. To chyba jest druga rzecz, którą powinieneś zrobić (oczywiście po napisaniu testów jednostkowych!). W przypadku małej firmy lub startupu zdarzają się sytuacje, w których szybkie poruszanie się i zepsucie rzeczy jest właściwym sposobem działania. Ale to nie może być utrzymywane w nieskończoność. Jeśli nie będziesz mocno naciskać na przerwy w refaktoryzacji, Twój zespół w końcu spadnie z klifu długu technicznego (brzmi to tak, jakby trzymał się małej gałęzi, gdy mówimy). Dobrzy inżynierowie i tak powinni naciskać na refaktoryzację. Fakt, że nie wspomniałeś o żadnych środkach zaradczych zalecanych przez programistów, mówi mi, że brakuje ci takich inżynierów. Kod nie musi być doskonały przy pierwszym pisaniu (i prawie nigdy nie będzie). Ale powinieneś być w stanie poprawić to za każdym razem, gdy go dotkniesz. Refaktoryzacja powinna być drugą naturą całego zespołu i każdy powinien czuć się do tego upoważniony, gdy zmiany są wyraźnie korzystne dla całego zespołu. Oczywiście chcesz uniknąć nieodpłatnej refaktoryzacji. Wątpię jednak, by stanowiło to nawet ryzyko dla Twojego zespołu.
• Operacje / metryki - nie tylko potrzebujesz testów na poziomie kodu i poza produktem, ale także wskaźników operacyjnych, aby zobaczyć, jak produkt wykonuje. Wskaźniki te powinny obejmować parametry jakości (liczba transakcji, szybkość, liczba błędów / współczynniki itp.). Twój szef nie powinien żądać od Ciebie naprawiania błędów. Powinieneś mieć własne cele jakościowe zdefiniowane przez zespół, które zmuszają cię do przejścia do trybu czyszczenia, gdy zbłądzisz poza nimi.

Następne kroki

Co ciekawe, jedyną rzeczą, o której nie wspomniałeś, jest to, że szef żąda dostarczenia 20 nowych funkcji do przyszłego tygodnia, oprócz naprawienia wszystkich błędów. Zakładam, że jest jakaś taka presja, ale twój brak podkreślenia tego daje mi nadzieję. Sugeruje to, że masz miejsce, aby poprosić o wstrzymanie dostarczania funkcji, podczas gdy Twój zespół spłaci ogromny dług techniczny, który narosł. Jeśli przygotujesz dla swojego szefa szczegółowy plan, w jaki sposób zamierzasz systematycznie podnosić jakość swojego produktu i utrzymywać wysoki poziom jakości w przyszłości , być może znajdzie wsparcie dla takiego planu.

Oczywiście, musisz popracować z zespołem nad planem i uzyskać zgodę na to, które kroki będą najbardziej odpowiednie i skuteczne. I na pewno będą kompromisy, które trzeba będzie osiągnąć ze wszystkich stron. Być może będziesz musiał amortyzować refaktoryzację w kilku cyklach produktowych, podczas gdy twój szef może od razu zauważyć potrzebę zbudowania przyzwoitego zestawu testów, nawet kosztem zamrożenia funkcji.

Podsumowując, myślę, że Twój sytuacja jest całkowicie do uratowania. Myślę jednak, że wymaga to dużej zmiany myślenia i nastawienia całego zespołu. Zamiast postrzegać swojego szefa jako wroga, powinieneś zacząć myśleć o nim jako o sprzymierzeńcu w nowej erze jakości oprogramowania. I pamiętaj, aby skupić się na jakości jako amunicji, sprzedając swój plan naprawczy: „Cóż, powiedziałeś nam, że chcesz naprawić wszystkie błędy. Mamy plan, aby to zrobić, ale będzie to wymagało spotkania z nami w połowie drogi . Oto, co proponujemy ... ”

Powodzenia!

Istnieją inne sposoby na zwiększenie produktywności przy usuwaniu błędów niż tylko dłuższa praca. Poprosiłbym Twój zespół o pomysły na ten temat i dałbym im czas na ich wdrożenie. Upodmiotowienie to długa droga w kierunku morale. Kilka pomysłów:

• Popraw testowanie i spraw, aby testy były uruchamiane przed każdym scaleniem.
• Refaktoryzacja problematycznego kodu.
• Określ priorytety błędów, tak aby ważne te z nich pracują jako pierwsze.
• Dowiedz się, który kod powoduje najwięcej błędów i poświęć czas, aby poprawić jego ogólną jakość.
• Użyj lintingu lub narzędzi do analizy statycznej.
• Napraw ostrzeżenia i włącz -Wall -Werror lub odpowiednik w Twoim języku.

Skoncentruj się na pracownikach. Upewnij się, że co tydzień organizujesz (najlepsze praktyki) jeden na jeden, aby porozmawiać o większych celach, wielkich pomysłach, rozwoju zawodowym. Oto świetne źródło z mieszanką płatnych i bezpłatnych ofert - darmowe rzeczy mają prawdziwą wartość: https://www.manager-tools.com/

W szczególności , poszukaj informacji na temat spotkań „jeden na jeden”.

Miałem sytuację, w której mój szef poinformował jednego z moich ludzi, że jego umowa nie zostanie przedłużona - za rok. Czy możesz sobie wyobrazić? Oto co zrobiłem. Skoncentrowałem się na pracy z facetem, aby poprawić jego CV. Co chcesz, aby zawierało CV? Zróbmy trochę z tej rzeczywistości. Gdzie chcesz stąd iść? Jak mogę ci pomóc się tam dostać? To działało bardzo dobrze, dopóki facet nie znalazł kolejnej okazji, w którym to momencie było prawie na torach. Ale to bardzo pomogło.

Indywidualne spotkania są kluczem do nawiązania kontaktu z ludźmi - jako ludźmi. Przy okazji, to nie są spotkania dotyczące projektu ani aktualizacji. To Ty jako menedżer wykonujący jeden aspekt przywództwa, jedna osoba na raz.

Jest takie stare powiedzenie, że ludzie zazwyczaj nie rezygnują z pracy - odchodzą z menedżerów.

Ponieważ twoi ludzie są „tylko” źle traktowani, a nie już zwolnieni, masz więcej opcji niż ja. Upewnij się, że Twoi ludzie wiedzą, że robisz wszystko, co w Twojej mocy dla ich dobra, czy to w tej pracy, czy w następnej.

Czy korzystasz z formalnego procesu? Domyślam się ze wskazówek kontekstowych i Twojego innego pytania, że ​​a) budujesz oprogramowanie ib) jesteś w Chinach. „a” jest istotne, „b” może nie być, ale pamiętaj, że pochodzę z perspektywy Stanów Zjednoczonych / Kanady i mogą istnieć zachowania kulturowe / wyuczone, które wpływają na wykonalność moich sugestii lub wymagają ich dostosowania. Sugestie te opierają się na ponad 20 latach profesjonalnego tworzenia oprogramowania i pracy w firmach, od małych start-upów po ogromne globalne przedsiębiorstwa i posiadających wszystko, od niezwykle wspierającego kierownictwa po despotów rządzących przez strach.

1. Jeśli jeszcze tego nie robisz, zacznij tworzyć programowanie sterowane testami lub podobne rozwiązanie zapewniające szybką informację zwrotną, aby natychmiast powiadomić Cię, jeśli nowe zatwierdzenia coś zepsują (zakładając, że krok 0 jest zakończony i używasz kontroli źródła - jeśli nie, zaimplementuj to natychmiast ). Testowanie musi być automatyczne i wykonywane przy każdym zatwierdzeniu.
2. Przyjmij proces przyjmowania, wykonywania i dostarczania nowej pracy. Scrum jest bardzo popularny. Kluczową kwestią jest tutaj niezwykle przejrzysty sposób szacowania i realizacji oraz zapewnianie ciągłej informacji zwrotnej o postępach. Trzymaj się wiernie tego, co możesz realistycznie dostarczyć: szybko, niedrogo, dobrze - wybierz 2. W ramach tego stwórz listę znanych błędów i pracuj nad ich redukcją.
3. Ustal priorytety, aby nie wprowadzać nowych błędów. Jeśli # 1 pokazuje coś zepsutego, napraw to, zanim wprowadzisz jeszcze więcej zmian. Jeśli będziesz ciągle dodawać nowe błędy, nigdy nie nadrobisz zaległości, a produktywność nigdy się nie poprawi. A ciągły cykl niekończących się błędów to pewny sposób na zmniejszenie produktywności i motywacji.
4. Śledź swoje postępy: czas dostarczenia, wskaźnik tworzenia błędów, liczbę zaległych błędów itp. Zademonstruj za pomocą danych, że gdy zespół jest pod presją, aby dostarczyć więcej, niż twierdzi, że może wygodnie dostarczyć, jakość produktu spada. Celebruj stopniowe usprawnienia i traktuj niepowodzenia jako okazję do uczenia się, a nie jako wymówkę do wymierzenia kary.
5. Pomóż członkom zespołu rozpoznać, że traktowanie pracownika przez kierownictwo nie jest odzwierciedleniem wartości tej osoby. To jest coś, co każda osoba w Twoim zespole musi zrozumieć. Pracują w toksycznym środowisku, co ma ogromny wpływ na twoje zdrowie psychiczne. Mogą nawet nie zdawać sobie sprawy, jak to na nich wpływa, dopóki ktoś nie zwróci na to uwagi.

Ostatni element jest prawdopodobnie najważniejszy, ale pierwsze cztery pomogą Ci tam dotrzeć. Nie można zmusić ludzi do „skupienia się”, przynajmniej nie skutecznie.

Obserwacja, którą dokonałem przez lata, jest taka, że ​​firmy prowadzone przez właścicieli, którzy konsekwentnie przeszkadzają profesjonalistom wykonującym pracę i starają się wyciskanie produktywności przez groźby kary również bywa najmniej skuteczne.

Odpowiadając konkretnie na to pytanie:

Czasami zauważam, że członkowie mojego zespołu nie pracują tak skoncentrowani, jak powinni, ponieważ wszyscy wiemy, że musimy znowu pracować po godzinach

Prawdopodobnie zdali sobie sprawę, że są w biurze nie tylko do czasu naprawienia kilku błędów, ale że tkwią tam na tyle godzin, ile wybrało kierownictwo, ilość pracy, którą wykonują, nie ma znaczenia.

Napraw to, wyznaczając cel na dzień, nad którym zespół może pracować: „3 więcej błędów i wszyscy możemy wrócić do domu. X, jeśli skończysz bug, czy możesz sparować się z Y, abyśmy wszyscy mogli szybciej wrócić do domu? ”

Ale tak naprawdę, jak powiedzieli wszyscy inni, Twoim zadaniem jest walczyć za swój zespół, a nie go wykorzystywać. Pełzanie funkcji powinno zostać cofnięte do następnej iteracji.

Złe warunki pracy odbiją się na Twoich pracownikach - nie ma znaczenia, kto jest za nich winny.

Najlepsze, co możesz zrobić, to przekonać kierownictwo, że Praca w nadgodzinach przynosi efekt przeciwny do zamierzonego, a tempo, w jakim od czasu do czasu wyciągają nadgodziny, zgodnie z tym, co jest prawdopodobne w umowach pracowników, może być niezgodne z prawem (zależne od jurysdykcji).

EDYCJA: Zgodnie z komentarz virolino, należy to zrobić ostrożnie . Nie możemy powiedzieć, które podejście najlepiej sprawdzi się w przypadku Twojego kierownictwa, ponieważ ich nie znamy. Jeśli nie możesz sobie na to odpowiedzieć, najlepiej omiń tę opcję.

Odpowiadając na Twoją pierwszą aktualizację:

Z drugiej strony, jeśli jest niedziela, ale pracujemy w biurze w godzinach nadliczbowych, ile czasu jest dopuszczalne na korzystanie z mediów społecznościowych?

W niedzielę? Powiedziałbym, że przynajmniej osiem godzin jest do zaakceptowania, chociaż mam nadzieję, że znudzą się wcześniej!

Na początek dlaczego nie sprawisz, że weekendowa praca będzie przyjemniejsza?

Wszyscy musicie przychodzić do biura w weekendy, kiedy wciąż są błędy do naprawienia, taka jest niefortunna rzeczywistość twojej sytuacji.

Ale już wiesz, że nikt nie będzie być w stanie naprawić wszelkie błędy w sobotę i niedzielę, ponieważ pracowałeś już od poniedziałku do piątku.

Więc zaakceptuj, że nikt i tak nic nie zrobi, na pewno możesz wymyślić coś lepszego niż przeglądanie mediów społecznościowych?

Możesz zacząć od grania w gry programistyczne, takie jak TIS-100 i Shenzhen I / O, i rywalizować ze sobą o wysokie wyniki.

Kiedy wszyscy są trochę zrelaksowani i dobrze się bawią, może pomyślisz o projekcie programistycznym, nad którym w dziesiątkę moglibyście razem pracować? Może niektórzy z Was mają już jakieś pomysły?

Jest weekend! Nie dostajesz zapłaty. Więc rób, co chcesz.

Następnie, może , jeśli masz na to ochotę, przez ostatnią godzinę każdej soboty i niedzieli możesz powiedzieć „OK chłopaki! Niech każdy z nas weźmie błąd i spędzi ostatnią godzinę dzisiejszego dnia na naprawianiu go!”

Pełen energii i zmotywowany zespół naprawi więcej w ciągu godziny niż zdemotywowany zespół będzie w jeden weekend.

Tytuł mojego drugiego pytania może być trochę mylący. Pełzanie funkcji jest jednym z głównych powodów, dla których musimy naprawić wiele błędów. Rozwijamy nowe funkcje w imię naprawy błędu!

Jak pracujesz? Wygląda na to, że masz nową listę funkcji, do której wciąż się dodajesz, nad którą pracujesz w ciągu tygodnia; oraz lista błędów, która również rośnie, nad czym pracujesz w weekendy.

Jeśli możesz naprawić listę błędów, nie będziesz już musiał przychodzić w weekendy (bez względu na to, jak bardzo chcesz po zaimplementowaniu ostatniego bitu ;-))

Przerwij pracować w sprintach. Zaplanuj każdy ze swoim zespołem. Nadaj priorytet naprawianiu błędów nad opracowywaniem nowych funkcji. Rób retrospektywy. Ogólnie rzecz biorąc, wszystkie dobre rzeczy z odpowiedzi Lawnmower Man.

Ale najpierw rozwiąż problem z morale, aby zespół mógł z powrotem przyspieszyć.

Myślę, że nikt do tej pory nie odniósł się do poniższego: ludzie koncentrują się na „nie” (co w pełni popieram) lub skupiają się na niektórych praktykach kodowania.

Jeśli nie możesz całkowicie znieść niepłatnych nadgodzin ( jak wynika z góry), co możesz zrobić?

• Czy możesz zapewnić elastyczne godziny pracy? „Chłopaki i dziewczęta, wiem, że potrzebujemy 80 godzin tygodniowo, ale w moim zespole możecie przychodzić i wychodzić, kiedy chcecie, wystarczy, że odliczacie te godziny, ponieważ nie mogę jeszcze tego zmienić”.
• Czy masz fundusze na rekompensatę? Pewne finansowe voodoo może być w twoim uścisku. „Wiem, że nadgodziny nie są w rzeczywistości opłacane przez firmę, ale każdy pracownik w moim zespole otrzymuje premię w wysokości 1 000 USD, jeśli usuniemy 100 błędów do końca roku”.
• Uzyskaj niepieniężną rekompensatę, a la Google zrobiło to, aby ludzie byli w biurze na dłużej. „Osoby pracujące w godzinach nadliczbowych dostają trzy posiłki serwowane za darmo, otrzymują wejściówkę na siłownię i mogą odwiedzać terapeuty za darmo w rzadko poza godzinami pracy”. Oczywiście przesadzam.
• Rzeczy, których nie wymyśliłem, ale wspieraj swój zespół na wszystkie możliwe sposoby. Kup im bardziej wyszukane komputery. Przenieś ich do lepszego biura. Poderżnij gardło menedżerowi wyższego szczebla i zlikwiduj niepłatne nadgodziny. Takie rzeczy.
• Jeśli wszystko zawiedzie: wyjdź z całym zespołem i znajdź nową pracę / uruchom start-up.

Jak mogę zarządzać swoimi członkami, aby utrzymać rozsądną produktywność, gdy mój pracodawca nie traktuje dobrze pracowników?

Ostatnia połowa pytania jest nieistotna. Jeśli pracownicy nie są produktywni, zdyscyplinuj ich, ponieważ inne podejścia nie zadziałały. Jeśli nie jesteś przygotowany na karcenie, to nie spełniasz swojej roli.

Spróbuj zgadnąć, kto jest najgorszy i najpierw go zdyscyplinuj.

Możesz Muszę to powtórzyć kilka razy. W międzyczasie zobacz, co możesz zrobić z szefem, jeśli chodzi o ustępstwa dla morale personelu, powtarzaj to również. Nie osłabiaj swojego szefa wobec pracowników, ale zrób wszystko, co w twojej mocy dla nich i dla swoich obowiązków.