Użytkownik "Mateusz Ludwin" <n...@s...org> napisał w wiadomości
news:hjulhr$sui$2@inews.gazeta.pl...
> 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?

Pytasz, po ilu latach?
Widzę, że dobre samopoczucie dopisuje.

Grunt, to zadowolenie klienta. :)


pozdr.

j.

do góry

W dniu 2010-01-29 13:50, Mateusz Ludwin pisze:
> 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?

Po pierwszym padzie systemu, który będzie się podnosiło kilka godzin,
zanim właściwa osoba przypomni sobie, jak to wyglądało przed poprawką.

Nie koniecznie chodzi o rygor projektowy (tj. projektowania
i wprowadzania poprawki do kodu). Elementarna jest np. procedura
rollbacku zmiany, czyli przynajmniej łatwe uruchomienie systemu
w poprzedniej wersji.

Oczywiście, jak wszystko - zależy. Jeśli klient może sobie pozwolić
na pad systemu, bo go to niewiele relatywnie kosztuje, to OK.

--
Paweł Kierski
n...@p...net

do góry

W dniu 2010-01-29 13:51, Mateusz Ludwin pisze:
> 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.

To działa do pewnego momentu. W każdym projekcie jest ileś zmian,
które mogą przynieść duży zysk, a można je tanio "nahackować". I do
tego momentu klient jest zadowolony. Ale przy takim "hackowaniu"
przychodzi dzień, gdy krytyczna zmiana jest praktycznie niemożliwa do
wprowadzenia, bo jakoś tak po drodze koszy kolejnej zmiany (szczególnie
potrzebny czas) rosły wykładniczo.

Zarządzanie ryzykiem polega na świadomym wyborze między skrajnościami:
a) każda zmiana kosztuje mniej więcej tyle samo (koszty stałe jej
wprowadzenia są duże, ale prawdopodobieństwo wygenerowania
dodatkowych kosztów jest marginalne)
b) koszty zmian rosną wykładniczo

--
Paweł Kierski
n...@p...net

do góry

Uzytkownik "crtm81" <w...@d...rada.pl> napisal w wiadomosci
news:hjfj5q$5or$1@achot.icm.edu.pl...
> Napiszcie jak to wyglada u Was.

Pracujemy razem? :)

do góry

Użytkownik "crtm81" <w...@d...rada.pl> napisał w wiadomości
news:hjfm6g$928$1@achot.icm.edu.pl...
> On 23/01/2010 21:04, Mariusz Marszałkowski wrote:
>> W jednym projekcie szef mi powiedział ze nie wie co mamy zrobic.
>> Podał tylko branze i ze program ma podniesc atrakcyjnoscj jego
>> produktow :) Koszmar, nikt nic nie wiedzial, nikt nie znal branzy,
>> nikt nie mial doswiadczenia.... ale po roku cos z tego sie wyklulo :)
> Widzisz, twoj szef przynajmniej sie przyznal ze sie nie zna na temacie.
> Moj tez sie nie zna, ale uwaza sie za znawce. Przychodzi do mnie z jakims
> zadaniem i sie kompromituje.

Gdzieś to... chyba mamy tego samego szefa ;)

do góry

Użytkownik "jacem" <j...@1...pl> napisał w wiadomości
news:hjfmk3$a21$1@atlantis.news.neostrada.pl...
> Użytkownik "crtm81" <w...@d...rada.pl> napisał w wiadomości
> news:hjfm6g$928$1@achot.icm.edu.pl...
>> On 23/01/2010 21:04, Mariusz Marszałkowski wrote:
>>> W jednym projekcie szef mi powiedział ze nie wie co mamy zrobic.
>>> Podał tylko branze i ze program ma podniesc atrakcyjnoscj jego
>>> produktow :) Koszmar, nikt nic nie wiedzial, nikt nie znal branzy,
>>> nikt nie mial doswiadczenia.... ale po roku cos z tego sie wyklulo :)
>> Widzisz, twoj szef przynajmniej sie przyznal ze sie nie zna na temacie.
>> Moj tez sie nie zna, ale uwaza sie za znawce. Przychodzi do mnie z
>> jakims zadaniem i sie kompromituje.
> A na czym się znają wasi szefowie, skoro są szefami?
> W takim razie, po co Wam szef? ;)


