Skip to main content

Менеджер продукта в Microsoft

Steven Sinofsky

Предисловие

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

Оригинальный текст действительно не содержит ни одной картинки и весьма объемный. Но я рекомендую его всем – он очень интересный.

Есть еще одна особенность – сама роль менеджера продукта. В Microsoft она называется менеджер программы. У этой роли в Microsoft немало специфики. Одной из причин, на мой взгляд, является специфика их продуктов. Вторая в собственном изобретении роли. Но в целом роль менеджера программы очень похожа на то, что в современном мире понимают под менеджером продукта.

Сразу замечу, что процесс разработки продукта в Microsoft не является очень гибким и скорее напоминает классическое управление проекторами по PMBok. Так что если вы адепт Agile, то наберитесь терпения :)

PM в Microsoft

Когда я был в Стенфорде на этой неделе, ко мне обратилось немало менеджеров продуктов, с целью поговорить о роли Менеджер Программы в Microsoft. Роль менеджера программы – уникальная роль компании Microsoft. Она была создана в ответ на вызов по созданию продуктов, которые легче использовать, и в то же время которые являются некоторым объектом искусства новых технологий. Поэтому, когда мы говорим о менеджере программ в Microsoft, мы говорим с перспективы создания и развития этой роли на протяжении жизни компьютерной индустрии.

За время моей работы в Microsoft я занимал как позицию менеджера программ, так и позицию SDE (software design engineer, проектировщик программного обеспечения). Я пришел в компанию как кандидат на позицию SDE. Во время прохождения собеседований, я узнал о позиции менеджера программ. Тогда я подумал – “Круто!”. Похоже я нашёл отличную работу – в конце концов она звучит как невероятно крутая роль, так как в ее названии есть слово “менеджер”. Если вы читали или слышали о её описании, то знаете, что оно звучит как описание человека, который управляет всем шоу. Название должности «менеджер программы» не очень хорошее, так как они не программируют и не управляют (здесь в оригинале игра слов со словосочетанием «program manager», где «to program» – программировать, а «to manage» – управлять). Я претендовал на позицию SDE, потому что хотел писать код. Проработав на позиции SDE 4 года, я решил развиваться в сторону управления программами. Думаю, для меня это было отличное решение. Хотя мне нравилось думать, что я хороший разработчик, но я не отношусь к гениальным разработчикам. Я вряд ли добился бы большого успеха с моими навыками программирования. Но я думаю, то, что я не смог бы сделать, будучи разработчиком, я сделал с помощью навыков, которые необходимы менеджеру программы.

Далее вы найдете описание задачи управления программой глазами менеджера программы. Отмечу, что этот текст является аналитическим описанием, основанным на моем опыте. Я не пытаюсь расхваливать эту работу или преувеличить её важность. Недавно я общался с несколькими кандидатами, которым рассказывали о должности менеджера программ в других компаниях, и я чувствую, что им не рассказали всей правды. Поэтому в моем блоге я постараюсь рассказать полную историю и не буду “продавать” вам эту работу. Такой подход может заставить вас думать, что нет никакой возможности изменить или повлиять на определение это роли, но это не так. Роль, которую я описываю, находится в постоянном развитии и члены команды постоянно её развивают. Менеджер программы – это роль, которая содержит много ответственности. Но это также партнерская работа с экспертами дизайна, умными разработчиками, отличными тестировщиками и так далее. Вы все работаете вместе, чтобы определить продукт и вместе нести ответственность за свои части работы. Менеджер программы – это одна из равноправных частей всей системы.

