Jak nie ustępować, gdy koledzy zaniedbują ten proces?

14

Problem, przed którym stoję:

Członkowie mojego zespołu rozpoczynają pracę nad projektami bez przygotowania dokumentów funkcjonalnych / technicznych - nawet jeśli proces naszej firmy nakazuje, aby były one dostępne przed rozpoczęciem.
Członkowie mojego zespołu akceptują tanie, nieustrukturyzowane rozwiązania i zaimplementują naprawdę złe hacki w oprogramowaniu, nie zastanawiając się dwa razy, gdy kierownictwo projektu zauważy , że mają „ograniczony czas”.
Członkowie mojego zespołu rozpoczynają pracę nad projektami, które współpracują z niedokończonym projektem innego zespołu - który jest nieprzetestowany i niedokończony. (powodując dużo dodatkowej pracy).
Ulepszenia i cała faza (etapy) oprogramowania nie są właściwie planowane i często skutkują tym, że front-end / projektowanie nie jest ukończone, gdy programista back-end musi rozpocząć pracę.

Problemy te były omawiane bez końca wiele razy, odkąd zacząłem tutaj pracować. Wszyscy zgodzili się, a dolna linia było to, że musi egzekwować ten proces, co oznacza, że deweloper back-end nie rozpocznie się, dopóki wszystko jest załatwione.

Te problemy wciąż się zdarzają - i jestem tak naprawdę motywowany do tego stopnia, że denerwuję się samą pracą i kilkoma moimi kolegami.

Członkowie mojego zespołu narzekają dużo - ale tylko wobec siebie. They keep on going - whatever the situation is. Wynik?

Staję się niepewny, może to ja?
Czy tak właśnie powinno być?

Moje pytanie? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

To nie wygląda jak denerwujący programista, który cały czas szuka czegoś, co można suka.

project-management teamwork

— Wesley van Opdorp
źródło

Zadaniem kontroli jakości jest upewnienie się, że proces jest przestrzegany.

— mouviciel

Mamy zespół zarządzający, sprzedaży, zarządzania projektami i programistów. Brakuje kontroli jakości - niestety.

— Wesley van Opdorp

Rola procesu nie jest jasna dla wszystkich i dlatego nie jest stosowana tak, jak powinna. Oto dlaczego istnieje kontrola jakości: wymuszająca zastosowanie procesu. Definiowanie procesu bez osób odpowiedzialnych za jego egzekwowanie jest jak definiowanie prawa bez policji i sędziów.

— mouviciel

Co powiedział twój szef, kiedy rozmawiałeś z nim o tym?

8

Czy wszyscy naprawdę zgodzili?

Kiedyś miałem sytuację, w której chcieliśmy usprawnić procesy. Stworzyliśmy propozycję innego Procesu i wszyscy wydawali się zgodzić.

Ale potem, za każdym razem, gdy chciałem śledzić ten proces, pojawiał się wyjątek z powodu „ważniejszych spraw”, który na pierwszy rzut oka zawsze brzmiał rozsądnie. W efekcie proces ten nigdy nie był realizowany de facto, ale wszyscy myśleli „w zasadzie postępujemy zgodnie z tym procesem”.

Problem polegał na tym: jeśli zaproponujesz poprawę, nie ma nikogo, kto się nie zgadza (kto nie lubi ulepszeń?). Ale jeśli przedstawisz koszty, zwykle istnieje spór. A utrata wygodnego sposobu robienia rzeczy jest ogromnym kosztem dla większości ludzi.

Aby to zademonstrować, sformułowałem Pytanie inaczej: „Proszę nadać priorytet wszystkim tym, co powinienem zrobić (wdrażanie funkcji, usuwanie błędów, postęp w ulepszonym procesie, sprzątanie biurka, przybycie na czas)”.

Po zakończeniu procesu skończyło się sprzątaniem biurka i nie spóźnieniem się 5 minut. Zasadniczo zgodzili się na coś zupełnie innego niż zaproponowałem.

Problemem może być to, że nie chcą ponosić kosztów jakości. Może to doprowadzić ich do zracjonalizowania twojej krytyki jako marudzenia, ale z mojego doświadczenia wynika, że tak nie jest. Dług techniczny może nie być tak widoczny i łatwo przypisać go okolicznościom, ale ostatecznie rzeczywistość się pojawia.

Mam nadzieję, że do tego czasu zdali sobie sprawę, albo zmieniłeś Jobsa.

— keppla
źródło

2

„Podążanie za ulepszonym procesem” jest jedyną opcją bez celu, więc wynik nie jest niczym nieoczekiwanym. W tym kontekście brzmi to bardziej jak „podążanie za procesem dla samego procesu”, a nie działanie ukierunkowane na cel (wyższa jakość, wydajność itp.).

— MaR

