Professional Documents
Culture Documents
PRZYKADOWY ROZDZIA
SPIS TRECI
KATALOG KSIEK
KATALOG ONLINE
TWJ KOSZYK
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
ZAMW INFORMACJE
O NOWOCIACH
ZAMW CENNIK
CZYTELNIA
FRAGMENTY KSIEK ONLINE
Wydawnictwo Helion
ul. Kociuszki 1c
44-100 Gliwice
tel. 032 230 98 63
e-mail: helion@helion.pl
O autorze ................................................................................................ 13
Rozdzia 1. Jak zwycizcy rozRozdaia zwycizczwy ............................ 19
Gdzie zwycizcy znajduj swoje pomysy? ................................................................................19
Jak utrwali dobry pomys? .........................................................................................................20
Krok 1.Usid ..........................................................................................................................20
Krok 2. Rozcignij swj pomys .............................................................................................21
Krok 3. Upewnij si, e pomys jest dobrze zdefiniowany .....................................................22
Krok 4. Rozwi swoj koncepcj ............................................................................................22
Krok 5. Skonfrontuj koncepcj z wasnym dowiadczeniem ......................................................23
Krok 6. Zbierz swoj paczk ...................................................................................................24
Krok 7. Jeste tylko czowiekiem ............................................................................................24
Dlaczego opaca si rozwija pomysy? ......................................................................................25
Rozdzia 2. O co Rytaia Oudzie sukcesuy ................................................ 27
Kogo pyta? .................................................................................................................................28
Ilu ludzi trzeba przebada? ..........................................................................................................29
Etyka ............................................................................................................................................30
Zadanie dla profesjonalisty? ........................................................................................................30
Tworzenie kwestionariusza .........................................................................................................31
Jaka moe by cena? ................................................................................................................31
Moliwoci sprzeday .............................................................................................................32
Konkurencja .............................................................................................................................32
Informacje o firmie ..................................................................................................................33
Trudne pytania .........................................................................................................................33
Typy pyta ...................................................................................................................................33
Pytania otwarte ........................................................................................................................34
Pytania zamknite ....................................................................................................................34
Pytania porwnawcze ..............................................................................................................34
Pytania nieporwnawcze .........................................................................................................34
Skala Likerta ............................................................................................................................35
Badanie pilotaowe ......................................................................................................................35
Spis treci
Spis treci
Spis treci
10
Spis treci
11
12
By moe nie wiesz jeszcze, co przesdza o sukcesie w dziedzinie produkcji oprogramowania, ale wiesz ju, co rodzi problemy:
t
Niedokoczone plany.
Mgliste cele.
Nierealne terminy.
Niewystarczajce rodki.
Mimo tak wielkiej wagi planowania i gromadzenia funduszy to wanie produkcja oprogramowania jest etapem, na ktrym firma programistyczna przeksztaca swoje marzenia
w rzeczywisto. Produkcja oprogramowania to jego pisanie i zarzdzanie tym pisaniem.
Nie moe dziaa, jeeli harmonogramy, ludzie i techniki nie zostay ze sob zgrane.
Przemylany plan o odpowiedniej strukturze znacznie uproci proces produkcji. Po
szczegowym okreleniu zasobw, kolejnoci i kluczowych etapw moliwe jest posuwanie si na przd z w miar sta prdkoci. Nie trzeba podejmowa krytycznych
decyzji w poowie drogi.
Bywa jednak, e najprostszy fragment kodu moe okaza si najbardziej skomplikowanym. Podobnie moe by z produkcj. Jak nakazuj reguy, musimy jednoczenie kontrolowa cztery sprawy: ludzi, produkt, projekty i proces. Niniejszy rozdzia to praktyczna szkka onglowania czterema pikami. Na szczcie, jeeli bdziesz postpowa
zgodnie z zasadami opisanymi dotychczas w tej ksice, wikszo pracy bdziesz mia
ju za sob.
88
menederowie projektu,
technolodzy,
architekci,
programici,
testerzy,
twrcy dokumentacji.
ZdobZdobywaodeodywdbyeZaobdwy
W kadym projekcie programistycznym czas jest na wag zota. Ostatni rzecz, na jak
moesz sobie pozwoli, jest zatrudnienie ludzi, ktrzy bd go marnowa. W pierwszej
kolejnoci powiniene szuka osb, ktre znaj si na danym typie aplikacji i wszelkich
kwestiach z ni zwizanych. Jeeli wic tworzysz program do projektowania, to kandydaci, ktrzy pracowali przy programach graficznych albo byli szkoleni w tym kierunku,
s zesacami niebios. Jeeli tworzone przez Ciebie oprogramowanie wymaga szczeglnych
kompetencji, musisz zatrudni kandydata z odpowiednim dowiadczeniem.
Osoby takie mog wnie gbok znajomo aplikacji i rozwiza programistycznych,
na ktre kto nieobeznany nigdy sam by nie wpad. Ich dowiadczenie nie tylko tworzy
fundament do rozwizywania problemw technicznych, ale take pozwala pisa kod
w taki sposb, jakiego oczekuje klient. W ten sposb mona unikn znacznych poprawek
w przyszoci. W innym bowiem razie wydawca oprogramowania bdzie musia przekona klientw do pracy w programie odstajcym od pewnych norm. Kiedy programici
znaj dziedzin, w ktrej aplikacja bdzie zastosowana, rwnie o wiele atwiej implementowa usprawnienia dla klientw i odrzuca sugestie, ktre nie daj ostatecznym uytkownikom adnej realnej korzyci.
89
Jeeli z pocztku nie jeste w stanie zebra zaogi takiego kalibru i z takim dowiadczeniem,
na jakie zasuguje projekt, bd wytrway. Nie ruszaj z realizacj, dopki jej nie znajdziesz. Zawsze lepiej poczeka, a dostpni bd lepsi, ni prbowa zaczyna z osobami
niekompetentnymi. Kady zatrudniony powinien rozumie, do czego suy produkt i dlaczego jest potrzebny. Jeeli jaka osoba nie widzi sensu istnienia takiego produktu albo
nie akceptuje go ze strony etycznej lub emocjonalnej, zapraszanie jej do zespou mogoby
by dla niej krzywdzce.
Zatrudniajc poszczeglne osoby, zwracaj uwag, by inwestowa pienidze tam, gdzie
wymagaj tego Twoje potrzeby.
MenedeMenMder p
Ju od wczesnego etapu potrzebni s ludzie, ktrzy czuwaliby nad pracami zespou i meneder projektu jest oczywicie tak osob. Meneder projektu jest staym ordownikiem produktu. Jego zadaniem jest nadzr nad pisaniem kodu i budowaniem programu,
tak by zgadza si ze specyfikacj co do natury i treci. W firmie bdcej u progu powstania zwykle rol t bierze na siebie szef marketingu.
Dobry meneder projektu to najlepsza gwarancja terminowoci realizacji. Osoba ta bdzie
wiedziaa, jak zarzdza projektem i tworzy harmonogramy realizacji. Oprcz wasnego
wkadu w pisanie kodu w razie potrzeby pomoe i doradzi programistom w sprawie nowych podej i technik. Co rwnie wane, meneder projektu sprawi, e wszyscy skupi
si na tej samej wizji i powstanie mniej niepotrzebnego kodu.
Meneder projektu nosi w sobie ca mdro o tym, do czego suy produkt, jak trzeba
go napisa i dlaczego jest taki wany. Interpretuje firmow wizj produktu na potrzeby
programistw w odniesieniu do kompozycji ekranw, komunikatw ekranowych oraz
umieszczania logotypu firmy lub produktu. Poza tym pilnuje, by z pokoju programisty
wychodziy tylko autoryzowane wersje kodu.
Niektre firmy wierz, nie bez powodu, e co bardziej delikatne kwestie tej roli powinny
zosta przejte przez dowiadczon osob, ktra nie jest bezporednio zaangaowana
w codzienny proces pisania kodu. Osoba ta moe zajmowa si rwnie nadzorowaniem
beta-testw.
To, jak osob moesz przycign, w duej mierze zaley od rozmiaru Twojej organizacji
i tego, co jeste w stanie zaoferowa. Poza tym zaley od nieograniczonych szans i nagrd
zwizanych z tak prac.
90
wspomina si o niewyczerpanej energii, umiejtnoci rozumienia bez sw i takiej umiejtnoci motywowania, ktra poprowadziaby mrwki na Mount Everest, ale oto lista najwaniejszych cech, ktrych naley szuka:
t
Zorganizowanie.
PMdcM oici
Im bardziej wymagajce jest zadanie do wykonania, tym waniejsze jest posiadanie dobrych programistw. Gdyby szuka dobrego architekta, inyniera lub projektanta, zwracaby wiksz uwag na to, co zrobili, ni na to, co mwi. Takie podejcie sprawdza
91
si rwnie w odniesieniu do programistw. Przyjrzyj si ostatnim projektom, jakie realizowa kandydat na programist, wybierz fragmenty kodu i popro o ich objanienie. Sabi
programici mog pooy cay projekt, jeeli wic programista nie przejawia faktycznie tych umiejtnoci, jakie deklaruje, zdaj si na instynkt i odrzu go.
Jeeli zatrudnisz niekompetentnego programist (a wielu z nas to si zdarzyo), otrzymasz bezuyteczny kod, atmosfera w zespole si pogorszy, stracisz czas, a budet rozleci si w py. Jedyne co moesz zrobi, to jak najszybciej pokaza takiej osobie drzwi,
a kod, ktry napisaa, przepuci przez niszczark. Jeeli trafisz na dobrego programist,
bdziesz o tym wiedzie. Podobnie reszta zespou.
Jeeli wybierajc programist, przy podejmowaniu decyzji bierzesz pod uwag,
jaki jest w obyciu, jeste na dobrej drodze do klski.
Oto sygnay wiadczce o tym, e programista moe nie by tak kompetentny, jak twierdzi:
t
Wolno si uczy.
Pracuj szybko.
92
Kierownik
produkcji
Podwykonawcy
jednoosobowa
2 12 (maa)
tak
by moe
2 12
tak
by moe
raczej tak
18 30 (rednia) tak
tak
prawdopodobnie
tak
tak
tak
prawdopodobnie
1000 +
(korporacja)
tak
kilku
tak
prawdopodobnie
tak
by moe
by moe
ndoiir erieMdonicze
Brana IT zapoyczya stanowisko chief technical officer (CTO) od brany badawczej pod
koniec lat 70. W tym samym czasie obszar technologii informatycznych znacznie si rozszerzy w miar pojawiania si nowych produktw, pomysw i dyscyplin. To spowodowao, e osobie odpowiedzialnej za projekt coraz trudniej byo ogarn wszystkie
aspekty programowania. W konsekwencji rola CTO ograniczya si do obserwacji. Jego
podstawowym zadaniem jest zdobywanie wiedzy na temat produktw i technologii, jakie
pojawiaj si na horyzoncie, i okrelanie stawianych przez nie wymaga.
Jak wspomniano w rozdziale 5., inwestorzy ceni wybitnych ekspertw technicznych
w firmie, w ktr planuj zainwestowa. Ich zdaniem firmy, ktrymi kieruje ekspert
techniczny, demonstruj wizj i wiadomo wagi najnowszej technologii.
Dobrzy CTO to rzadko, poniewa osoba taka musi rozumie teraniejszo i przewidywa przyszo. Z drugiej strony, zatrudnianie kogo takiego w penym wymiarze nie
musi by konieczne. Szukaj osoby z dobr praktyczn znajomoci technologii, jakie
maj by stosowane w programie, oraz konsekwencji ich stosowania. Kto taki powinien umie poprowadzi Ci przez te obszary nowoczesnych technologii, w ktrych
sam masz ograniczon wiedz. Powinien rwnie pomc wykorzysta te techniki, ktre
dopiero poznae.
93
CEOeEncineeMinc
W duych projektach stanowisko to czsto obejmuje wana osoba, ktra nadzoruje infrastruktur techniczn komponentw dla zachowania wewntrznej zgodnoci.
KieMdonirenMddprci
Kierownikw produkcji mona zwykle spotka w organizacjach, ktre pracuj jednoczenie nad kilkoma programami. Zwykle podlegaj szefowi wydziau lub dyrektorowi
generalnemu. Niestety, niewiele jest osb z dowiadczeniem na tym stanowisku, wic
istnieje tendencja do promowania kadego, kto zdaje si nadawa do tej roli. Wielu kierownikw produkcji zaczyna prac na tym stanowisku ze stosunkowo niewielkim dowiadczeniem. Menedera produkcji czasami nazywa si CEO Engineering, ale jego rola
jest szersza.
PddoPrdn ocP
Nie ma sensu zatrudnia na stae osoby, ktrej umiejtnoci bdzie mona wykorzysta
przez stosunkowo krtki okres. Do takich podprojektw lepiej wynaj podwykonawcw.
Warto zapamita szczeglnie dobrych na potrzeby przyszych projektw.
Zobwweywewaeyp
Zatrudnij wietnych ludzi, a otrzymasz realn szans, by sta si gigantem. Ludzie rzadko
odchodz ze wietnych zespow. Ale nie moesz by tego pewnym. Jeeli Twj projekt
jest krtkotrway, a jego realizacja musi by szybka, cakiem uzasadnione jest poproszenie osoby, ktra ma dla Ciebie pracowa, o to, by nie zmieniaa pracy w trakcie realizacji projektu. W miar moliwoci wyjanij, e jest to w interesie wszystkich zaangaowanych. Jeeli np. przewidywana jest premia w wysokoci 5000 dolarw dla kadego
czonka zespou, gdy projekt zostanie zrealizowany w terminie, i jedna osoba odejdzie
do pracy, gdzie oferuj o 10 000 dolarw rocznie wicej ni obecnie, zyskuje tylko 5000
dolarw i doywotni uraz ze strony byych wsppracownikw.
Mowajwetaeypebw
Due zespoy nie pracuj. One tyraj. Gwnie dlatego, e tyle uwagi powica si temu,
by wszyscy byli na bieco i wiedzieli, co si dzieje. Zarzdzanie zajmuje im wicej
czasu ni produkcja. O wiele lepiej stworzy kilka mniejszych zespow ni jeden duy
moloch. Podziel wic zadanie, gdzie tylko si da, na odrbne zespoy skadajce si z od
trzech do siedmiu osb. Praktyka wskazuje, e dziewi osb w zespole to maksymalna
liczba, jak powiniene bra pod uwag. Kady zesp w ramach projektu powinien
mie wasnego menedera, ktry wsppracuje z innym grupami i kontaktuje si z gr.
Podan struktur zespou przedstawiono na rysunku 6.1.
94
Rysunek 6.1.
Struktura zespou
odzwierciedlajca
stosown liczb
czonkw
i menedera
Standardowym rodkiem ostronoci jest wysanie przez menedera projektu do wszystkich czonkw zespou e-maila z zapytaniem, czy wiadomo im o jakichkolwiek rnicach pomidzy pierwotnym planem projektu a biec sytuacj, poza tymi, o ktrych
ju wszyscy wiedz (tutaj powinna zosta umieszczona lista znanych zmian). Nie zaczynaj
realizacji, dopki nie otrzymasz jednoznacznych odpowiedzi od wszystkich czonkw
zespou i nie uzgodnisz ostatecznie, co naley zrobi.
95
Jeeli okolicznoci niezalene od firmy ulegy znacznej zmianie od chwili zatwierdzenia planu, wprowadzanie przypadkowych zmian nie jest dobrym pomysem. Najbardziej
uzdrawiajc rzecz, jak moesz zrobi, jest zebranie wszystkich zainteresowanych
stron, wyjanienie, co zaszo, i poproszenie o pomoc. W kocu wszyscy zaangaowani
maj wsplne cele. W tym gronie powinno da si wypracowa najlepszy sposb reakcji
na zmiany, ktre zaszy. Takie rozwizanie jest o wiele lepsze ni ogoszenie, e zatrudnionych zostanie mniej programistw, ktrzy nie bd mieli dodatkowego czasu na realizacj.
Menederowie dziaajcy pod naciskiem nie zawsze przywizuj wag do ubocznych
efektw swoich decyzji.
O wiele lepiej usi wsplnie i omwi wszystkie implikacje. By moe znajdzie si jakie mniej bolesne rozwizanie. Jeeli nie, przysta tylko na to, co Twoim zdaniem jest
rzeczywicie moliwe. Jeeli Twoje uwagi nie s przyjmowane, zachowaj uprzejmo,
spokj i notuj zastrzeenia. Wyjanij, w jaki sposb mog one zagraa projektowi, a potem miej ju tylko nadziej, e bye w bdzie.
ZorwdwobywarZwZeywz
Nierealne jest oczekiwanie, e dobrze zaplanowany projekt nie pociga za sob adnego
ryzyka. Nie w informatyce. Zarzdzanie ryzykiem ma wiele postaci, czego dowodz
kolejne punkty. Zanim zaangaujesz si w programowanie, warto uwiadomi sobie, co
jest niepewne, i wiedzie, jak obserwowa te rzeczy. Jedynym sposobem na radzenie
sobie z ryzykiem jest jego akceptacja, pomiar i stawienie mu czoa.
96
ZoeoeaewoebayaeywbypdwZ
Opnienia, ktre mona wyrazi w jednostkach czasu, rwnie dobrze mona wyrazi
w kategoriach pieninych i wanie dlatego kady czonek zespou musi pilnie obserwowa piasek przesypujcy si w zotej klepsydrze. Ksigowi mierz kady wydatek.
Szef firmy interesuje si efektem kocowym, take w kwestii finansw. Meneder projektu pilnuje, by nie przekroczy granic czasowych i kosztowych. Pracownicy pilnuj,
by ich wydatki nie przekroczyy dopuszczalnych limitw i by wykona prac na czas.
Przy realizacji projektw programistycznych kady musi kontrolowa dostpne zasoby.
Oto pi najczstszych przyczyn przekraczania budetu projektu:
t
Zmiany w specyfikacji.
97
LyedydodobywaewZbbyendaroweroewojeZeZ
Kiedy wszyscy uwiadomi sobie, e kade przerwanie pracy programicie sprawia, e
traci on p godziny, szybko przestan przeszkadza. Zapewniajc programistom odpowiedni przestrze do pracy (omawian w rozdziale 4.), zapobiegamy spontanicznym
pogawdkom. Jednak takie starania s zupenie bezuyteczne, jeeli ludzie i tak bd je
porednio atakowa. Oto pocztkowy zbir regu dla programistw:
t
CdeMdPipiecdPenMdcM oicieiiCednybni gz
Czsto jest to pierwsza oznaka kopotw. Czasami programista dokadnie wie, na czym
polega problem, ale nie wie, jak z niego wybrn. Przeszkody przy pisaniu kodu to co,
co trudno zdefiniowa. Nie s to jakie widoczne obiekty z nalepion du etykiet
kopoty. Zwykle jest to fragment, ktry po prostu nie chce zadziaa tak, jak trzeba.
Czsto upywa troch czasu, zanim programista zda sobie spraw, e moe nie by w stanie
rozwiza problemu wasnymi siami.
Dobra zasada mwi, e jeeli programista powici wicej ni p godziny, poruszajc
si drog donikd, powinien zastosowa plan B, nawet jeeli zakci tym prac kolegw.
Najpierw powinien omwi problem z menederem projektu od tego wanie jest
meneder. Jeeli meneder projektu nie potrafi rozwiza problemu, powinni we dwoje
ustali, kto najprawdopodobniej bdzie zna odpowied (osoba z zespou lub spoza organizacji). Jeeli to nie da efektw, powinni wysa zapytanie na grupy dyskusyjne.
Odpowied moe pojawi si zaskakujco szybko, ale czsto trzeba poczeka nawet do
czterech godzin. Jeeli programista zdecyduje si na taki krok, oczywicie w midzyczasie zajmie si czym innym, przerywajc co godzin, by sprawdzi, jak przebiega
internetowa burza mzgw.
Poczucie wstydu i zaenowania samo w sobie nie przeamie blokady. Pomoe w tym
za to rozmowa z kim innym. Zawsze kiedy kto utknie, naley pamita, e co dwie
gowy to nie jedna.
98
Bicieen e n Mo
Programowanie, najkrcej mwic, jest jak jednotorowa linia kolejowa. Jeeli kto utknie
w jakim punkcie, czsto reszta zespou ma problemy z ruszeniem do przodu. Dlatego
wane jest, by przeszkody usuwane byy w najkrtszym moliwym czasie. Nie myl, e
jeeli osoba, ktra natrafia na problem, bdzie udawa, e nie jest to problem, to ten
sam zniknie albo odpowied sama si znajdzie. Prby prowizorycznego zaatwienia problemu zwykle pogarszaj tylko spraw. Gdy tylko kto natrafi na problem, powinien bi
na alarm i prosi o pomoc kolegw, prowadzcego projekt lub kogokolwiek, kto moe
suy rad. Jeeli nikt nie zna odpowiedzi, trzeba jak najszybciej wysa zapytanie na
grupy dyskusyjne. Nie obawiaj si szuka pomocy poza wasn organizacj. Jeeli odpowied istnieje (a przewanie istnieje), to kto na pewno j zna.
99
Sz cdo nieecz ip
Nie wszystko dzieje si zgodnie z harmonogramem. Stosowanie analogii do innych dziedzin, takich jak drukarstwo, hydraulika czy rczne kalkulacje, nie pozwoli nam ustali,
ile zajmie napisanie kodu, ktry komputeryzuje jak czynno. Co, co jest atwe do
opisania, moe by trudne do zaprogramowania, a co, co wydaje si ogromnym wyzwaniem, moe okaza si bahostk. Na przykad program zliczajcy wszystkie sowa,
jakich uy Szekspir w swoich dzieach, mona sprowadzi do trzech wierszy kodu.
Szekspir uy 29 066 sw. Z kolei napisanie i zapenienie danymi formularza WWW,
ktry uywa wariantowych list rozwijanych pozwalajcych wprowadzi nazw kraju,
miasta i ulicy, zajmie dowiadczonemu programicie osiem godzin pracy.
Programici czsto potrafi poda przybliony czas wykonania rnych rzeczy przy zaoeniu, e kod bdzie dziaa zgodnie z planem bez adnych komplikacji. Jednak kod,
ktry napisali, moe mie wpyw na inn procedur programu. Dotarcie do przyczyny
moe by bardzo trudne. Tak wic, o ile czasem moliwe jest wykonanie caodniowej
pracy w minut, innym razem minuta pracy rozciga si do caego dnia. Monitorowanie
i zarzdzanie dziaalnoci jest jedynym moliwym mechanizmem jej kontrolowania.
N d o niee eon
Najwiksza rnica pomidzy zespoami programistw, ktre odnosz sukcesy, a tymi,
ktrym si nie udaje, polega na tym, e zwyciski zesp ma odpowiednie tempo pracy.
Zesp programistw, grupowo i indywidualnie, wyznacza cele do osignicia na kady
dzie. Kada osoba zobowizuje si wykona okrelon ilo pracy do koca dnia. Pi
minut przed kocem dniwki kierownik produkcji pyta kad osob w obecnoci innych, jak jej poszo. Odpowiedzi s odnotowywane, ale nie padaj adne komentarze,
nawet pochway. Sytuacja ma mwi sama za siebie. Kierownik produkcji prosi wwczas wszystkich o zastanowienie si do nastpnego ranka, co zamierzaj zrobi jutro.
Nastpnego dnia w pierwszej kolejnoci prosi kadego czonka zespou o podanie celw
w obecnoci innych. Cele te nie maj by ambitne. Nie chodzi tu o bicie rekordw tylko
o sukces caego zespou. Najwaniejsza jest cicha determinacja.
Co prawda kady czonek zespou bdzie chcia pokaza swoim kolegom, e przykada
si do pracy, ale cel, jaki sobie wyznacza, musi by osigalny. Kierownik produkcji na
tym etapie okae pomoc kademu, kto opnia si w stosunku do wasnego harmonogramu. W uzasadnionych przypadkach moe poprosi innych o pomoc.
Inteligentne zespoy zdaj sobie spraw, e zahamowanie tempa jest tylko kwesti czasu.
Dlatego powinny od pocztku wypracowa zapas czasu, dajc z siebie wicej i starajc
si upcha dodatkowe 15 minut pisania kodu w siedmiogodzinnym dniu pracy i tym
sposobem uzyskiwa odpowiedni przewag.
100
Kluczowe znaczenie dla utrzymywania tempa ma przygotowanie etapw realizacji projektu. Bez tego, niezalenie od stopnia trudnoci, kady program bdzie pisany duej
jako cao ni jego poszczeglne etapy z osobna. Istnieje tak zwany czynnik SNZ
(strach, niepewno, zwtpienie), ktry trapi szczeglnie nowych i niedowiadczonych
czonkw zespou. Dlatego menederowie projektw dziel projekt na kilka niezalenych
etapw. Pierwszy podzia opiera si na funkcjach programu. Nastpnie gwne etapy
dzieli si na rozsdne czci moliwe do wykonania przez tydzie. Dalszy podzia pozostawia si ju samym programistom. Na przykad wykonanie strony witryny internetowej moe zosta podzielone na nastpujce etapy:
1. Uzgodnienie zawartoci.
2. Stworzenie modelu proponowanego interfejsu.
3. Wybr technologii.
4. Zaprojektowanie szablonu.
5. Zatwierdzenie szaty graficznej.
6. Napisanie kodu HTML.
7. Testowanie.
Nastpnie moemy monitorowa postp realizacji kolejnych etapw, w miar jak zesp
nabiera pewnoci, radzi sobie z wszystkimi wyzwaniami i koczy realizacj poszczeglnych krokw.
W efekcie, dziki zwikszonemu wysikowi podjtemu wczeniej, szybciej otrzymasz
gotowy produkt.
Panuje przekonanie, e programici nie cierpi raportw o postpach, poniewa pokazuj one, jak bardzo s spnieni. Dobrzy programici nigdy nie s tacy krtkowzroczni.
Dziki tym raportom kady moe mie wiadomo biecego postpu w realizacji
projektu. Praca bez raportw przypomina rejs do Ameryki bez codziennego zaznaczania
pozycji statku.
101
J rerdn Mdndo p
Pamitaj, e nigdy nie otrzymujesz tego, czego oczekujesz, tylko to, co sam sprawdzisz.
Przegld postpw i rezultatw powinien nastpowa pod koniec kadego dnia pracy.
Jeeli z jakiego powodu nie udao si tego zorganizowa, przyjrzyj si dokadnie nastpnego ranka, co zostao osignite dzie wczeniej. Nigdy nie pomi przegldu dwa
dni z rzdu.
Programici bd bardziej szczerzy, jeeli okaesz im wsparcie. Nie zawsze dadz Ci
powody do zadowolenia, cho bd chcieli. Dlatego zawsze zwracaj si do nich w swobodny sposb. Jeeli wiesz, e pracuj akurat nad czym skomplikowanym, uzgodnij
wygodny dla nich czas spotkania. W pozostaych przypadkach po prostu dostaw sobie
krzeso i zacznij codzienn pogawdk. Interesuj Ci trzy rzeczy:
t
Jeeli dana osoba pracuje w domu, zadzwo do niej i porozmawiaj, popro o wysanie
e-maila ze zmianami, ktre wymagaj sprawdzenia, albo pocz si zdalnie z jej komputerem, by zobaczy, nad czym pracuje. Niezalenie od tego, czy Twoi ludzie pracuj
102
zdalnie, czy na miejscu, nie ograniczaj si do rozmowy. Przegldaj kod i pro o zademonstrowanie, jak dziaa. Komentuj. Udzielaj zasuonych pochwa. Zanim si poegnasz,
omw zadania na jutro.
Dziki codziennym przegldom Twoi programici nigdy nie bd musieli wyznawa, e
maj miesic opnienia. Najdusze opnienie, o jakim moesz usysze, to jeden dzie.
Cd PcddnidoeezePM ni
Produkcja oprogramowania to praca zbiorowa, ale sam akt programowania to samotne
dziaanie. Regularne cotygodniowe spotkania to najlepszy sposb na podtrzymanie ducha
zespou, dbanie o to, by wszyscy byli poinformowani, omwienie biecych problemw
i przegld postpw. Jest to rwnie okazja do dyskusji na bardziej oglne tematy. Cotygodniowe spotkania to dla programistw idealna okazja do zadawania pyta, a dla menederw do poinformowania wszystkich, jakie wystpiy problemy.
Zebrania najlepiej odbywa na pocztku pracy w poniedziaek rano. Zesp bdzie czu si
wieo po weekendzie, ktry daje te czas na przemylenie tego, co osigno si w zeszym tygodniu.
BpMzeeoyzcyo
Jeeli w zespole nie ma adnych wybitnych mylicieli, rozwizaniem moe by burza
mzgw. Najlepiej gdyby udao si zebra cay zesp i obecny by kto z marketingu,
aby by wiadomy postpu i wyjani kwestie, ktre maj wpyw na poziom sprzeday.
Warto zaprosi rwnie blisko mieszkajcych pracujcych zdalnie. Jeeli mieszkaj dalej,
zorganizuj telekonferencj lub zarezerwuj im bilety lotnicze. Wszystko w miar zdrowego rozsdku.
Najwaniejsze w burzy mzgw jest to, e aden pomys nie jest zy. Prowadzcy moe
zaakceptowa najdziwniejsze idee. Ewentualnie moe poprosi o wyjanienie. Wszelkie
dalsze nagabywanie zwykle nie sprzyja efektywnoci.
Kady pomys naley zapisa w zwizy i jasny sposb bez opatrywania go komentarzami.
Argumenty przeciwko pomysom zwykle mwi same za siebie, a w lunej atmosferze
jedna myl prowadzi do drugiej. Meneder projektu powinien przejrze protokoy, podpisa je i rozda wszystkim zainteresowanym.
W przypadku wikszych projektw korzystny jest krtki raport na koniec kadego tygodnia, odnotowujcy postpy i problemy. Takie raporty, zwykle przygotowywane przez
menederw projektu, nie musz by zbyt formalne i mog by albo rozdawane, albo
rozsyane e-mailem.
W nr ezeP e c neo
Bardzo czsto programici natrafiaj na mur. Z jakiego powodu program nie akceptuje
kolejnej inkrementacji i nikt nie jest w stanie stwierdzi dlaczego. Wwczas konieczny
jest powrt do poprzedniej wersji. W trakcie pisania programu co takiego moe si zdarzy wiele razy.
103
Aby unikn niepotrzebnego zamieszania, warto dysponowa dobrym programem do kontroli wersji oprogramowania. Taki program zachowuje stare kopie, indeksuje zmiany i ledzi,
kto co zrobi i kiedy. Ten elektroniczny archiwista pozwala analizowa wczeniejsze
wersje programu i wyszukiwa rnice midzy poszczeglnymi wersjami. Jest szczeglnie
przydatny w sytuacji, kiedy nie potrafisz dotrze do tego, co sprawio, e program zwariowa.
Najprostsze programy do kontroli wersji przechowuj jedynie wskazane pliki i zarzdzaj nimi. Bardziej wyrafinowane umoliwiaj jednoczesne wprowadzenie zmian, automatyzuj konsolidacj, wymuszaj testy regresyjne, a czasem nawet tworz i kompiluj gotowy produkt. Niezalenie od wymaganego stopnia zoonoci, nie zaczynaj pracy,
nie instalujc wczeniej oprogramowania do kontroli wersji. Zadbaj te, by Twoi podwykonawcy i pracownicy zdalni dysponowali kompatybilnymi wersjami.
Recpn Mneerdnidnid ce
Im szybciej zaczniesz testowa produkt, tym szybciej wykryjesz i usuniesz usterki. Im
szybciej programici dowiedz si, e ich kod integruje si i dziaa, tym szybciej moliwe
stanie si wprowadzenie produktu na rynek. Sprytni inynierowie tworz projekt w taki
sposb, by dopuszcza on monta caoci z gotowych prefabrykatw. Dziki temu mog
uruchomi produkt w fazie zarodkowej tak szybko, jak to tylko moliwe. Kolejn zalet
tej techniki jest moliwo zademonstrowania klientom i zarzdowi pierwszych dziaajcych wersji. 94% firm, ktre odniosy sukces, wykonuje codzienne lub cotygodniowe
konsolidacje. Firmy, ktre nie odniosy sukcesu, konsoliduj kod raz na miesic albo i rzadziej (Secrets to Software Success, Detlev Hoch et al).
Kdnieez n idoeerddp
Przed rozpoczciem pracy nad jakimkolwiek projektem musisz zadba o mechanizm,
ktry automatycznie tworzy kopie zapasowe kodu. Kopie powinny by przechowywane
poza terenem firmy, aby zapobiec ich utracie w przypadku wamania lub poaru. Mona
albo fizycznie przechowywa je w innym miejscu, albo przesya je poczt elektroniczn lub protokoem FTP. Pamitaj, by uwzgldni kod pisany przez podwykonawcw
i pracownikw zdalnych. Za bezpieczne tworzenie kopii zapasowych odpowiada meneder projektu.
104
ProjwetZawoweobw
Jeeli projekt jest realizowany na zlecenie, to im duszy jest czas od rozpoczcia projektu
do dostarczenia gotowego produktu, tym bardziej naraony jeste na problemy z klientem. Jeeli klient jest niedowiadczony, powi mu wicej czasu i zadbaj, by zrozumia
cay proces (moesz np. namwi go na przeczytanie niniejszej ksiki), a take powi szczegln uwag temu, by priorytety byy zgodne z kolejnoci potrzeb klienta,
a nie Twoj wygod.
Po dopracowaniu specyfikacji i zasileniu Ci pierwszym zastrzykiem gotwki klient
bdzie mia duo czasu na refleksj na temat tego, o co tak naprawd mu chodzio. Czsto
bdzie prbowa wprowadzi pniejsze zmiany bez ponoszenia kosztw. Zmiany w prawie, gospodarce lub wewntrznej sytuacji firmy klienta rwnie mog wpyn na wymagania. Jednak nawet bez tego typu oddziaywa niewielu klientw potrafi naprawd
wyobrazi sobie to, co zlecili. W kocu dlatego wanie Ty piszesz program, a klient jest
klientem.
Klienci wiedz za to dokadnie, co im si nie podoba, kiedy ju to zobacz. Wwczas
nie omieszkaj o tym powiedzie. Czasami przesadzaj w obawie, e jeeli nie bd tego
robi, zostan zignorowani. Czasami nie do koca potrafi wyrazi, o co im chodzi. Suchaj uwanie i na bieco notuj wszystkie kluczowe uwagi. Suchaj nie tylko tego, co
mwi, ale tego, co prbuj powiedzie. Pniej przemyl wszystko z ich punktu widzenia
i ustal, co jest dla nich najbardziej korzystne.
Jeeli klient wydelegowa do wsppracy z nami menedera redniego szczebla, najlepiej interpretowa wszelkie jego zalecenia dosownie. Jeeli pniej okae si, e program nie dziaa jak trzeba, okae si rwnie, e zosta napisany idealnie wedug specyfikacji menedera. Menederowie maj wiadomo, e kto znajdzie nieprawidowoci
i obwini wanie ich. Krytyka moe by w tym przypadku drobna albo potna. W takiej sytuacji najlepiej nie robi zamieszania. Zaoferuj, e sam postarasz si wszystko
poprawi. Nastpnie dopisz do rachunku suszn sum, ale dyskretnie. Osoba, z ktr si
kontaktujesz, doceni, e wyratowae j z opresji i e Twoja firma stworzya dokadnie
to, czego potrzebuje jej firma. Najczciej bdzie wdziczna.
Pamitaj jednak, e za pewne bdy obwiniony moesz zosta Ty. W kocu te nie jeste nieomylny. Jeeli okae si, e rzeczywicie popenie bd, we za niego odpowiedzialno i postaraj si jak najszybciej go poprawi. Jeeli jednak to, o co prosi
klient, jest powan zmian, przypomnij taktownie, e przy okazji zatwierdzania specyfikacji utworzone zostay rezerwy na dodatkowe koszty. Polegao to na dokadnym,
105
wsplnym przeczytaniu kadego elementu specyfikacji, by zminimalizowa konieczno wprowadzenia duej liczby poprawek. Przede wszystkim rb wszystko, by do takiej sytuacji nie doszo. Jeeli ju dojdzie, staraj si zaagodzi problem na wczesnym
etapie, pokazujc klientowi kolejne konsolidacje programu.
Pokazywanie klientowi konsolidacji w trakcie realizacji projektu przypomina nieco pokazywanie przyszym rodzicom zdj podu. Gdy potem przychodzi na wiat syn lub
crka, nie jest to ju taka niespodzianka. Zawsze, gdy klient prosi o co nowego lub
nowatorskiego, sprytne firmy programistyczne zdobywaj jego poparcie, demonstrujc
kolejne konsolidacje i prototypy. Klient szybko dostrzee wwczas, e nie da si od razu
trafi w dziesitk i zawsze potrzebne s wyczerpujce dyspozycje w kadym zakresie.
Zapoznajc klienta z postpem prac sprawiasz, e zaczyna on uczestniczy w procesie
tworzenia, i gdy ju jest po Twojej stronie, bdziesz zaskoczony jego pomysowoci
i wsparciem.
Jeeli rozwizanie nie ma zaawansowanego technologicznie charakteru, najlepsz osob
do prezentacji konsolidacji jest zwykle meneder projektu. Najczciej to on najlepiej
zna potrzeby klienta oraz tworzony program.
Zawsze, kiedy klient prosi o now funkcj, pamitaj, e dodajc j, by moe rozwizujesz problemy, z ktrymi borykaj si inni klienci. Zastanw si, czy w Twoim najlepszym interesie ley obcienie klienta caym kosztem jej stworzenia, czy podzieli koszt
pomidzy przyszych klientw. Pomyl, ile czasu zajmie stworzenie tej funkcji i w jaki
inny sposb firma mogaby ten czas wykorzysta. Pomyl o tym wszystkim rwnie
z perspektywy rynku.
106
eo
PcznPci
NdoienM cdonicP
Pamitasz swj pierwszy dzie w nowej szkole? Ktry z uczniw wzi Ci pod swoje
skrzyda i pokazywa Ci wszystko. Najszybszy sposb na wdroenie nowego czonka do
zespou to wyznaczenie kogo ze starszych pracownikw, by go wprowadzi. Kilka dni
patronowania zwykle wystarczy, by nowa osoba poznaa ludzi i dowiedziaa si, u kogo
szuka pomocy.
oi ni
Kiedy ludzie zaczynaj prac, trzeba ich przedstawi. Powinna przy tej okazji nastpi
wymiana nazwisk, funkcji i atwych do zapamitania szczegw. Na przykad: To jest
Sadie Brown. Opiekuje si bazami danych i jest maniaczk latania lotni za odzi motorow, A to jest Chris White, nasz spec od marketingu. Zrobi wietn robot przy
projekcie Mars. Z kad osob skojarz jaki wart zapamitania fakt.
W czasie oprowadzania nowego pracownika po wszystkich dziaach (lub po pokoju)
zdysz z grubsza opowiedzie mu o tempie pracy, o tym, kto komu podlega, co powinien
zrobi, gdy napotka powany problem, jakiego wsparcia moe oczekiwa itd.
Staraj si pozna osobicie swoich ludzi. Podwo ich do domu albo zabieraj na obiady.
Dowiedz si, czego dokonali, czy lubili szko, jak im si ukada w domu, z czego s
dumni i jakie maj aspiracje. Powiedz te co o sobie. Czasem moecie w ogle nie
rozmawia o sprawach zawodowych, a dziki temu rodowisko pracy stanie si bardziej
komfortowe.
Zanim rozdzielisz prac lub opublikujesz harmonogramy, zorganizuj zebranie, by przedyskutowa najdrobniejsze szczegy. Wyjanij, w jaki sposb projekt ma tworzy cao, jaki jest Twj styl zarzdzania, czego oczekujesz od kadego pracownika i czego
pragniesz za wszelk cen unika.
107
Reakcja
Jeeli znajdziesz si w ktrej z powyszych sytuacji, nie obawiaj si zleci innemu programicie poprawienia lub napisania od nowa wadliwego fragmentu kodu. Jeeli now
wersj kodu pisze ten sam czowiek, zwykle trwa to trzy razy szybciej, ni napisanie
pierwotnej wersji. Jeeli programista notorycznie traci grunt pod nogami, zastanw si
powanie, czy w ogle si do niej nadaje.
Jeeli na uczelni bdziesz bada co przez trzy lata, po czym napiszesz prac magistersk, w ktrej stwierdzisz, e to co nie dziaa, tytu magistra masz prawie zapewniony.
W wiecie biznesu niepowodzenie to ostatnia rzecz, jaka jest nagradzana. Pamitaj jednak, e niektrzy z najwikszych ludzi sukcesu dowiadczyli poraki, zanim osignli
sukces. Ich zdaniem poraka nie zasuguje na spoeczne potpienie, z ktrym zwykle si
spotyka. Jeeli zdasz sobie spraw, e utkne w martwym punkcie, jak najszybciej
zwoaj zebranie. Jeeli nikt nie znajduje ratunku, sprbuj podej do problemu z innej
strony. Mimo e jest to trudna decyzja, czasami wicej sensu ma wstrzymanie projektu
ni parcie dalej.
Oto typowe okolicznoci, w ktrych najlepiej zwoa wszystkich menederw i ustali,
czy warto kontynuowa projekt:
t
108
Kluczowi ludzie nie s ju dostpni, a dalsza praca bez nich nie jest moliwa.
Wywdwyw,aeywdZaeeodewZ
Programici, jak wszyscy rzemielnicy, potrafi dopracowywa i udoskonala swoje dzieo
w nieskoczono. Krytyczne moliwoci funkcjonalne wymagane z punktu widzenia
marketingu zawarte zostay w planie projektu. Pozytywne wyniki testw potwierdz
eliminacj usterek. Po spenieniu tych kryteriw oprogramowanie jest gotowe do premiery. Nawet jeeli siedzisz w pokoju i samotnie przesz do przodu, powiniene pamita,
e Twoim zadaniem jest co wicej ni tylko pisanie kodu.
Nie myl nawet o rozpoczciu programowania, jeeli nie zakoczye tworzenia planu.
Oto lista kontrola pozwalajca dokoczy plan:
1. Zatrudnij najlepszych moliwych ludzi.
2. Wybierz osoby, ktre znaj bran, w jakiej dziaa uytkownik kocowy.
3. Znajd menederw, ktrzy zajmowali si tym w przeszoci.
109