Jak przekonać moich współpracowników, że robienie rzeczy pozwoli im zaoszczędzić czas

Niedawno zacząłem w nowej firmie z garstką programistów. Jest to firma średniej wielkości, zatrudniająca około 70 pracowników, ale dział IT ma tylko 9–10, a obok mnie jest 3 „programistów”. Jednak ci faceci mają bardzo ograniczone doświadczenie i robią wiele rzeczy naprawdę okropnie. Na przykład jednym z naszych projektów jest strona internetowa PHP. Większość kodu jest przechowywana w 20 000 liniowym kontrolerze PHP, z ~ 6000 liniami JavaScript wbudowanymi w PHP.

Ciągle robię małe sugestie tu i tam, ale nikt nie słuchał, wszyscy mówią, że są zbyt zajęci, aby wdrożyć moje sugestie. Chodzi o to, że nie powinni być tak zajęci i nie byliby, gdyby wszystko zostało zrobione dobrze. Większość czasu spędzają na naprawianiu rzeczy, które ciągle się psują. Jeśli każdy projekt został poprawnie zbudowany, mógłbym to wszystko zrobić sam.

Jakie podejście powinienem zastosować, aby przekonać tych gości lub kierownika, że ​​rzeczy muszą się zmienić, a zmiana rzeczy pozwoli zaoszczędzić sporo czasu? Czy powinienem pominąć próbę przekonania moich współpracowników i udać się bezpośrednio do kierownika z propozycją biznesową, w jaki sposób firma zaoszczędzi mnóstwo pieniędzy, jeśli zaczną robić wszystko poprawnie?

Odkryłem, że główną przyczyną niechlujstwa w pracy, poza tym, że programista po prostu nie dba o to, jest brak wiedzy. Niestety w wielu środowiskach brakuje wiedzy, a nie dyskusji.

Niektóre techniki, które z powodzeniem wykorzystałem do wspierania dyskusji, rozwoju i ogólnej ekscytacji programowaniem to:

• Cotygodniowe sesje technologiczne z brązową torbą (poproś o zbadanie tematu i prezent)
• Codzienne lub cotygodniowe sesje mentorskie pomiędzy młodszymi i starszymi członkami.
• Recenzje kodu (z naciskiem na naukę, a nie na wskazywanie błędów).

Uczenie się jest zaraźliwe. Kiedy sprzyjasz środowisku, które zachęca do nauki, nie tylko produkujesz lepszych programistów, ale także pokazujesz innym członkom swojego zespołu, że są oni częścią czegoś większego niż sposób na wypłatę.

Po zobaczeniu, że zostałeś zatrudniony jako starszy programista PHP i Twoim zadaniem jest naprawienie rzeczy, sugeruję, aby nadszedł czas, abyś rozluźnił mięśnie.

Gdybym był na twoim miejscu, dobrze zbadałbym kod i dostrzegł błędy, które zdarzają się w kółko. Co tydzień blokuj czas spotkań, aby omówić te kwestie z zespołem. Nie wskazuj palcami ani nazwiskami, po prostu pokaż, jak poprawnie wykonać to zadanie.

Następnie, skoro już widziałeś, że trzeba naprawić, utwórz listę. Jeśli jest to szybkie i łatwe, zrób to. Jeśli to ułatwi ci życie ... zrób to. Zrób listę wszystkich rzeczy, które należy zrobić, i kup im bilety i zobacz, kiedy ludzie mają cykle, aby to zrobić. Jeśli ktoś naprawia błąd w obszarze problemu, pokaż mu, jak go naprawić.

Jeśli wymaga to dużej zmiany, usiądź z zespołem i zainteresowanymi stronami i omów opcje.

Miej politykę otwartych drzwi, w której będziesz pomagać ludziom. Bądź kimś, kto kształci, a nie onieśmiela. Nie, „musisz to zrobić w ten sposób” i więcej „byłoby lepiej, gdyby zrobiono to w ten sposób”. Wyjaśnij zalety robienia tego tak, jak sugerujesz, oraz wady sposobu, w jaki zostało to zrobione. Ludzie będą bardziej skłonni zrobić to we właściwy sposób, jeśli poczują, że czegoś się nauczyli, zamiast powiedzieć im, że ich droga jest zła, i zrobić to w inny sposób, jak mówisz.

Perspektywa zarządzania dla problemu Jeśli zaakceptowali czas rozwoju w stosunku do ilości wad, dlaczego mieliby to ryzykować? Kiedy świadczenia długoterminowe są sprzeczne z celami krótkoterminowymi, zwykle tracą. Prosimy ich o cofnięcie się o krok. Mogą myśleć, że spowoduje to długie opóźnienie. Musisz ich przekonać, że nie przyniesie to dodatkowych korzyści. Jeśli nie uważają, że mają bałagan, poproś ich o wyjaśnienie, dlaczego tak długo zajmuje wprowadzenie nowych błędów przy każdej „poprawce”.

Jakość kodu zależy od wielu okoliczności i sytuacji. Sprzedaż, marketing i menedżerowie sprawią, że uwierzysz, że każdy niedotrzymany termin oznacza, że ​​firma przegapi ten jeden strzał w milionowego inwestora venture capital. W rzeczywistości nie chcą przekazywać złych wiadomości 1% klientów, którzy tak naprawdę nie potrzebowali tej funkcji. Jestem ekstremalny i zwykle spada gdzieś pomiędzy, więc programiści muszą dowiedzieć się, co jest prawdziwą sytuacją awaryjną. Wtedy łatwiej jest przekonać ich, aby poświęcili czas na zrobienie tego dobrze, niż na to, aby to zrobić. Musisz zrozumieć ryzyko.

Podobnie jak świetna powieść, kod po raz pierwszy nie jest dobrze napisany, ale niestety wciąż jest zbyt często publikowany. Zacznij od czegoś fundamentalnego, takiego jak ustanowienie standardu kodowania. Każdy ma jeden, ale wielu podobnie jak w twojej sytuacji, nie zostały sformalizowane ani nie są bardzo surowe. "Rób co chcesz." to bardzo łatwy w utrzymaniu standard. Następnym krokiem jest ustalenie, w jaki sposób zamierzasz utrzymać swoje standardy.

Przed tobą wielkie zadanie. Być może kilku świetnych programistów rozwinęło swoje umiejętności i nawyki w zakresie, w jakim nigdy nie musi iść na kompromis w sprawie jakości swojego kodu ani popadać w techniczne długi, ale poczekaj i zobacz, co się stanie, gdy ten anioł-inwestor obiecuje, że wszyscy się wzbogacą.

Usiądź i napisz prototyp (lub jakiś moduł, jeśli cały projekt jest zbyt duży), który wykorzystuje naprawdę dobry projekt, jaki uważasz za odpowiedni. Następnie przedstaw / omów to z zespołem. Przekonanie przez przykład może być łatwiejsze.

W tym procesie możesz również odkryć, że niektóre narzędzia, biblioteki, podejścia itp. Nie są tak dobre. Zawsze oceniaj najpierw i poproś swój zespół, aby wykorzystał to później. Uważaj na tani marketing wokół narzędzi niespełniających norm.