Temat: Metodyka wytworzenia produkty analizy biznedsowej

Jarek Żeliński:
policz: jeden analityk liczony 18 tys.m-c i zespół pięciu programistów każdy 10 tys m-c. kolejne miesiące liczone narastająco, jak pracuje analityk to nie pracują programiści, jak zaczynają programiści już nie pracuje analityk...wszytko się zgadza

Chyba się nie dogadamy :) 3 miesiące pracy analityka (3x18000) to 54000, 3 miesiące pracy 5 programistów (3x50000) to 150000. Teraz analityk + programiści (54000+150000) to 204000. Czy coś źle liczę? :)

Temat: Metodyka wytworzenia produkty analizy biznedsowej

sprawdzę arkusz... możliwe, że coś jest nie tak, ale generalnie chodzi o to, że pięciu programistów w miesiącu to dużo większy wydatek niże jeden analityk projektant...

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Jarek Żeliński:
sprawdzę arkusz... możliwe, że coś jest nie tak, ale generalnie chodzi o to, że pięciu programistów w miesiącu to dużo większy wydatek niże jeden analityk projektant...

To akurat się zgadza, szczególnie w dużych projektach, gdzie programistów jest kilkunastu :)

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Aleksander Olszewski:

Jarek Żeliński:
sprawdzę arkusz... możliwe, że coś jest nie tak, ale generalnie chodzi o to, że pięciu programistów w miesiącu to dużo większy wydatek niże jeden analityk projektant...

To akurat się zgadza, szczególnie w dużych projektach, gdzie programistów jest kilkunastu :)

rzecz w tym, że wiele firm praktykuje "pospolite ruszenie" na problem całym tym zespołem od samego początku tłumacząc swoim klientom, że "analityk i projektant jest zbędnym kosztem"...

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Jarek Żeliński:

Aleksander Olszewski:

Jarek Żeliński:
sprawdzę arkusz... możliwe, że coś jest nie tak, ale generalnie chodzi o to, że pięciu programistów w miesiącu to dużo większy wydatek niże jeden analityk projektant...

To akurat się zgadza, szczególnie w dużych projektach, gdzie programistów jest kilkunastu :)

rzecz w tym, że wiele firm praktykuje "pospolite ruszenie" na problem całym tym zespołem od samego początku tłumacząc swoim klientom, że "analityk i projektant jest zbędnym kosztem"...

Ja osobiście wolę, gdy najpierw pracuje analityk, może z powodu sentymentu do RUP :) Ale żeby być obiektywnym, włączenie np. w Scrumie analityka jest problematyczne: powinien być wcielony do zespołu. Współdzielenie analityka w Scrumie między zespołami doprowadzi do niezdrowej rywalizacji o jego czas i w konsekwencji do zawalenie Sprintu. Natomiast opieranie się w Scrumie o wyniki analiz mocno koliduje z ideą eksperckiej wiedzy zespołu i zminimalizowania dokumentacji projektowej. To taka moja degresja :)

Pospolite ruszenie obserwuję rzeczywiście często. Trzeba wtedy uważać aby burza mózgów nie przerodziła się w sztorm. Natomiast decyzje wtedy często mają charakter polityczny a nie ekspercki :)

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Jarek Żeliński:
...
- faza 0: nazwać cel biznesowy (jeden a nie zlepek życzeń),
- faza 1: doprowadzić do dokładnego zrozumienia i udokumentowania modelu biznesowego (rola firmy na rynku) oraz logiki biznesowej (jak tę rolę realizuje), zamawiającego oprogramowanie. (w MDA jest to model CIM)
- faza 2: zdefiniować zakres projektu i opracować model logiki jaka ma zostać zaimplementowana w projekcie (w MDA jest model PIM, wykonany metodami DDD staje się analizą systemową),
- faza 3: implementacja

