Błędy początkujących analityków danych: jak je zauważyć i poprawić

Na początku nauki analizy danych łatwo uznać, że kolejnym krokiem musi być kolejne narzędzie. Znasz już kilka formuł, więc pojawia się SQL, potem Python, dashboard i model uczenia maszynowego. Lista rośnie, a przy pustym pliku nadal trudno zdecydować, od czego zacząć. W takiej sytuacji sprawdziłbym sposób pracy nad zadaniem, zanim dopisałbym następny kurs do planu.

Najwięcej uwagi poświęciłbym pięciu miejscom: podstawom, zakresowi projektu, samodzielności, oczekiwaniom wobec pierwszej pracy i komunikacji. Proponuję potraktować je jako praktyczny zestaw pytań do przeglądu własnej nauki. Każdy punkt da się sprawdzić na małym zadaniu, bez kupowania nowego narzędzia i bez wielomiesięcznej przebudowy portfolio. Wybierz najpierw ten, przy którym najtrudniej Ci podać konkretny przykład ze swojej pracy.

Posłużę się syntetyczną migawką zgłoszeń do pomocy technicznej. Dzięki niej zobaczysz, jak pozornie drobna decyzja zmienia znaczenie wyniku. Nie będziemy budować całego systemu obsługi klienta. Celem jest przygotowanie krótkiej, odtwarzalnej informacji o tym, co można powiedzieć na podstawie dostępnych rekordów i czego jeszcze brakuje do oceny pracy zespołu.

Błąd pierwszy: przeskakiwanie nad podstawami

Znajomość polecenia nie oznacza jeszcze, że rozumiesz obliczenie. Możesz umieć uruchomić grupowanie i nadal nie wiedzieć, czy grupujesz zamówienia, pozycje zamówień czy klientów. Możesz poprawnie napisać średnią, lecz podzielić przez niewłaściwą liczbę obserwacji. Dlatego na początku każdego ćwiczenia pytam, co reprezentuje jeden wiersz, jaki jest klucz i które wartości są rzeczywiście znane.

Przed użyciem funkcji potrafię opisać jej oczekiwany rezultat na kartce. Przy pięciu rekordach nie zajmuje to wiele czasu, a ujawnia niejasności dużo wcześniej niż gotowy wykres. Szczególnie pilnuję różnicy między zerem a brakiem, liczby wierszy po połączeniu tabel oraz znaczenia daty. Data utworzenia zgłoszenia i data jego zamknięcia prowadzą do różnych zestawień okresowych.

Opis roli analityka w Microsoft Learn obejmuje przygotowanie danych oraz współpracę z odbiorcami raportów. To przydatne przypomnienie, że sama obsługa wykresu jest tylko fragmentem pracy. Nie traktuję opisu jednego dostawcy jako kompletnej definicji wszystkich stanowisk, ale wykorzystuję go do sprawdzenia, czy mój plan nauki obejmuje coś więcej niż klikanie w interfejsie.

Mała próbka, która ujawnia duży problem

Poniższa tabela jest całym naszym przykładem. Status Closed oznacza zamknięte zgłoszenie, a Open otwarte. Hours to czas rozwiązania w godzinach, zapisany tylko tam, gdzie go znamy. Znak „brak” opisuje brakującą wartość, nie liczbę zero. Ostatni wiersz T06 jest dokładną kopią wcześniejszego rekordu, dodaną celowo jako powtórzenie eksportu.

Surowy plik zawiera osiem wierszy i siedem różnych identyfikatorów. Po usunięciu wskazanej dokładnej kopii zostaje siedem zgłoszeń: pięć zamkniętych i dwa otwarte. Czas znamy dla czterech zamkniętych zgłoszeń. Suma tych czasów wynosi dwadzieścia godzin, więc średnia dla dostępnych obserwacji to pięć godzin. Ta informacja nie opisuje automatycznie wszystkich zgłoszeń.

Gdy brakujący czas T05 zastąpisz zerem i podzielisz przez pięć zamkniętych rekordów, otrzymasz cztery godziny. Rachunek jest wykonalny, lecz wprowadziłeś nieuzasadnione założenie, że brakujący pomiar oznacza natychmiastowe rozwiązanie. Nie wiemy też, ile jeszcze będą czekać otwarte zgłoszenia. Tabela nie zawiera dat, więc nie można uczciwie przedstawić wyniku jako trendu tygodniowego ani porównania dwóch miesięcy.

Ćwicz podstawy przez celowe zmiany

Pierwsze ćwiczenie polega na uzyskaniu podanych liczebności i średniej w znanym Ci narzędziu. Możesz użyć arkusza albo SQL. Zapisz, jak wybrałeś zamknięte zgłoszenia, jak rozpoznałeś kopię i jaki mianownik zastosowałeś. W przypadku SQL zacznij od prostych zapytań i kontroli wyniku. Wybór programu nie zmienia znaczenia brakującego czasu.

