Nowe odkrycie - Phing

Zawsze myślałem, że z uwagi na to iż PHP jest językiem skryptowym wszysto co jest związane z procesem budowania i kompilacji - nie dotyczy PHP właśnie...

Tzn. zawsze wiedziałem, że kompilacja się odbywa podczas wykonywania kodu, więc mnie nie zajmowała. Klawisz F9 z Delphi czy BorlandBuildera zastąpiony został przez klawisz F5 w przeglądarce ;)

Jeśli chodzi o budowanie (Crtl+F9 zdaje się ;)) to wiedziałem, że zawarta jest w tym procesie. Reszta mnie nie interesowała, więc osunąłem się w słodkie objęcia ignorancji.

Czytając książki sugerujące stosowanie systemów ciągłej integracji (CI) i konsolidacji myślałem sobie, że spoko, fajnie by było, ale jednak w PHP nie ma czegoś takiego jak integracja i konsolidacja.

Nie mogłem bardziej się mylić ;) Dopiero przy trzeciej książce, w której wspomniana jest CI mnie olśniło:
Budowanie aplikacji to cały proces, który zmienia czysty kod z repozytorium w działającą aplikację!

A zatem obejmuje stworzenie bazy danych o odpowiedniej strukturze(*), ustawienie odpowiednich uprawnień do katalogów, które tego wymagają, wypełnienie bazy danymi startowymi i wszystkie inne czynności wymagane do poprawnego używania aplikacji.

Niezwykle ważne jest, aby móc cały ten proces zautomatyzować. Jedna z rzeczy jakich nauczyłem się podczas mojego, dwuletniego już, stażu w zawodzie to:
Jeśli jest do wykonania skończony ciąg operacji oraz
informacja o tych operacjach zapisana jest w pamięci ludzkiej
to
istnieje skończona, stosunkowo mała, liczba powtórzeń ciągu tych operacji, że
przynajmniej jedna z operacji nie zostanie wykonana.

Nazywę tą regułę "Zasadą zapominania". Dlatego warto zautomatyzować ten proces przy pomocy chociażby narzędzia Phing (jest to php'owy odpowiednik Ant'a).

Możliwe, że niedługo napisze Wam co i jak z tym Phing.

* Nigdy nie wiedziałem dlaczego przechowywanie struktury bazy w repozytorium jest moją obsesją. Widać podświadomie czułem, że kiedyś będę używał Project Build System(s).

Działanie 8.1 i 8.2: Dlaczego warto dwa razy się zastanowić zanim się na nie rzucimy

O tej porze roku - prawdziwy urodzaj. Wszyscy razem z wiosną budzą się i piszą projekty o unijne dotacje. Te o których myślę to działania 8.1 i 8.2 - projekty, których osią często jest szeroko rozumiany "system informatyczny".

W tym artykule chciałbym zwrócić uwagę na ukryte problemy, których możesz nie być świadom pisząc projekt z myślą o tym, żeby po akceptacji zlecić go zewnętrznej firmie budującej systemy informatyczne.

Przede wszystkim specyfika wsparć unijnych wymaga, aby taki system został w (niemal) 100% wyspecyfikowany. To jest wymóg szkodliwy, zakładający że

• klient dokładnie wie czego mu potrzeba
• potafi doskonale wyartykuować swoje myśli
• analityk w lot złapie o co klientowi chodzi i...
• ... idealnie zamodeluje te wymagania

Takie rzeczy możliwe są co najwyżej w przyszłowiowej "erze" (czyt. w reklamie i marketingu). Każdy kto miał styk z wytwarzaniem oprogramowania w stylu wodospadowym (dokładnie takim jaki wymusza UE) wie, że to bardzo rzadko jest możliwe.

Wykorzystując analogię budowlaną, gdyby projektem był dom, to musiałbyś najpierw móc opisać słowami jaki dom potrzebujesz. Nie zamówiłbyś u architekta szkicu (prototypowanie!) bo masz nadzieję, że szkic upchniesz w całym projekcie i zapłaci Ci za niego unia. Wszystko co możesz to powiedzieć co chcesz móc robić w tym domu:
spać, kąpać się, zjeść obiad, zaparkować samochód, oglądnąć telewizję, urządzić przyjęcie.
Czy z czymś takim poszedłbyś do firmy budowlanej, żeby oszacowali koszty zbudowania takiego domu?
Niech masz wstępnego projektu, bo zapłaci za to Unia. Nie masz żadnego szkicu i chcesz do planu dodać jakieś szacowanie, bo Unia wymaga, żeby na samym początku podać kwoty.

Z powyższej listy, można wywnioskować, że potrzebna Ci kuchnia (chcesz jeść), salon (tv + przyjęcie), garaż, sypialnia, łazienka. Doświadczony wykonawca domyśli się, że potrzebujesz też toalety mimo iż na liście "zrobić siku" zapomniałeś umieścić. Ale nie domyśli się, że salon powinien mieć przynajmniej 200m bo przyjęcia chcesz dla 100 osób organizować. Nie wie ile tych sypialni. Czy w ogóle chcesz ogród? Może ogrzewanie? Nie wspomniałeś nic o oknach, ani drzwiach.

Przejdźmy dalej. Kolejną wadą projektów wspieranych przez Unię jest to, że Unia za to płaci. Tym razem będzie analogia zakupowa. Wyobraź sobie, że idziesz do sklepu na zakupy i:

1. bierzesz 500zł własnej ciężko zarobionej krwawicy
2. ktoś daje Ci 500zł i to co wydasz to Twoje, czego nie wydasz - musisz oddać

Zagadka: Które zakupy zaowocują zakupem naprawdę potrzebnych rzeczy?
Dokładnie tak samo jest z "systemem informatycznym". Gdy Ty za niego płacisz - jesteś zainteresowany funkcjonalnościami, które naprawdę zwiększą Twoją wydajność. Gdy płaci Unia - upychasz tam ile się da bo "a nuż się przyda". Najważniejszym problemem w tym wypadku jest to, że takie upychanie kilkuktornie komplikuje projekt. A to z kolei

• zwiększa koszt całego projektu (tym się nie przejmujemy, bo unia płaci),
• implikuje jeszcze mniej dokładne niż "wróżenie z fusów" szacowanie (ryzykujemy obsówę projekty - Unia może nie zapłacić, ale nie przejmujemy się, bo w umowie załączymy kary umowne i wykonawca zapłaci)
• skutkuje skomplikowanym do wdrożenia systemem, pełnym niepotrzebnych funkcji, który muszą opanować Twoi pracownicy (robi się nieprzyjemnie, bo za to Unia nie zwraca, płacisz tylko Ty)

Dlatego warto się zastanowić, czy zwyczajnie warto. Czy na prawdę chcesz mieć Wielką Kobyłę za 150 tysięcy złotych, pełną niepotrzebnych funkcji, która była robiona w pośpiechu i przez to nikt nie chce nawet zaglądnąć do jej kodu, żeby cokolwiek zmodernizować? Czy chcesz czekać na Wielką Kobyłę za 150 tysięcy półtorej roku i kiedy dostaniesz ją do testów (sic!) wiesz, że otoczenie biznesowe i konkurencja zmieniły się na tyle, że przydało by się mieć juz coś lepszego?