„ulepszony proces” jest krótkoterminowy dla takich rzeczy jak „przetestuj przynajmniej powierzchownie przed wdrożeniem”, i to jest zorientowane na cel: celem jest ograniczenie pracy niezbędnej do późniejszego czyszczenia, co nieuchronnie się wydarzyło. To nie tak, że wyciągnąłem proces z powietrza i uczyniłem z niego dogmat. Wywodzi się z powtarzających się problemów, które miały wpływ na wydajność. To, co nazywam „procesem” w tym poście, było mniej więcej zgodne z 2 lub 3 elementami testu Joela.

— keppla

1

chciałem podkreślić, że ważne jest, jak sprzedajesz „proces”. Powiedziałbym, że „test przynajmniej powierzchownie przed wdrożeniem” uzyskałby wynik znacznie lepszy niż „postęp w ulepszonym procesie” w porównaniu z „czyszczeniem biurka”.

— MAR

@ MaR: Zgadzam się, zaniedbałem ten aspekt w moim poście. W pracy nie powiedziałem „proszę postępuj zgodnie z procesem”, ale raczej coś w rodzaju „uzgodniliśmy, że musimy najpierw przetestować, aby ponownie nie irytować klienta zepsutą usługą. Dlaczego teraz to ignorujemy?

— keppla

3

Być może to ty

Wydaje się, że preferujesz bardzo ustrukturyzowany i zorganizowany sposób kodowania, a twoi koledzy z drużyny wydają się mieć podejście bardziej „załatwione”. Teraz wspominasz, że prowadzi to do dużo „zmarnowanego czasu”, więc być może pewna struktura jest w porządku i nie ma usprawiedliwienia dla niechlujstwa. Jednak projekty oprogramowania są zazwyczaj płynne, a egzekwowanie zbyt dużej struktury spowoduje również znaczne obciążenie organizacyjne.

Być może powinniście wszyscy spotkać się w środku i wypróbować bardziej zwinne i interaktywne, ale ustrukturyzowane podejście.

— Homde
źródło

1

Jeśli koledzy z drużyny nie lubią „swojego” podejścia, dlaczego się zgodzili? Czytając jego post, nie mam wrażenia, że to była jego propozycja. I nawet płynne podejście nie działa bez specyfikacji, różnicą jest moim zdaniem nie brak, ale wyraźny prowizoryczny charakter specyfikacji.

— keppla

Po pierwsze, niezgadzanie się z czymś nie jest tym samym, co angażowanie się w coś :) Być może jego koledzy z drużyny nie widzą innych alternatyw. Nawet jeśli proces ten był pomysłem kierownictwa, być może może być konieczne dostosowanie go do rzeczywistości, aby zapewnić akceptację wszystkich stron. Zgadzam się, że muszą istnieć pewne specyfikacje, ale niestety czasami określenie czegoś może być tak trudne, jak jego zbudowanie. Zwinny, iteracyjny proces może umożliwić krystalizację specyfikacji w miarę ich

— upływu

Wyraźnie stwierdził, że jego zespół zgodził się, a nie, że się nie zgadzali. Proszę, nie zrozumcie mnie źle, nie jestem przeciwny zwinnym procesom, ale one też są takie: procesy, które wymagają co najmniej podstawowego zaangażowania. Jeśli wszyscy zignorują awarię, nikt nie będzie miał zaległości, „specyfikacje” to tylko „nawiasem mówiąc…”, które dostaje się, przechodząc obok menedżera, nawet zwinny proces umiera. Z mojego doświadczenia wynika, że nie jest to nawet malowanie czarnego obrazu. Nie każda firma jest Google. Większość wydaje się ponownie dokładniej zamieniać dilbert.

— keppla

2

Zgadzam się, muszą znaleźć proces, w który każdy może się wkupić. Umowa Tacid nic nie jest warta. Prawdopodobnie muszą eksperymentować i zobaczyć, co dla nich działa, albo to, albo jego koledzy z drużyny są po prostu niekompetentni i muszą zostać zwolnieni :) Zauważyłem jedną rzecz dotyczącą procesów, chociaż nawet jeśli jest wpisowe, często musi być co najmniej jedna „nazistowski proces”, który zapewnia, że proces staje się nawykiem. Działa tylko wtedy, gdy proces ma wpisowe

— Homde

... Btw, nie użyłbym google jako dobrego przykładu procesu. Wydaje się, że cierpią na poważny przypadek inżynierii z powodu dużego obciążenia strukturalnego. Ostatnio słyszałem, że próbują wrócić do swoich początkowych korzeni

— Homde

2

Kto jest odpowiedzialny za te osoby? Ktoś ich wynajął i ktoś może ich zwolnić / pociągnąć do odpowiedzialności.

„Moja firma wymaga ...” jest bez znaczenia bez pewnego egzekwowania.

