Jak rozpoznać to w zespole? Od czego najlepiej zacząć? Najpierw warto dokładnie omówić to z potencjalnym partnerem. W jakim stopniu chce on zapoznać się z problemem, wyzwaniami oraz dotychczasowymi odkryciami? Czy interesuje go dlaczego i dla kogo budujemy nasz produkt. Jakie wnioski nasuwają mu się na wstępie? Jeśli zespół zewnętrzny uchyla się przed odpowiedzią albo twierdzi, że nowy produkt zupełnie go nie interesuje (uwierzcie, zdarzają się jeszcze takie przypadki!) bądź jego członkowie chcą się skupić wyłącznie na technologii, to zły sygnał. Oznacza to, że wybraliśmy nieodpowiednie osoby do współpracy.

Ważna jest kultura pracy

Ludzie, którzy mają z nami pracować nad czymś innowacyjnym (nie mówię tu o „innowacyjnym” UX, ale o nowym produkcie bądź usłudze redefiniującej rynek bądź mocno nim wstrząsającym, czyli o przełomowych innowacjach), muszą w pewnym sensie żyć tym wyzwaniem od pierwszego momentu. I nie chodzi tu o sam początkowy błysk w oczach tych, którzy za chwilę mają to produkować.

Chodzi o pewną proaktywność, motywację do dalszej pracy widoczną gołym okiem. O intensywne wejście w prace analityczne nawet na etapie przygotowywania oferty, szybkie przyswajanie i dużą potrzebę wiedzy na temat założeń oraz konstruktywne propozycje zastosowania metodyk, narzędzi i technik pracy.

Odpowiedni dobór tych aspektów jest niezwykle ważny dla zespołu czekającego na zadania, bez względu na osobiste preferencje jego członków, itd. Od partnera technologicznego warto także oczekiwać podpowiedzi jak zorganizować pracę w tym ciągłym iteracyjnym procesie, który powinien towarzyszyć powstawaniu innowacji. Ale też wskazówek gdzie warto stworzyć repozytorium zdobytej wiedzy w trakcie pracy i jak wizualizować tę pracę w samym procesie wytwórczym. Jak widać – dobry partner technologiczny nie dostarcza wyłącznie samej technologii.

Ten duch zespołowej pracy badawczej, rozwojowej, badawczo-rozwojowej lub najczęściej

produkcyjnej, powinien wyrastać z przekonania, że tym, co steruje każdym wysiłkiem zespołu jest wartość, którą dany team ma dostarczyć. Wartość oczywiście bezpośrednio implikująca to czy dany produkt bądź usługa będzie innowacyjna. Nie znaczy to, że w innych projektach ta wartość ma nie występować. Po prostu, jeśli ma powstać innowacja – potrzebni są najlepsi, najbardziej zmotywowani ludzie będący w stanie wnieść duży potencjał umysłowy w pracę, w proces twórczy. Należy również wziąć pod uwagę fakt, iż produkt czy usługa powstają w warunkach dużej niepewności. Właściciel produktu stawia hipotezy – część z nich nie zostanie potwierdzona, a z niektórymi pomysłami trzeba będzie się rozstać w kolejnej fazie, nawet jeśli ich realizacja była najwspanialszą przygodą programistyczną ever. Podsumowując: partner technologiczny musi dać od siebie powiedzmy 10%. Czyli to, co powstanie przy jego udziale – powinno być zrobione na 110%. I nie chodzi tu o zakres, tylko o jakość, wartość tego, co powstało.

Na etapie wyboru warto zapytać więc samego partnera, a potem nawet jego byłych/obecnych Klientów o przykłady takich innowacyjnych prac czy przełomowych wdrożeń. Dlaczego? Po pierwsze, by to potwierdzili, a po drugie – podkreślili, co rzeczywiście wniósł zespół zewnętrzny, co było jego zasługą, wartością dodaną, pomysłem bądź koncepcją, która nie powstałaby, gdyby nie pojawił się ten konkretny partner.

Proxy Product Owner – czy jest potrzebny?

Po stronie partnera, dostawcy technologii przydałby się także Product Owner, który posiada wiedzę dziedzinową i zna domenę, której dotyka innowacja. Oczywiście to nie jest warunek konieczny, ale takie wsparcie dla Product Ownera w postaci jego nie tyle odpowiednika, co uzupełnienia po stronie dostawcy – może być bardzo przydatne w momencie, gdy właścicielowi produktu brakuje chwilowo energii, pomysłów, a niekiedy też czasu.

