On 20/05/2011 09:12, Przemek O. wrote:
> W dniu 2011-05-20 02:45, Andrzej Jarzabek pisze:
>
>> Nie mylę, tylko zwraqcam uwagę na wieloznaczność pojęcia "częściowa
>> funkcjonalność". Funkcjonalność jest częściowa lub nie częściowa
>> względem czegoś, co arbitralnie uznajesz za kompletną funkcjonalnośc.
>> Jeśli przyjmiesz Office 2010 zqa kompletną funkcjonalność pakietu
>> biurowego, to Office 1.0 ma funkcjonalność częściową.
>
> Tak z punktu widzenia wersji 2010. Jednak wersja 1 miała wszystko to co
> było zaplanowane dla wersji 1, a kolejne wersje są jej rozwojem a nie
> dodawaniem funkcjonalności które były zaprojektowane w momencie
> projektowania wersji 1. Czy uważasz że projektując Office'a 1 mieli w
> planach ribbona dodanego w wersji 2007? Jednak mylisz pojęcia.

Uważam, że prawdopodobnie mieli w planach mnóstwo rzeczy, które nie
znalazły się w wersji 1.0, a z których część znalazła się w kolejnych
wersjach, część w międzyczasie została odrzucona bo stały się obsolete,
albo doświadczenia użytkowników z eksploatacji wersji 1.0 wykazały, że
są one niepotrzebne, a część być może nawet teraz jest w planach dla
kolejnej wersji Office.

>> w mniej więcej takim czasie, więc możemy razem zaryzykować, gdzie
>
> Interesów nie robi się "mniej więcej".

Oczywiście, że się robi. Przecież te wszystkie analizy, plany i co tam
jeszcze nie dają 100% pewnych i 100% dokładnych odpowiedzi. Dają
oszacowania, "estimates", a to właśnie znaczy potoczne określenie "mniej
więcej".

>> Przecież nie chodzi o to, że trzeba udowodnić, tylko że zleceniodawca
>> przewiduje takie straty, więc nalega na wpisanie ich do umowy. Tak jak
>> piszesz, w praktyce to się nie dzieje, ale to dlatego, że w praktyce
>> zleceniodawca zwykle bierze część ryzyka na siebie i ewentualnie ponosi
>> część kosztów opóźnień bądź wycofania się z projektu.
>
> Po pierwsze, prowadzenie biznesu jest ryzykiem samym w sobie.

No właśnie!

> Po drugie nikt nie przewiduje strat na podstawie patrzenia w szklaną
> kulę i swojego widzimisie. Więc bajek się do umowy nie wpisuje.

Różne są sposoby przewidywania strat, widzimisię odpowiedniej osoby może
być warte tyle, co miesiące analiz. Ostatecznie oczywiście żadna metoda
nie daje gwarancji poprawnego przewidywania.

>>> Jeśli ma doświadczenie to potrafi to ustalić. Jak nie potrafi to znaczy
>>> że nie ma.
>>
>> Ogólnie to nieprawda, chociaż nie będę się kłócił, że być może w twojej
>> branży tak właśnie jest.
>
> Kurcze facet, bzdurzysz niemiłosiernie. Jeśli ktoś pisał np. kalkulator
> i zajęło mu to x tygodni i kosztowało Y pieniędzy, to napisanie takiego
> samego kalkulatora tylko z różowymi przyciskami zajmie mu tyle samo

No to właśnie mówię: jeśli masz branżę taką, że piszesz takie same
kalkulatory różniące się kolorami przycisków, to być może właśnie tak
jest, jak piszesz.

> czasu + czas na implementacje różowych przycisków i będzie kosztować Y +
> wartość implementacji różowych przycisków.

W znanych mi branżach raczej by się wzięło tamten wcześniej zrobiony
kalkulator, zmieniło kolor przycisków, zrobiło build i wysłało do
testowania/uzupełnienia dokumentacji itd.

> I w każdej branży tak jest, a przewinąłem się przez kilka firm robiących
> oprogramowanie dla różnych branży, od usługowych poprzez produkcyjne do
> handlowych.
> Sytuacja o której piszesz, może być jedynie w sytuacji gdy firma
> specjalizująca się w oprogramowaniu księgowym weźmie zlecenie na np.
> ERP. Fakt, mając ogóle doświadczenie w tworzeniu oprogramowania i zerowe
> w zakresie zarządzania produkcją nie ma możliwości poprawnego
> oszacowania kosztów i czasu.

Być może w branży programów do ERP czy do księgowości robi się tak, że w
kółko pisze się od nowa programy o prawie takiej samej funkcjonalności,
ale tam, gdzie ja pracowałem w takiej sytuacji raczej wykorzystuje się
istniejący program, a development polega na tworzeniu nowej
funkcjonalności, w której (z wyjątkiem szczególnych przypadków) nikt nie
ma doświadczenia, bo istniejące oprogramowanie firmy takiej
funkcjonalności, jakby, nie ma.

