GoldenLine
Zaloguj się
Arkadiusz Cempura

Arkadiusz Cempura Najlepszą metodą
przewidywania
przyszłości jest jej
tworz...

Ostatnio przeczytałem w pewnym opiniotwórczym tygodniku dla managerów IT , iż:
"Opóżnienia projektów IT są tak powszechne, że nieomal stały się rutyną. Nikt zapewnień, że wszystko można zrobić na czas, nie traktuje poważnie. Standardem stało się precyzyjne zaplanowanie projektu i późniejsze pomnożenie tego przez mityczne "x2"

Tylko co, jak w trakcie planowania (precyzjnego) ktoś już użył parametru "x2"?

Edytowane w celu poprawy literówek ;)Arkadiusz Cempura edytował(a) ten post dnia 31.03.09 o godzinie 13:44
Link do wypowiedziLink
Przemek Sobieszczuk

Przemek Sobieszczuk Dyrektor Sprzedaży /
Pełnomocnik Zarządu
w OPITZ Consulti...

Arkadiusz Cempura:
Ostatnio przeczytałem w pewnym opiniotwórczym tygodników dla managerów IT , iż:
"Opóżnienie projektów IT są tak powszechne, że nieomal stały się rutyną. Nikt zapewnień, że wszystko można zrobić na czas, nie traktuje poważnie. Standardem stało się precyzyjne zaplanowanie projektu i późniejsze pomnożenie tego przez mityczne "x2"

Tylko co, jak w trakcie planowania (precyzjnego) ktoś już użył parametru "x2"?

Ja z kolei dowiedzialem sie ostatnio, ze szacujac koszty projektu IT, przy pierwszym szacowaniu popelnia sie blad nawet do +/- 400%. Tak wiec x2 moze:
- dzialac w obie strony
- i moze faktycznie byc jeszcze x2.

Wniosek jest taki, ze zanim sie wybierze dostawce/ integratora IT,to trzeba przeczesac nieco rynek i zorientowac sie w ofertach (sa czasem zaskakujaco spore rozbieznosci). Zdrowy rozsadek nakazuje, aby wybierac tych ze srodka stawki.

PS
Link do wypowiedziLink
Marcin Mikucki

Marcin Mikucki Urząd Komisji
Nadzoru Finansowego

Wniosek jest taki, ze zanim sie wybierze dostawce/ integratora IT,to trzeba przeczesac nieco rynek i zorientowac sie w ofertach (sa czasem zaskakujaco spore rozbieznosci). Zdrowy rozsadek nakazuje, aby wybierac tych ze srodka stawki.

PS

Z takim wyciąganiem wniosków byłbym ostrożny. Rzadko zdarza się aby oferty były łatwe do porównania.

Druga sprawa - klienci jak ognia (niestety) unikają analiz przed wdrożeniowych przez co dopiero w trakcie realizacji projektu wychodzą nowe, nieplanowane wcześniej (a wielce pożądane) funkcjonalności
Link do wypowiedziLink
Rafał S.

Rafał S. Czasami I. Czasami
T.

Witam,
Ja wyznaję zasadę usłyszaną od pewnej mądrej Pani zarzązającej projektami od 20 lat :)
Mówi ona:
1. Jeśli realizujesz projekt pierwszy raz i nie miałeś styczności z technologiami Uzywanymi w tym projekcie i nie wiesz ile to może dokładnie trwać pomnóż wyliczony czas(podany przez firmy zewnetrzne, pracowników) razy PI :)
2. Jeśli robisz projekt zbliżony do projektów, które już kiedyś wykonywałeś pomnóż czasy razy Pierwiastek z PI
3. Jeśli masz już wypracowany szablon i orientujesz się w podobnych projektach możesz pokusić się o brak mnożenia.
4. Jeśli jesteś specjalistą, pracujesz z zespołem który ma wykonać projekt od wielu lat znasz realia w tego typu projektach podziel czasy przez Pierwiastek z Pi i do dzieła.
5. Do tego punktu chyba nikt nie dotrze... Podziel przez PI :)