Менеджеры программ появились в Microsoft во время разработки Excel для Macintosh. Вызов, с которым столкнулась компания, – попытка реализовать технологический шедевр (разработка для совершенно новой ОС, с использованием совершенно новых концепций графического пользовательского интерфейса). Разработчики были очень заняты тем, что пытались заставить хорошо работать такие вещи как печать, отображение, графика и так далее, одновременно пытаясь разработать новые алгоритмы для работы с таблицами и моделированием. А значит, мы недостаточно фокусировались на таких вещах как удобство использования или сценарии использования пользователями нашего ПО. Как это часто бывает, целью нашей разработки был код – это классический подход большинства организаций в настоящее время, где происходит только разработка и тестирование (иногда называемое QA). Данные и пожелания от пользователей и клиентов поступают при анализе спроса или от команды маркетинга (которых в Силиконовой Долине называют менеджерами продукта. Прим. переводчика – похоже в голове у Microsoft есть некоторых хаос с терминологией). Поэтому в Microsoft была создана специальная роль – Менеджер программы. Его цель – партнерство с разработчиками и работа на протяжении всего цикла разработки продукта в качестве адвоката конечных пользователей и клиентов.

Сегодня мы сталкиваемся с массой вызовов – написание кода с использованием передовых технологий, максимальное упрощение работы конечных пользователей с наиболее сложными сценариями, а также создание полностью нового опыта использования ПО, в котором мы стараемся сменить традиционную парадигму меню/панелей управления. С этими вызовами мы продолжаем сталкиваться, разрабатывая веб-сайты (OfficeOnline), серверные продукты, такие как SharePoint, и полностью новые продукты, такие как OneNote.

Я хочу рассказать о том, почему роль менеджера программы в Microsoft является уникальной и обладает неограниченным потенциалом. Именно менеджер программы может собрать команду, сплотить её вокруг новой идеи и вывести продукт на рынок (такой продукт как OneNote, InfoPath). Менеджер программы может решить бизнес-задачу и работать с маркетингом и отделом продаж, чтобы по-настоящему решить большую проблему пользователя с помощью уникального и инновационного ПО (такого как SharePoint Portal Server). Именно менеджер программы может взять такую технологию как XML или графику и превратить в функционал для конечно пользователя, которым воспользуются 400 миллионов человек (Формат Office Open XML или новая графическая функциональность в Office12). Я мог бы нарисовать очень эмоциональную картинку, но давайте лучше поглубже погрузимся в аналитические аспекты этой работы.

Там, где разработчики сфокусированы на коде, архитектуре, производительности и технике, там менеджер программы будет фокусироваться на большой картинке того, “что мы пытаемся сделать”, на деталях пользовательского опыта, наборе функционала и пути использования продукта. На самом деле эта работа значительно повзрослела и практически невозможно полностью задокументировать полный список обязанностей по управлению программой. Один из способов сделать такой документ – перечислить разделы спецификации функционала в Office, которые должен завершить менеджер программы до того, как будет написан код. Этот список включает конкретизацию конкретного сценария использования, оценку международного влияния (будет ли такой же сценарий у клиентов из Китая, Индии или Эстонии), разработку методов интеграции с продуктом для сторонних разработчиков (объектные модели и возможность работы по средствам API), будет ли этот продукт безопасным и будет ли соблюдены права на частную жизнь, с какими другими моделями будет пересекаться ваш новый функционал, будет ли ваш функционал достаточно отзывчивым и производительным и другие. Всё это критические части дизайна любого продукта. Когда у вас есть 400 миллионов потенциальных клиентов, то критически важно обдумать все эти вопросы ДО начала работы.

