Dawanie instrukcji innym

Opiszcie sposoby przekazywania innym instrukcji co mają zrobić, w taki sposób żeby kurde to zrobili a nie wynajdywali wymówki że nie mogą. Oczywiście są jednostki takie że jak im jasno napisać "nie rób tego" to właśnie to zrobią i rżną głupa, ale mi chodzi o sposoby radzenia se ze zwykłą olewką... Chodzi mi o sytuacje że dajecie instrukcję komuś, on zrobi na odwal, a wy się potem zastanawiacie czy to nie wasza wina, może instrukcja była za mało jasna (jakby się nie mógł dopytać). Już wiem że lepiej wszystko dawać na piśmie, napisane jak dla idiotów... no ale zawsze ktoś wynajdzie większego idiotę

Czy ludzie dobrze wiedzą co tak naprawdę jest celem (projektu)? Mają ogólne pojęcie jak wszystkie elementy mają działać?

I smell micromanagement.

Miang napisał(a):

Opiszcie sposoby przekazywania innym instrukcji co mają zrobić, w taki sposób żeby kurde to zrobili a nie wynajdywali wymówki że nie mogą.
(...)
Już wiem że lepiej wszystko dawać na piśmie, napisane jak dla idiotów... no ale zawsze ktoś wynajdzie większego idiotę

Zacząłbym od nieuważania ludzi z zespołu za idiotów.

Może zacząć zatrudniać graczy A? Jak w tym modelu Guya Kawasaki. Gracze A to ludzie z wizją, highly driven. Gracze A zatrudniają innych graczy A, bo wiedzą że zrobią lepiej od nich samych. Tyle że graczy A jest mało więc trzeba się posiłkować graczami B, którzy zatrudniają graczy C, bo chcą gorszych od siebie by mogli ich kontrolować. Jedyna opcja być graczem A i unikać nadmiernego wzrostu.

Pokaż przełożonemu instrukcje i wyczyny współpracownika.
Niech on oceni.

IMO to szersza kwestia budowania kultury firmy i zaangażowania pracowników. Poza tym, kim Ty jesteś, żeby komuś kazać coś zrobić? :D

Po drugie, w wolnej chwili:

1. Wyznaczyć cel (CO), a nie sposób realizacji (JAK).
2. Wyjaśnić ograniczenia (DLACZEGO nie tak jak) i zaznaczyć, że od niego zależy przyszłość świata.
3. Ustalić z delikwentem jak zamierza zrobić taska?
4. Przywołać ustalenia i postawić trudne pytanie, dlaczego nie zrobił tak jak obiecał?

Chodzi mi o sytuacje że dajecie instrukcję komuś, on zrobi na odwal, a wy się potem zastanawiacie czy to nie wasza wina, może instrukcja była za mało jasna (jakby się nie mógł dopytać). Już wiem że lepiej wszystko dawać na piśmie, napisane jak dla idiotów... no ale zawsze ktoś wynajdzie większego idiotę

Zależy od sytuacji, ale obstawiam, że ktoś czegoś nie zrozumiał albo nie umiał zrobić lepiej.

Pytanie tylko,

• czy zostali zatrudnieni słabi programiści (czyli problem z procesem rekrutacyjnym, że takie osoby w ogóle zostały zatrudnione),
• czy problem leży w słabo zdefiniowanych zadaniach (niby można dopytać, ale nie zawsze to rozwiązuje problem. Tak jak zdarzają się niekomunikatywni juniorzy/regularowie, tak i zdarzają się niekomunikatywni seniorzy i PMowie - zapytasz, a i tak nie potrafią wyjaśnić jasno).
• a może problem leży w problemach technicznych np. kupę legacy kodu, które sprawia, że zadania, które wydawały się proste do zrobienia, stają się wielkim wyzwaniem. W takich wypadkach po prostu nie da się zrobić czegoś dobrze, jeśli przez całe miesiące projekt nie był robiony dobrze, tylko jest to jakieś spaghetti.
• może ktoś był zawalony robotą i nie mógł przeznaczyć zbyt wiele czasu na dane zadanie?
• a może same zadania nie mają wiele sensu, a może powinnaś sama coś zrobić, zamiast stosować micromanagement ("dawanie instrukcji innym" kojarzy mi się z pracą na jakimś magazynie, gdzie kierownik wzywa i prosi, żeby przenieść towar z palety i pozamiatać. Wydawało mi się, że programiści raczej pracują skuteczniej w systemie "wymagań do spełnienia" czy "problemów do rozwiązania" niż odbębniania instrukcji)

a może jeszcze inaczej. W sumie bez kontekstu ciężko wyrokować.

LukeJL napisał(a)

Zależy od sytuacji, ale obstawiam, że ktoś czegoś nie zrozumiał albo nie umiał zrobić lepiej.

W niektórych przypadkach tak, ale niektóre to raczej olewactwo, podejście a może mi to klepną. Oczywiście w wielu przypadkach nie było problemu z dogadaniem się

Pytanie tylko,

• czy zostali zatrudnieni słabi programiści (czyli problem z procesem rekrutacyjnym, że takie osoby w ogóle zostały zatrudnione),

to też, a problem z rekrutacją owszem był

• czy problem leży w słabo zdefiniowanych zadaniach (niby można dopytać, ale nie zawsze to rozwiązuje problem. Tak jak zdarzają się niekomunikatywni juniorzy/regularowie, tak i zdarzają się niekomunikatywni seniorzy i PMowie - zapytasz, a i tak nie potrafią wyjaśnić jasno).
• a może problem leży w problemach technicznych np. kupę legacy kodu, które sprawia, że zadania, które wydawały się proste do zrobienia, stają się wielkim wyzwaniem. W takich wypadkach po prostu nie da się zrobić czegoś dobrze, jeśli przez całe miesiące projekt nie był robiony dobrze, tylko jest to jakieś spaghetti.

w tworzonych od początku też

• może ktoś był zawalony robotą i nie mógł przeznaczyć zbyt wiele czasu na dane zadanie?
• a może same zadania nie mają wiele sensu, a może powinnaś sama coś zrobić, zamiast stosować micromanagement ("dawanie instrukcji innym" kojarzy mi się z pracą na jakimś magazynie, gdzie kierownik wzywa i prosi, żeby przenieść towar z palety i pozamiatać. Wydawało mi się, że programiści raczej pracują skuteczniej w systemie "wymagań do spełnienia" czy "problemów do rozwiązania" niż odbębniania instrukcji)

"określanie warunków brzegowych" brzmi lepiej?

Według mnie, to zależy od typu jaka to jest instrukcja:

A) Instrukcja w normalnym tickecie Jirowym, task z opisem co należy zrobić. Jeśli kwestia jest taka, że tworzymy taska i nim się jakiś programista zajmie za kilka dni bądź później, to należy podać kontekst zadania, o jaki obszar chodzi, konkretne Acceptance Criteria, jeśli kwestia się tyczy UI to dobrze załączyć screeny. Jeśli chodzi o buga, to kroki do zreprodukowania. Programista w zespole powinien mieć pewną świadomość i założenia - np że używacie IntelliJ, że przed commitem trzeba sformatować kod, że trzeba dodać unit testy i test integracyjny, że aplikacja zespołu robi to i tamto. Natomiast pisząc opis takiego taska, należy mieć świadomość, że nie wszystko, co mamy w głowie, ma w głowie także druga osoba - niby oczywista oczywistość, a większość ludzi nie ma tej świadomości.

B) Instrukcja w normalnym tickecie Jirowym, task z opisem co należy zrobić. Jeśli task powstał jako skutek wspólnej dyskusji zakończonej godzinę temu, i kolega z zespołu właśnie nad nim pracuje i poprosił tylko o stworzenie taska, to można być trochę mniej szczegółowym, niż w przypadku A) (chociaż idealnie by było trzymać zasady z punktu powyższego)

C) Instrukcja stawiania środowiska dla nowego developera - tutaj kroki muszą być jeszcze bardziej szczegółowe, włączając w to podanie konkretnych ścieżek na komputerze, zmienne środowiskowe, no po prostu kliknięcie po kliknięciu. Dobrze jest dodać sporo screenshotów.*1.

