W poprzednim artykule (Ile jest tych wymagań na system ERP) pisałem, że nadmierne skupianie się na szczegółach nie tylko nie wnosi niczego do projektu ale nie raz wręcz go niszczy. Dotyczy to zresztą ogólnie projektów analitycznych, nie tylko w dziedzinie IT.
Na stronach jednego z bardziej poczytnych serwisów o analizie IT – http://www.modernanalyst.com – pojawił się jakiś czas temu ciekawy artykuł o analizie SWOT. Autor opisuje jak tę analizę przeprowadzić, ja opiszę jak jej użyć w analizie systemowej organizacji i specyfikowaniu wymagań. We wstępie artykułu czytamy:
Much of the business of business analysis is in the details, and most business analysts are by nature detailed, systematic thinkers. Occasionally most organizations, though, have times when they can?t see the forest for the trees. That is when the high-level, broad-range view that SWOT Analysis affords is just as useful in avoiding costly errors as unambiguous requirements. (What is SWOT Analysis?).
W dużym uproszczeniu: wielu analityków skupia się od razu na szczegółach, bo to naturalne elementy naszego bezpośredniego otoczenia, nie potrafią spojrzeć na organizację z daleka, „nie potrafią dostrzec lasu patrząc na pojedyncze drzewa”. Analiza SWOT pozwala spojrzeć na problem z innej, wyższej perspektywy, szerzej, dzięki czemu jest bardzo użyteczna w unikaniu kosztownych błędów jakimi są niejednoznaczne wymagania.
Jednym z „zabójców projektów” (a konkretnie ich budżetów i harmonogramów) są tak zwane wymagania osierocone i wymagania nieodkryte na etapie analizy. Są to odpowiednio wymagania zgłoszone do specyfikacji i zrealizowane, z których następnie nikt nie korzysta, oraz te odkrywane dopiero na etapie wdrożenia. Nie da się „zaprojektować” lasu myśląc o drzewach bo celem jest las, a nie konkretne drzewa.
Jeden projekt może mieć jeden cel, jeżeli jednak „celem” ma być każdy kolejny krok, podróż nigdy się nie kończy.
Wymagania o jakich pisałem w poprzednim artykule to wymagania wobec rozwiązania, którym było „jakieś oprogramowanie”. Jednak to drugi etap analizy. Generalnie najpierw analizuje się i definiuje wymagania biznesowe, a potem dopiero wymagania wobec rozwiązania, wiedząc już jakie warunki musi ono spełniać. Przykładowym wymaganiem biznesowym może być podniesienie jakości obsługi klienta (co by to tu teraz nie miało znaczyć), a dopiero rekomendowanym rozwiązaniem może być, np. oprogramowane CRM albo reorganizacja działu sprzedaży (co z resztą wiele firm robi znacznie częściej niż kupuje nowy CRM ;)).
Wiele firm rzuca się na projekty od razu z założeniem, że „musimy mieć nowe oprogramowanie”. Co nie raz bywa dużym błędem i masą zmarnowanych środków. Jak się przed tym ustrzec?
Warto popatrzeć na organizację i konkretny problem z pewnej perspektywy, z wyższego poziomu abstrakcji, niż tylko stojąc między biurkami widząc konkretne sprawy i ludzi się nimi zajmującymi. Narzędziem pozwalającym „wznieść” się na wyższy poziom abstrakcji jest właśnie analiza SWOT. Analiza ta polega na zidentyfikowaniu czterech kluczowych elementów wpływających na organizację : czynniki zewnętrzne jakimi są okazje i zagrożenia oraz czynniki wewnętrzne czyli silne i słabe strony organizacji. Tu ważna informacja, analiza SWOT to analiza „czegoś konkretnego” w „określonym środowisku”. Czynniki wewnętrzne opisują „to coś”, zaś czynniki zewnętrzne opisują „środowisko tego czegoś”. Można tak analizować organizację (np. firma i jej otoczenie rynkowe) czy też produkty projektów (np. konkretne oprogramowanie w firmie) ale nie sam projekt wdrożeniowy czy proces (one nie są „czymś”).
Analiza SWOT może być elementem analizy systemowej organizacji. Analiza SWOT to np. wstęp do opracowania rekomendacji w odpowiedzi na problem biznesowy. SWOT to identyfikacja i wpływ określonych elementów, pozostaje ocena tego jaki, i na co. Dlatego analiza SWOT stała się częścią tak zwanego Modelu Motywacji Biznesowej (BMM). Model ten pozwala lepiej zrozumieć otoczenie „problemu” oraz „śladować” elementy zidentyfikowane w analizie SWOT na konkretne procesy biznesowe i strukturę organizacyjną.
(diagram BMM: analiza SWOT i przejście na procesy biznesowe opr. własne autora).
Z poprzednich moich artykułów wiemy, że wymagania wobec rozwiązania (w tym wobec oprogramowania) mają swoje źródło w procesach biznesowych i ich wykonawcach. Jednak spisanie ich w postaci deklaratywnej listy podczas warsztatów i wywiadów, prowadzi do powstania długiej i praktycznie nieweryfikowalnej listy o jakiej pisałem w Ile jest tych wymagań na system ERP.
Lekarstwem na problem jest weryfikacja (tworzenie) listy wymagań wobec rozwiązania. Weryfikacja (diagram powyżej) polega na tak zwanym śladowaniu. Śladowanie to wywodzenie każdego wymagania z pierwotnej potrzeby, jaką jest taktyka, którą przyjęto by osiągnąć cel. Taktyka ma swoje źródło w strategii (taktyka implementuje strategię). Strategia (jej skonstruowanie) jest odpowiedzią na okazję rynkową, która jest przyczyną, dla której podejmujemy działania rynkowe. Okazja rynkowa daje szansę na „zysk” (produkt dający dochody) w postaci dostarczenia swojemu otoczeniu wartości dodanej. Warto tu zwrócić uwagę na to, że elementy analizy SWOT także powinny mieć swoje uzasadnienie w postaci identyfikacji zewnętrznych i wewnętrznych czynników wpływu. Słabe strony oraz zagrożenia powinny identyfikować ryzyka projektu. Analizę uznajemy za zakończoną po zidentyfikowaniu wszystkich znanych kluczowych czynników wpływu i ryzyk. Analiza taka jest elementem analizy systemowej organizacji.
Wielu właścicieli firm, ich zarządy, pomija ten etap w projektach z uwagi na swoje przekonanie, że ich dotychczasowe działania i chęć ich kontynuacji, nie wymagają żadnej korekty, oczekują podania na tacy opisu narzędzia, którego – jak sądzą – potrzebują. Zachowują się jak pacjenci, którzy mimo, że ostatnie badania robili wiele lat temu, nie dopuszczają myśli, że lekarz może im przepisać na gorączkę coś innego niż kolejną aspiryną. Bywa, że zbyt późno odkrywają, że tym razem to nie było kolejne przeziębienie.
Praktyka pokazuje, coś bardzo ciekawego: zamiast prowadzić żmudne i kosztowne wywiady, sesje warsztatowe, burze mózgów, których produktem jest długa lista dość przypadkowych „pomysłów na wymagania”, warto dochodzić do listy wymagań metodą od ogółu do szczegółu, właśnie od poziomu analizy SWOT (opartej na wizji i misji organizacji). Takie podejście od razu, najkrótszą drogą, prowadzi – przez model procesów biznesowych – do bardzo spójnej i kompletnej, bez nadmiarowych (osieroconych) wymagań, specyfikacji wymagań wobec rozwiązania. Każde wymaganie ma swoje uzasadnienie (śladowanie) w strategii, nie ma ryzyka, że coś pominiemy, bo tu weryfikatorem jest model procesu (kompletna i sprawdzona lista czynności). Koszty uzyskania specyfikacji wymagań tą metodą, są znacznie niższe niż tradycyjnymi (wywiady) metodami bo: nie angażujemy czasu całych zespołów pracowników na wywiady i warsztaty, ryzyko bardzo kosztownych pominięć i nadmiarów jest minimalne, liczba iteracji w takim projekcie zbliża się do JEDNEJ! i nie trzeba odkrywać wymagań metodą kosztownych prototypów na etapie przedwczesnej implementacji. Jedyny „problem” to jej przeprowadzenie, mimo „pokusy”, rozpoczęcia projektu od razu bo „nie ma czasu na analizę, i szkoda na to pieniędzy”.
Trochę to zaczyna przypominać 5‑latki PRLu 🙂
Łatwo jest popaść w fikcyjne misje i wizje, niezwiązane z rzeczywistością.
Z perspektywy zarządzania są to kluczowe elementy, wręcz szkolna wiedza, którą niestety pomijają inżynierowie… dla inżyniera projekt jest fajny z samego faktu, że jest, dla inwestora niekoniecznie… Najgorsze w wielu projektach jest to, że w odpowiedzi na pytanie „dlaczego Pan to robi” zapada cisza…wtedy już można robić cokolwiek. Ja zawsze pytam: skoro napisaliście tu te 73 wymagania, dlaczego nie jest ich 50 lub 100? Pytanie złośliwe: Dlaczego liczba wymagań jest proporcjonalna do czasu trwania sesji warsztatowych?
Moim zdaniem to podstawowy błąd w zarządzaniu, że wyznacza się fikcyjne misje, cele, wizje itp. nie weryfikując ich z rzeczywistością – patrz 5‑latki PRL, albo misje , albo http://www.strategicdevelopment.com/dilbert-mission-statement.php
Co do pytania to nie zawsze tak jest. Zauważyłem, że po pewnym czasie (>3h) ilość wymagań nie rośnie – pojawia zmęczenie:) Ale na poważnie to najczęściej powodem jest brak koncentracji na celu.
Ja proponuję inne pytanie: Dlaczego koszt (i czas) projektu jest wprost proporcjonalny do ilości zaangażowanych osób po stronie klienta?
O ile są fikcyjne to masz rację…
Bo brak koncentracji na celu jest wtedy gdy celu nie ma :), a jest nim własnie misja, strategia i taktyka 🙂 rozwiązania problemu.
Dlaczego koszt projektu jest wprost proporcjonalny do ilości zaangażowanych osób po stronie klienta? To jest złe pytanie bo koszt zawsze zależy od ilości ludzi zaangażowanych :), dlatego ja nie dopuszczam, by tych ludzi i roboczodniówek było z byt wielu, po stronie dostawcy także. Jest na to doskonałe lekarstwo: umowy fixed price :), u tylko takie toleruję u dostawców oprogramowania.
Całkowicie się zgadzam z Panem Jarosławem. Ostatnio, podczas przeprowadzonego wywiadu ze specjalistą ds. IT(inżynier wykonujący projekt) usłyszałem, że strategia, cele taktyczne i operacyjne to jest coś, co musi być, ale on(informatyk) tego nie rozumie i dla niego jest to bełkot. Dotarcie do strategii i misji firmy jest to pierwszy krok dla analityka.
Panie Jarosławie, mam jednak do Pana pytanie. Czy istnieje jakaś metodyka analizy SWOT. Chciałbym przeprowadzić taką analizę, ale niestety „nie umiem” – czyli nie wiem na jakie czynniki zwrócić uwagę. Jest jakiś „template” do przeprowadzania analizy SWOT?
No algorytmu nie ma ale są „dobre praktyki”, w każdej kratce jedna cecha plus ewentualnie dwie lub trzy uzupełniające. Zanim zaczniemy analizę SWOT musimy dysponować nazwą i kontekstem „tego co jest analizowane” i to musi być JEDNA RZECZ. Linkowany na początku artykuł jest czymś w rodzaju takiego „opisu jak” (choć jest troszkę rozwlekły). Dużą pomocą jest zebranie kluczowych czynników wpływu (wewnętrzne i zewnętrzne) nie zmienia to faktu, że SWOT może zrobić „biznes” lub „ja z biznesem” albo „ja” po wykonaniu analizy biznesowej. Może pokuszę się o taki opis :). I jeszcze jedno: „strategia, cele taktyczne i operacyjne to jest coś, co musi być, ale on(informatyk) tego nie rozumie i dla niego jest to bełkot” to fakt i powód dla którego nie ma sensu by ludzi z IT czynić analitykami wymagań w projekcie bo dla IT wymagania biznesu to zawsze „bełkot”.
Przy umowach fixed price, zawsze pytam o skład zespołu po stronie klienta 🙂
I słusznie :), ja dodatkowo dokładnie opisuję do czego ja się zobowiązuję a do czego klient. Drugie jest „silniejsze” od pierwszego ;). Innymi słowy: nie podpisuje umów, w których klient do niczego się nie zobowiązuje, bo powinien co najmniej dostarczyć co najmniej raz określone dane wejściowe ;).
Tu chodziło mi o aspekt wyceny – czym większy zespół, tym więcej pracy (np. uzgodnień).
To fakt, pytanie czy większy zespół to to samo co lepszy produkt końcowy.… bo ja tu bym polemizował 🙂
Myślę, że jeśli to jest proporcjonalne to odwrotnie 😀
Czyli czym większy zespół (analityczno-ekspercki), tym produkt końcowy gorszy.
Ale ja praktycznie dokładnie to napisałem :). Swoim klientom zawsze mówię, że wielkie obrazy czy rzeźby tworzą pojedynczy ludzie, próba skrócenia czasu ich powstania poprzez dodanie kolejnych „współautorów” jedynie podnosi koszt, tworzy chaos i prowadzi do znacznego pogorszenia jakości końcowego produktu. Owszem, wykończenie można powierzyć zespołowi (wypełnianie plam farba, konturów które stworzył Michał Anioł a Kaplicy Sykstyńskiej) ale najpierw musi powstać całe dzieło: projekt z ręki jednego autora.
Z tym bełkotem dla ludzi z IT to ja się do końca nie zgadzam. Oczywiście jest spora grupa, która prezentuje taką postawę, ale ta grupa to głównie programiści – nikomu nie ujmując, to nie jest element ich pracy i wcale się od nich tego nie wymaga. Jednakże jakoś nie potrafię sobie wyobrazić osób projektujących na podstawie analizy biznesowej czy zajmujących się QA czy (w sumie w Polsce dość nowym zagadnieniem) UX, którzy nie „czują” biznesu. Bez zrozumienia biznesu nie można dobrze wykonać swojej pracy w powyższych obszarach.
Co do samego artykułu no to przydałby się jeszcze jakiś przepis jak ten Top Management przekonać do tego żeby jednak nie upierali się przy tej aspirynie podawanej od lat. Niestety z tego typu sytuacjami spotykam się na co dzień, a że obecny klient to organizacja budżetowa to podważanie celowości jest wręcz nieformalnie zabronione – niemalże uderza w honor zleceniodawcy (no bo przecież on wie co robi), a niestety praktyka lat ubiegłych nie daje zbyt wiele do myślenia pomimo tego, że zlecane rozwinięcia systemu nie zawsze były pasmem sukcesów.
” jakiś przepis jak ten Top Management przekonać do tego żeby jednak nie upierali się przy tej aspirynie” – dyplomacja i jeszcze raz dyplomacja 🙂 czyli ja kończę na rekomendacjach i sygnalizuje ryzyka. Żaden lekarz nie ma prawa przymusu ale powinien informować o potencjalnych skutkach.
Może źle się wyraziłem. Podjąłem się stworzenia strategii informatyzacji pewnej spółki. Temat bardzo obszerny i pracochłonny, ale stwierdziłem, że spróbuję wraz z dwoma współpracownikami.
Umówiłem się na spotkanie ze specjalistą ds. IT w danej spółce i zaczęliśmy rozmowę. Próbowałem moderować tą rozmowę w celu zdobyciia potrzebnych informacji. Oprócz tego, że zdobyłem wiedzę na temat stanu ogólnego IT w firmie (specjalista podał bardzo wiele potrzebnych faktów). Ponieważ osoba, z którą rozmawiałem była bardzo kompetentna, to stwierdziłem, że warto zapytać o strategię organizacji i w jaki sposób dział IT „wpisuje się” w tą strategię i wtedy usłyszałem tą odpowiedź:
„Ja wiem, że takie coś istnieje i jest ważne, ale dla mnie to są rzeczy zbędne i niezrozumiałe – bełkot”.
Szkoda tylko, że w większości polskich średnich spółkach nawet kierownictwo na poziomie dyrektorów nie wie jaka jest strategia spółki i jakie są cele taktyczne spółki.
Zgadzam się ze stwierdzeniem, że programista czy specjalista ds. IT nie musi znać strategii. Dlaczego? dlatego, że to nie jest kluczowe w jego pracy, on raczej operuje na celach operacyjnych.
Nawiązując do tezy: „Zgadzam się ze stwierdzeniem, że programista czy specjalista ds. IT nie musi znać strategii. Dlaczego? dlatego, że to nie jest kluczowe w jego pracy, on raczej operuje na celach operacyjnych.”, ale szef IT powinien bo jest częścią kadry kierowniczej i powinien znać i rozumieć strategię firmy, która reprezentuje oraz umieć ocenić czy to co robi (lub planuje robić) wspiera tę strategie czy jej szkodzi. Jeżeli firma nie ma „szefa IT„a jedynie specjalistę od „sprawa operacyjnych” (który nie poczuwa się do strategii) to nie powinien on się w ogóle mieszać (ten specjalista) w proces jakiejkolwiek analizy wymagań, a w szczególności kierować nim.