When projects fail in a company, management tries to understand what went wrong. Often, first impressions are that we don’t have skilled enough people or our methodology is not well implemented. When we ask a consulting company, they, in most cases, conduct ASIS analysis then sell a new methodology implementation or trainings. Nothing or little will change. The challenge is in the system of work. System of work consists of such things as structure, hierarchy, goals, multitasking, team dysfunctions, planning horizons, etc.. All of this and more influence our projects every day. Although systems of work are around us, it is not visible. That is the challenge.

„Leaders are missing the solution because they are not looking at the systemsstructuresprocesses and polices that affect day-to-day behaviorsThey arefocused on the symptoms instead of the principles that promote trust.”                       

Covey „Speed of trust”

 

Don’t Change the Methodology. Change the System! (part 1)

Don’t Change the Methodology. Change the System!

24. lutego 2013 · 2 komentarze · Categories: Better Way, Lean, Tesis · Tags: , ,

Miałem przyjemność brać udział w spotkaniu ITSMF w Poznaniu. Przyjemność spotęgowana tym, że spotkanie odbyło się w siedzibie Grupy Allegro oraz prelegenci to moi koledzy z GA. Nie będę pisał całej relacji. To zrobią inni.

Podczas prelekcji Przemka Wysoty na temat zarządzania zmianą padło pytanie czy istnieje w GA taka forma jak CAB (Change Advisory Board). W odpowiedzi usłyszeliśmy, że tak naprawdę to nie istnieje i wynika to ze zwinności (agile) organizacji. Otwartość na zmiany, szybkość, dostosowanie się do potrzeb firmy. Od słowa do słowa doszło do szybkiego skrótu myślowego, że agile tzn. brak kontroli. To mi przypomniało historie naszego biura zarządzania portfelem projektów, które też już nie istnieje. Czy to znaczy, że nie zarządzamy portfelem lub nie mamy change managementu w IT? Nic bardziej mylnego.

Na prawie wszystkich konferencjach poświęconych nowoczesnej organizacji, zwinności padają słowa: nie potrzebujemy managerów, ale potrzebujemy management. Nie potrzebujemy testerów, ale potrzebujemy testowanie itd.

W wielu przypadkach to sobie ciężko wyobrazić, jednak jest sens w tych słowach. Jest to bardzo ciężkie do osiągnięcia dla tradycyjnych firm. Transformacja jest bardzo ciężka, o ile w ogóle możliwa. Pocieszające jest to, że istnieją na świecie nowe organizacje, które opierają się na nowym DNA – przykładem jest Valve.

Brak CAB’u lub biura zarządzania portfelem jest łatwiejszym zastosowaniem powyższego. Nie potrzebujemy CAB’u, ale potrzebujemy kontroli zmian. Nie potrzebujemy biura zarządzania portfelem, ale potrzebujemy zarządzania portfelem.

To jest łatwiej sobie wyobrazić pod warunkiem zmian systemowych i bardziej wywodzi się z lean niż agile.

W krótkim zdaniu można powiedzieć, że biuro zarządzania portfelem jest odpowiedzialne za priorytetyzowanie projektów zgodnie z kierunkami strategicznymi firmy i za ich wprowadzenie do realizacji.  Jeszcze krócej, jest odpowiedzialne za to, aby zlecać do realizacji projekty, które są najbardziej wartościowe (najważniejsze) dla organizacji. Tu powstaje pytanie, czy rzeczywiście potrzebujemy do tego osobnego biura zarządzania portfelem? Przecież to jest odpowiedzialność każdej osoby w firmie, aby robić to co najważniejsze dla firmy, a już na pewno odpowiedzialność managerów. Zatem oddajmy managerom tą odpowiedzialność. Niech będzie to dokładnie nazwana odpowiedzialność za decyzje o tym co firma realizuje. Co jest najważniejsze, a co jest mniej ważne. Rozumiem, że nie każdy to potrafi. Nie jest to jednak powód, aby nie podejmować decyzji i się uczyć. Błędy są rzeczą ludzką i dzięki nim możemy wiele się nauczyć. Jak ktoś od początku nie jest do tego gotowy to dajmy czas na naukę i zdobycie kompetencji. Nie jest tutaj rozwiązaniem zatrudnianie kogoś innego, kto zrobi za nas robotę i podejmie decyzje.  Organizacje z nowym DNA idą dalej, oddają tę odpowiedzialność do pracowników. Każda osoba w firmie, znając strategię, znając swoich klientów i to co dla nich najważniejsze powinna umieć zweryfikować, czy to co robi ma rzeczywiście sens. Dokładając do tego system szybkiej informacji zwrotnej i weryfikacji tego co robimy możemy pozwolić sobie na eksperymenty bez obawy o błędy na dużą skalę. Właśnie ta szybka informacja zwrotna jest najlepszą kontrolą dla naszego działania. Dodatkowo uczymy siebie odpowiedzialności i przedsiębiorczości.