U mnie szef jest po to, bo się okazało, że program (ok, 0.8mln linii kodu
napisanych/projektowanych/testowanych przez jedną osobę) nie spełnia w 100%
oczekiwań klienta. Więc dostałem szefa, który ma mi w tym pomóc zaradzić :)
I zamiast wzbogacić dział programistyczny o menedżera/konsultanta znającego
technologię i branżę, programistów i testerów, rozwinął helpdesk ze
śladowymi znajomościami programowania ;)

do góry

Paweł Kierski wrote:

>> To znaczy po ilu latach przestanie być zadowolony?
>
> Po pierwszym padzie systemu, który będzie się podnosiło kilka godzin,
> zanim właściwa osoba przypomni sobie, jak to wyglądało przed poprawką.

To czemu ciągle jest zadowolony?

> Nie koniecznie chodzi o rygor projektowy (tj. projektowania
> i wprowadzania poprawki do kodu). Elementarna jest np. procedura
> rollbacku zmiany, czyli przynajmniej łatwe uruchomienie systemu
> w poprzedniej wersji.

Poprawiacz zapewne ma jakieś kopie zapasowe na swoim dysku.

> Oczywiście, jak wszystko - zależy. Jeśli klient może sobie pozwolić
> na pad systemu, bo go to niewiele relatywnie kosztuje, to OK.

Jak na razie system się nie wysypał.
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

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.
>
> Rozumiesz oczywiscie pojecie "ryzyko"? I "koszt ryzyka"?

Rozumiem ale co to ma do rzeczy? Biznes ma to gdzieś i podoba mu się gówno w
pehapie. I co mu zrobisz?
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

do góry

W dniu 2010-02-01 14:03, Mateusz Ludwin pisze:
> Paweł Kierski wrote:
>
>>> To znaczy po ilu latach przestanie być zadowolony?
>>
>> Po pierwszym padzie systemu, który będzie się podnosiło kilka godzin,
>> zanim właściwa osoba przypomni sobie, jak to wyglądało przed poprawką.
>
> To czemu ciągle jest zadowolony?

Tak jak kierowca, któremu przykręcone na jednej śrubie koło jeszcze
się nie urwało.

>
>> Nie koniecznie chodzi o rygor projektowy (tj. projektowania
>> i wprowadzania poprawki do kodu). Elementarna jest np. procedura
>> rollbacku zmiany, czyli przynajmniej łatwe uruchomienie systemu
>> w poprzedniej wersji.
>
> Poprawiacz zapewne ma jakieś kopie zapasowe na swoim dysku.

Ty pewnie byś miał. Ja bym się postarał mieć nie tylko na swoim, ale
i na produkcji, żeby nie było problemów z przerzucaniem. Ale bywają
tacy hardcore'owcy, dla których tego typu zabezpieczenie byłoby poniżej
ich godności, bo sugerowałoby, że mogą się pomylić...

>> Oczywiście, jak wszystko - zależy. Jeśli klient może sobie pozwolić
>> na pad systemu, bo go to niewiele relatywnie kosztuje, to OK.
>
> Jak na razie system się nie wysypał.

... "Jak na razie dobrze karmią" - rzekł kogut przed niedzielnym
obiadem... 8-)

To cały czas kwestia ryzyka - jeśli się go nie zna, to naturalnie
uważa się je za zerowe. Tym boleśniejsze spotkanie z rzeczywistością.
Jeśli jest oszacowane i biznesowo pomijalne, to OK - można nawet spalić
kod źródłowy.

A co do marginalności ryzyka - sam walnąłem gafę, rzucając na
spotkaniu projektowym: "Taki przeplot, to jak wygrać szóstkę.". Problem
był taki, że dla 6 mln użytkowników, to tylko 2-3 razy mniej
prawdopodobne, a szóstka w Polsce pada częściej niż raz na miesiąc...

--
Paweł Kierski
n...@p...net

do góry

W dniu 2010-02-01 14:04, Mateusz Ludwin pisze:
> 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"?
>
> Rozumiem ale co to ma do rzeczy? Biznes ma to gdzieś i podoba mu się
> gówno w pehapie. I co mu zrobisz?

Co najmniej napiszesz dupochron, że ryzyko jest. Inaczej przy padzie
to będzie twoja wina. I co wtedy zrobisz biznesowi, jak Cię będzie
zwalniał, albo pozywał o odszkodowanie? Może się oczywiście zdarzyć, że
samo przedstawienie takiego dupochronu spowoduje zwolnienie, ale to
chyba nawet lepiej - po co iść na dno z lemingami?

--
Paweł Kierski
n...@p...net

do góry