Отойдем немного в сторону – последнее время активно обсуждается “гибкая разработка” (Agile). Основное преимущество управления программой состоит в том, что мы стали более гибкими (agile) благодаря ему. Это может показаться нелогичным (даже для многих разработчиков в Microsoft, которые сейчас ждут своих менеджеров программы для уточнения спецификаций (ТЗ)). Но мысль, что вы можете начать писать код без четкого представления о деталях и спецификациях это прямой путь к плохой архитектуре. Хороший менеджер программы знает, когда все детали достаточно продуманы для начала разработки и хороший разработчик знает, когда он может начать писать код даже без четкой проработки деталей. Но так же, как и при строительстве дома, – вы не начинаете без планов. Несмотря на то, что программное обеспечение мягкое (“soft”), стоимость повторного моделирования и переделки не отличается от перестройки дома, когда вы решили, что стены находятся не там, где надо или если вы забыли оставить место для HVAC системы (отопление, вентиляция и кондиционирование). Так как при разработке ПО нет материальных затрат, мы порой думаем, что с “переписыванием” нет никаких проблем. На самом деле, это работает только в двух случаях. Первый –  если ваша программа очень мала, тогда вы конечно можете ее переписать. В мире коммерческого программного обеспечения большинство проектов – это работа не одного или двух людей. Если проект – это работа только одного или двух людей (или около 100 тысяч строк кода), тогда экономическая ценность (а также влияние) этого продукта наверняка очень ограничена (по крайней мере конкуренты могут очень быстро вас догнать). Второй случай – это улучшение качества вашего кода, когда вы оглядываетесь назад и переделываете то, что должно быть переделано (это похоже на клонирование существующего проекта, имплементирование n-ый раз). Когда вы создаете инновации, время, потраченное на проектирование и анализ, окупается сторицей. Они дают возможность разработать завершенную программу и получить серьёзную экономическую ценность. Когда у вас есть процесс, который включает проектирование и размышление о перспективах, ваша разработка становится более гибкой. Когда вы отдаете код в руки ваших клиентов – через 2 месяца или через 2 года – то у вас есть время на ответ и на реакцию на изменения, потому что вы не перегружены базовыми проблемами.

Последний пункт стоит подчеркнуть. Существуют школы разработчиков, которые утверждают, что запуск бета версии вашего продукта и последующая “реакция” на обратную связь – это лучший способ сделать продукт. Как правило, это работает для продуктов, у которых уже есть определение, к которому вы стремитесь и вам интересна инкрементальная обратная связь. Если вы создаете новый опыт по работе с электронной почтой, то вы можете выпустить бета-версию и ваши пользователи помогут вам расставить приоритеты нового функционала. Но если вы делаете что-то новое и инновационное или, что более важно, если вам нужно что-то большее, чем инкрементальная обратная связь, то вам понадобятся куда более сложные механизмы, чем просто обратная связь по бета-версии от опытных пользователей. Роль менеджера программы – представлять всех клиентов, а не только тех, которые участвуют в бета-тестировании или тех, у кого есть время на обратную связь или использование молодого продукта. Ключевой навык менеджера программы – сопереживание широкому кругу клиентов. Очень часто, когда вы только начинаете работать вы обнаруживаете, что очень легко переоценить раннюю обратную связь от пользователей. Не поймите меня неправильно, ваши опытные пользователи очень важны, но это только один из видов пользователей. Walt Mossberg отличный адвокат “маленького парня”. Он укажет вам, когда вы слишком фокусируетесь на “технарях”. Большинство людей не являются технарями, в то время как большинство бета-тестеров и ранних последователей продукта – технари. Вы как менеджер программы должны валидировать вашу работу на более широкой аудитории.