Alternatywą jest system mniejszy. Zawierający 10% funkcjonalności Wielkiej Kobyły. Ale są to te rzeczy, które zwiększają Twoją wydajność (a co za tym idzie konkurencyjność) na przykład trzykrotnie. Może zapłacisz za nie więcej niż 10% ceny Wielkiej Kobyły i z własnej korzyści, ale spójrz na stosunek cena/korzyści. A co jeśli dodam do tego taki bajer:
Po dwóch miesiącach Twoi pracownicy uzywają systemu. Oni stają się specjalistami w zakresie jego obsługi i mogą współpracować przy jego rozwoju. Na pewno będą miec świetne pomysły, aby nieco ulepszyć działanie programu znów poważnie zwiększając swoją wygodę (wydajność!) pracy.
Przypomnij sobie ile razy używając Standardowego Programu (MsExcell, Outlook, Firefox etc.) miałeś poczucie "Kurcze, gdyby zmienić tutaj to i to, to bym się mniej naklikał przy tych codziennych ... (raportach, analizach, wstaw cokolwiek)".

To są rzeczy, których nie przewidzisz projektując Wielką Kobyłę.

Dlatego zamiast liczyć złotówki (150tys.) których nie musiałeś wydawać, policz korzyści których nie udało Ci się osiągnąć. Wiem, że to boli bardziej i nie jest takie proste. Nie mam pojęcia czy Twoja księgowa to potrafi ;).

Możesz też spróbować odpowiedziec na pytanie: Czy na przyjęciu/konferencji/piwku z ludźmi z branży wolisz:
a\ Opowiedzieć o tym jak to ostatnio wdrożyliście Customer Relationship Management Entenrprise Edition (nazwa kodowa Wielka Kobyła) za 150 tysięcy złotych, podciągnąć spodnie, odchrząknąć, a potem obwąchać pobliską latarnię i zaznaczyć swoje terytorium*
b\ Pochwalić się jak udało Wam się zwiększyć wydajność jednego z działów trzykrotnie za mniej niż miesięczną pensję dla tego działu. Polecić ekipę, z którą naprawdę dobrze się Wam pracowało. Następnie wrócić tego wieczoru do domu z długonogą menadżerką (ew. wspaniale umięśnionym, przystojnym menadżerem) spragnioną szczegółów na temat tego projektu.

Na zakończenie: pamiętaj, że ekonomia to coś więcej niż rachunkowość. Więc przestań liczyć tylko dutki na koncie.

(*)wiem, odpowiedzi są tendencyjne, ale to nie jest nielegalne ;)

Zarządzanie wersjami STRUKTURY bazy danych w cakePHP 1.2

W poprzednich postach (m.in. zarządzanie wersjami oprogramowania) udało mi się nakreślić problem przy zarządzaniu oprogramowaniem pojawiający się na styku kod-baza danych. Nawet mogę powiedzieć, że mały sukces na tym polu odnotowałem przy pomocy ImageBehavior, jednak jeśli chodzi o strukturę - ciągle zmagałem się do tej pory z przeciwnościami.

Jednak okazuje się, że cake w nowym wydaniu wychodzi nam na przeciw razem z klasą Schema, oraz z narzędziem konsolowym ./cake schema ... po krótce opowiem o co chodzi.

Zabawę z tym narzędziem najlepiej zacząć mając już jakiś zalążek aplikacji (tabele + modele). Jeśli sprawiamy ten podstawowy warunek możemy wpisać w konsoli ./cake schema generate ... ot tak, dla jaj.

Następnie możemy się w katalogu app/config/sql/ namierzyć plik schema.php. To właśnie artefakt wygenerowany przez nas przed sekundą. Można w celach samorozwojowych zajrzeć do środka...

Jednak ciekawe rzeczy dzieją się, kiedy ponownie wywołamy to samo polecenie: otóż cake rezolutnie zauważy, że plik schema.php już istnieje i zapyta nas co dalej. Polecam wybór opcji [S]napshot i ponowny rzut oka do wspomnianego wyżej katalogu. Co widzimy? Dokładnie! Nowy plik o nazwie schema_2.php :D Zachęcam do zapoznania się z helpem (./cake schema help).

Wystarczy, że teraz przekonam zespół, aby w sytuacji, gdy nastąpiły zmiany w bazie, przed commitem wywołali to polecenie. Jest jeden problem, którego ewentualnie można się spodziewać - sporadycznych konfliktów. To znaczy sytuacji, w której dwóch programistów:

1. ściąga repozytorium, 
2. dokonuje (nawet różnych) zmian w bazie, 
3. zatwierdza dane: 
1. schema generate, 
2. svn add schema_X.php, 
3. svn commit

Problem w tym, że w takiej sytuacji w punkcie 3.3 jeden z nich dostanie informację

Nie mogę dodać schema_X.php do repozytorium, gdyż takowy  już w repozytorium istnieje.
Z poważaniem Twój
SVN

Nie jest to jakaś wielka tragedia, jak przy każdym konflikcie trzeba będzie go rozwiązać (w tym wypadku przy spotkaniu tych dwóch programistów). Jednak myślę, że takie sytuacje można by zlikwidować wywołując tą sekwencję w jednym ciągu (nie np. commit po dwóch godzinach od schema generate), może nawet napisać prosty skrypt, który załatwi to za nas (taki svncommitwithcakeschemagenerate.sh ;))

W tej branży 2+2 nie równa się 4

