Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Projektowanie - jak to wyglada w praktyce?

5 views
Skip to first unread message

crtm81

unread,
Jan 23, 2010, 2:37:28 PM1/23/10
to
Witam,

Pracuje jako programista juz w drugiej firmie i w obu firmach nie ma
czegos takiego jak zbieranie wymagan czy projektowanie oprogramowania.
Praktycznie wszystkie czynosci sa przeprowadzane przez programistow, nie
ma nawet testerow. Fakt, firmy sa male, ale to nie zmienia faktu ze
powinny wdrozyc jakies procedury, tym bardziej ze te obecnie stosowane
rzutuja na jakos produktu.

Czesto zdarza sie tak, ze trzeba po prostu realizowaz wizje szefa, nawet
jesli sie z nim nie zgadza. Albo ze w trakcie wykonania jednego zadania,
ktore jest na wpol ukonczone, ale juz "jakos tam" dziala szef przychodzi
i mowi mi ze mam to jak najszybciej skonczyc (czyli byle jak) i zajac
sie czyms nowym.

Napiszcie jak to wyglada u Was.

Pozdrawiam

Mariusz Marszałkowski

unread,
Jan 23, 2010, 3:04:09 PM1/23/10
to

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 :)

Pozdrawiam

jacem

unread,
Jan 23, 2010, 3:28:47 PM1/23/10
to
Uzytkownik "crtm81" <wu...@dobra.rada.pl> napisal w wiadomosci
news:hjfj5q$5or$1...@achot.icm.edu.pl...

PHP?

crtm81

unread,
Jan 23, 2010, 3:29:04 PM1/23/10
to
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.

jacem

unread,
Jan 23, 2010, 3:33:45 PM1/23/10
to
U�ytkownik "crtm81" <wu...@dobra.rada.pl> napisa� w wiadomo�ci
news:hjfm6g$928$1...@achot.icm.edu.pl...


A na czym siďż˝ znajďż˝ wasi szefowie, skoro sďż˝ szefami?

W takim razie, po co Wam szef? ;)

We�cie sprawy w swoje r�ce.

crtm81

unread,
Jan 23, 2010, 4:27:25 PM1/23/10
to
On 23/01/2010 21:28, jacem wrote:
> PHP?

JSP

Depesz

unread,
Jan 24, 2010, 8:16:04 AM1/24/10
to

Uzytkownik "crtm81" <wu...@dobra.rada.pl> napisal w wiadomosci
news:hjfj5q$5or$1...@achot.icm.edu.pl...
> Witam,
>
Uciekaj jak najszybciej z tej firmy bo nic dobrego z tego nie wyniknie. Przy
takiej polityce firmy, zarabiasz na siebie (i ofc na szefa) zrealizowanymi
projektami. Jakosc wykonanej pracy ma mniejsze znaczenie, liczy sie tylko
ilosc zamowien spadajacych na firme. W takim przypadku ogranicza sie lub
calkowicie rezygnuje z niektorych etapow wytwarzania oprogramowania
(zbieranie wymagan, testowanie itp), byle tylko zrealizowac wiecej zamowien.
Programista sam sobie jest sterem, zeglarzem i okretem, bo firmie nie oplaca
sie stworzyc zespolu projektowego z podzialem rol.


Jacek

unread,
Jan 24, 2010, 8:54:48 AM1/24/10
to
I potem wychodza takie Platniki.

crtm81

unread,
Jan 24, 2010, 10:48:02 AM1/24/10
to
On 23/01/2010 21:33, jacem wrote:
> A na czym siďż˝ znajďż˝ wasi szefowie, skoro sďż˝ szefami?
>
> W takim razie, po co Wam szef? ;)
>
> We�cie sprawy w swoje r�ce.

Moj szef kiedys tam byl programista. To kiedys tam bylo dawno temu i
technologia zmienila sie tak bardzo, ze jego wiedza jest juz nieaktualna.

Powinien zajmowac sie sprawami biznesowymi, a w sprawach technicznych
konsultowac swoje decyzje z ludzmi, ktorzy w tym siedza.

Er

unread,
Jan 24, 2010, 1:21:17 PM1/24/10
to
crtm81 pisze:

> Moj tez sie nie zna, ale uwaza sie za znawce. Przychodzi do mnie z
> jakims zadaniem i sie kompromituje.

Czy my nie pracujemy razem?
;)

crtm81

unread,
Jan 24, 2010, 3:57:24 PM1/24/10
to

Mam nadzieje, ze nie jestes moim szefem :)

Er

unread,
Jan 24, 2010, 4:30:11 PM1/24/10
to
crtm81 pisze:

