5 wyzwań w pracy z klientami startupowymi z branży MedTech: Perspektywa programisty (Część 1)

5 wyzwań w pracy z klientami startupowymi z branży MedTech

 

 

Nie jest pewnie niczym zaskakującym (szczególnie dla doświadczonego developera), kiedy powiem, że praca z klientem startupowym może być niezwykle satysfakcjonującym i rozwijającym doświadczeniem, którego trudno szukać w organizacjach o innym modelu biznesowym. To nie tylko ciekawe wyzwania technologiczne (które szybko rozwijają nasz programistyczny warsztat), ale też (przede wszystkim) możliwość pracy blisko z klientem – poznanie jego perspektywy, zrozumienie biznesu, a także próba podążania jak najbardziej pragmatyczną i efektywną ścieżką, by osiągnąć jego biznesowy cel.

Pracując jako programista przy wielu projektach startupowych z klientami z całego świata, zauważyłem zestaw problemów, które warto wziąć pod uwagę podczas współpracy. W tej pierwszej części artykułu omówimy pięć najczęstszych wyzwań, z którymi zespoły programistyczne często spotykają się podczas współpracy z klientami startupowymi z branży MedTech. Zrozumienie tych problemów jest kluczem do efektywnej współpracy i realizacji projektów.

WYZWANIE 1. Komunikacja w outsourcingu oprogramowania

Wśród pięciu wyzwań, które omawiam w tej części artykułu, komunikacja i zaufanie nie są w żadnym wypadku najmniej istotne. Wiem, że może to brzmieć banalnie, ale są to kluczowe czynniki dla efektywnej współpracy. Większość, jeśli nie wszystkie, powszechne wyzwania związane z outsourcingiem oprogramowania, o których wspominam tutaj, sprowadzają się do słabej słaba komunikacji a w efekcie – do braku zrozumienia. Brak przejrzystości powoduje brak zaufania.

Filary scrumowe

Co można z tym zrobić?

Najlepszym sposobem uniknięcia problemów z komunikacją jest zapewnienie przejrzystości i szczerości.

Przyjęcie metody Scrum zarówno przez klienta, jak i jego zespół deweloperski może pomóc, ponieważ jedną z podstawowych wartości Scrum jest otwartość, a jednym z jej filarów jest inspekcja. Warto tu wspomnieć, że należy sprawdzać postęp projektu oraz patrzyć na pracę osób w zespole. W końcu, jak mogą się one adaptować (adaptacja jest drugim filarem Scrum), jeśli nie wiedzą, co robią źle? Jeśli Ty i Twój zespół pracujecie w Scrum i uda się wdrożyć klienta we wszystkie trzy filary w takiej pracy (trzeci to przejrzystość, którą można rozumieć jako gotowość do udzielania i otrzymywania informacji zwrotnej), możesz być pewien, że będziesz mieć mniej problemów do rozwiązania.

Jak było u nas?

  • Nasze podejście do poprawy komunikacji z naszymi klientami polegało na codziennych spotkaniach, podczas których nasz Product Owner informował ich o postępach w realizacji celów biznesowych. Dobrą praktyką jest również udział klienta w innych (najlepiej: wszystkich) wydarzeniach SCRUM, ponieważ pozwala to na zwiększenie zrozumienia pomiędzy zespołem a klientem.
  • Komunikacja z klientem z zagranicy odbywa się głównie online. Jednak komunikacja nabiera nowego wymiaru, gdy wszyscy spotykają się osobiście. Wiem, że może to być trudne, kosztowne i czasochłonne, ale sugeruję, abyś organizował spotkania na żywo z klientem tak wcześnie i tak często, jak to możliwe.
  • Warto rozszerzyć komunikację na odbiorców oprogramowania (w moim przypadku, na lekarzy). Każdy w projekcie powinien móc rozmawiać z użytkownikami, zadawać im pytania i słuchać tego, co mają do powiedzenia. Rolą osób odpowiedzialnych za utrzymywanie kontaktu z końcowymi użytkownikami w zespole klienta powinno być budowanie mostu między nimi, Product Ownerami, programistami i innymi osobami zaangażowanymi w rozwój produktu.
  • Najlepiej, gdy zespół deweloperski wie, jak wygląda praca u klienta (np. ich obowiązki, odpowiedzialności lub narzędzia, których używają) – wtedy łatwiej zrozumieć ich decyzje, motywacje i przebieg procesów. Warto zadawać pytania, gdy coś jest niejasne.
  • Ważne jest, aby komunikować się za pomocą publicznych kanałów.
    Korzystanie z prywatnych wiadomości powinno być ograniczone do minimum, chyba że dotyczy spraw poufnych.

Wartości Scrumowe

WYZWANIE 2. Zaufanie

To drugi, często kluczowy problem. Każdy założyciel startupu chce mieć pewność, że może polegać na firmie outsourcingowej, którą zatrudnił, a każdemu zespołowi pracuje się dużo płynniej i spokojniej gdy takie zaufanie uda się z klientem zbudować. Jednak budowanie zaufania wymaga sporego wysiłku i zazwyczaj zajmuje dość dużo czasu. 