Ten problem nakreślił niedawno Patrys na blogu, który czytuję (http://room-303.com/blog/2009/02/20/przypowiesc-o-osobomiesiacu/) Mam ochotę napisać o tym nieco więcej.

Ciągle mam problem ze złym podejściem do produktu jakim jest oprogramowanie. Dlatego będę pisał o tym pewnie za każdym razem, gdy da mi się we znaki. Jak zwykle zpróbuję opisać to na przykładzie.

Załóżmy, że pytasz mnie ile czasu pracy jednego programisty zajmnie gdyby miał zaprogramować:

- Prosty blog
 Ja odpowiem, że dwa miesiące.
- Galerię zdjęć
Ja również odpowiem, że dwa miesiące.

Jeśli uważasz, że to wystarczające szacowania i gdybyś chciał dostać system, który ma funkcjonalności kryjące się pod hasłem "Prosty blog" i "Galeria zdjęć", oszacujesz już sobie sam, że to razem 4 miesiące...

Otóż jesteś w błędzie. Ten nowy system zajmie więcej czasu.

Jeśli uważasz, że przypisując czterech programistów do tego projektu czas jego wykonania skróci się czterokrotnie - również się pomyliłeś. Zapomniałeś o tym, że nie zawsze można podzielić projekt na kilka niezależnych elementów, które można implementować współbierznie. Nawet gdyby się dało - ktoś musi odwalić tą robotę, odpowiednio zaprojektować i koordynować współbierzną implementację.

Dlatego jeśli jesteś menadżerem, kierownikiem projektu, sponsorem lub klientem - oddasz przysługę wielu ludziom, jeśli przestaniesz traktować tworzenie oprogramowania jak skręcanie długopisów.
Nam zaoszczędzisz nerwów i wrzodów na żałądku, a sobie - rozczarowań.

Odpowiedzialność społeczna przedsiębiorcy, a motywacja pracownicza.

Dziś wielu przedsiębiorców ma świadomość tego, że motywowanie
pracowników jest ważnym aspektem działalności menadżerskiej. Odnoszę
jednak wrażenie, że wydaje się im to istotne jedynie dlatego, że wierzą
w to iż jest to opłacalne. Głównie dlatego, że wdrożenie nowego
pracownika jest kosztowne. Chciałbym jednak przedstawić aspekt etyczny
motywowania i systemu motywacji pracowników.

Czym jest motywacja, a czym odpowiedzialność
społeczna?

Odpowiedzmy sobie najpierw na to
ważne pytanie. Philip Zimbardzo pisze: „Motywacja (motivizion) to ogólny
termin na określenie wszystkich procesów zaangażowanych w rozpoczęcie,
kierowanie i podtrzymanie aktywności fizjologicznych i psychicznych”
¹. Motywowaniem nazwiemy zatem
wywoływanie (w sobie lub w innych) tych procesów.

Odpowiedzialnością społeczną
możemy nazwać dobrowolne zobowiązanie do uwzględniania interesów
społecznych, ochrony środowiska przez przedsiębiorcę (a w efekcie przez
przedsiębiorstwo) w trakcie budowania strategii, oraz przestrzeganie
tego zobowiązania w działalności przedsiębiorstwa
². Ta odpowiedzialność przejawiać
się może w finansowaniu publicznego transportu, budownictwa, rzetelnej
informacji na temat produktów, trosce o ekologię³
i wielu innych.

Jest jednak jeszcze jeden aspekt,
w którym odpowiedzialność społeczna przedsiębiorstwa może zostać
wyrażona- umożliwienie rozwoju pracownikom, którzy przecież również są
częścią tego społeczeństwa.

Motywowanie pracowników- w czym się przejawia?

Motywowanie zakłada, że można
wpłynąć na wewnętrzny stan napięć pracownika w celu skłonienia go do
pracy, lub zwiększenia jej wydajności. Dlatego musi wykorzystywać metody
i narzędzia wpływu społecznego, które nierzadko stawiają osobę stosującą
je świadomie na pograniczu manipulacji. Wykorzystują one często
naturalne potrzeby drzemiące w ludziach. Dodatkowo Abraham Maslow
różnicuje motywację na wynikającą z niedoboru i wynikającą z potrzeby
wyjścia poza stan aktualny
⁴.
Dlatego w dwojaki sposób motywować pracowników: albo zabierając im, lub
utrudniając dostęp do pewnych nagród, lub strasząc odcięciem tego
dostępu (obcinanie premii, grożenie zwolnieniem); albo roztaczając przed
nimi wizję zaspokojenia potrzeb wyższego rzędu takich jak rozwój i
uznanie. Nawet gdyby oba podejścia były tak samo efektywne, to warto
zastanowić się jakie efekty, oprócz zwiększenia wydajności pracownika,
przynosi nasze działanie.

W pierwszym przypadku wywołany
stan jest bliski niewolnictwu. Praca wynika z zagrożenia (życia,
stabilizacji) pracownika, zatem wydaje się pracownika degenerować. Nie
ma co liczyć na inwencję tak motywowanego pracownika. Nie ma też co
liczyć na jego lojalność. Widać ten efekt aktualnie w Polsce: wcześniej
zatrzymanie pracownika było proste, gdyż panował rynek pracodawcy,
wysokie bezrobocie oznaczało wysoką konkurencję wśród pracowników.
Dodatkowo w wypadku ludzi starszych strata pracy na pół roku mogła
oznaczać całkowite wypadnięcie z „obiegu”. Aktualnie przy zwiększonym
wzroście gospodarczym i otwarciu granic w swobodnym przepływie między
innymi pracowników, polskie firmy nie wytrzymują niejako konkurencji z
zachodnimi przedsiębiorcami.

Zastanawiające jest, że ludzie
gotowi są jechać tysiące kilometrów i rozstawać się z rodzinami; moim
zdaniem nie jest to tylko wynikiem nadziei na zwiększenie zarobków⁵.

Odkładając jednak na chwilę
sytuację aktualną w Polsce, zastanówmy się co się stanie, jeżeli
większość pracodawców zacznie straszyć swoich pracowników. W takim
czarnym scenariuszu łatwo dojść do wniosku, że prędzej czy później praca
sama w sobie stanie przestanie być źródłem dumy, czy zadowolenia. Raczej
będzie przykrym obowiązkiem, lub nawet przedmiotem żartów. Ktoś, kto
wkłada wiele energii w pracę stanie się w oczach społeczeństwa
„frajerem”⁶. Etos pracy przestanie istnieć.
Bumelanctwo i kombinowanie będzie wartościową i cenną umiejętnością. Do
tego spadek zaufania społecznego i mamy idealną mieszankę, która zwolni
skutecznie wzrost dobrobytu całej społeczności.

Wracając jeszcze na moment do
problemu emigracji zarobkowej. Sam, pracując w wakacje, jeszcze w
liceum, w pewnej z firm po usłyszeniu nowych wymogów co do wydajności
pracy, gdy ktoś wyraził niezadowolenie usłyszałem, że przed bramą czeka
stu takich, co będą za połowę tego co my pracować. Osobiście nie
przejąłem się tym za bardzo – w końcu chciałem mieć tylko trochę
oszczędności na rozpoczęcie studiów, jednak pracowali tam ludzie, dla
których ta praca oznaczała byt! Nie trudno mi wyobrazić sobie, jak
właśni Ci ludzie pierwsi szturmowali przysłowiowe zmywaki w Londynie
również po to, żeby wreszcie pracodawca potraktował ich po ludzku.

Weźmy teraz pod lupę pozytywny
sposób motywacji. Oprócz oczywistych profitów dla organizacji, takich
jak wzrost wydajności, inwencji i zadowolenia pracowników, degeneracja
społeczna opisana wcześniej na pewno nie wystąpi z tego powodu.
Wyobraźmy sobie dziecko, przysłuchujące się rozmowie rodziców, którzy
wymieniają się osiągnięciami w pracy, chwalą rozwojem i wręcz
promieniują zadowoleniem. Niemal pewne jest, że w swoim dorosłym życiu
będzie szukało ono pracy, która w co najmniej takim samym stopniu będzie
źródłem zadowolenia. Zdaję sobie sprawę, że przykłady te nie są poparte
żadnymi badaniami, jednak wydaje mi się, że brzmią po prostu rozsądnie.
Dlatego pokuszę się o stwierdzenie, że przedsiębiorca etyczny jest w
stanie, oprócz towarów wymienionych w cenniku, produkować szczęście. W
sytuacji dominowania takiego postępowania wśród menadżerów – skutki są
odwrotne do przedstawionych powyżej. Budowane jest społeczeństwo
uczciwej pracy, które w całości pracuje na swój dobrobyt.

Warto jeszcze dodać, że
dostarczając pracownikom możliwości rozwoju, sprawiamy po prostu, że są
nieco szczęśliwsi.

Dlaczego zatem etyka czasem się nam gubi?

„Wymiar etyczny bywa często
sztucznie eliminowany z rozważań o zarządzaniu i dlatego bez wzajemnego
powiązanie mówi się często o władzy jako o samodzielnym zjawisku - i o
trosce o innych, byciu w emocjonalnej relacji do innych jako o osobnym
od władzy. Tymczasem te stany są dwoma ekstremami wymiaru etycznego
organizowania. Dopiero wzięte razem przestają mieć charakter typów
idealnych i zawierają całe spektrum realnych możliwości odniesienia
ludzi do siebie.”⁷

Mamy skłonność do upraszczania.
Czasem, żeby coś zrozumieć, musimy zbudować zubożony model, gdyż inaczej
nie bylibyśmy w stanie zrozumieć całości. Nie ma w tym nic nagannego,
pod jednym warunkiem: nie możemy zapomnieć, że mamy do czynienia z
uproszczeniem! Nie można zapomnieć, że jest tam coś jeszcze. Coś co może
nie przynosić bezpośrednich dochodów:

„Władza formalna - struktura,
jest uważana za aktywny potencjał i kojarzona z przywództwem. Troska o
innych, często przybierająca aktywną postać podporządkowania władzy,
jest w rzeczywistości drugą stroną tej samej monety. Jedna relacja nie
występuje bez drugiej;”⁸

To jest właśnie powód, dla
którego warto przypominać o etyce biznesu i etyce w ogóle. Działalność
biznesowa, jak każda inna działalność nigdy nie jest oderwana od
otoczenia, zatem na nie wpływa. Skoro tak, to na tych, którzy podejmują
działalność, ciąży jednocześnie odpowiedzialność, żeby przyniosła jak
najwięcej pożytku, przy jak najmniejszej ilości strat.

Związek społeczeństwa z przedsiębiorstwem.

W pracy „Etyka biznesu” została
podana odpowiedzialność przedsiębiorcy:

"[Menadżer odpowiada – gp] Za
wypracowanie zysku. Biznes produkuje zyski. Firma, a dokładnie zarząd
firmy, musi powiększać zdolność zasobów rzeczowych i osobowych do
tworzenia i produkowania bogactwa. Odpowiedzialność ta - pisze P.
Druckner - jest nie do odrzucenia i absolutna. [...]

Ale społeczeństwo nie może wziąć
z przedsiębiorstwem rozwodu. Musi ponieść straty, jeśli przedsiębiorstwo
nie produkuje koniecznych zysków, musi ubożeć, jeśli nie odnosi
sukcesów. Nakłada to na firmę obowiązek zarządzania w pancerzu etyki"⁹.
Rozmyślania na temat nieetycznego zarządzania zdają się być potwierdzane
tym cytatem. Chcę tylko dodać jeszcze jedno przemyślenie: jak
społeczeństwo może się bogacić kosztem zubożenia społeczeństwa? To
wyraźna sprzeczność potwierdzająca rację bytu etyki w naukach
traktujących o gromadzeniu bogactw.

Jak promować etykę?

J. Dietl i W. Gasparski proponują¹⁰
następujące metody promowania etyki:

1. 
   
   "Propagowanie dobrych wzorów,
   "budujących" przykładów. Powszechnie znane jest postępowanie znanego
   menadżera, który w najgorszym dla Chryslera roku, jako szef koncernu
   zredukował wysokość swojej pensji do jednego dolara rocznie” - moim
   zdaniem najlepsza i najtańsza. Ci którzy mają szczęście doświadczać
   potrzeby etycznego postępowania muszą dawać (i niejako „siłą rzeczy”
   dają) dobry przykład.
   
   


2. 
   
   "Stanowcze potępianie
   nieetycznych zachowań. " Co oznacza zdefiniowanie kodeksu etycznego i
   definitywne jego przestrzeganie.
   
   


3. 
   
   "Powołanie sądownictwa
   polubownego", które jest świetnym sposobem na budowanie więzi
   społecznych. Do tego społecznie akceptowana instytucja arbitra będzie
   idealna do realizowania punktu poprzedniego.
   
   


4. 
   
   "Treningi wrażliwości etycznej.
   " dla tych, którzy nie mieli szczęścia tej wrażliwości się wyuczyć¹¹.
   Miałaby ona polegać na przedstawianiu pozytywnych przykładów etycznego
   postępowania, które odniosły pożądany skutek. Dietl i Gasparski
   proponują również nawyk stawiania się po drugiej stronie. Można to
   nazwać nauką „menadżerskiej empatii”.
   
   

Czym tak w ogóle jest etyka?

Na zakończenie, aby domknąć
rozmyślania, chciałbym zamieścić dwa wybrane cytaty z pracy „Etyka
biznesu”, które odpowiadają na te pytanie.

Pierwszy Tadeusza Kotarbińskiego:

"Tadeusz Kotarbiński, w pracy
'Medytacja o życiu godziwym' podkreśla znaczenie takich wartości, jak:
miłość i przyjaźń, sprawiedliwość, hierarchiczność celów oraz kierowanie
się głosem sumienia, które domaga się od nas postawy znamiennej dla
opiekuna, na którym można polegać, spolegliwego opiekuna¹²"

Drugi Jana Pawła II:

„... Człowiek najpełniej afirmuje
siebie, dając siebie ... nie przyjmując perspektywy daru z siebie samego
, zawsze istnieje ryzyko wolności egoistycznej”

Powyższy tekst to praca zaliczeniowa na
przedmiot "Etyka w biznesie", napisana w połowie 2008 roku. Bardzo
ciekawie i inspirująco wykładany przez dra Leopolda Zgodę. Jego wykłady
otworzyły mi oczy na to, czego do tej pory nie widziałem (choć może
gdzieś pod skórą czułem). Postanowiłem się tym tekstem podzielić (tym
bardziej, że został on dobrze przez doktora oceniony :))

