Odkrycie miesiąca

Jakiś czas temu spędziłem dwa dni na poszukiwaniach narzędzia, w którym mógłbym projektować system przy pomocy UMLa i wygenerowac kod w PHP. Niestety bezowocnie. Kiedy wczoraj przez przypadek trafiłem na BOUML.
Byłem pogodzony z tym, że takie narzędzie nie istnieje, dlatego tym większe było moje zaskoczenie, że nie dość, że potrafi on generować kod PHP (i nie tylko o jesze C++, Python, Java) to potrafi zrobić reverse engineering istniejącego kodu. Z przyjemnością wrzuciłem do niego źródła CakePHP i stworzyłem diagram klas wrzucając istniejące w tym frameworku klasy :)
Już widzę jak przyjemnie będzie wplatać aplikacje we framework już w trakcie projektowania.

Share Button

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

Share Button