wtorek, 21 października 2008

Zarządzanie innowacją - skąd się biorą pomysły?

Dzisiaj krótko, ale na temat bardzo interesujący. Wszyscy wokoło chcą teraz nagle zarządzać innowacjami. I fajnie. Niech się gospodarka rozwija nie tylko w oparciu o doskonałość operacyjną, ale także o nowe rozwiązania. Problem jaki widzę jest taki, że podejście do innowacji nawet w poważnych firmach jest dość mało poważne. Najlepiej widać to na przykładzie procesu zbierania pomysłów na nowe innowacje. Zwykle sprowadza się to do powołania jakiegoś "oficera innowacji", którego zadaniem jest zbieranie pomysłów od pracowników. Ta sama osoba odpowiedzialna jest za zorganizowanie mniej lub bardziej formalnej oceny przysyłanych pomysłów oraz późniejsze wdrażanie w życie tych, które ocenę przeszły pozytywnie. Czy to działa? Tak, i nawet są jakieś efekty - zwykle w postaci dziesiątek, jeżeli nie setek pomysłów od pracowników, które nigdy nie zostały wdrożone.

Przedstawione podejście, poza oczywistą taką zaletą, że działa, ma jeszcze dwie poważne wady. Po pierwsze nie ukierunkowuje pracowników na szukanie rozwiązań konkretnych problemów. Zgłaszane pomysły zwykle proponują usprawnianie wszystkiego po kolei zamiast tych rzeczy, które najbardziej bolą i uniemożliwiają rozwój. A takich rzeczy jest relatywnie mało. Według Teorii Ograniczeń zresztą tylko jedno. Ukierunkowanie całej kreatywności pracowników w jedno tylko miejsce będzie miało zdecydowanie lepszy rezultat niż zbieranie, czy jeszcze gorzej realizowanie, pomysłów na ślepo. Wyzwanie jakie tu się kryje to konieczność przeprowadzenia wnikliwej analizy przedsiębiorstwa przed wytyczeniem tematyki, w której miałyby nastąpić innowacje. A to jest trudne. Dużo trudniejsze od wyznaczenia "oficera innowacji".

Druga wada jest z zupełnie innego poziomu. Otóż chodzi w skrócie o to, że zbieranie pomysłów jest dużo bardziej efektywne nie na zasadzie "pomysły luzem", ale na zasadzie reakcji na konkretne wydarzenia. Na przykład takim wydarzeniem jest... nieoczekiwany sukces. Jeżeli organizacja odniosła sukces, który nie był spodziewany to należy się jak najszybciej zainteresować powodami, dla których ten sukces został osiągnięty. Ostatnio leci taka reklama z pralkami: firma sprzedaje dużo pralek w Indiach i pracownik jedzie na miejsce zobaczyć dlaczego, okazuje się, że Hindusi w tych pralkach mieszają soki. Teraz można oczywiście obśmiać Hindusów, jacy oni głupi, ale można też lekko zmienić projekt urządzenia i wprowadzić mieszarkę do soków. A następnie zarobić krocie. Cała sztuka polega na tym, żeby to było odpowiednio zapisane w procesach firmy. tak, aby tego rodzaju innowacje nie stanowiły szczęśliwego trafu, ale były efektem skodyfikowanego, powtarzalnego procesu.

wtorek, 14 października 2008

Dokumentacja wdrożeniowa i administracyjna

Ostatnio pojawiło się bardzo dużo, bardzo ciekawej pracy. Stąd przerwy w pisaniu na blogu. Będę próbował się poprawiać :-)

Wracając do tematu, spotkałem się z bardzo ciekawym człowiekiem, który pisze pracę magisterską z dziedziny agile. Konkretne na temat dokumentacji w projektach realizowanych metodami zwinnymi. Ja już kiedyś swoje zdanie na ten temat wyraziłem (tutaj). W trakcie rozmowy wyniknął jednak jeden ciekawy problem.

Kto bowiem w zespole pracującym zgodnie z metodami zwinnymi jest odpowiedzialny za pisanie dokumentacji wdrożeniowej i administracyjnej? Na początek ustalmy pojęcia. Dokumentacja wdrożeniowa obejmuje opis procesu, który trzeba zastosować, aby system został uruchomiony w środowisku klienta i poprawnie funkcjonował z innymi systemami wcześniej tam obecnymi. Dokumentacja administracyjna obejmuje opis procedur, które muszą być stosowane przez osoby obsługujące systemy (bardzo często są to pracownicy naszego klienta) aby zapewnić utrzymanie systemu. Często dokumentacja administracyjna obejmuje też instrukcję radzenia sobie z najczęstszymi problemami.

W przypadku dokumentacji technicznej oraz dokumentacji użytkownika sprawa jest dość prosta. Odpowiadają za nią członkowie zespołu, którzy jednocześnie piszą kod bądź testują oprogramowanie. Z dokumentacją wdrożeniową, a już zwłaszcza administracyjną, jest jednak inaczej. Otóż w najczęściej spotykanych przypadkach jest tak, że osoby zajmujące się wdrożeniami systemu (czy też integracją systemów) nie są bezpośrednio członkami zespołów agilowych. Wynika to z faktu, że w większość znanych mi firm (nie mówię tu o sytuacji super-idealnej wziętej z książki któregoś z guru) osoby zajmujące się rozwojem produktu oraz osoby zajmujące się jego wdrożeniem i później ewentualnie administracją pracują w różnych działach, często nie mających ze sobą nic wspólnego. Dlatego w znanych mi zespołach nie było osób z kwalifikacjami potrzebnymi do napisania tego typu dokumentacji.

Jak więc sobie z tym poradzić? Długo się zastanawiałem i wymyśliłem dwa sposoby. Pierwszy jest „ortodoksyjny”. To znaczy zespół agilowy jest odpowiedzialny za stworzenie i tej dokumentacji. Przy czym oznacza to wprowadzenie do zespołu osoby, która się na tym zna. Oznacza to, niestety, że zespół się rozrośnie, bo tak jak to wspomniałem wcześniej rzadko zdarza się, żeby osoby pracujące nad rozwojem produktu miały wiedzę i umiejętności potrzebne do napisania takiej właśnie dokumentacji. Drugim rozwiązaniem, bardziej praktycznym, jest… odpuszczenie sobie tej dokumentacji na poziomie prac wykonywanych w poszczególnych iteracjach. Dokumentacja wdrożeniowa i administracyjna powinna pojawiać się wówczas jako element wypuszczanej wersji a nie produkt iteracji (o różnicach w planowaniu wersji i iteracji pisałem tutaj). Wówczas będzie działać to tak, że zanim wersja zostanie uznana za gotową do wypuszczenia do klientów jako warunek konieczny pojawi się „dostępna dokumentacja wdrożeniowa i administracyjna”. Pracę tą można wykonać na przykład podczas iteracji synchronizującej (tutaj). Ma to też sens patrząc się ze strony działów wdrożeń, których pracownicy będą się musieli uczyć zmian w systemie raz na wersję a nie raz na iterację. Z ich punktu widzenia to akurat bardzo duże ułatwienie.