Michal Kleczek wrote:
> Mateusz Ludwin wrote:
>
>> Michal Kleczek wrote:
>>
>>> W dowolnym nietrywialnym systemie robienie jakiejkolwiek (nawet
>>> najmniejszej) zmiany w jeden dzien jest proszeniem sie o klopoty.
>>> Dlatego pisalem o "Hello, World".
>> Jak są kłopoty to się je rozwiązuje na drugi dzień i mamy 2 MD.
>
> Wszystko fajnie dopoki wystapienie tych "klopotow" nie niesie za soba
> kosztow. To, ze czesto sie tych kosztow nie zauwaza, nie wynika z tego, ze
> ich nie ma, tylko z tego, ze trudno je oszacowac - do tego jest potrzebne
> zarzadzanie ryzykiem, a tego nikomu nie chce sie robic.

Skoro jest taniej niż z rygorem, to znaczy że nie niesie.

>> Przy zachowaniu rygoru projektowego jest to minimum 5 MD.
>>
>> Więc po co biznes ma przepłacać?
>
> Dlatego stosuje sie podejscie odwrotne - kumuluje sie wiele zmian w jednym
> release po to, zeby koszty stale zwiazane z zachowaniem rygoru projektowego
> sie rozkladaly.

Nic się nie kumuluje. Robi się poprawki na kolanie i biznes jest zadowolony.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
news:hjuiuq$jg5

> Nic się nie kumuluje. Robi się poprawki na kolanie i biznes jest
> zadowolony.

Do czasu. ;)

do góry

Mateusz Ludwin wrote:

> Michal Kleczek wrote:
>
>>>> W dowolnym nietrywialnym systemie robienie jakiejkolwiek (nawet
>>>> najmniejszej) zmiany w jeden dzien jest proszeniem sie o klopoty.
>>>> Dlatego pisalem o "Hello, World".
>>> Jak są kłopoty to się je rozwiązuje na drugi dzień i mamy 2 MD.
>>
>> Aha - a skad bez zachowania rygoru projektowego wiadomo, ze rozwiazanie
>> jednych klopotow nie rodzi nastepnych?
>
> Bo nic się nie sypie.

Tak, tak. Jasne.

> A jak się posypie, to się poprawi.

To jest oszukiwanie klienta, bo on za te wszystkie zmiany i poprawki w
zmianach i zmiany do zmian placi. Wydaje sie, ze to jest tanio, bo kazda
mala zmiana malo kosztuje - widac drzewa a nie widac lasu.
Ale calosciowe koszty sa znacznie wieksze.
Po drugie sa jeszcze koszty ukryte - np. niemoznosc zrobienia pewnych zmian,
bo pies z kulawa noga juz nie wie jak to cudo dziala i jakie konsekwencje
zmiany ze soba niosa. To powoduje, ze albo po prostu sie zmian nie robi i
ponosi sie koszty zaniechan, albo robi sie inne (mniejsze) zmiany,
"workaroundy" itp. - tylko potegujace ogolny balagan.
Wreszcie - co jakis czas - wyrzuca sie badziewie na smietnik i robi sie nowe
badziewie zgodnie z zasada "tym razem to juz bedzie znakomity produkt". A
powstaje nowy syf, bo przy tym podejsciu nic innego powstac nie moze.
Kazdy taki "zryw rewolucyjny" to w sumie zmiana jak kazda inna (tyle ze
wieksza) - wiec oczywiscie patrz punkt o kosztach zmian i niewidzeniu lasu.

Jasne - nikt sie nie przyzna do problemu i wszyscy beda mowili ze jest
swietnie (oczywiscie narzekajac przy wodce w gronie znajomych po robocie).
Do momentu, gdy przyjdzie "kryzys" lub inne wydarzenie uzmyslawiajace
wszystkim, ze nie oplaca sie wyrzucac pieniedzy w bloto i wtedy jest
pretekst, zeby cale towarzystwo wypieprzyc na bruk.

--
Michal

do góry

jacem wrote:
> Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
> news:hjuiuq$jg5
>
>> Nic się nie kumuluje. Robi się poprawki na kolanie i biznes jest
>> zadowolony.
>
> Do czasu. ;)

To znaczy po ilu latach przestanie być zadowolony?
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Michal Kleczek wrote:

> Tak, tak. Jasne.
>
>> A jak się posypie, to się poprawi.
>
> To jest oszukiwanie klienta, bo on za te wszystkie zmiany i poprawki w
> zmianach i zmiany do zmian placi. Wydaje sie, ze to jest tanio, bo kazda
> mala zmiana malo kosztuje - widac drzewa a nie widac lasu.
> Ale calosciowe koszty sa znacznie wieksze.

Ale wcale nie są większe i klientowi pasuje to co dostaje. Klientowi się nie
podoba że podobny soft zrobiony z rygorem miałby kosztować 3x więcej czasu.

Ty myślisz jak programista na studiach, a biznes ma to gdzieś. Ma działać na
jutro, bo np. dodanie jednego pola spowoduje wzrost przychodów o paręset tysięcy
zł. dziennie.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Mateusz Ludwin wrote:

> Michal Kleczek wrote:
>
>> Tak, tak. Jasne.
>>
>>> A jak się posypie, to się poprawi.
>>
>> To jest oszukiwanie klienta, bo on za te wszystkie zmiany i poprawki w
>> zmianach i zmiany do zmian placi. Wydaje sie, ze to jest tanio, bo kazda
>> mala zmiana malo kosztuje - widac drzewa a nie widac lasu.
>> Ale calosciowe koszty sa znacznie wieksze.
>
> Ale wcale nie są większe i klientowi pasuje to co dostaje. Klientowi się
> nie podoba że podobny soft zrobiony z rygorem miałby kosztować 3x więcej
> czasu.

To jest wlasnie nieprawda - twoj sposob wydaje sie tanszy bo zakladasz
klapki na oczy i nie uwzgledniasz wszystkich kosztow.

>
> Ty myślisz jak programista na studiach, a biznes ma to gdzieś.

Ja mysle jak programista po studiach i z kiklunastoletnia praktyka :)
A biznes oczywiscie ci uwierzy jak mu powiesz, ze "to nic nie kosztuje".
Tyle, ze ty oszukujesz.

> Ma działać
> na jutro, bo np. dodanie jednego pola spowoduje wzrost przychodów o
> paręset tysięcy zł. dziennie.

Pod warunkiem, ze nic nie zepsujesz w taki sposob, ze bug przyniesie pareset
tysiecy zl dziennie strat.

--
Michal

do góry

Michal Kleczek wrote:

>> Ale wcale nie są większe i klientowi pasuje to co dostaje. Klientowi się
>> nie podoba że podobny soft zrobiony z rygorem miałby kosztować 3x więcej
>> czasu.
>
> To jest wlasnie nieprawda - twoj sposob wydaje sie tanszy bo zakladasz
> klapki na oczy i nie uwzgledniasz wszystkich kosztow.

Jaki znowu MÓJ sposób?

>> Ty myślisz jak programista na studiach, a biznes ma to gdzieś.
>
> Ja mysle jak programista po studiach i z kiklunastoletnia praktyka :)
> A biznes oczywiscie ci uwierzy jak mu powiesz, ze "to nic nie kosztuje".
> Tyle, ze ty oszukujesz.

JA?

Ja jestem po stronie rygoru z którego biznes jest niezadowolony bo poprzednio
było 3x szybciej jak jeden gość klepał pehap na kolanie.

>> Ma działać
>> na jutro, bo np. dodanie jednego pola spowoduje wzrost przychodów o
>> paręset tysięcy zł. dziennie.
>
> Pod warunkiem, ze nic nie zepsujesz w taki sposob, ze bug przyniesie pareset
> tysiecy zl dziennie strat.

Najwyraźniej nie przynosi.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Mateusz Ludwin wrote:

>
>>> Ma działać
>>> na jutro, bo np. dodanie jednego pola spowoduje wzrost przychodów o
>>> paręset tysięcy zł. dziennie.
>>
>> Pod warunkiem, ze nic nie zepsujesz w taki sposob, ze bug przyniesie
>> pareset tysiecy zl dziennie strat.
>
> Najwyraźniej nie przynosi.

Eee tam. Nie przynosi, jak nie kalkulujesz ryzyka. Np. ryzyka zwiazanego z
dziurami w bezpieczenstwie systemu.

--
Michal

do góry

Michal Kleczek wrote:

>>>> Ma działać
>>>> na jutro, bo np. dodanie jednego pola spowoduje wzrost przychodów o
>>>> paręset tysięcy zł. dziennie.
>>> Pod warunkiem, ze nic nie zepsujesz w taki sposob, ze bug przyniesie
>>> pareset tysiecy zl dziennie strat.
>> Najwyraźniej nie przynosi.
>
> Eee tam. Nie przynosi, jak nie kalkulujesz ryzyka. Np. ryzyka zwiazanego z
> dziurami w bezpieczenstwie systemu.

Ale nie przynosi, zrozum że to tak działa od paru lat i wszyscy są zadowoleni.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

Mateusz Ludwin wrote:

> Michal Kleczek wrote:
>
>>>>> Ma działać
>>>>> na jutro, bo np. dodanie jednego pola spowoduje wzrost przychodów o
>>>>> paręset tysięcy zł. dziennie.
>>>> Pod warunkiem, ze nic nie zepsujesz w taki sposob, ze bug przyniesie
>>>> pareset tysiecy zl dziennie strat.
>>> Najwyraźniej nie przynosi.
>>
>> Eee tam. Nie przynosi, jak nie kalkulujesz ryzyka. Np. ryzyka zwiazanego
>> z dziurami w bezpieczenstwie systemu.
>
> Ale nie przynosi, zrozum że to tak działa od paru lat i wszyscy są
> zadowoleni.

Rozumiesz oczywiscie pojecie "ryzyko"? I "koszt ryzyka"?

--
Michal

do góry