Перед разговором о том, что особенного делает менеджер программы, очень важно посмотреть на менеджера программы в контексте взаимоотношений с другими людьми, которые вносят свой вклад в создание продуктов. Менеджер программы служит точкой координации между всеми дисциплинами – поэтому вы можете думать о менеджере программы как о центре интереса (hub). Важная особенность роли менеджера продукта в Microsoft в том, что все люди работают как “виртуальная команда”, разрабатывающая продукт. Менеджеру программы не надо собирать их вместе, а скорее помогать всем быть в курсе и быть на одной волне. Ресурсы, выделенные на проект, включат в себя разработку, тестирование, продуктовое планирование, удобство использования и дизайн. Каждая роль предоставляет уникальный набор навыков для процесса разработки продукта. Очень часто вы понимаете что-то в соседней дисциплине, но очень сложно найти человека, у которого есть навыки и опыт в каждой из них. И я обещаю, что любой значительный продукт действительно требует специальных навыков, чтобы сделать работу мирового уровня и создать устойчивый и по-настоящему инновационный продукт. Наверное, мне стоит написать пост о каждой из этих ролей – возможно, после праздников!

  • Разработка — разработчики пишут код. Они несут ответственность за архитектуру кода, производительность, надежность, безопасность, и попадание функционала в продукт.
  • Тестирование — тестировщики проверяют качество продукта. Но еще более важно, чтобы продукт сразу соответствовал потребностям клиента, которые мы хотим закрыть. Тестировщики проверят все спецификации и используют свою точку зрения и опыт в работе с менеджером программы и разработчиками, чтобы убедиться в том, что продукт не будет хрупким и что мы сможем обеспечить успешную реализацию.
  • Удобство использования — специалисты по удобству использования проверяют дизайн нашего ПО и объединяют в одно целое понимание множества клиентов нашего ПО. Microsoft одним из первых внедрила проверку удобства использования в процесс разработки продукта (однако некоторые могут сказать, как мы вообще выпустили тему Hot Dog Stand  – речь идет о теме оформления в Windows 3.1 – в этот мир, если у нас есть проверка удобства использования). Многие члены команды проверки удобства использования имеют PhD в области HCI (Human-computer interaction) или связанных областях исследования (например, антропология), или являются студентами в области HCI или имеют бекграунд в психологии. Эти члены команды проектируют механизмы проверки и валидации дизайна.
  • Дизайн продукта — команда дизайна работает партнером менеджера продукта, чтобы разработать модель взаимодействия с продуктом, а также над собственным видом продукта и восприятием продукта. Маленькие команды используют понятие дизайн подразумевая “графический дизайн” (которым мы тоже занимаемся). А наши дизайнеры – это эксперты во взаимодействии с компьютером. Многие из них закончили такие программы как Delft или CMU. Когда вы смотрите на новый интерфейс пользователя в Office12, знайте, то, что вы видите, – это результат плотного взаимодействия между менеджерами программы и экспертами дизайна и удобства использования.
  • Продуктовое планирование — наши планировщики – эксперты в понимании рынка и понимании того, что наши клиенты хотят от программного обеспечения. Планировщики занимаются исследованиями и донесением этих исследований до менеджера программы, продуктовой команды и до руководителей, определяя общие цели для релиза. Планировщики назначаются на обширные технологические или бизнес области (взаимодействие, бизнес-аналитика), где они становятся экспертами во всех продуктах и решениях на рынке. Они думают о том, как Microsoft может предложить своим клиентам решения, которые были бы лучше существующих на рынке. Многие планировщики имеют бизнес-бекграунд и опыт работы в маркетинге.

Многие компании “продадут” вам, что один их специалист может отлично делать все эти задачи. Это не имеет отношение к реальности. Мне всегда немного жаль тех людей, которые верят в это. Я слышу это в двух случаях. Первый – это стартапы, которые призывают вас – “приходите к нам после выпуска и научитесь всему этому”. Настоящий опыт стартапа в том, что вы специалист без опыта работы, а это значит, что вы будете делать всю черновую работу, в то время как основатели и инвесторы будут делать всю стратегическую работу – поэтому вы можете обнаружить себя сборщиком на конвейере в автозаводе, вместо того чтобы взаимодействовать с клиентами. Второй случай – когда компания продает решения, конкурирующие с Microsoft. Тогда они говорят, что “в нашей компании мы не специализируемся на мелочах и каждый делает все”. Есть еще одна ситуация. Есть компании, которые заявляют, что создают спецификации или проводят исследования клиентов и стратегическое планирование. Они называют это управлением продуктом. Но на самом деле, эта работа производилась разными специалистами, которые просто составляли отчеты для команды маркетинга. А мы знаем, что это значит. Когда дело доходит до маркетинга, команде понадобятся все силы, чтобы выбраться оттуда и создать реальный бизнес и продажи. Даже когда существует единая группа, которая выполняет работу менеджера продукта, эта работа проводится разными специалистами и не является единой ролью. Таков мой личный опыт и, конечно, ваша конкретная ситуация может быть другой. Я видел эти шаблоны, которые повторяют друг друга многие годы, когда нанимал студентов. Такие шаблоны заставляют студентов возвращаться обратно к Microsoft, после небольшого опыта работы в подобных компаниях.