1Cyt. P.G.Zimbardzo,
Psychologia i życie, Warszawa: Wydaw. Naukowe PWN, 1999, s.436

2Zob. Wikipedia,
Wolna encyklopedia, http://pl.wikipedia.org/wiki/CSR,
Dostęp 24/05/2008

3Zob. Anna
Lewicka-Strzałecka, Etyczny wymiar przekształceń gospodarczych w Polsce,
pod red. Adama Węgrzeckiego ; Akademia Ekonomiczna w Krakowie, s 147

4Zob. P.G. Zimbardo,
F.L. Ruch Psychologia i życie, Warszawa 1997, s. 404.

5Można dopatrywać się
tutaj nadziei na lepsze traktowanie, o czym za chwilę.

6Warto porównać to z
nast. cytatem: „Najprawdopodobniej określenie "etyczny menadżer"
wywołałoby u licznej grupy co najmniej zdziewienie, komentarze i znaki
zapytania. Bo "etyczny" obecnie w Polsce to właściwie jaki: "naiwny",
"nieprzedsiębiorczy", a może wręcz "głupi"?”, Etyka biznesu, red. nauk.
Jerzy Dietl, Wojciech Gasparski, s.210

7Cyt. Etyka Biznesu,
J. Dietl, W. Gasparski, s.192

