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

Выбирайте из следующих советов по своему усмотрению!

1. Уменьшите количество переключений контекста до завершения задачи

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

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

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

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

2. Найдите баланс между самодостаточностью и заданием вопросов

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

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

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

3. Укажите похожие структуры кода в базе кода.

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

4. Слушайте и сохраняйте открытость

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

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

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

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

5. Документируйте свои процессы

Я не говорю о том, чтобы оставлять комментарии по всему вашему коду. «Хорошие кодовые документы сами по себе» остаются правдой. Документация необходима для трех частей:

  1. Разработка: стили кодирования, разработка через тестирование, форматы Sprint
  2. Развертывание: тестовые среды и производственные среды. Процесс развертывания. Каковы цели каждой среды?
  3. Процесс обслуживания: СОП на случай возникновения производственных проблем.

6. Составьте план передачи знаний о домене

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

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

7. Назначьте важные задачи

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

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

Установите установку на рост вместо установки на данность.

8. Внедрите систему ротации в своей команде

Когда вы достигли заключительного этапа адаптации, легко просто повторно поручать аналогичные задачи новому разработчику: разработчик A действительно хорош в исправлении CSS, поэтому давайте передадим ему все задачи по проектированию.

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

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

9. Обучайте процессу отладки

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

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

10. Постоянные проверки и обратная связь

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

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

Удачи! Спасибо за прочтение.