To jak to jest z tym CAB’em? Na spotkaniu padło pytanie to kto na końcu jest odpowiedzialny za zmiany. I oczy padły na mojego serdecznego kolegę, który zarządza działem. Tak, to jest właściwa osoba na właściwym miejscu. Jest odpowiedzialny za zmiany wykonywane przez jego zespół. Nie ma tutaj dodatkowych osób, które podejmą decyzję za niego. On wie, kto jest jego klientem, jakie ma potrzeby i zgodnie z tym podejmuje decyzje. Można iść dalej, jak zespół dobrze będzie rozumiał klienta, swoją odpowiedzialność to sam będzie umiał podejmować odpowiednie decyzje. Trzeba ku temu stworzyć odpowiednie warunki i kulturę. Kulturę uczenia się, wyciągania wniosków, poprawiania całości.

Wyobraźmy sobie, gdy dany pracownik bierze na siebie zadanie i odpowiedzialność za te zadanie. Popełnia błąd i zostaje ukarany. Wtedy to będzie jego ostatni raz, gdy tak postąpił. Następnym razem będzie szukał decyzji i odpowiedzialności u kogoś innego. Będzie się bardzo długo przygotowywał do zadania, przygotowywał różne scenariusze na wypadek, gdy się nie uda. Na wypadek, kiedy będzie musiał się tłumaczyć z błędu. Jest to dość naturalne działanie, lecz prowadzi do straty (waste) w postaci dodatkowego czasu oraz zaangażowania dodatkowych osób. Wtedy, rzeczywiście musi być taki CAB, który weźmie na siebie pracę za kogoś.

Zmiana kulturowa zakłada, że ludzie znają się na swojej pracy i chcą ją zrobić porządnie. Czasem popełniają błędy, ale to ich uczy. Tylko wtedy stają się coraz lepsi.

Kultura to jeden składnik, drugim jest działanie i myślenie systemowe. Jeden składnik umożliwia drugi i odwrotnie. Co w przypadku gdy, wierzymy w dobrą pracę ludzi, jednak oni nie mają narzędzi i możliwości do jej wykonywania. Co w przypadku, gdy system nie pozwala wykonać danej zmiany w sposób bezpieczny? Wtedy to znów prowadzi do przygotowywania dodatkowych planów, scenariuszy, angażowania dodatkowych osób. Nie możemy zmieniać kultury, gdy system na to nie pozwala. Trzeba zmienić system, na taki, który np. pozwoli w prosty sposób przeprowadzić zmianę na bezpiecznym wycinku całości lub na środowisku testowym lub, lub, lub. Potrzebujemy system, który da szybką informację zwrotną, bez dużych konsekwencji błędnego działania i pozwoli na szybką reakcję i działanie naprawcze w przypadku pojawienia się problemów. Standardy, automatyzacja, oprogramowanie wspomagające zarządzanie przychodzą nam z pomocą. A błędy? Błędy i pomyłki się zdarzają i będą się zdarzać wszędzie tam, gdzie działamy na krawędzi naszych możliwości. Tam gdzie wyciskamy z siebie jak najwięcej możemy.

To tak jak działanie Andon Cord w fabrykach Toyoty. Jest to prosty mechanizm (linka), która służy do zatrzymania produkcji w momencie kiedy pracownik widzi problem lub możliwość usprawnienia. Przeciętnie w ciągu dnia następuje około 1000 zatrzymań linii produkcyjnej w celu wprowadzenia małych poprawek. Oczywiście system pozwala na zamknięcie produkcji w małym obszarze, więc nie jest to destruktywne dla całego procesu produkcyjnego. Każdy pracownik ma prawo i obowiązek zatrzymania linii, kiedy uzna to za stosowne. Pewnego razu liczba Andon Cord spadła do 700 dziennie. Czy był to powód do radości? Dla zarządu był to sygnał ostrzegawczy. Z jednej strony  mogło to znaczyć, że z jakiegoś powodu pracownicy boją się zatrzymywać linie produkcyjną i w tym przypadku zarząd jeszcze raz podkreślił, żeby nie bać się usprawniać i poprawiać. To jest wartość na podstawie której budujemy doskonałość. Z drugiej strony może to oznaczać, że nie działamy na maksymalnych możliwościach, że odpuszczamy i wtedy jest mniej błędów. Nie mamy czego usprawniać.

