Pytanie:
Jak mogę promować kulturę punktualności w firmie programistycznej?
Jacob G
2012-04-12 22:34:49 UTC
view on stackexchange narkive permalink

Jakie są dodatkowe strategie, które warto zastosować jako nowy kierownik techniczny w nowej firmie, aby zmienić kulturę zespołu programistów, aby ludzie pojawiali się w żądanym przeze mnie czasie?

TLDR : mój zespół nie pojawia się na czas. Próbowałem ich zmusić, ale to nie działa.

Dane ogólne:

  1. Mała firma, 30 pracowników, 5 członków mojego zespołu.
  2. Poprzedni trop nadal dotyczy personelu jako zwykłego programisty.
  3. Kultura przed moim przybyciem była nieformalna, bez ustalonych granic i godzin pracy. Ta kultura nie została zakwestionowana przez liderów korporacji. Z tego powodu większość osób w zespole pojawiłaby się między 10:30 a 11:00.
  4. Inne działy, ze względu na charakter swojej pracy, wyznaczyły czas rozpoczęcia na 8 lub 9.

Ta rozbieżność i nieprzewidywalność powodują wiele niepokoju między moimi dział i inne działy. W związku z tym posadziłem zespół i określiłem „nie później niż” godzinę 9:30. Wyjaśniłem swoje rozumowanie i wyjaśniłem zalety takiego programu oraz wady obecnego programu. To była długa i kontrowersyjna rozmowa, a 3 z 5 osób w zespole było bardzo niezadowolonych.

Nie trzeba dodawać, że ludzie nie pojawiają się na czas (a 9:35 nie jest na czas).

Zaplanowałem nasze codzienne spotkanie standupowe o 9:30 jako dodatkową motywację. Wiedząc, że zmiana godzin rozpoczęcia zabiera trochę czasu (z dojazdem do pracy itp.), Początkowo czekałem z rozpoczęciem spotkania, aż wszyscy się pojawią, ale teraz po prostu zaczynam spotkanie (i często je kończę) ktokolwiek jest obecny. Wydaje się, że to również nie robi różnicy, a to sprawia, że ​​zespół jest mniej spójny.

Rozmowy indywidualne i grupowe dają takie same wyniki, jak oryginalna rozmowa (tj. Nie widzą wartości, myślą Odbieram korzyść z pracy itp.)

Mam pełne wsparcie i wsparcie kadry kierowniczej wyższego szczebla i jestem upoważniony do korzystania z wszelkich urządzeń, które uznam za stosowne, aby się tym zająć.

Mój obecny następny krok to wysłanie kogoś do domu i biorą dzień wolny. Czy to zbyt drastyczne? Czy istnieją alternatywne strategie, których pomijam, które pomogłyby mi rozwiązać ten problem?

Edytuj w oparciu o pytania w odpowiedzi Jarroda

Co nowego z technicznym kierownikiem? silny> 6 miesięcy, w tej firmie, w momencie tego pytania.

Dlaczego narzucacie czysto nietechniczne zasady zarządzania? Jest to objęte zakresem mojego stanowiska określonego przez kierownictwo.

Jakie są Twoje kwalifikacje kierownicze? 10 lat doświadczenia jako kierownik techniczny. Brak formalnego wykształcenia lub certyfikacji z zakresu zarządzania.

Jakie masz doświadczenie w zarządzaniu personelem? Od 10 lat jestem kierownikiem technicznym. Byłem odpowiedzialny za zatrudnianie / zwalnianie / przeprowadzanie rozmów kwalifikacyjnych / recenzowanie / kierowanie / budowanie kilku różnych zespołów technicznych.

Czy zdobyłeś szacunek zespołu pod względem technicznym? Tak

Czy zdobyłeś szacunek zespołu jako menedżer? Udzielono mi wywiadu dotyczącego umiejętności technicznych i menedżerskich zespołu. Mówiłem jasno i otwarcie o tym, jak lubię kierować zespołami technicznymi i jak lubię prowadzić projekty (z oczywistym zastrzeżeniem, że jest to tylko punkt wyjścia, a kultura i personel ostatecznie wpływają na to, gdzie wyląduję). perspektywa menedżerska, z której zespół jest całkiem zadowolony.

Czy poprzedni kierownik techniczny ustąpił? Tak.

Czy poprzedni kierownik techniczny został zdegradowany? Nie. To była jego prośba.

Czy poprzednie wskazówki techniczne były skuteczne? Przez jakiś czas. Jednak rozwój firmy i podstawy kodu sprawiły, że jego styl był nieskuteczny.

Czy większość obecnego zespołu ma bardziej osobiste relacje z poprzednim kierownikiem technicznym? Tak.

Czy poprzedni kierownik techniczny nadal skutecznie rządzi? Nie.

Zatem [poprzednia kultura nieformalności bez ustalonych granic] musi mieć pracował? To działało przez pewien czas, kiedy firma była jeszcze startupem. Rozrosła się i ewoluowała znacznie poza fazę rozruchu, a dzięki temu wzrostowi nie jest już tak skuteczna jak kiedyś. Zwłaszcza, że ​​inne działy wprowadziły nieco więcej formalności i przewidywalności.

Czy zespołowi udało się dostarczyć przydatne produkty zgodnie z obietnicą? Na początku. Jednak wraz z rozwojem firmy i produktu jakość i czas dostaw znacznie się pogorszyły.

Wygląda na to, że nawet nie rozważałeś lub nie badałeś jakiegoś kompromisu ze swoim zespołem lub zespołami zewnętrznymi na podstawie ich negatywnych informacji zwrotnych. Zrobiłeś to? Oczywiście, nie jestem debiutantem. Faktem jest, szanuję fakt, że reszta firmy pracuje w sztywnym boksie ze względu na charakter swoich obowiązków. Zespół nie chciał iść na kompromis w kwestii elastycznego czasu pracy, aw wielu przypadkach inne działy nie są w stanie tego zrobić. Odniosłem się również do negatywnych opinii, szczególnie w innych działach, i wdrożyłem szereg rzeczy, aby poprawić sytuację. Jedną z największych zalet tej zmiany była poprawa przewidywalności i zmiana postrzegania.

Ostatnia aktualizacja

Z pierwotnej 5-osobowej załogi zastąpiono 2 osoby. Pierwszym był poprzedni lider zespołu. Nie mogliśmy się porozumieć, jak prowadzić projekty rozwojowe, a on nie mógł zaakceptować zmian w tym, co wcześniej ustalił, więc wspólnie zgodziliśmy się rozstać. Drugi stracił zainteresowanie pracą, popełnił kilka dużych błędów i wspólnie zgodziliśmy się rozstać.

Zespół jako całość pojawia się teraz wystarczająco wcześnie, aby zapewnić wystarczającą ilość informacji dla reszty firmy. Ostatecznie zadziałał mandat i presja rówieśników. Ponadto inne wprowadzone zmiany doprowadziły do ​​rozwiązania prawie całego międzywydziałowego niepokoju. Każdy nadal może pracować nad niesamowitymi projektami, głównie według własnego wyboru, we własnym tempie w ekscytującej firmie i wszyscy są całkiem zadowoleni, mimo że rynek pracy jest śmieszny w okolicy.

Otrzymałem awans na stanowisko kierownicze i nowy „zespół problemowy” został przeniesiony pod mnie (oprócz tego, że nadal zachowuję kontrolę nad zespołem programistów i wciąż się rozwijam). Teraz pracuję, aby pomóc im lepiej działać i być lepszymi kolegami z zespołu dla swoich kolegów. Nie mam problemu z punktualnością w tym nowym zespole ... Ich problemy to dokładność i komunikacja.

