Рубрика «продуктовая разработка» - 4

«Попался. Предатель. Ржунимагу». Как-то так реагируют люди, узнав, что у меня iPhone. И вот стою я перед вами, уличенный в пользовании продуктом конкурента — и признаю себя виновным.

Но, если отложить в сторону блогеров с их постами в духе «попался», на деле есть реальные причины для того, чтобы пользоваться продуктами/сервисами помимо тех, что сделаны вами (или компанией, где вы когда-то работали). Можно написать хоть тысячу твитов, но, думаю, это всё равно все знают. Подход, применяемый во многих отраслях — недооценивать или даже чураться конкуренции — подробно описан и изучен, и выводы, к которым он приводит, говорят о том, что конкуренция это хорошо.

Способность учиться у конкурентов не только необходимо развить у всей команды разработчиков продукта, но она также может быть своего рода навыком, который имеет смысл оттачивать. Давайте в деталях рассмотрим всё, что касается использования продуктов конкурентов.
Читать полностью »

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

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

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

Зачем делать отчеты о поездках?

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

Отчет, это всего-то — набор слов и материалов, это далеко не список дальнейших действий, поскольку их можно сформулировать лишь, собрав данные с разных точек зрения и обдумав все последствия. На самом деле, ошибочно при разработке продукта тотчас кидаться воплощать все соображения, которые кто-то «привез» из одной из командировок или же чью-либо личную точку зрения (и не важно, кто из команды написал этот отчет). Это всего лишь рассказ, и чтобы превратить его в конкретные шаги — смену плана или изменение состава возможностей — нужна отдельная работа.

Подходы

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

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

От кода к продукту. Ciklum Speakers Corner, Днепропетровск

Приглашаем Вас на очередное мероприятие серии Ciklum Speakers’ Corner под названием «От кода к продукту» от Димы Маленко. На мероприятии вы сможете нырнуть в мир особенностей продуктовой разработки.

Что будет обсуждаться:
— Разработчики любят код
— Готовый продукт – это намного больше, чем просто код
— Мечтаешь создать свой стартап? Научись быть инженером, дизайнером, админом и…
— Стартап? Простые способы стать знаменитыми
Читать полностью »

Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог, в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.

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

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

Естественное напряжение (sic!)

Каждый не-инженер, который хоть раз общался с инженером, знает как сложно (или неприятно) выслушивать, что «что-то возможно, а что-то — нет», или что «это правильно, то бессмысленно, а вот это — глупее некуда». Точно так же и каждому инженеру знакомы неприятности в общении со специалистом по продажам, продавцом, или потребителем, который настаивает на том, что «делать нужно именно так», но не может хоть сколь-нибудь разумно объяснить, почему. Это обычно называют «естественным напряжением» или «организованный баланс сил», влияющих на команду.

Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js