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 ;)

Share Button

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.

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