Może inny rodzaj motywatora, na przykład pączek * tylko * dla tych, którzy pojawiają się na czas lub wcześnie. Codziennie może to być kosztowne, więc może rób to tylko raz w tygodniu, ale nie mów im * który * dzień ...;) Nigdy tego nie próbowałem, dlatego raczej piszę jako komentarz niż odpowiedź.
W tym pytaniu brakuje jednej ważnej rzeczy: *** DLACZEGO *** dokonujesz tej zmiany? Czy praca nie jest wykonywana w odpowiednim czasie? Czy istnieje rzeczywisty problem, który wymaga rozwiązania (i czy jest to właściwy sposób na jego rozwiązanie? Może być tematem na inne pytanie ...) Jak zauważył Andrew w swojej odpowiedzi, dyktując arbitralny czas rozpoczęcia wiedzy „nie po” pracownicy, którzy mają już kulturę elastycznego czasu pracy, będą niepopularni i ciężko jest zaproponować motywatorów / metodologię bez szerszego kontekstu ...
@voretaq7: Myślę, że „Ta rozbieżność i nieprzewidywalność powoduje wiele niepokoju między moim działem a innymi działami” oznacza, że ​​inne działy muszą być w kontakcie z działem OP. a kiedy jedna grupa przychodzi o 9 rano i zależy od innych, którzy nie pojawią się przed 11:00, powoduje to problemy.
@FrustratedWithFormsDesigner Całkiem możliwe, ale jeśli programista położy pracę na biurku projektanta o 20:00, aby przetestować ją jutro rano między 9 a 11, nie widzę problemu. Wolę koordynację od arbitralnych reguł. Staram się też nie robić z góry założeń, ale „niepokój” może równie łatwo brzmieć: „Sprzedawcy płaczą, ponieważ chcą przyjść późno, a jeśli nie, nikt nie może!”.
Czy chcesz wyegzekwować drugą stronę zasady „szkolnego dzwonka”? Każdy przerywa to, co robi i odchodzi w pewnym momencie, niezależnie od tego, ile pracy może jeszcze zostać cofnięte?
@JimInTexas to bardziej zasada „Core Hours”. Musisz być w biurze między 9:30 a 4:00 ... możesz huśtać się wcześniej lub później, jak chcesz.
@voretaq7, w świecie korporacji menedżer musi działać, gdy narzekają inne działy. Pracownicy tych działów nie widzą, dlaczego muszą być tam o ustalonych godzinach, a programiści nie. Jestem pewien, że polecono mu rozwiązać problem.
@HLGEM Zależy to jednak od charakteru skargi: Czasami właściwym działaniem jako menedżera jest powiedzenie innym działom „Tak działa mój zespół i to działa w firmie. Tough Rocks”. - W przypadku Jacoba, chociaż jego twórcy wydają się być zepsutymi primadonami z problemami z nastawieniem [zobacz tę dyskusję na czacie] (http://chat.stackexchange.com/transcript/message/4208458#4208458) i niektóre z poniższych komentarzy. ..
@JacobG: Czyli ludzie z innych działów * potrzebują * regularnie spotykać się twarzą w twarz z programistami w Twoim zespole, tak bardzo, że fakt, że programiści przychodzą do pracy o 11 rano, poważnie temu przeszkadza? Dlaczego potrzeba tak wielu bezpośrednich interakcji między działami? *Czy to konieczne? Czy udział w tych spotkaniach naprawdę dobrze wykorzystuje czas twoich programistów, czy może koordynacja może odbywać się na wyższym poziomie (powiedzmy, między * tobą * a innymi działami)? Nie wątpię w twój opis sytuacji, ale wydaje się to dziwne.
@KeithThompson: Interakcja między działami jest częsta i często wynika z potrzeby współpracy. Jesteśmy małą firmą i małym zespołem deweloperskim i musimy nosić wiele czapek w SDLC, wspierać nasze środowiska produkcyjne i pomagać innym działom również w realizacji ich produktów. Wielu z nas w firmie ma do dostarczenia pilne czasowo rzeczy i zwykle nie ma wystarczająco dużo czasu, aby spędzić dni na koordynowaniu. Staram się przeszkadzać najlepiej, jak potrafię, ale nie mogę wziąć tego na siebie i potrzebuję, aby reszta zespołu była dostępna.
* Nie trzeba dodawać, że ludzie nie pojawiają się na czas (a 9:35 nie jest na czas). * To brzmi dyktatorsko, mikro-zarządzanie i tyrańskie. Wygląda na to, że potrzebujesz stworów; szukaj tych typów osobowości, gdy obecna załoga odchodzi.
W momencie, w którym powiesz: (a 9:35 nie jest na czas.), Natychmiast daj mi wrażenie, że jesteś surowym szefem i rzadziej słucham tego, co mówisz. Programiści prawie wszędzie mają zawsze elastyczność godzin pracy i przez większość czasu ludzie popadają w rutynę, jest mało prawdopodobne, że są nieprzewidywalni, kiedy przyjdą. Ludzie robią to głównie ze względu na to, co jest dla nich najlepsze, co z kolei sprawia, że ​​są bardziej produktywni.
@JarrodRoberson i tsoverflow - Oczywiście jesteście mile widziani w waszych opiniach, ale myślę, że wasze hiperbole są trochę poza granicami. Nie jestem ani „tyrani”, ani „douchy”, ale oczekuję, że ludzie pojawią się na zebraniach na czas i będą gotowi do udziału.
Wciąż wygląda na to, że problem dotyczy * ciebie *, a nie reszty zespołu. Masz tu dyktatorski ton, mogę sobie tylko wyobrazić, jak trafiasz do ludzi, których masz * przewodzić *. Mam wrażenie, że to twój pierwszy lub drugi raz na tym stanowisku i myślisz, że powinni po prostu robić to, co mówisz, ponieważ to ty rządzisz. Istnieje kultura na dobre i na złe; trzeba się do niego dostosować i zmienić przykładowo od środka. Przyjechałeś tu z prośbą o pomoc, ale nie chcesz słuchać niczyich opinii. To naprawdę powinno być * Jak mogę nagiąć moich pracowników do mojej woli? *
śniadanie składające się z bajgli, pączków, kawy itp. zapakuj wszystko o 9:30
Nie wiem, co wszyscy myślicie, ale kłótnie trwające ponad pięć minut nie są tak naprawdę skutecznym ani produktywnym sposobem spędzania czasu z zespołem.
@Spoike - To może być tylko 5 minut, ale wciąż są spóźnieni. Jeśli nie mogą nawet pojawić się w TIME 9/10 razy, jak autor może im zaufać?
@Ramhound: Za każdym razem, gdy ktoś spóźnia się na spotkanie, szczerze ** nie obchodzi mnie to **. W końcu rozmawiam z ludźmi, którzy przychodzą na czas (omawiając dzień, życie, cokolwiek ... no wiesz ... poznajemy ich lepiej), a potem zabieram się do prawdziwego biznesu, kiedy wszyscy przybędą. Zaufanie to coś, co zarabiasz poprzez interakcje z innymi ludźmi. Karanie (choć wygląda dobrze w hollywoodzkich hitach filmowych) nie polega na tym, jak budujesz z nimi zaufanie.
@Spoike Powiedziałbym, że zwykłe spóźnianie się * na spotkania * zdradza brak szacunku dla czasu innych, którym należy się zająć. Firma nie powinna płacić pięciu osobom za siedzenie i kręcenie kciukami i prowadzenie pogawędek czekających na przybycie wszystkich Istnieje * trochę * pogawędek itp., Ale kultura, w której biznes spotkania zaczyna się dopiero po kilku minuty po zaplanowanym czasie rozpoczęcia wskazują, że czas nie jest ceniony i szanowany.
@tsOverflow: Jeśli spotkanie w trybie stand-up jest punktualnie o 9:30, po prostu musisz zaplanować przybycie na 9h25 i możesz sobie pozwolić na spóźnienie o 5 minut w przypadku problemu.
@MatthieuM .: OP zdecydował, że wszyscy przyjdą najpierw o 9:30, a potem celowo zaplanował spotkanie na 9:30, aby zmusić wszystkich do przyjścia wcześniej. Istnieje różnica między zaplanowaniem spotkania wcześniej celowo w ten sposób a faktycznym odbyciem spotkania w tym czasie bez podstawowego zamiaru nakłaniania ludzi do przyjścia w określonym czasie.
@JohnMcG: Wejście jako nowy menadżer, aby zakłócić sprawę, nie pozwalając nikomu mieć na to mandatu, to wielka sprawa, znak, że nie słuchasz i oznaka braku szacunku. Takie zmiany wymagają czasu, a nawet lat. Spróbuj zacząć szanować innych, zanim * zażądasz * szacunku. Z edycji: jego zespół nie chce rezygnować z elastycznego czasu pracy, który, jak sądzę, jest nim zainteresowany i prawdopodobnie zapisał się do tego rodzaju pracy. Bez względu na powód, Twoim zadaniem jako menedżera jest radzenie sobie z tym i zarządzanie oczekiwaniami ... lub zwolnienie zespołu ... ale to jest złe rozwiązanie.
@JacobG: Z dyskusji na czacie połączonej z voretaq7 wynika, że ​​Twoją sytuację można podsumować następująco: „Muszę kierować działem zepsutych primadonn, które nie wykonują pracy prawidłowo, mają złe relacje z innymi działami i spóźniają się” - w takiej sytuacji „spóźnij się” to * najmniejszy z twoich problemów *. Możesz jednak wykorzystać to na swoją korzyść - jeśli zgodzisz się z kierownictwem wyższego szczebla, że ​​punktualność można złagodzić w zamian za ulepszenia w innych obszarach, * i * przedstawisz to jako rekompensatę dla swojego zespołu, * możesz * uzyskać ulepszenia dookoła.
@Spoike - Wygląda na to, że praca z Tobą byłaby bardzo trudna. Wydaje się, że nie myślisz, że „spóźnianie się” w oczach przełożonego jest problemem. Szczerze mówiąc, nie ma znaczenia, jaka była polityka starego przełożonego. Jeśli nie spodobają im się wspomniane zmiany, mogą odejść, a nowy przełożony może je zastąpić osobami, które BĘDĄ na czas.
@Ramhound: Teraz robisz założenia, których nie ma i są bardzo nieprzydatne. Zwykle przychodzę na spotkania na czas, a nawet wolę być kilka minut wcześniej i zwykle łatwo się z nimi pracuje, przynajmniej tak mówią moi koledzy na moim profilu LinkedIn. :-) Mówię tylko, że nawet jeśli ktoś spóźni się na spotkanie, to nie chcę poświęcać całej swojej energii poznawczej na kłótnie o to, są o wiele pilniejsze sprawy do załatwienia.
Nadal zastanawiam się, dlaczego utrata godziny lub dwóch okien rano jest tak katastrofalna dla koordynacji z innymi działami. Jeśli twoi programiści spędzają więcej niż godzinę dziennie na robieniu tego rodzaju rzeczy, jest to dla mnie wskaźnik poważnego zarządzania (niekoniecznie OP) lub problemu kulturowego. Jeśli deweloperzy są primadonami, to możliwe, że wszyscy są szarpnięciami. Możliwe jest również, że ktoś ma ich na wielu godzinach spotkań dziennie, aby stale otrzymywać informacje o postępach w pracy, której nie mogą wykonać, aż do godziny 17:00, kiedy wszyscy inni odchodzą. Byłem tam / widziałem to kolosalne marnowanie pensji programistów.
* Mam pełne wsparcie i wsparcie kadry kierowniczej wyższego szczebla i jestem upoważniony do korzystania z wszelkich urządzeń, które uznam za stosowne, aby się tym zająć. * - Myślisz, że pomoże Ci to narzucić kulturę punktualności? Powodzenia, stary.
@JimG. Była to jedynie potencjalnie istotna informacja, której ktoś mógł użyć do sformułowania produktywnego rozwiązania „zachęcania”, a nie „narzucania” kultury punktualności. Zapraszam do udziału w społeczności i oferowania własnego produktywnego rozwiązania.
Pytanie jest oksymoronem ...
Intensywność dnia pracy programisty jest nieporównywalna z pracownikami innego działu, dlatego nie można ich traktować równorzędnie. Na przykład, jeśli Twoja praca polega na sprawdzeniu kilku CV lub wykonaniu telefonu, oczywiście musisz być tam od 9:00 do 17:00. Mam na myśli, że są prace, w których nie masz trudnych zadań, ale twoja obecność jest potrzebna przez cały dzień, a są inne, w których masz termin i ilość pracy do wykonania wcześniej, niezależnie od tego, kiedy przychodzisz ranek.
* „Zaplanowałem nasze codzienne spotkanie standupowe na 9:30 jako dodatkowy czynnik motywujący…” * - nazywasz to * „motywacją” *? O MÓJ BOŻE..
Czy jest jakiś powód, dla którego musisz podkreślać, że to ty decydujesz o wszystkim w swoim zespole?
OP brzmi jak dyktator. „Dlaczego narzucasz czysto nietechniczne zasady zarządzania? Jest to zakres mojego stanowiska zdefiniowanego przez kierownictwo”. Dużo podróżujesz?
„Zatrudniliśmy wiele osób tanio w zamian za super elastyczne godziny pracy. Teraz, gdy połknęli przynętę, którą chcielibyśmy zmienić.” Jeśli chcesz „punktualności”, umieść (podstawowe) godziny pracy w umowie.
Jestem nowy na tej stronie i chciałbym zostawić tutaj tę notatkę: jako programista chciałbym wiedzieć, dla jakiej firmy pracował OP w momencie, gdy zadał to pytanie, więc nigdy nie wysyłam im mojego CV.
Czytając pytanie, komentarze i czat, nie jest dla mnie jasne, gdzie dokładnie jest motywacja do tego „usunięcia korzyści” pomiędzy „potrzebujemy koordynacji między działami” a „inne działy są zazdrosne o nasze korzyści”. Prawdopodobnie jest to oczywiste, ale jeśli twoi programiści uważają, że pierwszy powód jest tylko fasadą drugiego, reakcja, którą otrzymujesz, jest całkowicie przewidywalna: skoro już to robisz, dlaczego nie obniżyć ich pensji, aby dostosować się do innych działów? Jeśli naprawdę jest to problem „koordynacji”, czy jest to problem każdego dnia? Jeśli nie, musi istnieć inne możliwe rozwiązanie
Zastanawiałem się, dlaczego w innych działach panuje „niepokój”. Czy mógłbyś to rozwinąć?
@ThorbjørnRavnAndersen Prawdopodobnie grali w Bright Eyes w swoim dziale.
Jeśli * oni […] myślą, że odbieram korzyść z pracy *, to dlatego, że jesteś. Może być też uzasadnione, konieczne, nierozsądne, dyktatorskie, ale jest tym, czym jest.
Więc powodem wczesnego startu jest to, że inne działy są zazdrosne? Być może trzeba przyjrzeć się, dlaczego 9-5 stał się w pierwszej kolejności standardem i wieloma powodami, dla których nie dotyczy już większości programistów w dobie telepracy ...
Siedemnaście odpowiedzi:
#1
+155
Nicole
2012-04-13 00:42:13 UTC
view on stackexchange narkive permalink

Najlepszym czynnikiem motywującym jest zaufanie. Jedność zespołu jest najważniejsza w osiąganiu twoich celów. Kultury rządzące rodzą się z nieufności, a kije i bodźce do egzekwowania reguł tylko jeszcze bardziej osłabi zaufanie twojego zespołu.

Zamiast martwić się dokładnymi czasami i nieformalnymi kulturami, spróbuj dowiedzieć się, jakie są nieodłączne wartości.

  • Czy 9:30 (lub jakakolwiek inna godzina) naprawdę ma znaczenie? A może Twój zespół musi się upewnić, że swoją nieobecność nie utrudnia pracy innym zespołom?

  • Czy 5 minut ma znaczenie ? Czy też czy najważniejsze jest, aby wszyscy członkowie przyłączyli się do codziennej walki?

  • Czy nieformalność jest problemem? Czy też czy elastyczność to korzyść?

Zagłębiłbym się w sedno problemu, którym jest to, że Twój zespół nie zaakceptował tego pomysłu . Zobacz, gdzie jest rozłączenie, ale unikaj tworzenia kultury reguł . Odesłanie ich do domu za spóźnienie (taktyka dyscyplinarna, którą można znaleźć w szkole podstawowej) sprawi, że Twój zespół uwierzy, że postrzegasz je jako dzieci, którym nie można ufać.