Są też i wady takiego podejścia. Dwóch „właścicieli” produktu może się zbytnio challengować czy spierać o wizję produktu. Nie zmienia to jednak faktu, że lepszą opcją jest to, gdy odrębne wizje ścierają się czy choćby tylko konfrontują na tym etapie niż gdyby, mając taki potencjał pod ręką – nie wykorzystać go, idąc w jedyną słuszną stronę. “Uzupełniający” Product Owner to dodatkowa perspektywa, dodatkowe kompetencje i … dodatkowe ręce do pracy dla właściwego właściciela produktu.

Dlatego namawiam gorąco do korzystania z tej opcji i pytania potencjalnego partnera o możliwość „zatrudnienia” także Proxy Product Ownera. Puryści agile’owi zaraz mi zarzucą, że Product Owner powinien być jeden. I ja się z tym absolutnie zgadzam – w układzie Product Owner – zespół zewnętrzny z Proxy Product Ownerem wciąż jest jeden człowiek, który finalnie podejmuje decyzje i wyznacza kierunek rozwoju produktu, bierze za niego pełną odpowiedzialność. Pod warunkiem rzecz jasna, że posiada pewną autonomię.

Proxy product Owner ma mu tylko w tym pomóc, wspierać, a kiedy trzeba (dla dobra produktu) być adwokatem diabła. Proxy Product Owner może też dużo wnieść, jeśli chodzi o zwrócenie uwagi zespołu na najlepsze praktyki, usługi konkurencji, ciekawe choć alternatywne sposoby rozwiązania tego samego problemu na innych rynkach lub nawet na rodzimym rynku, wypracować przewagę konkurencyjną. Może też pomóc nam lepiej zdefiniować wizję produktu: czyli czym chcemy być dla naszych użytkowników. Jeśli to człowiek doświadczony – czerpmy zatem z zasobów jego wiedzy, doświadczeń i traktujmy go jako eksperta w naszym zespole. Powiedzmy: eksperta dziedzinowego. Taki człowiek może z powodzeniem wesprzeć wizję nas, czyli w tym wypadku Klienta. Może przenieść jego produkt na wyższy poziom.

Jeśli robimy innowacyjną porównywarkę ubezpieczeń, a u partnera znajduje się człowiek, który pracował w biznesie ubezpieczeniowym – może to być bardzo ciekawy asset i warto rozważyć udział takiego eksperta w naszych pracach. On może mieć inny pogląd na przykład na kwestię zestawiania ofert różnych ubezpieczycieli według kryterium cenowego, ale nikt tak jak on, nie pomoże nam w wypracowaniu innego podejścia do porównywania produktów ubezpieczeniowych ze względu na znajomość specyfiki budowania ofert, kwotacji, polisowania, etc. Jeśli ten człowiek stanie się w naszym projekcie Proxy Product Ownerem – wspólnie z właścicielem produktu będą tworzyli dream team. Pod warunkiem oczywiście, że ekspert zewnętrzny uwierzy w tę nową wizję przykładowej porównywarki i zaangażuje się w prace nad jej realizacją.

Podstawą jest zaplecze

Niezwykle ważne jest także zaplecze partnera i jego możliwości współpracy z innymi podmiotami (firmami, instytucjami) bądź freelancerami w celu udoskonalania produktu. Czy to na etapie product discovery, czy rozwijania gotowego produktu albo wprowadzania zmian po nagłym piwotowaniu – mogą nam być potrzebni spece różnej maści – od badaczy, researcherów, analityków, grafików, inżynierów danych, copywriterów, specjalistów od SEO, a nawet lingwistów czy psychologów. Często zakłada się, że aby zrobić dobry, innowacyjny produkt wystarczy kilku programistów biegłych w danej technologii. „My odpowiadamy za biznes – Wy zapewnijcie zespół programistyczny” – słychać bardzo często podczas rozmów potencjalnych partnerów.

Tymczasem warto założyć, że od przyszłego partnera możemy potrzebować także innych zasobów i zapytać go na wczesnym etapie, potwierdzić to, czy jest otwarty na szerszą współpracę i jakie w tym zakresie są możliwości. Wiedząc to na początku, uwzględniając takie opcje – będziemy spokojniejsi o takie wsparcie, a partner będzie czuł się za nasz produkt bądź usługę jeszcze bardziej odpowiedzialny, co wyjdzie tylko na plus obu stronom.