8Tamże.

9Cyt. Etyka biznesu,
s. 209

10Zob. Tamże, s.
224 - 225

11Również dla tych,
którzy to szczęście mieli – zawsze warto tę umiejętność pogłębiać.

12Por. z pojęciem
aktywne współczucie i z ideą Bodhisattwy w buddyzmie, http://www.diamentowadroga.pl/dd20/wspolczucie_jezyk_bodhisattwy,
http://www.diamentowadroga.pl/dd25/dzialania_bodhisattwy

Czy pamiętasz ze szkoły trójkąt czas-koszt-jakość?

Jeśli nie, to z przyjemnością Ci przypomnę.

Wyobraż sobie trójkąt równoramienny. Jego wierzchołki oznaczają osiągalny (fizycznie, technologicznie) maksymalny danej z trzech cech. Jeden jakości, drugi czasu, trzeci kosztu (chodzi o pieniądze, nie abstrakcyjne pojęcie kosztu, bo wtedy oznaczałoby to również czas).

Twój produkt to jeden punkt wewnątrz tego trójkąta. Im mniejsza odległość tego punktu od jakiejś cechy, tym większa jej wartość. Może dokładniej: im bliżej punktu jakość - tym ta jakość większa. Im bliżej punktu koszt - tym taniej. Im bliżej punktu jakość - tym lepszy jakościowo jest produkt.

Jednocześnie maksymalna osiągalna odległość od danego punktu oznacza minimalną (najgorszą) wartość danej cechy...

Dla przykładu wyobraź sobie, że stawiasz mur (metr wysoki, 20metrów długi) na swojej posesji. Chcesz to zrobić jak najtaniej (przesuwasz się do wierzchołka koszt) więc zatrudniasz studenta pierwszego roku socjologii. Nie dajesz mu cegieł, ale każesz znosić kamienie i cegły z ruin, starych fabryk itd. Nie dostanie też cementu z sugestią, że może użyć błota z rzeki wymieszanego ze słomą. Nie płacisz mu pensji, ale pozwalasz rozbić namiot w pobliżu muru, który buduje. Może zjeść co upoluje i ogrzać się na masce Twojego samochodu, gdy wrócisz z pracy... ok zapędziłem się, ale wydaje mi się, że masz już w głowie TEN obraz. Myślę, że efektu końcowego nie muszę już opisywać. Widać, że wyżyłowaliśmy kwestię kosztów, jednak oddaliliśmy się znacznie od punktu jakość i czas (prawdopodobnie będzie liczony w latach, lub pokoleniach potomków owego studenta ;))

Niby sprawa oczywista, ale konsekwencje nie są oczywiste dla każdego. Szczególnie jeśli chodzi o projekt informatyczny. W tym wypadku produkt jest na tyle wirtualny, że występuje pokusa wirtualnego myślenia. Że jak w grze po wpisaniu kodu jesteśmy nieśmiertelni i potrafimy latać, tak tutaj punkt może się rozciągnąć i zetknąć z każdym wierzchołkiem trójkąta. Czy jeszcze muszę pisac, że tak niestety nie jest?

Trochę mnie bajkopisarstwo poniosło, więc na koniec napiszę o korzyściach wynikających z tego, że model ten będziesz miał w głowie.

Jeśli jesteś menadżerem projektu. To jest twój koronny argument w negocjacjach terminów. Jeśli ktoś Ci powie, że ten trójkąt to bujda, że Toyota i w ogóle - nie jesteś jeszcze stracony - czytaj dalej.

Jeśli jesteś klientem, to dobre dla całego projektu będzie, jeśli będziesz o nim myślał realistycznie a nie w kategoriach fantasy. Pamiętasz, że udany projekt leży również w Twoim interesie?

Jeśli jesteś programistą... cóż, możesz sobie ten trójkąt rysować kiedy wiesz, że projekt w którym uczestniczysz oddalił się znacznie od punktu jakość i czas, i nie mieć z tego powodu wyrzutów sumienia ;)


Oczywiście w myśl zasady "zawsze trafisz na większą górę, wyższe drzewo i mądrzejszego człowieka" nie możesz spocząć na larach. Prędzej czy później trafisz na mądralę, który odbije piłeczkę a na niej będzie logo Toyota.
O co chodzi? Otóż są tacy, którzy twierdzą, że model trójkąta jest bujdą, gdyż toyocie udaje się ciągła redukcja kosztów z ustawicznym wzrostem jakości. I nie jest to kłamstwem. Jednak są dwie rzeczy, których przytoczony mądrala sobie nie uświadomił:

1. Trójkąt w modelu jest taki, nie inny w danej chwili.
2. Toyota stosuje podejście procesowe w zarządzaniu powiązane z filozofią kaizen 
3. Dlatego Toyota zmniejszyła swój trójkąt koszt-czas-jakość, a nie wpisała odpowiedni kod w grze ;)
4. To trwało lata!

Dlatego mądrala nie ma racji, bo dany projekt:

1. Ma do dyspozycji taką technologię jaką ma, taki know-how jaki ma i na potrzeby danego projektu tego kapitału nie powiększy (po zakończeniu - owszem)
2. Prawdopodobnie nie wiesz na czym polega zarządzanie procesowe, a nawet jeśli wiesz, to pewnie nie jest wdrożone, a jeśli jest - to znaczy, że w tej kwestii na razie nie wiele możesz poprawić.
3. Z dwóch powyższych wynika, że nie zmniejszysz swojego Trójkąta na potrzeby najbliższego projektu (chyba, że zmienisz wykonawce, ale wtedy trójkąt może okazać się nie równoramienny i punkt kosztu niknie za horyzontem)
4. Projekt startuje już, nie za kilka lat jak już sobie "popróbujemy"

Zarządzanie wersjami oprogramowania

Najtrudniejsze zadanie z jakim się obecnie spotykam w mojej pracy to zarządzanie wersjami produktu.

Od jakiegoś czasu używamy Subversion i pewnie jest o niebo lepiej niż by było bez tego narzędzia, ale dalej jest cholernie ciężko. Szczególnie wtedy, gdy Ciągle wprowadzane są poprawki w bazie. Bywa tak, że mam trzy wersje do synchronizacji: developerską, do testów wewnętrznych i do testów klienta.

