May 2011 – Page 2 – JZ IT Consulting Ltd

Urzędnikom i ustawodawcy zawdzięczamy utratę 100 mln euro

Post author:Jaroslaw Zelinski
Post published:23 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Koszt analizy i opracowania to ok. 20% wartości implementacji i mieści się nie raz nawet w kwocie nie wymagające przetargu (co istotnie skraca czas całości). Po drugie mając projekt, wycena implementacji nie jest już wróżeniem z fusów z narzutem 200-500% na wszelkie niewiadome (powszechna praktyka wielu firm developerskich, z bożej łaski integratorów). Zlecenie całości (analiza, projektowanie, wykonanie) jednej firmie nie raz kończy się tak: Wykonawca został wybrany w trybie zamówienia z wolnej ręki, ze względu na ochronę praw wyłącznych firmy Sygnity SA. Wykonawca został wybrany zgodnie z prawem polskim, natomiast zastrzeżenia Komisji wynikają z faktu, że w owym czasie polskie prawo nie było dostosowane do unijnego

Managing Requirements from a Business Analyst or an Enterprise Architect perspective using BABOK 2.0 and/or TOGAF 9

Post author:Jaroslaw Zelinski
Post published:23 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Autor artykułu porównuje obie te specyfikacje i pokazuje, że są praktycznie zgodne w 100%, nie licząc metody prezentacji i perspektywy. W obu przypadkach ma miejsce analiza, porównanie i specyfikacja celów biznesowych oraz przyporządkowanie ich do narzędzi (głównie ale nie tylko IT) wspierających realizację tego celu. Jeżeli uznać, że specyfikacja coś opisuje, to zależnie od fazy projektu jest specyfikacją potrzeb a potem specyfikacją tego co się posiada (jak uda się zakup ;)).

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

Post author:Jaroslaw Zelinski
Post published:21 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

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.

Postrzyżyny, czyli przyszedł Groupon do fryzjera

Post author:Jaroslaw Zelinski
Post published:20 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Co mogę poradzić małym i średnim firmom? To, że jak już raz ustalą cenę by jej nie zmieniały bez mocnego uzasadnienia. Promocja to nie prosta obniżka ceny a wymiana ustępstw pomiędzy dostawcą a kupującym. Jeżeli jest to wprowadzanie nowego produktu na rynek, to obniżka ceny jest rekompensatą za ryzyko kupowania czegoś nowego czego się nie zna. Często można usłyszeć o promocji na np. jogurty, sprzedawane są po obniżonej cenie produkty, którym kończy się termin przydatności do spożycia ale to nazwał bym raczej wyprzedażą. W obu jednak przypadkach obniżona cena ma uzasadnienie i powrót do poprzedniej wyżej ceny jest możliwy bez psucia sobie wizerunku. Klient, który coś kupi taniej a później znowu widzi wyższą (np. poprzednią cenę) czuje się oszukany.

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

Post author:Jaroslaw Zelinski
Post published:19 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

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...