Stworzyliśmy produkt wewnątrz korporacji. Nietypowa historia produktu IT
Swoboda i dowolność – słowa, które dość rzadko kojarzymy z pracą IT w korporacji. Gdy myślimy o projektach informatycznych w dużych organizacjach do głowy przychodzą nam raczej ograniczenia, regulacje, rozwiązania legacy i tym podobne. Może być jednak inaczej. Zapraszam na opowieść o tym, jak poprzez stworzenie i rozwój produktu IT udało nam się osiągnąć autonomię w ramach rozbudowanej korporacji.
Tomasz Bondaruk. Senior Software Developer w Robert Bosch, wcześniej konsultant wdrożeń IT. W swojej pracy przeszedł i dotknął wszystkich aspektów tworzenia systemów, od zbierania wymagań, poprzez definicję architektury, implementację aż po testy z klientami (czasem bardzo nerwowymi i trzaskającymi drzwiami). Interesuje go wiele obszarów pracy w IT, nie tylko programowanie czy testowanie ale również kierowanie projektami oraz UX. W swojej pracy zawsze kieruje się dobrem klienta. Prywatnie mąż, ojciec, fan piłki nożnej, akwarystyki oraz robienia domowych nalewek owocowych.
Spis treści
Czym jest produkt IT?
Odpowiedź na to pytanie jest niejednoznaczna. Produktem IT najczęściej nazywamy gotowe rozwiązania, które możemy wziąć “z półki” i zainstalować na swoim komputerze/serwerze, możliwe że wymagające konfiguracji. Istnieje jednak inna możliwość. W Robert Bosch stworzyliśmy produkt, który nie jest czarną skrzynką gotową do instalacji a zestawem narzędzi, z których jesteśmy w stanie zrealizować poszczególne projekty implementacyjne.
Nasze narzędzie nosi nazwę CDP – Cognitive Data Processor i skupia się na automatyzacji procesów. Oferujemy możliwości kognitywnej analizy dokumentów i automatyzację ich przetwarzania. Chcemy, aby dzięki naszemu rozwiązaniu firma zrobiła krok w kierunku organizacji w pełni cyfrowej i zautomatyzowanej.
Narodziny idei
Pomysł na Cognitive Data Processor narodził się przypadkiem. Pewnego dnia do naszej jednostki zwrócił się przedstawiciel jednego z biznesów Bosch, abyśmy wsparli go w implementacji pewnego pomysłu. Chodziło o narzędzie do automatycznej klasyfikacji oraz przeszukiwania treści dokumentów zakupowych. Problem polegał na ogromnej liczbie plików, które nie były skategoryzowane, opisane i wymagały ręcznego opracowania.
W trakcie implementacji zrozumieliśmy, jak bardzo ogólny jest problem, który rozwiązujemy i jak wiele obszarów mogłoby czerpać korzyści z rozwiązania, które pozwala na automatyzację przetwarzania dokumentów. Zaproponowaliśmy więc “przejęcie” pomysłu oraz dalszy jego rozwój. I tak zespół składający się wyłącznie z programistów zajął się wdrażaniem innowacji.
Chcieliśmy dokonać uogólnienia zbudowanego rozwiązania, tak aby było na tyle elastyczne, że mogłoby dostosować się do dowolnego problemu. W tak różnorodnej korporacji jaką jest Robert Bosch potencjał rozwojowy takiego narzędzia wydawał się bardzo duży, jednak droga od pomysłu do dojrzałego produktu okazała się kręta i wyboista.
Trudne początki
Paradoksalnie, pierwszym co zrobiliśmy na drodze stworzenia produktu, nie był wcale nowy projekt w InteliJ czy innym środowisku programistycznym, a prezentacja w PowerPoint, a właściwie bardzo wiele prezentacji…
W każdej dużej organizacji innowacyjne produkty powstają na jeden z dwóch sposobów:
- zespół otrzymuje finansowanie na stworzenie gotowego narzędzia (np. z centralnego budżetu przeznaczonego na innowacje), które następnie będzie oferowane do użycia dla zewnętrznych lub wewnętrznych klientów,
- zespół nie otrzymuje finansowania a musi samodzielnie je zorganizować poprzez projekty implementacyjne i poprzez nie rozwijać swój pomysł.
W naszym przypadku działaliśmy bez centralnego wsparcia finansowego, wybraliśmy więc drugą z przedstawionych ścieżek, czyli drogę organicznego wzrostu, w którym nasz produkt będzie rozwijany wraz z kolejnymi wdrożeniami. Takie podejście ma wiele niepodważalnych zalet.
Przede wszystkim pozwala na rozwój produktu bazując na oczekiwaniach i potrzebach użytkowników. Nie budujemy czegoś, co wydaje nam się, że będzie potrzebne, a rozwiązujemy konkretne problemy, które istnieją wewnątrz organizacji.
Z drugiej strony jest to droga, która wymaga znalezienia klientów, gotowych na zainwestowanie w rozwiązanie, które jest na wczesnym etapie rozwoju. Zmusza nas do działania wielotorowego, a nie jedynie skupieniu się jedynie na implementacji.
Aby znaleźć pierwszego klienta rozpoczęliśmy zakrojoną na szeroką skalę akcję marketingową. Chcieliśmy dotrzeć do możliwie największej liczby działów, grup tak, aby zgodnie z zasadami statystyki, ktoś nam zaufał i podzielił się budżetem. Pamiętam, że w tym okresie były dni, w których miałem po trzy prezentacje dziennie, ponieważ staraliśmy się uruchomić możliwie najwięcej kanałów komunikacyjnych i wykorzystać wszystkie znajomości naszych przełożonych. Przy okazji zaobserwowaliśmy ciekawy fenomen psychologiczny.
Otóż większość ludzi jest chętna korzystać z innowacyjnych produktów i rozwiązań, ale bardzo niewielka część jest gotowa w nie zainwestować. Jednym z najczęstszych pytań, które było nam zadawane wtedy, jak również teraz, jest to o inne implementacje oraz wdrożenia. Dlatego, znalezienie pierwszego klienta było kluczowym krokiem nie tylko w kierunku stworzenia rozwiązania, ale również znajdowania kolejnych klientów.
Pierwsze koty za płoty
Po niezliczonej liczbie prezentacji oraz spotkań, które odbyliśmy udało nam się przekonać do siebie jeden z działów podatkowych. Mieliśmy nieco szczęścia, ponieważ była to komórka odpowiedzialna za wdrażanie innowacji, której do końca roku zostało nieco niewykorzystanego budżetu. Szczęściu jednak należy dopomagać i gdybyśmy się z nimi nie kontaktowali kilkukrotnie, to budżet otrzymałby pewnie inny projekt. Uradowani przystąpiliśmy do implementacji naszego pierwszego własnego projektu.
Jak pamiętacie, nasz zespół składa się z programistów z krwi i kości. Jako mały zespół nie mogliśmy sobie pozwolić na zakontraktowanie wielu osób, więc zajęliśmy się wszystkimi aspektami projektu własnymi siłami. Nie mogliśmy się skupić tylko na programowaniu, do naszych obowiązków należało również prowadzenie projektu, komunikacja z klientem oraz wszelkie formalne aspekty aktywności. To była dla nas nowość, do której nie podeszliśmy początkowo entuzjastycznie. Ale dzięki temu zdobyliśmy wiele nowych doświadczeń i spojrzeliśmy na projekt ze znacznie szerszej niż dotychczas perspektywy. Zrozumieliśmy, ile formalnych aspektów należy brać pod uwagę, ile obszarów musi być zweryfikowanych zanim projekt uzyska akceptację startu.
Przez cały czas przed oczami mieliśmy cel, czyli stworzenie elastycznego i adaptowalnego produktu. Dlatego też, już podczas pierwszego wdrożenia, budowaliśmy to rozwiązanie w sposób możliwie najbardziej ogólny. Zdecydowaliśmy się na architekturę mikroserwisów, aby móc potem łatwo rozszerzać i zmieniać nasze rozwiązanie.
Budowa marki
Po zakończeniu pierwszego projektu z sukcesem byliśmy pewni, że kolejne przyjdą nam znacznie łatwiej i sprawniej, zważywszy na to, że mogliśmy się już pochwalić dokonanym wdrożeniem. Rzeczywistość, niestety, zweryfikowała nasze plany. Mimo wielu spotkań i prezentacji nie udało się zakontraktować kolejnych projektów. Wszystkie osoby, z którymi rozmawialiśmy bardzo nas chwaliły i zgodnie twierdziły, że pomysł ma potencjał, niestety nie szły za tym inwestycje oraz kolejne wdrożenia. Nasz projekt został odłożony “na kiedyś”, a my wróciliśmy do swoich codziennych zadań.
Trudno było się nam pogodzić z tym, że to byłby koniec Cognitive Data Processor. Wiedzieliśmy, że wciąż w organizacji jest duże zapotrzebowanie na to rozwiązanie. W trakcie prac nad innymi projektami ponownie uruchomiliśmy wewnętrzny marketing. Okazuje się, że w dużych organizacjach istnieje wiele kanałów na reklamowanie rozwiązań i informowanie innych działów o swoich produktach.
Pierwszym krokiem było zaprezentowanie się wewnętrznemu zespołowi konsultantów biznesowych. Mają oni na celu powiązanie biznesu z IT. Po prezentacji naszego produktu dostaliśmy wiele nowych potencjalnych kontaktów. Udało się nam również dostać na kilka wewnętrznych konferencji, na których mogliśmy się zaprezentować. Wraz z tym jak rosła nasza sieć kontaktów, rosły nasze nadzieje na dalszy rozwój produktu.
Kolejne kroki
Wzmożone działania przyniosły swój efekt. “Nalot dywanowy” – jak nazwaliśmy naszą akcję promocyjną – poskutkował zakontraktowanym trzech kolejnych projektów. Po raz pierwszy stanęliśmy przed sytuacją, w której zapotrzebowanie na nasze usługi jest większe niż możliwości dostarczenia – nasz produkt stał się dojrzały.
Nie oznacza to bynajmniej końca naszej drogi. Kolejnymi krokami jakie chcemy postawić jest zapewnienie sobie ciągłego strumienia nowych zamówień oraz klientów, jak również zbudowanie stabilnej grupy projektów, które będziemy wspierać już po go-life. Zapewni to przewidywalność i ciągłość pracy zespołu.
W dalekiej perspektywie widzimy przekształcenie naszego produktu w platformę do automatyzacji, w której klient może samodzielnie “wyklikać” sobie swój proces i otrzymać gotowe rozwiązanie w sposób całkowicie automatyczny. Będzie to jednak materiał na całkowicie osobną opowieść…
Morał
W tej historii było wiele punktów zwrotnych, które mogły zupełnie zmienić bieg wydarzeń. Ja widzę tutaj trzy krytyczne decyzje, które pozwoliły na szczęśliwe zakończenie:
-
- Dobra diagnoza potrzeb, które pozwoliło trafnie oszacować szanse projektu,
- Działania poziome, a nie pionowe – zamiast skierować projekt do osób wysoko umiejscowionych w hierarchii działu IT, szukaliśmy partnerów wśród osób na podobnych stanowiskach w innych działach,
- Gotowość do przyjmowania różnych ról, co pozwoliło na tani i szybki rozwój projektu,
- Bliska współpraca z klientami, dzięki której nasz projekt odpowiada na ich realne potrzeby.
Nawet w dużych organizacjach jeden zespół programistyczny może wiele zdziałać! Przy tej okazji chciałbym bardzo serdecznie podziękować całemu zespołowi zaangażowanemu w sukces naszego przedsięwzięcia jak również kierownictwu, które nieustannie nas wspierało!
Zdjęcie główne artykułu pochodzi z unsplash.com.