Podam ci przykład: pracowałem w firmie tworzącej oprogramowanie dla
instytucji finansowych, kiedy została ogłoszona, a potem weszła w życie
unijna dyrektywa MiFID. Dyrektywa ta miała duży wpływ na działanie wielu
produktów firmy, wymuszając zmiany, ale też dając okazję dodania nowej
funkcjonalności, która wcześniej nie była możliwa. I co się okazało:
nikt nie miał doświadczenia we wdrażaniu funkcjonalności związanej z
MiFID, bo w ogóle nikt na świecie nie miał takiego doświadczenia, jako
że ta dyrektywa wcześniej nie istniała.

Co więcej, do momentu wejścia w życie tej dyrektywy, a nawet już po tym
momencie, żadni analitycy nie byli w stanie przewidzieć wszystkich
konsekwencji MiFID.

>> Tylko koniec końców klient konkurencji miał większe korzyści, bo przez
>> te 9 miesięcy zarobił więcej kasy, niż ty przez swoje dwa.
>
> To wszystko jest gdybanie zależne od funkcjonalności która dostarczył
> ten pierwszy po 9 miesiącach. Jeśli ta funkcjonalność była wystarczająca
> do zarabiania (jak to piszesz) to reszta jest w ogóle niepotrzebna.

Bo jak już ktoś zarabia milion, to po co mu jeszcze kolejne 3 miliony,
prawda?

>>> Pewnie, wszystko można spierniczyć, ale bez projektu jest to
>>> zdecydowanie prostsze.
>> Nie zgodzę się.
>
> Jesteś fenomenem. Łatwiej trafić do celu z mapą czy bez?

Zależy. Na pewno mapa rysowana przez kogoś, kto sam do tego celu nie
dotarł i bez żadnych informacji od kogokolwiek, kto dotarł, może mieć
wątpliwą wartość.

>> No i tak samo wiarygodne estymaty czasu i budżetu programu z danym
>> zestawem wymagań dadzą ci tylko ci, którzy robili program z dokładnie
>> takim samym zestawem wymagań.
>
> No a o czym ja cały czas pisze? Różne hipotezy są do siebie niepodobne
> (czyli nie mają wspólnych cząstkowych - tak przynajmniej zakładam, bo
> się na tym nie znam) więc nikt nie robił niczego podobnego, stąd nikt
> nie jest w stanie nawet w przybliżeniu podać tych wartości.

Dlaczego? Oczywiście, że istnieją podobne do siebie hipotezy. I czasem
jest tak, że podobna hipoteza daje się udowodnić w dwa miesiące, a
udowodnienie tej właściwej zajmuje 300 lat

> Natomiast jeśli ktoś robił oprogramowanie zarządzające produkcją w
> firmie X, to z dużym prawdopodobieństwem poda realne terminy wykonania i
> koszty zarządzania produkcją dla firmy Y, gdzie wymagania różnią się
> jedynie specyfiką ścieżki produkcji.

Nie znam się kompletnie na oprogramowaniu zarządzającym produkcją. Mam
natomiast doświadczenie z tym, że buduje się nowe systemy albo
rozbudowuje istniejące o jakościowo nową funkcjonalność, często taką,
jakiej dana firma nigdy nie tworzyła.

>> To ty sobie poczytaj o tym, co robiło Apple w momencie, kiedy im
>> pokazano Xerox PARC Alto. I wytłumacz mi, jak to się mogło stać, że
>> Xerox, w końcu poważna spółka akcyjna, zainicjowała i przeprowadziła
>> development nowego projektu nigdy nie zdając sobie sprawy, że siedzą na
>> żyle złota. Czyżby nie potrafili wykonać prostej analizu potrzeb rynku?
>
> Inna sytuacja gospodarcza, inny poziom rozwoju technologii. My piszemy o
> sprawach dla nas oczywistych, gdzie oprogramowania jako takiego jest na
> pęczki. Komputerów na tamten moment (lub maszyn "podobnych") było tyle,
> że można było na palcach policzyć.

Ale weź naprawdę cokolwiek o tym przeczytaj, zanim będziesz dalej brnąć
w te bzdury. Choćby stronę w Wikipedii.

Prawdą jest oczywiście, że poziom rozwoju technologii jest inny, ale też
dzisiaj raczej nie tworzy się od zera GUI o funkcjonalności Xerox Alto.
Tworzy się nowe programy, robiące nowe rzeczy, które często bywają
nieoczywiste.

> Tak samo jak w czasach dzisiejszych
> wielka korporacja zbudowałaby teleport wielkości hangaru, za kwotę 9
> zerową - raczej interesu na tym by nie zrobiła, ale jak jakiś Woźniak
> zrobiłby coś podobnego wielkości garażu i za kwotę 5 zerową, to nawet
> jeśli teleportowałby 9 / 10 osób (ta jedna by nie wracała) to jeśli
> byłby popyt na tego rodzaju sprzęt to zarobiłby ogromną kasę.
> I celowo piszę tu o fantazji typu teleport, bo mniej więcej tym samym
> dla przeciętnego człowieka w tamtych czasach był komputer.

To może przypomnij mi, na czym Apple się tak rozrosło, że w 1980 roku
weszło na giełdę?