Zmierza�em raczej do tego, �e mo�e mamy wsp�lnego szefa ;)

Paweł Kierski

unread,
Jan 25, 2010, 5:02:37 PM1/25/10
to
W dniu 2010-01-24 14:16, Depesz pisze:

Na początek zastrzegam - też lubię pracować w zespole, w którym jest
czas, miejsce i pieniądze dla dobrych praktyk: podziału ról,
testowania, zbierania wymagań i ich biznesowej selekcji.

A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje
biznesowy sukces, przynajmniej w bliskim horyzoncie. Oczywiście na
dłuższą metę nie da się tak rozwijać projektu, który ma jako tako
ustalone wymagania i odbiorcę - w końcu utrzymywanie jakość, kosz
utrzymania projektu i prób jego rozwoju staną się zaporowe dla klienta.
Ale czasem dokładnie tego zleceniodawca/pracodawca od nas może wymagać.
Praca z tak ograniczonymi zasobami czasu i informacji też może być
ciekawa, ale... nie na dłuższą metę. No i pochwalić się dobrą robotą
raczej nie będzie można, a i o rozwoju własnym lepiej zapomnieć.

--
Paweł Kierski
ne...@pkierski.net

arturbac

unread,
Jan 25, 2010, 8:21:26 PM1/25/10
to
W dniu 2010-01-25 23:02, Paweł Kierski pisze:

> Na początek zastrzegam - też lubię pracować w zespole, w którym jest
> czas, miejsce i pieniądze dla dobrych praktyk: podziału ról,
> testowania, zbierania wymagań i ich biznesowej selekcji.
>
> A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
> cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje

Ja od paru lat pracuje w metodologi agile - cos podobnego do extreme
programing i nie narzekam. Ale cel chocby ustnie - emailem zawsze
okreslamy i calosc projektu iterujemy od kad dolaczylem do zespolu.

Jacek Czerwinski

unread,
Jan 26, 2010, 1:36:19 AM1/26/10
to
arturbac pisze:

> W dniu 2010-01-25 23:02, Paweł Kierski pisze:
>> Na początek zastrzegam - też lubię pracować w zespole, w którym jest
>> czas, miejsce i pieniądze dla dobrych praktyk: podziału ról,
>> testowania, zbierania wymagań i ich biznesowej selekcji.
>>
>> A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
>> cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje
>
> Ja od paru lat pracuje w metodologi agile - cos podobnego do extreme
> programing i nie narzekam.

O ile XP to konkretna spisana metodyka, to "agile" jest grupą, kategorią
metodyk i warto by powiedzieć w której konkretnie.

Nie weź tego zbyt osobiście, ale agile to szalenie wygodne hasło,
wszędzie gdzie nie mam żadnej metody(-ki) można powiedziec "bo my
własnie pracujemy w agile", "pracujemy w metodzie 'podobnej' do XP".
Jak mówi reklama, "prawie" robi różnicę.

Co nie zmienia faktu, że są tacy którzy rzeczywiście używają
"ukonstytuowanych" XP lub innych konkretnych opisanych metod z grupy
'agile', ale te masy naciagające słowa jak z gumy popsuły znaczenie tego
słowa.

crtm81

unread,
Jan 26, 2010, 12:06:31 PM1/26/10
to
On 26/01/2010 07:36, Jacek Czerwinski wrote:

> O ile XP to konkretna spisana metodyka, to "agile" jest grupą, kategorią
> metodyk i warto by powiedzieć w której konkretnie.
>
> Nie weź tego zbyt osobiście, ale agile to szalenie wygodne hasło,
> wszędzie gdzie nie mam żadnej metody(-ki) można powiedziec "bo my
> własnie pracujemy w agile", "pracujemy w metodzie 'podobnej' do XP".
> Jak mówi reklama, "prawie" robi różnicę.

My pracujemy wg. metody eXtreme Working :)
W znaczeniu doslownym oczywiscie

"Prawie" robi roznice, ale lepsze to niz totalny chaos.

crtm81

unread,
Jan 26, 2010, 12:10:51 PM1/26/10
to
On 25/01/2010 23:02, Paweł Kierski wrote:

> A teraz uwaga, będzie herezja: model zbliżony do "zróbmy jakkolwiek,
> cokolwiek, byle najdalej na dzisiaj" w niektórych przypadkach daje
> biznesowy sukces, przynajmniej w bliskim horyzoncie. Oczywiście na
> dłuższą metę nie da się tak rozwijać projektu, który ma jako tako
> ustalone wymagania i odbiorcę - w końcu utrzymywanie jakość, kosz
> utrzymania projektu i prób jego rozwoju staną się zaporowe dla klienta.
> Ale czasem dokładnie tego zleceniodawca/pracodawca od nas może wymagać.
> Praca z tak ograniczonymi zasobami czasu i informacji też może być
> ciekawa, ale... nie na dłuższą metę. No i pochwalić się dobrą robotą
> raczej nie będzie można, a i o rozwoju własnym lepiej zapomnieć.
>

