Сейчас я работаю с несколькими командами разработки. В каждой из них есть менеджер, он же владелец продукта. В ежедневной работе я достаточно часто общаюсь с каждым из них. Раньше я работала внутри одной команды в качестве разработчика и техлида и взаимодействовала всегда только с одним менеджером. Поэтому относительно давно у меня появился определенный собирательный образ владельца продукта, с которым мне круто работать. И мне очень хочется, чтобы у каждой команды был такой менеджер.
Разрабатывая ИТ-продукты определенное количество времени, начинаешь задумываться о том, откуда берутся сроки, насколько эффективен ты и команда, и, конечно, о том, как на это можно влиять. Для чего? А для того, чтобы не работать по ночам, не работать сверх нормы, не делать бесполезное и «в стол», и еще куча других «не». Ведь очень хочется получить результат, который можно ощутить, вложив столько сил не зря. Про личную эффективность существует куча разных методик, о которых стоит рассказывать отдельно. А вот про командную эффективность частично поговорим здесь.
Если вы разработчик, то наверняка у вас в команде есть такой человек, как менеджер. Как часто вы задумываетесь о том, какая у него роль и чем же он может вам помочь, кроме как спрашивать каждый день, когда будет готово?
В поисках ответа на этот вопрос известная компания Google проводила различные эксперименты и пришла к выводу, что менеджер нужен команде и даже влияет на ее эффективность. В своей книге «Работа рулит, или Почему люди хотят работать в Гугл» Ласло Бок рассказывает о разных экспериментах. Один из них — это проект «Кислород», в ходе которого сравнивали эффективность разных команд и оценивали, как тот или иной менеджер влияет на эту самую эффективность своими действиями. Прочитать о нем подробнее можно по ссылке: learn-about-googles-manager-research.
Относительно своего опыта я хочу рассказать о своих ожиданиях от владельца продукта в команде и какие действия влияют на ее эффективность. Я буду использовать некоторые слова и отсылки к книге Максима Дорофеева «Как сберечь мыслетопливо и опустошить инбокс» про обезьянку и кнопку.
Для удобства я поделю описание ожиданий на 4 крупные части:
Если у нас несколько идей, то получается, что нужно несколько проектов планировать. Появляются приоритеты и план работ: что будет сделано раньше, а что позже.
Конечно, многое зависит от размера команды и самой идеи. Но это всё к чему? Для чего нам эти планы и проекты? Представим, что у вас есть Х золота на реализацию идеи. Реализация одной идеи стоит Y золота. Каждый разработчик за свой труд хочет получить Z золота. Хватит ли у вас золота? Как это узнать? Нужно понимать, из чего будет состоять план реализации идеи. Часто слышу, что невозможно написать план, потому что неизвестно, что писать, невозможно всё предусмотреть и вообще вдруг всё поменяется, а мы тут план какой-то собираемся писать. Проще оставить на потом, вдруг не придется думать, хотя это не так. Да, план сложно писать, потому что нужно думать и погружаться в детали, это требует умственных затрат. План — это наш контракт между бизнесом и разработкой. Любые изменения могут повлиять на сроки и стоимость, но без плана невозможно будет оценить влияние.
Так как мы хотим еще и развивать успешно запущенный продукт в долгосрочной перспективе, нам по-прежнему будет нужна команда разработки. При активном развитии скорее всего понадобится увеличивать команду. Как понять, сколько нужно добавить людей в этом году? Сколько еще нанять разработчиков? Чтобы примерно посчитать, нужно четко понимать, как хотим развивать продукт, что именно собираемся делать, что будет через полгода. Поэтому мы заранее думаем об этом, пишем цели.
Все мы хотим делать что-то полезное, то, что несет ценность, то, чем будут пользоваться люди. Поэтому важно уметь четко формулировать стратегические цели. Они должны быть понятны команды, ведь это способ показать, куда будет развиваться продукт, который они делают. Целей не должно быть много, иначе это усложнит и приоритизацию, и ориентирование в них при дальнейшей реализации. Для всего этого хорошо подходит известная формула SMART.
Прежде чем делать что-то новое, фичу или продукт, хорошо бы провести продуктовое исследование о надобности этого. Если мы получили ожидаемые результаты, то можно начинать прорабатывать детально клиентский путь, или фичу, или продукт, договариваться с руководителями смежных команд.
Важно приоритизировать цели. Цели и приоритеты нам очень пригодятся в управлении проектом и в реализации, потому что можно будет оценить разработку и дальше понимать, хватит ли нам сил реализовать всё, понимать, что важнее и что можно сделать первым, а чем можно пожертвовать. Ситуация в команде может меняться по разным причинам, и скорость разработки тоже, и может случиться так, что всё не получится успеть, поэтому приоритеты важны уже в самом начале.
Важно подготовить цели и оценить их на предстоящий период уже к концу текущего, чтобы была понятна перспектива, чем будет заниматься команда и как будет развиваться продукт. Поместить это всё можно на наглядную схему, чтобы все могли посмотреть и не тратить «мыслетопливо» на попытки вспомнить.
Попробую ответить на вопросы, которые я написала.
Делать, конечно, будем сразу НЕ всё, а по крупным частям, потому что слон довольно большой. Чтобы понять, в каком порядке делать и когда, составим план действий по частям слона, дадим верхнеуровневую оценку. Приоритеты у нас уже есть.
Дальше будем делить крупные части на составляющие. По каждой из них составим план, декомпозируем и накидаем задач, ещё раз оценим, на этот раз подробнее. Получится много задач, которые нужно будет делать в определённом порядке всей командой. Но не вся команда будет делать одну задачу, а единовременно будет по одной задаче на одного участника до тех пор, пока не сделает. Задачи могут блокировать друга друга, зависеть друга от друга.
Хорошо бы использовать прозрачный для всех инструмент для ведения задач и всего это безобразия, иначе можно запутаться и возникнут нежелательные последствия: поедут сроки и качество. В качестве такого инструмента могу предложить JIRA.
Хорошо бы уметь применять инструмент правильно. Для этого можно взять, например, Agile и спринты, допустим, двухнедельные итерации. Это поможет ограничить для команды список дел на ближайшие две недели, и с ними будет проще справиться, потому что ближайшее будущее известно, нам понятно, что нужно сделать и кому помочь. Заведём для этого регулярное командное мероприятие и назовём его «планирование спринта».
Посмотрим поближе задачку. Она относится к крупной части нашего слона и является маленькой его частью. У неё есть описание «что и зачем будет делать». А также у неё есть несколько состояний: базовые "todo", "in progress", "done". Довольно удобно ещё использовать состояния "review" и "testing". Рецензирование кода в ходе разработки — это командное мероприятие, каждый разработчик находится в контексте вносимых изменений и может помочь с реализацией и качеством. Тестирование — тоже очень важный этап для продукта, оно напрямую влияет на качество и положительные эмоции, а также помогает увеличить пользу от использования продукта. Про него нужно писать много и отдельно. Кроме того, тестирование поможет нам определить, соответствует ли результат изначальной постановке задачи. Если всё работает как ожидалось, то можно ли считать задачу готовой? И да, то переведём задачу в состояние "done".
Вот сделали мы задачи в спринте. Что дальше? Остановимся и посмотрим, что творили две недели? Конечно! Ведь две недели — это хороший период для того, чтобы сделать что-то ощутимое, а может быть ещё и поделиться с кем-то, а может быть обсудить наболевшие проблемы в ходе спринта с командой, предложить улучшения.
Как насчёт ещё парочки командных мероприятий? Одно из них — это демо: давайте покажем, что мы сделали. Другое — это ретро: давайте поговорим о том, что шло хорошо, обсудим проблемы, предложим улучшения.
Кроме того, заказчик может ожидать релиз, и по итогу спринта всё готовое нужно ещё и зарелизить, а неготовое — оставить на разбор и сообщить, что это не сделали и когда будет сделано.
Ещё стоит сказать про daily standup — ежедневные маленькие встречи команды для синхронизации в формате «что я сделал, что делаю, что планирую делать, есть ли блокеры». Такую встречу стоит проводить, все мы люди и хотим минут 15 пообщаться, увидеть друга друга, увидеть команду, узнать статус по блокирующим задачам, попросить помочь, предложить помощь и всякое такое.
У всех этих командных мероприятий — планирование поедания слона и ведение задач, дейли, демо, ретро, релизы — должен быть ответственный. И это project manager. Если с задачей что-то пошло не так, не получается, не хватает информации, поменялись приоритеты, появились срочные баги, поехали сроки, кто-то заболел — всё это поможет разрулить хорошее управление проектом.
Описанные выше командные мероприятия напрямую влияют на внутренний климат. Потому что команда — это когда делаем задачи вместе, а не каждый в своем углу. Разработка представляет собой длительный умственный процесс, на который крайне негативно влияют частые переключения контекста. Поэтому четко сформулированная задача и время на её реализацию без отвлечения — залог успеха.
Помимо вышеописанного нужно ещё знать в деталях, как работает продукт и уметь тестировать его как пользователь: знать, где и под каким аккаунтом зайти, что и в каком порядке нажимать, что уже сделано и что ещё не доделано.
habr.com
Какой же он, менеджер ИТ-мечты разработчика?..
В чём ценность менеджера, называемого владельцем продукта, для команды разработчиков? В мире есть компании, которые практикуют подход без этой роли, подразумевающий общение разработчика с заказчиком напрямую. Такой сам себе менеджер. А есть компании, где роль владельца продукта явно выделена. Такой подход к работе практикуется и у нас в ДомКлик.Разрабатывая ИТ-продукты определенное количество времени, начинаешь задумываться о том, откуда берутся сроки, насколько эффективен ты и команда, и, конечно, о том, как на это можно влиять. Для чего? А для того, чтобы не работать по ночам, не работать сверх нормы, не делать бесполезное и «в стол», и еще куча других «не». Ведь очень хочется получить результат, который можно ощутить, вложив столько сил не зря. Про личную эффективность существует куча разных методик, о которых стоит рассказывать отдельно. А вот про командную эффективность частично поговорим здесь.
Если вы разработчик, то наверняка у вас в команде есть такой человек, как менеджер. Как часто вы задумываетесь о том, какая у него роль и чем же он может вам помочь, кроме как спрашивать каждый день, когда будет готово?
В поисках ответа на этот вопрос известная компания Google проводила различные эксперименты и пришла к выводу, что менеджер нужен команде и даже влияет на ее эффективность. В своей книге «Работа рулит, или Почему люди хотят работать в Гугл» Ласло Бок рассказывает о разных экспериментах. Один из них — это проект «Кислород», в ходе которого сравнивали эффективность разных команд и оценивали, как тот или иной менеджер влияет на эту самую эффективность своими действиями. Прочитать о нем подробнее можно по ссылке: learn-about-googles-manager-research.
Относительно своего опыта я хочу рассказать о своих ожиданиях от владельца продукта в команде и какие действия влияют на ее эффективность. Я буду использовать некоторые слова и отсылки к книге Максима Дорофеева «Как сберечь мыслетопливо и опустошить инбокс» про обезьянку и кнопку.
Для удобства я поделю описание ожиданий на 4 крупные части:
- управление продуктом;
- управление проектом;
- управление командой;
- технический бэкграунд.
Бизнес и продукт. Управление и развитие
Идея
Это то, с чего всё начинается — мы хотим что-то создать. Как донести свою идею так, чтобы понимание было максимально одинаковым? Описываем, делаем зарисовки, формулируем метрики, показываем, определяемся с реализаций, составляем план внедрения и проверки гипотезы. Теперь это у нас проект. Появляются сроки реализации. Чем быстрее сделаем, тем быстрее получим результаты.Если у нас несколько идей, то получается, что нужно несколько проектов планировать. Появляются приоритеты и план работ: что будет сделано раньше, а что позже.
Конечно, многое зависит от размера команды и самой идеи. Но это всё к чему? Для чего нам эти планы и проекты? Представим, что у вас есть Х золота на реализацию идеи. Реализация одной идеи стоит Y золота. Каждый разработчик за свой труд хочет получить Z золота. Хватит ли у вас золота? Как это узнать? Нужно понимать, из чего будет состоять план реализации идеи. Часто слышу, что невозможно написать план, потому что неизвестно, что писать, невозможно всё предусмотреть и вообще вдруг всё поменяется, а мы тут план какой-то собираемся писать. Проще оставить на потом, вдруг не придется думать, хотя это не так. Да, план сложно писать, потому что нужно думать и погружаться в детали, это требует умственных затрат. План — это наш контракт между бизнесом и разработкой. Любые изменения могут повлиять на сроки и стоимость, но без плана невозможно будет оценить влияние.
Так как мы хотим еще и развивать успешно запущенный продукт в долгосрочной перспективе, нам по-прежнему будет нужна команда разработки. При активном развитии скорее всего понадобится увеличивать команду. Как понять, сколько нужно добавить людей в этом году? Сколько еще нанять разработчиков? Чтобы примерно посчитать, нужно четко понимать, как хотим развивать продукт, что именно собираемся делать, что будет через полгода. Поэтому мы заранее думаем об этом, пишем цели.
Цели
Ставим цели. А сколько их нужно? И как ставить?Все мы хотим делать что-то полезное, то, что несет ценность, то, чем будут пользоваться люди. Поэтому важно уметь четко формулировать стратегические цели. Они должны быть понятны команды, ведь это способ показать, куда будет развиваться продукт, который они делают. Целей не должно быть много, иначе это усложнит и приоритизацию, и ориентирование в них при дальнейшей реализации. Для всего этого хорошо подходит известная формула SMART.
Прежде чем делать что-то новое, фичу или продукт, хорошо бы провести продуктовое исследование о надобности этого. Если мы получили ожидаемые результаты, то можно начинать прорабатывать детально клиентский путь, или фичу, или продукт, договариваться с руководителями смежных команд.
Важно приоритизировать цели. Цели и приоритеты нам очень пригодятся в управлении проектом и в реализации, потому что можно будет оценить разработку и дальше понимать, хватит ли нам сил реализовать всё, понимать, что важнее и что можно сделать первым, а чем можно пожертвовать. Ситуация в команде может меняться по разным причинам, и скорость разработки тоже, и может случиться так, что всё не получится успеть, поэтому приоритеты важны уже в самом начале.
Важно подготовить цели и оценить их на предстоящий период уже к концу текущего, чтобы была понятна перспектива, чем будет заниматься команда и как будет развиваться продукт. Поместить это всё можно на наглядную схему, чтобы все могли посмотреть и не тратить «мыслетопливо» на попытки вспомнить.
А теперь запишем
Думаю, отдельно стоит проговорить, почему все цели, планы и проекты лучше записывать в общий инструмент (например, Confluence). Во-первых, команды и все причастные к этому продукту коллеги будут понимать, что вы делаете, куда собираетесь развиваться и могут ли они чем-то вам помочь. Во-вторых, это асинхронная коммуникация: туда всегда можно заглянуть, если кто-то что-то забыл. В целом это помогает разгрузить голову (не надо специально что-то запоминать или выучивать), и не придётся спрашивать каждый раз или слушать часовые лекции. Можно будет оставить комментарии не сразу, а потом, когда мысль отлежится и мозг сгенерирует какую-то интересную идею. И конечно, еще это снижает bus-factor. В-третьих, это уважение к коллегам, так как помогает всем сэкономить время и мыслетопливо.Управление проектом
Вот у нас есть идеи, мы составляем по ним планы. А что дальше? Идея становится проектом. Много идей — много проектов. Каждый проект хочется завершить. Кажется, тут всё просто: бери да делай. Делать, конечно, нужно, не спорю. Но у меня возникает несколько вопросов:- Сразу всё будем делать?
- А в каком порядке будем делать?
- А как поделим? Нас же много, кто и что будет делать?
- А точно уже всё готово, чтобы делать?
- А как убедиться, что работает как нужно?
- А как проверить, что результат есть?
- А когда считать, что уже готово?
- А кому-то сказать надо, что уже готово?
- А кто-то ждёт, зависит от нашей готовности?
- А что сделать раньше, а что потом?
- А если кому-то нужна помощь?
- А если кто-то заболел?
- И куча других вопросов...
- И кто вообще за этим всем следить должен?
Попробую ответить на вопросы, которые я написала.
Делать, конечно, будем сразу НЕ всё, а по крупным частям, потому что слон довольно большой. Чтобы понять, в каком порядке делать и когда, составим план действий по частям слона, дадим верхнеуровневую оценку. Приоритеты у нас уже есть.
Дальше будем делить крупные части на составляющие. По каждой из них составим план, декомпозируем и накидаем задач, ещё раз оценим, на этот раз подробнее. Получится много задач, которые нужно будет делать в определённом порядке всей командой. Но не вся команда будет делать одну задачу, а единовременно будет по одной задаче на одного участника до тех пор, пока не сделает. Задачи могут блокировать друга друга, зависеть друга от друга.
Хорошо бы использовать прозрачный для всех инструмент для ведения задач и всего это безобразия, иначе можно запутаться и возникнут нежелательные последствия: поедут сроки и качество. В качестве такого инструмента могу предложить JIRA.
Хорошо бы уметь применять инструмент правильно. Для этого можно взять, например, Agile и спринты, допустим, двухнедельные итерации. Это поможет ограничить для команды список дел на ближайшие две недели, и с ними будет проще справиться, потому что ближайшее будущее известно, нам понятно, что нужно сделать и кому помочь. Заведём для этого регулярное командное мероприятие и назовём его «планирование спринта».
Посмотрим поближе задачку. Она относится к крупной части нашего слона и является маленькой его частью. У неё есть описание «что и зачем будет делать». А также у неё есть несколько состояний: базовые "todo", "in progress", "done". Довольно удобно ещё использовать состояния "review" и "testing". Рецензирование кода в ходе разработки — это командное мероприятие, каждый разработчик находится в контексте вносимых изменений и может помочь с реализацией и качеством. Тестирование — тоже очень важный этап для продукта, оно напрямую влияет на качество и положительные эмоции, а также помогает увеличить пользу от использования продукта. Про него нужно писать много и отдельно. Кроме того, тестирование поможет нам определить, соответствует ли результат изначальной постановке задачи. Если всё работает как ожидалось, то можно ли считать задачу готовой? И да, то переведём задачу в состояние "done".
Вот сделали мы задачи в спринте. Что дальше? Остановимся и посмотрим, что творили две недели? Конечно! Ведь две недели — это хороший период для того, чтобы сделать что-то ощутимое, а может быть ещё и поделиться с кем-то, а может быть обсудить наболевшие проблемы в ходе спринта с командой, предложить улучшения.
Как насчёт ещё парочки командных мероприятий? Одно из них — это демо: давайте покажем, что мы сделали. Другое — это ретро: давайте поговорим о том, что шло хорошо, обсудим проблемы, предложим улучшения.
Кроме того, заказчик может ожидать релиз, и по итогу спринта всё готовое нужно ещё и зарелизить, а неготовое — оставить на разбор и сообщить, что это не сделали и когда будет сделано.
Ещё стоит сказать про daily standup — ежедневные маленькие встречи команды для синхронизации в формате «что я сделал, что делаю, что планирую делать, есть ли блокеры». Такую встречу стоит проводить, все мы люди и хотим минут 15 пообщаться, увидеть друга друга, увидеть команду, узнать статус по блокирующим задачам, попросить помочь, предложить помощь и всякое такое.
У всех этих командных мероприятий — планирование поедания слона и ведение задач, дейли, демо, ретро, релизы — должен быть ответственный. И это project manager. Если с задачей что-то пошло не так, не получается, не хватает информации, поменялись приоритеты, появились срочные баги, поехали сроки, кто-то заболел — всё это поможет разрулить хорошее управление проектом.
Управление командой
На мой взгляд, это очень большая тема, интересная и сложная, о которой можно говорить много и долго, потому что управление командой — это управление людьми. О чём же хочется поговорить?Команда
Команда — это люди, и все они разные, даже если вы набирали схожих по духу и навыкам ребят. От набора до формирования команды проходит долгий путь, основная часть которого — это решение общих задач и достижение общих целей. Команда представляет собой целостный организм, все компоненты которого работают слаженно, эффективно и в дружелюбной атмосфере. Почти половину рабочего времени команда находится в общении друг другом.Процессы
Хорошо построенные процессы помогают сформировать и объединить команду, направить её в нужном направлении, а также управлять её эффективностью. Особенно управлять её эффективностью. Все работают с разной скоростью, и эта скорость постоянно меняется: каждый час, каждый день, неделю, период жизни, и на нее влияет множество различных факторов. Например, на всё новое мы тратим больше энергии, чем на то, что мы уже делали или привыкли делать. Если мы ожидаем, что командные мероприятия проходят в определённое время и день, и знаем, сколько времени это займёт, то мы можем спокойно планировать свой день. Неожиданные переносы мероприятий и отмены ломают ритм. Чтобы заново настроиться и запуститься нужны дополнительные ресурсы. Всё это связано с тем, как функционирует мозг.Описанные выше командные мероприятия напрямую влияют на внутренний климат. Потому что команда — это когда делаем задачи вместе, а не каждый в своем углу. Разработка представляет собой длительный умственный процесс, на который крайне негативно влияют частые переключения контекста. Поэтому четко сформулированная задача и время на её реализацию без отвлечения — залог успеха.
Мотивация
Долгосрочное планирование является хорошим мотиватором для команды: каждый хочет знать, куда и как будет развиваться продукт, компания, он сам. Поэтому, например, я очень ценю ежеквартальные и ежегодные встречи в нашей компании. Кроме того, зная направление движения можно предложить идеи для развития и участвовать в этом.Технический бэкграунд
Его можно и нужно развивать. Очень хорошо иметь представление о таких понятиях и вещах, как интернет, браузер, почтовый клиент, VPN, различные мессенджеры, инструменты аналитики, базы данных, сервисы, персональные данные, аутентификация и авторизация, приложение, бэкенд, фронтенд, тестирование, кеш, UX, интерфейс и всё к нему относящееся (цвета, кнопки, карты, и т.п.).Помимо вышеописанного нужно ещё знать в деталях, как работает продукт и уметь тестировать его как пользователь: знать, где и под каким аккаунтом зайти, что и в каком порядке нажимать, что уже сделано и что ещё не доделано.
В заключение
Владелец продукта играет важную роль в составе команды, и его роль — это клей, который делает из людей команду. Он помогает ей организоваться и эффективно создавать и показывать результат, который ожидает бизнес. Владелец продукта распределяет роли, находит интересные задачи, налаживает внутрикомандный микроклимат и понятные процессы, разруливает любые коммуникации. Очень хочется созидать и делать классные фичи, а не выяснять отношения.
Менеджер мечты в разработке ИТ-продуктов
Сейчас я работаю с несколькими командами разработки. В каждой из них есть менеджер, он же владелец продукта. В ежедневной работе я достаточно часто общаюсь с каждым из них. Раньше я работала внутри...
habr.com