Те, кто занимается развитием технологического бизнеса (разработка ПО, интернет-сервисы и т.д.), наверняка читали такие книги, как «Преодоление пропасти» и «Внутри торнадо» авторства Джефри Мура. Из этих книг читателю известна модель жизненного цикла технологий на рынке (хотя сама модель появилась раньше, в книге другого автора, чего сам Мур в своих произведениях не скрывает).

Если вам эти книги не знакомы, то модель легко понимается по схеме (взята с сайта www.techlifecycles.com):

Цель — это сильный внутренний мотиватор, согласно последним исследованиям в психологии, которые собрал и обобщил Ден Пинк. Работая с продуктовыми командами, я довольно часто сталкиваюсь с примерами, подтверждающими его доводы.

Отсутствие ясности на уровне видения продукта, четкого позиционирования на рынке, стратегии развития на 3-6 месяцев, давления срочности или ощущения конкурентной схватки — гасит скорость работы команды и личную вовлеченность ее участников.

Способность Владельца Продукта (роль Product Owner в терминологии SCRUM) воплощать видение продукта в своих словах и действиях, нельзя переоценить, когда мы говорим о командной разработке. Такая способность помогает команде работать сфокусированно (focus — одна из ценностей процесса SCRUM).

Фокус внимания меняет наше восприятие. Что бы лучше понять о чем это, попробуйте небольшой эксперимент. На протяжении дня держите в фокусе какую-то простую вещь, например, красный цвет. Обращайте внимание на все красное на улице и в офисе, думайте о красном в душе и лифте, найдите пару интересных фактов о самом цвете, или красных вещах. Уже к концу дня вы начнете воспринимать красный по-другому. Мужчины могут с удивлением обнаружить, что у красного есть оттенкиJ А на следующий день, вам могут приходить в голову “красные” мысли.

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

Ниже — 5 идей для Владельцев продукта о том, как усилить внутреннюю мотивацию и командную работу через видение.

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

К этой статье меня подтолкнул большой перекос, который я вижу в массовом сознании и сознании профессионального сообщества менеджеров IT компаний. Увы, сайтов про управление проектами море, а про управление продуктами — кот наплакал.

Это как если бы было море книг, тренингов, целых институтов о том, как правильно ходить, и ни одной брошюрки про то, как выбрать направление пути.

В книгах по управлению проектами (особенно для новичков) авторы очень любят начинать с тезиса о том, что мир состоит из проектов, проекты везде. Готовите еду — проект, лечитесь у доктора — проект, ковыряетесь в носу или занимаетесь любовью, даже отпуск — всё проекты.

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

Дальше я приведу несколько примеров, чем это вам может грозить.

Julie Zhuo явялется продакт-менеджером в Facebook, занимается разработкой News Feed и мобильными приложениями. Статья о том, как не превратить продукт в кладбище идей.

Есть что-то радостное и волнующее во всем новом. Сделайте поиск по картинкам в Google, и вы поймете, что я имею в виду. Слово «новый» пишется полностью заглавными буквами (будто выкрикивается), часто размещается в яркой звездообразной фигуре и усиливается восклицательными знаками. Нет ничего более захватывающего. «Новое» кричит: «Посмотри на меня, я сияю и маню! Обрати внимание на будущее, полное возможностей, которые я открываю! Возможно, я изменю твою жизнь! Как минимум, вдохну новую жизнь в твой устаревший гардероб/дом/быт/продукт».

«Новое» – это необходимое лекарство, своего рода скрытая надежда. Мы думаем, что новое всегда лучше, поэтому считаем дни до следующего грандиозного запуска, зацикливаемся на недавно добавленной функции или обсуждаем последнюю тенденцию. Каждый день я наблюдаю и слышу, как новые идеи летают в офисах, конференц-залах и кафе как теннисные мячики. Вот было бы здорово, если бы мы добавили… Я бы очень хотел, чтобы у нашего продукта появилась эта новая функция… Я действительно думаю, что можно заработать стопицот миллионов, если собрать команду и сделать…

Перевод оригинальной статьи за авторством Des Traynor

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



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

Суть любого бизнеса:
персонал, продукт, прибыль.
Если у вас проблемы с первым пунктом,
о двух других можете забыть.
Лидо Энтони «Ли» Якокка
президент Ford, председатель
совета директоров Chrysler



Как улучшить организацию процессов на предприятии? Какие методы эффективны для управления ИТ проектами и продуктами? Где набирать себе компетентных людей? Как усовершенствовать работу компании?



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

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

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

В жопу спецификации!

Несмотря на активную конференционную осень 2013г., мы не могли обойти вниманием, конференцию, которая пройдет
6 декабря в Казани — Software Project Manager Conference.