IT to dosc ryzykowny biznes i takie praktyki sa uzasadnione na poczatku
projektu, chocby po to, zeby wybadac reakcje potencjalnych klientow.

Ale po jakims czasie, jak aplikacja zaczyna sie rozrastac, wypadaloby
pomyslec o jakosci. Nie tylko zwieksza to szanse na sprzedaz, ale tez
ulatwia rozwoj. Poza tym jezeli produkt ma szanse sie sprzedawac, to
pieniadze wydane na jego dopracowanie sa dobra inwestycja.

arturbac

unread,
Jan 27, 2010, 2:45:49 PM1/27/10
to
W dniu 2010-01-26 07:36, Jacek Czerwinski pisze:
> arturbac pisze:

>> Ja od paru lat pracuje w metodologi agile - cos podobnego do extreme
>> programing i nie narzekam.
>
> O ile XP to konkretna spisana metodyka, to "agile" jest grupą, kategorią
> metodyk i warto by powiedzieć w której konkretnie.

zdaje sobie sprawe.

> Nie weź tego zbyt osobiście, ale agile to szalenie wygodne hasło,

bo oddaje istote ?

> wszędzie gdzie nie mam żadnej metody(-ki) można powiedziec "bo my
> własnie pracujemy w agile", "pracujemy w metodzie 'podobnej' do XP".
> Jak mówi reklama, "prawie" robi różnicę.

No ale liczy sie cel -> zyje z tego, a nie to jak sie go osiaga i czy
zgodnie z ogolna ideologia dla nas bardziej liczy sie efektywnosc takze.

> Co nie zmienia faktu, że są tacy którzy rzeczywiście używają
> "ukonstytuowanych" XP lub innych konkretnych opisanych metod z grupy
> 'agile', ale te masy naciagające słowa jak z gumy popsuły znaczenie tego
> słowa.

Pracujemy w metodzie "podobnej do XP" wedle wlasnych regol.
Nie bedzie to dokladnie XP ani nic inengo bo team siedzi przed kompami w
EU i nikt nie wnika gdzie akurat jestem, Tricity, Kopenhadze czy Krakowie.
Poza tym pewne reguły są luźne bo nie liczy się u nas czas realizacji
ale perfekcja więc poślizgi w iteracjach są z góry "planowane". Nie
robimy w parach ale pojedynczo. W parach tylko elementy zazebiajace
rozne elementy skladowe. Jak w XP w wiekszosci przypadkow iteracji
rozwiazanie w ogole nie jest znane i dostepne publicznie. Testy nie sa
mozliwe do napsiania tj efektywniejsze jest testowanie interecyjne
produktu jako calosci, kierujac sie kryterium uzytkowym przyszlego
klienta, od tego sa osobni ludzie. Klientem jest rynek i przezycie
produktu ktory na nim jest wiec klient i kontakt z nim jest imitowany
przez nasza kreatywnosc w zakresie kierunkow rozwoju. Specyfikacja
najwazniejszych elementow powstaje, szczegolnie tam gdzie sa trudne do
ponownego wejscia w nie. itd itp.

Czyli : Dostosowanie do produktu, specyfiki pracy i celu naszego
dzialania a nie do metodologi, z reszta moje porownanie do XP jest tylko
porownaniem nikt nigdy miedzy nami tego tak nie nazywal.

Ale czy to oznacza ze moja metodologia pracy nie jest rodem z agile
dlatego że nie staram się trzymać konkretnej nazwanej ?

Jacek Czerwinski

unread,
Jan 27, 2010, 3:05:07 PM1/27/10
to
arturbac pisze:

>
> Ale czy to oznacza ze moja metodologia pracy nie jest rodem z agile
> dlatego że nie staram się trzymać konkretnej nazwanej ?

dzięki za wypowiedź. Osobicie dobrze się czuję, jeśli zasady (choćby
własne, jak w rodzinie) są jawne, dobrze jak spisane, bo jednak spisanie
ma coś z konstytucji.

Zasady są żywe (a nie martwe), jeśli dają siłę by powiedzieć "nie", np.
"ale jak mamy kodować, jak szkielet pakietów (klas, funkcjonalności ...
) nie został okreslony!".

Obrazowo: choćby własne, ale dające się przypiąć pinezką do szafy.

Paweł Kierski

