Czy według Ciebie i Twojego doświadczenia jest to dopuszczalne zdanie w pewnych okolicznościach? W miejscu pracy zawsze jest źle?

Kiedy ktoś mówi „Nie płaci się za myślenie, ale za zrobienie X”, nie należy tego brać dosłownie. W każdym przypadku płaci się za choć trochę pomyśleć, w przeciwnym razie robot wykonywałby twoją pracę.

Zwykle tego wyrażenia używa się do odcięcia powtarzających się, nieproduktywnych argumentów i jako dyrektywy, aby rozpocząć pracę.

Z mojego doświadczenia wynika, że ​​jest to głupie stwierdzenie, którego ktoś używa. Nie oznacza to, że domniemany powód („zbyt dużo kłótni, za mało pracy”) jest błędny, tylko że zazwyczaj istnieją lepsze sposoby, aby to powiedzieć.

W tym konkretnym przypadku tester był wyraźnie niewłaściwe wprowadzanie opinii do zadań Jira zamiast testowania i zgłaszania błędów zgodnie z oczekiwaniami. Współpracownik z innego zespołu, który złożył oświadczenie, również był niewłaściwy.

Kierownictwo powinno pomagać każdemu w zrozumieniu ich ról i tego, ile osobistych opinii powinno być zaangażowanych. Gdybym był dyrektorem ds. Kontroli jakości, odbyłbym długą rozmowę zarówno z testerem, jak i współpracownikiem. Powinni dążyć do tego samego celu, a nie biernie-agresywnie strzelać do siebie nawzajem.

Jeśli pracujesz w branży IT, otrzymujesz wynagrodzenie za myślenie.

Zdanie, które opisujesz, może być najbardziej niepoprawną rzeczą, jaką kiedykolwiek słyszałem w swojej karierze IT . Żaden personel IT nigdy nie jest opłacany za myślenie, bo inaczej jego praca byłaby zautomatyzowana.

Wygląda na to, że prawdziwym problemem jest to, że Twój współpracownik po prostu nie korzysta z właściwych kanałów aby zakomunikować możliwe ulepszenia, decydując się na umieszczenie ich w tematach związanych ze śledzeniem błędów zamiast w tematach sugestii / ulepszeń.

Kilka możliwych alternatywnych zdań, których możesz użyć.

• Weźmy tę dyskusję do [bardziej odpowiedniej tablicy / tematu]
• Proszę prowadzić tutaj dyskusje ściśle związane z błędami
• Dobry pomysł / punkt, ale czuję, że ta rozmowa może być bardziej odpowiednia dla [bardziej odpowiednia tablica / temat]

Jest o wiele więcej zdań, których można użyć, aby przekazać swój punkt widzenia, nie sprawiając, że kolega poczuł się bezwartościowy.

To nie jest produktywna odpowiedź z kilku powodów:

1. Jest to wyjątkowo niegrzeczne.
2. To dewaluuje osobę odpowiedzialną za kontrolę jakości na poziomie osobistym i zawodowym.
3. Nie wyjaśnia w odpowiedni sposób, dlaczego zachowanie osoby odpowiedzialnej za kontrolę jakości było nieodpowiednie, co prowadzi do ...
4. Może to spowodować, że osoba ta przestraszy się wykonywania swojej pracy i zachowania należytej staranności.

Z powodu tego wybuchu możliwe jest, że osoba odpowiedzialna za kontrolę jakości zauważy coś poważnego, co wykracza poza zakres jej obowiązków zawodowych, i nie zgłosi tego, a cała firma może na tym ucierpieć.

Współpracownik B ma rację, że osoba odpowiedzialna za kontrolę jakości nie wykonuje prawidłowo swoich obowiązków zawodowych i ma to wpływ na innych pracowników i samą firmę. Współpracownik B nie miał racji, mówiąc to zdanie. Muszą przeprosić, a potem musi się odbyć jakieś spotkanie, aby wyjaśnić, w jaki sposób należy zgłaszać sugestie i komentarze, aby projekt ruszył naprzód.

„Nie płaci się za myślenie, ale za zrobienie X” jest zawsze złe w miejscu pracy?

Może nie, ale zawsze jest to czerwona flaga. Coś może być gdzieś nie tak i należy się tym zająć.

Jeśli to wyrażenie „ucieka” czasami, może to nie być koniec świata, ale jeśli stanie się mantrą, „statek” jest prawdopodobnie tonie. Znajdź zdrowszy, silniejszy statek.

Oczywiście jest jeszcze inna strona problemu - mnóstwo komentarzy, ich jakość i to, co z nimi zrobić zawodowo.

Pierwszą rzeczą do zrobienia jest obiektywna analiza komentarzy : czy są one naprawdę przydatne do ulepszania procesu / testowania / produktu?

• Jeśli tak , muszą nadejść, być może innym kanałem - aby uniknąć zatopienia projektu.
• Jeśli nie , inżynier testowy musi wyjaśnił, czego oczekuje się od systemu komentarzy i jak pisać lepsze komentarze - a także, że można nie pisać żadnych komentarzy, jeśli nie są one potrzebne.

Następna rzecz, polega na przeanalizowaniu wpływu i pilności komentarzy. Na tej podstawie zostanie ustalone priorytety. Następnie działania wynikające z komentarzy muszą być zaplanowane do wdrożenia w projekcie.

Konkluzja: IT bez myślenia to recepta na katastrofę . Prędzej czy później. Tak, czy inaczej. Przykłady można znaleźć w niezliczonych książkach drukowanych i w Internecie.

„Nie płaci się za myślenie, ale za przeprowadzanie testów”

Wypowiadanie się w ten sposób jest zawsze nie do przyjęcia. Rozwiązywanie problemów, krytyczne myślenie i synteza to powody, dla których organizacje zatrudniają ludzi - sugerowanie, że to nie jest ważny wkład ze strony współpracownika, jest pozbawieniem praw wyborczych i brakiem szacunku.

Twój kolega mógł próbować wyrazić frustrację lub prowadzić coaching, ale ten konkretny komentarz też nie był produktywny. Przykro mi, że tego doświadczyłeś.

Ujmowanie tego w ten sposób jest oczywiście niegrzeczne. Lepszym sposobem byłoby: „Nie wykonujesz swojej pracy. To, co robisz, to marnowanie czasu wszystkich i to kosztuje firmę”. (Było to również błędne co do faktów. QA opłaca się myśleć. Właściwe myślenie pozwoliłoby uniknąć tych JIRA, które marnują czas i pieniądze).

Ale zadaniem kontroli jakości jest zapewnienie, że produkt jest odpowiedniej jakości do sprzedaży / wysyłki. Będą produkować JIRA, jeśli wystąpią problemy, które programista musi naprawić.

Jeśli pracownik ds. kontroli jakości zalewa programistów sugestiami opartymi wyłącznie na opiniach, jest to nieproduktywne. Deweloper nie chce i absolutnie nie powinien dokonywać zmian z powodu takiej sugestii. To powinno trafić do menedżera produktu, który powinien zdecydować, co należy zrobić, i stworzyć zadania, aby wprowadzić taką zmianę lub nie tworzyć takich zadań.

Wygląda na to, że ten pracownik ds. kontroli jakości marnował czas programisty. Od kontroli jakości oczekuję, że JIRA to coś nie działa tak, jak powinno. I czasami , aby uzyskać JIRA, gdy coś działa zgodnie z projektem, ale sposób, w jaki jest zaprojektowany, nie jest dobry. Nie spodziewam się, że zostanę zalewany setkami JIRA, które odrzucę.

Może więc dojść do sytuacji, w której marnowanie czyjegoś czasu spowoduje chamstwo. Jak powiedziałeś dalej, wydaje się, że zadziałało. Pracownik kontroli jakości nie rozumiał swojej pracy, nie wykonywał swojej pracy, co miało złe konsekwencje (opóźnienia) dla firmy, a niegrzeczność spowodowała skutek - przyczyna niegrzeczności została naprawiona. Ktoś, jak przypuszczam, wyjaśnił mu swoją pracę.

PS. Jeśli osoba odpowiedzialna za kontrolę jakości nie tylko zmarnowała czas, ale opóźniła cały projekt, dodając komentarz „ Myślę, że ten przycisk powinien być zielony zamiast niebieskiego” po wielokrotnym powiedzeniu mu, że nie powinien robić tego rodzaju bzdur, a następnie powiedziano „Nie płaci się za myślenie” jest zrozumiałe.

Sedno sprawy polegało na tym, że główny tester projektu zalewał zadania Jira setkami komentarzy z sugestiami

Osobiście widzę, jak byłoby to denerwujące, gdyby musisz przeczytać każdą linię, aby dowiedzieć się, czy jest błąd. Byłoby to również wyjątkowo bezproduktywne, gdyby pomysł został już sprzedany firmie, a komentarze musiałyby zostać ponownie ocenione przez firmę.

Chciałbym po prostu zauważyć, że komentarze nie są produktywne, ponieważ pomysł jest już sprzedany i tak chce tego biznes. Chciałbym również zauważyć, że pisanie setek komentarzy przyniosłoby skutki odwrotne do zamierzonych, ponieważ trudno jest rozszyfrować rzeczywiste błędy, a jeśli są one jedynie komentarzami.

Myślę, że krzyczenie, że nie płaci się za myślenie, byłoby nieproduktywne, ale zrozumiałe wybuchy. Chciałbym skorzystać z tej okazji, aby podkreślić sedno sprawy.

„Nie płaci się za myślenie” jest wyjątkowo niegrzecznym i świetnym sposobem na spalenie pracownika

Utrzymuj otwarte kanały komunikacji

Dobry tester QA zagłębi się w tworzony przez ciebie system i dostrzeże rzeczy, których nie ma specjalnie polecać. Mają doświadczenie w badaniu oprogramowania i mogą mieć cenny wkład. Naprawdę nie chcesz zamykać tego kanału informacji.

... Ale dbaj o porządek

Jednak Twoja firma ma proces śledzenie błędów (dobrze), z regułami mówiącymi, że błędu nie można zamknąć, dopóki wszystkie komentarze nie zostaną rozwiązane (dobrze), a tester umieszcza komentarze nie na temat (źle). Musisz skłonić testera do umieszczenia swoich danych wejściowych we właściwym miejscu, a nie w złym miejscu. Krótko mówiąc, możesz zacząć używać tekstu takiego jak:

„Komentarz zamknięty, nie na temat. W tym celu zgłoś osobny problem w (odpowiednim miejscu)”.

Musisz się upewnić, że odpowiednie miejsce faktycznie istnieje i działa. Jeśli Twój tester nie ma odpowiedniego miejsca, aby zgłosić „Też zauważyłem” rzeczy, na które ludzie reagują, oznacza to, że sam ściągnąłeś ten problem na siebie.

Zastanawiam się, czy Twój obecny proces komunikacji polega tylko na zadawaniu konkretnych pytań (przypadkach testowych)? Gdzie tester ma się udać, jeśli ma coś do zgłoszenia, o co nie pytano? Czy ten kanał jest traktowany poważnie? Umieszczanie komentarzy w pozycji „musi rozwiązać wszystkie komentarze przed zamknięciem”, raporty o błędach mogą być wołaniem o pomoc.

Wyjaśnij, że „nie zadziała”

To nie jest rola QA w decydowaniu o funkcjach produktu. Aby stworzyć udany produkt, musisz także zdecydować, których funkcji nie będziesz używać. Ponieważ nie są potrzebne lub niewystarczająco wartościowe, aby dodać je w ostatniej chwili i ryzykować przekroczenie terminu. Musisz wyjaśnić swojemu testerowi, że chociaż cenisz sugestie, nie oznacza to, że faktycznie zastosujesz je wszystkie.

Zrób różnicę między zwracaniem uwagi na sugestie a ich przyjęciem. Jeśli tester proponuje funkcję lub ulepszenie, a Ty zdecydujesz się tego nie robić, potwierdź to, zamiast sprawiać wrażenie, jakbyś nawet nie widział sugestii.

