Oprogramowanie szyte na miare Jak rozmawiac z klientem ktory nie wie czego chce Wydanie II rozszerzone 2

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

Printed in Poland.

Księgarnia internetowa

•

Lubię to! » Nasza społeczność

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

Poleć książkę

Kup książkę

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

Poleć książkę

Kup książkę

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

Poleć książkę

Kup książkę

Oprogramowanie szyte na miarĊ

– 8 –

Poleć książkę

Kup książkę

Rozdziaá 3.

Wspólna wizja

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

Poleć książkę

Kup książkę

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

. JeĞli wiĊc peánisz funkcjĊ analityka, szczególnie

uwaĪnie przeczytaj ten rozdziaá.

W jĊzyku angielskim Product Owner.

Poleć książkę

Kup książkę

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

. 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

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

W jĊzyku angielskim Software Requirements Specification — specyfikacja
wymagaĔ do oprogramowania.

W jĊzyku angielskim Customer Relationship Management.

Poleć książkę

Kup książkę

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

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

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.

Poleć książkę

Kup książkę

Wspólna wizja

– 35 –

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:

Poleć książkę

Kup książkę

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.

Poleć książkę

Kup książkę

Wspólna wizja

– 37 –

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.

Poleć książkę

Kup książkę

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.

Poleć książkę

Kup książkę

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.

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

Poleć książkę

Kup książkę

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.

Poleć książkę

Kup książkę

Wspólna wizja

– 41 –

ABELA

3.3. Wizja, która pochodzi od klienta

Klient

Specjalista

—

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.

—

Poleć książkę

Kup książkę

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:

SuperTest jest systemem do przeprowadzania badaĔ
satysfakcji klienta banku.

WyobraĨ sobie, Īe w ramach Twojej organizacji powstaáa koncepcja

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ą pojawiü siĊ wnioski oparte na nastĊpującym rozu-
mowaniu:

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

Poleć książkę

Kup książkę

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.

Poleć książkę

Kup książkę

Oprogramowanie szyte na miarĊ

– 44 –

Poleć książkę

Kup książkę