unread,
Jan 27, 2010, 4:22:50 PM1/27/10
to
W dniu 2010-01-26 18:10, crtm81 pisze:

Zgadzam się w ogólności. Chodziło mi raczej o pokazanie, że jest
możliwy taki model, w którym zarabia się niemal wyłącznie na projektach
"w stanie początkowym". I nie chodzi o startupy, które się pisze,
sprzedaje, a nabywca musi je przepisać gdy liczba użytkowników wzrasta
wykładniczo. Komu zależy na jakości kodu i jego procesu wytwórczego
w zabawkach klasy tamagochi?

--
Paweł Kierski
ne...@pkierski.net

Mateusz Ludwin

unread,
Jan 28, 2010, 5:01:57 AM1/28/10
to
crtm81 wrote:

> IT to dosc ryzykowny biznes i takie praktyki sa uzasadnione na poczatku
> projektu, chocby po to, zeby wybadac reakcje potencjalnych klientow.
>
> Ale po jakims czasie, jak aplikacja zaczyna sie rozrastac, wypadaloby
> pomyslec o jakosci. Nie tylko zwieksza to szanse na sprzedaz, ale tez
> ulatwia rozwoj. Poza tym jezeli produkt ma szanse sie sprzedawac, to
> pieniadze wydane na jego dopracowanie sa dobra inwestycja.

Aplikacja w Javie z n-warstwami, wzorcami itd. gdzie dodanie nowej
funkcjonalno�ci trwa tydzie�.

Aplikacja w PHP zawieraj�ca si� w jednym pliku obsranym logik�, SQL-em, CSS-ami
i HTML-em, gdzie dodanie nowej funkcjonalno�ci trwa jeden dzie� d�ubania.

Jak my�lisz, co woli klient biznesowy?
--
Mateusz Ludwin mateuszl [at] gmail [dot] com

Jacek Czerwinski

unread,
Jan 28, 2010, 6:02:21 AM1/28/10
to
Mateusz Ludwin pisze:
> crtm81 wrote:

> Aplikacja w Javie z n-warstwami, wzorcami itd. gdzie dodanie nowej
> funkcjonalno�ci trwa tydzie�.
>
> Aplikacja w PHP zawieraj�ca si� w jednym pliku obsranym logik�, SQL-em,
> CSS-ami i HTML-em, gdzie dodanie nowej funkcjonalno�ci trwa jeden dzie�
> d�ubania.

Dok�adnie tak jest.

Dodaj sobie drug� strone medalu, �e framework w PHP dzi� modny zostanie
zaorany za 2-3 lata (tak oceniam �ycie produkt�w w tym kr�gu). Gdzie
frameworki sprzed 5 lat??????

Zwykle inwestycjom w www (zw�aszcza publiczych stron, nie intranet�w)
najbli�ej do dzia�u marketingu a tam nie ma zwyczaju grania na d�u�szy
dystans. Wr�cz tam modne jest zaoranie co dwa lata z nastaniem nowego
dyr d/s marketingowych, tak jak zmiana kolor�w formowych itd, to w tej
bran�y dobrze �wiadczy o nowej ekipie, jak wyje...e w bloto odpowiednio
wielk� ilo�� z�otych (tzw bud�et marketingu).

Powiedz g�o�no tym niemarketingowym (o zaoraniu co 2 lata) odno�nie
oprogramowania wewn�trznego rzeczywi�cie s�u��cego firmie, ale wcze�niej
zapisz siďż˝ na termin u chirurga.

Tomek Łabuz

unread,
Jan 28, 2010, 7:12:57 AM1/28/10
to
Mateusz Ludwin pisze:

> Aplikacja w Javie z n-warstwami, wzorcami itd. gdzie dodanie nowej
> funkcjonalno�ci trwa tydzie�.
>

znam taki jeden system gdzie dodanie pierdo�y trwa jakie� 2 tygodnie, i
nikt sobie nie wyobra�a tego inaczej zrobionego....


> Aplikacja w PHP zawieraj�ca si� w jednym pliku obsranym logik�, SQL-em,
> CSS-ami i HTML-em, gdzie dodanie nowej funkcjonalno�ci trwa jeden dzie�
> d�ubania.
>
> Jak my�lisz, co woli klient biznesowy?