Давайте немного поговорим о размере команды менеджера программы. Мы используем небольшие команды управления программой в Office (наши команды разработки обычно состоят из 20-30 разработчиков, как я писал ранее). Весь пользовательский интерфейс в Office12 был разработан командой из примерно 12 менеджеров программы – представьте, что 12 менеджеров программы сделали всю работу по определению новой модели взаимодействия для 400млн. пользователей Office. Несмотря на то, что команды небольшие, они созданы таким образом, чтобы у каждого молодого члена команды был ментор и тренер в лице каждого опытного члена команды (вы можете посмотреть это видео, чтобы познакомится с главой команды менеджеров программы по интерфейсу пользователя). Поэтому вы можете оказывать максимальное влияние на проект нового ПО, получая максимум внимания от профессионалов очень высокого уровня. У каждого менеджера программы есть команда разработчиков, и его обязанность в том, чтобы обеспечить их спецификациями и функционалом для разработки. Команда разработки пользовательского интерфейса была меньше 30 человек (то есть около 2 разработчиков на каждого менеджера программы). Ещё одна уникальная особенность роли менеджера программы в Microsoft состоит в том, что у менеджера программы есть выделенные разработчики под его функциональную область. Ваша работа в том, чтобы получить максимум от этих разработчиков – получить лучшие идеи по функционалу и предоставить им лучшие спецификации для работы.

Итак, что же делает менеджер программы? Существует четыре фазы управления программой: изучение (learn), убеждение (convince), спецификация (spec), доработка (refine).  Это практически зеркало жизненного цикла разработки продукта, о котором я писал ранее.  Держите в голове, что это не фиксированный график, а скорее фазы жизненного цикла.  Если мы делаем проект на 12 месяцев, то время жизни разбивается на те же фазы, что и для проекта длительностью 24 или 30 месяцев.

Изучай–> Прототип

Во время фазы изучения менеджеры программы изучают проблемы клиентов, продукты и технологии, которые уже существуют, и пытаются решить эти проблемы.  Необходимо проделать массу работы для глубокого понимания конкурентных продуктов или новых продуктов на рынке. Как вы можете себе представить, клиенты сталкиваются с массой проблем, когда пытаются получить от своих компьютеров то, что им нужно. Очень часто мы тратим дни на рабочем месте клиента, учимся у них и наблюдаем за ними, когда они пытаются сделать свою работу. Отличным примером такой работы является работа, которую мы проделали, чтобы понять, как пользователи управляют документами в организациях. Легко увидеть, что такие организации, как юридические фирмы или фармацевтические компании, сильно зависят от прохождения документов в организации (контракты, одобрение лекарственных препаратов и исследовательские документы). Поэтому системы работы с документами являются критичными для цели компании и очень сложными. Компании по-настоящему хотят автоматизировать как можно больше и сделать такие системы более удобными и надежными. Работа менеджера программы состоит в том, чтобы глубоко понять, как составить модель прохождения документов в организации. Они проводили время в больших фармацевтических компаниях, маленьких стартапах, больших юридических фирмах, маленьких юридических компаниях, агентствах по связям с общественностью, которые выпускают пресс-релизы, или государственных учреждениях, которые занимаются законотворческой деятельностью. Помимо этой работы, менеджер программы и специалисты по планированию разработали концептуальную модель под названием “жизненный цикл документа” (DLC — document lifecycle).  Это помогло нам ограничить способ работы нового функционала по мнению пользователей. Итак, для этой работы менеджер программы должен быть по-настоящему хорош в непосредственной работе с клиентами, в умении научиться у них, выслушать их, быть открытым к различным способам работы и так далее. Это первая работа, к которой вы приступите, получив работу менеджером продукта, если у вас еще нет опыта работы.

