Gdybym tylko robił produkty…
Jeden z ostatnich postów na blogu testerzy.pl (link) powstał po naszej wspólnej rozmowie z Radosław Smilgin. Całą rozmowę będziecie mogli usłyszeć już w przyszłym roku w formie podcastu, ale zanim dojdzie do publikacji, chciałabym wykorzystać inspirację, którą ja miałam po tej rozmowie. Radek zdradził nam, że codziennie stara się pisać jeden artykuł, większość publikacji na testerzy.pl jest jego autorstwa. A zatem podejmuje wyzwanie i otwieram blogowy kalendarz adwentowy. Nie będzie to zaplanowane, idealnie spójne jeżeli chodzi o treść wyzwanie, chcę wyrobić nawyk. O czym dziś?
Wiele razy spotkałam się ze stwierdzeniem “jak gdybym tylko robił swój produkt, wyglądałoby to całkiem inaczej” albo “praca w outsourcingu mnie nie kręci, poszukam pracy w firmie produktowej”. Zastanawia mnie, czym jest ten mityczny produkt IT, który postrzegany jest przez sporą grupę inżynierów jako coś lepszego? Postaram się obalić kilka mitów!
- Przez deadline klienta nie mam czasu na testy!
Nie ma znaczenia, czy jest to projekt pisany na zlecenie klienta, czy produkt kierowany bezpośrednio do odbiorców, zawsze będą terminy, które trzeba spełnić. Zwinna strategia testów będzie w tym przypadku pomocna, żeby zdecydować, na jakie testy postawić aktualnie. Jeżeli strategie widzisz jako obszerny dokument, opisujący podejście do zapewniania jakości to nie tędy droga. Podejdź do strategii testów na podstawie analizy ryzyka. Odpowiedz sobie na pytanie, w jakim stopniu jesteś w stanie podjąć zidentyfikowane ryzyko jeżeli wystąpi? Jeżeli skutki ryzyka są zbyt kosztowne (kary umowne, brak wdrożenia wytycznych, utrata użytkowników) testuj!
- Jakbym pisał kod w swoim produkcie byłby on lepszej jakości.
Czasem po prostu się nie da i nie jest ważne czy to produkt, czy outsourcing. Zasada “rób w porządku od początku” na ogół się sprawdza, ale nie w dobie silnej konkurencji na rynku. Jeżeli wydaje Ci się, że klient Cię nie rozumie, bo chce coś szybko, a przecież trzeba zrobić dobrze, albo mocno zależy mu na integracji z systemem, który uważasz za słaby, nie stawaj w mocnej opozycji. Postaraj się zrozumieć, dlaczego tak mu na tym zależy. Wielu inżynierów jest zainteresowanych wymaganiami funkcjonalnymi, niewiele osób pomyśli o wymaganiach niefunkcjonalnych, a jeżeli pomyśli to o security i performance. Ja często zaczynam od wymagań, które są zapisane kontrakcie. Umowy podpisane z partnerami, klientami, odbiorcami oprogramowania często definiują konkrety wpływające na to, co jako inżynierowie jesteśmy w stanie dostarczyć. #InżynierowieCzytajcieUmowy
- Produkt zaraz byłby w chmurze, a tak musimy się męczyć z tym nie skalowalnym środowiskiem.
Nie każdy produkt może opierać się o chmurę. Jeśli wytwarzasz oprogramowanie dla biznesu, który dotyka danych wrażliwych np. healthcare, wojsko itp. możesz zapomnieć o wykorzystaniu chmury publicznej i większości rozwiązań typu SaaS (System as a Service). Do tego, nie wszyscy dostawcy chmury posiadają certyfikację, która mówi o tym, że dane dla Twojego biznesu będą bezpieczne. Wywołuje Wojtka do tablicy, który opowie jutro o tym, jak to jest z tą chmurą i produktami.
- Praca w produkcie jest super, bo produkty piszą najlepsi inżynierowie.
W każdym środowisku znajdziesz ludzi, których fascynują nowości technologiczne, rozwój i hackatony po pracy, oraz takich, którzy po 16 chcą wyjść z biura i poświęcić czas na hobby niezwiązane z IT. Po prostu robią dobrą robotę do 16, nie samym softwarem człowiek żyje. Jeżeli ktoś w ramach hobby nie poświęca czasu na pisanie kodu po pracy w najnowszym frameworku, albo nie pojawia się na meetupach branżowych, nie musi znaczyć, że jest słabym inżynierem. W tym czasie może robić świetne zdjęcia uliczne i każdy wolny weekend uczyć się w szkole fotografii.
- W firmie produktowej mógłbym zająć się innymi dziedzinami niż tylko programowanie.
Nic nie stoi na przeszkodzie, żebyś zrobił to w firmie outsourcingowej, która ma prężnie działający dział marketingu, eventów czy rekrutacji. Jeżeli jesteś w stanie pomóc w innych dziedzinach, powiedz o tym głośno i nie marnuj swojego potencjału, jest to duża strata dla firmy. Dział marketingu możesz wesprzeć artykułami technicznymi, jeżeli firma organizuje eventy np. lokalne meetupy, możesz zostać prelegentem, a w rekrutacji bądź przy rozmowach technicznych. W każdej firmie możesz to zrobić, nieważne czy wytwarza ona projekty dla klientów, czy produkty.
Przekonałam Was? Czy dalej chcecie robić produkty? Jakie mity produktowe Wy spotkaliście? Dajcie znać w komentarzu, postaram się z nimi rozprawić!