Druga zazwyczaj generuje typową ilość znalezionych bugów, a potem sporą ilość 'feature requests' (przegląda ją między innymi manager projektu, który ma dobre pomysły jak usprawnić pracę w systemie; sęk w tym, że poważnie utrudniają one pracę nad systemem).
Trzecia z kolei generuje szum pt. 'na stronie X, link Z jest w nie takim foncie jak potrzeba' i inne problemy ;)

*Razem tworzą żyzne środowisko, z którego co jakiś czas wylęgają się pomysły wymagające zmiany struktury bazy danych.

**Wszystkie trzy wersje są update'owane w różnych momentach, do różnych wersji repozytorium.

Z * i ** wynika, że powinno się zdarzać (i zdarza, a jak!), że na każdej wersji systemu jest inna wersja bazy danych.

Jeszcze nie koniec.

W teamie mam pewną ilość programistów, którzy nie rozwinęli jeszcze umiejętności polegającej na pisaniu kodu w taki sposób, aby był on jak najbardziej elastyczny (dzięki wszystkim bogom za CakePHP, bo przy przenoszeniu systemu na serwer klienta przepisywalibyśmy wszystkie linki... aż mnie ciarki przeszły). Jednocześnie nie mogę ich za to zdyscyplinować - przecież nie dostali żadnych wytycznych jak pisać kod (kto próbował coś takiego napisać, ten wie...)

No i to w sumie wystarczy, żeby przy końcówce projektu mieć poczucie braku kontroli.

Jednak jest pewne światełko w tunelu (nikt nie wyłączył z powodu kryzysu;)), o którym napiszę w następnym poście...
Niektóre wskazówki znajdziesz wponiższych postach:

• Zarządzanie wersjami struktury bazy danych 
• ImageBehavior - pliki w bazie, a jednak na dysku
  

Co jest ważniejsze: funkcjonalność, użyteczność czy marketing?

Jeśli zadałeś sobie kiedykolwiek takie pytanie, to znaczy, że dałeś się wciągnąć w potencjalną świętą wojnę, między działami Twojej firmy.

Programiści pewnie forsowali funkcjonalność, projektanci użyteczność (ang. usability)*, dział marketingu - wiadomo. I wiesz co? Najfajniejsze jest to, że wszyscy oni mają rację!
Jak to możliwe? Ok, wzbogacę to zdanie i wszystko będzie jasne:
Wszyscy oni mają rację, z ich własnego punktu widzenia.
Ty jednak, jako menadżer zobligowany jesteś do widzenia, jeśli nie na ostatecznym poziomie, to chociaż z szerokiej perspektywy. Dlatego musisz wiedzieć (i jeśli chcesz - uświadomić swój zespół), że jest tak:

Bez funkcjonalności nie da się spełnić wymagań użyteczności, nie da się też prowadzić marketingu (produktu, który nie istnieje). Bez użyteczności oprogramowanie o najbogatszym zestawie funkcji jest koszmarne w użytkowaniu, a trudno prowadzić marketing do kiepskiego narzędzia (łatwiej to zrobić z kiepskim szamponem). Na koniec - najgenialniejsze systemy o interfejsie tak intuicyjnym, że przy pierwszym kontakcie każdy jest zaawansowanym użytkownikiem, bez jakiejkolwiek instrukcji jest bezużyteczne, jeśli nikt o tym nie wie.

Ubarwiając wpis pozwolę sobie na metaforę: po co Ci do wyścigów koń, który ma mocne serce, a nie ma nóg? Po co Ci taki, który ma nogi, ale słabe serce? Po co Ci taki, który ma mocne serce i nogi, ale nie ma głowy (innymi słowy - padlina)? Biznes to wyścigi, w których zarabiasz, kiedy jesteś w czołówce, nie tracisz w peletonie, a bankrutujesz w ogonku.


*w Polsce na szczęście coraz większą uwagę zwraca się na to kryterium jakości oprogramowania, do niedawna było to mizerne.

Odpowiednie narzędzia

W poprzednich postach( Czego tak na prawdę ode mnie chcesz [kliencie] ? i Funkcjonalność czy bajery?) napisałem o podstawowych niebezpieczeństwach jakie czyhają na nas w procesie tworzenia dedykowanego systemu dla klienta. W obu przypadkach w pewnym sensie ochroną przed tymi zagrożeniami będzie odpowiedni framework. Poznałem (lepiej lub gorzej) do tej pory trzy frameworki: CakePHP, ZendFramework i Django. Intensywnie pracuję z CakePHP i na nim oprę ten artykuł, pozostałe znam na tyle, żeby mieć pewność, że w podobny sposób pomagają w produkcji oprogramowania i żeby nie musieć opisywać każdego z osobna.

Głównym celem frameworku jest usprawnienie pracy programisty. Ma on dostarczać mechanizmy, które odciążają nas od żmudnego powtarzania nieciekawych czynności (łączenie z bazą, tworzenie milionowego formularza, pisanie kolejnego foreach żeby wydłubać coś z tablicy...). Nieciekawych oczywiście z punktu widzenia doświadczonego programisty, który robi to już długo - zaczynając przygodę z tą dziedziną wszystko jest ciekawe, ale ten stan po jakimś czasie mija.

Jeśli jesteś kompletnie zielony - odradzam zaczynanie przygody z programowaniem od poznania frameworku. Wydaje mi się, że postępując w ten sposób trudniej będzie Ci zrozumieć mechanizmy w nim zachodzące i zamiast mieć możliwość pełnego wykorzystania narzędzia, stanie się on dla Ciebie magiczną różdżką, której potencjału nie wykorzystasz. (oczywiście są wyjątki i możesz robić co chcesz).

Ja jednak nie będę skupiał się na dostarczanych przez framework bibliotekach, bo o tym już wiele napisano. Spróbuję za to napisać jak można go wykorzystać do przeciwdziałania trudnym tendencjom pojawiającym się w procesie produkcji i nie mających wiele wspólnego z samym programowaniem.

Na początek problem specyfikacji wymagań. Maksymalne starania Twoje i klienta, żeby dokładnie określić wymagania i tak nie zabezpieczą Cię w stu procentach. Zawsze po drodze okazuje się, że przydało by się coś innego. Coś mogło by działać lepiej i że pojawił się nowy pomysł. Tak jak z budowaniem samochodu - wkładając wysiłek w obliczenia będziesz pewny, że wycieraczki obejmą maksymalnie przednią szybę, ale dopiero jak się nim przejedziesz to stwierdzisz, że drążek zmiany biegów jest za krótki, a słupek boczny ogranicza Twoje pole widzenia. Gdybyś produkował samochody doświadczenie mógłbyś wykorzystać dopiero w następnym modelu. Ty jednak jesteś farciarzem jakich mało i produkujesz ciągi zer i jedynek, które możesz w każdej chwili zmienić/wyciąć/dodać! Mechanizm zwany w CakePHP Scaffold jest tym, co owo wycinanie, zmienianie i wklejanie czyni bezbolesnym w początkowej fazie produkcji.

