Эффективное техническое руководство

image

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

Все компании разные, но между лучшими техническими руководителями, с которыми мне довелось работать, существует кое-что общее. Снимаю шляпу перед Брайаном Столером, Натаном Хантом, Эваном Гилбертом и Ричем Бердоном за то, что послужили мне хорошим примером.

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

Качества

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

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

Чтобы оставаться компетентным, я делаю три вещи в следующем порядке:

  1. Оцениваю код
  2. Читаю проектную документацию
  3. Пишу код (см. статью ABC: Always Be Coding)

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

Технический руководитель должен владеть несколькими технологиями. Например: Java, JavaScript, C++, распределенные системы хранения данных и веб-разработка на стороне клиента позволяют занять должность технического руководителя серьезного веб-приложения (подробнее о том, кто такой Full Stack специалист)

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

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

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

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

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

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

Функции

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

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

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

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

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

3. Перенаправление
Независимо от того, насколько вы хороши, вы не знаете всего. И вы не можете ответить на любой вопрос. И даже если бы технически вы могли это делать, практически все ваше время уходило бы на ответы на вопросы. Чтобы заполнить эти пробелы (и иметь возможность выполнять собственную работу), вы должны в уме составить список экспертов, чтобы всегда знать, где найти ответ. Изначальное и частое перенаправление – чрезвычайно полезная практика. Технический руководитель часто «человек 302» (или человек-переадресация), который соединяет людей. Если разработчик в вашей команде в чем-то не уверен или задает вопрос, на который вы не знаете точный ответ, понимание, к кому его нужно отправить, чрезвычайно ценно и экономит много времени.

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

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

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

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

  1. Уменьшаю количество вариантов до 2. Сложность любой проблемы экспоненциально возрастает с каждым вариантом.
  2. Быстро определяю, можно ли сделать оптимальный выбор на основании опыта или данных.
  3. Если правильный ответ на этом этапе не является очевидным, можно ли перенаправить вопрос кому-то, кто больше подходит для принятия решения?
  4. Если все еще нельзя сделать оптимальный выбор, тогда возможно недостаточно данных или задан неправильный вопрос. Я или блокирую принятие решения или разблокирую его, следуя инстинкту.

Вышеуказанные шаги необходимо мгновенно проходить в уме.

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

5. Демонстрация
Одним из самых важных качеств технического руководителя является способность демонстрировать на примере. Мы все слышали фразу «подавать пример», однако мне больше нравится показывать, а не говорить. Технический руководитель обычно не является менеджером, так как он сосредотачивает свою энергию на коде, а не на людях. Поэтому необходимо добиться уважения и доверия от своей команды, что лучше всего достигается демонстрацией того, что вы знаете свое дело.

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

Действия

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

  • Создает и поддерживает планы по разработке, тестированию и выпуску.
  • Проводит эффективные совещания команды разработчиков.
  • По необходимости обеспечивает полезность и лаконичность совещаний.
  • Помогает обозначить и расставить приоритеты по проекту.
  • Часто говорит «нет» новым излишним функциям.
  • Определяет лучшие способы отслеживания решения проблем.
  • Организует хакатоны и исправление ошибок.
  • Поддерживает межфункциональные отношения.
  • Определяет контрольные сроки.
  • Следит за появлением полезных инструментов.
  • Инструктирует других разработчиков.
  • Нанимает разработчиков из других команд.
  • Принимает практикантов, делает их успешными.
  • Подробно оценивает код и оставляет полезные комментарии.
  • Читает, пишет и комментирует проектную документацию.
  • Пишет правильный код в правильное время.
  • Защищает разработчиков от руководства, если необходимо.
  • Работает с другими командами разработчиков, особенно зависимыми.
  • Определяет технический долг.
  • Объясняет, почему принимаются решения.
  • Борется за правильные решения.
  • Находит время на работу с техническим долгом.
  • Распределяет нагрузку в команде.
  • Принимает новых разработчиков и назначает разработчиков в качестве наставников.
  • Корректирует курс и целевые даты по необходимости.
  • Поддерживает определение минимальных жизнеспособных продуктов проекта.
  • Оценивает архитектурные решения и их последствия.
  • Обеспечивает написание тестов для основных функций.
  • Поддерживает процессы по требованию и дежурные процессы.
  • По необходимости поднимает блокирующие проблемы.
  • Изучает проблемы конфиденциальности и безопасности продукта.
  • Часто генерирует новые идеи и превосходные решения.
  • Решает сложные производственные вопросы.
  • … и так далее.

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

Будьте уверенны в себе, продолжайте двигаться и постоянно совершенствуйтесь!

Перевод выполнен в рамках летней школы стартапов Tolstoy Summer Camp.

Автор: tomshinsky

Источник

Оставить комментарий