Budżet na projekt IT

Tak więc moim zdaniem budżet zamawiającego to wiedza zamawiającego, której nie musi ujawniać. Skoro już jej nie ujawnia to powinien mieć kompetencje (własne lub wynajęte) pozwalające po pierwsze opisać projekt, po drugie zdefiniować (opisać) “to coś informatycznego” co pomorze mu ten projekt zrealizować.

Wyjawienie przez klienta planów i budżetu takiemu dostawcy to postawienie się pod ścianę w negocjacjach z nim. Dlatego nie ma sensu sytuacja gdy dostawca pyta klienta o jego budżet czy oferowanie mu czegokolwiek. I nie ma tu znaczenia uczciwość tego dostawcy bo z perspektywy klienta sprzedawca na prowizji stanowi duże ryzyko dla rzetelności takiej oferty.

I na koniec: napisanie tylko: “system ma wystawiać faktury VAT” jako opis tego co chcemy kupić nie ma żadnego sensu bo to stanowczo za mało by cokolwiek wycenić i ocenić…. ale też napisanie, że “kontrahenta można dodać do faktury z rozwijanej listy uruchamianej prawym klawiszem myszy”, jest jeszcze większym błędem, bo po pierwsze nie raz narzuca wspomnianą kastomizacje (a to podnosi koszt), a po drugie bywają lepsze sposoby rozwiązania tego problemu. Dla gotowego systemu nie ma sensu pisanie aż takich szczegółów, a dla dedykowanego robi się to zupełnie inaczej.

Czytaj dalej Budżet na projekt IT

Open Source – plusy, minusy, mity

Ja produkty open source porównał bym do produktów dużych międzynarodowych korporacji, całkowity koszt dla ostatecznego ich użytkownika zawsze będzie sumą kosztów utrzymania twórców oprogramowania oraz tych, który je wdrożyli i potem wspierają to wdrożenie. Podział i jawność poszczególnych pozycji tych kosztów to w moich oczach tylko marketingowe zabiegi. Jedno jest pewne, produkty “słabo” finansowane kończą albo jako “zaprzestano rozwoju” albo, jeśli są na prawdę dobre, są przejmowane i komercjalizowane. Czasem ma miejsce coś co ja nazywam “autokomercjalizacją” czyli społeczność twórców po prostu przekształca się w podmiot rynkowy oferujący swój produkt.

Czytaj dalej Open Source – plusy, minusy, mity

IBM CIO Study: 60% w chmurze za 5 lat

system ERP czy CRM, traci sens jako monolityczny pakiet a stanowi sobą pakiet usług z jakiego korzysta dane organizacja. drugorzędne znaczenie ma to czy użytkownik jest ich właścicielem, dzierżawca czy chwilowym użytkownikiem. Analiza Biznesowa tu polega na analizie i stworzeniu modelu organizacji, wskazaniu gdzie jakich usług wspierających działania się w niej oczekuje, wyszukaniu dostawców usług lub ich stworzeniu, integracji.

Osobiście uważam, że kończą się czasy gdy sprzedawcy “atakują” rynek, wybierają sobie klientów i sprzedają im oprogramowanie. Zaczyna się era gdy to klient wybiera usługę i jej dostawcę. Sprzedaż oprogramowania będzie wyglądała podobnie jak sprzedaż w pasażu butików: dostawcy usług wystawią swoje usługi, a klient (projektant systemu) będzie się przechadzał i wybierał najlepiej mu pasujące. Podobnie jak teraz: budując dom, remontując mieszkanie zapraszamy projektanta wnętrz, ten znając oferty marketów budowlanych dobierze najlepsze wyposażenie, materiały i kolorystykę i kupi. Nadchodzi powoli koniec ery napastliwych sprzedawców i ich firm, koniec dyktatury developerów. Nadchodzi, powoli, era rynku usług.

Czytaj dalej IBM CIO Study: 60% w chmurze za 5 lat

Kilka słów o kosztach analizy przedwdrożeniowej i prawie autorskim

Tak więc na zakończenie zwrócę uwagę: analiza wymagań i projekt oprogramowania jest złożona, niezależnie od tego ilu użytkowników go będzie używało. Jednak koszt wdrożenia oprogramowania w firmie 10 osobowej będzie nieporównywalnie mniejszy niż w korporacji zatrudniającej 1000 osób. Tu jednak problemy leżą już gdzie indziej.

