Informatyczny światek wprost uwielbia skróty. Jednym z nich jest TTM czyli Time To Market, który to metodyki agile rzekomo obiecują skrócić. Tylko po co?
TTM czyli Time To Market
Time To Market (TTM) to czas od momentu rozpoczęcia prac nad daną rzeczą, aż do jej udostępnienia. Tą rzeczą może być np. nowa funkcjonalność w naszym systemie albo nawet cały produkt czy aplikacja. „Udostępnienie” zaś oznacza moment, w którym staje się ona użyteczna – trafia do sprzedaży czy do zamawiającego.
„Dostarczaj funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.” – Agile Manifesto
Definicja wydaje się być piękna, pożądana i szczególnie w dzisiejszych czasach – przydatna. Czy jednak powinniśmy wykorzystywać w naszej pracy tego typu mierniki?
Do czego TTM?
Wartość naszego wskaźnika TTM jest niezwykle ważną informacją z punktu widzenia m.in. przewagi konkurencyjnej. Ten, kto szybciej dostarcza rzeczy na rynek (ang. to market), ten ma okazję zgarnąć największy kawałek tortu.
Każdy z nas, prowadząc biznes, dąży do dokonania innowacyjnego „odkrycia”. Jednak to nie wystarczy, trzeba je jeszcze udostępnić klientom zanim zrobi to konkurencja.
Czas, o którym mowa, jest też nie do przecenienia kiedy rozważymy nasze dyskusje z klientem na temat istotnych zmian funkcjonalności czy nowych produktów. Z pewnością będzie on dopytywał o szacowany czas wdrożenia.
Nie oszukujmy się, jeśli mówimy o konieczności wdrożenia czegoś nowego na silnie konkurencyjnym rynku, nie ma bardziej istotnej informacji niż to, jak długo nasz klient będzie zmuszony czekać. Szczególnie w dzisiejszym świecie, gdzie zmiany czyhają na nas niemal za każdym rogiem, Time To Market jest miernikiem, który może odpowiedzieć nam na wiele istotnych z punktu widzenia naszego przedsiębiorstwa pytań.
I nie ma tu znaczenia czy mówimy o firmie produkującej zabawki dla niemowląt, drewniane meble, czy o firmie wytwarzającej oprogramowanie. W każdym z powyższych przypadków odpowiedź na pytanie ile czasu zajmie nam udostępnienie „towaru” dla klienta końcowego (licząc od momentu rozpoczęcia prac) jest pytaniem wręcz fundamentalnym.
Miernik Time To Market
Nie ma jednego, ustandaryzowanego i powszechnie wykorzystywanego miernika TTM. Na pewno jednak do wyliczenia Time To Market musimy użyć jednostek czasu, np. dni. Bardziej istotne od jednostki miary są jednak definicje startu i zakończenia naszego działania.
Nie od dziś wiemy, że ludzki umysł ma tendencję do dopasowywania odpowiedzi do kontekstu i osoby, której informacja będzie udzielana. Jeśli zależeć nam będzie na podaniu jak najdłuższego czasu, naszym początkiem prac będzie wczesna incepcja, kiedy to dowiadujemy się o konieczności wykonania jakiegoś zadania i zabieramy się za pierwsze prace analityczne. Możemy w ten sposób uargumentować chociażby wysokość nakładów inwestycyjnych na realizowane przedsięwzięcie.
Jeśli zależeć nam będzie na podaniu jak najkrótszego czasu, najprawdopodobniej weźmiemy pod uwagę okres od rozpoczęcia dewelopmentu, aż do jego zakończenia. Nie uwzględniając finalnych testów i samego wdrożenia będziemy jednak ponosić ryzyko związane z jakością.
Nie oznacza to jednak, że to ryzyko na pewno się zmaterializuje, ale warto zastanowić się czy oprogramowanie działające na serwerach testowych rzeczywiście możemy określić jako spełniające warunek „to market„.
Są dziedziny, w których nie możemy nagiąć rzeczywistości i wartość wskaźnika jest stała. Należą do nich chociażby rolnictwo, gdzie na plony musimy poczekać zgodnie z przyjętym przez Matkę Naturę harmonogramem, a także np. wypiek pieczywa. Są również takie miejsca, gdzie proces wytwórczy jest bardzo zróżnicowany i niedeterministyczny. Do tych ostatnich należy na pewno wytwarzanie oprogramowania.
Jak poprawić TTM?
W filmie na YouTube pod tytułem „Wdrożenie raz w roku” zastanawiamy się czy można w ogóle mówić o podejściu zwinnym, jeżeli mamy nieregularne, rzadkie wdrożenia. Czy przypadkiem nie tracimy wtedy większości korzyści płynących z agile’owego procesu wytwórczego?
Ale problemem bywają nie tylko wdrożenia. Jeżeli wszystkie świetne pomysły i inicjatywy najpierw są opiniowane przez „ekspertów”, a potem trafiają na spotkania zarządu, a potem przygotowywane i wdrażane są w ramach jednego Sprintu, to jak na dłoni widać, gdzie możemy zyskać najwięcej. Nie skracając dewelopment z dwóch tygodni do jednego, ale optymalizując długi proces opiniowania.
Czasami będzie odwrotnie – wszystkie pomysły szybko dostają zielone światło, ale potem utykają w dewelopmencie na miesiące. Z kolei w innej organizacji może się zdarzyć, że wszystko przebiega sprawnie, ale brak procesów Continuous Delivery powoduje, że gotowy inkrement leży odłogiem miesiącami.
Jeżeli chcemy poprawić nasz Time To Market, to najpierw zidentyfikujmy który etap od pomysłu do wdrożenia zajmuje nam najwięcej czasu. Jak mówi Zasada Pareto, większość opóźnień będzie pochodziła z jednego-dwóch etapów procesu. A jak mówi nasze doświadczenie, zwykle nie będzie to dewelopment.
A co z jakością?
Częstym zarzutem dążenia do minimalizacji wartości TTM jest niska jakość wytwarzanego oprogramowania. Argument ten znamy już chociażby z krytyki innego trzyliterowego skrótu – MVP.
Produkt wytwarzany w pośpiechu może posiadać wady. Często mówi się o „chorobach wieku dziecięcego”, szczególnie w kontekście rozwiązań technologicznych. Ujawniają się one tuż po trafieniu produktu na rynek i są spowodowane niedostatecznym zwróceniem uwagi na jakość w trakcie procesu wytwórczego.
Mam przekonanie, że to od nas samych zależy, jaka będzie jakość wytwarzanego produktu. Zastosowanie w jego produkcji chociażby metodyk zwinnych może przynieść „skutek uboczny” w postaci wysokiej jakości produktu. Przecież po każdym Sprincie przyrost musi być gotowy do potencjalnego wydania na środowisko produkcyjne.
To sugeruje, że w przypadku Scruma Time To Market wynosi dokładnie długość Sprintu. Jest to prawdą jedynie dla prostych wymagań, bo duże funkcjonalności i tak są rozbijane na wiele zadań wykonywanych w kilku kolejnych Sprintach. Co więcej, TTM powinien być liczony od momentu trafienia wymagania do Product Backlogu, a nie od początku dewelopmentu. Na koniec – to, że Inkrement jest gotowy do wdrożenia co Sprint, to nie znaczy, że te wdrożenie faktycznie następuje.
Pamiętajmy też, że jeśli chcemy podążać w stronę superszybkiego dewelopmentu i poddać się presji biznesu co do maksymalnego skrócenia wartości TTM, to oczywiście odbije się to na jakości. Inaczej być nie może. Ale z drugiej strony, wiele tu zależy od nas samych. Wcale nie musimy się decydować na pogoń za jak najkrótszym Time To Market.
Bo przecież wystarczy go optymalizować, a nie minimalizować.
