Skip to main content

Клиент всегда прав … кроме случаев, когда он не прав

Запрос на улучшение

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

Одна из главных корзин? Запросы на улучшение.

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

Так как же сбалансировать такое количество запросов функций с долгосрочным видением продукта? На этой неделе StartupEdition исследует эту тему.

Читать дальше

Как нанять менеджера по продукту

Концепция найма. менеджер по персоналу ищет сотрудников. мультфильм деловых людей векторные иллюстрации. персонал и найм, кандидат на бизнес-набор Premium векторы

Классическое эссе о роли менеджера по продукту

Прошло немало времени с тех пор, как я нанимал людей в стартап, а найм в стартап сильно отличается от найма в большую компанию. В Yahoo! Search мне казалось, что мы постоянно кого-то нанимаем. Я проводил в среднем 5–9 собеседований в неделю. Это был неиссякаемый поток резюме, интервью и писем с предложениями. При этом не всегда именно я нанимал в свою команду. В свое время я принял на работу несколько менеджеров по продукту. Но кто-то постоянно нанимал менеджеров по продукту, а я обычно входил в команду, проводившую собеседование.

Читать дальше
три корзины

Руководство по продуктовому планированию: три корзины фич


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

Читать дальше

Качество - это не компромисс

Объем работы. Время. Талант.
(У автора нестандартный взгляд на классические ограничения проекта прим. переводчика)

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

Читать дальше

Расписание творца и Расписание менеджера

“…the mere consciousness of an engagement will sometimes worry a whole day.”
– Charles Dickens

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

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

Читать дальше

Семь смертных грехов планирования продукта

Юмористический комикс о планировании продукта

Предисловие

Это достаточно свободный перевод статьи Marty CaganThe Seven Deadly Sins of Product Planning. Так как я и сам работаю в роли PM, я стараюсь делать более живой перевод таких статей, руководствуясь собственным опытом. Но если у вас есть какие-то замечания и\или предложения — то я всегда открыт для обратной связи в личных сообщениях или комментариях.

Читать дальше

Безболезненные функциональные требования - Часть 4: Tips

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


Читать дальше

Безболезненные функциональные требования - Часть 2: Что такое требования?

(Уже прочитали первую часть? Она находится здесь.)

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

  1. Функциональные требования описывают как продукт будет работать с точки зрения пользователя. Не важно как именно это будет реализовано. Они описывают функциональность (или фичи). Эти требования описывают интерфейсы, меню, диалоги и так далее.
  2. Технические требования описывают внутреннюю реализацию в программе. Они описывают структуры данных, модели баз данных, выбор языков программирования, инструментов, алгоритмов и так далее

Читать дальше

Безболезненные функциональные требования — Часть 1: Зачем беспокоиться?

Начиная работать руководителем команды программистов 7 лет назад, я наткнулся (или кто-то посоветовал, уже не помню) на блог Джоэла Спольски. Джоэл пишет с юмором и не понаслышке знаком с проблемами, с которыми сталкиваются компании разрабатывающие программы и сервисы. Прошли годы, но его статьи про требования до сих пор актуальны и я рекомендую познакомится с ними всем менеджерам проектов и продуктов, которые только вступают на этот путь.

Для тех, кто хочет познакомится с оригиналом — Painless Functional Specifications — Part 1: Why Bother? Я, как всегда, открыт к любым замечаниям по моему переводу!


Читать дальше