Analiza biznesowa w projektach IT,
7 maja 2020
Aktor na diagramie przypadków użycia UML
„Stanęłam przed wyzwaniem analizy wstecznej systemu, w którym wszystkie procesy są wywoływane przez system, nie ma żadnych użytkowników biznesowych. System
Firmy zrażone ciągnącymi się latami projektami, które dostarczają nie to, co było potrzebne, są otwarte na alternatywy. Wykonawcy wychodzą naprzeciw oczekiwaniom (i swojej ciekawości nowych rozwiązań) proponując Scrum. Odtąd miejsce Waterfalla zastępuje Agile. Czy to zawsze najlepsza opcja? I czy jedyna alternatywa jaką mamy?
Modnemu ostatnimi laty Agile’owi przeciwstawia się tradycyjne sposoby pracy. Pod pojęciem tradycyjne wymieniane są jednym tchem takie pojęcia jak waterfall (cykl kaskadowy, PRINCE2, itp.). Mamy zatem dwa wyjścia – trwać w epoce starożytnej lub wejść w XXI wiek i stosować Scrum.
Cieszy, że dzięki popularności Scruma rośnie świadomość tego, że można wytwarzać systemy w sposób uporządkowany, nie chaotyczny. Świetnie by było, gdyby ta moda spowodowała też ciekawość innych rozwiązań, tak, abyśmy mieli wachlarz możliwości, nie przywiązywali się do jednego, które nie zawsze będzie najlepszym wyborem.
Przede wszystkim warto obalić kilka mitów, które stoją na drodze otwarcia na inne możliwości.
To zależy. Efekty widać co prawda szybko od momentu rozpoczęcia projektu. Kiedy jednak projekt zostanie zakończony? To zależy od tego ile niepewności jest w projekcie, ile niesprawdzonych tez biznesowych. Na pewno lepiej stosować takie wyjście przy tworzeni produktów na półkę (dla masowego użytkownika), start up’ach. Jeśli jednak mamy do czynienia z projektem, w którym wiele rzeczy jest z góry wiadomych, np. znane są przepisy księgowe, formularze ubezpieczeniowe, wnioski unijne, nie ma sensu „próbkować” i testować kolejnych iteracji. Szkoda na to czasu. Zamiast zawracać głowę klientowi recenzowaniem naszych strzałów wynikających z niewiedzy, zamiast wprowadzać ciągłe poprawki wynikające z późniejszego odkrywania powiązań w kolejnych modułach, dajmy spokój Scrumowi i weźmy inne rozwiązanie. Dobre zrozumienie, przemyślenie i opracowanie koncepcji na początku może znacząco skrócić późniejsze programowanie, bo nie ma tylu poprawek, nie ma powrotów, idziemy jak burza. Poniżej badania IBM na masie ich projektów.
Oczywiście, można w Scrumie próbować zrobić każdy projekt. Może się nawet udać. Pytanie czy to najlepsze, najtańsze rozwiązanie. Barry Boehm i Richard Turner prowadzący badania nad setkami projektów, konsultując się z najwybitniejszymi specjalistami, m.in. Grady Booch’em czy Alistair’em Cockburn’em (twórcą ruchu agile), odkryli, że w pewnych warunkach (np. >50 osób, duże powiązania między modułami, itd.) używanie Scruma powoduje więcej trudności niż korzyści. https://analizait.pl/2012/jak-nie-puscic-firmy-z-torbami/
Jeśli tworzysz tony niepotrzebnych dokumentów, to może być tylko jedna przyczyna:
Każdy dokument powinien czemuś służyć, coś wnosić. Jeśli jest za dużo stron, to znaczy, że nie umiesz uchwycić sedna, rejestrujesz tylko jak dyktafon, co mówi klient lub jakie materiały Ci dostarcza, bez zastanowienia, czy to ma sens i się ze sobą spina. Jeśli tworzysz kolejne strony, które nikomu nie są potrzebne, to znaczy, że zaplanowane przez Ciebie czynności są bez sensu. To Twój błąd, nie metodyki innej niż Scrum.
P.S. Jedym z głównych założeń PRINCE2 jest to, że skupiamy się na dostarczanym produkcie, nie na dokumentacji.
Masz cały wachlarz możliwości, jeśli chodzi o dobór metodyki i modelu wytwarzania.
Przede wszystkim dobry project manager (czy inżynier procesu) powinien dopasować sposób realizacji do projektu. Ma tutaj cały wachlarz możliwości. Poczynając od gotowych metodyk, kończąc na wybieraniu najlepszych praktyk z różnych metodyk, wg potrzeby. Większość metodyk określa jako warunek konieczny ich stosowania, aby je przyciąć (np. PRINCE2!) – dostosować do projektu. Wielkość i złożoność metodyki każdej innej niż Scrum jest zazwyczaj jedną z najczęściej podawanych przyczyn rzekomej niemożliwości wdrożenia w projekcie. Nikt nie każe, wręcz zabrania się, stosowania ich w całości. Ale do tego trzeba już trochę tę metodykę poznać, siąść i z głową dostosować.
Przykłady metodyk zwinnych: https://analizait.pl/2012/sprint-przez-metodyki-zwinne-agile/
Przykłady metodyk sterowanych planem znajdziesz w książce: Boehm B., Turner R., Balancing Agility and Discipline, A Guide for the Perplexed, Addison-Wesley, 2004
Modele wytwarzania znajdziesz tutaj: https://analizait.pl/2012/jak-wyglada-analiza-i-proces-wytwarzania/
Chcę, żebyś zapamiętał z tego artykułu jedno: Twój wybór to nie wieloletni waterfall lub Scrum. Masz ogromny wybór!
Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.
