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-Philipczyk
Projekt okładki: ULABUKA
Rysunki: Maria Pankowska
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail:
onepress@onepress.pl
WWW:
http://onepress.pl (księgarnia internetowa, katalog książek)
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://onepress.pl/user/opinie/opszm2
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
ISBN: 978-83-246-9826-4
Copyright © Michał Bartyzel 2015
Printed in Poland.
Spis treĞci
WstĊp do wydania drugiego ........................................... 9
WstĊp do wydania pierwszego ....................................... 11
Rozdziaá 1. MiĊdzy biznesem a IT ..................................13
Dla kogo jest ta ksiąĪka? .................................................................. 14
Ile zarządzania jest w zarządzaniu wymaganiami? .........................17
Klient, który wie, czego chce ............................................................ 19
Podsumowanie .................................................................................22
Rozdziaá 2. Co to znaczy „myĞleü biznesowo”? .............. 23
Nonszalancja programistów ............................................................23
Podsumowanie .................................................................................29
Rozdziaá 3. Wspólna wizja .............................................31
Czym jest wizja? ...............................................................................32
Wizja a zakres systemu ....................................................................33
Formuáowanie wizji .......................................................................... 35
Nazwa jest waĪna .............................................................................36
Wizja jest wspóádzielona albo nie ma jej wcale ...............................39
Kiedy wizja bywa niebezpieczna? ....................................................42
Podsumowanie .................................................................................43
Rozdziaá 4. Rozpoznanie procesu biznesowego ............ 45
Proces biznesowy, czyli co siĊ dzieje u klienta ................................ 47
Podsumowanie ................................................................................. 51
Oprogramowanie szyte na miarĊ
– 6 –
Rozdziaá 5. Sztuka zadawania pytaĔ ..............................53
Kto prowadzi konwersacjĊ? ............................................................. 53
Co to znaczy patrzeü z perspektywy klienta? .................................. 54
ĝwiadomoĞü sáownictwa w trakcie konwersacji ............................. 58
Podsumowanie ..................................................................................61
Rozdziaá 6. Odkrywanie potrzeb ...................................63
Czym jest potrzeba? ......................................................................... 64
Podsumowanie ................................................................................. 89
Rozdziaá 7. Sztuka konwersacji z klientem .................... 91
Podstawowa struktura konwersacji ................................................ 92
Konkretyzowanie wymagaĔ ............................................................ 97
Uogólnianie wymagaĔ ....................................................................132
Radzenie sobie z impasem w trakcie konwersacji .........................144
Proponowanie alternatywnych rozwiązaĔ .....................................149
Podsumowanie ................................................................................152
Rozdziaá 8. Pytania trafiające w samo sedno ............... 153
Bufor bezuĪytecznych odpowiedzi .................................................153
Pytania zamkniĊte i otwarte .......................................................... 160
WyraĪanie oczekiwaĔ poprzez zaprzeczenie .................................162
Ramy odniesienia i zmiana ram .....................................................166
Podsumowanie ................................................................................176
Rozdziaá 9. Czy miĊdzy nami jest chemia? ....................177
Mechanika a chemia konwersacji .................................................. 177
Parafrazowanie ...............................................................................178
Technika pozytywnej intencji .........................................................184
Przejmowanie kierunku konwersacji .............................................189
Chemia konwersacji w duchu Nonviolent Communication ..........193
Podsumowanie ...............................................................................208
Rozdziaá 10. Ustalanie priorytetów wymagaĔ ............. 209
Pytanie i eliminowanie .................................................................. 210
WaĪnoĞü a pilnoĞü ...........................................................................215
Excelowe czary-mary ..................................................................... 222
Podsumowanie ............................................................................... 225
Spis treĞci
– 7 –
Rozdziaá 11. Spotkania .................................................227
Spotkania efektywne i te, podczas których tylko tracisz czas .......229
Przygotowanie spotkania ............................................................... 231
Prowadzenie spotkania .................................................................. 241
Zamykanie spotkania .....................................................................247
Formuáy spotkaĔ na róĪne okazje .................................................248
Podsumowanie ...............................................................................256
Rozdziaá 12. Techniki zbierania wymagaĔ w piguáce ....257
Wizja ...............................................................................................258
Odkrywanie potrzeb .......................................................................259
Konkretyzowanie ........................................................................... 260
Technika skrzynki ..........................................................................262
Ekrany uĪytkownika ......................................................................263
Uogólnianie ....................................................................................263
PowiĊkszanie przestrzeni moĪliwych rozwiązaĔ ...........................265
Proponowanie alternatywnych rozwiązaĔ ....................................265
Pytania trafiające w samo sedno ...................................................266
Zmiana ram odniesienia ................................................................267
Parafrazowanie ...............................................................................268
Technika pozytywnej intencji ........................................................269
Przejmowanie kierunku rozmowy .................................................270
Komunikacja wedáug modelu NVC ............................................... 271
Ustalanie priorytetów za pomocą pytaĔ ........................................272
Spotkania ........................................................................................274
Rozdziaá 13. Kiedy techniki przedstawione
w tej ksiąĪce NIE zadziaáają? .......................................277
Lektura uzupeániająca ................................................ 279
Rozdziaá 3.
Wspólna wizja
R
YSUNEK
3.1. Wspólna wizja
yobraĨ 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 czytel-
ników. To naturalne, Īe kaĪdy z nas ma indywidualne preferencje
i wyobraĪenia. KaĪdy z nas jest inny. Poszczególne elementy naszej
W
Oprogramowanie szyte na miarĊ
– 32 –
indywidualnoĞci powstaáy w wyniku rozwoju spoáecznego lub, jak chcą
niektórzy, są w jakiejĞ czĊĞci uwarunkowane genetycznie. Skądkol-
wiek pochodzą, stanowią waĪny skáadnik naszej osobowoĞci. NaprawdĊ
zabawnie zaczyna siĊ robiü, gdy kilka indywidualnoĞci spotyka siĊ przy
jednym stole i ma za zadanie stworzyü COĝ (z uwagi na róĪne obli-
cza tego CZEGOĝ nazwijmy to produktem programistycznym lub
w uproszczeniu: aplikacją, oprogramowaniem albo systemem).
Czym jest wizja?
Podobnie jak z wyobraĪeniem sobie okna z przyciskiem, tak rów-
nieĪ w przypadku nowego systemu informatycznego opinie kaĪdego
z czáonków zespoáu na temat tego, co naleĪy zrobiü, mogą byü bardzo
zróĪnicowane. Tyle Īe w przypadku projektów informatycznych juĪ
nie chodzi o zabawĊ w wyobraĪenia, lecz o bardzo wymierne korzyĞci
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).
Kto jest odpowiedzialny za wizjĊ?
Wizja oczywiĞcie pochodzi od biznesu, gdyĪ to cele biznesowe system
ma realizowaü. Jednak za ustalenie wizji, a nastĊpnie za jej realizowa-
nie, odpowiedzialna bĊdzie osoba, która otrzymaáa za zadanie zdefi-
niowaü, czego biznes potrzebuje, i na tej podstawie okreĞliü zakres
prac dla IT. NajczĊĞciej ta osoba nazywana jest klientem albo wáaĞci-
cielem produktu
1
. JeĞli wiĊc peánisz funkcjĊ analityka, szczególnie
uwaĪnie przeczytaj ten rozdziaá.
1
W jĊzyku angielskim Product Owner.
Wspólna wizja
– 33 –
Ustalenie wizji systemu z biznesem to pierwszy krok w pracach nad nowym oprogra-
mowaniem, jego kolejnÈ wersjÈ lub nad nowymi moduïami.
Wizja jest po prostu „wyciągniĊciem na wierzch” tego, co Ty, Twój
klient i inne osoby zaangaĪowane w przedsiĊwziĊcie myĞlicie, gdy
zastanawiacie siĊ nad pytaniem: Jaki/czym bĊdzie ten system? Wycią-
gamy wszystkie odpowiedzi na powierzchniĊ, a potem ustalamy
wspólną odpowiedĨ na wspomniane pytanie.
Wizja a zakres systemu
Po pierwszym kontakcie z wizją moĪe siĊ nam wydawaü, Īe to nic
nieznaczące sformuáowanie, które zniknie gdzieĞ w odmĊtach ogrom-
nego dokumentu SRS
2
. CoĞ, co w dokumencie musi byü, bo jest wyma-
gane, ale nie warto przykáadaü do tego wiĊkszej wagi. Nic bardziej
mylnego! Wizja to niezwykle prosty i uĪyteczny sposób precyzowania
zakresu systemu.
WyobraĨ sobie nastĊpującą sytuacjĊ: ustaliáeĞ z klientem, Īe celem
projektu bĊdzie system do zarządzania kontaktami z klientami,
w skrócie CRM
3
. Podczas jednego ze spotkaĔ rozmowa 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, ale póárocznych i rocznych. Kwartalnych nie.
Klient: No, raport to raport. Chyba nie bĊdzie z tym káopotu?
Ty:
Hmmm…
2
W jĊzyku angielskim Software Requirements Specification — specyfikacja
wymagaĔ do oprogramowania.
3
W jĊzyku angielskim Customer Relationship Management.
Oprogramowanie szyte na miarĊ
– 34 –
Przedstawiony dialog w ten czy inny sposób powtarza siĊ w naszej
pracy wyjątkowo czĊsto. Z grubsza rzecz biorąc, chodzi o to, czy zgáa-
szana funkcjonalnoĞü mieĞci siĊ w obszarze kontraktu i kto
zapáaci za jej wykonanie. Chodzi wiĊc o zakres systemu, zakres
prac, do wykonania których siĊ zobowiązujesz
4
.
ZaáóĪmy, Īe wizja systemu zostaáa zdefiniowana nastĊpująco: CRM
sprzedaĪowy to oprogramowanie webowe dla przedstawicieli han-
dlowych, które pozwoli na bieĪące wyznaczanie zadaĔ sprzedaĪowych
i uproĞci generowanie raportów na zamkniĊcie 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: Hmmm…
Posáugując siĊ wizją, mogáeĞ bez problemu ustaliü, czy nowe wyma-
ganie naleĪy do zakresu prac, czy nie. PodkreĞlmy wyraĨnie, Īe nie
chodzi tu o wyprowadzenie klienta na manowce. Chodzi przede wszy-
stkim o szybkie, jednoznaczne i nienaruszające relacji interpersonal-
nych okreĞlenie, czy nowa funkcjonalnoĞü mieĞci siĊ w zakresie prac,
czy nie (rysunek 3.2). Chodzi o jasną odpowiedĨ na pytanie: Kto osta-
tecznie zapáaci za Twoją pracĊ?
Nawet najciekawsze technicznie systemy tworzone są z zaáoĪeniem,
Īe „zarobią na siebie”. KaĪda aktywnoĞü podjĊta w projekcie jest
4
Dla uproszczenia toku myĞlowego pomijam rozróĪnienie róĪnych sposo-
bów kontraktowania pracy: fixed price oraz time & material. Nie jest to
szczególnie istotne dla omawianego tematu.
Wspólna wizja
– 35 –
R
YSUNEK
3.2. Które wymagania wchodzą do zakresu prac?
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 potĊĪ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Ċ to odbyü w trakcie moderowanego przez Ciebie spotkania. Wtedy
powstaje wizja, cel, do którego wszyscy bĊdą od tej chwili zmierzaü.
Kolejnym krokiem jest komunikowanie wizji wĞród reszty
zespoáu i decydentów, aby kaĪda osoba zaangaĪowana w projekt miaáa
to samo rozumienie koĔcowego efektu.
Wizja jako krótki opis
Najprostszym sformuáowaniem wizji jest krótki opis w postaci zdania:
Oprogramowanie szyte na miarĊ
– 36 –
System <NAZWA> jest to <PRZEZNACZENIE,
GàÓWNE FUNKCJONALNOĝCI>.
System CRM sprzedaĪowy to narzĊdzie CRM dla sprzedawców, które
ujednolica sposób przechowywania informacji na temat klientów.
PowyĪszy schemat moĪna nieco uszczegóáowiü, tak aby przekazy-
waá precyzyjniejszą informacjĊ, nie tracąc nic ze swej zwiĊzáoĞci oraz
lekkoĞci:
System <NAZWA> jest to <WIĉKSZA KATEGORIA>
w <CZYJA? GDZIE?> dla <GàÓWNI UĩYTKOWNICY>
odpowiedzialna za <GàÓWNE USàUGI,
FUNKCJONALNOĝCI>.
ABCMobi to aplikacja mobilna firmy ABX Taxi w àodzi dla pasaĪe-
rów komunikacji miejskiej odpowiedzialna za: wyszukiwanie najkrót-
szych lub najszybszych poáączeĔ tramwajowych, zbieranie informa-
cji o zapytaniach wpisywanych przez uĪytkowników i proponowanie
atrakcyjniejszych niĪ dane wyszukanie przejazdów taksówką.
Arkusz wizji
Szczegóáową metodĊ konsolidowania wizji zaproponowaá Karl Wie-
gers w ksiąĪce Software Requirements, Second Edition w postaci
siedmiopunktowego arkusza wizji (tabela 3.1).
Nazwa jest waĪna
Jeden z moich klientów nazwaá kiedyĞ system, nad którym wspólnie
pracowaliĞmy, zintegrowanym systemem informatycznym (ZSI).
Ta z pozoru niewinna nazwa spowodowaáa sporo zamieszania. Byáem
niemal zmuszony do godzenia siĊ na wszystkie kolejne funkcjonalnoĞci.
Wspólna wizja
– 37 –
T
ABELA
3.1. Arkusz wizji
Element wizji
Przykïad
Jak siÚ nazywa produkt?
System „CRM sprzedaĝowy”
Jakiej kategorii/klasy jest to produkt?
jest aplikacjÈ webowÈ klasy CRM
Dla kogo jest przeznaczony?
przeznaczonÈ dla sprzedawców i marketingowców,
Jakie potrzeby zaspokaja?
Jakie moĝliwoĂci wykorzystuje?
którzy potrzebujÈ wsparcia procesu sprzedaĝy usïug
szkoleniowych.
Jakie przynosi korzyĂci, za które klient
zechce zapïaciÊ?
CRM sprzedaĝowy przeprowadza sprzedawcÚ
i marketingowca przez peïen proces sprzedaĝy,
w którym centrum procesu jest klient, dziÚki czemu
oszczÚdzimy uĝytkownikom koniecznoĂci pamiÚtania
o terminach i etapach procesu.
Jakie sÈ alternatywy?
W przeciwieñstwie do sytuacji obecnej, w której
kaĝdy z naszych sprzedawców ma wïasnÈ metodÚ
dziaïania, co powoduje sporo zamieszania,
Co odróĝnia produkt od konkurencyjnych
alternatyw?
CRM sprzedaĝowy ujednolica caïy proces sprzedaĝy.
Pozwala równieĝ zintegrowaÊ siÚ z systemem
organizacji szkoleñ.
— JakĪe mogáoby ich zabraknąü w zintegrowanym systemie
informatycznym? — argumentowaá klient.
— Ale przecieĪ to siĊ nie uda! — próbowaáem oponowaü.
Nic z tego. ZSI to ZSI i musi posiadaü wszystkie funkcjonalnoĞci,
których klient od niego oczekiwaá.
Zrozumiaáem potem, jaki báąd popeániáem. Gdy nadajesz czemuĞ
nazwĊ, to nazwa zaczyna budowaü Twoje oczekiwania w stosunku do
nazwanej rzeczy. Gdy nazwiesz buty butami sportowymi, to bĊdziesz
oczekiwaá, Īe bĊdą wygodne podczas biegania. Gdy nazwiesz buty
butami wizytowymi, to bĊdziesz oczekiwaá, Īe bĊdą siĊ dobrze pre-
zentowaü w zestawieniu z garniturem. JeĞli zatem nieopatrznie okre-
Ğlisz tworzony system nieadekwatną nazwą, to klienci bĊdą oczekiwaü
od systemu innych funkcjonalnoĞci niĪ powinni.
Oprogramowanie szyte na miarĊ
– 38 –
W opisanym przykáadzie zintegrowanego systemu informatycz-
nego nazwa byáa zbyt ogólna, w związku z czym niemal kaĪda
funkcjonalnoĞü pasowaáa do zakresu tak nazwanego systemu.
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Ċ jedno-
znaczną informacjĊ o tym, które funkcjonalnoĞci mieszczą
siĊ w zakresie prac nad systemem, a które nie. Odpowiednia
nazwa powinna skupiaü oczekiwania klientów na tym, czym w istocie
jest tworzony system, oraz pomagaü odrzucaü zbĊdne funkcjonalnoĞci,
zwane potocznie wodotryskami. Jest przecieĪ oczywiste lub áatwe do
wykazania, Īe odtwarzanie plików mp3 nie jest naturalną funkcjonal-
noĞcią systemu ksiĊgowego. Trudno jednak bĊdzie przeprowadziü
podobne rozumowanie w przypadku zintegrowanego systemu infor-
matycznego — skoro zintegrowany, to dlaczego nie z mp3?
Nowemu produktowi nadawaj konkretne nazwy, zwiÈzane z rzeczywistoĂciÈ (domenÈ)
informatyzowanego procesu.
Dobra nazwa powinna odwoáywaü siĊ do tego, co klienci juĪ znają —
do rzeczywistoĞci (dziedziny) informatyzowanego procesu. JeĞli two-
rzysz oprogramowanie wspierające dziaá HR, to oczywiĞcie moĪna mu
nadaü nazwĊ Szybki Lopez, ale czy to komukolwiek cokolwiek mówi?
Klienci bĊdą musieli nauczyü siĊ odpowiedniego rozumienia sformu-
áowania Szybki Lopez, a to zabierze nieco czasu. Lepiej odwoáaü siĊ
do doĞwiadczenia zaangaĪowanych osób i nazwaü 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Īo-
wani w projekt zaczną doĞü szybko posáugiwaü siĊ krótką nazwą Szybki
Lopez, lecz przypiszą tej nazwie to samo znaczenie co nazwie kadry
i páace, a o to przecieĪ chodziáo.
Wspólna wizja
– 39 –
Wizja jest wspóádzielona
albo nie ma jej wcale
JeĞli chcesz siĊ przekonaü, czy wizja speánia swoją funkcjĊ, zapytaj
dowolną osobĊ zaangaĪowaną w prace nad oprogramowaniem o to,
jaka jest wizja tego produktu. JeĞli nie potrafi o niej opowiedzieü, wizja
nie dziaáa.
Co to znaczy, Īe wizja nie dziaáa? Oznacza to, Īe oprócz terminów
i przydzielonych zadaĔ nie istnieje nic, co nadaje kierunek pracom.
Nie istnieje jasny dla wszystkich zaangaĪowanych osób cel pracy.
Wizja pochodzi od klienta
Przeanalizuj fragment konwersacji na temat wizji produktu, zamiesz-
czonej w tabeli 3.2.
T
ABELA
3.2. Wizja, która NIE pochodzi od klienta
Klient
Specjalista
Jak wspominaïem wczeĂniej, chciaïbym,
aby ten program pomagaï mi w rozliczaniu
czasu pracy kierowców. Przede wszystkim
chodzi o wykrywanie naruszeñ zwiÈzanych
z czasem pracy oraz o opisywanie tarczek.
—
—
Aha, czyli moĝemy napisaÊ: „system
do rozliczania czasu pracy kierowców
pracujÈcych w firmach pana klientów,
dla pana pracowników, odpowiedzialny
za rozliczanie czasu pracy kierowców
i opisywanie tarczek”. Zgadza siÚ?
Hm, sam nie wiem…
W wizji nie chodzi wyáącznie o wypeánienie pozycji Vision Sta-
tement w raporcie czy o sformuáowanie jej, bo tak trzeba. Chodzi
Oprogramowanie szyte na miarĊ
– 40 –
o zdefiniowanie punktu odniesienia, który w kaĪdym momencie trwa-
nia prac pomoĪe odpowiedzieü na pytanie: Czy wciąĪ robimy to, co
na początku zamierzaliĞmy robiü?
W przykáadzie z tabeli 3.2 specjalista przedstawiá wizjĊ produktu,
ale to byáa jego — specjalisty — wizja, nie klienta. Wizja sformuáowana
w podobny sposób pozwoli zachowaü kompletnoĞü dokumentacji, ale
nie bĊdzie dziaáaü.
Zobacz w tabeli 3.3, jak moĪe wyglądaü skuteczniejsze formuáowa-
nie wizji. Techniki uĪyte w konwersacji poznasz w kolejnych rozdzia-
áach ksiąĪki.
ZauwaĪ, Īe do sformuáowania wizji absolutnie niezbĊdna jest
konwersacja. Szablony, formularze, schematy postĊpowania mają
charakter pomocniczy, ich wypeánienie nie jest celem samym w sobie.
Dlatego tak istotna jest umiejĊtnoĞü Ğwiadomego prowadzenia kon-
wersacji z biznesem, co stanowi zasadniczy temat tej ksiąĪki.
Komunikowanie wizji
Raz — na początku projektu — przeprowadzone spotkanie ustalające
wizjĊ niestety nie zapewni, Īe wizja bĊdzie dziaáaü. Zazwyczaj prace
nad oprogramowaniem przebiegają bardzo dynamicznie. BieĪące dzia-
áania szybko przesáaniają to, co zostaáo ustalone miesiące temu. Aby
wizja byáa ciągle Īywa w ĞwiadomoĞci osób pracujących nad pro-
duktem, musi staü siĊ elementem codziennoĞci, zarówno wizualnie,
jak i w postaci codziennego jĊzyka, a zatem:
x umieĞü sformuáowanie wizji w formalnych dokumentach,
mailach, na stronie WWW;
x przypominaj wizjĊ na spotkaniach formalnych i nieformalnych;
x rozmawiaj o wizji z interesariuszami oraz zespoáem.
Wspólna wizja
– 41 –
T
ABELA
3.3. Wizja, która pochodzi od klienta
Klient
Specjalista
Jak wspominaïem wczeĂniej, chciaïbym,
aby ten program pomagaï mi w rozliczaniu
czasu pracy kierowców. Przede wszystkim
chodzi o wykrywanie naruszeñ zwiÈzanych
z czasem pracy oraz o opisywanie tarczek.
—
—
Co oznacza „opisywaÊ tarczki”?
Chodzi o to, ĝe sÈ dwa rodzaje tachografów:
cyfrowe i analogowe. Cyfrowe zapisujÈ czas
pracy na karcie chipowej, a analogowe
na papierowych okrÈgïych tarczkach.
W przypadku naruszeñ czasu pracy naleĝy
odszyfrowaÊ zapis tachografu na tarczce
i opisaÊ kaĝdÈ przyczynÚ kaĝdego naruszenia,
co moĝe uchroniÊ przed mandatem.
—
—
Czy dobrze zrozumiaïem, ĝe wïaĂciwie chodzi
o to, aby program wykrywaï i opisywaï
naruszenia zwiÈzane z czasem pracy?
Cóĝ, w zasadzie tak.
—
—
Kto przede wszystkim bÚdzie z niego korzystaï?
Moi pracownicy.
—
—
Jak siÚ nazywa ich stanowisko?
Specjalista do spraw rozliczania czasu pracy
kierowców — tak to wymyĂliïem.
—
—
BÚdzie to wiÚc oprogramowanie
„dla specjalistów do spraw rozliczania
czasu pracy kierowców, odpowiedzialne
za wykrywanie i umoĝliwienie opisywania
naruszeñ czasu pracy kierowców”?
Dokïadnie tak.
—
Oprogramowanie szyte na miarĊ
– 42 –
Kiedy wizja bywa niebezpieczna?
Czy po wszystkich zaletach wizji, które wymieniáem, moĪna zastana-
wiaü siĊ nad tym, czy jest ona niebezpieczna? OczywiĞcie, Īe moĪna.
KaĪde narzĊdzie czy metoda ma ograniczony zakres stosowalnoĞci.
Wizja równieĪ.
x Wizja staje siĊ niebezpieczna, kiedy sáuĪy do wyciągania
wniosków na temat systemu, który opisuje.
Powiedzmy, Īe tworzysz system, którego wizja zostaáa okreĞlona
nastĊpująco:
y
SuperTest jest systemem do przeprowadzania badaĔ
satysfakcji klienta banku.
WyobraĨ sobie, Īe w ramach Twojej organizacji powstaáa koncepcja
innego systemu okreĞlonego wizją:
y
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ą pojawiü siĊ wnioski oparte na nastĊpującym rozu-
mowaniu:
y
Skoro SuperTest sáuĪy do przeprowadzania badaĔ
i T-Expert bĊdzie sáuĪyá do przeprowadzania badaĔ,
zatem do budowy systemu T-Expert moĪna uĪyü juĪ
istniejących 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 opartego na sformuáowaniach wizji. Byáo
to moĪliwe dlatego, Īe wizja zostaáa uĪyta niezgodnie z jej przeznacze-
niem. Zamiast wskazywaü cel, do którego zmierzamy, staáa siĊ pod-
stawą wnioskowania. Raczej nie powstrzymasz klientów przed wycią-
ganiem tego typu ogólnych wniosków. Jedyne, co moĪesz zrobiü, to
byü na nie wyczulonym i w porĊ interweniowaü.
Wspólna wizja
– 43 –
Podsumowanie
W tym rozdziale dowiedziaáeĞ siĊ, czym jest wizja systemu albo pre-
cyzyjniej: produktu programistycznego. DowiedziaáeĞ siĊ teĪ, Īe celem
wizji jest wyznaczenie kierunku prac, a jej praktycznym zastosowa-
niem — wstĊpne ocenianie, czy pomysáy na nowe funkcjonalnoĞci
mieszczą siĊ w ustalonym zakresie, czy nie.
PoznaáeĞ równieĪ metody na formuáowanie oraz komunikowanie
wizji. Jednym z waĪniejszych spostrzeĪeĔ w tym rozdziale byáo to,
Īe aby wizja dziaáaáa, musi pochodziü od klienta, byü wspóádzielona
przez wszystkich interesariuszy oraz przez zespóá, który dostarcza
kolejnych porcji funkcjonalnoĞci.