Итак, среди нескольких кандидатов на позицию фронтенд-разработчика вы выделили для себя одного опытного сотрудника. Он уже отлично прошел техническое интервью, имеет компетенцию в активно развивающейся на проекте технологии, знает как с ней работать и где в случае чего искать информацию. Он не чурается оптимизаций и знает, что ваш сайт должен грузиться чуть быстрее, чем вечность, а бандл не должен весить как полноценная ОС. Уже работал в разных по размеру командах и знаком с процессом разработки ПО изнутри. Кажется, вы не прогадали с кандидатом, и он будет приносить бизнесу пользу. Вы сделали ему щедрое предложение, и кандидат с радостью его принял. Хотите ли превратить его рабочий процесс в ад? Желаете ли удивить его в негативном ключе? Мечтаете, чтобы он хотел сбежать от вас спустя 2 месяца? Если на все вопросы вы мысленно отвечали "Нет", то закрывайте эту статью. Если же вы отвечали "Да" (особенно ценятся ответы "Да" с коварной ухмылкой и потиранием рук), то добро пожаловать в этот анти-гайд.
Онбординг
Не проводите никаких онбордингов. Это все пустая трата времени, в ваших интересах сразу "включить" его в работу, и неважно какую. Разработчику незачем знать о том, над каким проектом вы трудитесь, кто заказчик, с чего вы начинали, где находитесь сейчас, и вообще зачем это все придумано. Разработчику не стоит говорить, о том, что его в любой момент могут переместить на другой проект, чтобы сделать внезапно появившиеся там задачи, пусть для сотрудника это будет сюрпризом.
Не рассказывайте о команде, кто за что отвечает, к кому можно обратиться, и как найти нужного коллегу. И абсолютно не имеет смысла обговаривать существующие процессы в компании и команде, объяснять как можно на них влиять и к кому за этим идти.
В общем, меньше знаешь — крепче спишь.
В таком случае разработчик станет сам искать ответы на эти вопросы. Он сам будет знакомиться с проектом и кодобазой, изучать, какие библиотеки и фреймворки вы используете, станет гуру пакетных менеджеров, просмотрит всю структуру и архитектуру проекта (кто знает, возможно, найдет какие-то проблемы), узнает, какие у вас есть конфигурации и настройки, скорее всего, довольно сильно углубится в предметную область и станет в ней каким-никаким экспертом. Параллельно с этим обязательно познакомится со всеми коллегами, станет очень коммуникабельным и будет писать чаще, чем МЧС во время плохой погоды. У разработчика быстро улетучится страх вопросов "А как …?", "А где находится …?", "Можешь рассказать о …?", в итоге он будет хранить у себя мини базу знаний в виде закладок, где есть все ответы мира. А может даже сам станет этой базой знаний, да настолько, что никогда не захочет уходить с проекта (а вы его отпускать, соответственно), и Bus factor опустится ниже 0.
Документация
Если у вас есть зачатки документации или (не дай Бог) уже существующая база знаний, удалите ее. Если очень хочется сохранить ее, то просто не говорите новому разработчику о ее существовании. Самый идеальный вариант, чтобы все члены команды думали по-разному. Базистам вполне можно сказать, что ее нет, бэкендерам, что есть, но знают о ней только базисты, а при фронтендерах упомянуть, что она уже неактуальная. Пусть спрашивают друг у друга и удивляются, в конце концов, это для их же блага — будут качками. Ну, хотя бы в плане мышц лица.
Не ведите документацию на систему и требования к ней, ведь куда лучше держать это в голове, так как вспомнить куда быстрее, чем искать что-то в каких-то документах. Ведь как известно, скорость мысли явно больше, чем скорость поиска "Да елки палки, как оно там работать-то должно" человека. Да и зачем разработчику что-то знать о системе и о том, как она должна функционировать.
Знание об API оставьте на совесть исключительно бэкендерам, нет необходимости использовать какие-то инструменты для предоставления информации об API другим или (что еще хуже) вести подробное описание запросов, ответов и ошибок в виде каких-то структурированных публичных файлов. Пусть телефоны бэкендеров вибрируют от бесконечных уведомлений в мессенджерах с вопросами об API.
Диаграммы и схемы верхнеуровневого дизайна системы спрячьте на один локальный компьютер, который никто не использует, и ни при каких обстоятельствах не говорите, что такие файлы есть. Очень желательно не упоминать о них, чтобы и знающие в какой-то момент забыли.
Настаивайте, чтобы README файлики (или подобные им) отсутствовали для всех проектов, потому что название проекта должно говорить само за себя, а нюансы запуска должны постигаться на практике.
С таким подходом разработчик будет постепенно сам становиться документацией, знать фичи проекта, как они работают, баги, как их обходить, и остальные мелочи работы системы. То есть все знания о функционале будут храниться в самом надежном месте — в памяти сотрудника.
Для работы с API он переберет все возможные варианты, узнает об ошибках валидации входных параметров, неправильных методах запроса, авторизации, неправильном формате дат, будет помнить наизусть ссылки, что по ним возвращается и в каких случаях.
README файлы просто-напросто станут не нужны, а каждый следующий новичок сможет обращаться по любым вопросам к любому разработчику.
Методология разработки
Все эти новые слова "Agile", "Scrum" и прочее придумали от нечего делать, а классического "Waterfall" сейчас поубавилось, поэтому наилучшим решением будет воспользоваться самой простой и легкой методологией под названием "Как пойдет". Ее суть в том, чтобы ни в коем случае не планировать какие-либо встречи и обсуждения по проекту, а когда заказчик абстрактно опишет фичу X, то сразу приниматься за ее реализацию.
Будет просто замечательно, если дизайн и некоторую функциональность удастся оставить на совесть разработчику, ведь так вы не потратите лишнее время на планирование, создание макетов, составление требований и прочие глупости.
Если нужно обсудить какой-то момент, не пишите обычным сообщением человеку. Каким бы маленьким ни был вопрос, необходимо устроить созвон с разработчиком в ту же минуту, вне зависимости от того, где он находится. Нет, он-то, конечно, может передвинуть его на несколько минут, но после этого времени вы обязаны напомнить ему о созвоне. На будущее не имейте никаких договоренностей о созвонах, делайте их (по возможности) спонтанными.
Максимально затягивайте выполнение других блокирующих задач, будь то реализация API или создание новых сущностей, адаптеров, и никогда не наполняйте базу тестовыми данными. В идеале дать задачу разработчику в тот момент, когда в база ничего нет, API только в процессе реализации, а фича нужна через 2-3 минуты. Когда все другие задачи будут выполнены, и, кажется, что конец близок, API полагается случайно оказаться нерабочим. Бэкендеры, конечно, не должны проверять свои фичи перед выкатом, что значит, что все это тестирование приятным сюрпризом ляжет на нового разработчика (размытие зон ответственности — залог успеха). Забудьте про тестировщиков, их изначально не должно существовать в вашей компании как класс. Базисты на просьбы наполнить базу хоть какими-то данными должны немо мычать, что не знают, как это сделать, или что это сделать нельзя по каким-то там непонятным причинам. Кстати, в последний день, когда уже нужно будет выкатывать функционал, настоятельно рекомендуется вежливо спрашивать каждые 10 минут, как у разработчика дела, успеете вы или нет. Под "вежливо спрашивать", естественно, подразумевается регулярное поторапливание. Можно даже немного изобразить панику, лишним не будет.
Рабочих стендов не должно быть больше одного. В лучшем случае этим единственным стендом должен быть прод. Можно, конечно, завести еще препрод, но тогда хотя бы уведомите о его существовании разработчика не сразу, а, скажем, через месяц. Хорошо, если бы он вообще о нем никогда не узнал. Всякие дев-стенды, стенды для тестировщиков или девопсов требуют дополнительных ресурсов, заводить их невыгодно. Да и нет ничего лучше, чем тестирование на проде.
В итоге разработчик разовьет свое мышление и научится додумывать за других, в частности за заказчика, что сильно сэкономит время. Он прокачается в дизайне и верстке благодаря тому, что многие решения будет принимать сам. Станет отвечать вам за секунду, ждать только вашего сообщения и даже предугадывать моменты, когда ему могут написать. Найдет в себе экстрасенсорные способности при описании моделей с базы данных, улучшит навыки работы вслепую, а также познает способы тестирования работоспособности API. Научится открывать в себе второе дыхание в день релиза и просить помощь у окружающих его разработчиков, даже если они не относятся к проекту.
Отслеживание задач
Трудно понять, зачем нынче ведут всякие Kanban доски на проектах с кучей колонок и непонятными фильтрами. Откажитесь от этой идеи, пусть разработчики видят только свои задачи и только в виде списка. Этого достаточно для эффективной работы всей команды.
Не нанимайте дизайнеров и аналитиков, чтобы потом они могли прикрепить ссылки на макеты и ТЗ к задаче. Описание задачи должно быть максимально кратким (таким, чтобы его осуждал Толстой), состоящим из нескольких предложений. Будет превосходно, если описание будет пустым, а название задачи будет говорить само за себя. Сократите количество скриншотов, картинок или любых других вложений. Если их наличие обязательно, то сведите их детализацию до уровня детализации рисунков в Paint.
Для User Story или крупной фичи не нужно связывать задачи между собой, так как разработчику необязательно знать, кто из его коллег отвечает за ту или иную часть общего функционала.
Краткие описания замотивируют сотрудника коммуницировать с другими разработчиками и авторами задач, возможно, это прокачает какие-то его художественные навыки. Но самое главное, что разработчик научится искать любые задачи в вашей системе трекинга задач по крупице информации, по одному слову, по общему названию фичи.
Код-ревью
Полностью отказаться от ревью, к сожалению, не получится. Но можно значительно повлиять на его скорость и удобство. Для этого не настраивайте линтер или форматирование, не создавайте общий конфиг с повторяющимися правилами, не добавляйте кастомные правила, критичные для вашего проекта или компании. Все негласные правила не стоит где-то сохранять, пусть за их соблюдение отвечают ревьюеры, которых должно быть много, максимально много. Ревьюеры не должны делить свои комментарии на обычные и придирки. Итоговое время от создание МР до его влития должно занимать больше количество времени, от нескольких часов вплоть до нескольких дней, при этом разработчик все это время не может отвлекаться на что-либо, кроме правок.
Исходя из этого, со временем сотрудник станет совершать меньше ошибок в коде, будет помнить наизусть все негласные правила и код-стайл команды.
График работы и коммуникация
Стоит забыть о нормированном количестве часов и строго ограниченном рабочем времени (ТК для лохов, ненормированный график для богов). Пишите разработчику в любое время, неважно утро это или поздний вечер, в конце концов, он должен быть доступен всегда. Не ставьте себе рамки, пусть люди переписываются и ночью. А если человеку надо отойти, и он предупредил вас об этом за год, то все равно отругайте его и внушите мысль, что в рабочее время он должен быть приклеен к стулу.
Кстати, заведите кучу чатов, которые обязательно поспособствуют продуктивности, но не называйте их подходящими именами, темы лучше оставить в секрете. Очень желательно, чтобы разработчик не знал, зачем они все нужны, но при этом тщательно следил за нескончаемым потоком сообщений в них.
Не бойтесь употреблять нецензурную лексику с первых минут знакомства, ведь это культурный сленг вашей компании, так что будет не лишним показать разработчику самые популярные фразы, которые он будет использовать, работая с вами.
Как уже было сказано, лучше разработчику не знать, чем занимаются его коллеги, а когда ему надо будет пообщаться с кем-то, то он с радостью поймет, что не знает контактов коллег. Еще одна опция - это иметь посредников (чем больше, тем лучше) между разработчиками и просто пересылать им сообщения друг друга, чтобы не форсировать получение информации (эдакий сломанный телефон).
Таким образом, разработчик будет мониторить все ваши чаты и не пропустит что-то важное, он также будет доступен все время суток, и если ему напишут, то он ответит сразу же. Стопроцентно научится правильно формулировать вопросы, чтобы собеседник с первого же сообщения его понял. А ещё проникнется вашей культурой речи.
Следуйте всем этим советам, и я гарантирую вам (проверено на опыте), что ваш "новоиспеченный" сотрудник в скором времени будет похож на тлеющий уголек. У него будет дергаться глаз, мешки под глазами от срочных задач будут волочиться по полу, он будет вздрагивать от любого сообщения с мольбами "только бы не с работы", все, кто его ревьюил, будут прокляты по несколько раз, а сам разработчик забудет, что такое чистый код, грязный код, помытый код и другие принципы или паттерны программирования. Он с радостью уволится и будет ассоциировать этот опыт с мемом про вьетнамские флешбеки. Поздравляю, ваша цель достигнута!