+1 - myślę, że jest to najbardziej zwięzły sposób sformułowania problemu * i * rozwiązań. Jakiekolwiek zasady, które ustalasz, muszą ułatwiać załatwianie spraw, i tak należy podchodzić do pracowników.
Podoba mi się ta odpowiedź i zgadzam się z nią. Wydaje mi się, że próbowałem przekonać ich, aby zrozumieli podstawowe problemy i w jaki sposób można by im pomóc dzięki polityce dotyczącej godzin pracy podstawowej. Jeden programista odpowiedział z wyższością (tj. Pieprzyć inne działy, b / c jestem wyjątkowy), a inni skupili się wyłącznie na utracie profitu. Nie wierzę, że postrzegają siebie jako część większego zespołu, a raczej jako supergwiazdę większego zespołu. Nie chcę ich „wysyłać do domu”, dlatego poprosiłem o alternatywną taktykę, ponieważ nie wiem, co innego robić.
@JacobG Wiesz, drugi programista _nie_ ma rację - możliwość przyjścia między 10:30 a 11:00 ** to ** korzyść, nawet jeśli nie akceptujesz ich używania (jak np. , zrywa się dym). Nie powinieneś go usuwać bez zaoferowania jakiejś formy rekompensaty.
+1 absolutnie się zgadzam. Dodałbym, że być może problem można złagodzić, rozważając posiadanie „zasięgu” w godzinach pracy, zamiast posiadania _ wszystkich_ na miejscu w godzinach pracy. Czy niektórzy deweloperzy mogą zgłosić się na ochotnika, aby pojawić się wcześniej, a inni zostać później?
Zgadzam się z czynnikiem motywacyjnym, ale nie zgadzam się, że kultura zasad jest zła.
kiedy ludzie mają złe nawyki, nagradzanie / wynagradzanie ich za rezygnację z nich nie jest wspaniałe. Wolałbym raczej nagradzać i rekompensować wyniki.
Kilka dobrych punktów, ale nie zgadzam się z twoim założeniem. Zaufanie, a nie nieufność, umożliwia kulturę reguł. Problem OP polega na tym, że jego raporty nie ufają mu na tyle, by robić to, o co ich prosi. Mogą mieć rację, jeśli tego nie robią. Więc raczej ** Najlepszym czynnikiem motywującym jest własny interes. **
To nie jest problem z * zaufaniem *, to jest problem z * szacunkiem * i czyimś bezpośrednim przełożonym, który wspiera ich opinię, szanując go i upewniając się, że jego głos jest słyszany. Przeczytaj komentarze do mojej odpowiedzi, nie ma przekonania, że ​​zespół deweloperski powinien mieć głos w tej sprawie, jest to podejście dyktatorskie, a nie wyspiarskie podejście do zarządzania.
Dla kierownika zespołu lub menedżera liniowego pracującego z mądrymi, kreatywnymi ludźmi najważniejszą umiejętnością jest słuchanie. Dopóki zespół jest produktywny i skuteczny, nie wchodź mu w drogę. W tym przypadku presja jest spoza zespołu - widzę swoją rolę jako * ochronę * zespołu przed tego rodzaju „organizacyjnym deszczem” i dlatego staram się walczyć o niego z kierownictwem, a nie na odwrót. Jeśli zespół jest wydajny i produktywny, nie zadzieraj z nim. Jeśli mierzenie czasu narusza spójność zespołu, upewnij się, że jest to poruszone w twoich retrospektywach jako problem do rozwiązania przez zespół.
+1 za skupienie się na głównym problemie i unikanie tworzenia kultury zasad. Kwestia elastyczności jako korzyści jest również dobra.
#2
+124
jmort253
2012-04-13 11:26:15 UTC
view on stackexchange narkive permalink

Stworzenie kultury punktualności może zająć trochę czasu i może być czymś, na co trzeba pójść na jakiś kompromis. Ponieważ masz do czynienia z inteligentnymi pracownikami wiedzy, odniesiesz większy sukces, jeśli uda ci się ich przekonać, aby weszli do planu. Zamiast skupiać się na czasie, skup się na problemie spowodowanym problemami z harmonogramem.

Przedstaw problem jako wyzwanie dla zespołu i zobacz, co wymyślą. Odpowiedzią mogą być harmonogramy lub coś innego, co rozwiązuje problem. Może to być poniedziałek, środa, piątek to 9:00 rano, a wtorek i czwartek to dni elastyczne. Chociaż plan może nie być doskonały, ani nie będzie dokładnie taki, jak sobie wyobrażałeś, znalezienie czegoś pośredniego, które uszczęśliwi zarówno zespół programistów, jak i rozwiązanie rzeczywistego problemu, zapobiegnie zgorzknieniu twojemu personelowi i postrzeganiu cię jako wroga .

Pamiętaj, że nie masz do czynienia z procesem produkcyjnym, w którym każdy musi pojawić się dokładnie o 9:30, kiedy rozlegnie się gwizdek, aby mogli rozpocząć odrętwiałe zadanie złożenia tego samego kilka plastikowych widżetów, aż znowu słychać gwizdek, a oszołomiony personel udaje się do lokalnego baru na happy hour.

Mój zespół nie pojawia się na czas. Próbowałem ich zmusić i to nie działa.

Zmuszanie inteligentnych ludzi nigdy nie działa. Musisz pamiętać, że masz do czynienia z dobrze wykształconymi, inteligentnymi, kreatywnymi ludźmi, którzy są dobrzy w rozwiązywaniu złożonych, abstrakcyjnych i unikalnych problemów. Ci ludzie, przynajmniej ci naprawdę dobrzy, nigdy nie będą ślepo wykonywać rozkazów. Wracamy do oddania problemu w ich ręce, przynajmniej na początku. Jeśli nic nie zrobią, będziesz chciał zastosować własne rozwiązanie.

Wspomniałeś, że jesteś nowym kierownikiem zespołu. Wejście na nową pozycję, taką jak ta, jest trudne i stresujące, ponieważ nie jesteś pewien, jak zdobyć szacunek zespołu, a także być dobrym liderem. Wiąże się to z doświadczeniem i często niedoświadczony nowy zespół prowadzi do prób „zmuszenia” lub zmuszenia ludzi do robienia rzeczy po swojemu. To nie jest przywództwo.

Programiści i inni pracownicy umysłowi nie potrzebują menedżera; zamiast tego potrzebują lidera. Świetni liderzy inspirują innych do robienia wielkich rzeczy, a to Twoja szansa, aby poprowadzić swój zespół do wielkości, zamiast narzucać mu rozpacz.

Badania pokazują, że ludzie są bardziej skłonni do zaangażowania się, gdy uczestniczą w ustalaniu, co rozwiązaniem będzie raczej, niż przekazanie im tego rozwiązania, a jest to szczególnie prawdą w przypadku pracowników umysłowych.

Aby uzyskać inspirację, zobacz artykuł Setha Godina Wywiad na temat różnicy między przywództwem a zarządzaniem. Gorąco polecam wszystkim przywódcom obejrzenie tego krótkiego wywiadu.

„Pozwól im wymyślić plan” była moją pierwszą reakcją. Jednak sądząc po komentarzach i czacie, wydaje się, że to nie zadziała w tym konkretnym przypadku ...
@Benjol - Ton pytania sprawia, że ​​myślę, że jest w tym coś więcej niż na pierwszy rzut oka. Wydaje się też, że zarządzanie stylem Teoria X, które nie jest skuteczne w zarządzaniu programistami. Słyszymy tylko jedną stronę tej historii, a prawda jest zawsze gdzieś pośrodku.
Zobacz moją odpowiedź :)
Najważniejsze jest to: „Zmuszanie mądrych ludzi nigdy nie działa”. Nie możesz traktować swoich wysoce inteligentnych członków zespołu jak dzieci i oczekiwać, że nie będą narzekać, walczyć i urażać Cię za to (przykład; nie ma to na mnie bezpośredniego wpływu, ale nadal trudno mi tego nie robić) obrażać się na sposób, w jaki PO próbuje zarządzać swoim zespołem). Pracownicy techniczni są na ogół tak mądrzy, jak ich menedżerowie (jeśli nie bardziej), więc jedynym skutecznym sposobem podejścia do nich jest kontakt z rówieśnikami, a nie jako bezmyślni podwładni, którzy powinni robić to, co mówisz, ponieważ to powiedziałeś.
Jestem słabo wykształcony i nadal sprzeciwiam się temu, by ludzie zabierali mi mój elastyczny czas.
#3
+64
Andrew
2012-04-12 23:19:20 UTC
view on stackexchange narkive permalink

Z mojego doświadczenia wynika, że ​​pracownicy umysłowi nie lubią, gdy im narzuca się zasady, dla których nie widzą żadnego celu. Podajesz cel, ale pracownicy, którymi zarządzasz, wydają się uważać, że nie jest to dobry. Co więcej, prawdopodobnie istnieją alternatywy, których nie wziąłeś pod uwagę, a biorąc pod uwagę coś, co brzmi jak kwestia „dyktowana z góry”, Twoi pracownicy mogą albo o nich nie myśleć, nie czuć się komfortowo, proponując je lub czuć, że zestrzelony.

Jeśli jedynym powodem, dla którego wdrażasz tę politykę, są napięcia z ludźmi z innych działów, Twoim zadaniem jest radzenie sobie z tym napięciem, aby pracownicy mogli pracować najbardziej efektywnie. Nie sądzę jednak, że to jedyny powód. Na przykład, co zrobić, jeśli programista jest potrzebny do naprawienia pilnego problemu produkcyjnego, który ma miejsce o 8:00 lub 9:00 lub o dowolnej innej godzinie? Jednak jest mało prawdopodobne, aby wszyscy obecni byli obecni programiści, aby naprawić ten problem. A co by było, gdybyś miał rotacyjny (chyba że ktoś zgłosi się na ochotnika) „wczesny” harmonogram, tak aby każdy programista musiał być tam o godzinie 8:00 (lub 9:00 itd.)? Wydaje się, że takie rozwiązanie z większym prawdopodobieństwem zaspokoi zarówno potrzeby biznesowe, jak i pragnienia Twoich pracowników. Każdy „dzieli ból” (lub zadaje go komuś, komu to nie przeszkadza). Ludzie mogą przychodzić i pracować przez większość czasu, kiedy czują, że byliby najbardziej produktywni. To tylko jedna możliwość, ale może wywołać dyskusję z pracownikami o tym, jak rozwiązać rzeczywiste problemy i zaspokoić wszystkie zainteresowania.

Jeśli zdecydujesz się pójść bardziej dyscyplinarną ścieżką, a kwestia „czasu rozpoczęcia” jest naprawdę ważna dla twoich programistów, stracisz swoich dobrych na rzecz innego zatrudnienia. Twoi pracownicy mogą czuć się niepewnie w swojej pracy (a co, jeśli pewnego dnia rzeczywiście wydarzy się jakiś prawdziwy kryzys, który sprawi, że ktoś się spóźni?). Co więcej, można to postrzegać jako zmianę w zarządzaniu w złym kierunku (z punktu widzenia pracowników), ponieważ wcześniej mieli oni doświadczenie w pracy pod kimś innym.

To oczywiście zależy od Ciebie, ale Zachęcam Cię do cofnięcia się o krok i do większego wysiłku, aby spojrzeć na sytuację z perspektywy pracowników. Masz oczywiście zadanie do wykonania, ale myślę, że istnieją rozwiązania, które lepiej zaspokajają interesy wszystkich niż to, które proponujesz.