W CakePHP scaffolding objawia się w dwóch formach. W pierwszej jest w stanie wygenerować fizycznie modele, kontrolery i widoki na podstawie struktury bazy danych (i podpowiedzi użytkownika). Jest to wykonywane przy pomocy skryptu bake.php znajdującego się w cake/libs/scripts (w wersji 1.19). Efektem tego jest powstanie wszystkich standardowych metod i widoków do operacji takich jak list/view/edit/add/delete. Z uwagi na to, że są one generowane fizycznie - możesz je zacząć zmieniać dostosowując je do swoich potrzeb. Jednak minusem jest to, że w razie zmiany struktury bazy trzeba albo na nowo wygenerować widoki i metody, albo edytować je ręcznie.
Drugą emanacją jest scaffold właściwy. Włącza się go w prosty sposób dodając w kontrolerze linię

var $scaffold;

(Tutaj uwaga - można włączyć scaffold 'globalnie' dodając tą zmienną w AppController, ale wtedy nie należy dodawać już jej w kontrolerach).
Efektem tego będzie każdorazowe generowanie metody i widoku dla standardowych operacji na podstawie struktury bazy danych (tej zdefiniowanej w modelach). Dziać się będzie to tak długo, aż nie usuniemy deklaracji zmiennej, albo nie zdefiniujemy w kontrolerze którejś z metod standardowych. W pierwszym przypadku scaffolding wyłączymy całkowicie dla danego kontrolera, w drugim nie będzie on działał dla metody, którą już zdefiniowaliśmy. Minusem jest to, że nie możemy dostosować widoku do naszych widzimisię (widok nie istnieje fizycznie na dysku)*, ale za to przy każdej zmianie struktury bazy danych widok jest uaktualniany bez naszej ingerencji (dodanie pola varchar zaowocuje pojawieniem się w formularzu pola input, text - textarea, enum - listy wyboru).
To rozwiązanie jest genialne w najwcześniejszej fazie produkcji oprogramowania. Wyobraź sobie, że po zaprojektowaniu samochodu od razu możesz się nim przejechać (fakt będzie brzydki, bez maski i tapicerki) i zobaczyć jak się nim jeździ i czy nie przydałby się większy bagażnik. Tak właśnie jest w tym wypadku: projektujesz bazę danych i już możesz pokazać klientowi podstawowe funkcjonalności**. Możecie z klientem UŻYWAĆ tej aplikacji i stwierdzić, że czegoś brakuje.
Oczywiście nie jest tak super cały czas - w pewnym momencie trzeba po prostu napisać trochę kodu, czasem aplikacji nie wpisują się tak łatwo w szablon listuj/wyświetl/dodaj/edytuj/usuń.
Jednak w 8 przypadkach na 10 sprawdza się doskonale. Dorzuć do tego dobrze zaprojektowaną, znormalizowaną bazę i początkowa faza, która obfituje w zmiany jest tak bezbolesna, jak to tylko możliwe.

* te pliki istnieją fizycznie na dysku, są cache'owane, ale nie nadaje się to do edycji (zostanie nadpisane prędzej, czy później). Do tego wydaje mi się, że istnieje możliwość edycji szablonu, który definiuje jak mają być tworzone widoki, jednak nie zajmowałem się tym do tej pory, więc nie będę o tym pisał.
** pod warunkiem, że nauczysz go patrzeć na system pod tym kątem. Jak klient chce tylko ładny interfejs i nie współpracuje to scaffold nie spełni się w 100%.

Funkcjonalność czy bajery?

Ten wpis zacznę od wyjaśnienia tytułu. Chodzi mi o problem, który
pojawia się w początkowym procesie tworzenia projektu i podjęcie złej
decyzji (albo jej brak i zaufanie do intuicji) ciąży już na całym projekcie.
Funkcjonalność to coś, co aplikacja potrafi zrobić. W prostym
przykładzie bloga to możliwość dodania wpisu, edycji, dodania
komentarza, usunięcie ich etc.
Pod pojęciem "bajery" kryje się to co widać: ładne ikonki, dobra
organizacja elementów na stronie (menu, przyciski, linki), AJAX (tak, wg
mnie to bajer wizualny, ale o tym później), web 2.0-owe pregress bars i
indicators ;)