Co można z tym zrobić?

  • Jako zespół deweloperski dążcie do roli partnera – pokazujcie, że nie jesteście tylko po to, aby wziąć pieniądze klienta, napisać kod i powiedzieć „do widzenia”. Bądźcie aktywni, postarajcie się zrozumieć na czym dokładnie polega biznes klienta i jaki jest jego cel. Pokażcie klientowi, że rozumiecie jego podejście i postarajcie się by proces developmentu był jak najbardziej przemyślany i dzięki temu efektywny.
  • Jako zespół stosujecie metodologię Agile i pracujcie w SCRUM – ponieważ jeśli robicie to naprawdę, między innymi, będziecie prowadzić backlog produktu, do którego klient może mieć dostęp w każdej chwili, a dzięki temu mieć wgląd w czasie rzeczywistym w proces developmentu. Prawdziwy SCRUM zmniejsza poczucie niepewności i pomaga zrozumieć przyczyny problemów (które zawsze się pojawiają).
  • Starajcie się budować zaufanie już na samym początku współpracy i wzmacniać je, zanim rozpocznie się współpraca.
  • Bądźcie w stałym kontakcie z klientem, sprawdzając, czy produkt odpowiada jego wizji i czy zespół porusza się we właściwym kierunku przy każdym inkrementacji. Istnieją wskaźniki, które potwierdzą, czy klient osiąga swoje cele, takie jak liczba pytań, które pojawiają się podczas spotkań, satysfakcja z pracy z zespołem (warto, aby klient był transparentny w kwestii jakości współpracy), wpływ wdrożonych działań (monitorowanie, czy proces się poprawia), czy wykresy burndown wykonanych story points.

WYZWANIE 3. Dane osobowe lub ważne dane

Każda osoba pracująca nad rozwojem oprogramowania, prędzej czy później będzie miała do czynienia w swojej pracy, z mniej lub bardziej poufnymi danymi klientów. Musisz zabezpieczyć te informacje, ponieważ wyciek danych jest rzeczą, która absolutnie nie powinna się wydarzyć. Jak więc pokazać, że Twój zespół wie, jak się nimi zająć?

Co można z tym zrobić?

  • Podpisz dwustronną umowę. Jeśli chodzi o dane osobowe i ważne dane, najistotniejsze jest posiadanie solidnej umowy, która szczegółowo opisuje sposób postępowania z tymi danymi.
  • Pytaj klienta o kwestie prawne. Praca deweloperów polega na tworzeniu oprogramowania, więc nie ma szans, że znają oni wszystkie przepisy, którym musi podlegać produkt klienta. Taki był kiedyś mój problem. Klient nie poinformował nas od razu, że powinniśmy pracować zgodnie ze standardem HL 7 FHIR. A kiedy w końcu to zrobił, okazało się, że zmarnowaliśmy dużo czasu na bezużyteczną pracę, ponieważ kod, który napisaliśmy, nie znając standardu, był bezwartościowy.
  • Sprawdź, czy Twój zespół zewnętrzny ma certyfikat dotyczący danych. Na przykład w branży zdrowia cyfrowego jest to zgodność z HIPAA. Zgodność z HIPAA to zestaw standardów i przepisów określonych w Ustawie o Przenośności i Odpowiedzialności Ubezpieczenia Zdrowotnego (HIPAA) z 1996 roku. Ustawa ta została ustanowiona w celu ochrony prywatności informacji zdrowotnych osób i zapewnienia wytycznych dotyczących bezpiecznego przechowywania i przesyłania danych zdrowotnych. Mój zespół uzyskał certyfikat, co ostatecznie uczyniło nas bardziej wiarygodnymi w oczach klientów.
  • Upewnij się, że Twój Product Owner zna wszystkie szczegóły branży klienta oraz przepisy prawa w jego kraju. W mojej opinii dobry PO dba o produkt zarówno od strony oprogramowania, jak i biznesowej.

Startupy zwykle są ograniczone budżetowo, ale jeśli klient ma pieniądze, może zatrudnić zewnętrznych kontrolerów i edukować zespół deweloperski. To dwie praktyki, które widziałem w jednym z moich projektów.

    • Klient regularnie przeprowadzał badania z nami i pytał, w jaki sposób rozwijaliśmy oprogramowanie. A kiedy mówię „badania”, nie mam na myśli dwóch pytań w formularzu Google. To były obszerne listy pytań dotyczących procesu rozwoju oprogramowania i ukończenia projektu. Musieliśmy udowodnić, że przestrzegamy standardów HIPAA, a nasz DevOps musiał wyjaśnić, że infrastruktura projektu jest bezpieczna i że żadna niepożądana osoba nie ma do niej dostępu. Zdołaliśmy zdać wszystkie te „testy”, co dodatkowo zwiększyło zaufanie klienta.
    • Firma, dla której pracowaliśmy, przeprowadziła szkolenie wewnętrzne dotyczące danych pacjentów. Fajnym rozwiązaniem było to, że zapewnili nam to samo szkolenie. To ulepszyło naszą pracę z danymi pacjentów, ponieważ lepiej zrozumieliśmy przepisy i prawa dotyczące opieki zdrowotnej.

