Jak sprawić, by ludzie przestali jeździć rowerem (koncentrując się na trywialnościach)?

Zadanie polegało na nauczaniu innych zespołów nowej bazy kodu, ale ciągle napotyka problem. Ilekroć wchodzę do kodeksu z ludźmi, nie docieramy zbyt daleko, dopóki całe ćwiczenie nie przekształci się w trening rowerowy (członkowie organizacji przykładają nieproporcjonalną wagę do trywialnych problemów). Ponieważ nie znają bazy kodu, ale myślą, że muszą pomóc ją ulepszyć, skupiają się na rzeczach, które mogą zrozumieć:

Why is that named that? _{(2 minuty na wyjaśnienie, dlaczego tak się nazywa, ponad 10 minut debatowania nad nową nazwą)}

Why is that an abstract base class rather than an interface? _{(2 minuty na wyjaśnienie, ponad 10 minut omawiających względne zalety tej decyzji)}

...i tak dalej. Nie zrozumcie mnie źle - dobre nazwiska i dobry, spójny projekt są ważne, ale nigdy nie rozmawiamy o tym, co właściwie robi kod ani jak zaprojektowano system w jakikolwiek znaczący sposób. Zrobiłem sędziowanie na spotkaniach, aby wyciągnąć ludzi z tych stycznych, ale ich nie ma - rozproszony przez to, jaki kod będzie / powinien być, gdy ich banalna trywialność zostanie naprawiona, i brakuje im szerszego obrazu.

Więc próbujemy ponownie później (lub z inną częścią bazy kodu), a ponieważ ludzie nie mieli wystarczającej wiedzy, aby przezwyciężyć efekt rowerowego roweru, powtarza się.

Próbowałem mniejszych grup, większych grup, kodu, tablicy, diagramów Visio, gigantycznych ścian tekstu, pozwalając im po prostu argumentować to na śmierć, natychmiast zmniejszając argumenty ... niektóre pomagają bardziej niż inne, ale nic nie działa . Do diabła, próbowałem nawet wytłumaczyć to innym osobom z mojego zespołu, ponieważ myślałem, że być może źle mówię.

Jak zatem edukować innych programistów na tyle, aby przestali się skupiać na trywialnościach i mogli znacząco przyczynić się do projektowania?

Myślę, że problemem jest zadanie: „Zadanie polegało na nauczeniu innych zespołów nowej bazy kodu”.

Otrzymałeś niewłaściwą pracę, a może źle zinterpretowałeś otrzymaną pracę.

Prezentując się na poziomie kodu, zapraszasz do myślenia na poziomie kodu.

Zacznij od poziomu systemu i przedstaw projekt oraz dokonane wybory projektowe. Nie zezwalaj na dłuższą dyskusję: nie recenzujesz jej. Pozwól na pytania: chcesz, aby rozumieli system. Jeśli ludzie „zrobiliby to inaczej”, w porządku. Może się zgadzam. Albo nie. Ale idź dalej. Tak jest teraz.

Gdy przejdziesz do poziomu kodu, będziesz już mieć je zalane terminologią systemu. Nazwy (zakładam) będą miały sens. To samo co powyżej: brak przedłużonej dyskusji, pytania do zrozumienia. Pójść dalej.

Teraz ustaw niektóre problemy klasowe do rozwiązania. Jak możemy ulepszyć X? Wybierz coś, co nie jest trywialne, a które „idzie w parze” z projektem systemu i pracuj nad tym, co chcesz zmienić. Powinni teraz uzyskać uzasadnienie systemu. Wybierz inne ulepszenie, które może uszkodzić system, jeśli zostanie wykonane nieprawidłowo, i pokaż, jak można to zrobić poprawnie. To powinna być dla nich chwila Ah Ha . Niektórzy mogą cię nawet pobić!

To trudny koncert, zwłaszcza po fałszywym starcie, który miałeś. Wygląda na to, że zainwestowałeś już dużo czasu i wysiłku, a może jest trochę ja w stosunku do nich. „Odwal się i zacznij od nowa. Zakładamy, że są to mądrzy ludzie. Podejmij wyzwanie myślenia na wyższym poziomie. I rozbić grupy, które już istnieją, wybierając różne przekroje zespołów dla nowych sesji.

