•
Kup książkę
•
Poleć książkę
•
Oceń książkę
•
Księgarnia internetowa
•
Lubię to! » Nasza społeczność
:V]HONLHSUDZD]DVWU]HĝRQH1LHDXWRU\]RZDQHUR]SRZV]HFKQLDQLHFDïRĂFL
OXEIUDJPHQWXQLQLHMV]HMSXEOLNDFMLZMDNLHMNROZLHNSRVWDFLMHVW]DEURQLRQH
:\NRQ\ZDQLHNRSLLPHWRGÈNVHURJUDILF]QÈIRWRJUDILF]QÈDWDNĝHNRSLRZDQLH
NVLÈĝNLQDQRĂQLNXILOPRZ\PPDJQHW\F]Q\POXELQQ\PSRZRGXMHQDUXV]HQLH
SUDZDXWRUVNLFKQLQLHMV]HMSXEOLNDFML
:V]\VWNLH]QDNLZ\VWÚSXMÈFHZWHNĂFLHVÈ]DVWU]HĝRQ\PL]QDNDPLILUPRZ\PL
EÈGěWRZDURZ\PLLFKZïDĂFLFLHOL
$XWRURUD]:\GDZQLFWZR+(/,21GRïRĝ\OLZV]HONLFKVWDUDñE\]DZDUWH
ZWHMNVLÈĝFHLQIRUPDFMHE\ï\NRPSOHWQHLU]HWHOQH1LHELRUÈMHGQDNĝDGQHM
RGSRZLHG]LDOQRĂFLDQL]DLFKZ\NRU]\VWDQLHDQL]D]ZLÈ]DQH]W\PHZHQWXDOQH
QDUXV]HQLHSUDZSDWHQWRZ\FKOXEDXWRUVNLFK$XWRURUD]:\GDZQLFWZR+(/,21
QLHSRQRV]ÈUöZQLHĝĝDGQHMRGSRZLHG]LDOQRĂFL]DHZHQWXDOQHV]NRG\Z\QLNïH
]Z\NRU]\VWDQLDLQIRUPDFML]DZDUW\FKZNVLÈĝFH
5HGDNWRUSURZDG]ÈF\0DJGDOHQD'UDJRQ
3URMHNWRNïDGNL-DQ3DOXFK
0DWHULDï\JUDILF]QHQDRNïDGFH]RVWDï\Z\NRU]\VWDQH]D]JRGÈ6KXWWHUVWRFN
:\GDZQLFWZR+(/,21
XO.RĂFLXV]NLF*/,:,&(
WHO
HPDLOKHOLRQ#KHOLRQSO
:::KWWSKHOLRQSONVLÚJDUQLDLQWHUQHWRZDNDWDORJNVLÈĝHN
'URJL&]\WHOQLNX
-HĝHOLFKFHV]RFHQLÊWÚNVLÈĝNÚ]DMU]\MSRGDGUHV
KWWSKHOLRQSOXVHURSLQLH"RSV]PL
0RĝHV]WDPZSLVDÊVZRMHXZDJLVSRVWU]HĝHQLDUHFHQ]MÚ
,6%1
&RS\ULJKWŅ0LFKDï%DUW\]HO
3ULQWHGLQ3RODQG
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
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
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
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
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)*ce NIE zadzia$aj)? ....................225
Lektura uzupe$niaj)ca .............................................227
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
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
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
2 8
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 $
Ustalenie wizji systemu
z biznesem to pierwszy
krok w pracach nad nowym
oprogramowaniem,
jego kolejn= wersj= lub
nad nowymi modu>ami.
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"?
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(.
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
W s p ó l n a w i z j a
2 9
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 b3dzie 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 b3dzie z tym k;opotu?
[Ty]: Hmm…
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
3 0
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 zadaI 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 si3 w ustalonym zakresie prac, w którym
CRM „upraszcza generowanie raportów na zamkni3cie 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- prac3?
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
W s p ó l n a w i z j a
3 1
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 b3dzie 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*.
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
3 2
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,
GAÓWNE FUNKCJONALNO/CI>.
PRZYK&AD
System CRM sprzeda=owy to narz3dzie 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
Przyk ad
Jak siJ 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 moUliwoVci wykorzystuje?
którzy potrzebuj& wsparcia procesu
sprzeda$y us(ug szkoleniowych.
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
W s p ó l n a w i z j a
3 3
Tabela 3.1.
Arkusz wizji — ci$g dalszy
Element wizji
Przyk ad
Jakie przynosi korzyVci,
za które klient zechce zap>aciX?
CRM sprzeda$owy przeprowadza
sprzedawc) i marketingowca przez
pe(en proces sprzeda$y, w którym
to klient jest centrum procesu, dzi)ki
czemu oszcz)dzimy u$ytkownikom
konieczno*ci pami)tania o terminach
i etapach procesu.
Jakie s= alternatywy?
W przeciwie,stwie do obecnej sytuacji,
w której ka$dy z naszych sprzedawców
ma w(asn& metod) dzia(ania,
co powoduje sporo zamieszania,
Co odróUnia produkt od konkurencyjnych
alternatyw?
CRM sprzeda$owy ujednolica ca(y
proces sprzeda$y. Pozwala równie$
zintegrowa/ si) z systemem organizacji
szkole,.
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 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 si3 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
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
3 4
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 $
Nowemu produktowi
nadawaj konkretne nazwy,
zwi=zane z rzeczywistoVci=
(dziedzin=) informatyzowa-
nego procesu.
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.
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 ksi3gowego. 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-
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
W s p ó l n a w i z j a
3 5
%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 badaI 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 badaI 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 b3dzie s;u=y; do przeprowadzania bada",
zatem do budowy systemu
T-Expert mo=na u=y? ju= istniej-cych
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
3 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 $
modu;ów systemu
SuperTest. Tworzenie T-Experta b3dzie
wi3c 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.
Kup ksiąĪkĊ
Pole
ü ksiąĪkĊ
