4 июля 2013 в 15:13

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

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.
Автор оригинала: David Byttow
Михаил Томшинский @tomshinsky
карма
90,0
рейтинг 0,0
Самое читаемое Разное

Комментарии (7)

  • +3
    Ох, ваш пост прям как бальзам на рану, как раз прохожу через многие круги этого маленького локального ада под названием «Превращение из разработчика в технического менеджера», и, порой, невольно сбиваешься на панику) Спасибо!
  • +3
    Спасибо, прочитал с удовольствием. Многое не ново, но повторение полезно.

    Хотел бы высказать по следующему моменту:
    «Думайте о том, как сделать правильно изначально, а не как потом исправить. „

    Здесь соглашусь лишь частично, т.к. моя практика, увы, показывает, что не редко бывает “лучше сделать 2 раза вовремя, чем 1 раз правильно» (эту фразу услышал когда-то от своего руководителя). Поэтому, не стоит всегда стараться сразу сделать «правильно» — оценивайте ситуацию, а не тупо следуйте «правилам».
    • +1
      Полностью согласен с «оценивайте ситуацию», но прошу при принятии решения «сделать быстро» сразу закладывать рефакторинг следующим этапом для «правильно».
  • 0
    По-моему, автор статьи пытается одновременно быть архитектором, team leader и project manager’ом.
    • 0
      Не соглашусь, project manager находится на вершине конечного продукта, а продукт может состоять из нескольких компонентов, у каждого компонента свой team leader.

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

      Чем крупнее проект и чем больше разработчиков тем тяжелее одному становится контролировать всё, поэтому схема может удлиняться до:

      Технический директор -> Руководитель группы (он же - ведущий программист) -> Разработчик

      В таком подходе Технический директор формирует команды для выполнения определённого модуля и передает часть своих полномочий Руководителю группы. По достижению результата группа или распускается или ей выдается новый модуль. Часто при выдаче нового модуля без роспуска группы производится изменение Руководителя группы на другого её члена, в основном по принципу знания основной технологии но и самое главное от готовности Руководителя группы брать на себя ответственность.
  • +1
    Прослезился от того, насколько верно написано.

    Добавлю 5-ый пункт в план по поиску решения:
    Если решение не очевидно или интуиция подсказывает, что вы придумали «не красивого монстра, которого мы потом отрефакторим» — то не надо боятся показаться некомпетентным, а стоит открыто вынести проблему на обсуждение с командой, друзьями (причем иногда бывает полезнее обратится не к профильными IT-шникам, а к технически грамотным людям из других сфер — они еще не испорчены шаблонами, платформами, фреймворками). Во-первых вы получите другие точки зрения, во-вторых разделите ответственность за выбор. И самое главное — пока вы будете объяснять кому-то суть проблемы и доказывать свое решение — скорее всего вы сами сделаете верный выбор.
  • 0
    Как правило, он не управляет людьми, а вместо этого учит их наилучшим образом выполнять свою работу


    В статье большой упор на технологии, но все же Технический директор работает в первую очередь с людьми и уровень вербальной коммуникабельности очень важен (по крайней мере для России).

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

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