zale�y jaki klient i jaka to ma by� aplikacja, s� takie co mo�na zaora�
co roku a s� takie co b�d� pracowa� lata, niestety do�� cz�stym b��dem
imho jest branie przyk�adowo javki do wszystkiego co popadnie, bo jest
fajna i wszyscy w niej pisz�, u�ywanie do pobrania dw�ch rekord�w z bazy
tych wszystkich dziwnych skr�t�w typu JPA, ORM a potem zastanawianie si�
czemu to takie pokr�cone jest....
i odwrotnie nie do wszystkiego php b�dzie super
no i tu warto si� z klientem zastanowi�, bo niekt�rzy okazuje si� my�l�
tylko czasem ich wiedza oparta jest tylko o to co przeczytaďż˝ na onecie
albo co s�ysza� od syna s�siada
btw - czy kto� jeszcze pami�ta, �e prost� aplikacj� w javce da si�
napisa� prosto, bez miliona warstw i standard�w i to jeszcze tak, �e da
si� j� p�niej rozwija� :)

Michal Kleczek

unread,
Jan 28, 2010, 7:20:40 AM1/28/10
to
Mateusz Ludwin wrote:

> crtm81 wrote:
>
>> IT to dosc ryzykowny biznes i takie praktyki sa uzasadnione na poczatku
>> projektu, chocby po to, zeby wybadac reakcje potencjalnych klientow.
>>
>> Ale po jakims czasie, jak aplikacja zaczyna sie rozrastac, wypadaloby
>> pomyslec o jakosci. Nie tylko zwieksza to szanse na sprzedaz, ale tez
>> ulatwia rozwoj. Poza tym jezeli produkt ma szanse sie sprzedawac, to
>> pieniadze wydane na jego dopracowanie sa dobra inwestycja.
>
> Aplikacja w Javie z n-warstwami, wzorcami itd. gdzie dodanie nowej

> funkcjonalności trwa tydzień.
>
> Aplikacja w PHP zawierająca się w jednym pliku obsranym logiką, SQL-em,
> CSS-ami i HTML-em, gdzie dodanie nowej funkcjonalności trwa jeden dzień
> dłubania.

I po tym jednym dniu wszyscy szczesliwi wrzucaja nowa wersje na produkcje,
po czym po 3 nastepnych dniach ktos zauwaza, ze z jakiegos powodu spadl
ruch. Sprawdzamy i... co to!!! HTTP 500 w "starej funkcjonalnosci"???
Przeciez mysmy "tylko dodali nowa funkcjonalnosc".

Jak ktos mowi, ze "dodanie nowej funkcjonalnosci" trwa jeden dzien, to ja
odpowiadam - byc moze w "Hello, World" dodanie wykrzyknika po "World".

--
Michal

Mateusz Ludwin

unread,
Jan 28, 2010, 7:30:09 AM1/28/10
to
Michal Kleczek wrote:

> I po tym jednym dniu wszyscy szczesliwi wrzucaja nowa wersje na produkcje,
> po czym po 3 nastepnych dniach ktos zauwaza, ze z jakiegos powodu spadl
> ruch. Sprawdzamy i... co to!!! HTTP 500 w "starej funkcjonalnosci"???
> Przeciez mysmy "tylko dodali nowa funkcjonalnosc".

Nie ma �adnego wrzucania wersji na produkcj�, programista poprawia co� na
kolanie i edytuje plik bezpo�rednio na serwerze produkcyjnym. System kontroli
wersji nie istnieje, jest tylko to co le�y na produkcji.

Co, dziwi ci� to? Ca�y serwis g��wny jednego z operator�w GSM jest zrobiony w
ten spos�b.

> Jak ktos mowi, ze "dodanie nowej funkcjonalnosci" trwa jeden dzien, to ja
> odpowiadam - byc moze w "Hello, World" dodanie wykrzyknika po "World".

Np. dodanie nowego pola w tabelkach i formularzach edycyjnych.

Michal Kleczek

unread,
Jan 29, 2010, 3:45:29 AM1/29/10
to
Mateusz Ludwin wrote:

> Michal Kleczek wrote:
>
>> I po tym jednym dniu wszyscy szczesliwi wrzucaja nowa wersje na
>> produkcje, po czym po 3 nastepnych dniach ktos zauwaza, ze z jakiegos
>> powodu spadl ruch. Sprawdzamy i... co to!!! HTTP 500 w "starej
>> funkcjonalnosci"??? Przeciez mysmy "tylko dodali nowa funkcjonalnosc".
>

> Nie ma żadnego wrzucania wersji na produkcję, programista poprawia coś na
> kolanie i edytuje plik bezpośrednio na serwerze produkcyjnym. System
> kontroli wersji nie istnieje, jest tylko to co leży na produkcji.
>
> Co, dziwi cię to?

Dziwi.

> Cały serwis główny jednego z operatorów GSM jest
> zrobiony w ten sposób.

Wiem.

>
>> Jak ktos mowi, ze "dodanie nowej funkcjonalnosci" trwa jeden dzien, to ja
>> odpowiadam - byc moze w "Hello, World" dodanie wykrzyknika po "World".
>
> Np. dodanie nowego pola w tabelkach i formularzach edycyjnych.

