Jak szybko jesteś w stanie dostarczyć produkt klientowi? Na tyle szybko, żeby nie odszedł do Twojej konkurencji? A może tak szybko, żeby był zadowolony? Czy też tak szybko, żeby nie zdąży zmienić zdania? Kiedy sytuacja ekonomiczna, możliwości technologiczne i potrzeby klientów dynamicznie się zmieniają, szybkie dostarczanie oprogramowania przestaje być kwestią przewagi konkurencyjnej i staje się standardem pracy.
Wyobraź sobie bank zamawiający duży system na początku roku 2008, jeszcze przed kryzysem. Projekt zakontraktowany na 30 miesięcy. Dodajmy do tego 6 miesięcy prób wdrożenia systemu i zintegrowania go z istniejącym oprogramowaniem klienta. Brzmi znajomo? Jak sądzisz, ile z zamówionych funkcjonalności klient będzie używał? Od połowy 2011 roku żaden bank nie udziela kredytów we frankach szwajcarskich. Mimo to nasz bank dostanie rozbudowaną funkcjonalność wspierającą ten produkt. Trudno, będzie na zaś. Przy okazji, zmieniło się prawo bankowe, więc musimy jeszcze nanieść poprawki tu i ówdzie. Nic trudnego. Następny projekt na rok albo dłużej i mamy pracę zapewnioną do końca życia… Niestety takich monstrum na rynku IT jest wciąż zatrważająco dużo.
Losowe zmiany
Oczywiście można próbować przyśpieszyć projekt. Takie akcje nazywamy zmianami i mają one zwykle charakter losowy. Każdy z nas widział takie próby. Kupujemy lepszy hardware, żeby przyśpieszyć kompilacje. I nagle, zamiast 30 minut, cały proces zajmuje 5. Sukces! Szkopuł w tym, że klient wciąż nie dostaje swojego produktu szybciej. Ewentualnie zakupujemy nowy sprzęt, ale nie mamy czasu lub pieniędzy aby go dobrze wdrożyć i przeszkolić z niego pracowników. Popularna też jest technika wybrania narzędzia dla inżynierów przez managerów na podstawie prezentacji sprzedawcy w power poincie.
Inna niezawodna metoda to powiedzieć pracownikom, żeby pracowali szybciej. No tak, przecież do tej pory tego nie wiedzieli i dopiero „zmotywowani” przez managera wezmą się do pracy. Do tej kategorii zaliczam również kierowników, którzy potwierdzają (czyli komitują od „commit”) nierealne daty, a potem oświadczają zespołowi „musicie to zrobić” (w wersji zespołowej: „musimy to zrobić”).
Kolejna metoda to dokładne kontrolowanie jak pracownicy wykonują swoją pracę. Inaczej mówiąc, na razie robią to w sposób nieefektywny i wystarczy im pokazać najlepszy sposób, aby ich skuteczność wzrosła. Ten jedyny słuszny sposób nazywamy standardowym procesem i jest on często definiowany przez specjalistów od procesu (ale nie od tworzenia oprogramowania) i narzucany wszystkim. Dzięki temu mamy dokładną kontrolę nad tym kto co robi, oraz stertę dodatkowej dokumentacji i raportów.
Kiedy projekt jest już poważnie opóźniony, wtedy, na deser, możemy dorzucić jeszcze kilku developerów. Gwarantuje to jeszcze skuteczniejsze spowolnienie projektu (patrz prawo Brooka).
Szukanie nieefektywności
Nie chcę przez to powiedzieć, że wprowadzanie zmian, zakup narzędzi, powiększanie zespołów czy standaryzacja procesów nie mają sensu. Jak najbardziej mają, pod warunkiem, że są robione z myślą o całym systemie, całej firmie, a nie jedynie lokalnej optymalizacji na poziomie departamentu. Zamiast „zmian” organizacje potrzebują „poprawy” i to ciągłej. Tak więc, aby przyśpieszyć tworzenie oprogramowania musimy popatrzeć na cały proces jego powstawania. Zrozumieć, jakie są konsekwencje wprowadzanych zmian. I tu warto skorzystać z doświadczeń Toyoty. Nazwanie tej firmy liderem szczupłej produkcji byłoby przejawem skromności gdyż Szczupłe systemy (Lean), wywodzą się właśnie z Systemu Produkcji Toyoty (Toyota Production System, TPS). Toyota wyróżniła trzy rodzaje nieefektywności:
- Muda – Strata, czyli wszystko co nie dodaje wartości z punktu widzenia klienta.
- Muri – Przeciążenie ludzi lub sprzętu prowadzące do problemów z jakością i bezpieczeństwem.
- Mura – Nierównomierność wynikająca na przykład z nieprzewidzianych problemów, albo fluktuacji zamówień, dostaw, czy wydarzeń.
Każda nieefektywność ma wpływ na pozostałe. Błędy, będące rodzajem strat (Muda), powodują nawroty partii materiałów do wcześniejszych procesów co generuje nierównomierne obciążenie produkcji (Mura). To znów powoduje przeciążenie maszyn i ludzi (Muri), co generuje błędy i koło się zamyka. W celu ułatwienia identyfikacji nieefektywnosci Toyota stworzyła listę siedmiu rodzajów strat, która w przypadku pracy umysłowej urosła do 10-ciu kategorii.
Co Cię spowalnia?
We wrześniu 2011 roku miałem przyjemność po raz pierwszy zaprezentować temat nieefektywności i strat na konferencji. Zachęcam do oglądania.
