Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00487 007044 14664896 na godz. na dobę w sumie
Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce - książka
Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce - książka
Autor: Liczba stron: 232
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3932-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> inne
Porównaj ceny (książka, ebook, audiobook).

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.

Znajdź podobne książki Ostatnio czytane w tej kategorii

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)

Gdzie kupić całą publikację:

Oprogramowanie szyte na miarę. Jak rozmawiać z klientem, który nie wie, czego chce
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: