Analityk to ktoś, kto ma pomóc zrozumieć problem, znaleźć rozwiązanie i ułatwić życie zespołowi oraz klientowi. A przynajmniej w teorii 😉. W praktyce bywa różnie. Poniżej znajdziecie moje subiektywne 10 przykazań złego analityka, czyli czego absolutnie nie robić, jeśli nie chcecie stać się zmorą swojego projektu.
1. Nie rozmawiaj z użytkownikami, bo przecież sam wiesz lepiej
Po co marnować czas na wywiady czy warsztaty, skoro masz w głowie gotowe rozwiązanie?
Dlaczego to błąd? Bez rozmowy z użytkownikami powstaje system „na wyobrażenia”, a nie „na potrzeby”. To najprostsza droga do produktu, którego nikt nie chce używać.
2. Notuj wymagania w taki sposób, żebyś tylko Ty je rozumiał(a)
Najlepiej w 200-slajdowej prezentacji, w której połowa to tabelki, a druga połowa to akronimy, których nikt nie zna.
Dlaczego to błąd? Dokumentacja to narzędzie komunikacji, a nie dzieło literackie. Jeśli rozumie ją tylko autor – cała reszta zespołu pracuje na domysłach.
3. Unikaj pytań, bo jeszcze wyjdzie, że czegoś nie wiesz
Pamiętaj: dobry analityk nie pyta, on zakłada. A potem projekt się wykłada, ale to już szczegół.
Dlaczego to błąd? Największą siłą analityka są pytania. Każde „a co jeśli…?” pozwala odkryć wyjątki i ukryte wymagania, które często ratują projekt przed kosztownymi poprawkami.
4. Rób dokumentację na koniec projektu
Albo jeszcze lepiej – wcale. Przecież każdy pamięta, co ustaliliście pół roku temu, prawda?
Dlaczego to błąd? Ustalenia znikają szybciej niż meeting notes w Teamsach. Dokumentacja robiona na bieżąco porządkuje wiedzę i zapobiega sytuacjom w stylu: ale przecież ustalaliśmy inaczej!.
5. Ignoruj devów i testerów
Po co pytać zespół techniczny o zdanie? Ważne, że klient jest zadowolony… do momentu, aż coś nie działa.
Dlaczego to błąd? Devi i testerzy widzą ograniczenia technologiczne, ryzyka i dziury w wymaganiach. Jeśli ich pominiesz to architektura i kod mogą rozsypać się szybciej, niż powstanie MVP.
6. Bądź zawsze na TAK
Klient chce jednocześnie rakietę kosmiczną i prostą apkę do notatek? Jasne, damy radę!
Dlaczego to błąd? Brak asertywności kończy się zakopanym zespołem i projektem, który spuchł od nadmiaru „wrzutek”. Dobry analityk musi umieć powiedzieć „nie” albo przynajmniej „nie teraz”.
7. Nie sprawdzaj wpływu zmian
Przecież jak klient chce „tylko jedną małą zmianę”, to na pewno nie rozwali to całej architektury.
Dlaczego to błąd? W IT nie ma małych zmian. Każda, nawet kosmetyczna, może wywołać efekt domina: od modelu danych po integracje. Analiza wpływu to obowiązek, nie opcja.
8. Mów językiem, którego nikt nie rozumie
Im więcej branżowych buzzwordów i skrótów, tym bardziej profesjonalnie wyglądasz. Synergia omnichannel z leverage data-driven approach – brzmi super, nie?
Dlaczego to błąd? Analityk jest tłumaczem między światem biznesu i IT. Jeśli biznes nie rozumie IT, a IT nie rozumie biznesu to projekt nie ma szans.
9. Unikaj priorytetów
Wszystko jest najważniejsze. A jak wszystko jest najważniejsze, to… nic nie jest.
Dlaczego to błąd? Brak priorytetyzacji = chaos. Po prostu. Projekt próbuje zrobić wszystko naraz, więc nic nie dowozi na czas. Dobry analityk pomaga ustalić, co naprawdę przynosi wartość.
10. Nigdy nie przyznawaj się do błędu
Bo przecież analityk się nie myli – najwyżej rzeczywistość się nie dostosowała.
Dlaczego to błąd? Przyznanie się do błędu buduje zaufanie. Brnięcie w zaparte niszczy wiarygodność analityka i relacje z zespołem.
Zły analityk to ktoś, kto nie pyta, nie słucha, nie dokumentuje i nie współpracuje. A dobry analityk?
- słucha użytkowników,
- angażuje devów i testerów,
- mówi ludzkim językiem,
- priorytetyzuje,
- a w razie błędu bierze odpowiedzialność.
Bo analiza to nie dodatek do programowania. To fundament projektu. Bez niej nawet najpiękniejsza architektura i najczystszy kod mogą okazać się kompletnie bezużyteczne.