PS. Ja powoli wchodzę w rejon punktu 2giego ;) A zasada sprawdza się świetnie.
Link do wypowiedziLink
Michał Sajdak

Michał Sajdak Securitum.

Jak ktoś ma kilka złotych (a raczej USD) do wydania to gorąco w temacie polecam książkę:

Software Estimation: Demystifying the Black Art.

http://www.amazon.com/Software-Estimation-Demystifying...

Na amazonie dostępny jest spis treści, który +- pozwala się zorientować o czym jest książka :)

Słusznie też ktoś zauważył, że jeśli nie ma +- sensownej analizy tematu, to można sobie szacować...

Dodatkowo b. dużą rolę gra też Project Management - który nie pozwala ponad miarę napompować funkcjonalności przez zamawiającego soft/projekt.
Co ciekawe można sobie spokojnie wyobrazić projekt prowadzony przez 2 różnych PM-ow. I jeden będzie miał czas przekroczony np. o 300%, a drugi będzie on time :)

--
http://securitum.pl
Link do wypowiedziLink

konto usunięte

ile to może dokładnie trwać pomnóż wyliczony czas(podany przez firmy zewnetrzne, pracowników) razy PI :)

To praktyczna zasada która sprawdza się w rzeczywistości, dobra do korelowania z wartościami z metody PERT.

Metoda x2 to tak naprawdę pogłoska z tzw. metody piramid (tak budowali piramidy) - czas wyliczony na prece x2+1 jednostka tego czasu.
Link do wypowiedziLink
Jerzy Zientkowski

Jerzy Zientkowski Public speaker and
coach. IT Manager.
Father.

Ciekawe, że temat mówi o współczynniku, a treść jedynie o czasie. A co z pozostałymi parametrami projektu? Koszty, zasoby, jakość? Jak tu mnożyć i jak one wpływają na siebie wzajemnie? :)
Pozdrawiam
Doom_
Link do wypowiedziLink
Zbigniew Rudnicki

Zbigniew Rudnicki Współzałożycieli
Muzeum Historii
Komputerów i
Informatyki...

A moje doświadczenia z zespołem programistów (już z przed 20 lat) nauczyły mnie, że najlepiej korzystać z mądrości pracowników IT z lat 70, czyli podaną przez zespół IT wielkość podnieść o rząd wielkości i wymnożyć razy 2.
Czyli jeśli mówią tydzień to wyjdzie 2 miesiące.
Niestety, wielokrotnie ten algorytm wyliczania okazywał się prawdziwy.Zbigniew Rudnicki edytował(a) ten post dnia 27.03.09 o godzinie 16:35
Link do wypowiedziLink

konto usunięte

Witam

Ktoś z was jest w stanie konkretnie odpowiedzieć dlaczego w ogóle tak duże rozbieżności muszą być brane pod uwagę?

pzdr
Link do wypowiedziLink
Michał Słociński

Michał Słociński making things happen

Paweł W.:
Witam

Ktoś z was jest w stanie konkretnie odpowiedzieć dlaczego w ogóle tak duże rozbieżności muszą być brane pod uwagę?

pzdr

głównie dlatego że podczas estymacji wygodniej jest nam estymować w dniach / godzinach "idealnych", natomiast później okazuje się że jeszcze w ciągu tygodnia trzeba jeszcze wziąć udział w 3 meetingach, przygotować prezentację, wziąć udział w dwóch interview nowych pracowników, rozwiązać pilny problem nie związany z obecnym projektem, pokryć dziurę po koledze który przeszedł do konkurencji, itp sprawy których nikt nie jest w stanie przewidzieć

myślę że (przynajmniej w przypadku programistów) efektywność w średniego / dużego rozmiaru firmie wynosi ok 50%

