Niedawno zupełnie przez przypadek, za namową pewnej dobrej osoby, zrodził się pomysł - aby do każdego artykułu dołączyć krótkie streszczenie. Nie streszczenie, nie zachęta, ale podsumowanie. Tak, że w ogóle nie da się przeczytać artykułu.
Spróbowałem i naprawdę mi się podobało. Ale to nie ma znaczenia - najważniejsze, że czytelnikom się podobało. Ci, którzy dawno przestali czytać, zaczęli wracać, piętnując mnie jako grafomana. I kolejna dobra osoba poradziła mi, abym napisał streszczenie dla każdego starego artykułu. Zgodziłam się i teraz, od niechcenia, piszę te opowiadania. Nazywał je szortami.
Na podstawie kilku publikacji zwracam uwagę na kilka takich krótkich spodenek. Być może znajdziesz coś przydatnego dla siebie.
Kot zdechł, ogon odpadł
Spotkania bardzo często kończą się bez rezultatów. Spotkali się, porozmawiali i każdy poszedł w swoją stronę.
Wyniki lub produkty spotkania są decyzjami. Dlatego zazwyczaj ich nie ma. A jeśli już, to nie zawsze jest dobrej jakości.
Jeśli spotkanie jest ograniczone w czasie i trzeba podjąć decyzję, to jest ona (decyzja) niskiej jakości.
Jeżeli spotkanie nie jest ograniczone w czasie i trwa do czasu podjęcia decyzji, wówczas jakakolwiek decyzja zostaje podjęta do czasu zakończenia spotkania.
Jeśli decyzja zostanie podjęta na spotkaniu, zostanie zaakceptowana - po prostu dlatego, że mózg docenia to, co wymyślił.
Zrozumienie złej jakości rozwiązania przyjdzie później, ale będzie już za późno.
Aby podjąć skuteczną decyzję, lepiej nie brać udziału w dyskusji, ale po cichu obserwować.
Po pierwsze, mózg nie będzie zajęty szukaniem odpowiedzi.
Po drugie, nie ma presji na podjęcie decyzji.
Po zakończeniu spotkania możesz spokojnie je przemyśleć i podjąć decyzję. Będzie wyższej jakości.
Kluczem jest milczenie i słuchanie podczas spotkania. Aby inni się nie martwili, powiedz, że jest to świadoma postawa.
→
Ukryte pasożyty
Zasadniczo istnieją dwa podejścia do wyznaczania celów i monitorowania ich realizacji: pasożytnicze i symbiotyczne.
Podejście symbiotyczne ma na celu zapewnienie rozwiązania problemu.
Podejście pasożytnicze polega na upewnieniu się, że problem NIE został rozwiązany.
Podejście symbiotyczne jest proste i proste, ale trudne do wdrożenia. Dlatego jest to rzadkie.
Zadanie jest tak postawione, żeby wszystko było jasne – cele, zasoby i ograniczenia.
Kontrola jest przeprowadzana tak, aby problem został dokładnie rozwiązany.
Podejście symbiotyczne polega na pozostawieniu części odpowiedzialności (co więcej) za rozwiązanie problemu reżyserowi.
Podejście pasożytnicze jest ozdobne i sprytne, ale łatwe do wdrożenia. Dlatego zdarza się to często.
Zadanie jest tak postawione, że nic nie jest jasne. Im mniej jasne, tym lepiej.
Wskazane jest, aby w ogóle nie sprawować kontroli.
Na kierowniku zadania nie ma żadnej odpowiedzialności, cała „małpa” zostaje przeszczepiona na szyję performera.
Cel podejścia pasożytniczego: manipulacja, niepokój emocjonalny, samoafirmacja. Dlatego często można go spotkać w pracy mentorów z początkującymi pracownikami.
Lepsze jest oczywiście podejście symbiotyczne.
→
Wymiary kontra iluzje
Jeśli oceniasz proces i wyniki swoich działań bez pomiarów, zawsze będziesz popełniać błędy.
Ocena bez liczb zależy od Twojego nastroju. Zły nastrój - będzie się wydawać, że nie pracujesz dobrze. Dobry nastrój jest odwrotny.
W ten sposób możesz przez tydzień siedzieć i słabo pracować, a w piątek możesz osiągnąć doskonałe wyniki i mieć wrażenie, że cały tydzień minął dobrze.
Zasadniczo istnieją dwa rodzaje metryk: ilościowe i alternatywne (lepiej znane programistom jako Boolean).
„Zadanie wykonane na czas” to wartość logiczna. To to samo, co „Część jest dobra” (alternatywny znak jakości, gdy nie można jej zmierzyć liczbami).
„Dobrze nam się pracuje”, „Realizujemy plan”, „Jestem świetny” - także logiczne.
Trudno jest skonstruować proces sterowania przy użyciu szacunków typu Boole'a. Zaleca się jak najszybsze przejście na wskaźniki ilościowe.
Wartość logiczna generuje biurokrację i formalizm. Na przykład terminowe wykonanie zadań można osiągnąć poprzez zwiększanie terminów, wymyślanie zadań dla siebie i wdrażanie IBD.
Aby zarządzać w oparciu o wskaźniki logiczne, trzeba poświęcić dużo czasu - na spotkania, analizy itp. Bo jest za mało informacji.
Zaleca się mierzenie zarówno procesu, jak i wyniku. Wtedy obraz będzie najbardziej kompletny.
Programistom zalecana jest metoda „Planning Poker” ze Scruma.
→
To jest Sparta
Załóżmy, że jesteś programistą i dostajesz poważne zadanie. I myślisz, że nie ma potrzeby rozwiązywać problemu - to głupie, szkodliwe.
Typowe zachowanie w takiej sytuacji: wyświetlenie zadania w polu publicznym. Wyślij go do akceptacji przełożonemu, uruchom wewnętrzny projekt, zarejestruj go w systemie itp.
Tutaj wszystko się psuje. Osoba, która przyniosła zadanie, nie chce być uważana za głupca. A kiedy już wejdą na pole publiczne, będą się bronić.
Ważne jest, aby człowiek nie stracił twarzy, w sensie politycznym. Najważniejsze w polityce jest to, aby nigdy nie przyznawać się do swoich błędów. Nie musisz nic robić, ale najważniejsze, żeby nie przyznać się do błędów.
Człowiek zrobi wszystko, żeby udowodnić, że programista to złoczyńca, idiota, przeciwnik zmian. A programista nadal będzie musiał rozwiązać problem.
W niektórych przypadkach osoba tak wszystko ułoży, aby programista w ogóle nie rozwiązał problemu. Wtedy osoba będzie „biała”, a programista będzie absolutnie „czarny” (opierał się i ostatecznie poniósł porażkę).
Istnieje kilka rozwiązań.
Pierwszym z nich jest zostać programistą biznesowym, zrozumieć powiązane obszary i samodzielnie określić, co i jak tam zautomatyzować.
Drugi to artykuł Szef Przemian. Na przykład dyrektor ds. rozwoju.
Po trzecie, nie pokazuj się i po prostu rób, co ci każą.
Po czwarte – Droga Sparty, szybkie odrzucanie decyzji. Lepiej znany jako porażka szybka, porażka tania.
Najważniejsze, aby nie angażować reklamy. Powiedz tej osobie – nie marnujmy dużo czasu, zróbmy prototyp i zobaczmy, czy rozwiązanie jest wykonalne, czy nie.
Prototyp zajmie trochę czasu. Jeśli im się uda, obaj otrzymają swoje – normalną decyzję i punkty polityczne.
Jeśli się nie uda, nikt nie ucierpi. Cóż, ludzie będą lepiej traktować programistę.
→
Surogaty
Biznes nie lubi 1C i jego produktów, twórców stron internetowych, QMS, księgowości, ekonomistów, projektów rozwojowych, Scrum, TOS, kontrolingu, KPI i systemów motywacyjnych.
Firmy uwielbiają zwiększoną rentowność dzięki automatyzacji, zwiększone obroty z promocji w Internecie, lepszą jakość produktów, prosty i zrozumiały obraz biznesu w liczbach, prognozy kondycji firmy, realny wzrost wydajności, szybszą realizację projektów 2-4 razy, wielokrotny wzrost zysków i zmniejszenie zapasów, trafny system zarządzania, jasny i zrozumiały system oceny stanu rzeczy w biznesie, system oceny pracy pozwalający zwolnić połowę menedżerów.
Biznes kocha osiągać cele biznesowe. Biznes nie lubi surogatów.
Surogat ma miejsce wtedy, gdy prosiłeś o osiągnięcie celu biznesowego, a otrzymałeś projekt automatyzacji, stronę internetową, stertę papierów, niezrozumiałą kadrę pracowników lub nieczytelne raporty z foot wrapów.
Surogat ma miejsce wtedy, gdy cel na drodze zostaje zastąpiony środkiem do osiągnięcia. I wszyscy zapomnieli o golu.
Produkcja surogatów opiera się na trzech filarach: formalizmie, stopniowości i wzajemnej odpowiedzialności.
Formalizm to przeniesienie celów na papier wraz z rozkładem. Ale w istocie - przeniesienie uwagi z wielkiego celu na drobne szczegóły. Nikt już nie pamięta gola, wszyscy dyskutują o szczegółach.
Gradualizm to niska prędkość przejścia od celów do środków. Na początku cel jest nadal czasami omawiany. Ale stopniowo, krok po kroku, mówi się o tym coraz rzadziej. Dopóki klient sam o tym nie zapomni, tonąc w szczegółach.
Wzajemna odpowiedzialność polega na tym, że wszyscy wykonawcy działają w przybliżeniu tak samo. Nie ma jednego narzędzia automatyzacji, które faktycznie zwiększa zyski. Dlatego klient tak naprawdę nie ma wyboru.
Co robić?
Unikaj surogatów i pierwszego kroku w kierunku ich stworzenia: formalizmu. Przynajmniej w projektach wewnętrznych. Wyznacz sobie cel i stale rozmawiaj o nim z wykonawcą. O skali, zasobach, planach itp. - To samo. Ale najważniejsze jest osiągnięcie celu.
W przeciwnym razie skupienie uwagi z pewnością się zmieni i otrzymasz innego surogata.
→
Jab Kliczko
Jest taki bokser – Władimir Kliczko. Ma osobliwość - ciągłe używanie dźgnięcia. Cóż, to znaczy. bardziej konsekwentny niż inni bokserzy.
Dźgnięcie stale trzyma przeciwnika w napięciu i wyczerpuje go.
Kluczowe cechy dźgnięcia Kliczki: łatwość wykonania (oczywiście względna) i spójność.
Wielu autorów twierdzi, że stale wykonywane, przydatne, ale proste działania mogą przynieść wiele korzyści.
Postanowiłem też spróbować. Zrobiłem prosty system księgowy - jakie dźgnięcia zrobiłem dzisiaj.
Stało się to w fabryce. Jadłem w porze lunchu (nie jem lunchu), tj. 1 godzina dziennie. Zrobił to, czego inni nie robią (mówią, że to prowadzi do sukcesu).
Układałem testy systemu samouczącego się, wymyślałem pomysły na rozwój, wdrażałem pomysły innych osób na rozwój, ustawiałem autozadania, refaktoryzowałem i optymalizowałem kod.
Codziennie - dowolne zadanie z tej listy. Wykonałeś jedno zadanie - przystojny. Możliwych jest kilka.
Obserwacje prowadzono przez 3 miesiące. W tym czasie przeprowadziłem 30 kontroli, wpadłem na 200 pomysłów, wdrożyłem 80 pomysłów innych osób, zbudowałem zautomatyzowane procesy dla dwóch działów i przeprowadziłem trzy fajne optymalizacje.
Fajny. Cóż, to jest „pomiędzy”. Polecam każdemu.
→
Elastyczny surogat
Słowo „Scrum” odnosi się do co najmniej dwóch bytów: filozofii i frameworku.
Filozofię, czyli podejście do pracy, opisuje książka Jeffa Sutherlanda.
Ramy, tj. algorytm działań opisany jest w dokumencie zwanym Scrum Guide.
Filozofia stała się ramą, ponieważ autorzy filozofii chcieli na niej zarobić (według własnych słów).
Ramy są znacznie uproszczone w porównaniu do filozofii. Najważniejsze, że cel został uproszczony, a raczej wyrzucony.
Cel filozofii: przyspieszenie osiągnięcia rezultatów. Co więcej, czasami. Książka zawiera przykłady przyspieszenia 8-krotnego.
Cel frameworku: żebyś miał Scruma. Jest tam napisane: jeśli postępujesz zgodnie z instrukcjami, masz Scruma; jeśli łamiesz instrukcje, nie masz Scruma.
Ramy w ogóle nie zakładają przyspieszenia osiągania wyników.
Osoby uczące lub wdrażające Scrum pracują z frameworkiem. Opowiadają i wdrażają algorytm, który nie prowadzi do żadnych innych rezultatów niż „mamy teraz Scruma”.
Sprawa jest jasna. Filozofię bardzo trudno sprzedać. Ramy są prostsze.
Framework jest produktem. Zgodnie z oczekiwaniami przeszedł „pakowanie”. To proste, zrozumiałe, jest wsparcie i wielu specjalistów. Nic Ci nie przypomina?
Wszystko jest w porządku, z wyjątkiem wyniku - nie ma żadnego.
Jeśli klient nie jest zaznajomiony z filozofią Scrum, to będzie w miarę zadowolony z wdrożenia frameworka.
Jeśli klient zna filozofię Scrum, to będzie rozczarowany wdrożeniem frameworka – nie będzie przyspieszenia w osiąganiu wyników.
Będzie fajnie, modnie, nowocześnie, ale nie zostaną osiągnięte żadne cele biznesowe (poza wydaniem budżetu na „coś nowego”).
Co powinienem zrobić? Przestudiuj filozofię Scrum. Opiera się na japońskiej filozofii zarządzania jakością, której istotą jest: pomiar i nieustanne doskonalenie.
Niestety trzeba dużo myśleć, eksperymentować, obserwować i niestety pracować. Jeśli to Ci nie odpowiada, weź framework.
→
Źródło: www.habr.com