(Ten post jest kontynuacją http://webbricks.blogspot.com/2008/04/czego-tak-na-prawd-ode-mnie-chcesz.html)

W czym tak na prawdę tkwi problem: w zatraceniu się w pierdołach. Ty
budując aplikację (szczególnie od zera, gdy jest BARDZO niedojrzała)
musisz skupić się na funkcjonalnościach, które ma wypełniać. Jednak
bardzo łatwo ulec pokusie zbyt wczesnego upiększania aplikacji.
Nie podoba Ci się jak domyślnie wygląda tabelka, zamiast linka edytuj
fajnie by było mieć ikonkę, a treści mogłyby się dodawać bez
przeładowania strony... i zaczynasz tworzyć style tylko dla tej tabelki,
umieszczasz ikonki w niepełnym layoucie, implementujesz Ajaxa nie
wiedząc co jeszcze będzie w tym widoku. Efekt jest taki, że robisz
rzeczy na tym etapie niepotrzebne, które są pracochłonne i nie przynoszą
satysfakcji.
Do tego odrywasz się od głównego problemu, który brzmi "zbuduj
DZIAŁAJĄCĄ aplikację", który jest święty i nadrzędny. Bez osiągnięcia
tego celu, upiększenia na które straciłeś tyle czasu i energii, są
niepotrzebne. Poza tym, gdy nie masz doświadczenia i intuicji kogoś kto
ma pięcioletnie doświadczenie w budowaniu aplikacji, bardzo łatwo coś
popsuć (szczególne za pomocą wszędobylskiego Ajaxa <o tym poniżej>).

Nie jestem przeciwnikiem Ajaxa, uważam ten trick (bo przecież nie
technologię) za coś fantastycznego, jednak użyty w niewłaściwym momencie
może wiele popsuć. Jest jak czosnek, który poprawia smak smażonych
potraw, ale dodany za wcześnie jest gorzki i obrzydliwy. Tak samo zbyt
wczesna implementacja rozwiązań w Ajaxie sprawi, że projekt stanie się
trudny w trawieniu.
Dużo lepszym, IMHO, podejściem jest stworzenie aplikacji, która będzie
działać w "czystym" html-u. Łatwiej ją przetestować, a tym bardziej
debugować. Pozbyć się w tym czasie poważnych błędów, zaprojektować
interfejs i dopiero wtedy skupić się na tym, żeby aplikacja była miła
dla oka. Twierdzę, że w tym momencie nie będziesz implementował w
funkcjonalności nic ponad proste, wspomagające funkcje współpracujące z
requestami ajaxowymi. Jestem niemal pewny, że większość tych requestów
będzie mogła działać na standardowych funkcjach, które już
zaimplementowałeś (ew. po drobnej przeróbce).
Podejście od przeciwnej strony owocuje powstaniem osobnych,
specyficznych funkcji dla Ajaxa, obok standardowych. Poza tym
wykrywanie, namierzanie i usuwanie błędów jest trudniejsze.

Nie wiem czy Cię, drogi czytelniku, przekonałem? Jeśli nie, to nie
szkodzi. Jeśli jesteś programistą, to sam pewnie stwierdzisz, że przy
"przeajaxowaniu" projektu w początkowej fazie tylko Ci przeszkadza.
Jeśli jesteś menadżerem, to nie Ty się będziesz z tym problemem użerał
bezpośrednio (jeśli jednak zauważysz, że projekty jakoś dziwnie grzęzną
przy pewnym etapie produkcji, to zastanów się, czy to nie jest problemem).

I tu otarliśmy się o drugą stronę medalu - odbiorcę. Może nim być
klient, gdy masz własne zlecenie, albo szef/menadżer projektu, którzy
nie mają inżynierskich podstaw i inżynierskiego spojrzenia na świat (*).
Postępują oni wtedy jak typowy użytkownik: oceniają aplikację
emocjonalnie - czy się podoba, czy nie. Swoją drogą ja też tak robię,
zanim przekonam się do aplikacji, którą zaczynam używać. Uważam, że nic
w tym złego, jeśli to jest produkt finalny. Jednak na etapie budowy
aplikacji trzeba przedstawić im argumenty, dlaczego nie powinni się na
razie skupiać na wyglądzie.
Powiedz odbiorcy: "słuchaj, to jest wersja beta 1 systemu, który
zamawiałeś. Wiem, że wygląda topornie, ale nie skupiaj sie teraz na tym,
ani na pomysłach, że jakiś przycisk powinien być gdzie indziej. Skup się
proszę na rzeczach, które można za pomocą tego systemu wykonać i pomyśl,
czy to jest to czego chciałeś podając swoje wymagania."
Tu już ocieramy się o AgileDevelopment, więc doczytaj sobie o tym w
wikipedii.

Cały sens tego artykułu można zredagować tak: rdzeniem Twojej aplikacji
jest funkcjonalność. Ty jesteś specem, który nie pozwala sobie na
narzucenie sposobu myślenia klienta- dla jego własnego dobra. Klient nie
ma (bo po co miałby ją wypracowywać?) dyscypliny odpowiedniego patrzenia
na projekt. To Ty musisz mu ją narzucić. Jeśli stanie się na odwrót Ty
zaplączesz się w niuansach i komplikacjach, ktoś z Was dwóch za to
zapłaci, a oboje rozstaniecie się niezadowoleni.

Niedługo coś, bez czego duży projekt obyć się nie może - baza danych i
dlaczego nie może być "nienormalna".

*- nie twierdzę, że muszą mieć. Jest mnóstwo menadżerów, którzy są z
nimi z zawodu i nie znają technologii - wszystko jest ok, jeśli uważnie
słuchają pracowników liniowych.

Czego tak na prawdę ode mnie chcesz [kliencie] ?

W czym problem? Otóż gdy przychodzi do nas klient, to mówi, że chce
stronę, gdzie po lewej stronie będzie miał kategorie, a po kliknięciu
owych pojawią się linki do artykułów, a po klinknięciu na nie pojawi się
strona, której treść będzie mógł edytować. Do tego w tych kategoriach
chce mieć galerię, po kliknięciu na którą mają się rozwinąć galerie
"taka" i "siaka", po kliknięciu na którą ma się pojawić galeria ze
zdjęciami. Ma być możliwość dodania i usunięcia zdjęcia z galerii, ale
też, jak się okaże potrzebne - dodanie galerii "owakiej". Menu ma mieć
tło niebieskie, a strona z tekstem - filetowy. Linki po najechaniu mają
się robić różowe, a o góry ma być logo firmy.

Jeśli nie miałeś jeszcze do czynienia z klientem, to może Cię to
zdziwić, ale tak właśnie klienci definiują swoje wymagania co do strony
(nie wszyscy oczywiście, ale znaczny odsetek). Zadziwiające jest też,
jak wiele używają słów i jednocześnie jak słabo definiują swoje
wymagania. Na tym etapie najważniejsze dla Ciebie informacje to :
- edytowalne strony
- kategorie dla stron
- galerie
Niezła esencja ;) To czego nie wiesz to na przykład:
- jak bardzo klient chce móc ingerować w wygląd stron, czy chce
wprowadzać treści w html-u, może wystarczy mu uproszczenie w postaci
czegoś a'la BBCode, czy potrzebuje WYSIWYG?
- czy to logo firmy, chce móc zmienić od czasu do czasu?
- czy galerie mają mieć swój opis?
- czy zdjęcia w galerii mają mieć swój podpis?
- czy kategorie mają mieć jeden poziom, czy może wiele (pod-kategorie,
pod-pod-kategorie itd.)?

Zauważ proszę, że pytań jest więcej niż rzeczy, które już wiesz. Jeśli
dasz sobie narzucić formę epopei preferowaną przez klienta, będziesz
miał wiele prozy do przeczytania, a ilość wiedzy będzie rosła w trakcie
czytania co najwyżej logarytmicznie - strata czasu.

Ty, kontaktując się z klientem jesteś analitykiem, więc powiedz mu, że
na początku należy się skupić na funkcjonalności, a nie na tym, gdzie
jaki link ma być. Poinformuj go, że wiesz iż dla niego to jest bardzo
ważne, ale w tym momencie te informacje bardziej przeszkadzają niż
pomagają. Ty jako profesjonalista, który napisze aplikację zgodnie z MVC
możesz ZAWSZE zmienić wygląd aplikacji później.
Dobrym sposobem ograniczenia zapędów klienta jest nauczenie go pracy z
diagramem przypadków użycia
(http://en.wikipedia.org/wiki/Use_case_diagram). Nie jest to trudne- w 5
minut można wytłumaczyć jak z tego narzędzia korzystać. Jednocześnie
narzędzie to wyklucza definiowanie wyglądu, interakcji, czy wymagań
technicznych. Umożliwia jedynie zdefiniowanie FUNKCJONALNOŚCI. A o to
nam właśnie chodzi.

Podsumowując: to Ty, jako analityk jesteś profesjonalistą i musisz
zaopiekować się klientem, który robi to po raz pierwszy. Korzyścią jest
oszczędność czasu, lepsze zrozumienie się z klientem, danie klientowi
impulsu, aby dobrze skupił się i sprecyzował wymagania, a to daje w
efekcie jego i Twoje zadowolenie. Również oszczędza wasz czas (nie
chodzi mi tylko o wyświechtaną frazę, że czas to pieniądz). W przypadku,
gdy popełnimy błędy my nie będziemy wiedzieć co zrobić (albo będziemy
wiedzieć i będziemy się mylić), klient będzie niezadowolony z efektu bo
nie tego chciał (i na pewno nie powie, że to jego wina) ktoś te błędy
będzie musiał naprawić i ponieść koszty.

W następnej części: funkcjonalność kontra bajery... może trochę o
podejściu Agile.

Kontynuacją tych rozmyślań jest post: http://webbricks.blogspot.com/2008/04/funkcjonalność-czy-bajery.html