oczywiście - tak jak pisze Rafał powyżej - jeśli zespół jest stabilny, zna domenę, technologię, zna siebie nawzajem, estymacje są dużo bardziej bliskie rzeczywistościMichał Słociński edytował(a) ten post dnia 27.03.09 o godzinie 20:32
Link do wypowiedziLink
Jacek Bilewicz

Jacek Bilewicz Aby coś zrobić,
trzeba zacząć

Zbigniew Rudnicki:
A moje doświadczenia z zespołem programistów (już z przed 20 lat) nauczyły mnie, że najlepiej korzystać z mądrości pracowników IT z lat 70, czyli podaną przez zespół IT wielkość podnieść o rząd wielkości i wymnożyć razy 2.
Czyli jeśli mówią tydzień to wyjdzie 2 miesiące.
Niestety, wielokrotnie ten algorytm wyliczania okazywał się prawdziwy.Zbigniew Rudnicki edytował(a) ten post dnia 27.03.09 o godzinie 16:35

Zbyszku!
I to niestety jest cała prawda na temat czasu i obietnic zespołów IT.
Pozdrawiam,
Link do wypowiedziLink
Piotr Wolański

Piotr Wolański Programista

Czas realizacji projektu IT w zależności o czasu poświęconego na projektowanie:
Wersja 1: jeden dzień projektowania - 6 miesiecy kodowania
Wersja 2: jeden tydzień projektowania - 4 miesiace kodowania
Wersja 3: jeden miesiąc projektowania - 2 miesiące kodowania

Ale praktycznie realizując wersję 3 po miesiącu okazuje się,
że tak naprawdę wyszła nam wersja 1 ;)
po miesiącu projektowania - poziom projektu jak po 1 dniu pomijając ilość wyprodukowanych papierów ;)
Link do wypowiedziLink
Piotr Wolański

Piotr Wolański Programista

Zbigniew Rudnicki:
podaną przez zespół IT wielkość podnieść o rząd wielkości i wymnożyć razy 2.
Czyli jeśli mówią tydzień to wyjdzie 2 miesiące.

W przypadkach wątpliwych proces należy powtórzyć
czyli z 1 dnia zrobią się 4 miesiące ;)
Link do wypowiedziLink
Krzysztof T.

Krzysztof T. Software maker

Piotr Wolański:
Czas realizacji projektu IT w zależności o czasu poświęconego na projektowanie:
Wersja 1: jeden dzień projektowania - 6 miesiecy kodowania
Wersja 2: jeden tydzień projektowania - 4 miesiace kodowania
Wersja 3: jeden miesiąc projektowania - 2 miesiące kodowania

Ale praktycznie realizując wersję 3 po miesiącu okazuje się,
że tak naprawdę wyszła nam wersja 1 ;)
po miesiącu projektowania - poziom projektu jak po 1 dniu pomijając ilość wyprodukowanych papierów ;)

Nie uogólniał bym - wszystko sprowadza się do jakości ludzi w zespole.

Im większa grupa słabych programistów tym większy narzut musi być na papiery by pohamować radosną twórczość kolegów ze słabym warsztatem.
Im mniejszy stosunek projektanów do klepaczy tym wyższy poziom abstrakcji winien być w mechanizmach strategicznych [czyli silniejsi projektanci](tak by projektanci nadążyli ze zwoją robotą) by klepacze mieli do czego resztę doklepywać, a im wyższy poziom abstrakcji tym więcej kwitów potrzeba wyprodukować na potrzeby kolegów z małym warsztatem by ci wogóle dali radę poprawnie sie oprzeć na takowym ustrojstwie (chyba, że bóg programistów jest łaskawy i pozwala rzeczy zaawansowane technicznie skutecznie odizolować).
Czyli wszystko sprowadza się do jakości ludzi w zespole (naturalnie rozpatruję projekty duże w których nie jesteśmy wstanie patrzeć wszystkim ludziom na łapki)