jak widać:
- na każdym kroku możliwa jest analiza wykonywalności i przerwanie projektu czyli można zawczasu zarobić pieniądze nie wyrzucając ich w błoto
- RUP na mój rozum startuje w fazie 2.
- analiza i projektowanie to fazy od 0 do 2
- implementacja to faza 3 (nie taka trywialna jeżeli wziąć pod uwagę, że tu projektowane są realizowane wymagania pozafunkcjonale),

Ja znam tą wersję RUP, jeszcze z czasów Rational: http://itcrewblog.pl/2011/12/19/symbioza-rup-i-prince2... W tym układzie, co też już podkreślałem np. tu: http://itcrewblog.pl/2011/08/12/rup-cookbook-cz-1/ w RUP rzeczywiście faza 0 występuje w sposób kompletnie nieformalny, innymi słowy to biznes przychodzi do informatyki ze swoim pomysłem, a informatyka odpala 1 fazę RUP i opracowuje dokument wizji, przegląd przypadków użycia, słownik pojęć, dokument wizji biznesowej, oszacowanie ryzyka oraz model dziedziny biznesu i/lub specyfikacja procesów biznesowych. Oczywiście na poziomie wystarczająco ogólnym. Szczegóły są opracowywane w fazie 2.

Dlatego mnie zdziwiło to odkrycie IBM o poświęcenie większej uwagi na analizy. Rational poświęcał na analizy 40% czasu projektu + jakiś procent przed odpaleniem RUP.

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Jeszcze jedna kwestia bardzo mnie interesuje: czy po przeprowadzeniu analizy oraz zbudowaniu modelu systemu przeprowadzasz również estymację kosztów projektu, czy ta działka przypada już dostawcy?

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Aleksander Olszewski:
Natomiast opieranie się w Scrumie o wyniki analiz mocno koliduje z ideą eksperckiej wiedzy zespołu i zminimalizowania dokumentacji projektowej. To taka moja degresja :)

i tu widzę problem, bo to tak jak by "inżynier murarz" powiedział, że "opieranie się na projekcie architektonicznym zamawiającego koliduje z ideą eksperckiej wiedzy zespołu developerskiego"... zapytam: kurcze jakiej wiedzy?????? Teraz rozumiem, dlaczego znajomy PM nazywa SCRUM: "zespół nadmiaru testosteronu w zespole"...

Co do minimalizowania dokumentacji projektowej wyraziłem swoje zdanie nie raz.... to strzał w swoje kolano i w głowę klienta..

Zacytuję znajoma firmę z dużym doświadczeniem, opis pewnego projektu "po kimś":


Analiza problemów

Zawiodła przede wszystkim kontrola jakości a zawiodła ponieważ w warunkach, w których były prowadzone te projekty [przejęte, mój przyp.] nie miała szansy się powieść jak się okazało w trakcie realizacji tych projektów. W szczególności:

Deklaracje programistów o realizacji zadania często okazywały się nieprawdziwe. Kontrola i odbiór polegające na prezentacji przez programistę zrealizowanej funkcjonalności oraz na przeglądzie kodu źródłowego okazały się nieskuteczne i niewystarczające. Późniejsze testy przez klienta i QA wykazywały wiele braków w realizacji. Nie wynikało to ze złej woli czy braku zaangażowania osób, ale z warunków, w jakich prowadzony był projekt.

Braki w dokumentacji i braki doświadczenia przez QA w obsłudze systemu znacząco obniżały skuteczność wykrywania błędów w implementacji przez QA. Pojawienie się w końcowej fazie projektu scenariuszy testowych powodowało zmiany w interpretacji zapisów z analizy wymagań.

Brak wsparcia ze strony osób tworzących system oraz niepełnej dokumentacji wpływał na poziom zrozumienia i właściwej interpretacji zapisów z analizy a przez to obniżał skuteczność programistów.


całość tu
http://www.infovidematrix.pl/inspiracje/?p=2077Jarek Żeliński edytował(a) ten post dnia 19.12.11 o godzinie 14:45

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Jarek Żeliński:
...

