W dniu poniedziałek, 15 października 2012 23:59:13 UTC+2 użytkownik Andrzej Jarzabek
napisał:
> Tylko że opłacalność tego potrafi też działać w drugą stronę - firma
> sprzedała program w jakiejś tam wersji, klienci chcą następnej wersji i
> nawet są skłonni zapłacić dużą kasę, ale z powodu niedobrych praktyk
> rozwijanie kolejnych wersji staje się coraz droższe, a co za tym idzie
> coraz mniej opłacalne.
Można się tylko zgodzić.

> Albo jeszcze gorzej: program którego zrobienie kosztowało dwa miliony
> został sprzedany za cztery, tylko że się okazuje, że w programie jest
> sporo bugów, które producent musi zapatchować za darmo, i patchowanie w
> końcu kosztuje kolejne trzy miliony.
Najwyraźniej my to wiemy.

> Poważnie jednak - to jest absolutnie normalne, że funkcjonalność
> programu jest rozbudowywana w ten sposób. Tak się robi, na tym się
> zarabia, i porządnie zrobione jest to obopólnie korzystne dla
> zamawiającego, jak i dla producenta. Chodzi jednak o to, że porządne
> zrobienie tego nie oznacza dopuszczenia do sieczki, a nawet jak już się
> sieczka gdzieniegdzie zrobi, to da się ją posprzątać. Powiesz, że
> klienta nie interesuje, czy jest sieczka, czy nie. Ale czy nie
> interesuje go również, czy zaimplementowanie kolejnego wymagania zajmie
> dwa tygodnie, czy - z powodu sieczki - dziesięć? Czy nie interesuje go
> ile razy na miesiąć system będzie padał i jaki będzie miał downtime?
Raczej powiem że w praktyce nie potrafię albo przepchnąć takiej argumentacji,
pomimo że moim zdaniem też jest oczywista, albo w praktyce zrobienie dobrego
projektu jest w ogóle trudne do osiągnięcia. Chodzi mi o taką praktykę...
jakby to zgrabnie określić, może... całą praktykę biznesową, nie tylko
programistyczną.
Nie potrafię przepchnąć takiej argumentacji w najróżniejszych okolicznościach. A to w

rozmowie z kolegą z zespołu ciężko, bo zaraz rozmowa przyjmie taki ton, że
uważam iż on zrobił sieczkę a nie porządny kod. Gdy poczuje zagrożenie z mojej
strony, to strach się bać co mi za plecami odwinie. Z managementem ciężko, bo
łatwo górę bierze chciwość i zaoszczędzenie odrobiny czasu. Z klientem to już w
ogóle najtrudniej, bo klient nie dysponuje odpowiednią wiedzą, a często chce
narzucać pewne rzeczy. Kolejna sprawa to wypada operować konkretami. Trzeba
podać jakie rozbudowy, o ile przyspieszą późniejszy czas wykonania, itd. Nie
da się przecież tak zaprojektować programu, żeby zupełnie każda modyfikacja była w
przyszłości łatwa. Z kolei żeby operować konkretami to trzeba dobrze znać dziedzinę,
ale
nawet jak się zna dziedzinę to jest trudno oszacować czas i próg opłacalności.
W mojej praktyce nigdy większego projektu nie robiłem dla dziedziny o której
na starcie miałem pojęcie. Zawsze musiałem douczyć się na szybko. Właściwie to
nie wiedziałem nawet co w ogóle może być użyteczne w systemie i jakie rozbudowy
zaproponować. W takich warunkach musiałem oszacować czas, cenę i, co tu dużo mówić,
odgadnąć jaki projekt będzie najlepszy. Nie można bez dobrej znajomości dziedziny
zrobić
dobrego projektu, można go co najwyżej odgadnąć. Kolejny problem jest taki, że krótko
po
rozpoczęciu chcą zobaczyć jakiś prototyp, tak jakby dla pewności że prace w
ogóle trwają. Prototyp wprost z definicji da się wykonać na skróty. Chociażby
można go zrobić bez uprzedniego przemyślenia jak będzie testowany, ale jest
więcej pułapek. Potem przy przechodzeniu z prototypu do pełnej wersji może nagle
się okazać, że program będzie bardzo trudny w testowaniu.

We wszystko powyższe czasami wplata się problem wydajnościowy, a kod
po zoptymalizowaniu to już masakra w utrzymaniu.

Aktualnie borykam się z właśnie z tego typu problemem - projekt który był dobry na
potrzeby prototypu, okazał się kiepski dla pełnej wersji.


Pozdrawiam
P.S.
Czy widac polskie znaki?