Nie można stawiać wymagań czasowych, które nie pozwalają na proces produkcyjny.

Wydaje się, że ten brak kontroli i nierealne oczekiwania są przyczyną niskiej jakości.

Możesz: odejść, zostać głównym programistą, nic nie robić lub rozpocząć pracę z tymi, którzy czują się tak, jak Ty. Upewnij się, że wszyscy wiedzą, że będziesz postępować zgodnie z prawidłowymi procedurami, dopóki ktoś nie znajdzie lepszego sposobu i je zmieni. Brzmi jak „The Cider House Rules”.

— JeffO
źródło

2

Wygląda na to, że nie chcesz, aby Twoi współpracownicy wykonywali zupełnie inny proces, po prostu chcesz, aby podejmowali w nim różne decyzje. Jasne, istnieją zasady (wytyczne?) Dotyczące tego, co powinni robić i ignorują je. Problem, który opisujesz, polega na tym, że muszą podjąć decyzję (rozpocząć pracę nad projektem lub odrzucić specyfikację) i zdecydować się kontynuować. Ta decyzja nie ulegnie zmianie, jeśli będziesz nadal przypominał im o zasadach; po prostu nie dbają tak bardzo o zasady jak ty . Chcą czuć się przydatni, a powiedzenie „nie” nie sprawia, że czują się przydatni .

Jeśli chcesz, aby ich zachowanie się zmieniło, ciągłe przypominanie im o regułach prawdopodobnie nie jest zbyt skuteczne; bardziej prawdopodobne jest, że cię zignorują. Spróbuj znaleźć sposób, aby zmienić proces, aby poczuli się bardziej przydatni, jednocześnie kontynuując proces. Czy potrafisz zaimplementować przegląd kodu, sprawdzanie kodu i uczenie się od siebie nawzajem, aby zapobiec włamaniom do kodu produkcyjnego? Czy możesz zmienić sposób, w jaki specyfikacje (docs / ext.interfaces / front-end) są obsługiwane z czarno-białej gotowej / niedokończonej decyzji na bardziej kooperacyjny proces, w którym pod koniec specyfikacji prosi się programistę pomóc zakończyć? (I powinieneś zaakceptować to, że wymagania się zmienią)

Przeważnie to nie ty, to nie oni, to proces. Jeśli ty (i twój PM) potrafisz znaleźć sposób na zorganizowanie rzeczy, w których ludzie nie muszą tak bardzo sprzeciwiać się swojej postaci, proces ten będzie przebiegał znacznie szybciej.

— Jaap
źródło

2

Chodzi o punkt, w którym zameldowałbym się z sesją przy zamkniętych drzwiach z moim zespołem. Mamy nadzieję, że masz wystarczająco dobre relacje robocze z potencjalną szansą, że możesz uczynić to bardzo nieformalnym.

Celem spotkania jest ustalenie, dlaczego ustalenie, zespół robi rzeczy tak, jak je robi. Jeśli wszyscy się spotkali, kiwnęli głowami, uśmiechnęli się i zgodzili na nowy proces, to dlaczego nadal się nie zmieniają? Są duże szanse, że biegnie ona o wiele głębiej niż zwykła beztroska lub niekompetencja. Prawdopodobnie w pracy są kierowcy niewidoczni gołym okiem.

Rozpocznij spotkanie, zakładając, że Twoi współpracownicy wykonaliby, gdyby mogli, proces, który prowadzi do mniejszej paniki, mniej długu technicznego i wyższej jakości produktu - w końcu kto tego nie chce? Więc jaka jest niewidoczna siła?

Wygląda na to, że przed początkowym projektem i prototypem interfejsu użytkownika jest dużo implementacji / integracji. Czy w firmie brakuje osób, które mogą wykonać taką pracę z góry? Może mógłbyś się zgłosić? Czy istnieje problem z osiągnięciem porozumienia z interesariuszami? Może Twój zespół może znaleźć nowy sposób komunikowania się z nimi lub może przyjąć nowe podejście do dokumentowania założeń.

Jeśli zaczniesz od pojedynku, w którym zapytasz prowadzącego, dlaczego , możesz otworzyć drzwi do dyskusji, która pozwala uniknąć obrony i skupia się na problemach i rozwiązaniach.

Inną sztuczką może być pytanie, czy możesz być pionierem nowego sposobu robienia rzeczy. Poparcie od swojego zespołu prowadzi do wymuszenia nieco tego problemu i pozwala ci przyjąć podejście, które zalecasz - prawdopodobnie pojawią się problemy, gdy zburzysz „system”, więc chcesz, aby zarządzanie za tobą. Ale jeśli okaże się, że jesteś bardziej produktywny i bezstresowy, zapewnisz dobrą okazję do zmiany sposobu i prawdopodobnie zdobędziesz zwolenników.

— bethlakshmi
źródło