To pytanie zostało zainspirowane tym . Chociaż to drugie pytanie zostało uznane za zlokalizowane, uważam, że podstawowy problem jest czymś niezwykle powszechnym w naszej branży. Wiem, że są programiści, którzy to przeczytają i pomyślą, że to wymyślam, a następnie mogą odpowiedzieć, że wszyscy troszczą się o swoją pracę i chcą się uczyć, ale tylko patrząc na inne posty programistów SE ( przypadek ), Wiem, że to nie jest prawda.
Powiedzmy, że masz kogoś w zespole (a może większość), którego standardową procedurą jest kopiowanie / wklejanie i kto wierzy, że wszystko można rozwiązać, jeśli tylko dodasz wystarczającą liczbę wywołań funkcji i zmiennych. Ta osoba nigdy nie słyszała o TDD, SUCHYM lub SOLIDNYM, a poza 40 godzinami pracy, kiedy jest zajęta pracą, nigdy nie czytała ani jednej metodologii / praktyk / książki projektowej.
W przeszłości ja (i inni) pytałem, jak uczyć OOD . Ale teraz myślę, że to nie jest właściwe pytanie. Prawdziwe pytanie brzmi: w jaki sposób podchodzisz do takiej osoby / zespołu i sprawiasz, że ciekawi ich lepszy sposób działania? Jak inspirujesz ich do nauki? Bez tego wydaje się, że wszystkie nauczanie, spotkania, wykłady, dyskusje są bezużyteczne, jeśli są całkowicie szczęśliwi, wracając do biurka i robiąc to, co zawsze robili.
Pracuję z taką grupą ludzi. W rzeczywistości są to dość bystre osoby, ale nienawidzę, gdy słyszę: „Skończyłem kodowanie, wystarczy zrefaktoryzować i podzielić na wiele klas, aby uszczęśliwić DXM”. Nie refaktoryzują czystszego, czytelnego, łatwego do utrzymania kodu, ale tylko dlatego, że w przeciwnym razie zostaną skarceni. Wiem, że są w stanie się uczyć, wydaje się, że ogólny brak motywacji.
Kiedy dostarczam pracę, generalnie ma o wiele mniej błędów, a praca, którą posiadam, nigdy nie stała się potwornością 5000 linii. Inni komentowaliby: „Twój kod jest znacznie bardziej przejrzysty i czytelny niż nasze”, więc widzą różnicę. Ale jednocześnie czuję, że wierzą, że zarabiają 40 godzin bez względu na to, co robią, więc nie mają nic przeciwko temu, że spędzą 3 pełne dni na kontroli jakości, szukając błędu, którego nie powinien był wprowadzić pierwsze miejsce. Lub że modyfikacja jednej klasy zajmuje tydzień, ponieważ istnieje tak wiele zależności, że w końcu się dotykają. Jednak „może ta klasa powinna być napisana inaczej” nigdy nie wyskakuje.
Czy można coś zrobić w takich sytuacjach? Czy komuś się udało? A może najlepiej jest odizolować taki sposób myślenia od niekrytycznych części projektu i zminimalizować szkody?
UWAGA: Kiedy mówię „brak motywacji”. Nie sądzę, żeby brakowało motywacji do pracy lub dobrej pracy, ponieważ po prostu przestali się przejmować. Większość naszego zespołu jest wręcz przeciwnie. Z pewnością dbają o produkt. Mamy facetów, którzy będą pracować nocami i weekendami. Część, przez którą próbuję przejść, to ulepszone nawyki i umiejętności, w rzeczywistości nie musieliby tyle pracować. Wydaje mi się, że dzięki „40 godzinom” ten post brzmiał trochę zbyt negatywnie.
Odpowiedzi:
Znalazłeś sam powód: „Wiem, że są w stanie się uczyć, wydaje się, że istnieje ogólny brak motywacji”.
Są ludzie, którzy są pasjonatami swojej pracy. Są też inni, którzy czasami będąc wystarczająco kompetentni, pracują tylko dla pieniędzy . Znają się na rzeczy, ale nie lubią swojej pracy. Nie będą poświęcać dodatkowego czasu na dodatkowe refaktoryzowanie, aby kod był czytelny lub rozwiązywanie intrygującego problemu, gdy szybki i brzydki hack może wykonać zadanie.
Zjawisko to występuje w każdej pracy. Po prostu niektóre prace nie są wyjątkowo ekscytujące (czy widziałeś księgowego, który kocha swoją pracę i marzył o niej już jako dziecko?), Ale w programowaniu jest mnóstwo ludzi, którzy naprawdę kochają to, co robią (w przeciwnym razie Programmers.SE będzie całkiem pusty). Oznacza to, że jako namiętni programiści, którzy codziennie rozmawiają z innymi namiętnymi programistami, mamy większe szanse na zdziwienie widząc osobę, która programuje tylko dla pieniędzy.
Co możemy zrobić? Nie za dużo. We wszystkich przypadkach to nie do ciebie, ale do zasobów ludzkich wybierasz ludzi, którzy są naprawdę zmotywowani¹. I zwalniaj ludzi, którzy nie są.
Możesz spróbować zmotywować swoich kolegów, ale jest to niezwykle trudne. Jeśli dasz im książki do przeczytania, zwrócą je nieotwarte kilka tygodni później. Jeśli dasz im radę, nie będą słuchać, ponieważ ich to nie obchodzi².
Możesz:
Przekonuj swojego szefa, aby ustanowił w firmie szereg ścisłych zasad: wytyczne dotyczące stylu itp. Nie zmotywuje to tych ludzi do lepszej pracy, ale przynajmniej nie będzie w stanie zatwierdzić kodu źródłowego, który nie spełnia wymagań .
Pracuj nad wymaganiami, zwłaszcza wymaganiami niefunkcjonalnymi . Co z wymogiem, który mówi, że konkretny projekt musi zawierać mniej niż 5000 wierszy kodu IL (nie, nie mówię o bezsensownym LOC ) ³? Co z wymogiem uzyskania określonych wyników przy cykliczności złożoności lub sprzężeniu klas ?
Zwiększ liczbę godzin spędzanych w firmie na recenzowaniu kodu . Określ, co jest recenzowane: jeśli masz listę kontrolną, dodaj punkty związane z refaktoryzacją, czytelnością, czystymi i przydatnymi komentarzami itp. Jeśli nie masz listy kontrolnej, musisz.
Użyj [więcej] programowania par . Może to pomóc poprawić jakość kodu i zmotywować mniej zmotywowanych współpracowników.
Użyj systemu kompensacji podobnego do tego, który jest używany w Fog Creek.
¹ O to właśnie chodzi w rozmowach kwalifikacyjnych: przed zatrudnieniem zasoby ludzkie muszą zaspokoić nie tylko poziom techniczny, ale także motywację . Niestety niektóre firmy zapominają o drugiej części wywiadu i zatrudniają ludzi, którzy nie lubią programować zbytnio. Na szczęście w większości przypadków praca w tych firmach nigdy nie jest przyjemna, a test Joela rzadko przekracza 2.
² Naprawdę ich to nie obchodzi, nawet jeśli zarabiają mniej pieniędzy. Jestem bardzo blisko jednego z moich klientów (jestem freelancerem), który uważa, że jego praca polega na tworzeniu stron internetowych dla własnych klientów. Ma także projektanta. Wiele razy opowiadałem im o sposobach zwiększenia produktywności o 2 lub więcej. Gdyby po prostu zatrudnili kogoś kompetentnego, zwiększyliby swoje przychody o co najmniej 3. Ale mają wystarczająco dużo pieniędzy i nie dbają o jakość ani o ile kosztują nieświadomych klientów w porównaniu z kimś produktywnym.
³ Mam na myśli liczbę wierszy kodu IL widoczną w Code Metrics w Visual Studio , metrykę, która faktycznie coś znaczy. Prawdziwy LOC nie ma znaczenia i nie trzeba go mierzyć; to jedna z najgłupszych miar w historii. Egzekwowanie wierszy kodu IL oznacza, że programiści będą zmuszeni do faktoryzacji kodu, a nie tylko do zwinięcia dziesięciu wierszy kodu w jednym nieczytelnym wierszu.
źródło
Ten sposób myślenia jest rakiem w każdej drużynie i zabije motywację całego zespołu, jeśli nie zostanie natychmiast załatwiony. Mówię oczywiście o tym, że ze względu na staż pracy i / lub zasługi jesteś na stanowisku władzy technicznej, co daje ci siłę, aby wpływać i wprowadzać dobre praktyki w zespole.
To wszystko dobrze i dobrze, jednak gdyby twój zespół został wyraźnie sprzedany w ramach tych procesów, nie wyróżnialiby cię w takich oświadczeniach, które wyraźnie pokazują brak szacunku dla procesu i brak szacunku w tobie. Nadal postrzegają te najlepsze praktyki jako przeszkodę spowodowaną przez ciebie, a nie proces będący własnością zespołu, którego twój zespół będzie bronił według własnych zasług.
Wspomniałeś w poprzednich komentarzach, że inni członkowie zespołu rzeczywiście przestrzegają tych praktyk i standardów i stosują je prawidłowo. Najpierw skoncentruj się na wspieraniu ich, zapytaj, co działa, co nie działa, co im się podoba i co chcieliby zmienić. Jeśli to zrobisz i poważnie podchodzisz do ich opinii, będą oni postrzegać standardy zupełnie inaczej, jakby to była decyzja społeczności, a nie procedura przekazana im przez przełożonego.
Wspierasz wsparcie najlepszych praktyk i standardów, wskazując zespołowi, w jaki sposób poprawili proces tworzenia oprogramowania lub jego jakość.
Oddaj głos w sprawie do dyskusji i udokumentuj wyniki, najlepiej każda decyzja powinna być jednomyślna ze względu na legalność, ale jeśli masz do czynienia z twardymi przeszkodami, może to być niemożliwe i może po prostu zablokować każdą kwestię. W takiej sytuacji użyj większości głosów. Jeśli większość jest przeciwna twoim proponowanym standardom i praktykom, oznacza to, że już straciłeś pokój, po prostu zrezygnuj w tym momencie.
Będą właścicielami tych standardów i procedur i będą je egzekwować , abyś nie musiał. Jako lider technologiczny nie powinieneś ogłaszać dekretów i dekretów, to zły sposób na bycie liderem.
Gdy zespół poczuje się, jakby był właścicielem procedur, członkowie zespołu, którzy zaczną przypisywać ci określone procedury i najlepsze praktyki, uznają to za nieuprawnione. Twój zespół pomoże poprawić to nastawienie u innych.
źródło
Dobre pytanie! Myślę, że odpowiedź zależy od tego, dlaczego ludzie nie chcą doskonalić swoich umiejętności. Możliwe odpowiedzi to:
Najlepsze rozwiązanie naprawdę zależy od głównego problemu: na przykład formalne wytyczne dotyczące kodowania, metryki i recenzje mogą działać dla początkujących, ale ludzie w „złym postrzeganiu własnych umiejętności” - ludzie mogą walczyć z nimi lub grać w metrykę, ponieważ widzą jako negatywne biurokratyczne przeszkody w wykonywaniu ich pracy.
źródło
To jest to! To rzeczywiście prawdziwe pytanie.
Żeby dać trochę otuchy, po prostu nie mamy czasu na wiele formalnych szkoleń - ale czasami, jeśli to zrobię - nadal nie widzę światła. Należę również do firm, w których formalne szkolenie staje się procesem, ale i tak często jestem świadkiem, że ledwo uczą ich myślenia.
Pytanie, które zadaję im, nie polega na tym, jak ich uczyć - ale jak sprawić, by się uczyły? Różnica jest subtelna, ale to właśnie ją zmieni.
Nie wiem czy mam rację; ale często wierzę w okno dialogowe filmu Matrix - „To pytanie nas napędza!” Najważniejsze jest, aby zmusili ich do myślenia, aby zapytali dlaczego! I oczywiście większość osób, które myślą, że już wiedzą wszystko o niektórych wzorach projektowych, ponieważ uzyskały dobre oceny na studiach uniwersyteckich - są tam najtrudniejsze.
Jak możesz zadać im takie pytania? Moje ogólne podejście brzmi: „wrzucają je do stawu, jeśli chcesz, żeby nauczyły się pływać” . Zgadzam się, że ludzie mogą się nie zgadzać; i chętnie się z nimi nie zgadzam. Kiedy wrzucasz je do stawu - tak naprawdę nie uczą się pływać automatycznie; ale pobudza instynkt przetrwania, który skłania ich do myślenia - kiedy to nastąpi, naturalnie pomyślą, JAK i DLACZEGO.
Praktycznym przykładem, który daję ludziom, jest zaangażowanie ich w znacznie bardziej skomplikowany projekt niż to, na co liczyli, aby wziąć go w swoje ręce i pozwolić im stoczyć własną bitwę. Gdy zaczęli rozwikłać kod i trudno go prześledzić - zdajesz sobie sprawę, że zaczynają zadawać dobre pytania.
Może to zabrzmieć nieco ekstremistycznie, może to oznaczać marnowanie zasobów . I jestem pewien, że jest wielu innych, którzy udzielą mi rady, aby tego nie robić. Ale to zadziałało dla mnie!
Bez względu na to, jakie pakiety wynagrodzeń i tagi HR przypisujesz, nie rozwiąże to podstawowego problemu motywacyjnego . Bo ta jedyna droga polega na tym, że są kwestionowani; Jeśli iskrzysz w tym podstawowym ludzkim duchu - wszystko inne działa. Jeśli nie możesz, to luźna, luźna gra.
PS: Tak na marginesie, opublikowałem tutaj odpowiedź https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - i dostałem całe bzdury; przede wszystkim większość ludzi uważa, że firmy nie mogą sobie pozwolić na marnowanie zasobów! Jestem pewien, że ta odpowiedź może zostać potraktowana podobnie. Ale prawda jest taka, że zmuszanie ludzi do pracy i przekonanie ich, że wykonują dobrą pracę, jest przedmiotem psychologii człowieka w kwestii tego, jak stworzyć program kursu.
W każdym razie zadanie, które tutaj opisujesz, sprowadza się do rozpalenia wewnętrznej pasji dokonywania wielkich zmian. A większy system staje się trudniejszy. Rozpocznij od młodszych ludzi, którzy nadal mają ducha „ nie będę robić dobrze”, i rzuć wyzwanie status quo.
źródło
Jak zauważyłeś, jego motywacja. Nie myl ich, nie troszcząc się o niewiedzę. Oni wyraźnie wiedzą, co robić. Po prostu ich to nie obchodzi . Jeśli tak, to prawdziwe pytanie brzmi ... co robi twoje kierownictwo źle, co sprawia, że są tak niemotywowani? Czy jesteś najnowszym członkiem zespołu? Być może już to wszystko przeszli, ponieważ prowadziło to tylko do problemów z zarządzaniem. Więc po prostu trzymają się najmniejszej ilości pracy potrzebnej do utrzymania ich pracy, ponieważ nie sądzą, że na więcej pracy zareaguje pracodawca.
źródło
Wydaje mi się, że jest to problem z zarządzaniem i przywództwem - jeśli to twój zespół, możesz pracować nad tym, aby doskonalenie (osobiste i kodu) było podstawowym atrybutem twojego zespołu, pytanie brzmi: czy będzie ono wspierane przez twoje zarządzanie - ponieważ będziesz chciał robić rzeczy, które będą wymagały czasu (otrzymają wygraną netto, ponieważ powinieneś zmniejszyć nowy dług techniczny i spłacić istniejący dług techniczny).
Zapewniasz więc, że chcesz ulepszyć zespół, zgadzasz się, że to dobra rzecz (zespół jako całość pracuje nad poprawą jakości kodu), a następnie uruchamiasz program, aby to zrobić zdarza się - to brzmi tak łatwo ... Wiem, że nie!
Myślę, że składają się na to dwie części - edukacja i praktyki pracy.
Warto również przyjrzeć się Kanban (który jest postrzegany jako czynnik napędzający zmiany / ulepszenia).
Ostatnia myśl - jestem programistą zawodowym i chciałbym, aby mój zespół był taki sam, ale praca przez ponad 40 godzin tygodniowo nie jest tak naprawdę dobrą rzeczą, więc celem powinno być stworzenie zespołu, który wykona swoją pracę skutecznie i dobrze w normalnym tygodniu roboczym, a w związku z tym argumentem za poprawą praktyki pracy jest to, że bardziej prawdopodobne jest np .: dodanie testów jednostkowych w celu wykazania niepowodzenia, gdy (przed) naprawieniem błędu daje pewność, że tak jestnaprawiony; posiadanie serwera kompilacji daje pewność, że możesz w czysty sposób budować swoje rozwiązania - jeśli ta kompilacja generuje również pakiety wdrożeniowe, oznacza to, że wdrożenie jest znacznie uproszczone; Kod SOLID jest z definicji łatwiejszy do modyfikacji; i ogólnie rzecz biorąc, im mniej zaciągniesz dług techniczny, tym mniej będziesz musiał spłacić ...
źródło
Przypadkowo zająłem się programowaniem ~ 30 lat temu. Byłem zmotywowany do nauki podstawowych zasad inżynierii oprogramowania, ponieważ miałem za zadanie utrzymywać / wspierać kod innej osoby. W tych zadaniach nauczyłem się, jak czytnik kodów doświadcza kodu - jak wczuć się w czytnik kodów. Nie chciałem zadawać innym bólu mojego źle napisanego kodu!
Ta praktyka przypisywania nowych programistów do obsługi / obsługi kodu innych ludzi nie jest magiczną kulą i wydaje się motywować do uczenia się, jak tworzyć solidne kody częściej.
źródło