W tym przypadku i system i kultura pozwalają na to, aby stawać się coraz lepszym, aby dążyć do doskonałości. Uczymy się brać odpowiedzialność i próbować pracować na krawędzi naszych możliwości, tak aby ciągle się poprawiać.

Na spotkaniu padło pytanie czy mamy błędy. Odpowiedź była tak mamy i pewnie zbyt dużo. Jednak całość działa. Robimy błędy i uczymy się usprawniać system.

Wartości Lean mówią o eliminacji strat (Eliminate Waste) i o spojrzeniu na całość (Optimize the Whole).  Te podstawowe wartości prowadzą do takiego działania, kiedy nie ma formalnego biura zarządzania portfelem i CAB’u. Nie znaczy to, że ta praca nie jest wykonywana. Proces jest maksymalnie uproszczony, tak aby dostosować się do kontekstu i potrzeb organizacji. Biorąc pod uwagę kulturę organizacyjną oraz dostosowany system jest to możliwe. Daleko jeszcze do doskonałości, wiele usprawnień jeszcze musi być wprowadzone. To byłby najgorszy moment, gdy byśmy stwierdzili, że już jest doskonale i że nie ma co poprawiać.

16. lutego 2013 · Write a comment · Categories: Agile, Lean, Tesis · Tags: , , , ,

W ostatni poniedziałek 11.02.2013 miałem przyjemność zaprezentować podejście Agile dla IPMA Polska w Poznaniu– opis jest TUTAJ, a prezentacja znajduje się w zakładce Presentations.

To było ciekawe spotkanie dla mnie. Połączenie teoretycznie rozłącznych organizacji PMI, IPMA, WSB oraz tematyki Agile. Ja jestem wolontariuszem i członkiem zarządu w PMI, prezentacje robiłem dla IPMA. Jestem też wykładowcą na WSB na kierunku pod patronatem PMI. A WSB jest członkiem instytucjonalnym w IPMA. Tak czy inaczej wszystkie te organizacje łączy jeden cel podnoszenia profesjonalizmu i wiedzy.

Jak wiele osób wie – wywodzę się z tradycyjnego podejścia do zarządzania projektami. Na takim zdobywałem przez wiele lat wiedzę i doświadczenie. Od dłuższego czasu dużo też energii poświęcam na poznanie podejścia Lean-Agile. Pasjonuje mnie ten temat. Na nowo mogę zdobywać dużą porcję wiedzy i doświadczenia. Podczas prezentacji pokazywałem różnicę między tradycyjnym podejściem, a zwinnym. Łatwo mi o tym mówić bo znam oba. Prezentacja dotyczyła tematu Agile Project Management, więc główny nacisk oraz większość poruszanych aspektów dotyczyła podejścia zwinnego. Sądząc po komentarzach, pytaniach oraz po spotkaniu networkingowym mogę stwierdzić, że większość osób była bardzo zadowolona z prezentacji. Miałem wiele ciekawych rozmów.

