- PVSM.RU - https://www.pvsm.ru -
Не так давно Стивен Синофски (экс-вице-президент подразделения Windows в Microsoft) начал вести свой блог [1], в котором он делится мыслями о продуктах, продуктовой разработке и управлении.
Мы [2] с любезного разрешения автора решили заняться переводом его статей. Представляем вашему вниманию перевод первой статьи из этой серии.
Одна из масштабных проблем в создании технологичных продуктов заключается в том, что для вывода продукта или услуги на рынок нужно, чтобы блестящие инженеры добились блестящих результатов — при этом они не могут знать, приведет ли их выбор к успеху или провалу. Это кажется очевидным, но часто такая загвоздка – главный виновник напряжения в команде разработчиков или просто любой группе.
Примечание: Говоря «инженер», под этим мы подразумеваем все специализированные навыки, необходимые для создания продукта, включая разработку, тестирование, дизайн и прочее. Более того, под «продажами» или «маркетингом» мы имеем в виду все специализированные умения, которые требуются для передачи продукта клиентам и его поддержки — это целый спектр навыков и обязанностей, которые крайне важны. Независимо от того, сколько существует специализаций, границы между ролями всегда нечеткие — и это хорошо.
Каждый не-инженер, который хоть раз общался с инженером, знает как сложно (или неприятно) выслушивать, что «что-то возможно, а что-то — нет», или что «это правильно, то бессмысленно, а вот это — глупее некуда». Точно так же и каждому инженеру знакомы неприятности в общении со специалистом по продажам, продавцом, или потребителем, который настаивает на том, что «делать нужно именно так», но не может хоть сколь-нибудь разумно объяснить, почему. Это обычно называют «естественным напряжением» или «организованный баланс сил», влияющих на команду.
Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?
Справиться с этим непросто. Конечно, можно отправить инженеров к потребителям или же заставить «продажников» сидеть на совещаниях по архитектуре, но это смешно и никак не влияет на указанные проблемы и обстоятельства каждой из сторон. На самом деле, простого решения нет, поскольку реальность основана на опыте, культуре, а иногда и временных рамках для разных членов команды разработчиков. Чем принимать естественное напряжение как нечто неизбежное, полагаться на байки или пытаться совместить ДНК команды, можно найти более верный подход.
Если под командой вы понимаете горстку ребят, которые приходят на работу, чтобы каждый день (и ночь!) принимать сложные решения, тогда самым важным для нее будет разделяемое всеми и подробно очерченное представление общего плана продукта. Исторически сложилось так, что планирование софта еще не дозрело до того уровня планирования, на котором оно находится в большинстве других инженерных областей (строительство, транспорт). По большей части это можно считать плюсом — это та самая «мягкая» часть софта, которая делает его разработку юркой, гибкой и способной быстро подстроиться под текущую обстановку. Это сродни тому, как в сфере блогов и социальных медиа переформулировать сообщение о продукте, адресованное клиентам можно гораздо быстрее, чем во времена затянутых сроков разработки и печатной рекламы. Опять же, это и хорошо.
Но, если каждый из подходов в команде увеличивает ее креативность и гибкость, то и хаос не заставит себя долго ждать. И, что еще хуже, если все путается и никак не сходится, начинаются взаимные обвинения. А вкупе с оценкой производительности или операционными собраниями, проблема, возникшая как небольшое разногласие, очень быстро становится камнем преткновения или даже вовсе «политическим вопросом». Иногда поражаешься, как быстро даже те люди, которые искренне были настроены на совместную работу, могут начать страдать от так называемого «естественного напряжения», которое затем превращается в полный разлад в работе.
План того, над чем работает команда, может выглядеть тяжелым и сложным. Может. Но не должен. Другими словами, план — это «основа для принятия решений». Легко создать такой план, который расскажет, каким чудесным будет результат работы, и как чудесно будет делать на нем деньги. Это легкая часть плана.
Еще одна простая часть — перечисление всего, что не будет сделано — чтобы все понимали идею, инвертируя то, что планируется реализовать. Звучит несколько странно. Помню, как впервые узнал о методе намеренного детального описания всего, что не входит в цели проекта. Мне это напомнило разгадывание головоломки — и, возможно, этот специфичный инструмент полезен для некоторых команд разработчиков. Если вы перечислили цели проекта, нужно ли тогда говорить о «не-целях»? То же самое касается ранжирования задач или планов по приоритетам Часто, когда видишь списки задач/целей с приоритетами, непонятно, какие из них будут реализованы (Все обязательные и несколько необязательных? Большинство обязательных? и т.д.). Лучше всего было бы просто перечислить то, что вы обязуетесь действительно выполнить, так как, по большому счету, я не думаю, что хоть кто-то из вас работал над проектами, располагавшими избытком времени или денег!
Сложная же часть в подготовке плана — сформулировать, зачем создается продукт и каким образом он станет успешным. Эта сторона относится к общественным наукам, а у инженеров с ними туго. Вы не можете доказать, что какая-либо разработка будет успешна на рынке, поскольку нет уравнений, которые регулировали бы его поведение. Аналогично, роль технолога — очертить траекторию развития технологий в таком мире, который, возможно, будет отличаться от того, в котором мы сейчас живем, и от той реальности, в которой люди тратят деньги сегодня. Это социальный аспект, который сложен для сотрудников отделов продаж и маркетинга.
Для любого проекта, объем которого выходит за рамки команды из нескольких человек или отличается сложностью, крайне важен первый шаг – сформулировать «как» и «зачем» создается продукт, а не только «что» создается. Реальность такова, что каждый член команды только выигрывает от описания ситуации и мотивации для воплощения проекта. Вооружившись такой информацией, мы получаем основу для принятия решений о том, как реализовать детали проекта, их приоритетности, о том, как продукт будет позиционироваться или продаваться и тому подобное. Удивительно, как часто видишь инженеров, которые точно знают, что именно «нужно» сделать, при этом, не имея хорошо продуманной «истории продукта», то, зачем он создается. Равно, как нередко встречаешь и маркетологов, которые знают, какого рода история будет хорошо продаваться, но не знают, как ее создать. Смысл плана — создать основу, объясняющую «как» и «зачем», но не «что» нужно сделать.
Конечно, все меняется. Писать код сложнее, чем хотелось бы. Конкуренты занимают свободные места. Взгляды клиентов изменяются. Фактически, любой проект будет проходить через фазу пересмотра разделов и изменения деталей плана. Самая неочевидная особенность плана в том, что само его наличие означает, что у вас есть инструменты, чтобы его изменить, совместно, как единая команда. Отсутствие плана создает хаос, взаимные обвинения, уклонение от ответственности, которые мы все хорошо знаем. План не предполагает жесткости, но, как и любой инструмент, он может быть использован некорректно. Есть люди, которые считают, что план – то, что не вырубить топором. Есть так же люди, которые, напротив, думают, что это всего лишь отправная точка и все в нем должно быть подвижно. Разработка продукта — это динамичная система с планами, в которых определены междисциплинарные опорные точки для команды в целом.
При разработке плана имеет смысл учитывать:
При взгляде на эту систему есть три вещи, которые стоит упомянуть.
Во-первых, план — это не первостепенная бизнес-цель, согласно которой нужно «получить N% из Y», где Y — пользователи, деньги или некоторая единица измерения доли (рынка – прим. пер.). Также это и не «прикрутить 5 таких-то фич». Это возможные способы оценки успеха, но не главное в плане. Самое главное в плане — решение проблемы: либо такой, которая возникла из-за недовольства клиентов (сформулированная необходимость) или же такой, которую команда предвидит заранее (несформулированная необходимость).
Во-вторых, план — это продукт командной работы. Даже сама разработка плана требует скоординированных усилий всей команды. Можно сказать, что план – это не «спущенное сверху» (от руководителей к исполнителям) и не «сгенерированное на местах» (краудсорсинг) решение. Планирование – это процесс, скорее, требующий совместных действий «сверху», «снизу» и «из середины». Лучшие планы — те, которые объединяют самые удачные идеи от наиболее широкого круга людей, участвующих в разработке продукта.
В-третьих, может возникнуть соблазн представить план в виде схемы в PowerPoint и сделать на каждый шаг по слайду. Многие планы так и пишутся :-) Единственно верный подход к планированию — это написать план словами, в Word’е, а затем убедиться, что в нем есть последовательность и смысл. Процесс написания плана так же важен, как и сами идеи, изложенные в нем. Возможно, это тема для будущих постов.
Когда у команды возникает общее понимание всех вопросов, изложенных выше, следующий шаг можно сделать вместе. Есть две ключевые части плана, которые сводят всё воедино и помогают соединить «план разработки» и «общественную науку».
Есть много других частей плана — сам бизнес-план, маркетинговый план, PR-план, структура ценообразования, материалы для обучения тех.поддержки и продавцов, операционный и план масштабируемости, тест-план, self-host план и множество других. Все вышесказанное описывает некоторые меры, которые помогут работе всей команды, если принять их до фактического старта проекта. Когда команда входит в резонанс, то многое становится возможным сделать вместе и заранее. Это просто система, созданная для того, чтобы первая же поставленная цель объединяла членов команды на одном и том же этапе работы.
Как бы мы ни хотели, волшебного рецепта не существует. Если бы он был, каждый план составлялся бы по нему и работал идеально. Ни один продукт не разрабатывается повторно, поэтому наша способность сообща экспериментировать и создавать/изменять отдельные образцы продукта — ограничена. Все, что у нас есть это опыт и возможность особо внимательно отнестись к ситуации и существующей реальности при разработке продукта.
P.S. Спасибо, что прочли. Данный пост — первый в этом блоге, учебный процесс. Буду рад обратной связи касательно тона, структуры и подхода к повествованию. Всё это сложные темы, и, возможно, я вижу скорее полутона и нюансы, чем четкий «ответ на вопрос». Дайте мне знать, что вы думаете об этом.
P.P.S. Этот пост общего характера, а не о чем-то конкретном, реализованном в прошлом или настоящем.
Автор: AIVolkov
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/26061
Ссылки в тексте:
[1] блог: http://blog.learningbyshipping.com/
[2] Мы: http://unit6.ru/team-lbstranslators
[3] понимать конкуренцию: http://blog.unit6.ru/2013/01/learning-from-competition.html
[4] Источник: http://habrahabr.ru/post/167195/
Нажмите здесь для печати.