To wyrażenie jest dopuszczalne tylko wtedy, gdy próbujesz odgrywać rolę tyrana i jest zwykle używane przez złego menedżera. Zwykle po prostu wskazuje, że osoba, która go używa, albo nie radzi sobie z argumentem, albo nie może słuchać innych osób. Inną formą tego wyrażenia jest „ponieważ tak powiedziałem”. W twoim przypadku brzmi to jak prosty sposób na odcięcie się od drugiej osoby. Nie wybieram żadnej strony w walce, ale widzę to z obu stron (jako QA lub jako programista, ponieważ mam doświadczenie w obu). Osobiście w sytuacji, którą opisałeś, odkryłem, że o wiele bardziej produktywne jest otwieranie oddzielnego biletu dla inna pozycja: w przypadku otwarcia QA oddzielne zgłoszenie pozwala upewnić się, że podniesiony problem zostanie rozpatrzony. Jako programista wolę, aby bilet, nad którym obecnie pracuję, nie urósł do obszaru pełzania zakresu. Więc kiedy ktoś zaczyna wprowadzać wiele niepowiązanych komentarzy do zgłoszenia, poprosiłbym go o utworzenie nowego lub utworzenie go samodzielnie.

Jednak jest kilka rzadkich przypadków, w których funkcja została zaimplementowana, praca zgodnie z oczekiwaniami i na papierze wygląda fantastycznie w prawdziwym życiu nie ma sensu. Większość z nich zazwyczaj łapie dobra kontrola jakości i te najtrudniejsze, ponieważ wszyscy dali z siebie wszystko, ale wynik jest zerowy lub negatywny. Zawsze zwracam uwagę na jakąkolwiek wskazówkę dotyczącą takich informacji zwrotnych z kontroli jakości i staram się przenieść ją z powrotem na deskę kreślarską. Zazwyczaj taka informacja zwrotna pojawia się w bilecie jako niepowiązany komentarz. W takim przypadku wolałbym porozmawiać z osobą przekazującą takie informacje, aby dowiedzieć się, czy tak jest, czy nie. Jeśli rozmowy z osobą komentującą rzeczywiście kończą się takim przypadkiem, należy zareagować w ten sposób, w przeciwnym razie poproś osobę o utworzenie zgłoszenia lub utworzenie go dla niej. Wolę mieć zgłoszenie w zaległościach, które mogą zostać odrzucone w przyszłości, zamiast przegapić ważne informacje zwrotne.

Zasadniczo, kiedy dochodzisz do punktu, w którym rozmowa może się nieco rozgrzać, bardziej produktywne jest oddychanie, powiedz coś w stylu „Muszę o tym pomyśleć i mam zamiar odpowiedzieć w zgłoszeniu”, zregeneruj się twój spokój, napisz i jeśli jesteś pewien, że masz rację, napisz swoje argumenty w zgłoszeniu, dlaczego jest to nieistotne / nieważne / nie ma teraz znaczenia. Jednak jest to miecz obosieczny, ponieważ jeśli druga osoba miała rację, a ty nie, to teraz to udokumentowałeś.

I pamiętaj, że wszystkie takie rzeczy nie powinny być postrzegane jako deweloperzy (dba vs backend vs ui) vs QA vs klient vs ktokolwiek. Relacja powinna wyglądać następująco: programista + kontrola jakości + klient + ktokolwiek = świetny produkt . Przebywałem w środowiskach z silnym „wolnym dla wszystkich”, w których działałem na zasadzie współpracy i w zamian byłem tak traktowany.

Testy to nieco szczególny przypadek, jeśli chodzi o pracę IT. Szczególnie formalne, zwłaszcza testy regresji.

Jeśli test jest wcześniej udokumentowany (co jest zrobione, aby go przetestować), a wyniki są ostatecznie zredukowane do PASS lub FAIL, wynik końcowy nadal mówi „X, Y , Z ... zostało wykonane, z wynikiem ... ".

X, Y, Z można zdefiniować w specyfikacji umowy z klientem, modyfikacja testów może spowodować redystrybucję odpowiedzialności w bardzo niefortunny sposób, jeśli defekt ujawnia się (lub w najgorszym przypadku powoduje rzeczywiste uszkodzenie), który BYŁby złapany, gdyby procedura testowa była dokładnie przestrzegana. Drugą stroną tej monety jest to, że jeśli wada nie zostałaby wykryta przez określone i uzgodnione testy, w zależności od umowy, produkt może być nadal sprzedawany i zafakturowany zgodnie ze specyfikacją, środkowy palec wliczony w cenę. >

Z szerszej perspektywy praca (do specyfikacji) mogła już zostać opisana, zaoferowana, skalkulowana i SPRZEDANA. Chociaż modyfikacja po fakcie może podnieść wydajność (już obliczoną!), Podnosi również ryzyko (już obliczone!).