>> Jakich odpowiedników? Mówisz o tabletowych pecetach, które były na rynku
>> przed iPadem, czy wchodzącej narynek fali tabletów imitujących iPada?
>
> Tablety mają o wiele większą funkcjonalność i nie porównuję do nich.

iPad to jest tablet.

> I tak, po części piszę o tych, jak to nazywasz "imitacjach".

Zauważ zatem, że zanim iPad wszedł na rynek, to tych imitacji nie było.
A teraz nagle każdy i jego stryjek wypuszcza swojego tableta imitującego
iPada na rynek. Jak to się zatem stało, że tylko Apple było w stanie
przewidzieć zapotrzebowanie na tego typu produkty, skoro analiza rynku
to ujawnia?

> Szkoda tylko,
> że "imitacje" są na wyższym poziomie technologicznym, a do tego są o
> połowę tańsze. Szkoda też za Apple zerżnęło design zarówno urządzenia i
> systemu pierwotnego (iPhone) z Samsunga. No ale cóż, lepszy marketing i
> logo obgryzionego jabłka zobowiązuje.

Może jednak rozważysz możliwość, że pewne istotne aspekty ci umykają.

>> Bardzo prosto. Apple po prostu zrobiło analizę potrzeb rynku, na co nikt
>> inny nie wpadł, zapewne dlatego, że firmy próbujące wprowadzać wcześniej
>> tablet PC są kiepsko zarządzane.
>
> Tablet PC i iPad jest kierowany do innego klienta docelowego.

No i co? Żadna z firm produkujących tablet PC nie przeprowadziła analizy
potrzeb rynku, która by wykazała do jakiego klienta trzeba kierować żeby
zarobić?

>>> Z każdym następnym projektem lepiej.
>>
>> To może u was w firmie, bo jeśli chodzi o całość branży to nie jest tak
>> fajnie, czego efektem modele iteracyjne i również agile.
>
> Model kaskadowy też jest w wersji iteracyjnej.

Nie chcę się z tobą kłócić, co oznacza "model kaskadowy", ale określenia
"waterfall" często używa się właśnie do modelu bez iteracji.

>> Ale to tylko przenosi ryzyko na zleceniodawce. Zleceniodawca szuka więc
>> wykonawcy do programu, który mu jest potrzebny, więc robi analizę u
>> pierwszego wykonawcy i dostaje cenę nie do przyjęcia, robi u drugiego
>> wykonawcy i dostaje termin nie do przyjęcia, robi u trzeciego i dostaje
>> propozycję kar za opóźnienie nie do przyjęcia, robi u czwartego i
>> czwarty proponuje formy konktraktów nie dające odpowiednich gwarancji.
>> Stwierdza więc, że nie chce jednak zamawiać tego programu, a tymczasem
>> stracił już x milionów na te wszystkie analizy.
>
> Nie, bo analiza jest własnością zleceniodawcy. Tak więc robi się ja
> tylko raz.

No to masz odpowiedź, jak można w takiej sytuacji stosować agile. Masz
klienta, który zgodzi się zapłacić za analizę która by trwała np. dwa
miesiące, zakładając że jakaś wizja już na tym etapie istnieje (bo
przecież uzgadniacie czego ma to być analiza). Uzgadniasz z klientem, że
udostępni ci swoich przedstawicieli na potrzeby wynokania tej analizy, i
wokół tego zaczynasz budować zespół agile: na tym etapie będziesz
potrzebował analityków i programistów. Bierzesz wszystkich do kupy,
przedstawiasz wizję i zaczynasz planować iteracje. Po dwóch miesiącach
masz nie tylko analizę, ale już masz "working software", masz
programistów, którzy rozumieją co program ma robić, którzy mieli okazję
zapoznać się z poszczególnymi zidentyfikowanymi kawałkami
funkcjonalności, zidentyfikować część potencjalnych problemów
implementacyjnych, których analityk mógłby nie zauważyć (choćby dlatego,
że nie rozumie co to jest "złożoność wykładnicza"), masz gotową
infrastrukturę (source control, integration server, stanowiska,
narzędzia). Masz wymagania spisane przez analityków, w które też wchodzi
cenny feedback z użytkowania prototypów przez customerów, massz
zidentyfikowane MMF, customer representatives mają w tym momencie dobrą
orientację co do ważności features/stories, a twoi programiści co do
tego, jak trudne te fragmenty będą do zaimplementowania. Masz wyznaczone
velocity, a to znaczy, że w ostatniej fazie możesz zrobić planowanie
release'ów mając dobre estymaty co do scope i czasu wykonania dla dwóch
pierwszych wersji.

Co więcej, dzięki feedbackowi między zleceniodawcą, customer
representatives i tobą, zleceniodawca wie, że masz koncepcję produktu (w
postaci działającego demo), która mu się podoba, wie jaki masz proces,
wie że i w jaki sposób są uwzględniane uwagi jego customer
representatives, wie, że starasz się zrozumieć jego potrzeby i jak do
tego podchodzisz. W skrócie - o ile nie spierdoliłeś sprawy - masz
zbudowaną relację zaufania.