Leadership

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хоббив EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и ведуТелеграм-канал о UX-дизайне.

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

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

Проект и дизайн-команда

Проект, на котором мы работаем крупная e-commerce платформа с большой командой (80+ разработчиков, менеджеров, аналитиков, тестировщиков) и быстро меняющимися требованиями. На таком крупном проекте логично образовалась дизайн-команда из 4 ролей:

• UX-дизайнер, задача которого выяснить требования и сгенерировать наиболее удобное пользователям решение.

• UI-дизайнер (в EPAM эта роль также именуется Visual-дизайнер), который отвечает за то, чтобы интерфейс был красивым, эстетичным, хорошо смотрелся на разных разрешениях, соответствовал концепции бренда и возможностям разработки.

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

• Team Lead, который налаживает процессы и решает оргвопросы, обеспечивает команде комфортные условия работы и также занимается UX-дизайном.

Процессы в проекте построены вокруг Scrum: планирование спринта с оценкой задач, двухнедельный спринт, ревью и ретроспектива. Задачи команда оценивала в часах: сколько по времени успеваем столько и берём в следующий спринт. Звучит просто, но оценка в часах вызывала большие трудности у дизайн-команды.

В целом, задачи на дизайн сложно оценивать в силу нескольких причин:

• Требования на дизайн, как правило, наиболее неформализованные и приходят в виде сделайте чтобы было хорошо. Это нормально, но трудно в часах оценить время на поиск и проверку решения. А нужно ещё успеть его отрисовать и подготовить к разработке.

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

• Каждую идею нужно проверить и утвердить с заказчиком. И не так просто понять, сколько времени это займёт и как результат обсуждения повлияет на работу дизайнера.

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

Вот некоторые цитаты из ретроспектив, которые мы проводили внутри дизайн-команды:

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

Относительная оценка сложности

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

Согласно Scrum, для оценки задач используется абстрактная единица Story point. В одной команде ею могут измеряться часы, в другой дни, в третьей что-то ещё. Кому как удобно.

В нашей команде 1 Story point был равен 4 часам. И нам, по перечисленным ранее причинам, было крайне тяжело оценивать работу в таких Story points. Поэтому я решила наделить Story point другой мерой сложность.

Сложность (complexity) количество усилий, необходимых для выполнения задачи.

В нашем случае оценка сложности в Story points оказалась гораздо эффективнее, чем оценка часов, потому что:

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

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

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

• Исключаются обсуждения в формате Я бы сделал эту работу быстрее.

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

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

Параметры сложности

Сложность комплексная мера, и трудно сходу сказать, что это значит. Для удобства дизайн-команды я разделила сложность на 4 параметра*:

1. Зависимости от других людей

2. Навыки дизайнера

3. Количество коммуникации в рамках задачи

4. Согласованность нового дизайн-решения с уже существующими

_{*хотя параметры описывают работу дизайнера, я думаю, они будут актуальны и для других специалистов.}

Для каждого параметра я подобрала шкалы от 1 до 4. Например, оценка параметра Зависимость (Dependency) выглядит так:

1 (нет сложности) никто кроме дизайнера не вовлечён в работу, нет зависимости от других людей;

2 (низкая сложность) 1 человек вовлечён и немного работы с стороны;

3 (средняя сложность) 2-3 человека и/или много работы со стороны;

4 (высокая сложность) более 3 человек и/или невозможно определить количество работы со стороны.

Подробные шкалы по всем четырём параметрам сложности можно найти в моём докладе для конференции Design Z Day:

Как понять, что сложно, а что нет

Всё познается в сравнении.

Если время можно определить конкретно (например, два часа), то с оценкой сложности возникают проблемы. Что значит сложно? Где грань между сложно и очень сложно?

Секрет относительная оценка. Задачи оцениваются не в вакууме, а относительно друг друга, в сравнении.

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

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

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

Как наша команда начала использовать относительную оценку сложности

Нам было сложно перестроиться с абсолютной оценки часов на относительную оценку сложности.

Для начала я описала все параметры сложности во внутренней документации, привела примеры оценки. Мы обсудили это с командой. Далее мы проделали следующее упражнение:

Из прошлого спринта, который мы оценивали в часах, взяли 3 задачи. Мы их уже выполнили, поэтому всё про них знали. Для каждой задачи мы последовательно прошлись по 4 параметрам сложности (зависимости, навыки, коммуникация, согласованность) и дали новые оценки в относительных Story Points. Это было непросто, мы долго обсуждали каждую оценку и приходили к единой цифре. Вот что у нас получилось:

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

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

Результаты перехода на относительную оценку сложности

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

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

Важные результаты для нашей дизайн-команды:

• прозрачность задач;

• более точные оценки с меньшими усилиями;

• команда дизайнеров понимает, что мы должны знать перед выполнением задачи;

• лучшая декомпозиция задач;

• учитывается вся работа, включая согласования, генерацию идей и обсуждения;

• мы постоянно сравниваем задачи и видим общую картину.

Как итог, меньше стрессов, переутомления и неприятных сюрпризов.

Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале Поясни за UX.

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

Определение

Короткое: Технический лидер это инженер-программист, который отвечает за управление командой и поддержку технического направления.

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

Иногда позиция тимлидера может быть поделена между несколькими людьми, но очень редко делится позиция техлида. Технический лидер может руководить командой совместно с такими специалистами как Product-менеджер, инженер-менеджер или тимлид. Где инженер-менеджер или тимлид фокусируются на развитии людей и росте команды, технический лидер фокусируется на техническом росте членов команды и системы. Фокус техлида лежит на руководстве техническим направлением и качеством работы команды. Также у них могут быть дополнительные обязанности в зависимости от конкретной команды.

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

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

Что остается в любой команде несмотря на ее состав это техническое превосходство техлида. Эффективный техлид работает над техническим видением команды. И вместе с командой они обновляют, развивают его и претворяют в жизнь. Техлид постоянно работает с кодом, чтобы принимать обоснованные решения, выявлять технические риски и выстраивать доверительные отношения с разработчиками. В своей презентации The Geeks Guide to Leading Teams я предлагаю проводить над кодом минимум 30% времени.

Не просто тимлид

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

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

Больше практики, чем у инженера-менеджера

Вы управляете вещами и руководите людьми.

- Грейс Хоппер

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

• Поддерживают продуктивную рабочую среду для команд разработчиков;

• Выбивают бюджет на развитие и поддержку бизнес-целей;

• Представляют технологические перспективы на уровне руководства или совета директоров;

• Создают или координируют рабочие программы (реализуемые в рамках разработки);

• Занимаются рекрутингом и удержанием персонала для удовлетворения потребностей команды или ИТ-персонала.

Инженер-менеджер может быть как одним на команду, так и одним на несколько команд. У многих из них может даже не быть опыта разработки. Вместо этого они могут быть Product-менеджерами, QA или другими специалистами, вовлеченными в разработку ПО.

Техлид хороший архитектор

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

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

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

Какими ключевыми навыками должен обладать технический лидер?

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

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

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

• Лидерство эффективный техлид должен обладать сильными лидерскими качествами, даже если не он формально стоит во главе команды. Такие лидерские качества, как коучинг, влияние и делегирование полномочий, являются ключом к успеху.

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

- Определения техлида (от @patkua)

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

Почему уход сотрудника из компании часто становится катастрофой? Как готовиться к выходу из коллектива компании и сотруднику? Почему увольнение должно быть готово в первый день работы?

Ответы на эти и многие другие вопросы даст эксперт OTUS - Александр Пряхин, в рамках бесплатного демо урока курса "Team Lead 2.0". Записывайтесь на урок по ссылке.