Staram się nie faworyzować żadnej metodyki. Pracowałem w Scrum i moje prywatne przekonanie jest takie: świetnie sprawdzająca się metodyka w wewnętrznych projektach jakieś firmy, której nie zależy na bardzo sprecyzowanym wyniku, która chce odkryć jakąś niezajętą jeszcze niszę.

Co powiesz na praktyki Microsoftu (ale bez uprzedzeń, bo i ja nie lubię tej firmy), który organizował konkurujące ze sobą wewnętrzne zespoły projektowe, które miały wytworzyć nowy i bardzo innowacyjny produkt?

Jeśli chodzi o moje osobiste przekonanie, to gdybym miał możliwość wyboru metodyki, wybrał bym RUP, czyli poświęciłbym 40% czasu projektu na rozpoznanie biznesu oraz na modelowanie systemu w UML.

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Aleksander Olszewski:
Staram się nie faworyzować żadnej metodyki. Pracowałem w Scrum i moje prywatne przekonanie jest takie: świetnie sprawdzająca się metodyka w wewnętrznych projektach jakieś firmy, której nie zależy na bardzo sprecyzowanym wyniku, która chce odkryć jakąś niezajętą jeszcze niszę.

z tym mogę się zgodzić...

Co powiesz na praktyki Microsoftu (ale bez uprzedzeń, bo i ja nie lubię tej firmy), który organizował konkurujące ze sobą wewnętrzne zespoły projektowe, które miały wytworzyć nowy i bardzo innowacyjny produkt?

nie mieszajmy prac typu R&D (pomysł wcale nie jest taki głupi) w projekty komercyjne mające zakres, termin i budżet... co do Microsoftu: jak każda korporacja jest "mafią" nastawioną na zysk (nie widzę żadnej równicy pomiędzy MS, Oracle, IBM, CISCO i resztą...)

za to ma bardzo dobrze opracowaną metodykę prowadzenia projektów zarówno dla wdrożeń ERP Dynamix AX (SureStep, nie stosuje jej chyba żadna polska firma bo trzeba modelować i projektować a to wielu nie wsmak... za to wiele firm zachodnich robi to perfekcyjnie). Co do zaś projektów dedykowanych to VisualStudio oraz metody oparte na modelowaniu są bardzo dobrze opisane na MSDN, tu znowu "nie stosuje jej chyba żadna polska firma bo trzeba modelować i projektować a to wielu nie wsmak"

w tym sensie o Microsofcie mam jak najbardziej dobre zdanie, materiały na MSDN są wysokiej jakości,...

Jeśli chodzi o moje osobiste przekonanie, to gdybym miał możliwość wyboru metodyki, wybrał bym RUP, czyli poświęciłbym 40% czasu projektu na rozpoznanie biznesu oraz na modelowanie systemu w UML.

w kwestii tego czy preferuję jakąś metodykę, to odpowiem "wymagam planowania na każdym etapie projektu, a analiza i projektowanie to nic innego jak planowanie swojej pracy". Strasznie trudno mnie przekonać, że "weźmiemy się i coś fajnego razem zrobimy" to jakakolwiek metodyka... zbyt często słyszę w kuluarach od programistów "jak klient głupi to płaci za naszą naukę..." szkoda, że ich oferty wyglądają zupełnie inaczej ...

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Dyskusja Panów dotknęła kilku interesujących wątków. Chciałabym jeszcze wrócić do opisu metody na stronie :)

Jarek Żeliński:
Metody polegające na zbieraniu życzeń przyszłych użytkowników z pomocą ankiet,
sesji warsztatowych, pisania tak zwanych user story, to metody nie poddające się żadnej
weryfikacji ani ocenie kompletności.
Jarek Żeliński:
Analizy i projekty, które realizuję, dają w efekcie dokumentację praktycznie pozbawioną braków