WYZWANIE 4. Dostarczanie wartości

Wyzwaniem w projektach rozwoju oprogramowania jest zapewnienie, że dedykowany zespół rzeczywiście wykonuje pracę zorientowaną ściśle na dostarczanie wartości biznesowej oraz pisze kod wolny od błędów. Jak to osiągnąć?

Co można z tym zrobić?

Ponownie, SCRUM pojawia się, by pomóc. Wiem, że mogę zabrzmieć powtarzalnie, ale jeśli twój zespół pracuje w SCRUM, możesz zakładać i przyczyniać się do tego, że przestrzega on pewnych standardów, takich jak Kryteria Akceptacji, Definicja Gotowości i Definicja Zakończenia.

  • Kryteria Akceptacji (AC)

    To zestaw warunków, które muszą zostać spełnione, aby przyrost produktu został zaakceptowany przez klienta. Jest to „umowa” między zespołem deweloperskim, a klientem dotycząca tego, co powinno być zawarte w ostatecznym produkcie. Kryteria te mogą się różnić w zależności od rodzaju produktu, nad którym pracujesz, ale zazwyczaj obejmują funkcje, funkcjonalności, standardy wydajności lub miary jakości. Musisz naprawdę zadbać o Kryteria Akceptacji i aktualizować je za każdym razem, gdy coś się zmienia w projekcie. Najlepiej, jeśli Kryteria Akceptacji są zdefiniowane przez klienta. Jeśli to niemożliwe, powinny być przynajmniej zaakceptowane przed rozpoczęciem procesu rozwoju oprogramowania.

  • Definicja Gotowości (DoR)

    To zestaw zasad, które muszą być spełnione, zanim produkt może rozpocząć rozwój. Obejmuje to zapewnienie, że zespół ma wszystkie niezbędne zasoby i jest w pełni przygotowany do rozpoczęcia pracy nad projektem. DoR da Ci pewną dozę pewności, że wszelkie problemy zostały rozwiązane i wyjaśnione przed rozpoczęciem prac nad rozwojem.

  • Definicja Zakończenia (DoD)

    To zestaw kryteriów, które muszą być spełnione, zanim praca zostanie uznana za ukończoną. Obejmuje to zapewnienie, że produkt spełnia oczekiwania klienta i został przetestowany pod kątem zapewnienia jakości. DoD pomaga również zapewnić, że cała dokumentacja jest aktualna, wszelkie problemy zostały rozwiązane, a produkt jest gotowy do wdrożenia. Wszystkie te kryteria muszą być spełnione, zanim projekt zostanie uznany za ukończony. DoR i DoD powinny być ustalone na początku współpracy klienta z zespołem.

Oczywiście możecie zaimplementować dowolny inny zestaw kryteriów w projekcie rozwoju oprogramowania. Należy się tylko upewnić, że zasady są jasne i wiadomo, jak sprawdzić, czy są one spełnione.

WYZWANIE 5. Bariery językowe i różnice kulturowe

Język może stanowić przeszkodę w komunikacji, prowadząc do nieporozumień lub błędnych interpretacji, co może spowodować opóźnienia w realizacji zadań. Kultura również odgrywa rolę; różny kontekst kulturowy prowadzi do różnych sposobów myślenia.

Co można z tym zrobić?

Problemy z językiem i kulturą prawdopodobnie są jednymi z pierwszych rzeczy, które przychodzą Ci na myśl, gdy słyszysz “praca z klientami z całego świata”. Jednakże, z mojego doświadczenia, w rzeczywistości to nie jest problem! Oczywiście, moja wiedza jest ograniczona do mojego doświadczenia, ale mój zespół nigdy nie musiał radzić sobie z lingwistycznymi nieporozumieniami. Jeśli chodzi o kulturę, uważam, że Polska dzieli ogólną mentalność świata zachodniego, więc nie było to nigdy problemem w naszej pracy.

Wskazówka: dla informacji na temat języka, sprawdź ranking EF The World’s Largest Ranking of Countries and Regions by English Skills. Możesz też zwrócić uwagę na wymiary kultury ujęte w badaniach prowadzonych przez zespół, który prowadził Geert Hofstede: The 6-D model of national culture.

Omówiliśmy pięć kluczowych wyzwań, które programiści mogą napotkać w pracy z klientami startupowymi z branży MedTech. Zrozumienie tych problemów to pierwszy krok do ich przezwyciężenia. W drugiej części artykułu przyjrzymy się kolejnym pięciu wyzwaniom oraz przedstawimy skuteczne sposoby radzenia sobie z nimi.