Potem zmień T05 na znane dziesięć godzin. Średnia pięciu zamkniętych zgłoszeń powinna wynieść sześć godzin, a liczba brakujących pomiarów w tej grupie spaść do zera. Przywróć brak i dodaj drugą kopię T06. Liczba surowych wierszy wzrośnie, lecz liczba różnych zgłoszeń pozostanie siedem. Każdy eksperyment sprawdza inne założenie procesu.

Na koniec zmień status jednej kopii T06 na Closed. Teraz nie masz dwóch identycznych rekordów. Masz sprzeczne opisy tego samego identyfikatora. Bez daty aktualizacji lub reguły źródła nie wybierzesz wiarygodnie właściwego stanu. To dobry moment, by zatrzymać obliczenie i opisać pytanie do właściciela danych. Samodzielność obejmuje rozpoznawanie sytuacji, w których danych jest za mało.

Błąd drugi: projekt większy niż obecny problem

Zamiast tego ćwiczenia możesz zaplanować pobieranie zgłoszeń przez API, bazę w chmurze, automatyczny model przewidujący opóźnienia i rozbudowany dashboard. Każdy element może być wartościowy, lecz wszystkie naraz utrudnią ustalenie, co właściwie blokuje pracę. Problemy z konfiguracją zaczną mieszać się z problemami danych. Na pierwszy samodzielny projekt wybrałbym jeden plik, jedno pytanie i jednego odbiorcę.

Naszym odbiorcą będzie lider pomocy technicznej, który chce wiedzieć, czy dostępna migawka pozwala ocenić czas rozwiązania zgłoszeń. Wynik obejmie liczebności, średnią znanych czasów, brakujący pomiar oraz listę danych potrzebnych do dalszej oceny. Nie będziemy obiecywać prognozy przyszłego obciążenia. Nie mamy historii wpływu zgłoszeń, harmonogramów pracy ani informacji o ich trudności.

Taki zakres zapisuję przed rozpoczęciem. Osobno odkładam pomysły na później, na przykład analizę godzin roboczych albo kategorii spraw. Dzięki temu ciekawy pomysł nie staje się automatycznie warunkiem ukończenia. Po oddaniu pierwszej wersji można świadomie wybrać rozszerzenie i ponownie ustalić oczekiwany rezultat. To pozwala oceniać postęp po zakończonych zadaniach.

Błąd trzeci: kopiowanie projektu bez własnych decyzji

Odtworzenie tutorialu pomaga poznać narzędzie. Problem zaczyna się wtedy, gdy kopię traktujesz jako dowód samodzielnego rozwiązania wszystkich problemów. Autor materiału wybrał pytanie, dane i kolejność kroków, a często także usunął niewygodne wyjątki. Żeby sprawdzić własne rozumienie, zamknij instrukcję i spróbuj odtworzyć analizę z opisu celu oraz surowego pliku.

Nie musisz przy tym pamiętać każdej nazwy funkcji. Korzystanie z dokumentacji jest normalną częścią pracy. Ważne, żeby umieć wybrać operację, wyjaśnić jej wynik i zauważyć, kiedy nie pasuje do danych. W naszym przykładzie własnym rozszerzeniem może być kontrola sprzecznych statusów. To niewielka zmiana, ale wymaga decyzji, której nie da się zastąpić samym przepisaniem wykresu.

W portfolio jasno oznacz źródło ćwiczenia, otrzymaną pomoc i własne zmiany. Jeśli AI wygenerowało fragment kodu, przeczytaj go i uruchom przypadki testowe. Umiejętność wyjaśnienia, dlaczego brakujący czas nie stał się zerem, będzie konkretniejszym dowodem rozumienia niż deklaracja „projekt w pełni samodzielny” przy rozwiązaniu, którego nie potrafisz zmodyfikować.

Portfolio powinno pozwalać odtworzyć tok pracy

W opisie projektu podaj pytanie, źródło danych, znaczenie wiersza, wykonane transformacje, wynik oraz ograniczenia. Dodaj instrukcję uruchomienia i informację o użytym środowisku. Dokumentacja README w GitHub wyjaśnia rolę tego pliku jako wprowadzenia do projektu. Samo repozytorium z plikiem o nazwie final nie tłumaczy odbiorcy, od czego zacząć.

W naszym ćwiczeniu wystarczy krótka tabela kontroli: osiem wierszy wejścia, siedem zgłoszeń po usunięciu dokładnej kopii, pięć zamkniętych, cztery znane czasy i średnia pięć godzin. Obok umieść wyjaśnienie brakującego pomiaru. Nie trzeba budować rozbudowanej infrastruktury testowej, żeby pokazać, że wynik został sprawdzony. Kontrola ma obejmować realne ryzyko pomyłki w tym zadaniu.

