Несомненно, эффективный техлид является силовым ключом и "сородичем" знаменитого "10x engineer", помимо того, что сила техлида заключается в переносе этой волшебной силы разработчика каждому члену их команды. Удачливые инженеры, которые живут под опекой таких техлидов, получают 10-кратное увеличение своих собственных сил и чувствуют ни на что не похожую систему поддержки .

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

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

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

Руководство техлида Webflow

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

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

• Определение успешного Tech Lead
• Ожидания при переходе от чисто технической роли к той, которая представляет собой сочетание управления и технических знаний, и как управлять этими ожиданиями
• Стратегии смягчения общих проблем
• Позиция Webflow берет «управление» (намек: речь идет о сервисе, а не о диктатуре)

Что, так или иначе, представляет собой техлид?

По самому основному определению,  техлид является «ответственным только за успех проекта, тратя 30% своего времени на разработку кода, а остальные 70% на управление проектом». Термин лидера не ошибочен - ваша цель - вести команду талантливых инженеров через изменчивую среду, направлять их, отводить их от опасностей, явных препятствий и поддерживать их полноценную работу.

Это легче сказать, чем сделать.

Навыки, которыми должен обладать и развивать технический руководитель, бесчисленны,  но наиболее важными являются искреннее сочувствие, прозрачное общение и техническое превосходство. Эти навыки одинаково важны. Tech Lead - это «гибридная» роль, сочетающая управление и технологичность, и выступающая в качестве связующего звена между ожиданиями проекта и задачами разработки. Успех проекта лежит на плечах техлида, и на плечах Webflow, чтобы гарантировать, что проект с лихвой снабжен поддержкой, необходимой для успеха.

Почему управление в Webflow - другое.

В большинстве компаний менеджмент получил дурную славу. Это часто ассоциируется с восприятием сотрудников в качестве «винтиков», и это вызывает образы диктаторов, обладающими “солнцезатмевающим” эго. Это не работает в Webflow. Сначала мы рассматриваем каждого члена команды как человека, а затем - как талантливого вкладчика в работу. Людям нужны отношения, основанные на сочувствии и сотрудничестве. Работа техлида заключается в создании такой среды, и такая среда создается через философию сервиса.

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

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

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

Почему я должен хотеть стать техлидом?

Вы можете и не хотеть стать техлидом, и это нормально. Webflow стремится предоставить множество различных возможностей для продвижения карьеры инженеров, включая путь “индивидуального соучастника”, который имеет аналогичное значение для расширенных управленческих ролей. Техлид находится под большим давлением, чем средний инженер, и сложно уравновесить требования управления командой и вносить свой код, особенно при первом входе в ведущую роль (это, кстати, вполне нормально).

Тем не менее, управленческая жизнь может оказаться чрезвычайно полезной. Вы будете принимать решение на более высоком уровне. Умножается ваше влияние на пользовательскую базу. Вы будете развивать силу, которая будет отражена в ваших обзорах производительности, а затем предоставит больше возможностей для карьерного роста. Эта роль часто рассматривается как ступенька к званию Senior Engineer, а также предпосылка для должности Engineering Manager. Вы будете наставлять и помогать другим инженерам расти. Некоторые находят эти дополнительные задачи захватывающими и помогают подтолкнуть их к новым пределам.

Как я могу стать техническим лидером?

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

Что ожидается от меня при управлении командой?

Работа Tech Lead состоит из этих обязанностей (в любом порядке):

1. Работать в тесном контакте с менеджером продукта, чтобы установить разумные ожидания в отношении крайних сроков, а также вносить ясность, когда проекты будут завершены
2. Разбить проекты на усвояемые задачи, связать эти задачи с итеративными результатами и отслеживать эти результаты
3. Обеспечить достаточную непрерывность рабочего времени для своей команды, чтобы она могла работать в потоковом режиме, и выступать в качестве защитника своей команды от любых потенциальных блокировщиков и отвлекающих факторов
4. Обеспечивать вашу команду достаточным объемом работы на постоянной основе, чтобы никто не сидел без дела.
5. Выполнять добросовестные проверки кода, QA первого прохода и по возможности предоставлять код.
6. Быть доступным членам команды, когда они выполняют свои задачи.
7. Периодически работать с другими отделами