Основной акцент в данной конференции поставлен на качество докладов, широкий охват тем, умение докладчиков интересно подать информацию.
Не секрет, что многие участники приходят на конференции «на докладчиков». В этом году программа составлена так, что посетить захочется если не всех, то многих :) Понимая, что это задача трудновыполнимая мы организуем видеосъемку докладов, и записями с удовольствием поделимся.

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

Product manager – позиция неоднозначная. На постсоветском пространстве еще не сложилось полноценной культуры управления продуктом, хотя продуктовых компаний уже в общем-то немало. «Продактами» становятся бывшие бизнес-аналитики, проектные менеджеры, маркетологи и другие специалисты, каждый из которых по-своему подходит к своим новым задачам. Я хотел бы поделиться несколькими тезисами о работе с новыми фичами продукта, которые кажутся важными с моей колокольни.


Это тоже в своем роде управление продуктами, но речь пойдет о другом.

Disclaimer:

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

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

Перво-наперво, ряд вводной информации, которая отразит мою специфику:

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

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

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

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

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

Alconost — не только сервисная компания. Кроме локализации ПО и игр и создания видеороликов мы также разрабатываем несколько собственных продуктов. Для нас это новое направление, поэтому мы постоянно учимся, читаем интересные статьи.

Сегодня мы хотим поделиться переводом одной из таких статей о клиентоориентированности в процессе разработки.

В этом посте хочется поделиться личным опытом создания продукта с нуля. Путь «а давайте запилим/скопируем и выкинем на рынок» мы уже проходили. Такой подход чуть не убил нашу компанию.



По статистике, около 50% фич среднестатистического продукта никогда не используются и только 12% опций клиенты используют активно. Как всегда попадать в эти 12% функционала? А что, если я сам не являюсь пользователем этого продукта? Как сделать продукт простым и удобным? Наконец, стоит ли его вообще делать нашей компании? И как понять, будет ли продукт востребован рынком еще до его создания?

Безусловно, каждый в команде разработчиков делает всё возможное для выпуска крутого продукта. Но в случае неудачи все шишки сыплются на одного человека — менеджера по продукту. Конечно, на орехи достанется не только ему. Но именно для менеджера по продукту эта неудача — не просто «рабочий момент», а крест на всей проделанной работе.

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

Перевод статьи выполнен компанией-локализатором Alconost.

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

Сегодня моя цель – коротко рассказать о подходах data-informed продуктового менеджмента, который я исповедую и попытаться заинтересовать вас в использовании его базовых инструментов в ваших продуктах.

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

Для себя я сформулировала, что измерения успешности продукта состоит из трех блоков:

— счастье пользователей;
— успешность (качественная и количественная) итераций и релизов;
— счастье команды.

Ниже — вольный пересказ книги Running Lean, автор — Ash Maurya. Рейтинг Амазона — 4.8 из 5. Книга, насколько я знаю, на русский язык еще не переведена.

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

Допускаю, что нарушаю чьи-то права: пересказ лицензии не требует, но иллюстрации взяты из книги. Автору я писал в попытке прояснить этот вопрос, но ответа не получил.

Блог автора кгиги: practicetrumpstheory.com.

Структура пересказа

• Введение в процесс Running Lean
  • Три важнейших методологии
  • Roadmap
• Описание процесса Running Lean
  
  • Составьте «План А»
    
    • Определите кто клиенты
    • Создайте бизнес-модели
    • Ранжируйте бизнес-модели
  • Протестируйте и измените план
    
    • Подготовьтесь к проведению экспериментов
    • Категории рисков и четыре фазы тестирования плана
      
      • Фаза 1. Поймите проблему
      • Фаза 2. Найдите решение
      • Фаза 3. Валидируйте качественно
      • Фаза 4. Верифицируйте количественно
• Три стадии стартапа
  
  • Соотношение трех стадий стартапа и четырех фаз тестирования плана
  • Держите правильный фокус
  • Привлекайте финансирование вовремя
  • Масштабируйте правильно

Мы потихоньку готовимся к релизу Kotlin, в связи с чем встают новые и интересные организационные вопросы. Например: «Нужен ли нам PMM (Product Marketing Manager)?» Как это часто бывает, чтобы ответить на этот вопрос, надо сначала разобраться, кто вообще такой PMM. Поскольку я это более-менее сделал в последние недели, хочу поделиться с вами тем, что узнал.

Disclaimer: Замечу сразу, что все сказанное ниже — более или менее специфично для JetBrains, и я ни в какой части этого поста не хочу сказать, что так же устроены или должны быть устроены другие компании.