Как убедить моих коллег в том, что правильные поступки спасут их время

Недавно я начал работать в новой компании с кучкой программистов. Это компания среднего размера, в которой работает около 70 человек, но у ИТ-специалистов всего 9-10 человек, а кроме меня есть 3 «программиста». Тем не менее, эти парни имеют очень ограниченный опыт и делают очень много вещей действительно ужасно. Например, одним из наших проектов является сайт PHP. Большая часть кода хранится в PHP-контроллере на 20 000 строк, а в PHP встроено ~ 6000 строк JavaScript.

Я продолжаю делать небольшие предложения тут и там, но никто не слушал, все говорят, что они слишком заняты, чтобы реализовать мои предложения. Дело в том, что они не должны быть настолько заняты, и не были бы, если бы все было сделано правильно. Они проводят большую часть своего времени, ремонтируя вещи, которые продолжают ломаться. Если бы каждый проект был построен правильно, я мог бы сделать все сам.

Какой подход я должен использовать, чтобы убедить этих ребят или менеджера в том, что все должно измениться, и что эти изменения сэкономят кучу времени? Должен ли я пропустить попытку убедить своих коллег и сразу обратиться к менеджеру с деловым предложением о том, как компания сэкономит кучу денег, если они начнут делать все правильно?

Я обнаружил, что основной причиной небрежной работы, за которой программисту просто наплевать, является недостаток знаний. К сожалению, во многих средах недостаток знаний скорее рассматривается, чем обсуждается.

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

• Еженедельные технические сессии в коричневых сумках (попросите их изучить тему и представить).
• Ежедневные или еженедельные сеансы наставничества один на один между младшими и старшими членами.
• Обзоры кода (с акцентом на обучение, не указывая на ошибки).

Обучение заразно. Когда вы создаете среду, которая поощряет обучение, вы не только создаете лучших разработчиков, но и показываете другим в своей команде, что они являются частью чего-то большего, чем способ получить зарплату.

Увидев, что вы были наняты в качестве разработчика Sr. PHP и ваша задача - исправить ситуацию, я полагаю, что пришло время напрячь силы.

Если бы я был на вашем месте, я бы сделал хороший обзор кода и увидел бы ошибки, которые происходят снова и снова. Блокируйте время встреч каждую неделю, чтобы обсудить эти вопросы с командой. Не указывайте пальцем или называйте имена, просто покажите, как правильно выполнить эту задачу.

Далее, поскольку вы уже видели, что нужно исправить, составьте список. Если это быстро и легко сделать, сделайте это. Если это сделает вашу жизнь легче, сделайте это ... сделайте это. Составьте список всех вещей, которые нужно сделать, и сделайте для них билеты и посмотрите, когда у людей есть циклы, чтобы сделать их. Если кто-то исправляет ошибку в проблемной области, объясните, как ее исправить.

Если это требует больших изменений, сядьте с командой и заинтересованными сторонами и обсудите варианты.

Имейте политику открытых дверей, где вы будете помогать людям. Будьте кем-то, кто обучает, а не пугает. Нет, «вы должны сделать это таким образом» и более того «было бы лучше, если бы это было сделано таким образом». Объясните преимущества, которые вы делаете, как вы предлагаете, и недостатки того, как это было сделано. Люди будут более охотно делать это правильно, если они почувствуют, что они чему-то научились, вместо того, чтобы им сказать, что их путь неправильный, и делать это другим способом, как вы говорите.

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

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

Как и отличный роман, в первый раз код написан плохо, но, к сожалению, он все еще публикуется слишком часто. Начните с чего-то фундаментального, такого как установление стандарта кодирования. У каждого есть, но многие, как в вашей ситуации, они не были формализованы и не очень строги. "Делай что хочешь." это стандарт, который очень легко поддерживать. Следующим шагом является определение того, как вы собираетесь поддерживать свои стандарты.

Перед вами стоит большая задача. Может быть, несколько великих программистов развили свои навыки и привычки до такой степени, что им никогда не придется идти на компромисс с качеством своего кода или заниматься техническим долгом, но подождите и посмотрите, что произойдет, когда этот инвестор-ангел обещает, что все разбогатеют.

Сядьте и напишите прототип (или какой-нибудь модуль, если весь проект слишком большой), который использует действительно хороший дизайн, как вы считаете нужным. Затем представьте / обсудите это с командой. Это может быть легче убедить на примере.

В этом процессе вы также можете обнаружить, что некоторые инструменты, библиотеки, подходы или тому подобное не так хороши. Всегда оценивайте сначала и попросите вашу команду использовать это позже. Остерегайтесь дешевого маркетинга вокруг некачественных инструментов.