W dowolnym nietrywialnym systemie robienie jakiejkolwiek (nawet
najmniejszej) zmiany w jeden dzien jest proszeniem sie o klopoty.
Dlatego pisalem o "Hello, World".

--
Michal

Mateusz Ludwin

unread,
Jan 29, 2010, 4:26:49 AM1/29/10
to
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.

Przy zachowaniu rygoru projektowego jest to minimum 5 MD.

Wi�c po co biznes ma przep�aca�?

Michal Kleczek

unread,
Jan 29, 2010, 5:04:22 AM1/29/10
to
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.

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

--
Michal

Michal Kleczek

unread,
Jan 29, 2010, 5:07:40 AM1/29/10
to
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?


--
Michal

Mateusz Ludwin

unread,
Jan 29, 2010, 7:05:04 AM1/29/10
to
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. A jak siďż˝ posypie, to siďż˝ poprawi.

Mateusz Ludwin

unread,
Jan 29, 2010, 7:05:46 AM1/29/10
to
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.

jacem

unread,
Jan 29, 2010, 7:20:44 AM1/29/10
to
U�ytkownik "Mateusz Ludwin" <n...@spamuj.org> napisa� w wiadomo�ci
news:hjuiuq$jg5

> Nic siďż˝ nie kumuluje. Robi siďż˝ poprawki na kolanie i biznes jest
> zadowolony.

Do czasu. ;)


Michal Kleczek

unread,
Jan 29, 2010, 7:29:42 AM1/29/10
to
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

Mateusz Ludwin

unread,
Jan 29, 2010, 7:50:03 AM1/29/10
to

To znaczy po ilu latach przestanie byďż˝ zadowolony?

Mateusz Ludwin

unread,
Jan 29, 2010, 7:51:51 AM1/29/10
to
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.

Michal Kleczek

unread,
Jan 29, 2010, 7:56:48 AM1/29/10
to
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

Mateusz Ludwin

unread,
Jan 29, 2010, 9:39:01 AM1/29/10
to
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.

Michal Kleczek

unread,
Jan 29, 2010, 9:44:40 AM1/29/10
to
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

Mateusz Ludwin

unread,
Jan 29, 2010, 10:57:44 AM1/29/10
to
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.

Michal Kleczek

unread,
Jan 29, 2010, 11:27:13 AM1/29/10
to
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

jacem

unread,
Jan 29, 2010, 1:20:33 PM1/29/10
to
U�ytkownik "Mateusz Ludwin" <n...@spamuj.org> napisa� w wiadomo�ci
news:hjulhr$sui$2...@inews.gazeta.pl...

> jacem wrote:
>> U�ytkownik "Mateusz Ludwin" <n...@spamuj.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.

Paweł Kierski

unread,
Jan 29, 2010, 2:48:05 PM1/29/10
to
W dniu 2010-01-29 13:50, Mateusz Ludwin pisze:

> jacem wrote:
>> U�ytkownik "Mateusz Ludwin" <n...@spamuj.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
ne...@pkierski.net

Paweł Kierski

unread,
Jan 29, 2010, 2:56:32 PM1/29/10
to
W dniu 2010-01-29 13:51, Mateusz Ludwin pisze:

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
ne...@pkierski.net

gosmo

unread,
Feb 1, 2010, 3:12:07 AM2/1/10
to
Uzytkownik "crtm81" <wu...@dobra.rada.pl> napisal w wiadomosci
news:hjfj5q$5or$1...@achot.icm.edu.pl...
> Napiszcie jak to wyglada u Was.

Pracujemy razem? :)


gosmo

unread,
Feb 1, 2010, 3:12:47 AM2/1/10
to
U�ytkownik "crtm81" <wu...@dobra.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 ;)

gosmo

unread,
Feb 1, 2010, 3:17:40 AM2/1/10
to
U�ytkownik "jacem" <ja...@10g.pl> napisa� w wiadomo�ci
news:hjfmk3$a21$1...@atlantis.news.neostrada.pl...
> 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 ;)

Mateusz Ludwin

unread,
Feb 1, 2010, 8:03:28 AM2/1/10
to
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

unread,
Feb 1, 2010, 8:04:13 AM2/1/10
to
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?

Paweł Kierski

unread,
Feb 2, 2010, 3:55:08 AM2/2/10
to
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
ne...@pkierski.net

Paweł Kierski

unread,
Feb 2, 2010, 3:58:48 AM2/2/10
to
W dniu 2010-02-01 14:04, Mateusz Ludwin pisze:

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
ne...@pkierski.net

lolo