Работа с другими отделами

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

Tech Lead несет ответственность за передачу статуса своего проекта другим отделам в двух формах:

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

Отслеживание задач

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

Мастер отслеживания проблем (MTI)

В начале проекта или в начале непрерывных этапов проекта Tech Lead должен выделить время, чтобы тщательно проанализировать спецификации проекта и сделать все возможное, чтобы разбить спецификацию на отслеживаемые задачи объемом 1-5 дней (за пределами Code Review / QA) и оптимальной временной шкалой в 3 дня. Затем эти задачи должны быть сгруппированы в этапы. Каждый этап - это результат с датой истечения срока.

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

Текущая практика Webflow заключается в том, чтобы создавать проблемные пункты GitHub для каждой задачи, которые затем отслеживаются в Мастере отслеживания проблем. MTI должен получить ярлык [Master Tracking Issue] в заголовке пункта, а также в разделе ярлыка GitHub.

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

• Может быть легко назначен вашим членам команды, которые затем будут отвечать за открытие PR, чтобы закрыть проблему
• Отображает номер проблемы GitHub задачи и PR, который закроет проблему, а также заголовок для проблемы. Обычно это делается в табличном формате.
• Предоставляет предполагаемую дату окончания каждого этапа и статус каждой проблемы по этим этапам

Задачи

Каждая проблема (или 1-5-дневная задача) должна четко указывать на часть спецификации, касающуюся проблем, и на соответствующие области кодовой базы Webflow (если они существуют). Мы обнаружили, что для каждой задачи лучше всего

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

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

Это жестко

