Prototyp nie jest niczym ponad to, że jest tylko obrazkiem lub makietą

(developer nie jest w stanie stworzyć żadnego rozwiązania tylko na bazie obrazków).

Trudno z tym artykułem polemizować, a jednak rzesze analityków, i o dziwo developerów, chyba większości firm IT, jako produkty analiz wymagań przedstawiają tylko owe prototypy czyli “user story”, mock-up’y ekranów, tabele itp. W środku jest jakaś określona logika i to ona jest kluczowym wymaganiem.

Czytaj dalej Prototyp nie jest niczym ponad to, że jest tylko obrazkiem lub makietą

Krótka lista pięciu rzeczy, które nie są regułami biznesowymi

Od samego początku analizy i projektowania logiki systemu należy skupić się na tym “co i po co” a nie “jak”. Zajmowanie się pytaniami “jak” (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości, nadmiarowych, szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy – mając szkielet całego projektu – wiemy które mają jakiekolwiek znaczenie.

Czytaj dalej Krótka lista pięciu rzeczy, które nie są regułami biznesowymi

Produkty w procesie analizy wymagań

Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.

Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.

Czytaj dalej Produkty w procesie analizy wymagań

Najczęściej popełniane błędy podczas wdrożenia ERP

Przy piątku naszło mnie na zestawienie pewnych treści (cytaty). Podczas codziennej "prasówki" wpadłem na artykuł "Najczęściej popełniane błędy podczas wdrożenia ERP", oto cytat pierwszy: - Największym błędem popełnianym przy wdrożeniach…

Czytaj dalej Najczęściej popełniane błędy podczas wdrożenia ERP

Wszystkie drogi prowadzą do Rzymu – zarządzanie jakością

… spotykam się jednak w literaturze z tezami, że wdrożenie jakichkolwiek norm, nie tylko jakości, powinno być także poprzedzone analizą. Innymi słowy normy jakości powinny być wdrażane jako odpowiedź (rozwiązanie) na określone wymagania, a nie dla samego faktu ich wdrażania. Owszem, bywa, że wymaganiem jest np. wymóg przetargowy (oferty mogą składać tylko firmy mające określony certyfikat), jednak moda na jakość, mimo że nie przeminęła całkowicie, powoli przechodzi w racjonalne powody wdrażania norm jakości.

Czytaj dalej Wszystkie drogi prowadzą do Rzymu – zarządzanie jakością

Analiza procesowa a obiektowa czyli niedopasowanie oporu

Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.

Czytaj dalej Analiza procesowa a obiektowa czyli niedopasowanie oporu

Niski poziom analizy…

Niestety źle dobrany system informatyczny, mający wspierać/automatyzować czynności w procesie, może być powodem powstania całych podręczników procedur nieuzasadnionych biznesowo, dedykowanych użytkownikom tego systemu, stwarzając przy tym pozory, że to sam proces jest ich źródłem 🙁

Niestety tak się często kończą projekty, w których pomięto analizę i projektowanie i od razu wybrano dostawcę i produkt (analiza wykonana przez dostawce to raczej “jak wdrożyć to co mamy” a nie “jak rozwiązać problem użytkownika”).

Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej własnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji gdy sam sobie stawia wymagania a potem rozlicza ich realizację.

Czytaj dalej Niski poziom analizy…

Jarosław Żeliński – C.V.

Jarosław Żeliński, biuro w Warszawie, Al. Jana Pawła II 27. Mój stosunek do życia: "Dziadek rozmawia z wnukiem i mówi mu, że w każdym z nas żyją dwa wilki, które…

Czytaj dalej Jarosław Żeliński – C.V.