В то же время существует серьезные технические проблемы, которые необходимо решить. Нам надо решить проблемы контроля и доступа к информации (результаты тестирования лекарственных препаратов и контракты требуют разграничения доступа, при этом вы должны работать над ними совместно). Менеджеры программы тратят массу времени, работая с командой платформы Windows, которая разработала такие технологии платформы как Сервер Управления Правами (Rights Management Server) или Windows Workflow Foundation (WinWF). Эти технологии имеют решающее значение для создания надежной и расширяемой реализации DLC. Поэтому на фазе изучения менеджер программы должен хорошо разбираться в новых технологиях платформы и в том, как применить существующие технологии. Очень часто на этом этапе некоторые говорят – “будет легче сделать наши собственные”. Они правы в ближайшей перспективе (просто создать свой собственный связанный список или приемник/передатчик событий), но вы упускаете экспертизу, опыт и возможности, которые дает проработанная технология. Например, изучая возможности WinWF, будучи разработчиком этой технологии, мы может получить различные преимущества, такие как интеграцию с Visual Studio. А также получить очень надежный и масштабируемый сервер, не прикладывая вообще никаких усилий. Именно так поступают разработчики по всему миру используя модель процессов в Windows или библиотеки для работы с GDI.

Получив эту информацию, менеджер программы должен синтезировать знание в набор прототипов. Эти прототипы имеют разную точность. Здесь отлично подходит аналогия с архитектурой. Иногда вы делаете рисунок, иногда диаграммы с высокой точностью, а иногда вы строите модель. В разработке ПО мы делаем модель из статических скриншотов. Иногда мы делаем прототипы с помощью таких инструментов как VB.Net, а иногда наш прототип – это набор статических картинок, которые иллюстрирует сценарий. Для нашего нового пользовательского опыта в Office12 мы прошли через серию высокоточных прототипов начиная с PowerPoint (вы будете удивлены глубиной интерактивности, которую можно сделать в PowerPoint). Затем перешли к инструментам, ориентированным на более высококачественный дизайн. К моменту, когда мы готовы завершить фазу изучения, у нас есть полный макет пользовательского интерфейса (который я показывал на моем выступлении в кампусе в этом году).

Результатом работы этой фазы является прототип, который мы будем использовать для создания спецификаций.

Убеди–> План и цели

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

Как я уже говорил, многие компании скажут вам, что вы можете прийти и заниматься своими идеями. На самом деле это плохой план. Это скорее рецепт хаоса. Если на данном уровне у вас есть такая возможность, значит у команды управления так же есть такая возможность. Если каждый будет работать над своей идеей, то вы будете как “лебедь, рак и щука”. Идея начать работать в компании и преследовать свои собственные цели куда ближе к теории, чем к реальности – у всех компаний есть стратегия и бизнес-фреймворк, в который должна вписываться работа. По крайней мере, в конечном счете акционеры хотят возврат свои инвестиций в исследования и разработку.

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

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

Результатом работы на этой фазе является набор целей в области проекта. За этим следует разработка следующего уровня детализации.

Создай спецификацию–> Набор требований и спецификаций

Первая вещь, о которой думают люди – “спецификации для бюрократов”. Это немного сводит меня с ума. Я знаю, что люди всё чаще пытаются использовать новые продукты, не читая инструкции. Но разрабатывать новый продукт без первоначальной записи наших целей – это лунатизм. Основой процесса записи является размышление, а размышление всегда подталкивает вас к открытию новых проблем намного раньше, чем станет слишком затратным что-либо изменить. Все разговоры о гибкой разработке не учитывают спецификации, как самый важный шаг в достижении гибкости. На порядок проще изменить картинку или отредактировать текст в Word, чем продвинуться дальше и сменить архитектуру кода.