Nie zamierzam karać kogoś, jeśli ma uzasadniony powód spóźnienia. Zasypianie trzy razy w tygodniu, ponieważ grają w WoW całą noc, nie jest legalne. Mamy osobę, która wcześnie przychodzi o 7:30. Duży problem polega na tym, że jeśli Dev X pracuje nad projektem z Projektantem Y, a Projektant Y jest o 8, czeka do 13:00 lub później, aby dostać coś, czego może potrzebować. Na wezwanie deweloperzy nie widzą z tym problemu. Jesteśmy małą firmą i wszyscy powinniśmy należeć do tego samego zespołu. Poważnie, 9:30 to niezbyt wcześnie. Czy naprawdę jestem nierozsądny?
@JacobG Nie potrafię powiedzieć, czy bez dodatkowych informacji jesteś nierozsądny, jednak kluczem do elastycznego czasu jest to, że praca *** musi *** być wykonywana. Jeśli mówisz, że praca ** nie jest ** wykonywana, pozbycie się elastycznego czasu pracy z nieproduktywnych pracowników (lub pensji / urlopu) może być dobrym rozwiązaniem. W twoim przykładzie. Deweloper X i Projektant Y powinni koordynować pracę, więc żaden z nich nie siedzi i nie kręci kciukami, czekając na siebie. Jeśli tak się nie dzieje, jest to problem zarówno z procesem, jak i harmonogramem ...
`dobre stracisz na rzecz innego zatrudnienia '- to sedno całej sprawy, @Jacob. Jeśli praca nie jest wykonywana, masz głębsze problemy; Twoi programiści i projektanci muszą lepiej koordynować. Jeśli praca * jest * wykonywana, nie marnuj czasu programistów na bzdury, takie jak ustawianie określonego czasu rozpoczęcia.
+1 za przegraną z innymi pracodawcami. Gdybym wyszedł ze środowiska, w którym ufano mi, że dotrzymam własnego harmonogramu i wykonam swoją pracę, do środowiska, w którym mam problemy z opóźnieniem, odkurzałbym swoje CV.
@ErikDietrich: Tak więc, jeśli nie wykonałeś swojej pracy w zadowalający sposób, a twój szef powiedział: „Wiesz, twoja praca nie jest wykonywana ich ustalony i zalecany harmonogram, więc zacznijmy przychodzić zgodnie ze stałym harmonogramem najpóźniej o 9:30 ”. czy nadal możesz odkurzyć swoje CV?
@JacobG Gdybym pochodził ze środowiska elastycznych godzin pracy i teraz częścią „satysfakcjonującego” jest „bycie na czas”, to absolutnie bym to zrobił (i myślę, że twój zespół też). Elastyczne godziny to nie kwestia graczy, którzy grają całą noc w gry wideo - chodzi o kulturę zaufania. Jeśli to mój zespół, to ufam, że znają swoje osobowości i preferują godziny pracy na tyle dobrze, aby wszystko załatwić. Cofnięcie elastycznych godzin pracy oznacza cofnięcie tego zaufania i wysłanie wiadomości, że muszą być (mikro) zarządzane, ponieważ są leniwi i niekompetentni. Nawet jeśli to prawda, im się to nie spodoba.
Zgadzam się z @AdamRackis co do tego, czy: `` Dużym problemem jest to, że jeśli Dev X pracuje nad projektem z Projektantem Y, a Projektant Y jest o 8, czeka [...] `Zagłosowałbym Projektant Y powinien zaplanować z wyprzedzeniem i powiedzieć o koniec dnia „Hej, będę pracował nad tym jutro rano, czy mógłbyś przyjść jutro wcześnie i pomóc mi, lub załatwić to przed wyjazdem”. Zaproszenie ich do wspólnej pracy również wymaga mniej czasu .
„Zasypianie trzy razy w tygodniu, ponieważ grają w WoW całą noc, nie jest legalne”. Co oznacza „zaspanie”? Czy nadal jesteśmy tutaj w podstawówce? Osiem godzin to osiem godzin, niezależnie od tego, czy zaczyna się o 6 rano, czy o 10 rano.Jeśli chcesz, aby ludzie byli obecni na spotkaniach itp., Pozwól im wybrać określone podstawowe godziny, w których będą dostępni, powiedzmy od 10:00 do 15:00. lub cokolwiek. Ale to, czy praca jest wykonywana, jest ortogonalne do tego, czy przychodzą w określonym czasie, czy nie. ** Czy próbowałeś porozmawiać z programistami o problemie i poprosić * ich * o znalezienie rozwiązania? **
@Kyralessa - Jeśli twój szef mówi, że jesteś w pracy o 9:30, lepiej bądź w biurze o 9:30, w przeciwnym razie JESTEŚ SPÓŹNIONY. Nie mogę uwierzyć, ilu ludzi ma problem z pytaniem tego autora, nie mówiąc już o mówieniu mu, że nie jest rozsądnym przywódcą, uczono mnie, żebym przychodził na czas każdego dnia.
@Ramhound Problem w tym, że poprzednia kultura była taką, w której 9:35 NIE było spóźnione, a PO chcą przejść do kultury, którą jest, prawdopodobnie dla osób z talentami, których nie można łatwo zastąpić i które mają pewien poziom swobody Może krzyczeć „JESTEŚ SPÓŹNIONY”, jak przypuszczam, ale może to skutkować odejściem niektórych osób i obniżeniem morale, którego wydaje się, jakby próbował uniknąć.
@Renan Z pewnością nie jest idealny do wszystkich sytuacji. Chodzi o to, aby mieć pewność, że potrzeby biznesowe są zaspokojone. Jeśli w krytycznym momencie pojawi się pilny problem z produkcją, ktoś musi być w stanie go naprawić. Na moim obecnym stanowisku często to ja, ale zdarza się, że dostaję wiadomość e-mail na telefon, potwierdzam, wskakuję na komputer * w domu * i rozwiązuję problem. Jeśli zdarzy się nagły wypadek, istnieją problemy znacznie wykraczające poza to, kto jest w biurze i kiedy.
@Ramhound Ustalenie dowolnego czasu rozpoczęcia, kiedy wcześniej takiego nie było i oczekiwanie, że wszyscy po prostu dostosują swój harmonogram całego życia do niego _ jest_ nierozsądne. W tym przypadku ustalanie trudnego czasu rozpoczęcia, gdy nie jest to naprawdę konieczne, jest również nierozsądne. Oczywiście programiści nie uważają tego za konieczne, dlatego wydaje im się to nierozsądne. Ponadto, biorąc pod uwagę, że są w firmie znacznie dłużej niż kierownik i wszyscy wydają się zgadzać, mogą po prostu mieć rację.
#4
+50
Erik Reppen
2012-05-06 00:55:38 UTC
view on stackexchange narkive permalink

Dokładną odpowiedzią na twoje pytanie jest zwolnienie i zastąpienie kogoś, kto nie otrzyma wiadomości, a następnie zwolnienie każdego, kto nie otrzyma wiadomości.

Nie sądzę, że to pomoże Twoja kariera lub cele rozwojowe Twojej firmy, ale zdecydowałeś, że to jest problem i wygląda na to, że nic Cię nie przekonuje. Więc tak to się robi.

Bardziej konstruktywnie proponuję rozważyć następujące kwestie:

  • Twoi deweloperzy mieli elastyczny czas. Teraz chcesz to odebrać

Nie ma znaczenia, czy jest to oficjalna korzyść w jakiejś pisemnej polityce, czy nie. To de facto polityka i część ustalonej kultury. Życie ludzi i harmonogramy zostały ustalone w tych godzinach. A dla deweloperów takich jak ja, którzy wolą unikać godzin szczytu i którzy zimą dostają strasznie paskudnego SAD, ale nie mogą wymyślić żadnych przyjaznych programistom miejsc bliżej równika, wolałbym mieszkać, jest tak duży umowa jako przynosząca korzyści zdrowotne.

  • Jaka jest natura tego „niepokoju”, o którym wspominasz? Czy jest to a) przede wszystkim zazdrość, czy b) uzasadnione problemy z komunikacją między działami, takie jak trudności z planowaniem spotkań / ogólną komunikacją.

a) Deweloperzy nie muszą wchodzić w interakcje z klientami lub innymi firmami. Z doświadczenia wiem, że im sztywniejsza struktura firmy, tym bardziej mierni są twórcy. Chociaż większość prac rozwojowych to śruby i nakrętki, jest to również twórczy proces rozwiązywania problemów, który wymaga od ludzi bycia w najlepszym wydaniu. Jest to również nieprzewidywalny proces oparty na terminach, który czasami powoduje bardzo, bardzo późne godziny. Efektem ubocznym jest to, że deweloperzy często otrzymują „kreatywne” podejście. W 30-osobowej firmie nie powinno być trudno nalegać, aby ludzie byli osobami dorosłymi, jeśli chodzi o pracowników, którzy muszą być najostrzejsi, gdy są obecni i prawdopodobnie spędzą o wiele więcej godzin w ciągu roku niż 9-17, czyli zwykle pakują swoje rzeczy o 16:55 każdego dnia.

b) W firmie 30-osobowej nie powinno się odbywać tylu spotkań, że staje się to problemem. Nie licząc takich rzeczy jak spotkania sprinterskie lub inne dwumiesięczne sesje planowania, poświęcanie programistom więcej niż 30 minut każdego dnia na spotkania jest absurdalną, rażąco niekompetentną stratą pieniędzy. Podobnie z ogólną komunikacją. 30 osób oznacza, że ​​podchodzisz do drugiego faceta i rozmawiasz z nim. W scenariuszach elastycznego czasu pracy rozsądne jest określenie przedziału czasu, w którym wszyscy są w biurze w tym samym czasie. Nie przychodzi mi do głowy dobry powód, dla którego ten okres powinien trwać dłużej niż 3-4 godziny dnia pracy i dlaczego nie powinien on być tak blisko środka dnia, jak to tylko możliwe.

  • Dlaczego poranny standup?

Dlaczego jest tak, że pierwsze fragmenty zarządzania pomysłami ze scrum, agile itp. są zawsze radą, że nie masz standupu? W programowaniu zajmuje trochę czasu, aby przywrócić pełną świadomość wszystkich szczegółów i problemów, z którymi masz do czynienia w danym problemie. Kiedy robisz stand-upy, twoi deweloperzy nie będą mieli całkowicie przykręconych głów. Standupy są kluczowe dla komunikacji i poprawy wydajności, a nie coś, co robisz w pierwszej kolejności, aby „usunąć się z drogi”.

  • Czy twoi programiści nie wykonują swojej pracy?

Jeśli nie, po co mieszać z dobrą rzeczą? Nie jest ich zadaniem komunikowanie się z innymi problemami w firmie. To jest twoje. W rozsądnej strukturze zarządzania odpowiedzialność spoczywa na bezpośrednim przełożonym i ludziach, którymi zarządzasz, a nie na kwaśnych winogronach z innych działów, którzy muszą być tam o bardziej typowej porze ze względów praktycznych.

Odpowiedziałem na pytanie. A potem naprawdę długie uzupełnienie / uzupełnienie.
#5
+46
user718
2012-07-12 12:30:04 UTC
view on stackexchange narkive permalink

Przegląd pytania: jest wiele brakujących kontekstów i informacji

Jako nowy kierownik techniczny w nowej firmie, jakie dodatkowe strategie można zastosować, aby zmienić kulturę rozwoju zespół, aby ludzie pojawili się w czasie, o który prosiłem?

  1. Jak nowy z kierownikiem technicznym?
  2. Dlaczego narzucacie czysto nietechniczne zasady zarządzania?
  3. Jakie są Twoje kwalifikacje kierownicze?
  4. Jakie masz doświadczenie w zarządzaniu personelem?
  5. Czy zdobyłeś szacunek zespołu w sposób techniczny?
  6. Czy zdobyłeś szacunek zespołu jako menedżer?

TLDR: Mój zespół nie pojawia się na czas. Próbowałem ich zmusić, ale to nie działa.

Nie możemy zapewnić rozwiązania, chyba że wiemy konkretnie, dlaczego musisz zmienić kulturę, więc drastycznie. Nie wiemy też, do czego próbowałeś ich zmusić , aby móc powiedzieć Ci, dlaczego jest to nieskuteczne. Możemy zgadywać, ale to są spekulacje.

Dlaczego masz za zadanie rozwiązać zadanie, które jest prawdopodobnie zadaniem kierownictwa personelu pozatechnicznego? Przekaż to przełożonemu, który jest menedżerem i pozwól mu się tym zająć. Dobry gliniarz kontra zły gliniarz.

Dane ogólne:

Mała firma, 30 pracowników, 5 członków mojego zespołu. Poprzednia pozycja nadal dotyczy pracowników jako zwykłych programistów.

  1. Czy poprzedni kierownik techniczny ustąpił?
  2. Czy poprzedni kierownik techniczny został zdegradowany?
  3. Czy poprzedni kierownik techniczny był skuteczny?
  4. Czy większość obecnego zespołu ma bardziej osobiste relacje z poprzednim kierownikiem technicznym?
  5. Czy poprzedni kierownik techniczny nadal skutecznie dowodzi ?

Kultura przed moim przybyciem była kulturą nieformalną, bez ustalonych granic i godzin pracy. Ta kultura nie została zakwestionowana przez liderów korporacji.

  1. Więc to musiało działać?
  2. Czy zespołowi udało się dostarczyć przydatne produkty zgodnie z obietnicą?

Większość osób w zespole pojawiała się między 10:30 a 11:00 z powodu to. Inne działy, ze względu na charakter swojej pracy, wyznaczyły czas rozpoczęcia na 8 lub 9. Ta rozbieżność i nieprzewidywalność powoduje wiele niepokoju między moim działem a innymi działami.

A konkretnie, nie ma tu wystarczająco dużo szczegółów, aby w ogóle zacząć formułować odpowiedź na to pytanie. Jakakolwiek odpowiedź byłaby kompletną spekulacją.

W związku z tym posadziłem zespół i określiłem godzinę „nie później niż” na 9:30. Wyjaśniłem swoje rozumowanie i wyjaśniłem zalety takiego programu oraz wady obecnego programu. To była długa i kontrowersyjna rozmowa, a 3 z 5 osób w zespole było bardzo niezadowolonych.

Co powiesz na swoje korzyści i negatywy bez nich nie możemy ocenić, jak rozsądna i skuteczna mogłaby być Twoja komunikacja. Wygląda na to, że nawet nie rozważałeś lub nie badałeś jakiegoś kompromisu ze swoim zespołem lub zespołami zewnętrznymi w oparciu o ich negatywne informacje zwrotne. Zrobiłeś to?

Nie trzeba dodawać, że ludzie nie pojawiają się na czas (a 9:35 nie jest na czas).

To nie działa To brzmi jak bardzo pozytywne lub skuteczne podejście.

Zaplanowałem nasze codzienne spotkanie standup o 9:30 jako dodatkowy motywator. Wiedząc, że zmiana godzin rozpoczęcia zabiera trochę czasu (z dojazdami do pracy itp.), Początkowo czekałem z rozpoczęciem spotkania, aż wszyscy się pojawią, ale teraz po prostu zaczynam spotkanie (i często kończę spotkanie) z kimkolwiek jest obecny. To też wydaje się nie robić różnicy, a sprawia, że ​​zespół jest mniej spójny.

Tak więc jednostronne działania , które podejmujesz , zmniejszają spójność zespołu. Pomyśl o it.

Rozmowy indywidualne i grupowe dają takie same rezultaty, jak oryginalna rozmowa (tj. Nie widzą wartości, odbieranie korzyści z pracy itp ...)

Słyszymy i możemy ekstrapolować to, czego nie akceptują, czy słyszysz ich?

Mam pełne wsparcie i wsparcie ze strony kierownictwa wyższego szczebla i jestem upoważniony do korzystania z wszelkich urządzeń, które uznam za stosowne, aby się tym zająć.

Katolik Kościół miał taką samą władzę podczas inkwizycji, spójrz, jak to się skończyło!

