Pytanie:
Szef akceptuje, ale następnie ignoruje politykę firmy proponowaną przez pracowników
sigy
2016-04-15 13:55:11 UTC
view on stackexchange narkive permalink

Pracuję w małej firmie programistycznej. Jesteśmy dość mali, mamy tylko 3-4 pełnoetatowych programistów. Zacząłem tam pracować jako asystent studenta około 8 lat temu i zacząłem pracować na pełny etat po ukończeniu studiów magisterskich z informatyki.

Moi koledzy i ja niejednokrotnie proponowaliśmy różne zasady dotyczące tego, jak naszym zdaniem moglibyśmy ulepszyć proces tworzenia (np. styl kodu, przeglądy kodu itp.). Omówiliśmy te propozycje w zespole i doszliśmy do porozumienia. Również nasz szef, który od czasu do czasu zajmuje się rozwojem, zgodził się na to i przedstawił to jako oficjalną politykę firmy, jednak często te zasady ignoruje. Na przykład. zatwierdza kod bez przeglądu kodu, który więcej niż raz spowodował przerwanie kompilacji. Zapytany o to, albo mówi, że to nic wielkiego i nie traktuje skargi poważnie, albo się obraża (w firmie panuje dość rodzinna atmosfera).

Bardzo mi to przeszkadza, bo ja nie myśl, że tak powinno działać tworzenie oprogramowania i uważam to za brak szacunku. W końcu to on jest szefem, a ponadto wygląda na to, że tylko mnie to denerwuje. Od czasu do czasu narzekają na niego również moi koledzy, ale rzadko z nim o tym rozmawiają. Więc może wyglądać na to, że tylko ja narzekam. Myślę też, że nie da się przekonać kolegów, żeby z nim o tym porozmawiali, bo dla nich to nie jest taka wielka sprawa.

Co mogłem zrobić? Czy to mój szef zachowuje się źle, czy też jestem zbyt wybredna?

Nie jesteś zbyt wybredny. Widziałem takie rzeczy wielokrotnie w małych sklepach z oprogramowaniem. Jeśli Twojego szefa, który jest również programistą, nie ma na pokładzie, aby wzmocnić proces rozwoju, to naprawdę nigdy się to nie wydarzy. Możesz ponownie spróbować z nim porozmawiać, a on albo zaakceptuje to, co masz do powiedzenia, albo się zdenerwuje. Tak czy inaczej, nawet jeśli zaakceptuje to, co masz do powiedzenia, prawdopodobnie będzie nadal robił to samo. Więc proponuję poszukać nowej pozycji w innym miejscu. Teraz masz już pojęcie, czego szukać podczas rozmowy kwalifikacyjnej na stanowisko w innej firmie.
1 słowo na: Gated Check Ins.
Trzy odpowiedzi:
Magnus Kirø
2016-04-15 15:15:20 UTC
view on stackexchange narkive permalink

Spróbuj inaczej spojrzeć na problem.

1: W niektórych miejscach brakuje ci przeglądu kodu. 2: wiesz, że ktoś niszczy twoje kompilacje, ignorując jakość kodu.

W moim zespole ustawiliśmy automatyczne kompilacje i zaczęliśmy dużo więcej testować. To daje nam wizualną zieloną informację zwrotną „Wszystkie testy przeszły” i czerwoną, gdy ktoś coś schrzanił. To rozwiązuje 1. w większości przypadków, ponieważ każdy chce rozwiązać niezaliczone testy.

W przypadku 2. możesz zacząć automatycznie odrzucać zatwierdzenia, które psują kompilację. Jeśli jest to problem dla szefa, masz argumenty za zaoszczędzeniem pieniędzy na szybkości rozwoju i stabilniejszych usługach dla swoich użytkowników.

Jeśli wdrożyłeś te kroki i nadal Ci się nie udaje, jest wiele inne prace dla Ciebie. Nie marnuj energii tam, gdzie Twój głos nie ma znaczenia.

Twoje środki zaradcze dla 2. lub podobnych technik zostały już zaproponowane. Mój szef, a także moi koledzy nie lubią żadnego wsparcia narzędziowego, które zmusza ich do robienia / nie robienia pewnych rzeczy. Kłócą się np. że czasami ** potrzebujesz ** wypchnąć zepsuty kod, aby zrobić coś szybko.
Potrzeba wprowadzenia zepsutego kodu do produkcji w dużej mierze zależy od tego, jak krytyczny jest Twój system. System, nad którym obecnie pracuję, obsługuje 4 wyszukiwania na sekundę, a jeśli to zepsuje, firma traci znaczną część przychodów. Pomijając to, myślę, że celowe wypychanie zepsutego kodu do produkcji jest samo w sobie bardzo złe. Sama koncepcja zepsutego kodu powinna rozwiać wszelkie wątpliwości, że kod musi trafić do produkcji. Myślę, że to wskazuje na większe podstawowe problemy w twoim miejscu pracy.
Nie prowadzimy ciągłych dostaw. Jednak rozumiem. I zgadzam się.
Kilisi
2016-04-15 14:39:53 UTC
view on stackexchange narkive permalink

Nie jesteś wybredny, masz rację, ale on jest szefem. Wy, programiści, ponosicie ciężar tej pracy, ale ostateczny wynik jest jego, jeśli są problemy. Więc robisz, co możesz, aby temu zaradzić, powtarzasz znaczenie. A kiedy to lekceważy, naprawiasz to. To twoja praca.

Zadaniem szefa jest zapewnienie Ci wynagrodzenia każdego dnia wypłaty.

Dodatkowym problemem jest to, że jestem kierownikiem bieżącego projektu, w którym pracuje. Jeśli projekt nie zostanie dostarczony na czas, nie dostanę premii, która w innym przypadku zwiększyłaby moje roczne wynagrodzenie o ~ 12%
W takim razie powinieneś być bardzo czujny, to DUŻA premia. Miej kopie zapasowe i całą resztę, cokolwiek się zepsuje, napraw to natychmiast. Wyczyść jego kod, gdy zajdzie taka potrzeba, lub poproś o to kogoś innego. Normalne rzeczy, aby projekt dotrzymał terminów w zadowalający sposób.
Jay Godse
2016-04-17 18:56:09 UTC
view on stackexchange narkive permalink

Podejdź do szefa z problemem i powiedz, że próbujesz go naprawić i potrzebujesz więcej informacji. Zadaj wiele pytań, aby zrozumieć jego motywację do napisania kodu, nawet jeśli wiesz, jak to naprawić. Możesz dowiedzieć się kilku rzeczy o tym, dlaczego zrobił to w ten sposób. A następnie napraw błąd. A następnie udokumentuj to w swoim cotygodniowym raporcie.

Jeśli szef naprawdę dba o wydajność zespołu, zda sobie sprawę, że jego naruszenia w procesie powodują, że spędzasz dodatkowy czas na naprawianiu jego błędów zamiast wykonywania własnej pracy, a to powoduje, że marnuje czas na wyjaśnienie jego kodu, abyś mógł naprawić jego błąd. W tym momencie prawdopodobnie będzie mniej kodował lub lepiej postępował zgodnie z procesem.

Jeśli nie dba o wydajność zespołu, przynajmniej robisz pewne postępy w naprawianiu jego rzeczy, a nie brak postępu z powodu zepsutych kompilacji.



To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...