Метка: Open Product Management

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

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

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

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

Читать далее

---

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

Читать далее

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

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

Читать далее

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

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

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

Читать далее

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

---

Читать далее

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

---

Читать далее

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

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

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

---

Читать далее