В то же время мы не продаем спецификации, мы продаем только наш код. Поэтому пока мы работаем над стратегическими планами, мы не детализируем наши спецификации до полной документации по продукту. Это требует слишком много работы и не имеет экономического обоснования. Поэтому, если позднее вы внесете изменение, то мы задокументируем изменение в истории изменений, но мы не вернемся на начальный этап, чтобы переписать всю спецификацию. Ещё одна забавная вещь в чтении спецификации – настоящее имя функционала, используемого в продукте, никогда не совпадает с именем, используемым при разработке. Ассистент офис во время разработки назывался TFC. Где “C” означает клоун (clown). Я позволю вашему активному воображению выяснить, что могло означать TF.

Таким образом, при написании спецификации менеджер программы, который работал на фазе изучения, должен превратить свои знания в опыт пользователей. На этом этапе должны быть определены набор возможностей программы, интерфейсы пользователей, локализация, возможности для независимых разработчиков (ISV, Independent Software Vendors) и все остальные детали. Спецификация определяет, как разработчик оценит требуемое время на написание кода. Если ваша спецификация опускает массу деталей, то разработчику придется догадываться о деталях. А значит есть хороший шанс, что вы закончите неспособным реализовать все ваши мечты, потому что очень многие вещи потребуют конкретизации в последнюю минуту. Плюс, ваши разработчики будут не очень рады работать с вами. Именно поэтому очень важно провести хорошую работу над спецификацией.

Хороший менеджер программы возьмет весь набор функционала в своей области и разделит его на несколько спецификаций, которые подходят для разработчиков или разобьет функционал на куски, которые можно сделать. В среднем менеджер программы пишет около 8-10 спецификаций для своей области и каждая из них может быть от 30 до 50 страниц в зависимости от того, насколько она визуальная (как много картинок). Некоторые спецификации значительно больше и некоторые менеджеры программ выбирают написание большего числа спецификаций меньшего размера.

Спецификации предназначены не только для разработчиков. Специалисты по удобству использованию, дизайнеры продукта и тестировщики все являются создателями и потребителями спецификации. Хотя результатом работы на этой фазе является спецификация, финальный результат это – проинспектированная спецификация. Если вы знакомы с процессом ревью кода своим профессором и ментором (как стажер), то инспекция спецификации очень похожа на ревью кода. Во время этого процесса тестировщики могут обратить ваше внимание на граничные условия или совместимость с существующими продуктами. Дизайнеры продукта могут вместе с вами работать над улучшением внешнего вида. Специалисты по удобству использования могут исследовать инструментарий продуктов, существующих на рынке и использовать эту информацию, чтобы изменить приоритеты функционала. На самом деле роль данных критична для менеджеров программы Office. Если вы работаете над веб-сайтом, то у вас есть потоки кликов и логи. Office через программу Office Customer Experience Program имеет ту же самую информацию об использовании от миллионов волонтеров (конечно анонимную и приватную). Эта информация очень помогает нам при проектировании нового функционала (читайте блог Дженсона для дополнительной информации). Хотя менеджер программы и владеет спецификацией, она является результатом труда множества сотрудников.

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

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

Доработай–> Продукт

Во время разработки продукта менеджер программы постоянно дорабатывает детали, работая вместе с разработчиками и тестировщиками. Эта работа ведется, чтобы определить, что требует большего прояснения, что работает лучше, чем ожидалось (такое иногда случается), а что работает хуже, чем ожидалось (такое случается гораздо чаще). Менеджер программы вызывается для ответа на вопросы и “разблокирования” разработки.

