"Time to market" vs. "life cycle cost" czyli dług projektowy: kiedy i jak go zaciągać i czym są efemerydy.

Jarosław Żeliński – analityk biznesowy, projektant systemów

O prelegencie…

Od 1991 roku w branży IT i zarządzania Od 1998 – 2004 jako doradca w kilku spółkach akcyjnych Od 2004 roku jako niezależny ekspert i analityk Dziesiątki publikacji w prasie branżowej IT i gospodarczej Członek stowarzyszenia doradców gospodarczych Wykładowca katedry systemów informacyjnych wydziału przedsiębiorczości akademii

morskiej w Gdyni Kilkudziesięciu odbiorców usług doradczych, małe, średnie i duże firmy zarówno

informatyczne jak i ich klienci. Poświadczenie bezpieczeństwa wydane przez ABW Były ekspert przy gabinecie komisji nadzoru finansowego Współpracownik Wyższej Szkoły Informatyki Stosowanej i Zarządzania pod auspicjami

Polskiej Akademii Nauk

Agenda

• 1. dwa słowa o "Time to market"

2. dwa słowa o "life cycle cost"

3. dwa słowa o długu

4. dwa słowa o efemerydach

5. strategia tworzenia oprogramowania czyli polityka i reguły tworzenia projektów wysokiej jakości

dwa słowa o "Time to market"„Time to market” definiowane jest jako „okres od

momentu powstania konceptu produktu aż do wprowadzenia go na rynek”.

(źr. http://www.corpdevpar.com/stm_comp_edge.htm)

dwa słowa o "life cycle cost"Cykl życia produktu to szersze od time to market

pojęcie. Kolejna faza życia produktu to jego obecność na rynku od momentu pojawienia się (od zakończenia fazy time to market) do momentu wycofania z rynku.

Czas trwania tego okresu bardzo zależy od specyfiki produktu i jego roli na rynku (samochody dziesiątki lat, produkty finansowe nawet tylko kilka miesięcy).

dwa słowa o długu

Jednym z istotnych kosztów tak zwanego utrzymania oprogramowania jest jego aktualizacja i rozwój. Dług technologiczny to coś o czym mało się pisze i mówi, a prawie każdy się z nim boryka.

dwa słowa o efemerydach

Skoro jedne produkty żyją na rynku kwartał a inne np. pół wieku, warto się zastanowić nad podejściem do ich tworzenia, szczególnie kosztem wytworzenia.

Dobra architektura jest kosztowna, czy zawsze więc warto poświęcać jej dużo czasu i środków? Nie.

To jest kompromis, gdyż dobra architektura to czas i pieniądze, może na to nie być czasu w fazie time to market (wyścigi z konkurencją).

Z drugiej strony każde uproszczenie, każda droga na skróty, to praktycznie zawsze zaciąganie długu technologicznego. W efekcie może się okazać, że warto zbudować rozwiązanie „na już” i później zamiast je dalej rozwijać (co z uwagi na dług technologiczny może być bardzo kosztowne) po prostu się je wyrzuca, i jeżeli cykl życia produktu nadal trwa, tworzy nowe.

Takie produkty, z góry planowane do wyrzucenia to efemerydy.

strategia tworzenia oprogramowania czyli polityka i reguły tworzenia projektów wysokiej jakości

Widać więc, że bardzo potrzebne są firmom strategie rynkowe i taktyki (lub polityki) podejścia do zarządzania ofertą.

Decyzje kiedy tworzyć produkt na lata a kiedy efemerydę nie są bowiem łatwe i dobrze jest gdy opisuje to strategia firmy i polityka tworzenia oprogramowania.

Takie dokumenty powinny istnieć w każdej firmie.

Modelowanie strategii i analiza

Open Close principia w architekturze„Otwarta na rozszerzenia, zamknięta na zmiany”

Strategia

Proces biznesowy

Wymagania

Architektura

Podsumowanie

Analiza organizacji jest kosztownaProjektowa to także kosztowny procesKoszty utrzymania produktu ściśle zależą od jego

architektury:Zła architektura jest kosztowna w utrzymaniuDobra architektura jest kosztowna w wytworzeniu

Dlatego najważniejszą decyzją na początku jest strategia produktu: efemeryda czy nie…

Jakość na etapie …

- wymagania

- analiza i projektowanie

- kodowanie

- testowanie

- wdrożenie

Architektura OCP

Koszt wprowadzenia zmiany

Kosz rozszerzenia funkcjonalności

Architektura ???

Dziękuję za uwagę!

Jarosław Żeliński – Analityk Biznesowyj.zelinski@it-consulting.plhttp://IT-Consulting.plGSM: 0-608 05 90 20