Możliwości kadrowe ważne są także przy najważniejszych usługach świadczonych przez partnera, czyli gdy mowa jest o samym zespole programistycznym. Tu, taka zastępowalność ludzi o podobnym doświadczeniu i wiedzy jest kluczowa na etapie powstawania produktu. Bo już utrzymywać go na bazie dobrej dokumentacji jest na pewno innym dużo łatwiej niż przejąć prace developerskie w trakcie. A więc sprawdźmy takie możliwości: iloma w danej technologii specjalistami dysponuje dostawca, nasz przyszły partner? Czy są to ludzie dostępni w krótkim czasie czy wręcz przeciwnie – niedostępni, bo alokowani do innego strategicznego Klienta / projektu przez najbliższe dwa lata? Zawsze można porozumieć się z partnerem i budować taki backup w trakcie, wcześniej go planować, ale do tego potrzebna jest wiedza, że na nikogo więcej póki co nie możemy liczyć. Najgorzej jeśli będziemy tym zaskoczeni w trakcie. Rynek jest na tyle trudny, że czasem nawet praca nad bardzo innowacyjnym produktem, w powstawaniu którego bierze udział zdolny programista, nie jest w stanie go zatrzymać w firmie. Nie namawiam do pracy wyłącznie z dużymi firmami – wręcz przeciwnie. Jednak liczba dobrych i dostępnych programistów pracujących w wybranej przez nas bądź partnera technologii, ma znaczenie.

Partner, nie dostawca

Na koniec rzecz może oczywista dla niektórych, ale uważam, że warta podkreślenia – ta firma, z którą przyjdzie nam tworzyć, a potem rozwijać coś wyjątkowego, przełomowego – raczej przez lata, a nie miesiące – to musi być partner, nie dostawca. Oczekujmy od niego postawy partnerskiej, zrozumienia naszej sytuacji, momentu, w którym się znajdujemy, możliwości, którymi dysponujemy.

Często w swoje karierze widziałem, jak wybierano dostawcę według wiodącego kryterium cenowego, a potem okazywało się, że firma się z tym dostawcą męczy, a w końcu po dużej frustracji – rozstaje. To samo jak w życiu – jeśli kierujemy się tylko jednym kryterium wyboru partnera życiowego – może się to okazać zgubne. Niestety, to jest błąd wielu postępowań przetargowych – cena czyni cuda na etapie RFP i wyboru najlepszego dostawcy spośród wszystkich zgłoszonych. A potem brakuje tej wartości, którą może wnieść partner.

Partner technologiczny musi nam pomagać od początku, oczywiście nie chodzi mi o nieodpłatne usługi czy wsparcie tylko o duże zaangażowanie, focus na nasz unikalny produkt lub usługę tak, jakby to był ich biznes czy ambicję, by odnieść z nami wspólny sukces. Tak jak do partnera życiowego – musimy mieć do partnera technologicznego zaufanie. To zaufanie, ale też i zainteresowanie oraz zaangażowanie będzie ważne przez najbliższe lata, na różnych (czasem burzliwych) etapach rozwoju produktu. Po hucznie uruchomionym MVP, którego powstawanie porównałbym do pierwszego roku związku ;-), przyjdzie czas na dalsze ciężkie prace, zmiany (niekiedy bardzo drastyczne), utrzymanie, wsparcie, usuwanie ewentualnych błędów, poprawki czy udoskonalenia.

Dlatego jeśli decydujemy się na współpracę z partnerem technologicznym – zarówno my jak i on musimy mieć świadomość, w co się angażujemy i co nas czeka. Takie otwarte komunikowanie na wczesnym etapie potrzeb i oczekiwań ze strony firmy, która szuka partnera technologicznego bardzo pomaga we wzajemnym ułożeniu współpracy, dobraniu najlepszych ludzi do pracy, w skutecznym przeprowadzeniu całego procesu produkcyjnego i w efekcie: w odniesieniu wspólnego sukcesu.

Bo z perspektywy partnera technologicznego mogę powiedzieć zupełnie szczerze, że nic nie cieszy tak jak sukces produktu, nad którym się wspólnie pracowało. A jeśli ów produkt bądź usługa zostanie uznana przez rynek za innowację – ta satysfakcja jest bezcenna. Choć aby coś stało się przełomowe – potrzebny jest ogrom pracy utalentowanych ludzi, duże pieniądze na badania i rozwój oraz samą produkcję choćby tylko MVP, świetne rozumienie potrzeb konsumentów bądź klientów i wynikające z tego pomysł / rozwiązanie oraz oczywiście skuteczny partner technologiczny. Jako Binar Apps staramy się nim być.