Jedna z nich dotyczyła tego, że w agile nie ma nic nowego i że to wszystko już było. Biorąc pod uwagę mój poprzedni post trochę się z tym zgadzam. Jeżeli Agile jest zastosowaniem Lean to oczywiście nie może być to nowość bo Lean jak i podłoże Lean (TPS) powstał już bardzo dawno temu. Dodatkowo na prezentacji pokazywałem historie Agile. Po raz pierwszy Scrum był wspomniany w dokumencie The new new product development game. Dokument ten pochodzi z 1986. Można jeszcze kilka przykładów podać z historii. Jeden z kolegów stwierdził, że np. TQM i teoria ograniczeń (TOC) już dawno o takim podejściu mówiły. Technicznie zgadzam się. Agile nawet jawnie korzysta z TQM i TOC. To jest wartościowa wiedza. Podczas konferencji StoosConnect na jednej z prezentacji pokazane były skróty około dwustu metod, technik zarządzania, które na dzień dzisiejszy biznes ma do wykorzystania. Większość jest bardzo skomplikowana, nawet dla bardzo zaawansowanych osób, które ukończyły szkoły biznesowe.  Ile osób umie rozwinąć skróty takie jak TQM czy TOC? A ile osób wie czego one dotyczą i jak je zastosować? Dokładając do ich skomplikowania to, że większość osób ich nie rozumie sprowadza się do tego, że bardzo mało jest firm, które je w pełni stosuje i czerpie korzyści. Oczywiście podkreślam to, że większość z tych metod ma bardzo dużą wartość. Są opracowane na podstawie wieloletnich badań i obserwacji. Sam Ken Schwaber jeden z sygnatariuszy Agile Manifesto oraz współtwórca Scrum’a spędził wiele lat na obserwacjach systemów produkcyjnych poznając tak techniki wytwórcze jak i zarządcze. Robił to, aby z nich czerpać i zaproponować coś lepszego.  Wszyscy sygnatariusze Agile Manifesto to inżynierowie, którzy mieli możliwość poznać większość technik zarządczych. Więc co odróżnia Agile, że staje się popularny, że ludzie rozumieją i chcą z tego podejścia korzystać, że przynosi konkretne i mierzalne efekty? Po pierwsze to nowe zwinne podejście korzysta z dotychczasowej wiedzy ludzi, bierze elementy z metod i standardów zarządczych. Czerpie z nich to co najlepsze. Po drugie procesy zwinne są bardzo proste i zrozumiałe. Po trzecie i chyba najważniejsze – agile stawia człowieka na pierwszym miejscu. To nie procesy i narzędzia robią z nas lepszych tylko my sami możemy siebie poprawić. Agile jest bardzo bliski działaniu mózgu człowieka i w tym można upatrywać sukcesu.

Produkujemy coraz bardziej skomplikowane produkty, coraz więcej w tych produktach jest myśli i wiedzy ludzkiej (np. programy komputerowe). Coraz więcej kreatywności. Aby osiągać wysoki poziom innowacji nasze produkty będą jeszcze bardziej złożone. Więc nie utrudniajmy sobie życia poprzez wytwarzanie skomplikowanych i złożonych produktów przy wykorzystaniu skomplikowanych i złożonych procesów wytwórczych. Na procesy wytwórcze mamy wpływ i możemy je uprościć. To właśnie odróżnia agile od tego co już było. To jest to nowe myślenie. Agile jako proces jest prosty, jednak jest trudny do wdrożenia. Jest go trudno wdrożyć bo nadal ciężko nam uwierzyć w człowieka i zmienić nasze podejście (mindset).

Pewnie na tym nie koniec. Pewnie jeszcze będzie wiele okazji, aby o tych różnicach porozmawiać i wymienić się spostrzeżeniami. Jestem przekonany, że to może być ciekawy temat i przy konstruktywnym podejściu możemy znaleźć coś nowego.

Na koniec cały czas musimy pamiętać, że najważniejszy jest kontekst naszych projektów i agile na poziomie procesu nie zawsze jest idealny. Jednak sprawdza się w wielu projektach opartych na wiedzy, innowacyjności, kreatywności.  Wartości, które idą za agile powinny być stosowane w każdym projekcie. Szczególnie na poziomie pracy zespołów.

06. lutego 2013 · Write a comment · Categories: Lean, Tesis · Tags: , ,

Wczoraj wieczorem byłem na wydarzeniu PMI Poznań – PMI@Night. Gościem specjalnym był znajomy trener z USA: Joseph Flahiff. Więcej informacji o nim znajdziecie na jego stronie: http://whitewaterprojects.com/

Prelekcja Josepha była na temat powodów porażek implementacji Agile w zarządzaniu projektami. Znów przyszedł nam z pomocą Pareto i jego podział 80/20. Kiedy chcemy wdrożyć Agile w zarządzaniu projektami to 20% trudności jest po stronie narzędzi, technik – tych uczymy się bardzo szybko. Jednak 80% to kultura w organizacji, która jest prawdziwym wyzwaniem. Kultury tak szybko nie zmienimy, a do samej zmiany potrzebujemy wsparcia na wszystkich poziomach organizacji. O tym jaka kultura jest wymagana, jakie wartości i zasady w organizacji napiszę następnym razem.