Ale ktoś powie: duży ERP wymaga przewidzenia wielu ról w systemie i w związku z tym obsługi wielu etapów jakie pokonują tam dokumenty. Owszem, dlatego uważam, że należy osobno wybrać system, który wchłonie te dokumenty (np. finanse itp.) i osobno system, które je tam doprowadzi czyli “jakiś workflow”. To dużo bezpieczniejsze i mniej ryzykowne. (na diagramie poniżej (dan z IBM) wdrożenie to etap instalacji i oddania do użytku.

Dlatego dobrą praktyką jest raczej oddzielenie projektowania od wykonania. Zlecenie analizy i opracowania rozwiązania i przejęcie praw majątkowych do opracowania (projektu systemu) i na tej podstawie dopiero wskazanie wykonawcy daje gwarancje, że dostawca oprogramowania nie nabędzie żadnych praw do Państwa pomysłu. Daje gwarancję, że Wasz unikalny pomysł nie stanie się “modelem referencyjnym dla branży…” lub co gorsza “gotowym produktem z pudełka”…

Czytaj dalej Kilka słów o kosztach analizy przedwdrożeniowej i prawie autorskim

Polemika

Na zakończenie dodam coś do manifestu: ludzie, szanujmy na wzajem swoje kompetencje bo bez tego nie da się współpracować. Po drugie, nie tylko w kontekście owych modeli, których kolega nie doświadczył: to że ktoś nigdy nie widział czarnego łabędzie nie stanowi żadnego dowodu na jego nieistnienie. Dodam od siebie: to że ktoś czegoś nie potrafi nie znaczy, ze to nie możliwe. By nie budzić zbędnych emocji: obecnie nie potrafię już dobrze programować (co by to nie miało znaczyć) ale w swym rozsądku nie neguję istnienia oprogramowania.

Czytaj dalej Polemika

Czy wymagania opisują tylko to “co” system ma robić?

Bardzo często tak właśnie definiuje się produkt analizy wymagań: wymagania funkcjonalne opisują to co ma system robić. W dyskusjach (ile mam ich za sobą :)) z programistami przebija się teza, że analityk specyfikuje to “co” system ma robić, a oni już załatwia sprawę tego “jak” ma to robić. W czym problem? W tym, że funkcjonalności to test rozwiązania a nie wymagania! […] Przypadki użycia stanowią bardzo mierne przybliżenie rzeczywistości. […] Tak więc dokument wymagań to nie tylko przypadki użycia. Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). […] Programiści, proszę, nie udawajcie, że znacie się na zarządzaniu, marketingu, biznesie, sprzedaży, rynku, produkcji itp. bo to (poza pewnie istniejącymi wyjątkami) nie prawda, a projektowanie na zasadzie “wydaje mi się że rozumiem” to droga do porażki. […] System ERP można wybrać na bazie projektu na wyższym poziomie abstrakcji. Analizy firmy także polega tu na opracowaniu modeli procesów. Jednak w tym wypadku ich celem jest stworzenie raczej “modelu filozofii działania” firmy a nie projektowanie systemu od zera.

Czytaj dalej Czy wymagania opisują tylko to “co” system ma robić?

Czego moglibyśmy się nauczyć od naukowców?

I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu…

Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała jak trzeba! Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta…

Czytaj dalej Czego moglibyśmy się nauczyć od naukowców?

A na grzyba nam Pan Analityk?

Przecież analizę zrobimy sami, a jak nie – to zrobi to dostawca. Tak często rozpoczyna się tak zwana “Droga do klęski”. Rzemieślnicy produkujący ?przed Kopernikiem? skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem modelu geocentrycznego i swoich skomplikowanych przyrządów. Dlatego zapewne nie raz jeszcze usłyszę, że dobra analiza to setki stron, tysiące wymagań, miesiące pracy.

Jednak dobra analiza to tylko: dziesiątki stron i wymagań, tygodnie pracy ale nie dyktafon a zaawansowane metody, takie jak formalna analiza systemowa oparta na modelach i ich testowaniu.

Czytaj dalej A na grzyba nam Pan Analityk?