Mój obecny następny krok to wysłanie kogoś do domu i zmuszenie go do wzięcia dnia wolnego. Czy to zbyt drastyczne? Czy istnieją alternatywne strategie, które pomijam, a które mogłyby pomóc mi rozwiązać ten problem?

Eskalacja też nie brzmi jak realna alternatywa. Wysyłanie ich do domu bez wynagrodzenia jest obraźliwe i zaszkodzi firmie bardziej niż pracownikowi. Sprawi, że będziesz wyglądać jeszcze bardziej dyktatorsko i tyrańsko. Traktowanie ich jak dzieci sprawi, że będą zachowywać się jak dzieci jeszcze bardziej.


Przewidywany wynik Twojego obecnego podejścia

  1. Stracisz szacunek całego zespołu, będą coraz bardziej nieefektywni, będziesz postrzegany jako coraz bardziej nieefektywny, gdy produktywność spada.
  2. Twoje niepowodzenie w zmianie polityki i umiejętności zarządzania personelem spowoduje, że będziesz postrzegany jako nieefektywny przez swoich przełożonych.
  3. Stracisz szacunek ze strony osób spoza Twojego zespołu z powodu komunikacji między biurami. Sabotuje to również wszelkie przyszłe możliwości przywództwa technicznego.
  4. Z pewnością zaszkodzisz swojej reputacji w firmie, w górę iw dół łańcucha.
  5. Lepsi pracownicy będą głośno rezygnować pierwszy.
  6. Jeszcze lepsi pracownicy po cichu odejdą po nich.
  7. Ci z marginalnymi kwalifikacjami mogą zrezygnować lub nie, w zależności od bólu, który narzucisz.
  8. Niewykwalifikowani pozostaną jak tyka i znieść wszystko, co narzucisz.
  9. Firma traci i zyskuje złą reputację na zewnątrz przez pracowników, którzy odeszli.
  10. Percepcja jest wszystkim! Nigdy o tym nie zapominaj!

Niektóre sugerowane podejścia

  1. Jako ich menedżer powinieneś walczyć o odizolowanie ich od decyzji wyższego kierownictwa. Powinieneś walczyć o to, by ich głos został usłyszany. Powinieneś pomóc im wspólnie sformułować odpowiedź, odepchnąć i wesprzeć ich reakcją.
  2. Jest to decyzja nietechniczna i czysto korporacyjna. Dlaczego zajmujesz się tym i jego wdrażaniem? Miej z tym lepszy układ, taka jest ich praca.
  3. Nie zachowuj się jak dyktator lub tyran. Może nie równa się racji.
  4. Weź udział w szkoleniu umiejętności interpersonalnych i miękkich.
  5. Poruszaj się wolniej. Takie rzeczy nie zmieniają się z dnia na dzień.
  6. Jeśli mają oni dobre stosunki z zespołem, musisz mieć po swojej stronie poprzedniego kierownika technicznego.
  7. Wybierz alternatywny kompromis, jak o ludziach, którym nie przeszkadza wczesne przyjście, czy to, inni nie muszą?
  8. Przesunięcie czasu wstawania jest arbitralne, każdy to widzi i nie jest postrzegane jako praktyczne lub rozsądne, ale dyktatorskie.
  9. Poproś zewnętrzne zespoły, z którymi masz do czynienia, aby wzięły udział w dyskusji i pomogły Ci sprzedać zmiany zasad.
  10. Wycofaj się, zgódź się z nimi, być dobrym policjantem. Poproś przełożonego o ustanowienie prawa. Jest to problem związany z zarządzaniem, nie problem techniczny. Jesteś kierownikiem technicznym, a nie menedżerem, prawda?
  11. Poproś członków zespołu zewnętrznego i członków swojego zespołu o ustalenie czasu na spotkanie, kiedy tego potrzebują. Z góry określone dni i czasy dostępności byłyby dobrym kompromisem. Deweloperzy nie chcą, aby im stale przeszkadzał zespół zewnętrzny i wydają się być obecni wyłącznie po to, aby przeskakiwać na spotkania na ich żądanie.

Ostateczna myśl:

Mój Styl zarządzania, zarówno techniczny, jak i nietechniczny, opiera się na dyrektoru Wu Wei The Tao te Ching.

Zasadę Wu Wei można zrozumieć, uderzając w korek unoszący się w wodzie. Im mocniej go uderzysz, tym bardziej się ustąpi: im bardziej się ugnie, tym mocniej się odbije. Bez marnowania energii korek może cię łatwo zniszczyć.

Im więcej robisz, tym szybciej możesz się nie udać. Im mniej będziesz robić, tym większe prawdopodobieństwo, że to, co chcesz, zostanie wykonane.

Pośrednie przejrzyste przywództwo

Na początku ludzie prawie nie zauważają lidera. Następnie wielbią go i chwalą, a potem zaczynają się go bać, w końcu nim gardzą. W ten sposób utracona wiara rodzi utraconą wiarę.

Nie kieruj się, uczyń kilka słów cennymi. Kiedy praca zostanie zakończona, osiągnięta na koniec, wszyscy powiedzą: Zrobiliśmy to sami, naturalnie.

Zbierz osoby z działu zewnętrznego, które mają skargi, razem z twoimi ludźmi w pokoju i pozwól wypracowują między sobą akceptowalne rozwiązanie, bez ciebie w pokoju . Bądź gotów zaakceptować każdy wynik. Wtedy rozwiązanie należy do nich, są właścicielami, a ty zyskasz od nich bardzo potrzebny szacunek za to, że pozwolili im to rozwiązać. To jest podejście niedyrektywne .

+1, To wszystko są naprawdę świetne podejścia. Osobiście podoba mi się podejście polegające na wzmocnieniu zespołu w rozwiązaniu problemu. To niesamowite, do czego zdolni są dorośli, kiedy są traktowani jak… cóż… dorośli. Martha musi spotkać się z Johnem, więc planują i koordynują razem, bez wielkiego, wrednego, paskudnego szefa, który przychodzi i gra w dyktatora.
Zmodyfikowałem moje pytanie, aby odpowiedzieć na niektóre z Twoich konkretnych pytań.
@JacobG Nawet po edycji, jedna rzecz, która wciąż nie jest jasna, to czy jesteś * Kierownikiem technicznym *, czy tymi ludźmi * Nietechnicznymi kierownikami / kierownikami liniowymi *? Jest to ważne wyróżnienie, ponieważ kierownik techniczny jest liderem w podejmowaniu decyzji technicznych. Jakiej ** technologii ** użyć, ** nie ** kiedy programiści wchodzą do pracy! Dziesięć lat podejmowania technicznych decyzji nie jest żadnym rodzajem kwalifikacji do radzenia sobie z nietechnicznymi problemami społecznymi / osobowościowymi dotyczącymi kierownictwa, zwłaszcza bez formalnego szkolenia.
@JacobG Zacząłeś od podejścia * stick *, żadna ilość * marchewek * nie wyzdrowieje. Znakiem dobrego lidera jest wiedzieć, kiedy nie mają kwalifikacji i nie będą skuteczni, i poprosić o pomoc, osobiście uważam, że to jedna z tych chwil, w których możesz zachować twarz i skierować tę bitwę do kogoś innego . Przegrałeś wojnę psychicznie, nawet jeśli * wygrasz * bitwę, ty i drużyna przegracie wzajemnie. ** Jedynym ** sposobem rozwiązania tego problemu jest zebranie liderów zewnętrznych oddziałów razem ze swoim zespołem i zaproponowanie im rozwiązania * bez * ciebie w pokoju.
@JarrodRoberson - Nie jestem pewien, czy rozumiem twoje rozróżnienie. Odpowiadam za kontrolę kierunku technicznego, a także za ich recenzje. Zatwierdzam WOM i dostarczam funkcje. Robię obie te rzeczy od 10 lat. Co więcej, technicznie nie było podejścia „kijowego”. Ta polityka została wprowadzona podczas ponad 2 godzinnej dyskusji z całym zespołem. Nie był on przedstawiony dyktatorsko i nie pociągnął za sobą żadnych konsekwencji. Od tego czasu kierownictwo wzmocniło przekaz w zespole i zasadniczo odbyło tę samą ponad 2-godzinną dyskusję.
@JacobG * "został wprowadzony w wyniku ponad 2-godzinnej dyskusji" * to oksymoron. * „zostało wprowadzone” * oznacza ** jednostronną ** decyzję podyktowaną przez kogoś i zastosowaną. Większość miejsc, w których pracowałem w ciągu ostatnich 22+ lat, zdawało sobie sprawę, że powinien istnieć rozdział przywództwa technicznego i zarządzania. To bardzo dobrze ugruntowana struktura organizacyjna w większości dużych (mam na myśli wiele miliardów dolarów rocznie) firm, dla których pracowałem jako kierownictwo techniczne. Konflikt tych dwóch obowiązków jest receptą na walkę. Prowadzenie 2 x ponad 2 godzinnych * dyskusji * powinno pokazać, że polityka jest zła, a podejście jest gorsze.
@JarrodRoberson Myślę, że rozmawiamy ze sobą. 1) Ta firma jest zbyt mała, aby zagwarantować nietechnicznego kierownika ds. Rozwoju. 2) To pytanie tak naprawdę sprowadza się do „jak wpłynąć na zmianę kulturową” niezależnie od specyfiki zmiany. Faktem jest, że osoby odpowiedzialne za tę zmianę uznają potrzebę zmiany kulturowej i doszli do wniosku, co to za zmiana. Wszyscy zaangażowani zgadzają się, że zmiana jest prawidłowa. Mieli nadzieję, że przedyskutowanie tego z zespołem programistów doprowadzi ich do takich samych wniosków. Tak się nie stało i to fiasko jest wynikiem.
+1 to dobra odpowiedź ... chociaż wolę bardziej ustrukturyzowane środowisko, to jest rzeczywista odpowiedź z praktycznymi sugestiami.
@JacobG: „Wszyscy zaangażowani zgadzają się, że zmiana jest poprawna”. Jednak powiedziałeś, że 3 na 5 deweloperów mocno sprzeciwiło się zmianie. Czy to oznacza, że ​​programiści nie są „zaangażowani” w zmianę? Czy może chodzi o to, że po dyskusjach wszyscy programiści zgodzili się, że ta zmiana była konieczna?
@MarkBannister - Przepraszamy za zamieszanie. Chodziło mi o to, że każdy odpowiedzialny, który określił potrzebę zmiany kulturowej, zgodził się, że był to właściwy ruch.
@JacobG ciągle powtarzasz * omawiałeś to z nimi *, nie powiedziałeś im, jak będzie teraz i najwyraźniej kłócili się przez ponad 2 godziny. To nie jest * dyskusja * o zmianie polityki. ** Prawdziwa dyskusja ** byłaby * mamy następujące skargi z innych działów, jeden pomysł z tych zespołów to wcześniejszy czas rozpoczęcia, jakie macie inne pomysły, które możemy przekazać innym zespołom, aby je rozwiązać rzeczywiste problemy, które mają? *. Ponieważ nie wydaje się, że posiadanie wszystkich 100% zespołu wcześnie jest problemem.
@JarrodRoberson: Wydaje mi się, że nadal nie wyrażam się jasno. Przywództwo rozpoznało problem systemowy, kulturowy, opracowało rozwiązanie poprzez obszerną dyskusję. Elementem tego rozwiązania była punktualność. Dyskusja z zespołem deweloperskim miała poprowadzić ich zgodnie z tą samą logiką, która doprowadziła przywódców do wniosków z oczekiwaniem, że zespół wyciągnie te same wnioski. Tak się nie stało, ponieważ zespół nie zgodził się, że jest problem do rozwiązania. Postanowili skupić się na tej konkretnej kwestii ponad wszystkimi innymi.
@JacobG dyskusja zakłada dwustronną komunikację, jak sam przyznajesz, nawet tutaj, była to jednostronna komunikacja * jak będzie teraz *. * „Zaplanowałem nasze codzienne spotkanie standupowe na 9:30 jako dodatkową motywację.” * Jest arbitralnym ** kijem ** próbującym wymusić zgodne zachowanie. Każdy, kto to czyta, widzi, że Twój „zespół” to zauważył! Jest to zasada, która została wprowadzona, którą postrzegają jako karę za działania jeszcze nie podjęte i buntują się. Jeśli nie zaakceptujesz tej percepcji, nic, co zrobisz, nie będzie skuteczne. Mówisz jasno, nie słuchasz ich.
@JarrodRoberson Naprawdę nie wiem, dlaczego się tutaj nie łączymy. Jeśli 5 obrazków narzeka na 1 (prawdziwy / ważny), a 1 uważa, że ​​5 jest po prostu zazdrosnych / gorszych / powinno to pokonać, wtedy próba przekonania ich, dlaczego ta zmiana byłaby lepsza dla wszystkich, wydaje się sprawiedliwa. Jak powiedziałem, starszy kierownik poprosił mnie o wprowadzenie zmiany, próbowałem przeprowadzić zespół przez logikę, przez którą przeszedł starszy kierownik i odpowiedź była taka, że ​​naprawdę nie ma problemu. Czy mam wrócić do MGMT i powiedzieć „przepraszam, zespół deweloperów uważa, że ​​obsługa klienta to banda dzieci i powinienem sobie z tym poradzić?”
@JacobG chodzi mi o to, że ** twoje podejście ** do zespołu programistów było słabe. Jeśli będziesz upierał się przy takim podejściu, co brzmi tak, jakbyś to robił, ** nadal będziesz ponosić porażki **, a Twoi przełożeni zobaczą, że przegrywasz. Uważam, że powinieneś odepchnąć się w imieniu swojego zespołu, * duża część pracy menedżera * polega na odizolowaniu ich zespołu od takich rzeczy. Powinieneś przynajmniej dać zespołowi programistów szansę na wypracowanie alternatywnego rozwiązania. Podałem wiele ** skutecznych ** podejść do wypracowania wspólnego kompromisu. Nie wierzę, że cały ** zespół ** musi być na zawołanie.
@JacobG przestań spędzać tyle czasu na obronie swojego nieudanego podejścia i uzasadnianiu opinii innych działów i zacznij przyjmować wszystkie dobre sugestie dotyczące ** tego, jak możesz wspierać swój zespół i pozwolić, aby ich głos został wysłuchany! ** Jeśli uważasz, że nie powinni byli głos, cóż, nie chciałbym być w tej drużynie. Zobacz moje przewidywania dotyczące tego, co się stanie w mojej odpowiedzi.
Czytając tę ​​dyskusję, wydaje mi się, że prawdziwym problemem jest to, że wyżsi decydują o szczegółach, które ich nie dotyczą. Każdy poziom powinien zwracać uwagę na nieodpowiednie wyniki z poziomu poniżej. Jak powinno być w twoim sądzie. To, że programiści w tym momencie prawie wszystkich zawalają, sugeruje mi, że obaj mają dość i wcale nie martwią się o znalezienie nowej pracy, jeśli o to chodzi. Jeśli chcą tak to rozegrać, najlepiej oceniliby trudność zastąpienia większości zespołu deweloperów.
#6
+28
Tim
2012-04-27 00:55:45 UTC
view on stackexchange narkive permalink

