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.
Przecież analizę zrobimy sami, a jak nie – to zrobi to dostawca. Tak często rozpoczyna się tak zwana „Droga do klęski”. Jednym z typowych listów inicjujących współprace z wieloma moimi klientami był ten:
Planujemy wdrożenie nowego oprogramowania, chcemy tym razem uniknąć presji ze strony dostawcy oprogramowania. Poprzednim razem dostawca oprogramowania upraszczał sobie pracę, już na etapie analizy, którą wykonywał sam. Analiza wymagań polegała na wywiadach i warsztatach grupowych, skończyła się zwykłym opisem, tabelkami i kilkoma nieczytelnymi schematami. Podczas analizy i wdrożenia stale wmawiano nam, że „tego nie można”, „to należy uprościć” albo „tak się nie robi” my zaś nie potrafiliśmy tego ocenić. Wiele naszych potrzeb odkrywaliśmy dopiero podczas instalacji kolejnych prototypów, zaś dostawca unikał wprowadzania zmian i obiecanych dostosowań. Dostaliśmy w efekcie nieprzydatne i niezgodne z biznesowymi potrzebami oprogramowanie. Czy może nam Pan tym razem pomóc?
Czy to propaganda? Niestety nie. W czym problem? A mianowicie w metodzie prowadzenia analizy i potem treści specyfikacji wymagań. Łatwo powiedzieć: zebrać wymagania.
Powszechnie uważa się, że analiza wymagań na oprogramowanie to prosty, ale pracochłonny proces prowadzenia wywiadów i skrzętnego zapisywania tego, czego oczekuje przyszły użytkownik. Nic bardziej błędnego – jest to najgorszy sposób.
Wśród wielu tego typu metod są te najprostsze i najbardziej ryzykowne a mianowicie: wywiady, ankiety, [[sesje JAD]]. Sama ich istota zakłada, że klient wie co chce, należy to tylko z niego wyciągnąć i uporządkować. Być może czasami tak jest, ale z reguły kończy się to klasycznym stwierdzeniem klienta na koniec projektu:
Tak, dostarczyli nam Państwo dokładnie to co chcieliśmy ale zupełnie nie to, czego potrzebujemy.
Dlaczego tak się dzieje, choć wielu (analityków) tak bardzo się stara? Jak analiza może wyglądać napisałem tu już nie raz. Ale po co tyle zachodu? Dlaczego upieram się przy tych śmiesznych formalizmach, skoro można po ludzku zapisać co powiedział user a potem zamienić to na wypunktowane listy lub wiersze ładnej tabeli? Najlepiej jeszcze gdy liczą sobie najmniej kilkaset pozycji. Jednak tak pracuje analityk dyktafon.
Dobra specyfikacja wymagań na oprogramowanie, to wynik analizy i modelowania organizacji, kompromis pomiędzy możliwościami technologii a celami biznesowymi wdrożenia. Nie ma tu znaczenia czy będzie to gotowy system ERP, czy dedykowane rozwiązanie. Ale po kolei.
Czym grozi analityk dyktafon?
Tu pozwolę sobie skorzystać z zawartości krótkiego artykułu kolegi prowadzącego blog O wymaganiach. Poniżej kilka statystyk oraz mój komentarz co do ich przyczyn. a że problem jest poważny wystarczy wiedzeć, że:
Błędy w wymaganiach to jedna trzecia wszystkich defektów w projektach. [Dean Leffingwell, Don Widrig – „Managing Software Requirements” (1999)]
Produktem analizy wymagań są wymagania, jak już wspomniałem, można je zbierać metodami „rejestracyjnymi” (odpytywanie klientów) oraz „badawczymi”. Te drugie to kolejno: analiza i model organizacji klienta, identyfikacja celów biznesowych i czynników wpływających na ich osiągnięcie, projekt rozwiązania: co ma zostać dostarczone, opis projektu czyli specyfikacja produktu. Wywiady są łatwe a pełna analiza trudna. Nie trudno się więc domyślić, których się robi najwięcej. I mamy główną przyczynę, to właśnie:
Procesy związane ze zbieraniem wymagań są źródłem większości poważnych problemów z jakością. [Gerald Weinberg – „Quality Software Management” (1997)]
Jakość specyfikacji wymagań to między innymi jej kompletność, spójność itp. Jak dokument wymagań jest niskiej jakości to typowym objawem jest tak zwane odkrywanie wymagań w trakcie trwania projektu, czyli zmiany zakresu projektu, a:
Zmiany zakresu są jednym z najczęstszych źródeł dodatkowych kosztów w projektach i często prowadzą do porzucenia projektu. [Capers Jones – „Assessment and Control of Software Risks” (1994)]
Co jeszcze? Skąd te rozdęte budżety, przeterminowane projekty typu „czas i materiał”? Bo:
Naprawa błędów związanych z wymaganiami pochłania 70 – 80% kosztów ponownej pracy w projektach IT. A całkowite koszty ponownej pracy zjadają nawet do 50% kosztów projektu. [Dean Leffingwell – „Calculating and Return on Investment from More Effective Requirements Management” (1997)]
Kolejny etap, to koszty utrzymania:
Szukanie i naprawianie błędów wymagań po wdrożeniu systemu jest 100 razy kosztowniejsze niż szukanie i naprawianie tych samych błędów podczas zbierania wymagań. [Barry Boehm, Victor R. Basili – „Software Defect Reduction Top 10 List” (2001)]
I tyle o złych wymaganiach.
Analityk zamiast dyktafonu
Jeżeli wymagania specyfikuje się metodą prostej obserwacji (odsłuchu) otrzymujemy opis faktów a nie ich przyczyn. Rzecz a tym, że fakty nic nie mówią o ich przyczynach. Kolejny cytat:
Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: „Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku.” Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak tą metodą i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie. (źr. Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997).
Inny przykład, z nieco innej dziedziny ale doskonale oddający efekty polegania na obserwacji. Przez wiele lat uznawano, że Ziemia to centrum wszechświata. Ludzie obserwowali Niebo z Ziemi. To co widzą, po protu rejestrowali ufając, że sama obserwacja da właściwy wynik. W efekcie uzyskiwali takie oto trajektorie planet i gwiazd:
Nie dawały się opisać żadnym prostym równaniem, a te równania które powstawały były nie tylko przybliżeniami ale także bardzo złożonymi zależnościami dla każdego ciała niebieskiego z osobna. Powyższy rysunek to namiastka tego przynoszą z sobą analitycy obserwatorzy.
Prawdę odkrył i udokumentował Kopernik, człowiek który nie szukał poklasku ani u zwykłych ludzi patrzących z wiarą w niebo, ani u tych, w których interesie było, by Ci ludzie wierzyli, że Ziemia to stanowi centrum ich świata. Odkryta prawda w efekcie wszystkim dobrze służy ? mimo początkowego oporu, a wygląda ona tak:
System heliocentryczny jest prosty, zrozumiały dla każdego, łatwy do opisania (mimo to wielu ludziom nadal trudno się pogodzić z tym, że nie są pępkiem świata a jedynie jego częścią i to nie centralną). Poszczególne komórki organizacyjne w firmach i organizacjach, owe firmy na rynku, są jak poszczególne ciała niebieskie we wszechświecie, pracownicy tych organizacji jak różni obserwatorzy tego samego Nieba. Każdy ma swoje osobiste spojrzenie na swoją część ale nikt z nich nie widzi całości «z góry”. Każdy ma swój, geocentryczny widok. Typowe wywiady to zlepek takich opisów.
Praktyka pokazuje, że systemy (firmy, organizacje) obserwowane z ich wnętrza wydają się bardzo skomplikowane i tak też są opisywane przez większość ludzi (patrz wyżej diagram systemu geocentrycznego). W rzeczywistości większość systemów jest znacznie prostsza, jednak odkrycie tego wymaga głębokiego spojrzenia z zewnątrz.
Rzemieślnicy produkujący ?przed Kopernikiem? skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem tego modelu i swoich skomplikowanych przyrządów. Dlatego zapewne nie raz jeszcze usłyszę, że dobra analiza to setki stron, tysiące wymagań, miesiące pracy.
Jednak dobra analiza to tylko: dziesiątki stron i wymagań, tygodnie pracy ale zaawansowane metody takie jak formalna analiza systemowa oparta na modelach i ich testowaniu.
Warto jednak zaznaczyć, że tak jak projekty dedykowane mają sens od ok. 75 tys. zł. (wyliczenie w jednym zw wcześniejszych artykułów) tak zaprzęganie takich metod analizy ma sens nawet jeżeli wartość projektu (wartość ryzyka) przekracza już 10 tys. czyli nie tak wiele.… (koszt tego typu analiz to ok. 20% budżetu projektu).
Na zakonczenie cytat:
Niestety najczęstszymi przyczynami [problemów i dużych kosztów w projektach] są źle przeprowadzona analiza przedwdrożeniowa i niestety zbyt małe doświadczenie partnera wdrożeniowego. Zwłaszcza przy dużych projektach, gdzie specyfika przedsiębiorstwa wymaga oddzielnych rozwiązań uzupełniających i dużej wiedzy programistycznej, pojawiają się problemy. (źr. Wdrożenie ERP ? koszt czy zysk? – ERP ‑view.pl.)
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.
W styczniu tego (2011) roku napisałem: Mamy więc analizę biznesową i specyfikowanie wymagań poprzez opracowanie weryfikowalnych modeli a nie tylko listę potrzeb, której niestety nie da się zweryfikować co do kompletności i spójności bo nie ma narzędzia sprawdzającego. Co jest takim narzędziem? Ano modele i to, że powstały (jeżeli powstały) przy pomocy sformalizowanej notacji. (źr. Analiza przedwdrożeniowa ? czym jest | Jarosław Żeliński – rynek IT, analiza biznesowa i projektowanie systemów).
Przyszła pora na opisanie samej analizy. Skoro więc analiza bazuje na modelach, najczęściej diagramach, pokusiłem się na, tym razem na nieformalny diagram obrazujący analizę systemową w kontekście inżynierii oprogramowania.
Mamy dwa elementy tej analizy: analizę systemową jako proces główny oraz modele jako narzędzia testowania hipotez. W przypadku projektowania celem jest projekt rozwiązania.
Standardowym narzędziem stosowanym przez większość analityków wymagań do przekazania wymagań na oprogramowanie jest ich specyfikacja. Problem w tym, że pierwszym testem tej specyfikacji jest tak na prawdę dopiero ich implementacja.
Alternatywnym podejściem jest analiza systemowa i modelowanie. Problem do rozwiązania to opracowanie oprogramowania, które zrealizuje cel zamawiającego. Zamiast jednak, np. z pomocą wywiadów, spisywać, nie poddające się żadnym testom, oczekiwania zamawiającego, tworzymy dwa modele:
najpierw model firmy zamawiającego by na nim przetestować zrozumienie działanie samej firmy i ewentualnie ją nieco „zoptymalizować”,
model przyszłego oprogramowania, które ma zaspokoić potrzeby zamawiającego czyli zrealizowawszy jego cel.
Celem jest oprogramowanie a dostawcy oprogramowania najmniej ryzykują gdy dostaną jego specyfikuję czyli gotowy projekt. Tak wiec przetestowany model oprogramowania realizujący cel zamawiającego jako wynik analizy systemowej stanowi nic innego jak opis produktu, który ma powstać. Oczywiście nikt nie projektuje od zera oprogramowania biznesowego bo to nierozsądne, wykorzystuje się tak zwane szkielety oprogramowania. O szkieletach już było tu: Frameworks Introduction ? czyli jak się psuje dobre ERP. A teraz zapraszam do obejrzenia tego co tu napisałem po mojemu czyli na diagramie 🙂 (tak zwane mapy myśli czasami sie przydają :)).
Warto tu zwrócić uwagę na jedną rzecz: ewentualne zmiany rozwiązania i korekty modelu (czyli projektu) odbywają się nadal na etapie analizy i projektowania, a wiec o rząd albo dwa taniej, niż podczas implementacji. Jest to główna przewaga tej metody nad analizą w postaci sesji JAD ([[JAD, ang. Joint Application Development]] – oznacza współtworzenie aplikacji, które czasami postrzegam jako świadome angażowanie klienta w proces projektowania by potem uczynić go współwinnym niepowodzenia) i opracowywania strukturalnych dokumentów.
Jeżeli zrezygnujemy z modeli pozostaje nam ryzykowna sesja warsztatowa (niejedna):
Przygotowując warsztat zbierania wymagań musisz być pewien, że zaprosisz na niego właściwe osoby. Pamiętaj wtedy, że:
Twoi bezpośredni klienci (prezesi, dyrektorzy, właściciele firm) często nie znają tak naprawdę potrzeb i kontekstu pracy przyszłych użytkowników końcowych zamawianego systemu.
Użytkownicy końcowi nie zawsze znają i rozumieją potrzebę biznesową dla tworzenia nowego oprogramowania.
Klienci i użytkownicy końcowi nie znają technologii tak dobrze jak Ty i Twoja firma, więc nie będą w stanie zrozumieć szczegółów rozwiązań technicznych w tworzonym systemie.
Ty i Twoja firma możecie nie rozumieć w pełni potrzeb klienta i problemu, który tworzone oprogramowanie ma rozwiązać.
Co z tym zrobić? Pamiętaj, aby zadbać, żeby przedstawiciele wszystkich powyższych grup brali udział w warsztatach, wówczas interes każdej ze stron będzie reprezentowany. (źr. serwis O wymaganiach)
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.