Jeżeli założymy małą grupkę projektantów, niewiele większą grupkę analityków do produkcji kwitów i dołożymy spore stadko klepaczy - to wyjdzie nam wariant 3. lecz ciut inaczej:

PRZEŁOŻENIE:
1 mc papierkologii (analitycy + osoba pisząca przypadki testowe na podstawie w/w kwitów) == 2 mc produkcji z kodami (projektanci + klepacze + testerzy).

ZALETY:
przetestowany i dobrze udokumentowany produkt. Powstałe ustrojstwo całkowicie odzwierciedla analizę. Rzecz pomimo swoich gabarytów zwykle nie stwarza większych problemów w utrzymaniu i rozszerzaniu.

WADY:
Powstaje tona makulatury której wyprodukowanie sporo kosztowało i w przypadku rozszerzeń trzeba nadal pracować w oparciu o produkcję kodu dopiero po wyprodukowaniu nowych (lub nowej wersji) kwitów.Krzysztof Torenc edytował(a) ten post dnia 30.03.09 o godzinie 02:10
Link do wypowiedziLink
Krzysztof T.

Krzysztof T. Software maker

A nawiązując do tematu - to istnieje jeszcze teoria wg której czas projektu nalezy wydłużyć dodając pierwiastek z tygodni wstępnie oszacowanego projektu. W czasie prowadzenia projektu należy korygować (na nowo wyliczyć pozostały czas) po każdej ewaluacji projektu - co oznacza że w poczatkowej fazie nie jesteśmy w stanie dokładnie oszacowac czasu.
Największą wadą tej metody jest fakt, iz ostatni tydzień może nam się przeciągnąć w nieskończoność, ze względu na pierwiastek z 1 :)))))))))))))))))Krzysztof Torenc edytował(a) ten post dnia 30.03.09 o godzinie 02:20
Link do wypowiedziLink
Marcin Kaniewski

Marcin Kaniewski ITSM, ITIL, PM, IT
Manager

A ja byłbym ciekawy jak się ma to mnożenie do:
- wykorzystywanych metodyk projektowych
- technologii (czy jest uniwersalne, czy nie)
- wielkości zespołu (mam wrażenie, że nikt nie dodaje narzutu na komunikację, a nawet prosta matematyka pokazuje, że zbyt duży zespół potrafi wydłużyć czas trwania projektu w stosunku do założeń i w stosunku do zrobienia tego samego mniejszym zespołem)
- zarządzania czasem (ja twierdzę, że realny i wcale nie najgorszy jest podział czasu 60%+20%+20% gdzie 60% czasu idzie na projekt, 20% na tzw. "gaszenie pożarów", a 20% jest po prostu tracone - i tu zbliżamy się do współczynnika x2, choć Google chwali się, że doszli do układu 80%+20%)
- inwestycji w analizę przedwdrożeniową i to zarówno po stronie możliwych rozwiązań jak i analizy potrzeb biznesowych klienta - doświadczenie podpowiada mi, że klient formułuje potrzeby ogólnie, PM tego nie weryfikuje, i potem klient dokłada nowe pomysły pod hasłem "przecież ja to właśnie miałem na myśli" mimo, że z rozmów poza zapisami wynikało, że wcale nie miał - ale to już nie zostało zapisane.

Pozdrawiam, Marcin
Link do wypowiedziLink
Marcin Mikucki

Marcin Mikucki Urząd Komisji
Nadzoru Finansowego

Skąd rozbieżności?
-Za wcześnie padają liczby, które uznawane są za konkretne.

Najpierw osoby odpowiedzialne za projekt od strony wykonawcy + osoby odpowiedzialne za projekt od strony użytkowników określają potrzeby. I to jest absolutnie kluczowy element. I to w zależności od złożoności i zakresu może zająć mniej lub więcej czasu, ale jest moim zdaniem nie do przeskoczenia. Następnie następuje AKCEPTACJA potrzeb i końcowych funkcjonalności które chcemy wprowadzić.

