Od wielu lat lat, produktem mojej pracy są dokumenty opisujące w obiektywny sposób działanie organizacji, zawierające rekomendacje zmian do poprawy sytuacji, także wymagania na systemy informacyjne. Po opracowaniu rozwiązania i pomocy w wyborze jego dostawcy, prowadzę nadzór autorski nad realizacją opracowanego rozwiązania. [1] Po latach pracy nasuwa mi się dość ciekawy wniosek z obserwacji: Zamawiający działają na swoją szkodę!
Typowy projekt związany z wdrażaniem nowych rozwiązań to realne potrzeby Zamawiającego. Członkowie zespołu Zamawiającego mają nad sobą terminy i „nieuchronność” kary za niepowodzenie. W efekcie Dostawca szybko staje się „Panem projektu”, bo to on dostarcza rozwiązanie, zna się, a bywa że szantażuje. Przewaga merytoryczna Dostawcy nad Zamawiającym jest tak wielka, że ten ostatni w zasadzie nie jest w stanie panować nad projektem. Powoli rynek to dostrzega i dlatego od kilku lat niemalże każda moja umowa na projektowanie zawiera także nadzór autorski (to forma kontroli efektów pracy dostawcy).
Nadal bardzo często Dostawca tworzy jednak pewną atmosferę: „to my realizujemy Wasz projekt i wszystko – Wy także – od nas zależy, nadzór autorski psuje Wam harmonogram bo my musimy te dokumenty czytać i tworzyć”. Dwa razy w ostatnich pięciu lat zdarzyło mi się, że faktycznie Zamawiający zrezygnował z nadzoru autorskiego, bo członkowie zespołu zaczęli „trzymać stronę Dostawcy”, mimo informacji o szkodliwości zmian wprowadzanych przez z Dostawcę. Oba projekty skończyły się niestety klęską (mam kontakt z praktycznie każdym byłym klientem).
Projekt wdrożeniowy bez nadzoru merytorycznego, to bardzo często równia pochyła: od podpisania umowy na wdrożenie z dostawcą jest już tylko coraz gorzej, bo Dostawca upraszcza logikę systemu, pomija trudne do realizacji wymagania, stale organizuje spotkania, na których legitymizuje te zmiany w prosty sposób sposób: „to co macie w dokumentacji wymagań jest złe (nie da się, nikt tak nie robi itp.), nasz system realizuje to inaczej, zróbmy to prościej i szybciej a też będzie dobrze”. Zamawiający z reguły nie ma po swojej stronie żadnych kompetencji by ocenić skutki takich „propozycji” i na spotkaniach godzi się na to, podpisując kolejne notatki projektowe z takich „warsztatów”, małymi kroczkami funkcjonalność dostarczanego produktu oddala się od faktycznych potrzeb i wymagań. Projekt kończy się tak, że Zamawiający „dostał dokładnie to co chciał a nie to co jest mu potrzebne”. Statystyki projektów IT są bezlitosne: ok. 2/3 projektów to nadal projekty nieudane. [2]
Tam gdzie mój projekt był kolejnym podejściem, po poprzednim nieudanym, wyżej opisana sytuacja była praktycznie zawsze przyczyną wcześniejszej porażki. Paradoksalnie jest to – porażka – wręcz standardowa sytuacja, gdy Zamawiający najpierw wybiera Dostawcę a potem zleca mu analizę wymagań i kierowanie projektem.
Zjawisko to zawsze kojarzy mi się ze znanym w psychologii efektem nazywanym Syndrom Sztokholmski. Jest to sytuacja, w której ofiara, wbrew zdrowemu rozsądkowi, zaczyna sympatyzować ze swoim oprawcą.
[Syndrom Sztokholmski] …ofiara porwania czy zakładnik traci krytycyzm wobec swojej sytuacji, zaczyna wierzyć, ze jej oprawca działa w słusznym celu, i darzyć go sympatią. Jak twierdzi amerykańska psycholog, dr Natalie de Fabrique, zajmująca się badaniem tego syndromu, syndrom sztokholmski pojawia się u ofiar nieświadomie, to instynktowny, psychologiczny mechanizm obronny, dzięki któremu łatwiej jest im odnaleźć sens tego, co się dzieje, i uniknąć załamania nerwowego. [3]
W wielu projektach wdrożeniowych mamy podobną sytuację: pracownicy zamawiającego, zamiast działać na rzecz siebie czy swojego pracodawcy, zaczynają trzymać stronę Dostawcy, który żali się, że ma problem z terminami i przerzuca winę za to na swojego klienta. Po pewnym czasie dochodzi do tego, że zespół Zamawiającego tak się „zżył z pracownikami Dostawcy”, że zaczyna ich bronić przed własnymi przełożonymi. Są Dostawcy, którzy celowo stwarzają takie sytuacje (np. organizując wyjazdowe szkolenia i warsztaty z noclegami), ale nie raz dzieje się „samoistnie”. Popatrzmy na poniższą listę, czy nie przypomina Wam to czegoś?
Objawy i symptomy syndromu sztokholmskiego to: – pozytywne uczucia ofiary wobec sprawcy; – zrozumienie przez ofiarę motywów i zachowań sprawcy i podzielanie jego poglądów; – pozytywne uczucia sprawcy względem ofiary; – pomocne zachowania ofiary wobec sprawcy; – negatywne uczucia ofiary wobec rodziny, przyjaciół, autorytetów próbujących ją ratować; – niezdolność zaangażowania się w zachowania, które mogłyby doprowadzić do jej uwolnienia od sprawcy. Syndrom sztokholmski nie dotyczy wszystkich osób dotkniętych tragicznymi zdarzeniami. By zaistniał, muszą wystąpić określone warunki. Ofiara: – spostrzega, że jej przeżycie zależy od dobrej woli sprawcy; – nie widzi możliwości ucieczki; – dostrzega drobne uprzejmości ze strony sprawcy; – jest izolowana od perspektyw odmiennych od perspektywy sprawcy. [4]
Popatrzmy zatem na projekt wdrożeniowy, w którym:
Zespól Zamawiającego wierzy, że „być albo nie być” firmy, zależy od powodzenia projektu,
Zespół Zamawiającego nie widzi alternatywy dla tego wdrożenia,
Zespół Zamawiającego widzi, że Dostawca od czasu do czasu idzie mu na rękę (realizowanie drobnych zachcianek Zamawiającego w zakresie projektu),
Zespół Zamawiającego jest izolowany od innych perspektyw i spojrzenia na realizowany projekt (silne dążenie Dostawcy do wyeliminowania zewnętrznego nadzoru merytorycznego, audytów, nadzoru autorskiego).
Psycholodzy co do jednego są zgodni: człowiek nie jest w stanie bronić się przed swoimi emocjami, dlatego często jedynym sposobem obrony przed manipulacją jest unikanie kontaktu z manipulantem. Nie ma tu znaczenia czy to manipulacja celowa czy nieuświadomiona.
Lekarstwo na sytuacje, takie jak wyżej opisana, jest tylko jedno: zrezygnować z warsztatów grupowych z Dostawcą! Jak to komuś mówię to ma miejsce przerażenie i padają słowa „Ale przecież praca grupowa jest najefektywniejsza! Tak uczyli na szkoleniu i mówili na konferencjach”. W literaturze nie raz spotykałem się z podejściem odradzającym warsztaty grupowe i burze mózgów z uwagi a ich duże koszty i nieefektywność. Nie jest jednak takich opinii zbyt wiele, bo mit efektywności pracy grupowej jest wiecznie żywy (mimo tego, że badania naukowe pokazują, że praca grupowa jest mniej efektywna niż praca samodzielna).
Jednak od czasu do czasu spotykam się książkami czy wpisami na blogach, że odejście od idei JAD (ang. Joint Application Development) wydatnie poprawiło jakość projektów (sam IBM proponuje w to miejsce całkowite zastąpienie warsztatów analizą dokumentów źródłowych a potem pisemne formułowanie uwag i zarządzanie zakresem projektu z użyciem ścisłej procedury, co paradoksalnie trwa krócej, jest tańsze i daje znacznie lepsze efekty).
Co ciekawe, idea taka pojawiła się w np. tak zwanej zwinnej metodzie zarządzania projektem SCRUM, w postaci roli Product Ownera (PO) jako osoby praktycznie całkowicie separującej zespół zamawiającego od zespołu Dostawcy (business vs. developers):
There are several aspects about this role which I think are critical to understand: Product owners bridge the communication between the team and their stakeholders. As Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.[…]
The role of Product Owner (Scott Ambler, Agile Modeling)
Ciekawe jest to, że większość znanych mi zespołów deklarujących pracę zgodną ze SCRUM, to zespoły developerskie, które praktycznie całkowicie rezygnują z prawdziwej roli PO. Jak? Po prostu wyznaczają na PO jednego z pośród członków zespołu developerskiego, co jest pogwałceniem zasad SCRUM. Skutek jest taki, że osoba, której podstawową rolą jest zarządzanie funkcjonalnością produktu i separowanie Developera od Zamawiającego, pracuje na rzecz developera i godzi się na każdą zmianę korzystną dla swojego zespołu. Niestety w projektach programistycznych jest to niemalże reguła. W projektach budowlanych (setki lat doświadczeń) dla odmiany jest to prawnie zakazane: nie wolno łączyć roli nadzoru autorskiego (architekt i projektant) ani z rolą wykonawcy ani z rolą inwestora.
Na koniec polecam ciekawy artykuł na podobny temat:
Polacy kupują mieszkania bez usług i zieleni. Wybierają szczelnie ogrodzone betonowe pustynie bez przedszkoli, placów zabaw i komunikacji. A obok rozwiązań prawnych to właśnie decyzje konsumentów ukształtują nam przestrzeń na kolejne dziesięciolecia. (żr. Ufamy deweloperom bardziej niż lekarzom. Przypomina to syndrom sztokholmski).
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Wokół metod zwinnych narasta wiele mitów, szczególnie tych o skuteczności w dużych projektach. Dzisiaj kolejne kilka słów o popularnym narzędziu jakim jest tak zwane „user story” czyli historyjka użytkownika, o ich ewolucji i o tym, że mogą być przydatne i kiedy.
Co prawda, jako źródło informacji wolę dokumenty, ale bywa, że tym źródłem informacji są jednak użytkownicy, bo dotyczy to projektowania np. nowych portali biznesowych. Tu niestety nie ma ani ustaw z wzorami dokumentów ani „dotychczasowego papierowego obiegu dokumentów”. Bardzo podobnie wyglądają start-up’y w obszarze operacyjnym. Podobnie wygląda analiza i projektowanie systemów wspierających obsługę klientów (CRM i podobne). Dlaczego? Bo tej sfery nie regulują ani przepisy ani żadne normy. Nie licząc elementów prawa cywilnego, są całkowicie uznaniowe.
User Story
Historyjki użytkownika, mają swój rodowód w EX (programowanie ekstremalne) i są z reguły definiowane tak:
In software development and product management, a user story is a description consisting of one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function (źr. ang. wiki).
Scott Ambler pisze:
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. ?1?
Generalnie jest to opis w potocznym języku, ten – z uwagi na niejednoznaczność – jako wymaganie, stwarza problemy. Podejmowane są próby formalizowania tych historyjek. Pisze o tym autor bloga QAgile (podając przykłady, polecam cały artykuł):
W podejściu agile takim jak Scrum wymagania definiujemy na ogól w postaci User Story. Prosta forma, która ma adresować oczekiwania i potrzeby użytkowników często zespołom przysparza dużo problemów w implementacji.?2?
Swego czasu ja także pisałem o efektach stosowania tej metody z zbytnią ufnością w jej skuteczność:
Niedawno po raz kolejny widziałem negatywne skutki tego podejścia, tym razem był to wdrażany i zakończony porażką (projekt przerwano) obieg dokumentów, nie tylko kosztowych, więc postanowiłem do tamtego artykułu dodać coś jeszcze: wymagania zbierano tu z w postaci „user story”.[…]
Tak więc opisowe user story może być wymaganiem biznesowym, testem ale raczej nie specyfikacją tego co ma powstać. Bez analizy pozwalającej wyspecyfikować wymagania dziedzinowe (logikę wewnętrzną) nie mamy szans na sprawne stworzenie oprogramowania wykraczającego poza prosty zestaw kartotek i rejestrów.?3?
User story to opis z perspektywy użytkownika. Najlepszą chyba metaforą będzie tu znana anegdota z opisywaniem słonia:
Każdy z tych okrzyków to odrębne user story.
Wszelkie metody zakładające, że użytkownik wie czego chce i jest najlepszym źródłem „wymagań” bazują na zaufaniu dla tych opisów.
I tu wpadamy w efekt ?kręcenia filmu?. Najczęściej tak zwana analiza wygląda tak, że pracownicy analizowanej firmy, w toku warsztatów lub wywiadów, opowiadają z jakimi to sytuacjami mają do czynienia, co robią, kiedy i jak, opisując konkretne przypadki z jakimi mieli do czynienia i to, jak sobie z nimi poradzili. Do tego dochodzą przypadki, w których sobie słabo poradzili, przypadki tego jak sobie radzą z tym, że czegoś nie rozumieją, a to wszystko jest okraszone sposobami pracy wynikającymi nie raz z niewiedzy, nieznajomości prawa czy wewnętrznych regulacji. Na domiar złego, nie raz można się spotkać z przypadkami, w których opowiadający o swojej pracy wplata elementy pozwalające mu na działania niepożądane takie jak upraszczanie procedur lub wręcz łamanie prawa (np. swego czasu pewien urzędnik na moich oczach w trakcie warsztatów zgłosił jako wymaganie wobec systemu obiegu dokumentów, możliwość podpisania orzeczenia sędziego przeterminowanym podpisem elektronicznym!).?4?
Historyjki użytkownika mają sens, jednak nie jako „kompletny opis wymagań na aplikację” (wczoraj usłyszałem, że w pewnej dużej instytucji zebrano już ok. tysiąca (!) takich historyjek i proces ten nadal trwa). Mają jednak sens jako „sample” do analizy. Przekazywanie takich historyjek bezpośrednio developerowi jest ogromnym ryzykiem. Dlaczego? Historyjka, nawet w sformalizowanej formie, niesie tylko subiektywne „spojrzenie z zewnątrz”, a programista zaczyna domyślać się i gdybać, niejednokrotnie przekraczając dozwolone granice:
…?jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT?, do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz ?algorytm? wyliczenia podatków. Jeżeli programista zaczyna ?lepiej wiedzieć? od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie ? jako developerowi ? robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach ?polegnie?.?3?
Bywa bardzo często, że programista bez żadnego oporu przyjmuje historyjkę: „ja jako sprzedawca, chcę umieścić na fakturze towar, którego nie ma jeszcze w magazynie, w celu zaliczenia sprzedaży w danym dniu” … (Komentarz zbędny…)
Czy to znaczy, że należy odejść całkowicie od tego narzędzia? Moim zdaniem nie. Wystarczy uznać , że „user story” to WYŁĄCZNIE opis z perspektywy użytkownika, swoiste „jedno spojrzenie z setek możliwych”.
Swego czasu opisałem taksonomię pojęć stosowanych w analizie wymagań:
Taksonomia wymagań na system (źr. opracowanie własne Jarosław Żeliński)
U szczytu tej hierarchii mamy wymagania biznesowe. Są to w zasadzie owe historyjki użytkownika. To wyrażone językiem zamawiającego, oczekiwania w stosunku do oprogramowania. Rolą analityka jest takie przeanalizowanie i przetworzenie tych opisów, by doprowadzić do powstania sformalizowanego opisu (np. w postaci modeli UML: przypadki użycia, model dziedziny, ograniczenia, inne) czyli do postaci specyfikacji usług aplikacji i logiki (mechanizmu) działania tej aplikacji.
Kolekcjonowanie wymagań biznesowych w postaci np. user story, ma sens jako zbieranie „sampli”, przykładowych sytuacji. Na ich podstawie, w toku analizy, można tworzyć modele i testować te historyjki (stają się scenariuszami testowymi). Tu polecam między innymi blog i książki Scotta Amblera:
In this episode, Scott Ambler helps us to understand the power of using models and how to use models in an agile environment.?5?
Wspominałem nie raz o nim i o jego książkach na tym blogu:
Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć? ?6?
Ostatnio popularność zdobywa podejście sformalizowane do historyjek użytkownika, bazujące na koncepcji Scott’a Amblera (modelowanie) i Rona Jeffries’a, zwolennika porządkowania, nie tylko treści wywiadów ;). Tu posłużę się ilustracjami z artykułu na stronie Visual Paradigm.
User story is one of the most important tool for agile development. They are often used for identifying the features of a system under developed. User stories are well compatible with the other agile software development techniques and methods, such as scrum and extreme programming. […]
Concept of 3C’s
The 3C’s refer to the three critical aspects of good user stories. The concept was suggested by Ron Jeffries, the co-inventor of the user stories practice. Nowadays, when we talk about user stories, we usually are referring to the kind of user stories that are composed of these three aspects: Card – User stories are written as cards. […] Conversation – Requirements are found and re-fined through a continuous conversations between customers and development team throughout the whole software project. […] Confirmation – or also known as Acceptance criteria of the user story. […]?7?
W dużym skrócie: historyjki dzielimy na jednostkowe elementarne (niepodzielne) opisy w postaci „kart”, zawierających opis tego czego zamawiający oczekuje od aplikacji, zapis uwag (konwersacja) dotyczących kolejnych dyskusji z zamawiającym na temat danej historyjki to historia ustaleń, opis oczekiwanego uzyskanego efektu czynności opisanych w danej historyjce potwierdzenie uzyskania oczekiwanego efektu. Idąc zaś za wskazówkami Amblera, implementację poprzedzamy pracą nad koncepcją implementacji posługując się modelami na dość wysokim poziomie abstrakcji.
Karta historyjki to prosty zapis utrzymany w konwencji „ja jako «aktor», chcę «nazwa czynności» w celu «oczekiwany efekt». Osobiście w projektach dopuszczam bardziej „luźną” formę takiej historyjki, jednak pilnuje co do zasady, by dotyczyła wyłącznie jednego „uzyskanego efektu końcowego”. Każda karta ma unikalne oznaczenie, jest bowiem używana jako jedno zadanie, w backlogu i sprintach (kanban). W dokumentacji (wspomniane narzędzie VP) user story wygląda to tak:
Historyjki mają swój cykl życia i dobrą praktyką jest rejestrowanie wszelkich kolejnych uzgodnień w toku pracy:
Tak zapisujemy „słowotok” zamawiającego na temat jego wizji realizacji danej usługi aplikacyjnej. Analogicznie zapisujemy opis oczekiwanego efektu końcowego:
Do tego momentu mamy „klasyczne” zwinne prowadzenie projektu z jego wadami opisanymi powyżej.
Wymagania powinny być „spójne, kompletne i niesprzeczne”
Jak to osiągnąć? Analityk zaczyna zbierać te historyjki i zaczyna składać z nich kompletny proces biznesowy. Stanowi on weryfikator, czy całość (zestaw takich historyjek) stanowi jakąś spójną, kompletną i niesprzeczną logikę biznesową w skali całej firmy. Zmorą projektów są wymagania odkrywane w toku wdrożenia, dlatego warto poświęcić czas na weryfikację pomysłu na całość systemu i zweryfikować spójność i kompletność tej całości z pomocą utworzenia modelu każdego całego procesu:
Warto modelować proces gdyż wtedy widać, że nie zawsze prawdą jest, że jedna (każda) historyjka jest odrębnym przypadkiem użycia. Przypadki użycia wyprowadza się z elementarnych aktywności jeden do jednego, co z uzasadnieniem opisywałem w artykule Transformacja…. Model procesu biznesowego daje kontekst, pozwala lepiej zrozumieć „sens” całości. Czy powyższy model procesu (notacja BPMN) z naniesionymi historyjkami, nie przypomina Wam wyników badania słonia? Tu słoń został przez analityka odkryty: to proces biznesowy (jego model w notacji BPMN). Przypadkami użycia będą elementarne aktywności w procesie. Więcej na temat zwinnego prowadzenia projektu z użyciem user story można znaleźć w tutorialu Agile handbook.
Na zakończenie…
(źr. Martin Fowler, Analysis Patterns, 1997)
We are called ?analysts? for a reason! We don?t merely hear stories and convert them into ?requirements?. Our integrated value lies in going above and beyond the story and expanding beyond engendering deliverables. We coalesce critical thinking and intellectual curiosity to transform stories into abstracts and to propose the needs as well as what the problem really is.?1?
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta – nabywca systemu ERP – powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika (da się wyczytać) rola oprogramowania ERP w firmie: taktykę czyli opis realizacji strategii firmy z pomocą planowanego do wdrożenia systemu ERP. Ta taktyka, to opis tego kiedy i po co oprogramowanie ma wspierać pracownikw organizacji. To, jak się to będzie odbywało w szczegółach, zostanie opracowane przez dostawcę (wykonawcę) konkretnego produktu, to dostawca gotowego oprogramowania opracowuje koncepcję wdrożenia, na podstawie dokumentu opisującego taktykę użycia tego oprogramowania i wymagania biznesowe (oprogramowanie dedykowane wymaga dodatkowo zaprojektowania i udokumentowania logiki biznesowej jaką ma ono realizować).
I co teraz? Teraz potrzebne jest źródło spójnej wiedzy o organizacji, jej strategii i taktyce w którą ma się wpasować oprogramowanie ERP. Któż jest tym źródłem? [[Product owner]].
Pytane teraz brzmi: kim jest i członkiem czyjego zespołu jest (powinien być) „product owner”? Tu zacytuję ostani akapit mojej ciepłej jeszcze recenzji książki:
…na ile wizja produktu uprawnia jej posiadacza do aktywnego kierowania projektem wraz z kierownikiem projektu (Scrum Master), ale to pozostawiam czytelnikom i praktykom. Jedno moim zdaniem jest pewne: nie ma sensu by zespół developera kontaktował się, z tabunem przyszłych ?userów?, ma sens by dostawał spójną wiedzę o tym co tak na prawdę ma powstać.
Autor powyższej książki nie daje wprost odpowiedzi na to pytanie, jednak milcząco zakłada też, że to zespół dostawcy „walczy” ze zjawiskiem i product owner jest członkiem tego zespołu, nie zmienia to faktu, że wymagana od niego wiedza i zrozumienie tego, do czego user będzie używał oprogramowania, powinna być taka jak opisałem wyżej.
Co usłyszałem po raz kolejny (podobne rozmowy z dostawcami oprogramowania nie raz już prowadziłem) od przedstawicieli dostawcy systemu ERP? Potrzebują bardzo zwięzłej i spójnej dokumentacji (ale raczej 50-ciu stron niż setek, że nie wspomnę o kilku tysiącach (tak – widywałem takie) i po stronie klienta (jednej) osoby, która ten dokument zna, rozumie, ma dostęp do kluczowych osób w organizacji. Najchętniej do autora tego dokumentu… Dostawcy oprogramowania jak dostają listę setek pozycji wymagań podzielonych w mało zrozumiały sposób na funkcjonalne i poza funkcjonalne (i inne) raczej sobie z tych specyfikacji dworują niż cieszą się z ich otrzymania (pomijam, ze nie czytają w całości). Po co są więc robione? Bo zamawiający postrzega swoją pracę przez pryzmat jej złożoności, wariantowości, nie patrzy z perspektywy narzędzia a tym właśnie jest oprogramowanie. To tak jak by cieśla lub stolarz opisał wymagania na młotek ciesielski w postaci setek stron „user story” o tym jak, do czego i kiedy używa(łby) młotka.. dla analityka projektanta taki opis (a konkretnie jego skąpa część) ma sens, dla konstruktora – żadnego, ten raczej oczekuje rysunku technicznego wykonawczego.
The role of Product Owner (Scott Ambler, Agile Modeling)
Powyższy diagram to poglądowy model roli product ownera (PO) autorstwa jednego z moich ulubionych „zwinnych analityków”: Scott’a Amblera (Scott Ambler). Niewątpliwie można dywagować czy PO to „pracownik” dosatwcy czy kupującego ale tu chyba część wątpliwości rozwieją słowa jednego z moich klientów, postrzegam go jako jednego z lepiej zarządzających ryzykiem biznesowym, znanych mi, prezesów firm: „Panie Jarku nie wiem czy jest Pan lepszym czy gorszym specjalistą od ludzi dostawcy, zatrudniłem Pana bo przełożonym tamtych jest Prezes tamtej firmy”.
Where Do Product Owners Come From? The goods news is that there are several viable options for where Product Owners may come from: Business analyst. Although a traditional business analyst could fill the role of product owner, there is a risk that they will fall into their old habits of communicating via documentation. Keep in mind that what agile teams really need are people with agile analysis skills who are empowered to make decisions. So, a better option is an empowered agile business analyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).
Tak więc nasuwa się wniosek, że rolę PO powinien pełnić ten człowiek, który właśnie skończył analizę biznesową i napisał raport z niej. Raport, który zawiera specyfikacją wymagań (najlepiej w formie jak opisana powyżej). W zasadzie nadzór autorski nad realizacją taktyki wdrożenia systemu ERP (oprogramowania w ogóle) to nic innego jak „bycie product ownerem” w projekcie na etapie jego realizacji a SCRUM faktycznie, na dzisiejsze czasy, wydaje się być najlepszą metodą zarządzania takimi projektami a utrzymywanie aktualności dokumentu analizy biznesowej i wymagań w toku projektu prowadzi do tego, że po zakończeniu projektu mamy „niechcący” kompletną i aktualną dokumentacje stanu uzyskanego w toku wdrożenia.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
A tak poważnie, obserwuję stygnięcie ideologii zwinnych metod i przechodzenie od dogmatów do praktyki. Niewątpliwie otoczenie rynkowe zmienia się szybko i metody strukturalne, tak, te z lat 80’tych polegające na wnikliwej i czasochłonnej analizie i budowie całościowego relacyjnego modelu danych dla systemu i projektowaniu listy jego funkcji, to faktycznie „wodospadowe” złe podejście. Tego nikt rozsądny nie neguje. Zwinność jednak, to nie „rezygnacja z pracochłonnej dokumentacji” (często to właśnie słyszę), a uznanie, że oprogramowanie powinno powstawać relatywnie małymi krokami, przyrostowo. I tyle, nie znaczy to, ze rezygnujemy z planowania. Tak, analiza i modelowanie to planowanie tego co ma powstać. To się nazywa iteracyjno-przyrostowe tworzenie systemu. Ok, jedno z głowy.
A kto ma wiedzę o organizacji i o tym jaki produkt w danym projekcie rozwiąże określone problemy? Ten kto tę organizację przeanalizował, opracował wymagania na produkt (tu oprogramowanie) i jednoosobowo ma wizję tego produktu.
Tak, np. taką osoba jest Analityk Biznesowy. Na etapie Analizy Biznesowej jest tym, kto opracuje opis produktu czyli wymagania jakie ma spełniać. Od momentu podpisania umowy na dostarczenie (wytworzenie) tego produktu… pełni (może to robić) role Product Ownera, roli w metodyce SCRUM odpowiedzialnej właśnie za rozumienie tego czym ma być to oprogramowanie. Gorąco polecam książkę: Agile Product Management with Scrum: Creating Products that Customers Love, która tak na prawdę – nieco wbrew tytułowi – traktuje o roli Product Ownera.
Tu pojawia się problem: na ile wizja produktu uprawnia jej posiadacza do aktywnego kierowania projektem wraz z kierownikiem projektu (Scrum Master), ale to pozostawiam czytelnikom i praktykom. Jedno moim zdaniem jest pewne: nie ma sensu by zespół developera kontaktował się, z tabunem przyszłych „userów”, ma sens by dostawał spójną wiedzę o tym co tak na prawdę ma powstać.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Nie jestem zwolennikiem klasycznego, kaskadowego procesu projektowania i wytwarzania oprogramowania. Preferuje proces podobny do kaskadowego, z prototypami odrzucanymi, jednak prototypem jest u model (projekt) a nie żywy kod. Proces taki opisuje np. metodyka MDA (więcej na stronie OMG, przyjdzie pora i na niego tu). Jednak propaganda mówi, że jak „powszechnie wiadomo”…
…model kaskadowy skazuje klienta na długi czas oczekiwania na efekt końcowy. Bardzo dużo czasu pochłaniają analizy przedwdrożeniowe i szczegółowe projekty, a ich wynik jest widoczny wyłącznie ?na papierze?. (za Scrum eliminuje słabości tradycyjnych metod wytwarzania IT).
I od razu do rzeczy. Powyższe nie jest prawdą. Badania projektów pokazują coś zupełnie odwrotnego:
Jak widać, poprawna (o takiej tu mowa) analiza wymagań, skraca czas implementacji (projektowanie i wykonanie) o ponad połowę. Po drugie owe zwinne iteracje to nic innego jak odkrywanie wymagań metodą prób i błędów, co jest czasochłonne i kosztowne, co widać na powyższym diagramie (pokazuje on statystyki ukończonych projektów).
A co jest prawdą?
To, że ów czas trwania projektu jest długi, to najczęściej efekt zbyt dużego zakresu tego projektu a nie tej czy innej metodyki. Po prostu system mający 200 planowanych cech funkcjonalnych będzie budowany długo nie dlatego, że wybrano „kaskadową metodykę” tylko dlatego, że „jest duży”.
Cytowany artykuł (zachwalający metodykę SCRUM) wskazuje na kilka „wad” analizy i projektowania, zobaczmy co tu jest wadą…
Ryzyko uzyskania nieadekwatnego rozwiązania ? model kaskadowy skazuje klienta na długi czas oczekiwania na efekt końcowy. Bardzo dużo czasu pochłaniają analizy przedwdrożeniowe i szczegółowe projekty, a ich wynik jest widoczny wyłącznie ?na papierze?.
Z punktu widzenia klienta, analizy to bardzo istotny koszt, który długo się zwraca ? klient płaci za doradztwo, często nie widząc żadnego realnego rezultatu poza dokumentami. Skomplikowane i złożone projekty to dla organizacji wielka odpowiedzialność, tymczasem w podejściu kaskadowym im bardziej złożone projekty, tym mocniej rośnie ryzyko związane z rezultatem końcowym.
Przy zastosowaniu Scrum takie ryzyko praktycznie nie istnieje. Obie strony wiedzą, że w okresie współpracy mogą wypracować rozwiązanie, którego nie można było przewidzieć na początku projektu. Przy tym zwinnym podejściu coś takiego jak ostateczna definicja finalnej wersji produktu na początku projektu nie istnieje.
I to jest ten moment, gdy ja pytam: na co zawarto umowę i z czego jest rozliczany dostawca? Tak więc dostawca jest praktycznie bezkarny, bo może dostarczyć cokolwiek… jak nazwać to ryzyko? Po drugie krytyka procesu analizy jako zbędnego pożeracza czasu i środków wymagań nijak się ma do praktyki, co pokazuje przytoczony na początku wynik badań.
I dalej:
Opóźniony rezultat ? celem IT bardziej niż kiedykolwiek wcześniej jest dziś wspieranie biznesu w jego codziennych działaniach i szybkie reagowanie na dynamiczne zmiany w otoczeniu biznesowym. W modelu kaskadowym na rezultat projektu czeka się długo, ponieważ określa go pełna, finalna wersja produktu.
Dobry projekt ma wizję i etapy. Każdy etap to ograniczona liczba funkcjonalności, możliwych do dostarczenia w czasie wymaganym przez biznes. Nie widzę powodów, by działające podsystemy dostarczać np. kwartalnie, i tak się dzieje.
Bardzo mała elastyczność podczas projektu ? biznes ulega ciągłym zmianom, co w oczywisty sposób pociąga za sobą zmiany oczekiwań dotyczących funkcjonalności zamawianego oprogramowania. Model kaskadowy kontraktuje projekt na etapie analiz (lub nawet wcześniej), po czym obu stronom trudno jest bez ryzyka wnosić istotne zmiany do zaplanowanych prac.
Po pierwsze nie wiem skąd autor wziął tezę o tym, że „Model kaskadowy kontraktuje projekt na etapie analiz (lub nawet wcześniej”. Model kaskadowy nie ma tu nic do rzeczy. Dobra umowa zawiera zakres projektu, a projekt ma cel biznesowy, i nie powinno nim być zatrudnienie programistów na kwartał po jakiejś stawce, a wytworzenie czegoś konkretnego i nazwanego w konkretnym czasie.
System, w którym implementację poprzedza analiza i projektowanie dzieli się na etapy jak każdy inny. Po drugie nie prawdą jest, że kontraktuje się od razu całość. Dobry projekt ma oddzielony etap projektowania od wykonania, kluczem jest raczej to na jaki zakres „rzuca się”, zamawiający.
Potencjalnie większe koszty ? w projektach IT liczy się nie tylko zwrot z inwestycji (ROI), ale też czas, w jakim poniesione inwestycje zaczynają się zwracać.
Tu odnoszę wrażenie, że autor nie rozumie co napisał albo jest to błąd redakcyjny… zwrot z inwestycji to zysk w czasie, więc nie ma znaczenia nic poza całkowitym kosztem i czasem w jakim go liczymy.
Biznes jest dziś tak dynamiczny, że dużą korzyścią jest dla niego względnie szybki dostęp do dostatecznie dobrych rozwiązań. W podejściu kaskadowym czas oczekiwania na finalny produkt jest bardzo długi.
Kolejna nieprawda, czas oczekiwania jest dokładnie taki jaki zaplanowano… można planować podział dużego projektu na podsystemy (jak wyżej).
Duże ryzyko złych relacji ? model kaskadowy z założenia dzieli obie strony kontraktu na dwa obozy: dostawcy i odbiorcy rozwiązania.
To ciekawostka, nie wiem skąd autor wysnuł taki wniosek.…
Marnotrawstwo czasu i pieniędzy przez biurokrację ? praca oparta na częstych iteracjach i powtarzalnym procesie (sprintach) pozwala bardzo szybko identyfikować niedoskonałości specyfikacji i luki w pierwotnej koncepcji. Strony mogą szybko zorientować się, że na etapie przygotowawczym np. nie wzięto pod uwagę istotnych komponentów lub interfejsów. W modelu wodospadowym wnoszenie zmian wiąże się najczęściej z pisaniem aneksów i renegocjowaniem kontraktu.
Kolejna nieprawda. częste iteracje to częste poprawki projektu w poszukiwaniu „właściwego rozwiązania”. Takie same iteracje robi analityk na etapie analizy i projektowania, tworząc projekt „na papierze”, rzecz w tym, że analityk na papierze robi to sam w ciągu pojedynczych godzin a zespół programistów robi to kilka dni kosztem kilkunastu „osobodniówek” tego zespołu. Koszty i czas łatwo sobie porównać…
W Scrum wszystkie niedopatrzenia można natychmiast uwzględnić na każdym etapie realizacji projektu, bez konieczności uruchamiania niewygodnej dla obu stron, i często burzącej relacje biznesowe, procedury obsługi zmian (Change Requests). Jeśli podejście służy projektowi, a tak jest w przypadku Scrum, dostawca i odbiorca elastycznie dopasowują się do siebie niezależnie od tego, jak dalece zmieniają się oczekiwania i potrzeby biznesowe.
Jeżeli autor uważa, że wprowadzanie ad-hoc nieformalnych zmian w zakresie projektu czyni projekt lepszym, to pozostawiam go z tym przeświadczeniem.
Scrum polega na wspólnym widzeniu celu, jakim jest rozwiązanie konkretnego problemu biznesowego. Jest to często dalekie odejście od sztywnej interpretacji zapisów kontraktowej specyfikacji wymagań, które same w sobie narzucają zespołom projektowym ograniczenia realizacyjne (techniczne) niezależnie od problemu jaki jest rzeczywiście do rozwiązania. Zaletą Scrum jest przejrzystość i wysoka elastyczność projektu.
Tu przytoczę słowa mojego kolegi prawnika:
Największym problemem sporów przed sądem, w sporach z firmami programistycznymi jest to, że wiele tych firm niczego nie dokumentuje i tak na prawdę nie wiadomo o co toczy się spór. Większość takich spraw zakładają pokrzywdzone firmy, nabywcy usług programistycznych. W zasadzie większość tych spraw, te firmy właśnie przegrywają, bo nie wiadomo co miało powstać a wiadomo ile miało kosztować. Tu sądy są bezsilne… wygrywają programiści, mając pieniądze mimo, że nie osiągnięto celu zamawiając. Ale winni są sobie wyłącznie zamawiający, godzący się na taką treść tych umów…
A co mówią statystyki?
Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com).
Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). I niech nikt mi nie mówi, że 29% to same SCRUM’y a pozostałe 71% to „kaskadowe” projekty bo to nieprawda.
Na zakończenie
Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych… Państwo sami muszą wybrać… Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających „kastomizacji” bo to (nowe funkcjonalności systemu) także projekt dedykowany.
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Nie jest tu, na moim blogu, tajemnicą, że preferuję naukowe metody analizy. Nie chodzi o „gmatwanie świata” a o proste a skuteczne podejście. Codzienna lektura blogów zaprowadziła mnie dziś na strony programisty, który napisał:
Czego moglibyśmy się nauczyć od naukowców? A być może tego jak ważną rolę i jak bardzo czaso- i kosztochłonne jest samo planowanie eksperymentu, jak ważne jest zrozumienie czynników zewnętrznych które mogą mieć wpływ na przebieg eksperymentu. Być może warto się zanurzyć w ten świat i spróbować.
Zapowiada się nieźle. osobiście uważam, że eksperyment jest generalnie tańszy i bezpieczniejszy od ćwiczeń na żywym ciele, te ostatnie są zresztą nie raz wręcz zabronione. Zanurzanie się w „świat rzeczywisty” wiec nie raz jest możliwe tylko raz: oddają gotowe rozwiązanie (w zasadzie jak samolot, gotowy jest oblatywany już z człowiekiem na pokładzie).
Bardzo podoba mi się osobiście idea eksperymentu. W moim, tak uwielbianym wątku architektury, analizy biznesowej i zarządzania projektami czasami zbyt często zawierzamy teoriom, manifestom, wzorom i skomplikowanym mechanizmom wyliczania poprawności złożoności wszechświata. Naukowcy w sytuacji gdy złożoność problemu uniemożliwia jego rozwiązania metodami analitycznymi zwracają się ku „eksperymentowi”. Dlatego błagam was architekci i analitycy, następnym razem gdy będziecie próbowali zaprojektować złożony system wykorzystajcie siłę jaką daje eksperyment. Wszelkiej maści „prototypy”, „testy” czy też Agile’owe „spike” są lepsze niż UML’e, diagramy, workflow’y i rysuneczki z procesami biznesowymi. Programiści was polubią za ciekawe zadania, a wy będziecie się mogli pochwalić działającymi systemami.
I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić na koszt klienta, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu…
Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała od razu jak trzeba!
Czy prototypy kodu są lepsze o niż modele procesów i projektu UML? Ja zapytam: opracowanie i przetestowanie mapy prostego procesu, potem przypadku użycia, kawałka modelu dziedziny i testowanie tego diagramem sekwencji to praca dla mnie, jednej osoby, na kartce papieru, koszt to jakieś np. 1000zł. Oddaje produkt (projekt) nie wymagający niczego poza implementacją. Czy za 1000zł ktoś posadzi człowieka lub ludzi, napisze i przetestuje kod kilkunastu klas plus dziesiątków technicznych, mając do dyspozycji jakąś platformę by to uruchomić? I klient odbierze i użyje to za pierwszym razem?
Naukowe metody, szczególnie te zdarzeniowe, polegające na stawianiu tezy i próbie jej falsyfikacji, to po pierwsze skuteczne metody, po drugie nieinwazyjne, po trzecie relatywnie tanie (w relacji do pracy na żywym ciele/kodzie). Po co workflow? Po to by przetestować, czy to co opowiada nieudolnie i mozolnie klient jest logiczne, jest prawdą (tak!). Przetestowany proces biznesowy to nic innego jak makieta, dobry plan miasta do planowania wycieczki. UML? Cóż, można wpuścić tabun murarzy na budowę bez projektu architektonicznego, i metodą „prototypy”, „testy” czy też Agile’owe „spike” postawią wieżowiec ale nie jestem pewien czy to będzie tanio i nie wiem czy odważył bym bym się w tym czymś zamieszkać. Po drugie zapytam: skoro te UML’e głupie to dlaczego książki o wzorcach projektowych i architekturze systemów są nimi nafaszerowane?
Czego jeszcze możemy się nauczyć od naukowców? A to że „Dobry eksperyment musi być jak najprostszy w wykonaniu i jednocześnie dawać jak najbardziej jednoznaczną odpowiedź potwierdzającą lub falsyfikującą daną teorię” (Wikipedia). Czyli Keep Your Tests Simple. (źr. cytatów: primitive.jogger.pl.)
A tu proszę, same rozsądne rzeczy (może dlatego że przepisane z WIKI). Oczywiście: model procesu dobry, to prosty model, jego testowanie także nie jest skomplikowane, a odpowiedź zerojedynkowa: działa albo nie działa.
Autor pisze na poczatku swojego artykułu, że stworzenie programu to teza:
przy założonym czasie (t) oraz założonym budżecie (b) dostarczymy system (S)
który dane wejściowe (i) przekształci w dane wyjściowe (o)
Haczyk tu tkwi, w tym, że większość programistów rzuca się na takie coś mimo, że nie dysponuje opisem „czym jest (S). Bo nie są nim ani przypadki użycia ani user story anie notatki z sesji JAD. Po drugie czym jest tenże „system”? Bez jego projektu nie da się określić ani terminu ani budżetu ani czasu wykonania. To tak jak by ktoś napisał, że „przy założonym czasie i budżecie zbuduje hotel wiedząc jedynie ilu gości będzie musiał przyjąć w ciągu doby”.
Podejrzewam, że autor po prostu miał tego pecha, że dostawał jakieś kiepskie analizy i projekty, bełkot, którego niestety jest masa. Wtedy jak najbardziej ma prawo mieć rację (trochę). ale co dalej znajdujemy na tym blogu:
Estymaty projektów przy zastosowaniu zasady 200% buforu bezpieczeństwa nadal rozpadają się jak zamki z piasku. Jak to kolega ujął próbując zamknąć definicję Agile w jednym zdaniu „klient nadal nie wie co chce, a my dostarczymy co mamy” (źr. Slow coding).
Proponuje mu albo jego kierownikom projektów (w sumie to nie wiem kogo tu oceniać…) więc poczytać:
oraz: książki Fowlera, Yourdona, Evansa czy tak zwanego Gangu Czworga.
Nie są to może jakieś wypasione projekty ale co do zasady są to owe workflowły i juemele do zapoznania się…:
Na zakończenie
Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta i drugie 20% jakie uczciwy dostawca doda mając dobry projekt …
Autor napisał swoją odpowiedź i dobrze, bo polemika kształci:
Autor napisał: „Po dogłębnym zapoznaniu się z pracami autora dzielę się moimi przemyśleniami i czekam na równie ciętą ripostę „, którą napisałem i niezbyt ciętą (nie to było celem) szkoda jednak, że tenże autor nie tylko stosuje tanie erystyczne chwyty w swoich wypowiedziach (np. przyrównywanie prawdziwości swoich tez do pewności odkrycia Kopernika: „postanowiłem trwać przy mej teorii iż to jednak Ziemia krąży wokół Słońca” co jest dość duża zarozumiałością, bo jeśli w kwestii układu słonecznego faktycznie nie mamy wątpliwości to można je mieć w kwestii wywodów tegoż autora), a w końcu usunął ze swojej strony (dlaczego?) po pewnym czasie moją krótką odpowiedź i link do jej pełnej wersji na tym blogu:
Od 1991 roku realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analiz systemowych i modelowania (ORCID). Od 2005 roku nieetatowy wykładowca akademicki, obecnie Wyższa Szkoła Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Czytaj więcej o autorze. Sprawdź dostępne Szkolenia i Warsztaty.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.