Ciekawi mnie jakie metody stosuje Pan do zapewniania spójności i kompletności? :)

Jarek Żeliński:
Produktem takich analiz jest dokumentacja zawierająca (zależnie od zakresu projektu):
1. sformalizowany opis modelu biznesowego firmy (organizacji),

W jaki sposób sformalizowany?

zoptymalizowane i sformalizowane modele procesów biznesowych,

Jakie metody wykorzystuje Pan do optymalizacji procesów biznesowych? W opisie znajduje się kilka problemów (przerośnięte kompetencje, nieprzydzielone odpowiedzialności, itp.). Czy korzysta Pan z listy aspektów, na jakie należy zwrócić uwagę?

Moje dotychczasowe doświadczenie podsuwa mi perspektywę firmy - wykonawcy. Muszę przyznać, że na takim materiale, jakiego proces powstawania Pan opisuje, pracowałoby się z przyjemnością. Dawałby duże zrozumienie potrzeb Zamawiającego, znacznie zmniejszał ryzyko niedostarczenia odpowiedniego produktu. Także, co uważam za bardzo ważne - taki wkład porządkowałby pracę firmy wykonującej zlecenie, nawet jeśli ona sama byłaby niezbyt dojrzała procesowo.

Zdaje się, że wiele osób nie dostrzega zalet pracy analityka. Z jednej strony wiedza o jej korzyściach jest powszechna, z drugiej, w praktyce często deklaracje "tak, to ważne i potrzebne" nie mają odzwierciedlenia i w projektach okazuje się, że szkoda na to czasu. Ciekawi mnie jak wygląda sytuacja wśród Pana klientów? Wydaje mi się, że Ci, którzy potrzebują wsparcia w tej kwestii, często mogą jej sobie nie uświadamiać. Muszą więc zgłaszać się do Pana osoby świadome potrzeby rzetelnej analizy? Czy powodują to raczej pewne wymagania czy zobowiązania (wspominał Pan o zaleceniach dostawców ERP)? A może Pan sam potrafi dotrzeć do klientów, którzy są w takiej potrzebie? :)

Zastanawiam się także co myślą Panowie o projektowaniu - tworzeniu makiet (prototypów) jako stałym elemencie procesu prowadzenia projektu (i odkrywania wymagań) oraz jak widzą jego związek (kolej, zależność) z analizą i jej produktem (produktami?) w postaci dokumentu analizy wymagań?Hanna Wesołowska edytował(a) ten post dnia 20.12.11 o godzinie 00:36

Temat: Metodyka wytworzenia produkty analizy biznedsowej

Hanna Wesołowska:

Analizy i projekty, które realizuję, dają w efekcie dokumentację praktycznie pozbawioną braków

Ciekawi mnie jakie metody stosuje Pan do zapewniania spójności i kompletności? :)

w zasadzie standard IIBA/OMG to jest: nie opisy a sformalizowane zestawienia. Stosowanie dobrze opisanych pojęciowo notacji (przestrzeni pojęciowych) pozwala "oczyścić" dokument z wszelkich niejednoznaczności - największego wroga dokumentu wymagań. Spójność i kompletność osiąga się stosując modele i ich testowanie. Innymi słowy:mając dobry model np. procesu biznesowego (wykonany poprawnie formalnie) możliwe jest wyeliminowanie problemy późniejszego "odkrywania wymagań". Ich spójność osiąga się przy okazji.

Jarek Żeliński:
Produktem takich analiz jest dokumentacja zawierająca (zależnie od zakresu projektu):
1. sformalizowany opis modelu biznesowego firmy (organizacji),

W jaki sposób sformalizowany?

poprzez stosowanie sformalizowanych notacji, sformalizowanych słowników pojęć, sformalizowanej specyfikacji reguł biznesowych.

zoptymalizowane i sformalizowane modele procesów biznesowych,