Być może mało odkrywcze, ale mi dało do myślenia jedno zdanie, które padło podczas prelekcji. Agile jest zastosowaniem Lean w rozwoju oprogramowania. Całkowicie się z tym zgadzam. W moim otoczeniu jest bardzo dużo projektów, które polegają na rozwoju oprogramowania. Tam Agile sprawdza się w 100%. Został do tego stworzony, został stworzony przez programistów i przez nich jest stosowany. Tak powinno być.

Będąc coraz większym zwolennikiem Agile próbuje go stosować w każdym projekcie jaki prowadzę i tu zaczynają się trudności. Bo te projekty mają inny kontekst niż rozwój oprogramowania. Przywołam tu znane powiedzenie z zarządzania projektami „Context is a King”.  Projekty przeze mnie prowadzone polegają na wdrożeniach systemów klasy ERP/CRM. Są to też projekty które wprowadzają zmianę organizacyjną. Są to projekty, w których udział bierze kilku dostawców.  Przy tego typu projektach wyzwania są inne niż przy rozwoju oprogramowania.

Pytanie jakie się nasuwa to czy powinniśmy stosować Agile w tego typu projektach? Skoro Agile jest stworzony dla rozwoju oprogramowania, dla innego kontekstu to pewnie powinniśmy szukać innych sposobów.

Zatem wróćmy do źródeł. Skoro Agile jest zastosowaniem Lean w rozwoju oprogramowania to działając przy innych projektach powinniśmy stosować Lean w kontekście tych projektów. Mary Poppendieck przytacza takie wartości Lean dla projektów rozwoju oprogramowania:

  • Eliminacja strat (ang. Eliminate Waste)
  • Tworzenie jakości i spójności (ang. Build Quality In)
  • Wzmocnienie pozyskiwania wiedzy (ang. Create Knowledge)
  • Podejmowanie decyzji najpóźniej, jak to możliwe (ang. Defer Commitment)
  • Wdrażanie najwcześniej, jak to możliwe (ang. Deliver Fast)
  • Respektowanie zespołu (ang. Respect People)
  • Spojrzenie na całość (ang. Optimize the Whole)

Mimo, że są one napisane z myślą o rozwoju oprogramowania, cały czas są prawdziwe dla wszystkich projektów technicznych. Trzymając się tych zasad, należy spojrzeć na kontekst projektu i dostosować proces projektowy do tego kontekstu. Tak często słyszę, że nie da się wybudować domu korzystając z podejścia Agile. A korzystając z Lean da się? Skoro Toyota jest w stanie budować samochody od kilkudziesięciu lat korzystając z Lean, to i domy można budować. Można też inaczej podejść do projektów wdrożeniowych. Zastosować Lean w kontekście tych projektów. Idąc dalej, jeżeli nas interesuje nowa lepsza organizacja to zasady Lean powinny być zastosowane w całej organizacji. To jest ta zmiana paradygmatu, o której piszę Steve Denning. 

W poprzednim poście stwierdzam, że musimy się kierować w stronę strategii proponowanej przez Eric’a, aby budować lepszą i szybszą organizację. Książka jest długa, więc przytoczę kilka myśli, na które zwróciłem uwagę i które mogą pomóc nam w budowaniu lepszej organizacji.  Cała książka opisuje cykl: Build-Measure-Learn. Najwięcej skupienia jest na Learn – na uczeniu się. Celem naszego działania jest uczenie się jak zrobić lepszy produkt, który pokochają klienci. Zrobienie produktu jak najszybciej (ang. Just do it) i zobaczenie co się możemy z niego nauczyć, w przeciwieństwie do zrobienia produktu i zobaczenia tego co się wydarzy.

Przy starcie budowy nowego produktu ważne są nasze założenia. Zawsze jak coś nowego zaczynamy to mamy własne założenia. Jest to nasza wizja, są to nasze plany, są to nasze przewidywania co do zachowania klientów. Nie ma nic złego z posiadaniem założeń, jednak nie można ich traktować jako fakty. Celem założeń jest sprawdzenie ich prawdy tak szybko jak to możliwe.

Aby zbudować nasz pierwszy produkt musimy znać MVP tego produktu (Minimum Viable Product – produkt o minimalnej koniecznej funkcjonalności).

