Yearly Archives: 2012

Business Model Canvas vs. Business Motivation Model

Jak widać, "klasyczny" model biznesowy pokazuje tylko "co jest przedmiotem działalności i kluczowym źródłem zysku". Model taki jest modelem procesu, ten proces jednak to tylko opis tego co, jaką wartość dodaną, dana organizacja dostarcza swoim klientom i gdzie się zaopatruje. Model to-Be opisuje stan pożądany, nie daje żadnej wiedzy o tym, jak do niego dojść. Model As-is i To-be ma lukę pomiędzy tymi As-Is i To-be. Tę lukę wypełnia moim zdaniem kompletny model BMM - każe "opracować" strategię, taktykę, analizę SWOT, ryzyka i inne mające wpływ na osiągnięcie celu, a nawet na to czy jest on w ogóle osiągalny. Po co to wszystko? Bo dobra analiza, powinna być sama dla siebie dowodem słuszności jej wyników (dlatego nie raz tu napisałem, że powinna być prowadzona "metodą naukową").

Continue ReadingBusiness Model Canvas vs. Business Motivation Model

Bo najważniejsi Panie są Aktorzy…

Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali... ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i "normalizacji". Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są 'tymi samymi rzeczami" ale w innych kontekstach, prowadzi do bardzo wielu problemów z implementacją. Ale po kolei.

Continue ReadingBo najważniejsi Panie są Aktorzy…
Read more about the article CQRS czyli kto, co i jak zamawia i dostarcza

CQRS czyli kto, co i jak zamawia i dostarcza

Opisując wymagania wyłącznie jako "czarną skrzynkę" nie wiem co dostanę. Większość developerów będzie dążyło do uproszczenia implementacji (ich koszt, nie raz brak wiedzy) by zaspokoić na minimalnym poziomie wymagania opisane przypadkami użycia. Nie raz klient słyszy "tu musimy to uprościć bo tak się nie da", a zamawiający, nie mając kompetencji by polemizować z taką opinią, zgadza się i dostarczony system staje się zgniłym kompromisem opartym właśnie na "czarnej skrzynce" jako specyfikacji zamówień: "dostaliśmy dokładnie to co zamówiliśmy ale zupełnie nie to czego naprawdę potrzebujemy". Tak więc, nie ma znaczenia fakt, że na pewno są na rynku developerzy znający problem, który opisałem i stosujący opisane tu rozwiązanie takich problemów. Jednak nawet cień ryzyka (a jest ono na prawdę duże), że dostaniemy bubla, daje zamawiającemu prawo do szczegółowego definiowania wymagań jako "białej skrzynki", bo dzięki temu zamawiający dostanie "to czego potrzebuje a nie tylko to co zamówił".

Continue ReadingCQRS czyli kto, co i jak zamawia i dostarcza