Pierwszą rzeczą, którą musisz zrobić, jest przeczytanie „Peopleware”

Błędem jest próba zmiany tego teraz. Byłem menedżerem w firmie, w której mieliśmy dość elastyczny harmonogram pracy. Jeden z naszych najbardziej produktywnych programistów przyszedł o 11:00. Zgłosił się do mnie przez chwilę. Powiedziano mi, żebym zmienił godziny pracy. Walczyłem z tą prośbą. Ciężko. Zostałem odrzucony.

Wynik:

Mniej produktywny, mniej zainteresowany programista, który był wielkim współpracownikiem. Stał się znacznie mniej produktywny i przydatny dla zespołu.

Wszystko z powodu jakiegoś głupiego pojęcia „na czas”.

Skoncentruj się bardziej na produktywności.

Twoim zadaniem jako menedżera jest usuwanie barier dla produktywności - a nie sprawianie, by wszyscy wyglądali, czuli i zachowywali się tak samo.

Elastyczne godziny to zaleta - a pracodawca, który zezwala na elastyczne godziny, może przyciągnąć więcej wartościowych ludzi.

Jako „nowy kierownik techniczny” nie możesz szybko zmienić kultury. Zwłaszcza w kierunku, w którym wydaje się, że chcesz. Czy zrobiłeś coś, aby poprawić role / zadania swojego zespołu?

Najpierw pracuj nad budowaniem z nimi zaufania. Tak wielu menedżerów / leadów po raz pierwszy popełnia takie błędy.

Dowiedz się, czego NAPRAWDĘ potrzebują inne grupy. Nie „muszą tu być o 9:30”. Naprawdę dowiedz się, na czym polega problem. Następnie znajdź rozwiązanie.

Zamiast mówić zespołowi, co ma zrobić - wyjaśnij problem, a następnie ZAPYTAJ O SUGESTIE / OPINIE.

Mówisz niejasno, że „powoduje wiele niepokoju między moim działem a innymi działami” - ale nie jest jasne, co to za niepokój - czy są zdenerwowani, że deweloperzy są traktowani preferencyjnie? Jaki jest prawdziwy problem?

Próbowałem je zmusić i to nie działa.

Jest ku temu powód. I wydaje się, że nie słuchasz. Sięgnięcie po bardziej drastyczny środek i większe młoty tak naprawdę nie poprawią sytuacji. Wypróbuj podejście „marchewkowe” zamiast „kija”.

Jeszcze raz przeczytaj „Peopleware”.

Nie zamierzasz posuwać się daleko z pomysłami, takimi jak codzienne spotkania, wysyłanie ludzi do domu lub z myślą, że są twoimi sługami, którzy muszą robić to, co mówisz, "albo."

Kto ci mówi, że powinien być w pracy o 9:30? Inne grupy? Twoi szefowie? Ty? Znajdź PRAWDZIWY problem i rozwiąż go. Kiedy się pojawią, NIE powinno być problemem.