Jednak, aby poznać MVP naszego produktu trzeba dokonać pewnych założeń. Nikt przecież wcześniej takiego produktu nie zrobił. Określanie MVP wymaga naszej odwagi do sprawdzania naszych założeń. Te najważniejsze i najbardziej kluczowe powinny iść na początek, bo to od nich zależy powodzenie lub porażka naszego produktu. Najlepiej jest je sprawdzić na samym początku. Naszą strategią powinno być znalezienie najważniejszych pytań i założeń, najważniejszych hipotez, tak aby je sprawdzić.

Wspomniana odwaga to jest bardzo duże wyzwanie. Szczególnie dla managerów średniego szczebla. Jeżeli zaczynamy nową firmę to nie wiele mamy do stracenia i potrafimy ryzykować. Jeżeli jednak pracujemy dla dużej organizacji jako najemnicy to nasz poziom odwagi zmniejsza się. Ja to nazywam syndromem spiętych pośladków. Czyli duża presja na to, że cokolwiek robimy to musi być sukces. Stoi to w sprzeczności z uczeniem się. Eric napisał „if you cannot fail, you cannot learn”. W wielu firmach jak manager obieca dostarczenie produktu i mu się nie powiedzie ma bardzo duży problem. Często jak coś robimy dla pieniędzy, a nie po to aby się czegoś nowego nauczyć boimy się eksperymentować. Poprzez długie analizowanie obniżamy ryzyko i naszą odwagę do jego podjęcia.

Średni szczebel managerów to jedno z czterech wyzwań dla nowoczesnej organizacji, pozostałymi są odpowiednio dobrana struktura firmy, umiejętność oddzielenia wartości od straty oraz umiejętność zbierania informacji zwrotnej, tak aby zachwycić klienta.

Aby się uczyć, musimy obserwować to co robimy i mierzyć. Ważne są odpowiednie miary, które spełniają 3 warunki:

  1. Miary muszą być takie, abyśmy po ich uzyskaniu mogli coś zmienić, abyśmy mogli wykonać działanie, które będzie miało wpływ na wynik pomiaru. Nie ma sensu mierzyć coś, na co nie mamy wpływu i nie umiemy lub nie możemy na to wpłynąć. [actionable]
  2. Miary muszą być dostępne i znane wszystkim, którzy maja na nie wpływ. Chcemy je widzieć i obserwować. Chcemy mieć narzędzia do ich obserwacji, tak abyśmy mogli szybko reagować. [accessible]
  3. Miary muszą podlegać kontroli. Musimy mieć możliwość ich udowodnienia i sprawdzenia ich działania. Sprawdzenia, że wynik miary ma wpływ na nasz produkt i pokazuje go takim jakim jest. [auditable]

Bardzo ciekawe stwierdzenie odnośnie miar to z ang. „Metrics are people, too”. Miary powinny się skupiać na działaniach ludzi, konkretnych ludzi. Klientów z poszczególnych segmentów. Musimy wiedzieć, jakie miary wpływają na segmenty. Musimy wiedzieć jak zebrać od nich informację zwrotną i jak na nie wpływać poprzez zmianę naszych działań.

Eric też porusza elementy charakteryzujące nowoczesną organizacje. Do nich zaliczają się:

  1. Inkubacja – nowe organizacje powinny być dobre w wykonywaniu kilku różnych rodzajów pomysłów jednocześnie. Na pierwszy rzut oka, kojarzy nam się to z wielozadaniowością. Tutaj jednak chodzi o to, aby wykonywać kilka rodzajów naszego produktu, mieć w posiadaniu kilka ścieżek i kilka rozwiązań co pozwoli nam na elastyczność.
  2. Disruptive Thinking – koncepcja, która prowadzi nas do poszukiwania nowej drogi rozwoju. Drogi w której jesteśmy dobrzy tylko my.  To ma na celu zdobycie naszej przewagi konkurencyjnej.
  3. Szybkość adaptacji – nowoczesna organizacja musi potrafić tak szybko się zaadoptować jak szybko pojawiają się nowe wyzwania lub zmiany w otoczeniu.
  4. Wielkość partii produkcyjnej – w produkcji im większa partia produkcyjna tym lepiej i taniej, jednak nie sprawdza się to w innowacyjnych i kreatywnych firmach. Nowa organizacja opiera się na małych partiach, które może szybko zmienić i zaadoptować do nowych wymagań.
  5. Push vs Pull – nowoczesna organizacja posługuje się systemem pull. Czas mamy ograniczony i im więcej skończymy tym więcej skończymy. Pobieramy najbardziej wartościowe zadania do wykonania i je wykonujemy.

 