Co zrobić jak ktoś przyjdzie z zapytaniem jak zrobić krok 4, bo mu nie zadziałało?
Na spokojnie pomóc

Kiedy można się już trochę zirytować?
Kiedy po raz czwarty (nie drugi i nie trzeci) pyta o to samo

Ja w pierwszym projekcie w robocie gdzie dowodziłem dostałem pod siebie gościa który... ehhh niby regular a pytał się jak napisać ifa. Ja mu dawałem robote przez godzine wyjaśniałem mu co ma dokładnie zrobić przez cały dzień, po czym siadałem do swojej pracy, dzień później zaczynałem wcześniej niż on kończyłem jego robotę bo zazwyczaj nic nie zrobił, po czym on przychodził i pętelka zaczynała się znowu. po 1 lub 2 tygodniach opisałem wszystko górze, kilka dni później już gościa w firmie nie było :D

DYSKUSJA NAD ZADANIEM

Jeśli w zespole masz mniej doświadczone osoby to warto się nad nimi pochylić i przedstawić nie tylko techniczne wymaganie, ale również podkreślić kontekst i wskazać jaką rolę odgrywa wybrana funkcjonalność. Wydaje mi się, że tutaj najwięcej może pomóc zdefiniowanie user story.

Następnie warto dać czas na przeczytanie tej historyjki, na przemyślenie jej i potem warto usiąść i przedyskutować wspólnie wymagania na ten temat. Warto uzupełnić user-story o dodatkowe szczegóły precyzujące co znaczy, że zadanie jest ukończone

Ponadto warto w taką rozmowę zaangażować również osobę testującą, ponieważ ona również może wiele wnieść do tej dyskusji.

DAJ OD SIEBIE WIĘCEJ MAX FEEDBACKU

Jeśli osoba otrzyma dłuższe zadania to rób przeglądy. Na początku możesz pytać jaki ma plan na to zadanie, potem można sprawdzać co zrobiła od środka i to powtarzać co zadanie, aż w końcu osoba wdroży się w system.

DZIEL I RZĄDŹ

Jeśli zadania są za trudne i jeśli osoby nadal mają trudność z rozwiązywaniem zadań. To może trudniejsze zadania podziel na mniejsze. Dzieleniem takiego zadania powinna zajmować się osoba, która ma najwięcej doświadczenia technicznego i wiedzy o produkcie.

Jesli trudne zadanie nie da się podzielić, to w danym przypadku raczej potrzebny będzie ktoś z większym skillem albo ...

PROGRAMOWANIE W PARACH

Gdy 2 pary oczu patrzą na ten sam problem jest większa szansa, że dojdzie do burzy mózgów :D Jest większa szansa na to, że kod zostanie napisany z dobrymi praktykami, jest większa szansa, że testy będą porządne.

Programowanie w parach jest nie tylko w przypadku trudny zadań, ale i tych żmudnych. Wtedy są większe szanse na to, że praca pójdzie szybciej, a i też są większe szanse na to, aby aby wymyśleć efektywne obejście całego problemu.

WPROWADŹ AUTOMATYCZNĄ KONTROLĘ

Zamiast pracować nad wybraną osobą, by zmieniła podejście, by się bardziej starała. Wprowadź na pokład narzędzia, które będą kontrolować jakość kodu. Warto pisać testy, warto mieć CI. Wtedy praca nad idzie w las, gdy osoba się zwolni.

ALE..

Czasem to może wystarczyć, to są tylko inicjatywy jakie wynikają od strony managera/kierownika. Większą moc ma inicjatywa od strony pracowników:

DRUŻYNA GWIAZD

• Jeśli w zespole masz dwóch kozaków, którzy trzymają wysoki poziom i którzy nie zajmują się pilnowaniem juniorów, lecz trzaskaniem kodu w najskuteczniejszy sposób. To ich charakter pracy z czasem zacznie budzić podziw u słabszych programistów. Ci słabsi zaczną się drapać w głowę jak oni to robią. SAMI od siebie zaczną się starać by ich praca była coraz bliższa poziomowi tych speców - to działa tylko w tą stronę.

