Как нанимать и управлять программистами уровня junior и middle, не теряя месяцев времени

Всем привет! Я Лаптев Алексей, основатель и главный разработчик сервиса бесплатной сквозной аналитики и коллтрекинга Utmstat, а также Telegram-канала про сквозную аналитику. Сегодня расскажу, как работать с программистами на примере внутреннего регламента Utmstat.

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

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

Есть цепочка: бизнес — менеджер — программист, и она работает по принципу испорченного телефона.

Бизнес просто хочет сайт/сервис/приложение и поручает менеджеру сделать.

Менеджер по-своему понимает задачу, говорит ее программисту, при этом не может адекватно оценить решение от программиста.

Программист по-своему понимает задачу менеджера и просто пишет красивый код.

В итоге проект усложняется, выбивается из всех сроков и бюджетов, в конце концов просто не работает.

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

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

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

Возможно, с чем-то вы не согласитесь, но правила работают и могут послужить как минимум фундаментом для вашего регламента.

В интернете много холиваров на эту тему, особенно по поводу тестовых заданий. Для себя я вывел такую формулу.

1. Просим показать предыдущие проекты и оцениваем их сложность.

Если у вас интернет-магазин и там интернет-магазины — хорошо, если простенькие ленды — плохо. Опыта нет.

То есть смотрим, чтобы сложность предыдущих проектов была примерно как у вас.

2. Смотрим примеры кода.

Если все более-менее по стандартным паттернам — хорошо, если какой-то креатив и видно, что даже про MVC не слышал, — плохо.

3. Смотрим на рабочее окружение.

Если это бэкенд-программист, например PHP, то его рабочими инструментами должны быть Ubuntu/MacOS и PHPStorm. Это наиболее эффективная связка.

Если там Windows, noname-opensource-ide и удаленный сервер — это звоночек, но шанс еще есть.

4. Вспоминаем сложные моменты из проекта и просим предложить их решение.

Самое банальное — очереди. Если программист выдает решение похожее на ваше — хорошо, если ничего не выдает и понятия не имеет, как оно решается, — плохо.

Если словами сложно объяснить, можно попросить набросать схему компонентов в Google Draw. Писать код не нужно.

1. Писать код

У верстальщиков, конечно, можно спросить, но если программист на пальцах рассказал решение, то он и код напишет.

2. Требовать точные знания каких то команд и синтаксиса

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

3. Требовать знания алгоритмов и другой лютой теории

В 99% случаев программисту нужна арифметика на уровне (a+b)/2, поэтому если в задачи программиста явно не входит разработка логики с высшей математикой и каких-то быстрых алгоритмов повышенной надежности, то не надо спрашивать, как работает пузырковая сортировка и прочую ерунду.

Лучше спросите, как оптимизировать запрос или ускорить медленный модуль из вашего проекта. Это гораздо полезнее.

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

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

Прежде чем перейдем к правилам, надо понять, для кого и почему они написаны.

1. И так сойдет, лишь бы работало здесь и сейчас

У них нет цели сделать хорошо, разобраться. Пишут как умеют. Лишь бы платили.

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

Поэтому тут важно подробно ставить задачи и делать код-ревью, чтобы сделать нормально малой кровью.

2. Религиозный фанатик

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

Понятие, что под задачу надо подбирать правильный инструмент, им не очень знакомо.

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

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

3. Нормальный программист

Моя любимая категория.

Тут нормальный баланс фанатизма и пофигизма, работа идет ровно.

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

Не все понимают, что деньги платят за написание кода, за который платят деньги, а не просто красивого кода.

Поэтому на всякий случай нужно настроить на нужную волну.

Написание продукта за минимальное количество времени и шагов, скорейший вывод на коммерческое использование.

Написание продукта, напичканного всевозможными фичами, библиотеками, инструментами.

Вот так

Возможно, кому-то правила показались жесткими, но их соблюдение привело к комфортной, быстрой работе без авралов и стабильным кодом.