W dniu 2010-01-26 18:10, crtm81 pisze:
> 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.

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
n...@p...net