Największy problem tego podejścia jest taki, ze drużyna gwiazd musi być odpowiednio opłacana, bo nikt nie będzie robił jak wół jeśli kasa taka sama jak w firmie w której prawie nic nie trzeba robić. Częściowo opłacanie można zmniejszyć, dając ludziom więcej przestrzeni, tworząc najlepsze warunki do działania (i tu nie chodzi o playstation, a o problemy na miarę ich zainteresowań), zobacz kolejny punkt on też w to się wpasowuje.

KRAINA CZARÓW

Programista też człowiek, a pracę jaką wykonuje nie raz przyprawia o ból głowy. Programiści mają problem z wyrażaniem wielu potrzeb, dlatego wzbudzisz w człowieku większą chęć do starań jeśli zrozumiesz jego potrzeby. Sama kasa to na dłuższą metę to najsłabszy motywator.

Jak wprowadzisz do pracy trochę nowsze technologie, projekty z ciekawymi problemami to ludzie sami z siebie będą poświęcać pracy więcej zaangażowania, bo takie rzeczy porywają programistów do tego stopnia, że czasem aż trudno zasnąć. To jest gigantyczna różnica w stosunku do podejścia gdzie po 13:00 osoba odlicza czas do wyjścia, o 15:00 już się nie chce lub pisanie mailów, a o 16:55 to po prostu się znika i zapomina jak najszybciej o całej pracy.

BRAK ROZMYTEJ ODPOWIEDZIALNOŚCI

W firmach często wspólnie się planuje, wspólnie robi się taski, ale ostatecznie to w takim szanownym gronie osoby dające ciała nie są rozliczane ze swojej pracy. I tu najmniej chodzi o te słabe osoby, lecz o to, że taki filtr przysłania to co wnoszą osoby, które się starają. Może programiści słabo komunikują się, ale większość z nich ma ego i każdy lubi jak dostrzega się ich wkład w pracy. Człowiek chce czuć, że w pracy nie tylko chodzi o to, by uprawiac jakiś słoneczny patrol czy gaszenie pożarów, ale o to by przekraczać pewne własne granice.

Gdybyś powierzył ludziom obszar, dał im więcej swobody technologicznej i kazał strzec najlepiej jak potrafią wybranych partii kodu to ludzie chroniliby tych obszarów, i mało kto pozwoliłby na dziadowy kod w ich regionie - bo to byłaby ujma, tak jak psia kupa, która leży 2-3 dni na wycieraczce :D

Jak wydajesz polecenia, a współpracownicy nie robią tego, co miałaś na myśli, to możesz zacząć mówić im, co masz na myśli. To może pomóc.

Już wiem że lepiej wszystko dawać na piśmie, napisane jak dla idiotów... no ale zawsze ktoś wynajdzie większego idiotę

Traktowanie jak idiotę bywa odwzajemnianie

Jak cię ludzie nie słuchają to się nie bierz za zarządzanie i dowodzenie :D Projekty zazwyczaj trwają krócej niż kariera zawodowa, do góry są pchani zazwyczaj najbardziej niekompetentni więc żebyś się nie zdziwił jak za kilka lat ktoś utrąci twoją karierę bo miał nieprzyjemność słuchać twoich poleceń.

Ciszej jedziesz, dalej zajedziesz.

Ja na przykład zacząłem robić na odwal się jak zatrudnili typa który zarabiał dwa razy więcej od mnie, a umiał mniej, bo zatrudnili go do mojego zespołu, a widełki były na stronie z ofertami pracy it. Typ zaczął się modnie ubierać, mieć hajs na wszystko xD Więc zacząłem tak tnąć w bambino jeszcze przez kolejny rok specjalnie, aż się potem sam zwolnilem.

Przypomniało mi sie jeszcze coś jak daję linka do instrukcji po angielsku (do framworka, komponentu czy czegoś) to i tak lepiej kluczowe punkty napisać po polsku, mimo że teoretycznie osoba do której pisze angielski zna

