„Potrzebuję dwóch data scientistów na dwa miesiące, aby zbudować rozwiązanie.” – czasami słyszymy to od potencjalnych klientów. To może zadziałać, jeśli wiesz dokładnie, co zrobić. Ale zazwyczaj niestety nie wiesz.

W tworzeniu oprogramowania, jeśli tylko masz specyfikację, możesz rozszerzyć zespół i zrobić to, co powinno być zrobione. W modelowaniu matematycznym przez długi czas nie wiadomo, co jest możliwe.

Zdarzyło nam się, że zadanie zostało zdefiniowane jako „znalezienie profili użytkowników”, ale w rzeczywistości klient potrzebował zaawansowanego systemu rekomendacji produktów na podstawie zachowania użytkowników. Jak body leasing mógłby pomóc w takim przypadku?

Może zadziałać, jeśli ktoś dokładnie wie, co trzeba zrobić i jakie umiejętności są wymagane. Zdecydowanie nie działa to na zasadzie „potrzebuję dwóch analityków danych”, aby wzmocnić zespół programistów i dostarczyć produkt oparty na danych.

Jest to ryzykowne dla reputacji firmy, która dostarcza data scientistów w ten sposób. Dlaczego?

Ponieważ nie zobaczą oni problemu, który ma zostać rozwiązany. Otrzymają do wykonania pewne zadania, które powinny rozwiązać problem tak zdefiniowany, jak widzi go klient.

Dlaczego pojawia się tutaj ryzyko reputacyjne? Z mojego doświadczenia wynika, że najwygodniej jest obwiniać analityka danych. Nie to, że problem jest trudny albo niemożliwy do rozwiązania. Nie niewłaściwą infrastrukturę albo błędne decyzje projektowe czy biznesowe.

To są powody, dla których w QuantUp nie wynajmujemy data scientistów.

Chcemy mieć część projektu analitycznego lub cały projekt pod naszym kierownictwem i kontrolą. I decydować, jak powinien być rozwiązany i kto co powinien to zrobić. Chcemy wziąć na siebie odpowiedzialność, zarówno ryzyko, jak i nagrodę.

Oczywiście, nie decydujemy o wszystkim bez przedyskutowania tego z innymi.

Wreszcie, istnieje też elegancka nazwa dla body leasingu: „team augmentation”. Wolimy jednak używać tej pierwszej, ponieważ bardzo dobrze opisuje sposób, w jaki data scientiści są w tym przypadku traktowani.