„Zaparkuj je”. Na początku lekcji wyjaśnij, co chcesz omówić, i jasno wyjaśnij, co jest uważane za nie na temat. Jeśli zostanie zadane pytanie, które jest wyraźnie OT, powiedz tak i przejdź dalej. Jeśli wrócą, napisz pytanie na tablicy (jest to bardzo ważne) do późniejszej dyskusji i przejdź dalej. Pod koniec lekcji, kiedy są w swoim czasie, a nie twoim, obserwuj, jak szybko te pytania zostaną rozwiązane.

Ustaw poprawnie oczekiwania i bądź uczciwy, otwarty i otwarty.

Upewnij się, że Twoje cele są otwarte i przejrzyste.

Rozpocznij dyskusje od widoku wysokiego poziomu promowanego przez andy256 (+1), ale upewnij się również, że podałeś swoje cele, np.

„... gdy patrzymy na ten problem, upewnijmy się, że nie skupiamy się na x, y i z. Upewnijmy się również, że nie patrzymy na szczegóły implementacji, takie jak a, b, c lub szczegóły trywialne takie jak j, k, l. Wiem, że w kodzie musi być wiele szczegółów i szczegółów, które można rozwiązać, ulepszyć lub uczynić bardziej standardowymi, ale najpierw spróbujmy sprawdzić, co naprawdę osiąga na wyższym poziomie „

Jak zatem edukować innych programistów na tyle, aby przestali się skupiać na trywialnościach i mogli znacząco przyczynić się do projektowania?

Po pierwsze, nie myśl o ich obawach jako o „trywialnościach” lub „rowerach”. To są osądzające słowa i obraźliwe. Ich obawy są aktualne. Nie są w tej chwili ważne.

Kluczem do każdego dobrego spotkania jest, aby każdy wiedział:

• dlaczego masz spotkanie i
• co masz nadzieję z tego wyciągnąć
• jak długo to powinno trwać

Podaj te rzeczy z góry, wyraźnie i wyjaśnij cele.

Na przykład możesz powiedzieć: „To spotkanie ma na celu zapoznanie cię z pakietem Foo i jego wykorzystaniem w naszym module raportowania. Moim celem jest, abyś zrozumiał wystarczająco dużo o Foo, abyś mógł pracować nad projektem Bar Reports w przyszłym tygodniu. Chciałbym, żebyśmy skończyli w ciągu następnych 90 minut. ”

Następnie, gdy pojawia się temat, może wyglądać tak:

Nowa osoba: „Dlaczego FooWidget jest implementowany jako wzór fasady?”

Ty: „Myślę, że to dlatego, że (krótkie wyjaśnienie decyzji projektowej)” lub „Nie wiem”.

Jeśli odpowiedź wystarczy, to świetnie. Jeśli nie, i kontynuuje:

NP: „Nie sądzisz, że lepiej byłoby to zrobić jako singleton?”

Ty: „Naprawdę o tym nie myślałem, ale chciałbym kontynuować wyjaśnianie, jak działa FooWidget”.

NP: „Ale jeśli zrobimy to jako singleton, możemy…”

Ty: „Przepraszam, że przeszkadzam, ale muszę skupić się na tym, jak działa FooWidget. To spotkanie jest zaplanowane tylko do godziny 11:00 i mamy wiele do przejścia. Dyskusja na temat projektu będzie musiała poczekać jeszcze raz . ”

Po przejściu tego raz lub dwa razy możesz skrócić to do „To jest poza zakresem tego spotkania”.

Pamiętaj, że jesteś nie mówiąc: „To głupi się martwić o” lub „To nie ma znaczenia” czy „Shut up” lub „Jesteś zbyt nowy mieć wejście.” Po prostu koncentrujesz się na tym, co należy zrobić i na zaangażowanym czasie.

W niektórych organizacjach nigdy nie będziesz w stanie tego osiągnąć. Wiele organizacji ceni polityczną walkę i wspinanie się po drabinie bardziej niż zdolności intelektualne, pracowitość i lojalność. A dlaczego by nie mieli. Wspinaczka po drabinie stawia ludzi na pozycjach władzy, pozwala im poprawić swoje życie osobiste dzięki bardziej dyskrecjonalnym dochodom i naprawdę nigdy nie staje się przestarzała.

