Jeśli zapytasz stu ludzi, jak wyobrażają sobie piłkę, każdy powie Ci co innego. Ile osób, tyle różnych spojrzeń na każdy temat. Dlaczego więc zakładasz, że dokładnie wiesz, czego potrzebuje Twój klient? Dlaczego zakładasz, że Twój klient wie, co masz na myśli, gdy proponujesz mu wizję nowego systemu informatycznego???
Między biznesem a IT
W wynikach badań na temat przyczyn porażek projektów IT najczęściej przewijają się trzy najważniejsze czynniki: problemy komunikacyjne, niekompletne wymagania i brak zaangażowania użytkowników. Projekty nie udają się wcale nie dlatego, że temat jest trudny i nie ze względu na kłopoty techniczne czy finanse. Najwięcej problemów powstaje wtedy, gdy klient i usługodawca nie są w stanie się porozumieć.
Punktem wyjścia dla każdego systemu są wymagania klientów i użytkowników. Wiele już napisano o zarządzaniu wymaganiami, klasyfikowaniu wymagań, diagramach i niezliczonej ilości narzędzi informatycznych. Jednak aby wymaganiami zarządzać, trzeba je najpierw zebrać. Ta książka koncentruje się na etapie kompletowania wymagań. Podsuwa sposoby takiego zbierania informacji, aby w trakcie wywiadu z klientem lub użytkownikiem bardzo dokładnie zrozumieć ich problemy i potrzeby. To jedyny sposób, aby stworzyć dla nich oprogramowanie na miarę.
W branży IT jak dogmat powtarza się przekonanie, że 'klient nie wie, czego chce '. Przyszedł czas, aby się z nim zmierzyć.
Michał Bartyzel - konsultant i trener w firmie szkoleniowo-doradczej BNS IT. Zajmuje się doskonaleniem programistów i zespołów programistycznych, wdrażaniem metodyk pracy oraz rozwijaniem kompetencji pracowników branży IT. Prowadzi szkolenia oraz konsultacje z zakresu inżynierii oprogramowania, zwiększania efektywności zespołów projektowych i zarządzania projektami programistycznymi.
Darmowy fragment publikacji:
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości
lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione.
Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie
książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie
praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi
bądź towarowymi ich właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte
w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej
odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne
naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION
nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe
z wykorzystania informacji zawartych w książce.
Redaktor prowadzący: Magdalena Dragon
Projekt okładki: Jan Paluch
Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie?opszmi
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
ISBN: 978-83-246-3932-8
Copyright © Michał Bartyzel 2012
Printed in Poland.
• Kup książkę
• Poleć książkę
• Oceń książkę
• Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis treħci
Podziēkowania .........................................................9
Rozdziaã 1. Miēdzy biznesem a IT ................................ 11
Dla kogo jest przeznaczona ta ksiÈĝka? ......................................... 12
Ile zarzÈdzania jest w zarzÈdzaniu wymaganiami? ......................... 15
Klient, który wie, czego chce .......................................................... 17
Podsumowanie ............................................................................... 20
Rozdziaã 2. Co to znaczy „myħleĄ biznesowo”? ............... 21
Nonszalancja programistów ........................................................... 21
Podsumowanie ............................................................................... 25
Rozdziaã 3. Wspólna wizja ......................................... 27
Czym jest wizja? ............................................................................. 27
Wizja a zakres systemu ................................................................... 29
Formuïowanie wizji ........................................................................ 31
Nazwa jest waĝna ........................................................................... 33
Kiedy wizja bywa niebezpieczna? ................................................... 35
Podsumowanie ............................................................................... 36
Rozdziaã 4. Rozpoznanie procesu biznesowego ............... 37
Proces biznesowy, czyli co siÚ dzieje u klienta? ............................. 38
Podsumowanie ............................................................................... 43
Rozdziaã 5. Sztuka zadawania pytaĝ ............................ 45
Kto prowadzi rozmowÚ? ................................................................ 45
Podstawowa struktura rozmowy .................................................... 46
Konkretyzowanie ............................................................................ 51
Uogólnianie .................................................................................... 89
Peïen cykl konkretyzowania i uogólniania ................................... 105
Podsumowanie ............................................................................. 108
6
O P R O G R A M O W A N I E S Z Y T E N A M I A R Ē
Rozdziaã 6. Techniki rozszerzajĎce
podstawowe algorytmy rozmowy ................113
WiÚcej na temat pytañ .................................................................. 113
Parafrazowanie ............................................................................. 129
Technika pozytywnej intencji ....................................................... 136
Przejmowanie kierunku rozmowy ................................................ 141
Ramy odniesienia i zmiana ram .................................................... 144
Podsumowanie ............................................................................. 156
Rozdziaã 7. Ustalanie priorytetów wymagaĝ ..................157
Pytanie i eliminowanie ................................................................. 158
WaĝnoĂÊ a pilnoĂÊ ........................................................................ 163
Excelowe czary-mary .................................................................... 171
Podsumowanie ............................................................................. 174
Rozdziaã 8. Spotkania ..............................................177
Efektywne spotkania i te, podczas których tylko tracisz czas ...... 179
Przygotowanie spotkania ............................................................. 181
Prowadzenie spotkania ................................................................ 191
Podsumowanie koñcowe .............................................................. 197
Zamykanie spotkania ................................................................... 198
Formuïy spotkañ na róĝne okazje ................................................ 200
Podsumowanie ............................................................................. 207
Rozdziaã 9. Techniki prowadzenia rozmowy
na temat wymagaĝ w piguãce .....................209
Wizja ............................................................................................ 210
Konkretyzowanie .......................................................................... 210
Technika skrzynki ........................................................................ 212
Ekrany uĝytkownika ..................................................................... 213
Uogólnianie .................................................................................. 214
PowiÚkszanie przestrzeni moĝliwych rozwiÈzañ .......................... 215
Róĝne rodzaje pytañ ..................................................................... 215
Parafrazowanie ............................................................................. 217
Technika pozytywnej intencji ....................................................... 218
S p i s t r e ħ c i
7
Przejmowanie kierunku rozmowy ................................................ 219
Zmiana ram odniesienia ............................................................... 220
Ustalanie priorytetów za pomocÈ pytañ ....................................... 221
Spotkania ..................................................................................... 222
Rozdziaã 10. Kiedy techniki przedstawione
w tej ksiĎijce NIE zadziaãajĎ? ....................225
Lektura uzupeãniajĎca .............................................227
Rozdziaã 3.
Wspólna wizja
Wyobraě sobie okno z przyciskiem Zamknij. Jak wyglÈda Twoje
wyobraĝenie? Jaki kolor ma okno? Po której stronie umieszczony
jest przycisk? Czy przycisk ma obrazek, czy nie? Czy napis Zamknij
ma aktywny znak? Z pewnoĂciÈ Twoje wyobraĝenie jest róĝne od
wyobraĝeñ innych czytelniczek i czytelników. To naturalne, ĝe kaĝdy
z nas ma indywidualne preferencje i wyobraĝenia. Kaĝdy z nas jest
inny. Poszczególne elementy naszej osobowoĂci powstaïy w wyniku
rozwoju spoïecznego lub, jak chcÈ niektórzy, sÈ w jakiejĂ czÚĂci uwa-
runkowane genetycznie. SkÈdkolwiek pochodzÈ, stanowiÈ waĝny
skïadnik naszej osobowoĂci. NaprawdÚ zaczyna byÊ zabawnie, gdy
kilka chodzÈcych oryginalnych osobowoĂci spotyka siÚ przy jednym
stole i ma za zadanie wymyĂliÊ CO¥ (z uwagi na róĝne oblicza tego
CZEGO¥ nazywajmy to produktem programistycznym lub w uprosz-
czeniu aplikacjÈ, oprogramowaniem albo systemem).
Czym jest wizja?
Podobnie jak z wyobraĝeniem sobie okna z przyciskiem, tak w przy-
padku nowego systemu informatycznego opinie kaĝdego z czïonków
zespoïu na temat tego, co naleĝy zrobiÊ, mogÈ byÊ bardzo zróĝni-
cowane. Tyle ĝe w przypadku projektów informatycznych juĝ nie
chodzi o zabawÚ w wyobraĝenia, lecz o bardzo wymierne korzyĂci
28
O P R O G R A M O W A N I E S Z Y T E N A M I A R Ē
lub straty liczone w twardej walucie. Z tego wzglÚdu pierwszÈ rzeczÈ,
którÈ naleĝy zrobiÊ podczas przygotowañ do projektu, jest ustalenie
ze wszystkimi zaangaĝowanymi osobami, do czego naleĝy zmierzaÊ.
Innymi sïowy: ustalenie wizji nowego systemu, którÈ bÚdÈ wspóï-
dzieliÊ wszystkie osoby zaangaĝowane w projekt (rysunek 3.1).
Rysunek 3.1. Wspólna wizja
Kto jest odpowiedzialny za wizjē?
Ustalenie wizji systemu
z biznesem to pierwszy
krok w pracach nad nowym
oprogramowaniem,
jego kolejnĎ wersjĎ lub
nad nowymi moduãami.
Wizja oczywiĂcie pochodzi od biznesu, gdyĝ to cele biznesowe system
ma realizowaÊ. Jednak za ustalenie
wizji, a nastÚpnie za jej realizowanie
odpowiedzialna bÚdzie osoba, która
otrzymaïa zadanie zdefiniowania, czego
biznes potrzebuje, i ma na tej podsta-
wie okreĂliÊ zakres prac dla IT. Naj-
czÚĂciej ta osoba nazywana jest „analitykiem”. JeĂli wiÚc odgrywasz
rolÚ analityka, szczególnie uwaĝnie przeczytaj ten rozdziaï.
W s p ó l n a w i z j a
29
Wizja jest po prostu „wyciagniÚciem na wierzch” tego, co Ty,
Twój klient i inne osoby, które sÈ zaangaĝowane w przedsiÚwziÚcie,
myĂlicie, gdy zastanawiacie siÚ nad pytaniem: Jaki/Czym bÚdzie ten
system? WyciÈgamy wszystkie warianty rozwiÈzañ na wierzch, a po-
tem ustalamy wspólnÈ odpowiedě na wspomniane pytanie.
Wizja a zakres systemu
Po pierwszym kontakcie z wizjÈ moĝe nam siÚ wydawaÊ, ĝe to nic
nieznaczÈce sformuïowanie, które zniknie gdzieĂ w odmÚtach ogrom-
nego dokumentu SRS (ang. Software Requirements Specification).
CoĂ, co w dokumencie musi byÊ, bo jest wymagane, ale nie warto
przywiÈzywaÊ do tego wiÚkszej wagi. Nic bardziej mylnego! Wizja to
niezwykle prosty i uĝyteczny sposób precyzowania zakresu systemu.
PRZYKâAD
Wyobraě sobie nastÚpujÈcÈ sytuacjÚ: ustaliïeĂ z klientem, ĝe celem
projektu bÚdzie system do zarzÈdzania kontaktami z klientami, na-
zywany skrótowo CRM (ang. Customer Relationship Management).
Podczas jednego ze spotkañ rozmowa przebiega jak poniĝej.
[Klient]: Chciaïbym, ĝeby doszïa tu funkcjonalnoĂÊ raportowania
sprzedaĝy kwartalnej.
[Ty]: Ale przecieĝ nie mówiliĂmy o tym wczeĂniej…
[Klient]: OczywiĂcie, ĝe tak. Wspominaïem o raportach sprzedaĝy.
[Ty]: Tak, ale póïrocznych i rocznych. O kwartalnych nie.
[Klient]: No, raport to raport. Chyba nie bÚdzie z tym kïopotu?
[Ty]: Hmm…
30
O P R O G R A M O W A N I E S Z Y T E N A M I A R Ē
Przedstawiony dialog w takiej czy innej wersji powtarza siÚ w naszej
pracy wyjÈtkowo czÚsto. Z grubsza rzecz biorÈc: chodzi o to, czy
zgïaszana funkcjonalnoĂÊ mieĂci siÚ w obszarze kontraktu i kto
za jej wykonanie zapïaci. Chodzi wiÚc, ni mniej ni wiÚcej, o zakres
systemu, zakres prac, do wykonania których siÚ zobowiÈzujesz.
PRZYKâAD
Zaïóĝmy, ĝe wizja systemu zostaïa zdefiniowana nastÚpujÈco: CRM
sprzedaĝowy to oprogramowanie webowe dla przedstawicieli handlowych,
które pozwoli na bieĝÈce wyznaczanie zadañ sprzedaĝowych i uproĂci
generowanie raportów w zwiÈzku z zamykaniem roku obrotowego.
Podczas wspomnianego spotkania rozmowa mogïaby przebiegaÊ
nastÚpujÈco:
[Klient]: Chciaïbym, ĝeby doszïa tu funkcjonalnoĂÊ raportowania
sprzedaĝy kwartalnej.
[Ty]: Ale przecieĝ nie mówiliĂmy o tym wczeĂniej…
[Klient]: OczywiĂcie, ĝe tak. Wspominaïem o raportach sprzedaĝy.
[Ty]: Tak, lecz czy to mieĂci siÚ w ustalonym zakresie prac, w którym
CRM „upraszcza generowanie raportów na zamkniÚcie roku obrotowego”?
[Klient]: Hmm…
PosïugujÈc siÚ wizjÈ, mogïeĂ bez problemu ustaliÊ, czy nowe
wymaganie naleĝy do zakresu prac, czy nie. PodkreĂlmy wyraěnie: nie
chodzi tu o wyprowadzenie klienta na manowce. Chodzi przede
wszystkim o szybkie, jednoznaczne i nienaruszajÈce relacji interperso-
nalnych okreĂlenie, czy nowa funkcjonalnoĂÊ mieĂci siÚ w ustalo-
nym wczeĂniej zakresie prac, czy nie (rysunek 3.2). Chodzi o jasnÈ
odpowiedě na pytanie: Kto zapïaci za TwojÈ pracÚ?
W s p ó l n a w i z j a
31
Rysunek 3.2. Które wymagania wchodzÈ do zakresu prac?
Nawet najciekawsze technicznie systemy tworzone sÈ z zaïoĝe-
niem, ĝe „zarobiÈ na siebie”. Kaĝda aktywnoĂÊ podjÚta w projekcie
jest w konsekwencji i tak przeliczana na pieniÈdze. PieniÈdze, które
musisz wydaÊ Ty lub Twój klient. To, ĝe wizja pozwala w prosty
sposób, bez zbÚdnych konfliktów, zaliczyÊ zlecone prace na Twoje
konto lub na konto Twojego klienta, czyni z niej praktyczne i po-
tÚĝne narzÚdzie wspóïpracy z biznesem.
Formuãowanie wizji
Zgodnie z naszÈ definicjÈ: wizja jest wspólnÈ odpowiedziÈ wszystkich
zaangaĝowanych osób z biznesu na pytanie: Jaki/Czym bÚdzie ten
system? W tej definicji istotne jest sïowo wspólna. Wizja powinna
byÊ wypracowana wspólnie z klientem (z kluczowymi decydentami).
Moĝe siÚ odbyÊ w trakcie moderowanego przez Ciebie spotkania.
Wtedy powstaje wizja marzenie, do którego wszyscy bÚdÈ od tej
chwili zmierzaÊ.
32
O P R O G R A M O W A N I E S Z Y T E N A M I A R Ē
Kolejnym naturalnym krokiem jest komunikowanie wizji reszcie
zespoïu i decydentów, aby dosïownie kaĝdy zaangaĝowany w pro-
jekt dokïadnie tak samo rozumiaï efekt koñcowy.
Wizja jako krótki opis
Najprostszym sformuïowaniem wizji jest krótki opis w postaci zdania:
System NAZWA jest to PRZEZNACZENIE,
GÓWNE FUNKCJONALNO¥CI .
PRZYKâAD
System CRM sprzedaĝowy to narzÚdzie CRM dla sprzedawców, które
ujednolica sposób przechowywania informacji na temat klientów.
Arkusz wizji
SzczegóïowÈ metodÚ konsolidowania wizji zaproponowaï Karl
Wiegers w Software Requirements w postaci siedmiopunktowego arku-
sza wizji, który zamieszczam w tabeli 3.1.
Tabela 3.1. Arkusz wizji
Element wizji
Jak siē nazywa produkt?
Jakiej kategorii/klasy jest to produkt?
Dla kogo jest przeznaczony?
Jakie potrzeby zaspokaja?
Jakie moijliwoħci wykorzystuje?
Przykãad
System „CRM sprzedaijowy”
jest aplikacjĎ webowĎ klasy CRM
przeznaczonĎ dla sprzedawców
i marketingowców,
którzy potrzebujĎ wsparcia procesu
sprzedaijy usãug szkoleniowych.
W s p ó l n a w i z j a
33
Tabela 3.1. Arkusz wizji — ciÈg dalszy
Element wizji
Przykãad
Jakie przynosi korzyħci,
za które klient zechce zapãaciĄ?
Jakie sĎ alternatywy?
Co odróijnia produkt od konkurencyjnych
alternatyw?
CRM sprzedaijowy przeprowadza
sprzedawcē i marketingowca przez
peãen proces sprzedaijy, w którym
to klient jest centrum procesu, dziēki
czemu oszczēdzimy uijytkownikom
koniecznoħci pamiētania o terminach
i etapach procesu.
W przeciwieĝstwie do obecnej sytuacji,
w której kaijdy z naszych sprzedawców
ma wãasnĎ metodē dziaãania,
co powoduje sporo zamieszania,
CRM sprzedaijowy ujednolica caãy
proces sprzedaijy. Pozwala równieij
zintegrowaĄ siē z systemem organizacji
szkoleĝ.
Nazwa jest waijna
Jeden z moich klientów nazwaï kiedyĂ system, nad którym wspólnie
pracowaliĂmy, Zintegrowanym systemem informatycznym (ZSI). Ta
z pozoru neutralna nazwa spowodowaïa sporo zamieszania. Byïem
niemal zmuszony do godzenia siÚ na wszystkie kolejne funkcjo-
nalnoĂci.
[Klient]: Jakĝe by ich mogïo zabraknÈÊ w Zintegrowanym systemie
informatycznym?
[Ja]: Ale przecieĝ to siÚ nie uda!
Nic z tego. ZSI to ZSI i musi mieÊ wszystkie funkcjonalnoĂci,
których klient od niego oczekiwaï.
Zrozumiaïem potem, jaki bïÈd popeïniïem. Gdy nadajesz czemuĂ
nazwÚ, to ta nazwa zaczyna budowaÊ Twoje oczekiwania w stosunku
do nazwanej tak rzeczy. Gdy nazwiesz buty butami sportowymi, to
bÚdziesz oczekiwaï, ĝe bÚdÈ wygodne podczas biegania. Gdy nazwiesz
34
O P R O G R A M O W A N I E S Z Y T E N A M I A R Ē
buty butami wizytowymi, to bÚdziesz oczekiwaï, ĝe bÚdÈ siÚ dobrze
prezentowaÊ w zestawieniu z garniturem. JeĂli zatem nieopatrznie
nazwiesz tworzony system nieadekwatnÈ nazwÈ, to klienci bÚdÈ ocze-
kiwaÊ od systemu innych funkcjonalnoĂci, niĝ powinni.
W opisanym przykïadzie Zintegrowanego systemu informatycznego
nazwa byïa zbyt ogólna, w zwiÈzku z tym niemal kaĝda funkcjonal-
noĂÊ pasowaïa do zakresu tak nazwanego systemu.
Nowemu produktowi
nadawaj konkretne nazwy,
zwiĎzane z rzeczywistoħciĎ
(dziedzinĎ) informatyzowa-
nego procesu.
JeĂli nadamy nazwÚ konkretnÈ, np.: System obiegu dokumentów,
System zarzÈdzania produkcjÈ rowerów, System katalogowania produktów
w hurtowni, to nazwa ta przekazuje w miarÚ jednoznacznÈ in-
formacjÚ o tym, które funkcjonalnoĂci mieszczÈ siÚ w zakresie
prac nad systemem, a które nie. Od-
powiednia nazwa powinna ogniskowaÊ
oczekiwania klientów na tym, czym
w istocie jest tworzony system, oraz po-
magaÊ odrzucaÊ zbÚdne funkcjonalnoĂci,
zwane potocznie wodotryskami. Jest przecieĝ oczywiste lub ïatwe
do wykazania, ĝe odgrywanie plików mp3 nie jest typowÈ funkcjo-
nalnoĂciÈ Systemu ksiÚgowego. Trudno jednak bÚdzie przeprowadziÊ
podobne rozumowanie w przypadku Zintegrowanego systemu infor-
matycznego — skoro zintegrowany, to dlaczego nie mp3?
Dobra nazwa powinna odwoïywaÊ siÚ do tego, co klienci juĝ
znajÈ — do rzeczywistoĂci (dziedziny) informatyzowanego procesu.
JeĂli tworzysz oprogramowanie wspierajÈce dziaï HR, to oczywiĂcie
moĝna mu nadaÊ nazwÚ Szybki Lopez, ale czy to komukolwiek co-
kolwiek mówi? Klienci bÚdÈ musieli nauczyÊ siÚ odpowiedniego ro-
zumienia sformuïowania Szybki Lopez, a to zabierze nieco czasu.
Lepiej odwoïaÊ siÚ do doĂwiadczenia zaangaĝowanych osób i na-
zwaÊ oprogramowanie Kadry i pïace.
Nic nie stoi na przeszkodzie, aby stosowaÊ równieĝ nazwy ïÈczone,
np.: Szybki Lopez — kadry i pïace. W ten sposób wszyscy zaanga-
W s p ó l n a w i z j a
35
ĝowani w projekt zacznÈ doĂÊ szybko posïugiwaÊ siÚ krótkÈ nazwÈ
Szybki Lopez, lecz przypiszÈ tej nazwie to samo znaczenie, co na-
zwie Kadry i pïace, a o to przecieĝ chodziïo.
Kiedy wizja bywa niebezpieczna?
Czy po wszystkich zaletach wizji, które wymieniliĂmy, moĝna za-
stanawiaÊ siÚ nad tym, czy wizja jest niebezpieczna? OczywiĂcie, ĝe
moĝna. Kaĝde narzÚdzie czy metoda ma ograniczony zakres stoso-
wania. Wizja równieĝ.
Wizja staje siÚ niebezpieczna, kiedy sïuĝy do wyciÈgania wnio-
sków na temat systemu, który opisuje.
PRZYKâAD
Powiedzmy, ĝe tworzysz system, którego wizja zostaïa okreĂlona
nastÚpujÈco:
SuperTest jest systemem do przeprowadzania badañ satysfakcji
klienta banku.
Wyobraě sobie, ĝe w ramach Twojej organizacji powstaïa kon-
cepcja innego systemu okreĂlonego wizjÈ:
T-Expert jest systemem do przeprowadzania badañ potrzeb
szkoleniowych wĂród programistów.
WĂród klientów, zwïaszcza tych, którzy sÈ daleko od zagadnieñ
technicznych, mogÈ siÚ pojawiÊ wnioski oparte na nastÚpujÈcym
rozumowaniu:
Skoro SuperTest sïuĝy do przeprowadzania badañ
oraz T-Expert bÚdzie sïuĝyï do przeprowadzania badañ,
zatem do budowy systemu T-Expert moĝna uĝyÊ juĝ istniejÈcych
36
O P R O G R A M O W A N I E S Z Y T E N A M I A R Ē
moduïów systemu SuperTest. Tworzenie T-Experta bÚdzie
wiÚc trwaïo krócej i kosztowaïo mniej.
Z pewnoĂciÈ widzisz ogrom zagroĝenia powstaïego z powodu nie-
prawidïowego wnioskowania, które opiera siÚ na sformuïowaniach
wizji. Takie wnioskowanie byïo moĝliwe, poniewaĝ wizja zostaïa
uĝyta niezgodnie z jej przeznaczeniem. Zamiast wskazywaÊ cel, do
którego zmierzamy, staïa siÚ podstawÈ wnioskowania. Raczej nie po-
wstrzymasz klientów przed wyciÈganiem tego typu ogólnych wnio-
sków. Jedyne co moĝesz zrobiÊ, to byÊ na nie wyczulonym i w porÚ
interweniowaÊ.
Podsumowanie
Z tego rozdziaïu dowiedziaïeĂ siÚ, czym jest wizja oraz jak duĝy ma
wpïyw na zakres tworzonego oprogramowania. RozmawialiĂmy
o dwóch sposobach definiowania wizji:
poprzez krótki opis,
z uĝyciem arkusza wizji.
Pobierz darmowy fragment (pdf)