1

Wymagania umarły. Rozwiązaniem jest cykl życia produktu

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...

________________________________
  1. 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. 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. 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.