W dniu 2011-05-20 02:45, Andrzej Jarzabek pisze:

>>> A jednak MS Office 1.0 nie miał pełnej funkcjonalności MS Office 2010.
>>
>> MS Office 1.0 nie był prototypem. Mylisz fazy cyklu wytworzenia
>> aplikacji z cyklem rozwoju aplikacji.
>
> 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.

> w mniej więcej takim czasie, więc możemy razem zaryzykować, gdzie

Interesów nie robi się "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. Gdyby było
inaczej, każdy z nas byłby miliarderem z rentownymi przedsiębiorstwami.
Po drugie nikt nie przewiduje strat na podstawie patrzenia w szklaną
kulę i swojego widzimisie. Więc bajek się do umowy nie wpisuje.

>> 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
czasu + czas na implementacje różowych przycisków i będzie kosztować Y +
wartość implementacji różowych przycisków.
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.

> 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.

>> 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?

> 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.

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.

> 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ć. 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.

> 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. I
tak, po części piszę o tych, jak to nazywasz "imitacjach". 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.

> 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.

>> 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.

> 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.

pozdrawiam,
Przemek O.