Do publicznego portfolio wybieraj dane, które możesz udostępnić, albo własne dane syntetyczne. Eksport z pracy nie staje się materiałem publicznym po usunięciu kolumny z nazwiskiem. Jeśli nie masz pewności co do możliwości publikacji, wybierz inny zbiór. Własny przykład pozwala także celowo dodać duplikat i brak, których analizę chcesz pokazać, bez ujawniania informacji o rzeczywistych klientach.

Błąd czwarty: oczekiwania niepasujące do roli

Pierwsza praca analityczna może obejmować utrzymanie raportów, uzgadnianie definicji i poprawianie istniejących plików. Jeżeli wyobrażasz ją sobie wyłącznie jako swobodne eksperymentowanie z nowymi modelami, warto sprawdzić konkretne obowiązki przed podjęciem decyzji. Nazwa stanowiska nie wystarczy. Dwa zespoły używające określenia data analyst mogą mieć inne źródła danych, rytm pracy i wymagania wobec samodzielności.

Na rozmowie zapytałbym o przykład zadania dla nowej osoby, sposób sprawdzania wyników i dostęp do pomocy. Chciałbym wiedzieć, kto wyjaśnia znaczenie kolumn oraz co dzieje się, gdy dwa raporty pokazują różne wartości. To pytania o codzienną pracę. Pozwalają ocenić środowisko uczenia się dokładniej niż sama lista nazw technologii w ogłoszeniu.

Nie zakładam, że kilka projektów gwarantuje zatrudnienie ani że brak odpowiedzi dowodzi braku predyspozycji. Zapisuj, na jakie role aplikujesz, co było wymagane i na którym etapie kończyła się rozmowa. Wnioski wyciągaj ostrożnie, szczególnie z małej liczby przypadków. Poprawiaj elementy, na które masz wpływ: czytelność opisu, dopasowanie przykładów i konkretność odpowiedzi o własnym wkładzie.

Błąd piąty: wynik bez wyjaśnienia dla odbiorcy

Komunikat „średnia wynosi pięć” pozostawia za dużo miejsca na domysły. Pięć czego, dla jakiej grupy i z jakiego okresu? W naszym przykładzie powiedziałbym: „Średni znany czas rozwiązania czterech zamkniętych zgłoszeń wynosi pięć godzin. Dla piątego zamkniętego zgłoszenia brakuje pomiaru. Migawka zawiera także dwa otwarte zgłoszenia i nie pozwala ocenić trendu”. Odbiorca widzi zakres wyniku od razu.

Nie dopisywałbym, że zespół pracuje dobrze albo źle. Brakuje uzgodnionego celu, rodzaju spraw, godzin pracy i porównywalnej historii. Mogę natomiast zaproponować kolejny krok: uzupełnienie czasu T05 oraz pozyskanie dat utworzenia i zamknięcia. Rekomendacja powinna wynikać z ustalenia, a poziom pewności odpowiadać jakości dostępnych dowodów. To również umiejętność analityczna.

Government Data Quality Framework opisuje jakość w odniesieniu do celu wykorzystania danych. Przydaje mi się ta perspektywa: mała próbka może wystarczyć do nauki deduplikacji, ale nie do oceny całego działu. Gdy zmienia się pytanie, ponownie sprawdzam, czy źródło w ogóle zawiera informacje potrzebne do odpowiedzi.

Poproś o konkretny przegląd i reaguj na uwagi

Zamiast pytać wyłącznie „czy projekt jest dobry?”, poproś drugą osobę o próbę odtworzenia wyniku i wskazanie niezrozumiałego założenia. Możesz też poprosić, żeby wyjaśniła własnymi słowami, co obejmuje średnia. Jeżeli zrozumie ją jako wynik wszystkich zgłoszeń, popraw opis. To informacja o komunikacji projektu, nawet jeśli obliczenie techniczne jest bezbłędne.

Uwagę rozdzielam na problem wyniku, problem opisu i propozycję rozszerzenia. Sprzeczne liczebności wymagają poprawy. Niejasny podpis wymaga redakcji. Pomysł dodania kolejnego narzędzia może poczekać. Takie rozróżnienie pomaga dokończyć pracę, zamiast traktować każdą sugestię jako powód do rozpoczęcia projektu od nowa. Po poprawce ponownie wykonaj kontrolę, której dotyczyła uwaga.

Jeżeli odkryjesz błąd po pokazaniu projektu, zapisz, co było niepoprawne i jaki wynik obowiązuje teraz. Zachowanie historii poprawki ułatwia rozmowę o sposobie pracy. Nie musisz udawać, że pierwsza wersja była doskonała. Ważne, żeby odbiorca nie został z dwoma sprzecznymi wynikami bez informacji, który jest aktualny i dlaczego się zmienił.

