Jest naprawdę sporo podobieństw między oboma zawodami.
Może to być dość prowokacyjny tytuł zarówno dla naukowców zajmujących się danymi, jak i deweloperów. Nie chodzi oczywiście o to, że role są identyczne. Chodzi raczej o to, że dla celów tworzenia procesów i organizacji sensowne może być podobne traktowanie tych ról, a nie np. traktowanie data scientist jak analityka danych. Ta bardziej poprawna klasyfikacja ułatwi zarządzanie projektami data science i ustalanie oczekiwań.
Przyjrzyjmy się różnicom i podobieństwom między nauką o danych a tworzeniem oprogramowania aby sprawdzić, czy te role są rzeczywiście podobne.
Różnice
Jedną z głównych różnic jest planowanie i realizacja projektów. Klasyczne projekty programistyczne są zwykle binarne - w tym sensie, że mają mniejszą niepewność co do oczekiwanej implementacji i jej dokładności. Istnieją przecież dość skonkretyzowane (tak tak, wiemy jak to czasami wygląda…) wymagania dotyczące produktu, które są tłumaczone na specyfikację techniczną, która jest następnie implementowana w kodzie. Należy zauważyć, że większość dokumentacji projektowej dotyczącej inżynierii oprogramowania jest pisana przed wdrożeniem.
Projekty z zakresu nauki o danych są inne - charakteryzują się z natury wysoką niepewnością. Nigdy nie znasz dokładności modelu, dopóki nie zaimplementujesz prototypu. Co więcej, model nigdy nie jest „skończony”, jak może to mieć miejsce w przypadku typowego projektu oprogramowania, gdzie ktoś w końcu wystawia fakturę za jakąś wersję software’u. Za dwa tygodnie później może się przecież pojawić inny data scientist ze świeżym pomysłem na funkcję, która znacznie poprawi dokładność modelu, umożliwiając wprowadzenie nowych funkcji produktu, których wcześniej nawet sobie nie wyobrażano.
Wynika z tego, że naukowcy zajmujący się danymi znacznie częściej pracują z jednorazowymi notatnikami i skryptami, aby szybko zweryfikować hipotezy — prawdopodobnie skąd bierze się przekonanie, że nie potrafią napisać poprawnego kodu.
Podobieństwa
Główne podobieństwo między programistami i „danonaukowcami” polega na tym, że od programistów oczekuje się dostarczania oprogramowania, a nie tylko raportów, pulpitów nawigacyjnych, opinii czy wykresów informacyjnych. Po wdrożeniu modelu operującego na danych staje się on ciągłym elementem konserwacji, ponieważ istnieje potrzeba np. jego monitorowania i logowania zdarzeń. Podobnie jest w przypadku programisty – jego rola niejednokrotnie nie kończy się na stworzeniu programu ale także na jego aktualizacjach czy modyfikacjach.
Zarówno naukowcy danych, jak i inżynierowie oprogramowania są też oceniani pod kątem pewnych ogólnych umiejętności, które są – jakżeby inaczej - związane z tworzeniem oprogramowania:
- Przekładanie problemów biznesowych na specyfikacje techniczne
- Obsługa zależności wespół z innymi zespołami
- Prowadzenie projektu zorientowanego na klienta
- Konieczność bieżącego ustalania priorytetów i planowania
- Ocena nowych technologii i metod robienia rzeczy w lepszy czy bardziej wydajny sposób
Co to oznacza dla zespołu ds. analizy danych
Ponieważ analitycy danych, w tym data scientist, tworzą kod, który będzie używany w produkcji, musi on być wysokiej jakości. Modele uczenia maszynowego na ogół wymagają bardziej złożonych testów niż zwykłe oprogramowanie, ponieważ chcesz mieć pewność, że model zachowuje się dobrze w przypadkach skrajnych, jest zgodny z Twoimi założeniami a struktura walidacji prawidłowo symuluje środowisko produkcyjne.
Nie jest dobrym pomysłem praca badawcza o wysokiej niepewności bez jasno określonych wyników (Po prostu spójrz na te dane i zobacz, czy możesz wpaść na jakieś dobre pomysły). Zamiast tego możemy zastosować kilka przydatnych metod planowania, które znamy już ze złożonych projektów programistycznych, na przykład ustalanie ram czasowych niepewnych projektów w jasno określone rezultaty (zakończ zapytania o dane w tygodniu 1, wdróż wstępne przetwarzanie w tygodniu 2, wytrenuj A w tygodniu 3 itd.).