Создание [Master Tracking Issue будет напоминать, что у вас слишком много времени, и вы поставите вопрос о том, выполняете ли вы наиболее эффективную работу. Доверьтесь нам: это важно, и чем яснее MTI, тем выше вероятность успеха проекта. В зависимости от размера проекта это может занять неделю или более. 😱 Все в порядке. Планируйте это. Сделай это. Ваша команда поблагодарит вас. Крайне важно помочь вашей команде почувствовать ощутимый прогресс.

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

Отображение прогресса в MTI

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

Вышесказанное дает PM (или другому заинтересованному) быстрый способ оценить прогресс проекта. Например, можно увидеть, что этап BETA составляет около 75%, а поскольку задачи разбиты примерно на 1-5-дневный шаг, легко определить, выходит ли этап за рамки задуманного времени.

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

• Ее этап и дата
• Ее проблемный пункт
• Ее запрос на включение
• Краткое описание
• Ее прогресс

Профессиональный совет: если MTI становится слишком длинным и громоздким, можно разделить его на несколько отдельных MTI.

Основные этапы (показатели результативности)

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

Этап представляет собой:

1. Показатель результативности, обычно с шестинедельным сроком
2. Ответственность за управление серией задач / проблем, которая заканчивается, когда все задачи / проблемы переносятся на производство
3. Именуется в соответствии с типом показателя результативности, например Запуск, Версия и т.п.

Структура планирования для большого проекта должна состоять только из двух уровней: Этапы -> Задачи. Основные этапы будут находиться в компетенции функции, такой как редактор Rich Content Editor или Interactions 2.0, который может занять несколько месяцев (или лет). Этапы являются «кусками» непрерывной работы и обычно выполняются последовательно. Редко бывает, что команда работает над этапами параллельно, если они не очень взаимосвязаны, хотя ожидается некоторое перекрытие при переходе от одного этапа к другому.

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

Типы этапов

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

Задача в отношении неизвестных

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

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

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

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

Встречи

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

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

Еженедельный статус

Каждого инженера просят ежедневно сообщать о статусе  on-track / off-track в # status-frontend или # status-backend, и именно техлиды подтверждают эти данные ежедневно (реакция Slack «👍 всегда хорошая» ). Это заставляет каждого инженера отвечать за свои еженедельные задания, и это позволяет техлиду вмешаться, если задача давно находится в  off-track или ее выполнение перевалило за 5 дней.

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

Agile? Менеджеры проекта?

Возможно, вам интересно: «Где методология такого управления проектами?». Он может напоминать Agile, с его двухнедельными прогнозами и еженедельными встречами «Scrum», но ему не хватает списков выгорания и Scrum Masters. Хотя мы любим философию Agile, стремимся двигаться быстро и, по возможности, подстраиваться, Webflow не подписывается на конкретную методологию. Это то, что работает для нас прямо сейчас, и мы всегда открыты для пересмотра метедологии в процессе работы.

Какими типами команд может управлять Техлид?

Webflow объединяет своих талантливых инженеров в команды  Action and Permanent, за которые несет ответственность один технический руководитель.

Какой размер команды я должен ожидать?

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

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

Вышеупомянутые командные структуры могут состоять из Back-End и Front-End инженеров. Webflow хочет размыть линии между этими инженерными дисциплинами, в равной степени как с нетехническими дисциплинами, такими как дизайн.

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

Эффективность и организация команды

Существует два способа разработки команды. Одна касается эффективности “Функции”, которая помогает группам, которые сотрудничают в решении тесно связанных проблем вместе. Другая касается эффективности “Ресурса”,

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

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

Помогите! Мы отстаем от графика!

Это круто. В самом деле. Пойдите, выпейте кофе, или погрейтесь на солнце, и возвращайтесь к своему столу, когда ваше внутреннее “я” отражает спокойствие.

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

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

Пару слов об управлении проектами

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

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

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

Эти четыре рычага могут меняться по мере развития проекта. Они являются инструментами, эффективными для менеджеров проекта. Тем не менее, Webflow производит продукт самого высокого качества и не пожертвует качеством в пользу времени, ресурсов или масштаба, поэтому у нас есть только те три рычага, которые мы будем использовать в следующем разделе.

Совет: роль  техлида часто является первым набегом инженера в попытке удовлетворить базовые потребности бизнеса. Их решения должны быть сформулированы в вопросе: «Как это поддерживает компанию?» Если у вас мало или нет деловой хватки, взгляните на «Личный MBA» Джоша Кауфмана. Это потрясающий крутой курс в современной деловой практике, который поможет вам принимать более эффективные решения при рассмотрении потребностей Webflow и потребностей вашей команды.

Rework / Defer / Abandon (Стратегии смягчения для отложенного прогресса)

У вас есть три варианта, когда вы сталкиваетесь с угрозой срыва срока, которые должны обсуждаться с вашим менеджером продуктов. Здесь они сортируются по порядку рассмотрения:

1. Доработать поставляемый результат
2. Отложить установленный срок
3. Отменить проект

Доработка

Доработка состоит из двух вопросов:

• Можем ли мы добавить ресурсы для проекта в установленные сроки?
• Можем ли мы изменить объем поставляемой продукции в соответствии с установленным сроком?

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

Совет. Сокращение масштаба часто является выбором №1, когда вы пытаетесь достичь крайнего срока, сохраняя при этом ценность для бизнеса. Вероятность того, что проект потребует больше ресурсов для достижения предельного срока, вероятно, находится в диапазоне 10%. Уменьшите масштаб в 90% случаев.

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

Перенос

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

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

Отмена

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

Возможна и четвертая стратегия: взгляните на дедлайн повнимательнее

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

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

Как я могу сделать более точные оценки?

На момент написания этой статьи никто не обнаружил магический метод для прогнозирования сроков разработки программного обеспечения. Некоторые могут попытаться продать вам бесполезную информацию об этом, а другие могут сказать, что это совершенно невозможно. Лучше согласиться с тем, что оценка программного обеспечения редко бывает точной. Это лежит в основе философии Agile: итерировать и обнаружить, а затем доставить и улучшить. Это искусство обнаружения, а не искусство доставки. Webflow следует за итеративным процессом (см .: Что ожидается от меня при управлении командой?), как описано в других разделах, поэтому оценка важна, но не так важна, как выявление неизвестных. Тем не менее, здесь есть некоторые тактики, помогающие оценить задачи:

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

Добавление задач к неизвестным

После того, как вы создали свой Master Tracking Issue, (см .: Что ожидается от меня при управлении командой?), вы можете понять, сколько времени потребуется на выполнение проекта. Обязательно определите, какие задачи связаны с обнаружением (обнаружение неизвестных) и которые имеют более конкретные определения. После того, как вы выполнили все задачи обнаружения, вы получите гораздо лучшее представление о точности срока.

Правило 80/20

Легко учесть трудоемкие нюансы, которые замедляют последние 20% проекта. Когда вы просматриваете свой проект целостно, разбейте его, используя правило 80/20, и подумайте, что последние 20% проекта могут составлять еще 80% общей временной шкалы. Для этого существует целый ряд причин, но последние 20% часто заполняются совершенствованием поставляемой продукции, а для сложных функций требуется совершенствование для каждой функции и пограничного случая, которые объединяются при завершении проекта.

Что это значит для вас? Просто рассматривайте 80% -ное выполнение пунктов в своем проекте как пройденный наполовину путь. Это позволит выровнять ожидания против добавленных нюансов. Никогда не забывайте QA Когда вы оцениваете сроки, задайте дату завершения кода, чтобы QA успел обнаружить ошибки или проблемы UX. Ваши оценки должны учитывать эту дополнительную фазу и учитывать текущую рабочую нагрузку.

Cooldown: исправления ошибок после доставки

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

Как долго должны проходить проекты?

Хотя для воплощения функции могут потребоваться месяцы и месяцы работы, ее версионированные этапы должны быть нацелены на шестинедельные сроки, включая QA, поэтому каждый этап - это код, завершающийся в течение четырех недель. Это позволяет маркетингу оценивать проверенный набор функций и ставить их в очередь для объявления на основе рыночных тенденций. Разрыв большой функции на шестинедельные сроки может показаться сложной задачей, но мы задаем это по нескольким важным причинам:

* Гораздо проще рассуждать о меньших масштабах и сроках

* Это позволяет проектам подстраиваться, если их бизнес-ценность каким-то образом оказывается недостаточной

* Это позволяет группам из трех членов работать быстрее

Основные этапы шестимесячного проекта могут выглядеть следующим образом:

1. Альфа-запуск (6 недель)
2. Бета-запуск (6 недель)
3. Запуск функции v1.0 (6 недель)
4. Запуск функции v1.0.1 (6 недель) 🏁

Должен ли я отходить от ветвей на функциональность или нет?

Нет.

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

Подводя итог, Webflow имеет два основных направления:

1. dev
2. master

А ветви на функциональность

1. могут ответвляться от: dev
2. должны объединиться обратно в: dev

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

Как я могу оставаться сосредоточенным?

Пребывание сосредоточенным означает, что вы заботитесь о себе в первую очередь и

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

Как я могу оставаться организованным?

Руководители новых технологий чувствуют себя подавленными, и если они этого не делают, они, вероятно, не выполняют какую-то часть своей работы. 😅 (Хорошо, хорошо, некоторые из нас могут быть в состоянии взять на себя роль в ходу, но это неудобно для большинства). Ключом к смягчению слишком большого и страшного стресса является изучение искусства управления временем. Это может сложиться по-разному, и это сводится к вашим собственным предпочтениям. Если вы никогда не брали книгу по управлению временем, мы рекомендуем начать работу с Дэвидом Алленом «Getting Things Done». Это отличный первый шаг, чтобы научиться перенести какофонию шума в вашей голове в другое место. Если его метод не работает для вас, попробуйте найти другой и поделиться им, когда вы это сделаете.

Сколько я должен тратить на код?

Это зависит от проекта, но хорошая оценка заключается в том, что вы будете тратить на код 30% времени (если не меньше), оценивать код в 30% случаев (если не больше) и обслуживать свою команду с оставшимся временем. Обзоры кодов Поскольку вы в конечном итоге несете ответственность за качество поставляемой продукции, вам нужно будет просмотреть и подписаться на каждом PR. Это может быть невероятно трудоемким для более крупных команд, поэтому полезно поощрять вашу команду проверять код друг друга. Тем не менее, мы ожидаем много обзоров кода и рассмотрим их как возможность наставника младших членов команды и со старшими членами команды, чтобы держать вас на вершине ваших навыков.

Как предоставить отчеты о состоянии для встреч?

Каждый четверг в 11 часов по тихоокеанскому времени (на момент написания этой статьи) Webflow проводит встречу All Hands, где управленческая команда передает статус всех текущих проектов Webflow, а также крупные цели и инициативы компании. Перед тем, как эта встреча, ответственность за технологическое руководство заключается в предоставлении обновления прогресса для своего проекта в документе Google Tracker Project Tracker. Этот документ используется в канале # all-hands в Slack. Шаблон для обновлений находится в конце документа Google. Пожалуйста, следуйте им соответствующим образом. Элементы в шаблоне:

1. TDLR, или краткое описание состояния проекта.
2. MILESTONE ON-TRACK / OFF-TRACK, где вы предоставляете обновления треков для каждого активного этапа, их процентную долю и процентное изменение с предыдущей недели (это точки ожидания). Также перечисляйте следующие две недели задач, над которыми будет работать команда, и их ожидаемые даты доставки.
3. KEY DECISIONS, в которых упоминаются любые важные ключевые решения,

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

4. RISKS, UNKNOWNS и BLOCKERS, где вы упоминаете о любых рисках, неизвестных или блокаторах, появившихся с прошлой недели.

Lattice

Webflow использует Lattice для отслеживания целей компании на более высоком уровне. В дополнение к вашим еженедельным обновлениям All Hands мы просим вас также обновить любые цели Lattice, которые вам назначены. Если у вас нет учетной записи, обратитесь за помощью к своему менеджеру по инжинирингу.

Как мне мотивировать мою команду?

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

Автономия, мастерство и цель

Даниэль Пинк в своей книге «Драйв» развеял миф о том, что люди по своей природе мотивированы или, как говорят, мотивированы внешними факторами, такими как деньги или хорошие офисы, названия должностей и т. д. Вместо этого он обнаружил, что мы мотивированы внутренними факторами, такие как наличие чувства принадлежности, возможность развивать навыки и делать это на наших собственных условиях. Эти три внутренних фактора могут быть сведены к автономии, мастерству и цели и являются отличными отправными точками для анализа основ мотивации. Часть предоставления этих ключевых мотиваторов ложится на плечи Webflow, но умный Tech Lead также может использовать их для большого эффекта. Поэтому каждую неделю задавайте себе следующие вопросы:

1. Даю ли я своей команде достаточно свободы для решения проблем на их собственных условиях? Командую ли я, когда я должен давать направление и намерение? [Автономия]
2. Даю ли членам своей команды правильные задачи, которые могут помочь им расти? [Мастерство]
3. Согласен ли я, почему мы строим эту функцию с тем, как Webflow хочет помочь миру? [Цель]

Обеспечьте обратную связь Ким Скотт, выпускница Гарварда, которая работала в качестве исполнительного директора в Google и Apple, подводит итог, как лучше управлять отношениями и ожиданиями с каждым человеком в вашей команде в ее книге Radical Candor. Оказывается, мы не должны смягчать то, как мы чувствуем и как мы говорим друг с другом, а вместо этого мы должны сформулировать жесткие дискуссии персонально и заботливо. Основной предпосылкой этой аксиомы является «Заботьтесь персонально, бросайте вызов непосредственно», что означает, что вы должны сочувствовать своей команде и демонстрировать им, что вы заботитесь о своем благополучии, но все же предоставляете им критическую обратную связь (что может их задеть).

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

Совет: способ, которым мы формируем обратную связь, может иметь значение для того, насколько хорошо он получен. Вместо того, чтобы атаковать личные недостатки, выделите поведение, которое приведет к обратной связи. Подумайте об использовании модели ситуаций, поведения, воздействия для такого построения. Он работает следующим образом: Поднимите ситуацию, когда произошло определенное поведение, выделите поведение, затем укажите влияние, например. «Во время сегодняшней встречи вы несколько раз прерывали Брайана и заставляли Брайана чувствовать, что он не может говорить до конца собрания, где он представил победившую идею. Это сделало встречу дольше, чем нужно».

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

У меня есть неэффективный член команды. Что мне делать?

Вы слышали старую пословицу: «Нет плохих сотрудников, только плохие менеджеры?» Ну, это в основном верно. Webflow нанимает талантливых инженеров, поэтому прежде чем вы переходите к каким-либо выводам о том, что не так с исполнителем, убедитесь, что вы обслуживаете свою команду на 100% (см .: Как я могу мотивировать мою команду?). Каждый член команды должен быть достаточно мотивирован через широкие возможности для создания значимого прогресса, автономность, с возможностью повышения мастерства и с чувством цели. Обеспечение постоянной обратной связи также является важным компонентом.

Вы также должны учитывать внутреннюю трудовую жизнь члена команды. Можно спросить: «Как дела? Все в порядке вне работы? » Вы должны часто задавать эти вопросы, но не следует подслушивать. Дайте членам вашей команды возможность обсудить личные проблемы, помня, что они личные. Если вы сделали все возможное, чтобы создать подходящую среду для члена вашей команды, чтобы он делал все возможное для работы, и он все еще не оправдывает ваших ожиданий, поговорите с вашим менеджером о том, что делать дальше.

Как я могу избежать выгорания команды?

Если команда не может уложиться в заданный срок, это проблема управления, а не команды. Это означает, что где-то на этом пути проект не прошел так, как планировалось, и курс не был исправлен. Итак, Правило № 1, чтобы избежать выгорания, - «хорошо управлять проектом и ожиданиями» (см .: Справка! Мы отстаем от графика!)

Правило № 2: Никогда не спрашивайте со своей команде, чем с себя (и вы не должны просить себя работать по ночам и выходным дням). Другие организации могут попросить свои команды работать больше часов, когда ситуация становится напряженной. Это курс на истощение и долгосрочную неэффективность. Webflow глубоко заботится о своей команде не только профессионально, но и лично, поэтому мы должны сделать все возможное, чтобы хорошо справляться с нашим временем.

Аврал

О, горячая пора, ты преследовала лучшие команды, и тебя так трудно избежать. Как технический руководитель, вы непременно столкнетесь с крайним сроком, который находится в пределах досягаемости, и может потребовать немного больше усилий, чтобы подтолкнуть проект на последнем участке. Вашей команде, возможно, потребуется добавить еще несколько часов на свою 40-часовую рабочую неделю. Да все верно. Наша версия «аврала» - это не сумасшедшие часы, которые истекают вечером или в выходные дни. Это всего лишь несколько. Когда люди работают с максимальной производительностью, когда они участвуют в состоянии потока 2-4 часа в день, они неспособны к большей работе без серьезных последствий. Они должны уже работать с максимальной эффективностью, и спрашивать с них больше означает получить серьезные убытки и негативные последствия для них лично, а также для Webflow как компании. Аврал возможен. Аврал может быть симптомом плохого управления. Мы должны сделать все возможное, чтобы ограничить эти гиперактивные периоды до одного или двух раз в год.

No Comments