unread,
Feb 2, 2010, 4:11:31 AM2/2/10
to

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

wyrazi�e� si� za ma�o precyzyjnie ;) - inna szansa, �e Ty (lub
rozm�wca/kilku) trafisz 6-k� a inna, �e padnie w og�le (no i trzeba by
daďż˝ im szansďż˝ i zagraďż˝)

Mateusz Ludwin

unread,
Feb 2, 2010, 5:11:35 AM2/2/10
to
Paweďż˝ Kierski wrote:

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

Ale czy nie rozumiesz �e ja nie jestem po stronie biznesu?

Paweł Kierski

unread,
Feb 2, 2010, 5:33:17 AM2/2/10
to
W dniu 2010-02-02 11:11, Mateusz Ludwin pisze:

Jak na razie widz�, �e prezentujesz pogl�d: Dajmy biznesowi najta�sze
rozwi�zanie, gdzie najta�sze oznacza "najta�sze dzi�", bez ogl�dania
si� na �adne przysz�e koszty, poniewa� biznes jest zadowolony
z najta�szych rozwi�za�.

Je�li si� myl� to mnie skoryguj lub rozszerz.

Osobi�cie jestem za co najmniej poinformowaniem biznesu o ryzyku na
przysz�o��. A jeszcze lepiej - uwzgl�dnieniu r�nych "przypadk�w" na
przysz�o��, cho�by dla w�asnego rozwoju (umiej�tno�ci dopracowanego
projektowania i tworzenia oprogramowania) oraz dba�o�ci o w�asn�
kondycj� psychiczn�. Jako� nie lubi�, jak za tydzie�, miesi�c, czy
kwarta� biznes przychodzi i chce "na wczoraj" zmiany, gdy ca�o�� mam na
sznurku i ta�mie klej�cej. W dobrym projekcie zmiana jest do zrobienia
w normalnym trybie ("na czysto", w tydzieďż˝), a nie "hackeskim", czyli
same hacki, i babranie si� miesi�c z wdro�eniem, bo hacki zawsze co�
dodatkowo popsuj� - cho�by pierwsza wersja produkcyjna by�a w jeden dzie�.

--
Paweďż˝ Kierski
ne...@pkierski.net

Paweł Kierski

unread,
Feb 2, 2010, 5:36:14 AM2/2/10
to
W dniu 2010-02-02 10:11, lolo pisze:

OK - w kontek�cie tego, co omawiali�my, to akurat by�o jasne 8-)

Jak puszczamy produkt do 6 mln u�ytkownik�w, to pad u jednego bywa
wystarczaj�cym problemem. Tu akurat by� z gatunku tych przykrych. Czyli
chodzi�o o sytuacj� "ktokolwiek wygrywa".

--
Paweďż˝ Kierski
ne...@pkierski.net

MoonWolf

unread,
Feb 2, 2010, 6:26:26 AM2/2/10
to
Paweďż˝ Kierski denied rebel lies:

>> Ale czy nie rozumiesz �e ja nie jestem po stronie biznesu?
> Jak na razie widz�, �e prezentujesz pogl�d: Dajmy biznesowi
> najta�sze
> rozwi�zanie, gdzie najta�sze oznacza "najta�sze dzi�", bez ogl�dania
> si� na �adne przysz�e koszty, poniewa� biznes jest zadowolony
> z najta�szych rozwi�za�.
> Je�li si� myl� to mnie skoryguj lub rozszerz.

A mnie si� wydaje, �e Mateusz prezentuje podej�cie (og�lnie
rozumianego) "biznesu": "zr�bcie dzi�, najp�niej na jutro".