Jakie metody wykorzystuje Pan do optymalizacji procesów biznesowych? W opisie znajduje się kilka problemów (przerośnięte kompetencje, nieprzydzielone odpowiedzialności, itp.). Czy korzysta Pan z listy aspektów, na jakie należy zwrócić uwagę?

W zasadzie zawsze jest to indywidualna sprawa, nie ma podobnych firm, co do listy aspektów to należy stworzyć sobie model pojęciowy (przestrzeń nazw) pokrywający w 100% owe kompetencje, odpowiedzialności itp.

Moje dotychczasowe doświadczenie podsuwa mi perspektywę firmy - wykonawcy. Muszę przyznać, że na takim materiale, jakiego proces powstawania Pan opisuje, pracowałoby się z przyjemnością. Dawałby duże zrozumienie potrzeb Zamawiającego, znacznie zmniejszał ryzyko niedostarczenia odpowiedniego produktu. Także, co uważam za bardzo ważne - taki wkład porządkowałby pracę firmy wykonującej zlecenie, nawet jeśli ona sama byłaby niezbyt dojrzała procesowo.

pozostaje mi potwierdzić, zwracam jednak uwagę, że są także wykonawcy dla których taka specyfikacja jest kością w gardle bo w zasadzie nie da się w sposób niezauważony manipulować zakresem projektu w trakcie realizacji. Po drugie na bazie takiej dokumentacji możliwe jest zawarcie umowy fixed-price (taki jest jej główny cel) co także boli wielu dostawców ... nie zmienia to faktu, że są dostawcy, którzy zlecają mi analizy bo trzymanie analityka dla dwóch trzech projektów w roku jest nieopłacalne, przy okazji zyskują mediatora w projekcie.

Zdaje się, że wiele osób nie dostrzega zalet pracy analityka. Z jednej strony wiedza o jej korzyściach jest powszechna, z drugiej, w praktyce często deklaracje "tak, to ważne i potrzebne" nie mają odzwierciedlenia i w projektach okazuje się, że szkoda na to czasu.

niestety jak wyżej wspomniałem zbyt dobra dokumentacja przeszkadza wielu firmom, szczególnie tym lubiącym umowy typu czas i materiał.

Ciekawi mnie jak wygląda sytuacja wśród Pana klientów? Wydaje mi się, że Ci, którzy potrzebują wsparcia w tej kwestii, często mogą jej sobie nie uświadamiać. Muszą więc zgłaszać się do Pana osoby świadome potrzeby rzetelnej analizy?

Tak, praktycznie w 100% są to firmy po przejściach z umowami na czas i materiał: mają porównanie obietnic z tym co dostali... pozostałe - rzadkie dla mnie przypadki - to OPZty to przetargów

Czy powodują to raczej pewne wymagania czy zobowiązania (wspominał Pan o zaleceniach dostawców ERP)? A może Pan sam potrafi dotrzeć do klientów, którzy są w takiej potrzebie? :)

Zalecenia dostawców ERP są raczej ignorowane przez dostawców IT a klienci raczej nie mają o nich pojęcia... to bardzo nierówne kontrakty: dostawca ERP kontra kupujący, ten drugi bez wsparcia merytorycznego w zasadzie jest bez szans, przepychanki prawnicze w negocjacjach niczego nie wnoszę do tych umów.. jak się nie rozumie tego co się kupuje...

Zastanawiam się także co myślą Panowie o projektowaniu - tworzeniu makiet (prototypów) jako stałym elemencie procesu prowadzenia projektu (i odkrywania wymagań) oraz jak widzą jego związek (kolej, zależność) z analizą i jej produktem (produktami?) w postaci dokumentu analizy wymagań?

Jeżeli mowa o makietach ekranów (mockup) to dla systemów dedykowanych jak najbardziej są potrzebne :)Jarek Żeliński edytował(a) ten post dnia 20.12.11 o godzinie 07:53