Niedawno, zupełnie przypadkowo, z inicjatywy jednego dobrego człowieka, zrodził się pomysł — do każdego artykułu dołączać krótkie streszczenie. Nie aneks, nie zaproszenie, a właśnie krótkie streszczenie. Takie, żeby można było w ogóle nie czytać artykułu.
Spróbowałem, i bardzo mi się to spodobało. Ale to nie ważne — najważniejsze, że spodobało się czytelnikom. Zaczęli wracać ci, którzy dawno przestali czytać, oznaczając mnie grafomanem. A inny dobry człowiek zasugerował, aby napisać krótkie streszczenie dla każdego starego artykułu. Zgodziłem się i teraz, przy okazji, piszę te króciutkie teksty. Nazwałem je shortami.
Z przyjemnością przedstawiam kilka takich shortów, dotyczących kilku publikacji. Może znajdziecie w nich coś przydatnego dla siebie.
Kot zdechł, ogon wylizany
Spotkania bardzo często kończą się bez rezultatu. Zebrali się, pogadali, rozeszli.
Wyniki, czyli produkty spotkania — to decyzje. A tych zwykle brakuje. A jeśli są, to nie zawsze dobrej jakości.
Jeśli spotkanie jest ograniczone czasowo, a decyzja musi być podjęta, to ona (decyzja) bywa niskiej jakości.
Jeśli spotkanie nie jest ograniczone czasowo i trwa aż do podjęcia decyzji, to podejmuje się jakąkolwiek decyzję, byle tylko zakończyć spotkanie.
Jeśli decyzja została wymyślona na spotkaniu, to zostanie podjęta — po prostu dlatego, że mózg ceni to, co sam wymyślił.
Zrozumienie niskiej jakości decyzji przyjdzie później, ale wtedy będzie już za późno.
Aby podjąć skuteczną decyzję, lepiej nie uczestniczyć w dyskusji, a milcząco obserwować.
Po pierwsze, mózg nie będzie zajęty wymyślaniem odpowiedzi.
Po drugie, nie ma presji, aby podjąć decyzję.
Po zakończeniu spotkania można spokojnie przemyśleć i podjąć decyzję. Będzie bardziej jakościowa.
Kluczowe: na spotkaniu milczeć i słuchać. Aby otoczenie się nie martwiło, można powiedzieć, że to świadoma postawa.
→
Ukryte pasożyty
Zasadniczo są dwa podejścia do stawiania zadań i kontroli ich wykonania: pasożytnicze i symbiotyczne.
Podejście symbiotyczne — zrobić tak, aby zadanie zostało zrealizowane.
Podejście pasożytnicze — zrobić tak, aby zadanie NIE zostało zrealizowane.
Podejście symbiotyczne jest proste i bezpośrednie, ale trudne do wdrożenia. Dlatego występuje rzadko.
Zadanie stawiane jest tak, aby wszystko było jasne — cele, zasoby i ograniczenia.
Kontrola jest przeprowadzana w taki sposób, aby zadanie zostało dokładnie rozwiązane.
Podejście symbiotyczne polega na pozostawieniu części odpowiedzialności (co więcej, większej) za rozwiązanie zadania na zlecającym.
Podejście pasożytnicze jest zawiłe i wymyślone, ale proste w realizacji. Dlatego jest często spotykane.
Zadanie jest formułowane w taki sposób, aby nic nie było jasne. Im mniej jest jasne, tym lepiej.
Kontrolę najlepiej jest w ogóle nie przeprowadzać.
Zlecający nie ponosi żadnej odpowiedzialności, cała "małpa" przenoszona jest na barki wykonawcy.
Celem podejścia pasożytniczego jest manipulacja, ego, samopotwierdzenie. Dlatego często występuje w pracy mentorów z początkującymi pracownikami.
Lepiej, oczywiście, podejście symbiotyczne.
→
Pomiar vs Iluzje
Jeśli oceniasz proces i wyniki swojej działalności bez pomiarów, zawsze będziesz się mylić.
Ocena bez cyfr zależy od nastroju. Zły nastrój — wydaje się, że źle pracujesz. Dobry nastrój — przeciwnie.
Można w ten sposób siedzieć przez tydzień i źle pracować, a w piątek выдаć "na górze" wynik, i będzie się wydawało, że cały tydzień był udany.
Zasadniczo istnieją dwa typy metryk: ilościowe i alternatywne (bardziej znane programistom jako Boole).
"Zadanie wykonane na czas" — to Boole. To to samo, co „Element jest odpowiedni” (alternatywny znak jakości, gdy nie można mierzyć w cyfrach).
"Pracujemy dobrze", "Realizujemy plan", "Jestem świetny" — to też Boole.
Na ocenach typu Boole trudno zbudować proces zarządzania. Zaleca się jak najszybsze przejście do ilościowych metryk.
Boole generuje biurokrację i formalizm. Na przykład, aby zrealizować zadania w terminie, można zwiększyć terminy, wymyślać sobie zadania, prowadzić IBZ.
Aby zarządzać na podstawie wskaźników Boole, trzeba poświęcić dużo czasu — na spotkania, analizę itp. Ponieważ informacji jest zbyt mało.
Zaleca się mierzenie zarówno procesu, jak i wyniku. Wówczas obraz będzie najpełniejszy.
Dla programistów zaleca się metodę „Planowanie przez Poker” z Scrum.
→
To Sparta
Załóżmy, że jesteś programistą, a przyniesiono ci poważne zadanie. A ty uważasz, że zadania nie trzeba rozwiązywać — jest głupie, szkodliwe.
Typowe zachowanie w takiej sytuacji: przenieść zadanie do publicznej przestrzeni. Wysłać do akceptacji kierownikowi, uruchomić projekt wewnętrzny, zarejestrować w systemie itd.
W tym miejscu wszystko się załamuje. Osoba, która przyniosła zadanie, nie chce, aby uznano ją za głupka. A skoro wyszli do publicznej przestrzeni, będzie się bronić.
Osobie zależy na zachowaniu twarzy, w sensie politycznym. Najważniejsze w polityce — nigdy nie przyznawać się do swoich błędów. Można nic nie robić, ale najważniejsze — nie mieć uznanych błędów.
Osoba włoży wszelkie siły, aby dowieść, że programista to złoczyńca, idiota, przeciwnik zmian. A programista i tak będzie musiał rozwiązać zadanie.
W niektórych przypadkach osoba zaaranżuje wszystko tak, aby programista w ogóle nie rozwiązał zadania. Wtedy osoba będzie „biała”, a programista całkowicie „czarny” (i stawiał opór, i nie poradził sobie ostatecznie).
Jest kilka rozwiązań.
Pierwsze — zostać programistą biznesowym, zrozumieć pokrewne obszary i samodzielnie określić, co i jak należy zautomatyzować.
Drugie — artykuł Głównego ds. zmian. Na przykład, dyrektorem ds. rozwoju.
Trzecie — nie stawiać oporu i po prostu robić to, co mówią.
Czwarte — Droga Sparty, szybka eliminacja rozwiązań. Bardziej znane jako fail fast, fail cheap (szybko ponieść porażkę, tanio ponieść porażkę).
Najważniejsze — nie wprowadzać publiczności. Powiedz osobie — nie traćmy dużo czasu, zróbmy prototyp i zobaczmy, czy rozwiązanie jest wykonalne, czy nie.
Na prototyp potrzeba niewiele czasu. W przypadku sukcesu obie strony dostaną swoje — i normalne rozwiązanie, i punkty polityczne.
W przypadku niepowodzenia nikt nie ucierpi. No i osoba będzie lepiej traktować programistę.
→
Surrogaty
Biznes nie lubi 1C i jej produktów, programistów webowych, SMK, księgowości, ekonomistów, projektów rozwoju, Scrum, TQM, controllingu, KPI i systemów motywacyjnych.
Biznes ceni wzrost rentowności dzięki automatyzacji, zwiększenie obrotów poprzez marketing internetowy, poprawę jakości produktów, prosty i czytelny obraz działalności w liczbach, prognozy stanu firmy, rzeczywiste zwiększenie efektywności, przyspieszenie realizacji projektów od 2 do 4 razy, wielokrotne zwiększenie zysków oraz redukcję zapasów, precyzyjny system zarządzania, jasny i zrozumiały system oceny sytuacji w biznesie oraz system oceny pracy, umożliwiający zwolnienie połowy menedżerów.
Biznes dąży do osiągania celów. Biznes nie toleruje substytutów.
Substytut to sytuacja, kiedy proszono o osiągnięcie celu biznesowego, a w zamian uzyskano projekt automatyzacji, stronę internetową, stos papierów, niezrozumiałych pracowników lub nieczytelne raporty.
Substytut to sytuacja, w której cel po drodze zostaje zamieniony na środek do jego osiągnięcia. A o celu wszyscy zapominają.
Produkcja substytutów opiera się na trzech filarach: formalizmie, stopniowości i wzajemnym wsparciu.
Formalizm to przenoszenie celów na papier z dekompozycją. A w rzeczywistości jest to zwrócenie uwagi z dużego celu na drobne szczegóły. O celu już nikt nie pamięta – wszyscy dyskutują o detalach.
Stopniowość to wolne tempo przechodzenia od celów do środków. Na początku cel jest czasami jeszcze omawiany. Ale stopniowo, krok po kroku, wymienia się go coraz rzadziej, aż zleceniodawca sam o nim zapomni, tonąc w detalach.
Wzajemne wsparcie polega na tym, że wszyscy wykonawcy działają w podobny sposób. Nie ma ani jednego automatyzatora, który naprawdę zwiększa rentowność. Dlatego zleceniodawca ma niewiele możliwości.
Co robić?
Unikać substytutów i pierwszego kroku na drodze do ich stworzenia: formalizmu. Przynajmniej w projektach wewnętrznych. Wyznaczaj cel i ciągle rozmawiaj z wykonawcą o nim. O zakresach, zasobach, planach itd. – również. Ale najważniejsze – o celu.
W przeciwnym razie uwaga z pewnością zostanie odwrócona i znów otrzymasz substytut.
→
Władimir Kliczko
Jest taki bokser – Władimir Kliczko. Ma on szczególną cechę – ciągłe stosowanie jab.
Jab nieustannie utrzymuje przeciwnika w napięciu, męczy go.
Kluczowe cechy jaba Kliczki: jego prostota wykonania (relatywna, oczywiście) i niezmienność.
Wielu autorów mówi o tym, że proste, ale regularnie wykonywane działania mogą przynieść wiele korzyści.
Postanowiłem spróbować. Zrobiłem prosty system monitorowania – jakie zadania wykonałem dzisiaj.
To się wydarzyło w fabryce. Zadania realizowałem w czasie lunchu (nie jadam lunchu), czyli 1 godzinę dziennie. Robiłem to, czego inni nie robili (mówią, że to prowadzi do sukcesu).
Konfigurowałem testy samouczącego się systemu, wymyślałem pomysły na rozwój, realizowałem cudze pomysły na rozwój, ustalałem automatyczne zadania, refaktoryzowałem i optymalizowałem kod.
Codziennie – dowolne zadanie z tej listy. Zrealizowałem jedno zadanie – świetnie. Można zrobić kilka.
Obserwacje prowadziłem przez 3 miesiące. W tym czasie przeprowadziłem 30 testów, wymyśliłem 200 pomysłów, zrealizowałem 80 cudzych pomysłów, stworzyłem zautomatyzowane procesy w dwóch działach, dokonałem trzech świetnych optymalizacji.
Fajnie, nie? To „przy okazji”. Wszystkim polecam.
→
Elastyczny substytut
Termin „Scrum” odnosi się co najmniej do dwóch bytów: filozofii i ramowego podejścia.
Filozofia, czyli podejście do pracy, została opisana w książce Jeffa Sutherland.
Ramowka, czyli algorytm działania, została opisana w dokumencie zatytułowanym Scrum Guide.
Filozofia przekształciła się w ramy, ponieważ autorzy filozofii chcieli na niej zarobić (jak sami mówią).
Ramówka jest znacznie uproszczona w porównaniu do filozofii. Główna różnica polega na uproszczeniu, a dokładniej mówiąc, na braku celu.
Celem filozofii jest przyspieszenie osiągania wyników. I to wielokrotnie. W książce są przykłady przyspieszenia nawet ośmiokrotnego.
Celem ramowego podejścia jest to, abyście mieli Scrum. Tam jest wyraźnie napisane: jeżeli działacie zgodnie z instrukcją – macie Scrum, jeżeli łamiecie instrukcję – nie macie Scrum.
Ramówka nie zakłada przyspieszenia osiągania wyników w ogóle.
Osoby uczące lub wdrażające Scrum pracują z ramami. Opowiadają i wdrażają algorytm, który nie prowadzi do żadnych wyników, poza stwierdzeniem „mamy teraz Scrum”.
Istota jest jasna. Sprzedaż filozofii jest bardzo trudna. Ramówka – łatwiejsza.
Ramówka to produkt. Jak przystało, przeszła „opakowanie”. Jest prosty, zrozumiały, ma wsparcie i wielu specjalistów. Czy to nie przypomina niczego?
Wszystko w porządku, poza wynikiem – tego nie ma.
Jeśli klient nie zna filozofii Scrum, wdrożenie ramowego podejścia będzie mu całkowicie odpowiadać.
Jeśli klient zna filozofię Scrum, to wdrożenie tego frameworka przyniesie mu rozczarowanie — nie będzie żadnego przyspieszenia osiągania wyników.
Będzie fajnie, modnie, nowocześnie, ale nie zostaną osiągnięte żadne cele biznesowe (z wyjątkiem wykorzystania budżetu na coś nowego).
Co robić? Należy zgłębiać filozofię Scrum. Jest ona oparta na japońskiej filozofii zarządzania jakością, której istotą są pomiary i niekończące się doskonalenie.
Niestety, wymaga to dużo myślenia, eksperymentowania, obserwowania i, niestety, pracy. Jeśli to Ci nie odpowiada — weź framework.
→
Źródło: habr.com
