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

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

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

Качества

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

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

Источник