* Uwaga moderatora: rozszerzona dyskusja w komentarzach została usunięta. Jeśli chcesz kontynuować dyskusję, przenieś ją do [czatu] (http://chat.stackexchange.com/rooms/3060/the-water-cooler). *
Miałem kiedyś kolegę, który pojawił się o godzinie 12 i wyszedł, kiedy miał na to ochotę.Noszenie sandałów lub bez butów.Jako programista był niesamowity.Był jedną z nielicznych osób, jakie kiedykolwiek spotkałem, która była wyraźnie lepsza w tej pracy ode mnie.Próba zmuszenia tego gościa do wczesnego rozpoczęcia (a) nie zakończyłaby się sukcesem i (b) byłaby najbardziej absurdalnie głupią rzeczą, jaką można było zrobić.
#7
+20
Kristof Provost
2012-04-13 15:03:29 UTC
view on stackexchange narkive permalink

Niezależnie od tego, dlaczego to robisz, członkom zespołu wydaje się, że odbierasz bonus. Dla niektórych z nich może to być nawet jeden z głównych powodów, dla których pracują dla Twojej firmy, a nie innej.

Zasadniczo prosisz ich o zmniejszenie całkowitego pakietu wynagrodzeń.

Można ich przekonać, żeby to zrobili, ale będziesz potrzebować dobrych argumentów i prawie na pewno będzie z tego powodu utrzymywać się niechęć. Możesz stracić przez to dobrych ludzi lub nie.

Z twojego opisu wynika, że ​​głównym powodem jest zazdrość ze strony innych działów. Czy rozważałeś przyznanie innym działom tego samego atutu?

Krótko mówiąc: nie rób tego, chyba że uważasz, że warto stracić część z nich.

Nie jest to wyłącznie zazdrość i mój błąd, jeśli tak ją opisuję. Inne działy mają publiczne godziny pracy, więc elastyczny czas bez dodawania zasobów nie jest dla nich możliwy.
@Chad - Odpowiedź jest domniemana w drugim akapicie: zapłać im więcej
@CurtainDog - O ile podwyżka nie jest uzależniona od pojawienia się na czas, wątpię, czy będzie to trwałe rozwiązanie. Jeśli jest to przypadkowe, w pewnym sensie się zgadzamy.
Czy byłaby możliwość edytowania tego posta i rozszerzenia informacji o tym, jak dać drugiej drużynie ten sam profit? Chociaż ten post oferuje alternatywę, tak naprawdę nie zagłębia się w to ani nie odnosi się do faktu, że niektórzy pracownicy mogą być pracownikami zmianowymi, którzy muszą mieć harmonogram.
#8
+18
Erik Dietrich
2012-04-23 20:37:03 UTC
view on stackexchange narkive permalink

Aby zmienić swoją kulturę, musisz zdać sobie sprawę, dlaczego doświadczasz oporu, a następnie zająć się przyczyną tego oporu.

Z mojego doświadczenia wynika, że ​​„koordynacja z innymi działami” jest domeną tych, którzy mają wyższe stanowiska i podążał ścieżką zarządzania projektami / ludźmi. Twórcy na co dzień zainteresowani wyłącznie kodem są przed tym chronieni. W sklepach bardziej ustrukturyzowanych mogą w ogóle tego nie robić, aw mniejszych sklepach mogą to robić mniej formalnie.

Czy ci się to podoba, czy nie, odziedziczyłeś kulturę elastycznych godzin pracy, co jest ogromną zaletą dla większości programistów. Odebranie im tego w jednym z twoich pierwszych aktów jako przywódca nie tylko wyda się im tyrańskim (kiedy wyjaśnisz im, że 9:30 nie jest tak wcześnie, narzucasz własne harmonogram na nich, arbitralnie ich zdaniem), ale realnie jest to odjęcie znacznej korzyści. Możesz lubić pracę według określonego harmonogramu i nie uważać tego za znaczącą korzyść, ale prawdopodobnie uważają to za nieocenione. Potraktuj to na równi z powiedzeniem im, że zabierasz im tydzień wakacji lub zmniejszając ich wynagrodzenie o kilka procent.

Aby to zmienić, możesz użyć marchewki lub kija. Mówisz o używaniu kija i być może większego kija. Jeśli pójdziesz tą drogą, planuję zatrudnić kilku nowych programistów, ponieważ domyślam się, że część Twojego zespołu zacznie udzielać wywiadów w innych firmach. Osobiście poszedłbym marchewkowym szlakiem, aby uzyskać buyin za usunięcie tego profitu, wyjaśniając, że o przyszłych awansach i awansach zadecydują ci, którzy „koordynują z innymi działami”. Oznacza to, że liderzy / ważne osoby są na wczesnym etapie, współpracują z innymi zespołami, przejmują obowiązki itp. „Nowicjusze” otrzymują premię elastyczną, ale ludzie poważnie podchodzą do postępów na czas.

Jeśli stworzysz taką kulturę, podejrzewam, że niektórzy z twoich deweloperów zaczną przychodzić na czas z własnej woli. Zarówno ze względu na zainteresowanie awansem, jak i ze względu na przekonanie, że „ważni ludzie dostają się wcześnie”.

#9
+13
aroth
2012-07-12 11:03:25 UTC
view on stackexchange narkive permalink

Krótka odpowiedź jest taka, że ​​NIE powinieneś tego robić. Członkowie Twojego zespołu technicznego są (a przynajmniej powinni być ) na tyle sprytni, by wiedzieć, że nie ma wymiernych korzyści z obecności wszystkich w biurze w dowolnym czasie; jedyną ważną miarą jest to, czy ich praca jest wykonywana.

Jeśli Twój zespół nie wykonuje swojej pracy, jest to osobna kwestia. Ale jeśli załatwiają sprawy, to dlaczego ich nękasz tylko dlatego, że nękają cię inne działy?

Częścią twojej roli jako lidera jest odizolowanie zespołu od trywialnych rozproszeń i krytyki wywołanej przez źródeł zewnętrznych. Jeśli twoją reakcją na inne osoby narzekające na członków twojego zespołu jest przekazanie skarg członkom twojego zespołu i / lub dyktowanie zmian wyłącznie na podstawie tych skarg, to nie radzisz sobie w pracy. Sugerowałbym, że zakładając, że Twój zespół faktycznie wykonuje swoje zadania (a wydaje się, że są, ponieważ nie narzekasz na ich produktywność), lepszym sposobem odpowiedzi na taką krytykę jest poinformowanie narzekający „tak, moi ludzie ciężko pracują i konsekwentnie dostarczają solidne wyniki, i to jedyna rzecz, która ma znaczenie; więc dlaczego nie przestaniesz się martwić o to, jak mój zespół radzi sobie ze swoimi zadaniami i nie wrócisz do swoich?”.

I oczywiście, jeśli przejdziesz przez obowiązkową zasadę „musisz być w biurze do czasu X”, sprawiedliwe jest jedynie uzupełnienie jej zasadą „musisz wyjść z biura do czasu Y” oraz zasada „nie wolno pracować z domu poza normalnymi godzinami pracy”. Jest to sprawiedliwe tylko jako sposób na ochronę równowagi między życiem zawodowym a prywatnym pracownika, ponieważ założę się, że wielu członków zespołu, którzy nie pojawiają się do 11:00, prawdopodobnie albo zostaje z powrotem do późna, albo spędza dodatkowy czas w domu.

Tyle że autor twierdzi, że praca nie jest wykonywana.
@Ramhound - Nie, nie ma, przynajmniej nie w oryginalnym poście. Na liście zmian w pralni wspomina, że ​​ostatnio wydajność spada. Ale ponieważ w przeszłości zespół zawsze miał elastyczne godziny pracy, nadal nic nie wskazuje na to, że spadek wydajności jest skorelowany z godzinami pracy lub że ustalenie konkretnego czasu rozpoczęcia pracy spowoduje jakąkolwiek poprawę. Sądząc po oryginalnym poście, wydaje się, że autor jest najbardziej zaniepokojony negatywnymi opiniami, które otrzymuje z innych działów.
Wygląda na to, że „bicie będzie trwało, aż morale się poprawi”.
#10
+13
bethlakshmi
2012-07-12 21:36:53 UTC
view on stackexchange narkive permalink

Nie zazdroszczę Ci tego - jako koledze menadżera byłoby mi ciężko. I szczerze mówiąc, wierzę, że przez to stracisz ludzi. Myślę, że masz pojedynczy symptom, który pochodzi ze zmiany kultury Start Up -> Medium Sized i nie każdy programista dokona tej zmiany pomyślnie. Myślę, że musisz być przygotowany na opisy stanowisk i wiedzę o tym, jak otwierasz podania o pracę i myślę, że musisz położyć nacisk na możliwość zatrudniania nowych ludzi i ulepszania dokumentacji ...

Przepraszam, to takie ponure . Ale nie sądzę, że masz problem z zaufaniem lub przypadek, w którym możesz łatwo wytłumaczyć ludziom zgodę. I naprawdę nie ma wynagrodzenia, które doskonale równoważy ogromną elastyczność w pracy.

Zgadzam się, że odbierasz bonus. Dla niektórych osób elastyczność w czasie rozpoczęcia jest bardzo ważna i przemawia do nieformalnej kultury, która może być silną preferencją dla niektórych osób. Prawdopodobnie wraz z rozwojem firmy obciążenie pracą stało się bardziej niezawodne, zwiększyło się bezpieczeństwo pracy, wzrósł szacunek dla produktu i być może byliście w stanie zaoferować sprytne plany magazynowe, podwyżki płac lub inne ulepszenia. Jeśli nic z tego nie jest prawdą, to musisz zadać sobie pytanie, czy masz rozwijającą się dobrze prosperującą firmę &, czy firmę pogrążoną w rozpaczy.

Sztuczka polega na tym, że ludzie często nie są w stanie połączyć punktów między tymi nowymi wartościami. dodaje i usuwa ulubiony profit. Możesz spróbować to wyjaśnić, ale dla niektórych osób nie jest to dobra kompromis i nie jest to przypadek, w którym możesz zaoferować wybór. To „moja droga lub autostrada”, ponieważ ma wpływ organizacyjny, który niekoniecznie jest odczuwalny w zespole, ale który jest doświadczony i wspierany na wyższych szczeblach firmy.

Wygląda na to, że zrobiłeś właściwe rzeczy:

  • jasno to przedstawiłeś

  • omówiłeś powód i potrzeba zmiany

  • zaangażowałeś się jeden na jednego (i nadal to robię, jak przypuszczam), aby naprawiać indywidualne przypadki, gdy się pojawią

  • przekazałeś opinię

Myślę, że doszedłeś do pytania „czy on naprawdę ma to na myśli?” wskazać, gdzie ludziom udowadnia się, że mówisz poważnie i że to naprawdę musi się zmienić. Osobiście uważam, że spóźnienie się o 5 minut w biurze w moim regionie to nic wielkiego i że spotkania, które mają krótką długość (jak wstanie w zwinnym sprincie) nie powinny być tak uderzające w starcie w dniu roboczym, że utrata połączenia autobusowego lub utrudniony ruch będzie regularnym problemem. Jest to jednak nieco regionalne - w różnych lokalizacjach sytuacja na drogach jest bardzo zróżnicowana. To tyle, ile trzeba znać swój region i wiedzieć na podstawie indywidualnych skarg, co jest rozsądne.

Reszta to po prostu wymyślanie mechanizmu, który jest wystarczająco osłabiający, aby udowodnić, że mówisz poważnie. Jedną z opcji jest jednodniowa wypłata zadeklarowana w ramach twoich praw - chociaż każdy mechanizm, który wymyśliłbym, sprawdziłbym przez prawników. Tak samo jest z formalnym systemem ostrzegawczym, który prowadzi do działań dyscyplinarnych. Zakładam, że Twój dział HR może mieć sugestie ...

Wiele zależy od tego, co praca może tolerować - wysyłając kogoś do domu, tracisz również pracę tego dnia, co wpływa na Twoje koszty Harmonogram &. Kiedy masz system ostrzegawczy, który prowadzi do działań dyscyplinarnych - w tym zwolnienia - oszczędzasz resztę pracy, ale ryzykujesz, że będziesz musiał zwolnić pracownika.

Myślę, że chodzi o to, że masz do czynienia z karami , musisz być przygotowany na karę, która jest na tyle szkodliwa, aby ją potraktować poważnie i doprowadzić do wniosku, że „nie wykonujesz swojej pracy, jeśli tego nie robisz”.

#11
+10
weronika
2012-04-14 08:21:56 UTC
view on stackexchange narkive permalink

Wygląda na to, że istnieje rozdźwięk między tym, jak Twoi programiści postrzegają problem, a tym, jak inne działy (lub Twoi przełożeni lub ktokolwiek faktycznie domaga się tej zmiany) widzą problem. Sugerowałbym próbę wypełnienia tej luki, w razie potrzeby na wielu etapach.

Po pierwsze, czy programiści zgadzają się, że są dobre powody dla tej zmiany? Jeśli się nie zgadzają, czy mają jakieś dobre kontrargumenty lub alternatywne sugestie? Jeśli tak, powinieneś przedstawić je kierownictwu i sprawdzić, czy złagodzą wymóg czasowy - lub czy mogą wyjaśnić, dlaczego alternatywy nie działają, a kontrargumenty nie rozwiązują problemu, abyś mógł Wróć do swoich programistów i przekaż im pełniejsze wyjaśnienie. Kontynuuj w tę iz powrotem tak długo, jak to konieczne / produktywne.

Jeśli dojdziesz do punktu, w którym programiści zgadzają się, że są dobre powody, ale po prostu nie chcą się dostosować, lub nie Uważasz, że powody są dobre i uraza cały pomysł, poinformuj o tym kierownictwo . Wyjaśnij, że mógłbyś zmusić programistów do zrobienia tego, co chcesz, ale spowoduje to urazę, niższą motywację, prawdopodobnie niższą produktywność, a nawet odejście pracowników. Upewnij się, że kierownictwo to rozumie i nadal zgadza się, że ważne jest, aby wymusić godzinę rozpoczęcia (i ponownie poinformować o tym swoich programistów), w przeciwnym razie możesz zostać odpowiedzialny za zmianę, która straciła firmę bardziej niż zyskała.

(Osobista uwaga: byłem w sytuacji, gdy powiedziano mi, żebym przyszedł o ustalonej godzinie, ponieważ, jeśli chodzi o pracowników, bez powodu i jest to naprawdę bardzo mało motywujące . Bardzo ważne jest, aby upewnić się, że ludzie rozumieją przyczyny i nie czują, że zmieniasz zasady tylko z kaprysu lub dlatego, że im nie ufasz).

#12
+9
Michael Durrant
2012-05-06 19:27:24 UTC
view on stackexchange narkive permalink

Pracowałem w organizacji non-profit, która miała ten problem. Spotkania zawsze zaczynały się późno, 10 minut spóźnienia stało się „standardem”.

Potem zatrudniliśmy nowego kierownika projektu dla dużego, kluczowego projektu (i jednego w ustalonym czasie). Zwołała pierwsze spotkanie. Ludzie przychodzili jak zwykle, kilka minut spóźnieni i niedbale rozmawiając. Siedziała na swoim krześle i przez kilka minut nic nie mówiła - w ogóle nic. W końcu rozmowy „ucichły”, aż zapadła cisza. Wszyscy czekaliśmy na rozmowę. Pozwoliła, by cisza trwała trochę dłużej. Rozejrzała się i powiedziała: „Muszę to wyjaśnić. Spotkania zaczynają się punktualnie. Jeśli spóźnisz się 5 minut, nie przejmuj się, po prostu zobacz mnie później. robię w tym tygodniu [cokolwiek] ... ”. Zrobiło to DUŻE wrażenie i ludzie włożyli dużo wysiłku, aby być na czas jej spotkań.

Uwaga: poniżej dodano dodatkową odpowiedź.

Uwzględnij pracę wykonaną zdalnie.

Często najwyżsi producenci i tak wykonują dużą część swojej pracy zdalnie , więc czasami poświęcając tyle czasu zdalnie, co w biurze. Jest to ważna kwestia do rozważenia i komunikacji z innymi działami. Ta komunikacja powinna być subtelna - nie dzwoń na spotkanie, po prostu zacznij szukać sposobów, aby pokazać „tak, joe nie spał wczoraj późno, pracując nad x” i „tak, Mary naprawiła, że ​​w niedzielę była na nogach do północy '.

Porozmawiaj otwarcie o dojazdach. Jeśli ktoś przyjdzie o 10.30, jego dojazd może zająć 15 minut. Jeśli potrzebuje być o 9 lub 9.30, dojazd może zająć godzinę. Poza tym to samo idąc do domu, jeśli pracowali 8 lub 9 godzin. Wiele osób uważa, że ​​jest to główna strata ich życia. Wolą trochę pracować zdalnie, a potem przyjść. Spróbuj połączyć ten fakt ze swoimi potrzebami podczas ustawiania razy i upewnij się, że inne działy też o tym wiedzą, wspominając o tym często.

Upewnij się, że do pomocy używasz technologii . Na przykład pracuję wirtualnie - przez 100% czasu. Więc posiadanie włączonego Skype'a, pokazywanie mojego statusu online, kamery wideo itp. Też może pomóc.

Powodem, dla którego to głosuję, jest to, że pomysł menedżera jest świetny - praktycznie dała każdemu „darmową kartę wyjścia ze spotkań”.
#13
+8
Spoike
2012-07-17 14:04:35 UTC
view on stackexchange narkive permalink

Będąc w podobnych sytuacjach, choć wprawdzie w krótszym czasie niż PO, mam tylko do powiedzenia o stanie jego sytuacji:

Najbardziej praktyczne i najprostsze rozwiązanie ...

... zamiast tego spróbuj rozpocząć spotkania o godzinie 11:00. Nie martw się, nie "poddajesz się". Zamiast tego przekierowujesz przepływ, podobnie jak zasady stojące za Aikido. Chodzi o to, aby zamiast tego skupić się na umożliwieniu zespołowi załatwiania ważnych rzeczy, ponieważ jest to kwestia nadrzędna, ponieważ naprawdę istnieje jeden poważny problem, który należy rozwiązać:

Zespół naprawdę NIE ma pojęcia co dzieje się z innymi działami i co NAPRAWDĘ muszą zrobić.

Wystąpienie zespołu o 9:30, co, przyznaję, nie jest wczesne, nie jest jednak rozwiązaniem tego problem. Próbowałeś i nie udało Ci się, więc przestań nalegać. Przestań walić głową w ceglaną ścianę. Moją jedyną wskazówką jest to, aby zawsze cenić komunikację nad arbitralnie ustalonymi spotkaniami.

Ponieważ inne działy zaczynają o 8, możesz wykorzystać to późne spotkanie zespołu na własną korzyść . Między 8 a 11 masz 3 godziny , aby pomóc swojemu zespołowi w działaniach związanych z zarządzaniem projektami, takich jak (bez określonej kolejności lub priorytetów):

  • Chodzenie na spotkania i zbieranie celów i wymagania innych działów
  • Dowiedz się, co zostało ukończone od wczoraj
  • Zarządzaj oczekiwaniami i zobowiązaniami z innymi działami dotyczącymi tego, co należy i można zrobić w ciągu dnia pracy
  • Dostarczaj dobre i złe wieści innym działom
  • Aktualizuj wszelkie plany istotne dla zespołu, jeśli są jakieś
  • Dowiedz się, jakie problemy z kodem i architekturą oprogramowania muszą mieć uwaga dzisiaj
  • Mówienie „NIE” prośbom, które nie przynoszą żadnej wartości biznesowej.
  • Przyjmij krytykę ze strony innych mieszkań i przeproś z pewnością, że problemy zostaną rozwiązane.
  • itp. (zawsze jest coś, czym należy się zająć)

I na koniec przed spotkaniem podsumuj krótką informację dla zespołu na temat tego, co się dzieje, aby dać mu trochę świadomości sytuacyjnej. Kiedy spotkanie zaczyna się o 11 i wszyscy są świeżo przygotowani do pracy, masz przygotowane informacje i protokół spotkania. Możesz zapisać brief i protokół ze spotkania w formie biuletynu i wysłać go w wiadomości e-mail jakiś czas po spotkaniu jako delikatne przypomnienie.

Podczas spotkania z zespołem potrzebujesz od nich dwóch rzeczy:

  • Poproś o oszacowania zadań do wykonania, zwłaszcza tych o wysokim priorytecie. Nie musi być precyzyjne, jak w minutach. Dzięki temu możesz znacznie wyraźniej decydować o zobowiązaniach i terminach z innymi działami. Jeśli nie potrafią oszacować zadania, poproś ich, aby wymyślili to w ciągu dnia lub w następnym.
  • Poproś o przeszkody lub jeśli potrzebują pomocy, zapisz to i zobacz, czy te problemy można naprawić i czy zostaną one naprawione.

Po pewnym czasie prawdopodobnie będziesz mógł stopniowo przechodzić do wcześniejszych spotkań. Ale początkowo walka pod prąd nie jest właściwą drogą i prowadzi tylko do jeszcze bardziej zaraźliwej kultury (w której jedynym sposobem naprawy jest wymiana całego zespołu). Jeśli są, jak mówisz, „primadonnami”, to Twoim prawdziwym zadaniem jest przekształcenie ich w niesamowite primadonny, które zapewniają wysoką jakość. Oczywiste jest, że Twój zespół miał i chce autonomii, więc zacznij wykorzystywać tę kulturę na korzyść celów swojej firmy.

Kiedy udało Ci się stworzyć niezawodny zespół, dzięki komunikacji, a nie przymusowi, możesz wyjść trzy godziny wcześniej niż wszyscy inni zespół, który wie, że wykonuje swoją pracę (ale nadal jest na dyżurze, jeśli bzdury trafią w wentylator). To jest zaufanie, na które możesz liczyć.

Myślę, że jest to bardziej dobra, solidna rada i dobre alternatywne podejście, które doprowadzi do sukcesu. Rolą ** menedżera / lidera zespołu ** jest izolowanie zespołu od hałasu i zamieszania oraz usuwanie przeszkód, które zmniejszają jego efektywność. Ta odpowiedź proponuje podejście do robienia tych wszystkich rzeczy!
#14
+6
pap
2012-04-26 17:26:40 UTC
view on stackexchange narkive permalink

Czytam komentarze i odpowiedzi i muszę przyznać, że jestem trochę oszołomiony. Odkąd ludzie przychodzą na czas „tracą korzyści”? Od kiedy flex-time nie musi przejmować się wpływem twoich działań na resztę zespołu i firmę?

Z tego, co przeczytałem w pytaniu i komentarzach, wynika, że ​​zachowanie członków jego zespołu jest dające się udowodnić szkodliwe i kosztowne dla firmy. Po próbie uzasadnienia i kompromisu sytuacja nie uległa poprawie (a przy okazji, 9.30 to nie wcześnie lub w jakikolwiek sposób nierozsądne).

Wyjaśnij swojemu zespołowi, że nie masz problem z elastycznym czasem pracy, ale pociąga to za sobą pewną osobistą odpowiedzialność, aby upewnić się, że Twoje elastyczne podejście nie wpływa na pracę innych (w Twoim zespole lub innych zespołach). Ponieważ Twój zespół wyraźnie zawodzi w zakresie odpowiedzialności, powiedziałbym, że skuteczne natychmiast i do odwołania, cały czas elastyczny musi zostać wcześniej zatwierdzony przez Ciebie. Niestawienie się na czas rano bez zgody lub rozsądnej wymówki (nie, budzik nie włączył się jest niedopuszczalne) spowoduje podjęcie działań dyscyplinarnych, takich jak wynagrodzenie za dokowanie lub urlop.

Jasno wyjaśnij, dlaczego tak się dzieje i co zmusiło Cię do podjęcia takich działań. Zwróć uwagę, że nie jest to coś, co chcesz zrobić, ale coś, do czego zostałeś zmuszony . Należy również pamiętać, że te restrykcyjne zasady mogą zostać zniesione, gdy sytuacja się poprawi.

** Komentarze zostały usunięte. ** Użyj komentarzy, aby poprawić odpowiedź lub poprosić o wyjaśnienie, a nie do ogólnej dyskusji. W przypadku dłuższej dyskusji użyj [czat].
#15
+6
anonymous
2012-04-24 00:35:26 UTC
view on stackexchange narkive permalink

Inni podnoszą wiele dobrych punktów na temat sposobu radzenia sobie z tą sytuacją; Jednak pod koniec dnia, jeśli harmonogram Twojej grupy przeszkadza innym w firmie, musisz rozwiązać problem i upewnić się, że wszystko przebiega sprawnie. Mając to na uwadze, musisz dowiedzieć się, kiedy inne grupy potrzebują niezawodnego dostępu do programistów i czy jest miejsce na elastyczność w tym harmonogramie. Jeśli inne grupy potrzebują dostępu do programistów, gdy przebywają w biurze w sposób nieprzewidywalny, wówczas podstawowy segment deweloperów musi upewnić się, że ta potrzeba zostanie uwzględniona. Jeśli to oznacza, że ​​niektórzy programiści muszą być w biurze w ustalonych okresach czasu, to tak właśnie jest.

Jeśli chodzi o przeniesienie programistów do jakiegoś harmonogramu stałej dostępności, najlepszym rozwiązaniem ma na celu maksymalne złagodzenie wszelkich „ciężkich godzin”. Na przykład, jeśli „godziny podstawowe” są od 11:00 do 15:00, możesz również upewnić się, że godziny podstawowe w piątek nie są obecne, a piątek jest prawdziwym dniem elastycznym. Ponieważ wtorek, środa i czwartek są tradycyjnie uważane za najbardziej produktywne dni tygodnia, możesz mieć możliwość zastosowania podstawowych godzin pracy w tych dniach i pozwolić, aby poniedziałek i piątek były również dniami w pełni elastycznymi.

Jeśli chodzi o zapewnienie przestrzegania godzin, jeśli kierunek spada z góry i jest zatwierdzony przez kierownictwo wyższego szczebla, ostatecznie programiści muszą go przestrzegać w ramach swojego zatrudnienia. Powinieneś zrobić wszystko, co w twojej mocy, aby upewnić się, że jest on wprowadzany stopniowo, a jeśli niektórzy programiści mają zapisany w umowie o pracę elastyczny czas pracy, należy się tym zająć (np. Zmieniając ich wynagrodzenie i świadczenia, dzierżawienie ich itp.); jednak w pewnym momencie będziesz musiał upewnić się, że polityka musi być przestrzegana, co może również wymagać oficjalnego dyscyplinowania pracowników. Podobnie, jeśli niektórzy zdecydują się odejść, warto spróbować sprawdzić, czy są skłonni zostać przy zmianach odszkodowań i świadczeń; jednak być może będziesz musiał zaakceptować utratę niektórych deweloperów.

Ostatecznie, jeśli Twoja praca wymaga wymuszenia zmiany kulturowej w grupie, aby sprostać potrzebom firmy, wtedy opcje będą do pewnego stopnia ograniczone. Możesz i powinieneś zrobić wszystko, aby złagodzić zmianę i wywołać jakiekolwiek kompromisy z innymi grupami, jak tylko możesz, ale ostatecznie będziesz musiał wymusić zmianę i zaakceptować wszelkie zmiany personalne, które mogą się z nią wiązać.

#16
+2
Karlson
2012-04-12 23:14:29 UTC
view on stackexchange narkive permalink

Wciąż istnieje wiele możliwości rozwiązania tego problemu, z których jednym byłaby zmiana roli pełnionej przez dział, na przykład: Jeśli pracujesz z programistami, możesz zmienić rolę dla określonego lub osób w ciągu tygodnia, aby pomagali innym działom, co wymaga 1 lub więcej, aby przyjść o 9 lub wcześniej, a jeśli to nie zadziała, zawsze możesz powołać się na klauzulę niesubordynacji, która normalnie jest obecna w każdym podręczniku pracy w USA . Osobiście zawsze byłem przeciwny stosowaniu tej klauzuli, która daje menedżerowi możliwość upomnienia, a nawet zwolnienia kogoś z przyczyn , ale w twoim przypadku może to być właściwe. Dlatego przejrzyj podręcznik pracownika i przedyskutuj go ze swoim przełożonym, jeśli masz jakieś, że będziesz to robić.

Podstawowa idea jest następująca:

  1. Ustalasz zasadę, że co najmniej 1-2 lub wszyscy ludzie powinni być w pracy o godzinie X.
  2. Jeśli członkowie Twojego zespołu nie mają uzasadnionego powodu, aby nie pojawiać się lub wytrwać w tej praktyce, jako menedżer powinieneś ich upomnieć i ewentualnie zwolnić.

Jako menedżer robi to, co ja opisany byłby ostatecznością , ale na podstawie tego, co opisujesz, być może doszedłeś do tego punktu. Istnieje wiele artykułów na temat niesubordynacji pracowników, które można znaleźć w Internecie, a to tylko kilka przykładów:

Oczywiście niefortunną konsekwencją może być wysoki wskaźnik rotacji w Twojej grupie, który źle odzwierciedlałby Ciebie jako menedżera, ale wymusi dyscyplinę i prawdopodobnie zabije morale w trakcie.

Powiedziawszy to wszystko, mam jedno pytanie: czy naprawdę potrzebujesz, aby Twój zespół był wcześniej niż przychodzi?

W odpowiedzi na Twoje pytanie - tak. Mamy wiele działów, z którymi regularnie współpracujemy. Działy te są w godzinach 8-9 i wychodzą między 4: 30-5: 30. Późny start i obiad to minimum - 1) Brak spotkań przed godziną 13:00 i 2) Tracenie pół dnia lub więcej, jeśli ktoś czeka na coś z naszego działu. Niesamowicie nieefektywne.
@JacobG klasyczną konsekwencją jest „Zostajesz do późna, aby dokończyć pracę, albo my dokujemy wakacje”. W odniesieniu do „wszystkich”, którzy uważają 9:30 za rozsądny czas rozpoczęcia: ja nie. Z drugiej strony pracuję do 8-9 w nocy, czasem później, a często po powrocie do domu. To są moje najbardziej produktywne godziny i nie umieszczałbym ich, gdybym miał wejść do drzwi punktualnie o 9:30 „albo inaczej” - stałbym się 9 do 17. Każdy zespół jest wyjątkowy i mam nadzieję, że rozważasz to w swojej ocenie ...
@Jacob - co to za zespół deweloperów? Czy jesteście tylko kolejną firmą utrzymującą wewnętrzną aplikację X, czy też ci wysokiej jakości programiści piszą solidny kod, który jest kręgosłupem Twojej firmy? Jeśli to drugie, niektórzy z nich spodziewający się, że będą mogli pracować do późna w domu i spóźniać się, nie wydają się zaskakujące. Sugerowałbym, żebyś spróbował to pogodzić. Twórcy jakości są * niewiarygodnie * trudni do znalezienia. I zawsze mają inne możliwości, jeśli obecna praca nie wychodzi.
@voretaq7 nie bierze tego źle, ale uważam, że jest to w dużej mierze kwestia przyzwyczajenia. Jeśli przyzwyczaisz się iść spać o 23:00 zamiast o 3:00 i wstawać o 7:00 zamiast o 9:30, zauważysz, że po chwili najbardziej produktywny będzie czas przed obiadem, ao 21:00 zaczyna być trochę senny. Ludzie się przystosowują.
@JacobG Dlaczego marnuje się pół dnia? Czy te inne zespoły przyjeżdżają o 8 rano, a potem nagle zdają sobie sprawę, że potrzebują czegoś od programisty?
@robertc Z pewnością zdarzają się sytuacje, w których inne zespoły przyjeżdżają o 8 i widzą, że jest coś, co wymaga uwagi programisty. Ale nie o to mi chodziło. Chodziło mi o to, że jeśli inny dział blokuje coś od zespołu programistów, blokada nie zostanie zwolniona przynajmniej w połowie dnia żądającego. Czasami jest to w porządku, a często jest to po prostu niewygodne.
@JacobG Ale przegapisz mój punkt widzenia, dlaczego czekają do 8 rano w dniu, w którym potrzebują czegoś, aby zdecydować się powiedzieć deweloperowi, że czegoś potrzebują?
@robertc Ponieważ nie wiedzą, że potrzebują czegoś do 8 rano. „Klient zadzwonił i napotkał ten problem…” „Wygląda na to, że dane są uszkodzone ...”
@JacobG Żaden z wymienionych przykładów nie jest zadaniami programistycznymi. Nawet jeśli programiści zajmują się obsługą klienta (jak sugerujesz), dlaczego wszyscy programiści muszą być w biurze o określonej godzinie, aby udzielać pomocy? Dlaczego obiecałeś klientom i innym działom konkretne czasy realizacji w kwestiach wsparcia, skoro nie masz dedykowanego personelu pomocniczego?
Pracowałem w kilku zespołach, które zostały złamane z powodu zasad, takich jak ta tutaj zasugerowana. Jedna rada: ludzie mogą zacząć przychodzić wcześnie na kilka tygodni. Ale potem zobaczysz, jak pracują dla konkurencji.
#17
+2
A quiet hum
2018-06-24 21:22:16 UTC
view on stackexchange narkive permalink

Zasadniczo musisz zdecydować, co jest ważniejsze, prawidłowo wykonać pracę lub siedzieć przy biurku przez 8 godzin o wyznaczonych porach?



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...