@arek24: Czyli mówisz, że dowiedziałeś się, że ktoś (w Twoim odczuciu) słabszy od Ciebie zarabia lepiej i postanowiłeś coś udowodnić robiąc źle swoją pracę? Czy tylko mi się to wydaje dziwne? Pomijając fakt, że to dziecinne to co chciałeś tym osiągnąć? Zakładam, że do pracy chodzisz dla własnej korzyści (jak chyba wszyscy). Przecież tym sposobem nie zarobiłeś więcej, straciłeś rok nie rozwijając się, większość osób, która z Tobą współpracowała zapewne się podskórnie denerwowała i zapewne nigdy Cię nigdzie nie poleci... A zyskałeś co? Chyba tylko własną satysfakcję na zasadzie "ale im pokazałem".

Tak na prawdę pewnie nic im nie pokazałeś - po prostu uznali, że jesteś kiepskim zawodnikiem i pomijali Cię przy ewentualnych podwyżkach itp. Jeśli Twoje skille na rynku były warte więcej to trzeba było uciekać. Jeśli były tyle warte ile Ci płacili, a to kolega wyrwał coś ekstra, to trzeba było coś spróbować na tym ugrać dla siebie. A tak to w sumie nie wiem... Mam nadzieję, że chociaż się dobrze bawiłeś tym protestem, którego nikt nie zauważył ;-)
Chyba już wiem czemu HR zadają takie dziwne pytania na rozmowach.

Co do tematu to zakładając, że osoby są w stanie zrobić to czego się od nich oczekuje (w sensie maja wymagane umiejętności) to:

• opisywać dobrze taski i dobrze definiować dod
• rozmawiając prosić aby osoba opowiedziała czego się od niej oczekuje - w ten sposób Ty się upewnisz, że dobrze przeazałaś informację, a osoba jest zmuszona do jej przeczytania/przemyślenia.
• poprosić o plan wykonania zadania, choćby słownie
• podkreślać co ma znaczenie w danym tasku
• po wykonaniu zrobić CR i pokazać co było źle i odesłać od poprawki
• sytuacje często zwracanych tasków wyciągać na rozmowach o finansach / rozmowach okresowych

I przede wszystkim konsekwencja - jeśli sprawdza się co 10-te zadanie to oznacza, że 9 na 10 kiepsko wykonanych zadań przechodzi czyli w percepcji takie osoby robi ona wszystko dobrze, a ty się nagle czepiasz.

Oczywiście trzeba się zastanowić na ile problem jest w Tobie, firmie, filozofii, a na ile w pracownikach. Myślę, że warto ten temat poruszyć na rozmowach okresowych z podwładnymi - jak dobrze poprowadzisz taką rozmowę to może sami Ci powiedzą czemu tak robią jak robią.

Zawsze staraj się wyciągnąć deklarację, że ktoś coś i na kiedy. Wtedy masz podstawę do dalszej konstruktywnej rozmowy - możesz spytać, czemu czegoś nie zrobił i wyciągnąć wnioski. Z doświadczenia wiem, że ludzie, którzy mogą coś zrobić a tego nie robią są rzadkością. Zazwyczaj ludzie nie robią zadań, bo:
a) organizacja pracy leży
b) są zawaleni robotą
c) nie wiedzą jak coś zrobić

Pkt. a) nie oznacza, że to wina konkretnego człowieka. Organizacja może leżeć tak po prostu. Ale może być tak, że trzeba komuś pomóc w organizacji.
Pkt. b) oznacza, że organizacja leży na sto procent.
Pkt. c) - takiej osobie trzeba poświęcić trochę czasu.

Jeśli jednak trafisz na typa, który ewidentnie olewa rzeczy to szukaj haków i postaraj się go zwolnić. Wiem, że pozornie to niefajne, ale pamiętaj, że zachowanie typa:

• jest niefajne wobec ciebie
• jest niefajne wobec reszty zespołu

https://www.empik.com/extreme-ownership-willink-jocko-babin-leif,p1157085481,ksiazka-p

Jocko Willink jest jednym z autorów który udostępnił dużo informacji na temat przywództwa i integracji z przywódcą, dyscyplinie, nie-opierdalaningu-się, itp.