Gdy utkniesz, zmniejsz problem do sprawdzalnej próbki

Wyobraź sobie, że po połączeniu zgłoszeń ze słownikiem zespołów otrzymujesz dziewięć rekordów zamiast siedmiu. Pierwszym krokiem nie jest szukanie sposobu ukrycia dodatkowych wierszy. Wybierz jeden identyfikator, który się powielił, i obejrzyj wszystkie jego dopasowania. Jeżeli kod zespołu występuje w słowniku dwa razy, połączenie może działać zgodnie z poleceniem, a błąd tkwić w założeniu o unikalności słownika.

Tak przygotowane pytanie łatwiej skonsultować: „Dla T03 oczekuję jednego zespołu, lecz słownik ma dwa wpisy z tym samym kodem. Czy powinniśmy użyć dodatkowo daty obowiązywania?”. Pokazujesz oczekiwanie, zaobserwowany wynik i własną próbę diagnozy. Osoba pomagająca nie musi odtwarzać całego projektu. Nie przekazuj przy tym poufnych rekordów; mała syntetyczna próbka może odtworzyć ten sam mechanizm.

Jeżeli problem pojawia się w kodzie, uruchamiaj kolejne kroki osobno. Zapisz liczbę rekordów po imporcie, po filtrze i po połączeniu. Szukasz pierwszego miejsca, w którym rezultat przestał odpowiadać oczekiwaniu. Przy problemie definicji kod może w ogóle nie wymagać zmiany. Być może trzeba ustalić, czy raport ma pokazywać stan obecny, czy historię zmian statusu. Te pytania kieruję do osoby znającej proces.

Zapisuj lekcję, którą można wykorzystać ponownie

Po rozwiązaniu problemu robię krótką notatkę z przyczyną i kontrolą zapobiegającą powtórzeniu. „Poprawiono JOIN” niewiele wyjaśnia. „Słownik zawierał dwa wpisy na kod; dodano kontrolę unikalności i uzgodniono regułę wyboru wersji” opisuje decyzję. W kolejnym projekcie możesz zastosować tę kontrolę jeszcze przed przygotowaniem raportu. Tak powstaje własny warsztat, oparty na rozumieniu konkretnych pomyłek i ich skutków.

Nie każda pomyłka wymaga nowego kursu. Jeśli raz zapomniałeś filtra, przydatniejsza może być kontrola liczebności. Jeśli nie potrafisz wyjaśnić działania żadnego połączenia, warto wrócić do tej części podstaw. Rozróżnij pojedyncze przeoczenie od luki w rozumieniu. Dzięki temu plan nauki odpowiada rzeczywistemu problemowi, zamiast rosnąć przy każdym nieudanym uruchomieniu zapytania albo trudniejszym pytaniu podczas rozmowy.

Po kilku takich notatkach przejrzyj, które problemy się powtarzają. Wybierz jeden i przygotuj nowe ćwiczenie z innymi danymi, zachowując ten sam rodzaj trudności. Jeśli wcześniej pomogło Ci jedynie zapamiętanie rozwiązania, zmieniona próbka szybko to pokaże. Jeśli rozumiesz regułę, wyjaśnisz również nowy rezultat. To bardziej użyteczny sprawdzian postępu niż ponowne otwarcie ukończonego projektu i stwierdzenie, że nadal wygląda poprawnie.

Ustal moment zakończenia ćwiczenia

Uznałbym ten projekt za skończony, gdy druga osoba potrafi odtworzyć pięć godzin, zobaczyć brakujący pomiar i zrozumieć, dlaczego nie podajemy trendu. Powinna również znaleźć regułę usunięcia kopii T06 oraz opis przypadku sprzecznych statusów. Plik wejściowy, sposób przekształcenia i krótka notatka z wynikiem mają być dostępne bez odgadywania kolejności uruchamiania.

Następne ćwiczenie wybierz na podstawie konkretnej trudności. Jeśli nie kontrolujesz połączeń tabel, dołóż mały słownik i sprawdź liczbę rekordów. Jeśli trudne jest wyjaśnienie wyniku, przygotuj krótszą notatkę dla odbiorcy. Jeśli problemem jest powtarzanie ręcznych kroków, poznaj Power Query. Każde rozszerzenie powinno mieć własny sprawdzalny rezultat.

W nauce pomaga mi pytanie: co dziś potrafię zrobić i wyjaśnić bez prowadzenia za rękę? Odpowiedź może być niewielka: wykryć kopię, uzgodnić mianownik albo opisać brak danych. Z takich umiejętności składa się samodzielna analiza. Kiedy są stabilne, nowe narzędzia mają już konkretny cel, a portfolio pokazuje sposób myślenia stojący za gotowym obrazkiem.