Как только становится доступным реальный код, менеджер программы стремится попробовать его как можно быстрее и убедиться в том, что он отвечает ожиданием. Когда код развивается, мы постоянно носим его в лаборатории по тестированию удобства использования, чтобы лучше понимать, как работает продукт. Я расскажу вам популярную историю, которая порой происходит на этой фазе разработки. Менеджер программы пытался улучшать функционал во время разработки и запустил некоторые тесты по удобству использования. Функционал работал плохо. Менеджер программы пытался объяснить это разработчикам. Разработчики настаивали на том, что менеджер программы просто взял “тупых пользователей”, потому что функционал был отличный. Поэтому через несколько раундов менеджер программы притащил команду разработки посмотреть, как 10 из 10 пользователей не смогли использовать функционал. Разработчики наконец-то смягчились и функционал был исправлен. Сегодня разработчики могут наблюдать за тестами, используя потоковые трансляции, или спуститься вниз в лабораторию по тестированию удобства использования и лично понаблюдать за тестами. Практически все разработчики, которых я знаю, остро заинтересованы в том, как используют их функционал (и как менеджер программы проектирует этот функционал).

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

На раннем этапе мы встречаемся с небольшой группой (10-20) клиентов, которые проводят целые дни с нами в нашем кампусе и изучают новый продукт. Мы проводим их через все детали и запрашиваем их замечания и предложения. Мы делали это для Office12 прошлым летом. Было очень важно добраться до Beta1 с продуктом, который отражал бы использование в реальном мире. Как менеджер программы вы будете нести ответственность за совместную работу с этими клиентами и получение от них обратной связи.

Другая группа, у которой мы учимся это более большая группа наших MVP (Most Valuable Professional, самые важные профессионалы). Эти ребята – опытные пользователи Office. Наши менеджеры программы вовлечены в саммит MVP в кампусе и работают с MVP в малых группах, чтобы получить от них обратную связь и экспертизу в Office12. MVP знают о Office больше, чем любые другие клиенты на планете – они сокровищница информации.

На данный момент мы находимся на фазе изучения обратной связи от большого набора пользователей Beta1. Мы делаем это через новостные группы и через непосредственное общение.

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

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

Вся обратная связь попадает к разработчикам, где мы расставляем приоритеты и убеждаемся, что создаем лучший продукт. Конечно, эта работа не заканчивается вместе с выходом RTM. Мы постоянно дорабатываем продукт и прислушиваемся к нашим клиентам (даже несмотря на то, что мы не Web 2.0). Как я упоминал ранее, каждый месяц мы делаем более 100 изменений в Office, основываясь на информации от наших клиентов, поэтому продукт всегда улучшается, и мы постоянно учимся!

Навыки менеджера программы

Я рассказал про все фазы управления программой и работу менеджера программы в Office. В роли менеджера программы в Office есть не мало уникальных элементов, которые не копируются другими компаниями, которые так же пытались создать эту роль. Хорошая книга, которая описывает уникальность менеджера программы в Microsoft это книга Michael Cussumano’s “Microsoft Secrets” или его новая книга “The Business of Software”. Если вы рассматриваете роль менеджера программы в Microsoft (или Office), то, с моей точки зрения, есть пара таких особенностей:

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

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

  • Большой интерес к тому, что могут сделать компьютеры — интерес к технологиям и их применению для решения проблем, которые испытывают люди в работе и в обычной жизни.
  • Хорошие коммуникативные навыки — вам придется тратить много времени на письмо, проведение презентаций и убеждение других людей.
  • Уверенная жизненная позиция, но в то же время открытость для новых идей — лучшие менеджеры программ, это не обязательно те, у кого появляются лучшие идеи, а те, кто убедиться в том, что их идея будет реализована.
  • Бескорыстие  — это про уверенность в том, что команда сделала лучшую работу, а не в том, что были реализованы именно ваши идеи.
  • Эмпатия — как менеджер программы вы будете голосом клиентов, поэтому вы должны по-настоящему понимать их точку зрения и контекст.
  • Предприниматель — как менеджеру программы вам понадобится выйти из своего кабинета и убедить других в ваших идеях. Если вы умеете это делать, то вам будет гораздо проще.

Менеджер программы уникален для Microsoft, и, я думаю, будет честным сказать, что эта роль часто копируется, но никогда не дублируется.

–Steven