Dopiero w kolejnym etapie - znając cele które przed nami stoją + znając firmę/użytkowników i sytuację z której startują możemy pokusić się o sprecyzowane i rzucanie liczbami(ile zajmie, ile będzie kosztować, co obejmie itp). I tutaj jedyne poważne poślizgi spowodowane mogą być tylko czynnikiem ludzkim (urlop, nie dyspozycyjność w danym dniu itp) i jedynie w skrajnych przypadkach mogą znacząco odbiegać od przyjętych założeń (ktoś z firmy odszedł, itp). Zdarza się, że np firma - odbiorca nie wywiązuje się z płatności a umową ustalono, że płatne jest w ratach, za przepracowane godziny w ostatnim miesiącu itp i tutaj też może być opóźnienie - z zaznaczeniem, że "na życzenie" zleceniodawcy a nie specyfiki projektu jako takiego.

Inne opóźnienie może wynikać jeszcze, gdy w połowie wdrożenia zmienia się wizja i chce się osiągnąć coś innego niż pierwotnie zakladaliśmy. tutaj jednak wyraźnie należy zaznaczyć - ok jest to możliwe, ale pod pewnymi warunkami, w tym rozciąga się to w czasie o.
Sztuką jest taka analiza przed wdrożeniowa, aby do takiej sytuacji nie dopuścić...
Link do wypowiedziLink
Arkadiusz Cempura

Arkadiusz Cempura Najlepszą metodą
przewidywania
przyszłości jest jej
tworz...

Marcin Mikucki:

Druga sprawa - klienci jak ognia (niestety) unikają analiz przed wdrożeniowych przez co dopiero w trakcie realizacji projektu wychodzą nowe, nieplanowane wcześniej (a wielce pożądane) funkcjonalności

Z tym się zgadzam, ale pewnie wynika to z tego, że analiza zostanie napisana pod "kogoś" (odbiorcę wewnętrznego, dostawcę, itp) i jej wartość będzie nijaka.

Osobiście, o ile to możliwe, stosuję taką zasadę, że zamawiam od wybranego dostawy "demo", na którym mój zespół i ja zdobywamy wiedzę. Z dostawcą demo rozliczam się za usługi - ustalamy zakres i koszty integracji, wsparcia.
Dla nas to możliwość "pouczenia się", dla dostawcy możliwość zaprezentowania. Niestety nie gwarantujemy dostawcy, że ostateczne rozwiązanie będzie jego.
Dla nas to właśnie wartość takiej "analizy przedwdrożeniowej".
Link do wypowiedziLink
Arkadiusz Cempura

Arkadiusz Cempura Najlepszą metodą
przewidywania
przyszłości jest jej
tworz...

Marcin Mikucki:
>[...]

Najpierw osoby odpowiedzialne za projekt od strony wykonawcy + osoby odpowiedzialne za projekt od strony użytkowników określają potrzeby. I to jest absolutnie kluczowy element. I to w zależności od złożoności i zakresu może zająć mniej lub więcej czasu, ale jest moim zdaniem nie do przeskoczenia. Następnie następuje AKCEPTACJA potrzeb i końcowych funkcjonalności które chcemy wprowadzić.
[...]

Tak, tyle co zrobić, gdy na etapie definiowania projektu wymaga się od Ciebie całego mnóstwa danych, których nie masz, nie chcesz mieć. I nie mówię tu o celach biznesowycy, korzyściach i zagrożeniach wynikających z projektu, ale o tym, że musisz oszacować koszty sprzętu, softu i pracy ludzi - o czym nie masz pojęcia. Bez tego projektu nie może wystartować ;( A Ci którzy powinni to wycenić poruszają się we mgle.
Link do wypowiedziLink

konto usunięte

.Ten post został edytowany przez Autora dnia 26.07.16 o godzinie 20:33
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy



Wyślij zaproszenie do
Anuluj