Nie, t�umaczenie, �e potrwa to d�u�ej nie jest akceptowalne ("to ja
p�jd� do konkurencji").

> Osobi�cie jestem za co najmniej poinformowaniem biznesu o ryzyku
> na
> przysz�o��. A jeszcze lepiej - uwzgl�dnieniu r�nych "przypadk�w" na
> przysz�o��, cho�by dla w�asnego rozwoju (umiej�tno�ci dopracowanego
> projektowania i tworzenia oprogramowania) oraz dba�o�ci o w�asn�
> kondycj� psychiczn�. Jako� nie lubi�, jak za tydzie�, miesi�c, czy
> kwarta� biznes przychodzi i chce "na wczoraj" zmiany, gdy ca�o�� mam
> na sznurku i ta�mie klej�cej. W dobrym projekcie zmiana jest do
> zrobienia w normalnym trybie ("na czysto", w tydzieďż˝), a nie
> "hackeskim", czyli same hacki, i babranie si� miesi�c z wdro�eniem,
> bo hacki zawsze co� dodatkowo popsuj� - cho�by pierwsza wersja
> produkcyjna by�a w jeden dzie�.

Wszystko to super, ale je�li masz miesi�c na wdro�enie nowego produktu
("bo konkurencja juďż˝ to dawno ma") to czasem nie da siďż˝ inaczej niďż˝
hakersko - przy czym zapomnij o chocia�by analizie wymaga� klienta. A
tak�e do�� sobie ci�g�e zmiany w oryginalnym zamy�le, bo klient, kt�ry
dostaje prototyp wymy�la pi��set zmian (oczywi�cie "na wczoraj"). Przy
czym masz rzecz jasna rozgrzebane funkcjonalno�ci i trzeba je w po�owie
zmienia� na zupe�nie odwrotne.

Projekt *sigh*.

--
<:> Roger, MoonWolf Out <:>|Armageddon is here, like said
(::) (::)|in the past
(:) JID:moon...@jabberpl.org(:)| http://karakkhaz.prv.pl

Wit Jakuczun

unread,
Feb 2, 2010, 6:26:52 AM2/2/10
to
On 2 Lut, 11:33, Paweł Kierski <n...@pkierski.net> wrote:
> W dniu 2010-02-02 11:11, Mateusz Ludwin pisze:
>
> > Pawe Kierski wrote:
>
> >> 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?
>
> > Ale czy nie rozumiesz e ja nie jestem po stronie biznesu?
>
>    Jak na razie widz , e prezentujesz pogl d: Dajmy biznesowi najta sze
> rozwi zanie, gdzie najta sze oznacza "najta sze dzi ", bez ogl dania
> si na adne przysz e koszty, poniewa biznes jest zadowolony
> z najta szych rozwi za .
>
Mateusz pokazuje jak myśli biznes. Nigdy nie napisał, że takie
myślenie jest dobre.
Mi się podoba to co On pisze gdyż pokazuje jak działa rynek IT (i nie
tylko). Wiele osób myśli, że
wystarczy być np. dobrym programistą aby być docenionym przez biznes.
Marcin pokazuje, że
tak nie jest. Potrzebna jest jeszcze wiedza jak dobrze sprzedać
rozwiązanie.

Pozdrawiam,
Wit Jakuczun

Mateusz Ludwin

unread,
Feb 2, 2010, 7:24:41 AM2/2/10
to
Paweďż˝ Kierski wrote:
> W dniu 2010-02-02 11:11, Mateusz Ludwin pisze:
>> Paweďż˝ Kierski wrote:
>>
>>> 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?
>>
>> Ale czy nie rozumiesz �e ja nie jestem po stronie biznesu?
>
> Jak na razie widz�, �e prezentujesz pogl�d: Dajmy biznesowi najta�sze
> rozwi�zanie, gdzie najta�sze oznacza "najta�sze dzi�", bez ogl�dania
> si� na �adne przysz�e koszty, poniewa� biznes jest zadowolony
> z najta�szych rozwi�za�.

Nie, czytaj do skutku ca�y w�tek.

jacem

unread,
Feb 2, 2010, 7:25:30 AM2/2/10
to
U�ytkownik "Wit Jakuczun" <wit.ja...@gmail.com> napisa� w wiadomo�ci
news:c2c8be56-d1d3-

> Wiele os�b my�li, �e
> wystarczy byďż˝ np. dobrym programistďż˝ aby byďż˝ docenionym przez biznes.
> Marcin pokazuje, �e
> tak nie jest. Potrzebna jest jeszcze wiedza jak dobrze sprzedaďż˝
> rozwi�zanie.
> Pozdrawiam,
> Wit Jakuczun

Niestety, dobry programista nigdy nie jest dobrym handlowcem.

Od tego s� "czarodzieje" obiecuj�cy klientowi cuda za p� darmo i na jutro. :)
Klient �yje iluzj�. Cz�sto oczekuje, �e wdro�enie nowych rozwi�za� zlikwiduje
wiele problem�w w jego firmie, �e niejako problemy rozwi��� si� same, dlatego
czeka na nowe jak na wybawienie.

A programi�ci? S� od tego, �eby cuda materializowa�.

p.s.
W�a�nie zaproponowa�em klientowi nowe, moim zdaniem, funkcjonalnie lepsze
rozwi�zanie, ale klient i tak stwierdzi�, �e jest do d...py i wracamy do
starszej wersji :)

Klient p�aci - nasz Pan.

j.

Mikolaj Rydzewski

unread,
Feb 8, 2010, 6:44:47 AM2/8/10
to
jacem wrote:
> W takim razie, po co Wam szef? ;)
>
> We�cie sprawy w swoje r�ce.

Szef im zapewnia prace :-)

0 new messages