Bardzo mi się podobało podejście do systemów informatycznych i nowego pracownika. Eric namawia do tego, że jak mamy nowego pracownika w firmie to od początku powinniśmy go wdrożyć do pracy na środowisku produkcyjnym. Jeżeli środowisko jest stabilne i nie ma luk to nic się nie wydarzy. Jeżeli jest możliwa awaria, są luki w systemie to jak najszybciej trzeba je wykryć i naprawić. Nowy pracownik nam w tym pomoże.

Ważne zdanie pada pod koniec książki. Zmiana na nowy system jest trudna. Nowy system pokazuje fizycznie problemy w firmie, w starym widzieliśmy tylko te powierzchowne lub fikcyjne. Przez to, że widać bezpośrednio nasze błędy zmiana często jest postrzegana na gorszą. Z doświadczenia wiem, że wynik tej zmiany może zwrócić się z nawiązką. Nie można zamiatać problemów pod dywan – trzeba się z nimi rozprawić.

20. stycznia 2013 · Write a comment · Categories: Better Way, Lean · Tags:

Kilka tygodni temu przeczytałem książkę The Lean Startup, autor Eric Ries. Szkoda, że jej nie przeczytałem kilka lat wcześniej. Wtedy byłaby dla mnie zupełnie odkrywcza. Teraz uzupełniła moją wiedzę. Eric to swego rodzaju ewangelista nowego podejścia do produktu i do organizacji, która ten produkt wytwarza lub chce wytworzyć. Przez wielu uznany jako guru nowego podejścia. Przyłączam się.

Ostatnio dzięki stowarzyszeniu PMI, w którym aktywnie pracuje dostałem prenumeratę Harvard Business Review. We wrześniowym numerze pokazał się artykuł: „Too Many Pivots, Too Little Passion – What’s wrong with today’s entrepeneurism”. Artykuł krytycznie podchodzi do nowego typu przedsiębiorców tzw. startup’owców.  Wspomniana jest tutaj między innymi postać Erica i jego książka. Stawia podejście Erica w konfrontacji do wszystkim znanego Steve Jobs’a. Zamiast polegać na intuicji dotyczącej potrzeb klienta oraz na perfekcyjnym rozwoju produktu, który kończy się wielkim wejściem na rynek, Eric namawia do pokazywania pierwszej najprostszej wersji klientowi, do zbierania informacji zwrotnej i ciągłej poprawy produktu, aż do momentu, kiedy stworzymy coś co można sprzedać. Wspomniane są też inne książki takie jak „Startup Weekend”, która pokazuje, że można zbudować produkt w 54 godziny. Zarzuca, że nowe podejście, nowa strategia to głównie z ang. buzzwords. Nie da się przenieść tej strategii na produkty inne niż strony internetowe lub aplikacje. Zarzuca, że żadna z nowopowstałych firm na podstawie nowej strategii nie zmieniła świata. Zamiast podejścia budowania firmy, po to aby przetrwała wiele lat na rynku, buduje się firmy po to aby były szybko kupione przez Google. Dla wielu nowych przedsiębiorców, którzy stosują nową strategię nie ma znaczenia jaki produkt budują, nie mają pasji dla niego. Oni wierzą, że poprzez szybkie próby, błędy i poprawki są wstanie dojść do jakiegoś produktu, który się sprzeda. Wspomniane jest też inne skrajne podejście, które polega na wymyślaniu produktu przez lata, na wydaniu setek tysięcy dolarów bez pokazania lub próby sprzedania go klientowi. Autor artykułu namawia do podejścia równoważącego pasję, cierpliwość oraz respekt do informacji zwrotnej idącej z rynku.

Wg mnie równowaga jest bardzo potrzebna, jednak jeżeli chcemy budować lepszą organizację to musimy się kierować w stronę strategii prezentowanej w książce The Lean Startup. Można ją także wykorzystać do tradycyjnych produktów. Kilkadziesiąt lat temu firmy motoryzacyjne wypuszczały nowe modele samochodów co 8-10 lat. Toyota poprzez podejście lean skróciła czas wypuszczenia nowego modelu do 1-2 lat. To zaskoczyło rynek i pozwoliło na bycie światowym liderem w sprzedaży samochodów.  Szybszy wygrywa, lecz musimy pamiętać o równowadze szybkości i najwyższej wymaganej jakości naszych produktów.

Ograniczenia tkwią w naszym myśleniu o produkcie i jego budowie.