Менеджеры любят иностранные словечки типа заапрувить (согласовать), скилсы (навыки), фидбек (обратная связь). Кажется, что русские слова в бизнес-среде уже не особо нужны, но всё же остались выражения из русского языка, но которые уже изрядно всем надоели.
«Принято»
От менеджеров в течение дня может приходить несколько сообщений с одним словом «принято». Всё логично, человек принял от коллеги информацию и, скорее всего, должен передать её клиенту или руководителю. Но после долгой работы в такой атмосфере начинает воротить от менеджерского «принято».
«Я вас услышал»
У некоторых от этой фразы начинается нервный тик. Обычно фразу «я вас услышал» употребляют в момент спора, когда, например, не удается убедить клиента в своем мнении и приходится принимать его позицию пренебрежительным «хорошо, я вас услышал». Это выражение калька от английского «I got you».
«Активная жизненная позиция»
Если у вас активная жизненная позиция, вас точно примут на работу в какую-нибудь компанию. Но что значит это выражение? Что такое активная жизненная позиция? Как она проявляется? Для этого нужно быть экстравертом? А интроверт, который хорошо выполняет свою работу, уже не годится?
Майндкарты для бизнеса Как структирировать свои дела и задачи
В общем, «активная жизненная позиция» — это какое-то абстрактное понятие, лучше не писать так в резюме и вакансиях. Пишите конкретно: например, инициативный.
«Пул задач»
Да чего угодно «пул», хоть «пул проблем». То есть «пул» — это совокупность чего-либо. Первоначально так называли временное объединение между предпринимателями ради какого-то проекта. Сейчас у менеджеров постоянный «пул».
«Самый оптимальный вариант»
В это выражение закралась ошибочка. «Самый оптимальный вариант» — плеоназм. Достаточно просто сказать «оптимальный вариант», не нужно добавлять превосходную степень. «Оптимальный» образовано от латинского optimus, что означает «наилучший, наиболее благоприятный».
Источник: dzen.ru
7 ключевых и сотни дополнительных задач PM при запуске продукта
Привет, я Даша Васильева, Market Making Product Manager в Quadcode. В этой статье попробуем разобраться: кто такой PM, зачем он нужен бизнесу и как помогает команде достичь поставленных целей.
2613 просмотров
Сегодня уже довольно сложно встретить компанию, в которой нет продакт-менеджеров или людей, которые выполняют функции продакта: в маленьком стартапе роль PM часто берет на себя CEO, а в больших корпорациях есть целые продуктовые департаменты во главе с CPO, PM (Product Manager) и PO (Product Owner), отвечающими за разные направления бизнеса. Но до сих пор мало кто до конца понимает, чем занимается этот самый продакт.
Говоря PM (продакт, менеджер продукта), я буду иметь в виду человека, сочетающего в себе функции непосредственно PM (продумывание стратегии, маркетинга, аналитики) и PO (детализация задач и работа с командой разработки).
Бизнес задача и коммуникационное решение
Статья будет полезна:
— сотрудникам компаний, в которых есть продуктовое направление;
— тем, кто сам подумывает перейти в это направление, глядя на зарплаты продактов;
— самим продактам, чтобы скинуть статью друзьям и родственникам, которые спрашивают: «А чем ты занимаешься на работе?»
Итак, давайте разберем по пунктам, чем занимается PM в компании.
Первостепенные задачи продакта
1. Когда направление / продукт только создается, первая и главная задача PM — вместе с руководителями бизнес-ветки создать общую картину продукта. В рамках этого продакту необходимо ответить на вопросы: «Какую проблему мы решаем?», «Какую пользу это принесет компании?», «Нужно ли собственное решение или уже есть готовые решения для этой проблемы?» и так далее. Также во время формирования направления продакт обозначает стратегические цели команды и большими мазками описывает, как эти цели будут достигнуты.
Обычно на этот этап уходит от недели до месяцев. Всё зависит от:
— Опыта PM в этой сфере и наличия у него «профессиональной чуйки».
— Количества конкурентов, которых нужно проанализировать.
— Текущей стадии развития компании и межкомандных зависимостей.
— Уровня доверия бизнеса к PM.
Конечно, могут быть и другие причины, но, как правило, на этом этапе они такие.
Результат этого этапа — документ, в котором на одной-двух страницах описано видение развития направления. Я использую для этого Lean Canvas, с помощью которого фиксирую свое представление о продукте, который буду развивать.
Представим, что мы вытянули жребий и теперь наш черед организовывать идеальный отпуск в компании друзей. В нашем примере Canvas выглядел бы примерно так:
В Canvas мы:— обозначили проблемы, которые осложняют наш идеальный отпуск;— предложили решение этих проблем;— указали, почему лучше организовать самим, чем обратиться за помощью к посредникам;— определили, по каким параметрам будем измерять «идеальность» путешествия;— верхнеуровнево описали, из чего будет состоять наш отдых;— выяснили, на что предстоит потратиться, а где мы можем получить выгоду.
2. С первым пунктом закончили, успех! Далее PM начинает формировать конкретный пул задач (Backlog), которые нужно сделать для создания MVP (минимально жизнеспособный продукт). После этого продакт вместе с архитектором или техлидом команды оценивает сложность и важность каждой задачи.
Результат этого этапа — дорожная карта (Roadmap) продукта: документ, где с разбивкой по кварталам указаны задачи на создание части функционала (Features), которыми будет заниматься команда. Также на этом этапе становится понятно, на каких задачах нужно сфокусироваться в первую очередь в текущем / следующем квартале.
На Roadmap мы расположили все задачи, которые нужно выполнить. Указали время на каждую задачу и сроки, к которым она должна быть сделана. Также описали значимые блоки задач (Milestones), которые планируем выполнить к определенному сроку, и метрики, по которым будем измерять успех. Помимо этого описали пользовательские истории: что сможет сделать пользователь (в нашем случае участник путешествия), когда мы выполним часть задач.
Проработка задач
3. Итак, определились, на каких задачах будет сделан акцент. PM глубже погружается в каждую задачу:— какую проблему решаем;— какой функционал хочется получить по итогу;— что нам даст реализация этой задачи;— как реализация этой задачи повлияет на те или иные метрики.
На этом шаге продакт-менеджер тесно общается со всеми заинтересованными лицами и, балансируя между бизнес-пожеланиями и сложностью технической реализации, готовит развернутое описание бизнес-требований к функционалу с указанием сценариев его использования. Чем подробнее PM проработает задачу, тем вероятнее, что по итогу бизнес получит именно то, что хочет.
Ниже пример хорошо описанной задачи по выбору страны для отпуска. Подробно указано, что нужно сделать, по каким критериям будет проводиться оценка стран: что первостепенно, а что — второстепенно. Указано, какой результат должен получиться.
Пример хорошо описанной задачи по выбору страны для отпуска.
А теперь ниже пример плохо описанной задачи по выбору страны для отпуска: задача описана без конкретики, в формате «сделай хорошо». В данном случае исполнитель потратит значительно больше времени на выполнение задачи, а результат может быть не тем, который ожидает заказчик.
Пример плохо описанной задачи по выбору страны для отпуска
Передаем задачи в разработку
4. Когда задачи описаны и архитектор / техлид подготовил техническое решение, начинается подробное обсуждение (Grooming) задач с командами. Тут продакт отвечает на все вопросы, о том, что бизнес хочет получить от реализации каждой задачи. Также РM участвует в решении проблем с зависимостями от других команд.
5. Далее начинается разработка функционала, в ходе которой продакт отвечает на новые вопросы команды, которые возникают по ходу работы. А также PM решает проблемы с «узкими местами» (например, медленное тестирование, из-за чего разработанный функционал долго не внедряется) и в целом обеспечивает команду необходимой информацией и ресурсами.
6. По итогам разработки части функционала продакт проводит приемку и (при необходимости) презентует результат заинтересованным лицам. Именно продакт отвечает перед бизнесом за создание ожидаемого инструмента или продукта и достижение желаемых результатов.
Выходим на новый круг
7. Раз в квартал (иногда чаще или реже) PM определяет и согласовывает с бизнесом очередной пул задач, который будет сделан в следующем квартале. Конечно, если вдруг в ходе этих трех месяцев появляется какая-то прорывная идея, реализация которой принесет больше пользы компании, приоритеты можно пересмотреть. Но Backlog на квартал — это тот костяк, на который стоит опираться.
Это еще не все
Выше описан основной процесс работы PM, которого я придерживаюсь. Помимо этого продакт:— на постоянной основе мониторит рынок;— старается придумать новаторские решения;— валидирует гипотезы;— отвечает на вопросы других департаментов;— инициирует мероприятия (тимбилдинги, брейнштормы и т. п.);— участвует в регулярных созвонах / встречах с командами.
Другими словами, формирует максимально благоприятные условия для успешного выполнения задач. При этом создавая такую атмосферу, чтобы любой член команды чувствовал свою ценность и мог свободно делиться идеями, которые позволят направлению быстрее достичь бизнес-целей.
Если обобщить, PM — это буфер между бизнесом, требующим много денег здесь и сейчас, и командой разработки со всем сложностями создания нового функционала / продукта. Человек, который умеет запросы бизнеса (как пример — увеличить финансовые показатели компании) конвертировать в конкретные задачи для других команд на понятном для них языке.
Хороший продакт — это хороший предприниматель, который прорабатывает ожидания бизнеса, анализирует рынок и определяет, как достичь целей наиболее эффективным образом. Ведь не всегда нужно изобретать новый велосипед. Иногда для решения бизнес-задачи достаточно найти уже готовое хорошее решение или человека, который прошел подобный путь.
Вместо заключения я хочу поделиться полезными материалами, которые помогут вам узнать больше о работе продакт-менеджера:
- Подборка сообщества Ask Kevin — о всех аспектах работы продактом: маркетинг, аналитика, менеджмент и не только.
- Подборка для менеджеров продукта от VC.ru.
- Статья с подборкой лучших англоязычных ресурсов и курсов для продактов.
Если остались вопросы, то пишите в комментариях или напрямую Linkedin или TG.
Источник: vc.ru
Что такое «пул задач»?
Я искал на многих сайтах определение понятия «пул задач», но большинство описаний очень расплывчаты. Где я могу найти точное определение этого понятия?
- Разрешены ли зависимости в пуле задач?
- Может ли запущенная задача обмениваться данными с другими запущенными задачами?
- Обратно говоря, разрешено ли задачам принимать данные только до запуска и разрешено ли публиковать результаты только после завершения задачи?
- Например, если одной задаче нужно передать много данных следующей задаче, то имеет смысл запускать следующую задачу сразу после первой задачи и как можно ближе к первому потоку / процессору / машине / кластеру (локальность).
7 2010-11-08T06:02:14+00:00 4
Редактировал вопрос 9-го ноября 2010 в 5:44
Комментарии к вопросу (2)
Ответ на вопрос
8-го ноября 2010 в 6:16
2010-11-08T06:16:21+00:00
Дополнительно
Я уверен, что вы не найдете одного авторитетного ответа, потому что это термин, который может означать разные вещи в разных контекстах.
В терминах C# 4.0 и Task Parallel Library, пул задач — это коллекция ожидающих выполнения рабочих элементов, которые должны быть запущены.
Чтобы грубо упростить ситуацию, задачи берутся из пула и выполняются различными рабочими потоками параллельно.
(*) В реальной реализации задачи не берутся из пула по одной, поскольку это влечет за собой слишком большие накладные расходы. Вместо этого они берутся партиями — и не обязательно в том порядке, в котором они были добавлены в пул.
Комментарии к ответу ( 0 )
Решение / Ответ
JBRWilkinson
23-го ноября 2010 в 6:52
2010-11-23T18:52:23+00:00
Дополнительно
Здесь есть некоторые проблемы с терминологией, поэтому ваши поиски в Интернете еще не дали ответа.
Пул — это имя, данное коллекции «дорогих», повторно используемых ресурсов, таких как потоки, порты завершения, соединения с базой данных. Операционная система, библиотека или структура будут управлять количеством элементов в пуле в соответствии с некоторыми эвристиками, основанными на текущей нагрузке или доступности ресурса.
Задачи обычно представляют собой единицы выполнения, такие как Отложенный вызов процедуры, Вызов делегата или Задание цели C. Самый простой случай заключается в том, что существует очередь этих ожидающих событий, созданная кодом, который требует выполнения «позже», с более низким / более высоким приоритетом, чем другие задачи, асинхронно, одновременно, в другом потоке (например,. UI-поток) или какая-то комбинация всего этого. Некоторые структуры позволяют создавать взаимозависимости задач, поэтому вы в конечном итоге принимаете довольно сложные решения, чтобы определить, какую задачу выполнить дальше, но все зависит от структуры / библиотеки / O / S
Как уже упоминалось, библиотека Task Parallel является одним из примеров взлома материала для выполнения. Другим является NSOperationQueueue в Mac OS X, который был использован для значительного уменьшения количества потоков (дорогих), необходимых для работы в любой момент времени.
Чтобы ответить на ваши вопросы конкретно:
- Зависимости зависят от используемой вами структуры / библиотеки, но это первоклассная концепция.
- Владение данными, как правило, отделено от создателя задачи и передано самой задаче, поскольку фактическая тема / CPU, на которой она работает, неясна. Одна задача, передающая свои данные другому, концептуально не является конкретной проблемой — она зависит от структуры ограничений. Используйте зависимости выполнения, если одной задаче нужен вывод другой.
- Поскольку задача владеет данными, она должна взять на себя ответственность за последующую очистку. Очевидно, что если вы передаете данные другому заданию, вам нужен подсчет ссылок или сбор мусора в дополнение к политике владения данными.
- Некоторые фреймворки позволят настроить, какие задачи выполняются, сколько ЦП, на каком уровне планирования O / S и т. Д. Если задача начинается с использования всей доступной памяти, вам, вероятно, придется разобраться с этим в своем собственном коде. Даже если вы не использовали стратегию «пула задач», это было бы проблемой.
- Задачи, созданные «позже», могут быть включены в существующий пул задач для выполнения.
Источник: kzen.dev
