Jak to mawiał mój dawny profesor filozofii: “gdy dwóch mówi to samo to już nie jest samo”. To co nazywamy “zwinnym podejściem” to coraz częściej uznanie nieskuteczności metody polegającej na “zbieraniu wymagań” i obrona przed “obiecaniem z góry tego co ma powstać”, bo nikt nie wie czym to coś będzie jak już powstanie…(o ile powstanie). Takie głosy pojawiają się coraz częściej, i to nie od wczoraj….
Dzisiaj metody oparte na abstrakcji
Takie “pomysły” jak MDA (architektura bazująca na modelowaniu), MDE (inżynieria bazująca na modelowaniu), notacje BPMN, UML, SysML, SoaML i podobne, stanowiące sobą formę rysunku technicznego na wysokim poziomie abstrakcji, to ścieżka nie raz ratująca projekty informatyczne. To metoda pozwalająca radzić sobie z rosnącą złożonością inżynierii jako całości. Te narzędzia powstają i są rozwijane od ponad 20 lat… Konstrukcji dzisiejszego tramwaju czy złożonego oprogramowania, nie da sie już rzetelnie i precyzyjnie opisać z pomocą “listy wymagań zebranych w trakcie spotkań warsztatowych” na rozsądnej ilości stron papieru. Ich podział na “funkcjonalne i poza funkcjonalne” nie wprowadza niczego nowego do takiej listy. Ta technika specyfikowania (IEEExxx-1998?1?) ma swoje początki ponad 30 lat temu!
W czym problem?
Niedawno ukazał się kolejny ciekawy artykuł na ten temat.
Requirements gathering is one phrase I have learned not to use with stakeholders as I deliver projects. It appears to have struck fear, cynicism and/or anxiety in many of the user groups I have to engage at the most important stage of the solution ? the beginning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution2)
Popularne słowo “elicitation” to “uzyskiwanie, wydobywanie”. Branża IT poszła w kierunku uznania, że zainteresowany (stakeholder) ma rozumieć “wymagania”. To jednak nie działa.
Elicitation And Other Animals The industry then moved on with the terminology, to use the term ?elicitation.? To add complexity, there were separate definitions of functional requirements, being different to business requirements, then getting technical and coming up with system requirements. All of the types of requirements have clouded the understanding by stakeholders, and then time is lost in the defining the terminology before any discussions have begun. A plethora of white papers and authored article can describe the differences and it?s absolutely clear in some of those esoteric minds.. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution2).
Nie wolno zapominać, że zamawiający nie jest inżynierem. To co potrafi powiedzieć zamawiający i to co jest w stanie zrozumieć to wyłącznie “wymagania biznesowe” i nic ponad to. Poprzestanie w projekcie na takich “wymaganiach” nie stanowi żadnych wymagań wobec inżynierskiej konstrukcji jaką ma wykonać developer (czyli inżynier). Nie należy także zapominać o tym, że każdy biznesowy “udziałowiec” ma “swój interes” do realizacji, wymagania biznesowe to nic innego jak cele tych ludzi. I teraz kluczowe pytanie: kogo pytać o wymagania np. dla oprogramowania wspomagającego sprzedaż: prezesa tej firmy czy jego sprzedawców walczących o prowizje mających nadzieję, że ktoś złoży im propozycję lepiej płatnej pracy? Sponsorem projektów są zarządy firm, oczekują terminów, nazw, opisów a nie nadziei…
Today?s project needs are for solutions measured in time-to-market, risk reduction, take-up rates, or better still, what you defined as measurable at the beginning. (Źródło: Business Analyst | Requirements Are Dead, Long Live the Solution2)
Powiązany artykuł zawiera inne ciekawe pytanie:
Czego oczekuje biznes: efektu czy produktu?
What Is The Difference Between Outcome And Output? Before I go much further, I should probably explain what I mean when I use the words outcome and output in a context relevant to business analysts:
– Outcome is the change in the organization and changes in the behavior of stakeholders as a result of a project.
– Output is anything that your team delivers as part of your project. This could include requirements, documentation, processes, software, tests and other things that tend to be measured in order to gauge how the project is going.
(Źródło: Business Analyst | Your Job Is Not to Elicit and Document Requirements3)
i tu pojawia się teza dla analityków:
Requirements Are (Not The Final) Output (wymagania nie są ostatecznym produktem analityka)
To co nim jest? Popatrzmy na proces tak zwanej analizy systemowej:
Gdzie jest faza “zbierania wymagań” w rozumieniu “elicitation”? W zasadzie jest to dopiero początek drogi czyli sformułowanie problemu. Następnie ktoś powinien zbadać środowisko problemowe czyli przeprowadzić badanie (analiza biznesowa organizacji) i opracować model (mapy procesów biznesowych, struktury informacyjne). Kolejny krok to interpretacja wyników badania. Co jest tą rekomendacją? Jest nią rekomendowane rozwiązanie problemu, tym rozwiązaniem może być oprogramowanie, zmiany organizacyjne a najczęściej jedno i drugie.
Jednak nie jest rozwiązaniem stwierdzenie: “powinniście sobie kupić jakieś oprogramowanie i poprawić organizację”. Rozwiązaniem (rekomendacją) jest raczej: “to jest struktura i logika działania oprogramowania, które rekomenduję a to są rekomendowane zmiany organizacyjne”.
I to dopiero jest najwcześniejszy moment na “wpuszczenie” developera.
Nikogo w biznesie nie interesuje tak na prawdę suchy spis problemów (wymagania zebrane na warsztatach wśród pracowników), biznes jest zainteresowany czymś co można nazwać, kupić i wdrożyć w określonym czasie bo tylko to pozwala na oszacowanie korzyści z takiej inwestycji.
Rynek zmienia się szybko, więc nie ma sensu szczegółowe projektowanie czegokolwiek z uwagi na czas jaki zajmie takie projektowanie i ryzyko, że taki projekt stanie się szybko nieaktualny. Nikt rozsądny nie namawia dzisiaj do czegoś o wdzięcznej nazwie “waterfall”. Co więc zrobić? Dla dużych projektów tworzymy architekturę, opisujemy mechanizmy działania, politykę rozbudowy i opis cyklu życia. Czyli to co pozwoli rozwijać rozwiązanie metodą iteracyjno-przyrostową, w razie potrzeby pozwoli na przeprojektowanie, ale jako całość nadal będzie spójne, nie będzie wymagało wymiany całości gdy zmienią się warunki na rynku.
Można w tym miejscu zaryzykować tezę, że nie ma czegoś takiego jak “inżynieria wymagań” bo czym ona jest i co jest jej produktem? Uporządkowany spis życzeń? Mamy natomiast na pewno “inżynierię systemów“…. systemami są organizacje a także narzędzia jakich używają np. oprogramowanie…
Firma jako system
Każda organizacja to zbiorowy byt składający sie z komunikujących się ludzi. Jako ludzie, od wielu lata, wykorzystujemy komputery, które od początku swojego istnienia automatyzują wiele czynności, ale od niedawna służą przede wszystkim do komunikacji. Obliczenia stanowiły 100% zastosowań pierwszych komputerów, obecnie stanowią one tylko małą część tego do czego ich używamy, co całkowicie zmienia podejście do projektowania oprogramowania, które stało się integralną częścią organizacji.
________________________________
- 1.Żeliński J. IEEE1998 Czy produkuje dobre wymagania. IT-Consulting.pl. https://it-consulting.pl//2008/09/27/ieee830-1998-%e2%80%93-czy-produkuje-dobre-wymagania/. Published March 9, 2017. Accessed December 24, 2018.
- 2.Business Analyst | Requirements Are Dead, Long Live the Solution. BA Times. https://www.batimes.com/articles/requirements-are-dead-long-live-the-solution.html. Published March 9, 2017. Accessed December 24, 2018.
- 3.Business Analyst | Your Job Is Not to Elicit and Document Requirements. BA Times. https://www.batimes.com/articles/your-job-is-not-to-elicit-and-document-requirements.html. Published March 9, 2017. Accessed December 24, 2018.
Chcesz powiedzieć, że bliżej Ci do modelu realizacji projektów opisanych mniej szczegółowo ale z możliwością realizacji przyrostowej niż klasycznych metod projektowania rozpoczętych studium wykonalności projektu z aptekarską dokładnością?
Ja nigdy nie byłem aptekarzem, w inżynierii jestem zwolennikiem podziału prac na analizę i projektowanie i realizację/implementację. Jeżeli umówimy się, że nie mówimy o małych “projekcikach” to w dużych projektach jesteś skazany na etap projektowania szkieletu (architektura) i polityki jego rozbudowy oraz etap realizacji, rzucanie sie na detale implementacyjne na etapie projektowania to w obecnym tempie zmian na rynku strzał w stopę…. Od ogółu do szczegółu…. to mantra 😀
Studium wykonalności projektu to w zasadzie pierwsze wnioski z analizy biznesowej: jak już będzie wiadomo jakie rozwiązanie (w tym alternatywne) jest rekomendowane, ma sens ocena rentowności i technologicznej wykonalności.
Moje największe dokumenty (nafaszerowanie schematami blokowymi) mają ok 200 stron… standardowo poniżej 100…
Witam Panie Jarku
Chętnie zapoznam się z Pana publikacją Analiza Biznesowa.
Cześć.
1. Opinie, iż czas pozyskiwania wymagań minął są lekko przesadzone. Może to nie idea trąci naftaliną, a metody. Zgoda, co do tezy, że “lista wymagań” do realizacji jest już passe. Analiza biznesowo-systemowa stała się integralną częścią zjawiska o znacznie szerszym zasięgu – zarządzania zmianą, ze wszystkimi tego konsekwencjami, również w obszarze metodologii, technik i narzędzi.
2. Nawet jeśli zgodzimy się, że najwazniejsze dla biznesu jest rozwiązanie, to zawsze trzeba wiedzieć, jakiego problemu jest to rozwiązanie. Często bowiem mamy już gotowe lekarstwo (pod pojęciem lekarstwa rozumiem to, co aktualnie umie zespół IT, a szukamy na gwałt choroby, która do niego pasuje. Problem tkwi w sposobie/umiejętności identyfikacji problemów oraz uczciwości w ich stawianiu.
Pozdrawiam,
Marek
Dla porządku zwrócę uwagę, że mowa o złożonych rozwiązaniach, bo problemem jest rosnąca złożoność produktów (i np. telewizorów i oprogramowania).
1. Artykuł źródłowy i mój, wskazuje na formę. Wymaganiem nie będą “setki” cech zewnętrznych, a to do czego produkt ma być użyty i jak ma być skonstruowany, konstrukcja – architektura – powinna uwzględniać podatność na zmiany w cyklu życia produktu.
2. To prawda i to kwestia tego, że bez modelu organizacji stanowiącego kontekst projektu, stawianie komukolwiek i czemukolwiek wymagań w zasadzie nie ma większego sensu.
Obawiam się, że tym razem nie rozwiniemy się, tylko wymienimy poglądy (w myśl maksymy umieszczonej poniżej tego okienka).
Architektura – to jest właśnie to, co zastępuje “setki” cech zewnetrznych pęłniących role wymagań, a dokładniej, zmiany architektury biznesowej, konsekwencją których są / powinny być zmiany architektury systemu IT, rozumianego bądź jako “produkt” , bądź jako “infrastruktura”. Wymaganiami stricte są decyzje projektowe wynikające ze związków przyczynowo-skutkowych pomiędzy zdarzeniami w biznesie a cechami i sposobami używania systemów, które to związki są chyba najważniejszym i najcenniejszym efektem budowy i analizy architektury.
Ano, klientom powtarzam, że przychodzi taki moment gdy należy zrezygnować z zamawia schodów na piętro opisując je w detalach, należy zamówić schody pisząc, że służą nam na co dzień w drodze do sypialni i toalety, a czasami do tego by wnieść nowe łóżko o wymiarach nie mniejszych niż… ten drugi sposób jest znacznie mniej ryzykowny “biznesowo”…
polecam ciekawy wpis:
“In sum, for greater responsiveness and a higher benefits realization ratio, ?product-mode? is a more effective way of working than projects.”
https://martinfowler.com/articles/products-over-projects.html#ChallengesOfOperatingInProduct-mode