Як переконати своїх колег у тому, що робити все правильно, це заощадить їм час

Нещодавно я почав у новій компанії, з пригорщею програмістів. Це середня компанія, яка має близько 70 працівників, але ІТ має лише 9-10, а поруч є 3 "програмісти". Однак у цих хлопців дуже обмежений досвід і дуже багато чого роблять. Наприклад, одним із наших проектів є веб-сайт PHP. Більшість кодів зберігається у 20-ти рядковому контролері PHP з ~ 6000 рядками JavaScript, вбудованими в PHP.

Я продовжую робити тут і там невеликі пропозиції, але ніхто не слухав, всі кажуть, що вони занадто зайняті, щоб реалізувати мої пропозиції. Річ у тому, що вони не повинні бути такими зайнятими, і не було б, якби все було зроблено правильно. Вони витрачають більшу частину свого часу на виправлення речей, які постійно ламаються. Якби кожен проект був побудований правильно, я міг би зробити все сам.

Який підхід я повинен застосувати, щоб переконати цих хлопців чи менеджера, що все потрібно змінити і що зміна речей заощадить купу часу? Чи варто пропустити, намагаючись переконати своїх колег і піти прямо до менеджера, з діловою пропозицією про те, як компанія заощадить купу грошей, якщо вони почнуть робити все правильно?

Я виявив, що першопричиною неохайної роботи, поза програмістом просто не турбота, є брак знань. На жаль, у багатьох середовищах бракує знань, а не відкрито обговорюється.

Деякі методи, які я успішно використовував для сприяння обговоренню, зростанню та загальному хвилюванню щодо програмування:

• Щотижневі технічні сесії з коричневою сумкою (Попросіть їх вивчити тему та присутні).
• Щоденне або щотижневе один на один сеанс наставництва між молодшими та старшими.
• Огляди коду (з акцентом на навчання, не вказуючи на помилки).

Навчання заразне. Коли ви сприяєте створенню середовища, яке заохочує навчатись, ви не тільки розробляєте кращих розробників, але й показуєте іншим у своїй команді, що вони є частиною чогось більшого, ніж способом отримати зарплату.

Побачивши, що вас прийняли на роботу як сестра PHP-розробника, і ваша робота полягає в тому, щоб виправити речі, я припускаю, що настав час ви розгинати м'язи.

Якби я був на вашому місці, я б добре перевірив код і побачив помилки, які трапляються знову і знову. Щомісяця блокуйте час зустрічей, щоб переглядати ці питання разом із командою. Не вказуйте пальцями чи іменами, просто покажіть, як правильно виконати це завдання.

Далі, оскільки ви вже бачили потребу в виправленнях, складіть список. Якщо це швидко і просто зробити, зробіть це. Якщо це полегшить ваше життя, зробіть це .... зробіть це. Складіть список усіх речей, які потрібно зробити, і зробіть квитки на них, і подивіться, коли люди мають цикли, щоб їх робити. Якщо хтось виправляє помилку в проблемній області, перегляньте їх, як правильно її виправити.

Якщо це потребує великих змін, сідайте з командою та власниками акцій та обговорюйте варіанти.

Проведіть політику відкритих дверей, де ви будете допомагати людям. Будьте тим, хто навчає, а не залякує. Ні, "ви повинні це зробити так" і більше "було б краще, якби це було зроблено таким чином". Поясніть переваги, як це зробити так, як ви пропонуєте, та недоліки способу, що це робиться. Люди будуть готові робити це правильно, якщо відчують, що чогось навчилися, замість того, щоб сказати, що їхній шлях є неправильним, і робити це по-іншому, так як ви це скажете.

Перспектива керівництва проблеми Якщо вони прийняли час розвитку щодо кількості дефектів, то чому б вони ризикували? Коли довгострокові вигоди суперечать короткотерміновим цілям, вони зазвичай втрачаються. Ви просите їх зробити короткий крок назад. Вони можуть подумати, що це спричинить тривалу затримку. Ви повинні переконати їх, що це не буде разом із додатковими перевагами. Якщо вони не вважають, що у них безлад, попросіть їх пояснити, чому потрібно так довго, щоб швидко вводити нові помилки з кожним «виправленням».

Якість коду залежить від багатьох обставин та ситуацій. Продажі, маркетинг та менеджери змусять вас повірити, що кожен невдалий термін означає, що компанія пропустить цей удар на мегамільйонного інвестора венчурного капіталу. Реальність полягає в тому, що вони не хочуть доносити погані новини до 1% ваших клієнтів, які дійсно не потребували цієї функції. Я дуже екстремальний, і зазвичай він потрапляє десь посеред, тому розробникам потрібно дізнатися, що є справжньою надзвичайною ситуацією. Тоді легше переконати їх узяти час, щоб зробити це правильно, а не потрібен час для цього. Ви повинні розуміти ризики.

Як і чудовий роман, код не пишеться добре вперше, але, на жаль, він все ще надто часто публікується. Почніть з чогось принципового, як встановлення стандарту кодування. У кожного є такий, але багато хто, як у вашій ситуації, вони не були формалізовані, а також не дуже жорсткі. "Робити все, що ви хочете." це стандарт, який дуже простий в обслуговуванні. Наступний крок - визначити, як ви збираєтеся підтримувати свої стандарти.

Перед вами головне завдання. Можливо, кілька чудових програмістів розвинули свої навички та звички настільки, що їм ніколи не доведеться йти на компроміс з якістю свого коду чи вступати в технічну заборгованість, але зачекайте і подивіться, що станеться, коли той ангел-інвестор обіцяє, що всі розбагатіють.

Сядьте і напишіть прототип (або якийсь модуль, якщо весь проект занадто великий), який використовує дійсно гарний дизайн, як вважаєте за потрібне. Потім представити / обговорити це з командою. Це може бути простіше переконати на прикладі.

У цьому процесі ви також можете виявити, що деякі інструменти, бібліотеки, підходи чи подібне не так добре. Завжди оцінюйте спочатку і попросіть свою команду використати це пізніше. Остерігайтеся дешевого маркетингу навколо нестандартних інструментів.