Porównaj to sprzeczanie się z władzą z faktycznym rozwiązywaniem problemów, abstrakcyjnym myśleniem i podejmowaniem decyzji w trudnych kwestiach, które mogą być odpowiedzialne za konsekwencje później, a wielu pracowników jest ciężko po stronie próbowania jazdy na rowerze jak najwięcej.

Jedyna rada, którą sugeruję, to wyjaśnienie, w miarę możliwości, w kontekście organizacji, że osobisty los tych uczestników zależy od ich zrozumienia, wkładu i wysiłku w kierunku rzeczywistego problemu, który próbujesz rozwiązać. Jeśli taka jest architektura korporacyjna, wyrażona w tej bazie-błędów i to wszystko zawodzi, to tyle. Wyjaśnij im, że muszą wnieść znaczący znaczący wkład w tej sprawie . Żadna inna przypadkowość, która okazuje się być wkurzoną przez kogoś w starszym wieku lub kogoś innego i zdobędzie dla nich niezłe punkty za porozumienie ze wspomnianym kimś starszym.

Jest to często trudne, ponieważ starszy ktoś zwykle nie rozumie technologii, nie jest zainteresowany i niestety kontroluje surowce: czas pracownika; wynajem i ogień, polityka sal konferencyjnych, promocje itp. itd. poważnie, i tak dalej.

To, co nazywasz bikeshedding, nazwałbym przekształceniem czyjegoś przepływu myśli w nasz. Omawiając nazwy, wzorce, rozumieją kod na własnych warunkach i nie ma sposobu, aby temu zapobiec, jest to potrzebne.

Poza tym nie ma potrzeby przechodzenia do bardzo szczegółowego przewodnika po całej bazie kodu, ponieważ szczegóły zostaną zapomniane na długo zanim zaczną nad tym pracować.

Opierając się na tych dwóch pomysłach, sugerowałbym rozbicie bazy kodu na jednostki, a uczniów na dwie osoby. Dla każdej jednostki kodu każda grupa będzie miała, powiedzmy, 25 minut ( oczywiście zależy od LOC ), aby móc przejść 5-10 minutowy kod dla innych. Trzy minuty pytań i powtórz z następną jednostką. Wyjaśnij to słowo kluczowe; muszą upewnić się, że inni to wszystko zrozumieli.

Będziesz tam tylko po to, aby wymusić czas, nie ma tematów i kontrola jednostki została wystarczająco zrozumiana. Będą aktorami ich nauki i będą bardziej skupieni na wyjaśnianiu innym niż na rowerach.

Możesz wymagać od nich ręcznie narysowanego schematu jednostki kodowej, który zostanie skopiowany i zachowany w dokumentach udostępnionych przez zespół, aby mieli w przyszłości coś namacalnego. Dobrze jest też zakotwiczyć wspomnienia.

Przepraszam, jeśli już próbowałeś ...

Czy próbowałeś robić lekcje wstępne, nad którymi ludzie osobno się przyglądają?

Twórz krótkie filmy lub prezentacje, które wyjaśniają treść, sposób działania kodu, lub w zasadzie wszystko, czego chcesz ich nauczyć w formacie, w którym muszą na nie spojrzeć i dowiedzieć się, jakich informacji chcesz nauczyć.

Następnie używasz sesji zespołowych do omawiania problemów związanych z treścią. Musisz wyraźnie określić, że sesje zespołu służą wyłącznie do omawiania i rozwiązywania problemów związanych z treścią.

Jeśli zapewnisz lekcje ludziom indywidualnie, możesz być w stanie uniknąć tego innego problemu społecznego, w którym jedna sprawa może stać się głosem grupy jako zbiorowości i odwrócić uwagę od faktycznego celu lekcji.

Najpierw naucz ich projektowania bazy kodu, poprowadź ich wokół architektury, ZANIM zaczniesz szukać konkretnych przykładów. W ten sposób mogą zobaczyć, jak przykłady kodu, na które patrzysz, pasują do większego obrazu. Pomyśl o strukturze programu treningowego. I uwzględnij motywację biznesową projektu.

Spędziłem kilka lat szkoląc innych programistów i nigdy nie wdałem się w kod, zanim pokazałem im, jak system się ze sobą łączy. Potem, kiedy kazałem im robić ćwiczenia kodu w ramach, pytania były uporządkowane i tematyczne.