RegułyChaosu

Pracuję teraz w bardzo ciekawym projekcie, którego podstawą jest wykorzystanie najbardziej zaawansowanych metod wnioskowania statystycznego do sterowania cenami (Revenue Management, Dynamic Pricing). Rozwiązania informatyczne wykorzystywane w tym przedsięwzięciu to wysoka półka, ale ciekawsze są wnioski dotyczące zrozumienia siły i zasięgu ich stosowania.

W ramach podsumowania mini cyklu o Agile BI, kilka myśli dotyczących praktyki stosowania podejścia agile do projektów BI.

W projektach informatycznych realizowanych w trybie agile wykorzystywane są praktyki pozwalające na skuteczną realizację takich projektów. Pośród praktyk, które mają „najwyższe notowania” występuje TDD (Test-Driven Development). Czy w projektach BI także można stosować taką praktykę?

W praktyce projektów realizowanych w trybie agile podstawą dla zarządzania zakresem projektu jest backlog. Ta sama zasada powinna obowiązywać także w przypadku projektów BI realizowanych w tym samym trybie. Jak sformułować backlog projektu agile BI, aby nadawał się on do zarządzania zakresem takiego projektu?

Odpowiedź w wersji „streszczenia dla kierownictwa”: oczywiście, że tak i daje się tak działać. W tradycyjnej typologii projektów IT, projekty BI (Business Intelligence) postrzegane są jako „ciężkie” – dużo analiz, dużo programowania, dużo infrastruktury, zanim zbudowana będzie „wartość biznesowa”, którą można się już pochwalić. Wszystkie te lematy są już bardzo wiekowe i – w dzisiejszych czasach – często nie są prawdziwe.

W dzieciństwie słyszałem, że żadna praca nie hańbi – każda męczy. Później, już w dorosłym życiu, uzupełniłem, że każda praca stresuje, choć w różnym stopniu. Bagaż doświadczenia konsultanta pozwala mi także twierdzić, że taki „zawód” dodatkowo może być mocno frustrujący. Co z tym zrobić?

Od pewnego czasu nawet w tzw. mainstreamowych publikacjach na temat IT pojawiają się wypowiedzi sugerujące, że czasy opłacalności budowy systemów na miarę minęły bezpowrotnie. Dzisiaj to wykorzystanie istniejących rozwiązań tworzy przewagę konkurencyjną, nie zaś budowa „doskonale dopasowanych do potrzeb” systemów. Kilka lat temu krytyczna publikacja “IT Doesn’t Matter” (Nicholas G. Carr) wzbudziła „święte oburzenie” i wywołała długą dyskusję. Po kilku latach wygląda jednak na to, że miał on rację.

To zdanie, jakie słyszę od szefów projektów IT, jest bez wątpienia prawdą. Sprzęt to jedyny komponent stosu technologii informatycznej, który musi być fizycznie dostarczony. Na to potrzeba czasu, choć nie sam czas dostawy (Lead Time) jest tu decydujący – najpierw ktoś go musi kupić. Pomijając sztuczki i triki zakupowe, sprzęt jest zwykle zamawiany na początku projektu i sporo czasu upłynie, zanim zacznie być wykorzystywany w stopniu zamierzonym. Tak, zakupy sprzętu zwykle zabierają tyle czasu.