Откуда берутся идеи для новых продуктов? Эволюция и стадии развития идеи. Каковы принципы формирования проектной команды? Инструменты стимулирования новых идей. Обо всем этом мы рассказывали на минувшем форуме RIW/16. В этой статье вы найдете выдержки из выступления Елены Корякиной, директора департамента облачных технологий компании Parallels. Кстати, презентация доступна по ссылке.
— Думаю, надо начать с того, что идеи порождает личность. А личность развивается в процессе общения. Поэтому для нашей компании важно построить профессиональную команду, обеспечить эффективное взаимодействие между людьми и поддерживать креативную среду, чтобы идеи не умирали в головах наших сотрудников, а превращались в реальные продукты.
Наши принципы
Первый принцип — быть ближе к народу. Приоритеты, которыми руководствуется наша компания для разработки перспективных направлений, определяют бизнес-подразделения, руководство. Но техническую экспертизу никто не отменял. И поэтому бизнес обращается к нам на самых ранних этапах создания нового продукта. Для команды это крайне важно, потому что она понимает, что может влиять на принятие конечного решения.
Второй принцип — быстрая реакция на новости индустрии. Нужно все время помнить о том, что время — это успех. И всегда держать руку на пульсе.
Третий принцип — вся команда, которая работает над проектом, должна знать своего пользователя. Она должна понимать, что пользователь хочет видеть в следующих версиях, что ему не нравится на текущий момент. Сейчас у нас большая команда, поэтому программ-менеджеры и аналитики тщательно анализируют результаты Customer Experience Program (Программа улучшения качества продуктов Parallels), обращения в службу поддержки, обратную связь на форумах и в социальных сетях и делятся собранной информацией с остальными участниками разработки. А когда разрабатывали Parallels Desktop for Mac, мы все – руководители команд, программисты, тестировщики, представители службы поддержки — сидели на форумах, читали отзывы, отвечали, в онлайн-режиме устраивали технические сессии с нашими пользователями. Вся команда видела портрет своего пользователя и старалась быстро реагировать на его пожелания. Такой подход дает понимание, куда развиваться дальше, и позволяет направлять поток новых идей в нужное русло.
Четвертый принцип — основополагающий — «Все на сбор идей». У нас абсолютно вся команда участвует в генерации идей для очередного продукта. Перед началом нового проекта его руководитель и программ-менеджер традиционно проводят опросы наших сотрудников на предмет идей в данном направлении или вообще любых идей, которые они могли бы предложить. Опрос проводится по e-mail, на специальных встречах с мозговыми штурмами, или идея рождается в простой беседе, один на один, за чашечкой кофе.
Пятый важный принцип — «Внимание, новый продукт». У нас в компании не принято замалчивать направления, в которых мы работаем. Поэтому практически сразу, как только появляется новый продукт, новое направление, руководитель проекта рассылает соответствующую информацию, и любой сотрудник может присоединиться к команде разработки или просто поделиться своими идеями-предложениями.
Есть идея, есть...
Для того, чтобы стимулировать генерацию идей у сотрудников, у нас есть материальные и нематериальные способы. Мы стараемся делать ставку на нематериальные, потому что команда более стабильна, когда она работает не только за вознаграждение, а за такие вещи, как признание.
Начнем с материальной. Идея — это самая ценная вещь, которая есть в компании, поэтому компания всячески содействует оформлению патента. Сотрудник получает финансовое вознаграждение и возможность указать свой список патентов, например, в Linkedin, это повышает его уровень как профессионала.
Второе — это аварды. Есть глобал-авард, который выдается раз в квартал за заслуги перед компанией в целом. На него может номинироваться человек из любого подразделения. Победителю выдается красивая стеклянная табличка и к ней добавляется вознаграждение. Но, как показывает практика, в творческих коллективах для людей важно признание. Поэтому мы так и называем их – аварды-признания. В течение года люди номинируются на авард за особый вклад за развитие компании. У разработчиков это может быть что угодно — быстро разработанная фича, интересный новый процесс, новая идея. У HR-менеджера — количество привлеченных талантливых сотрудников в команду. И на новогоднем вечере в торжественной обстановке все это вручается. Почему это важно? Люди видят, что они работают в профессиональной команде, что рядом находятся интересные люди, которые делают классные продукты, и им хочется продолжать в этом участвовать.
Есть достаточно специфичные вещи. Например, все мы знаем, что предметы с символикой компании — футболки и прочее — тема заезженная. Но, как ни странно, если эти вещи делать эксклюзивно, чтобы люди понимали, что наличие той или иной вещи — престижно и интересно, это работает. Был такой случай, когда людям, которые сгенерили много идей и патентов, мы выдавали курточки Lord of Patent. И разработчики реально приходили и спрашивали — как им получить такую куртку. Мы отвечали — сгенери 10 идей, и у тебя тоже будет такая замечательная курточка. Как ни странно, это работает.
Если идея попала в топ-10 маркетинговых идей, и она заслужила интерес пользователя, человек может получить новый айфон. Есть еще такая практика, милая традиция, когда руководитель проекта сам делает бутерброды с красной икрой и угощает своих сотрудников после очередного релиза.
Все это направлено на то, чтобы люди чувствовали, что результаты их работы аккумулируются, и есть смысл напрягать и вкладываться в отрасль.
От идеи до проекта
Как идея эволюционирует в проект? Она может развиваться по нескольким направлениям. Первое — это идея, которая, скажем так, сейчас находится не в тренде развития компании. Мы на нее оформляем патент и кладем в копилку. Это такой «стратегический жирок» компании. Следующая возможная траектория для идеи – новая фича в существующем продукте.
И третий вариант — это когда возникает идея, из которой может получиться какой-то интересный проект. Ее надо проверить. Вообще, параллельно с разработкой базовой линейки продуктов мы имеем до двух пилотных проектов. Они организуются с минимумом ресурсов — один-два селф-менеджмент инженера плюс программ-менеджер. Обычно программ-менеджер представляет интересы конечного потребителя. В этот момент для него самое важное — угадать портрет того пользователя, которому будет интересен этот продукт. Несколько раз у нас «выстреливало» решение, когда идея сперва становилась фичей продукта, который уже сложился, имеет свою базу клиентов, и мы понимали, что она превращается во что-то серьезное, и может переродиться в новый интересный продукт. Например, в рамках работы над очередной версией Parallels Desktop for Mac был период, когда было модно говорить об облаках, и мы подумали — почему бы наши локальные компьютеры не воспринимать как облако? Мы можем запускать приложения и для Windows и для Mac одновременно, а человеку было бы удобно работать с этими приложениями, документами и файлами удаленно. Так появился Parallels Access, в дальнейшем продолжив свое развитие как самостоятельный продукт – удобный доступ к настольному компьютеру и работа с приложениями на любых устройствах. Мы стали активно наращивать и применять все наши наработки в области юзер экспириенса (удобство пользования), и поняли, что можем сделать что-то большее. Так мы придумали лупу для того, чтобы было удобнее работать с документами на маленьких экранах мобильных устройств. Похожая история у нашего недавно вышедшего продукта Parallels Toolbox. Сейчас этими продуктами пользуются сотни тысяч пользователей.
Простая «выстреливающая» идея зачастую лежит на поверхности, она может быть частью функциональности уже существующих продуктов, и ее важно улавливать и не бояться, развивая и преобразовывая, цеплять новым звеном, к тому что есть сейчас, это еще и хорошая возможность получить обратную связь от пользователей до выхода самостоятельного продукта.
Один в полне не воин
Поговорим теперь о проектной команде. Существуют общие принципы эволюции проектной команды от стартапа до сложившегося коллектива, у которого есть продукт, находящийся на стадии поддержки и имеющий определенного пользователя. Сначала программисты пишут код, реализующий некую функциональность. Затем появляется понимание важности проверки качества наработанного, в команду вовлекаются тестировщики. Дальше нужно отработать сценарии потенциальных пользователей, отобрать и описать новые идеи-фичи, которые им могут быть интересны и полезны. Появляются программ-менеджеры, которые начинают писать эти сценарии. То есть минимальная команда, которая может эффективно начать работу над проектом — это всего три человека — программист, тестировщик и программ-менеджер.
Пока всех мало и участники проекта работают тесно рука об руку, разделение ролей не сильно чувствуется, они сконцентированы на конечном результате, продукте в целом. Но как только мы начинаем добавлять людей на проект — их может быть до 100 человек, то сталкиваемся с такой ситуацией, когда есть команда профессионалов, в которой каждый пришивает свою пуговицу к пиджаку, а на сам пиджак не обращает внимания. Чтобы этого не происходило, мы стараемся из каждой области, из каждого подразделения привлекать человека в команду с самого начала, с ранней стадии создания продукта и до как минимум момента его релиза, передачи конечному пользователю.
Берется продукт, разбивается на направления по функциональности, идеям-фичам. Для каждой идеи-фичи создается рабочая группа. С самого начала в каждой группе присутствует по одному человеку от каждого подразделения — дизайнер, разработчик, тестировщик, программ-менеджер, представитель поддержки. Они проводят несколько сессий. И в момент, когда из идеи рождается функциональность, они уже четко знают, что им ожидать на каждой стадии проекта. Это позволяет учесть все мнения на ранних этапах обсуждений, избежать массовых переделок в дальнейшем, сделать результат предсказуемым на каждом шаге проекта. Для тестировщика не становится неожиданностью, когда программисты закончили свою работу, у них есть возможность заранее спланировать и подготовить тест планы.
Вторая вещь касается разработчика. Дело в том, что разработчики часто бывают людьми закрытыми, они делают какую-то свою часть кода, а куда она дальше пойдет, с чем будет интегрирована и как попадет на продакшн (станет доступна пользователям)- им не так интересно. Чтобы поддерживать культуру комплексного подхода и стимулировать их собственные коммуникативные навыки, мы делаем следующее — назначаем разработчика «фича-владельцем», с его согласия, конечно. И у него появляется возможность проявить себя — кстати, зачастую достаточно успешно — в роли координатора. Перед ним ставится задача — закончить работу над фичей полностью. Скоординировать свою работу с работой своих коллег, передать собранный вариант в тестирование, проверить соответствие тому, что было заявлено в исходном описании, и довести до продакшна, до конечного пользователя. Это важный опыт, каждый программист -владелец фичи держит фокус команды на продукте в целом, происходит обмен ролями, у команды отрабатывается навык более эффективного взаимодействовия друг с другом. В проектах часто возникают проблемы со сроками запуска продукта. Разработчики — люди творческие, они хотят что-то делать, желательно, без сроков. Когда человек попробует себя в качестве такого руководителя мини-проекта, он начинает задумываться о том, почему есть такое понятие, как срок сдачи проекта, и сам «побывав в шкуре» руководителя более серьезно впоследствии относится к процессам достижения этих сроков. Для команды в целом это еще одна хорошая возможность прочувствовать общую причастность и ответственность за продукт перед конечным пользователем.
Еще один важный тезис – программистам важно переключаться. И мы используем этот немаловажный фактор в построении команд в Parallels. Будь то новая проектная команда или открытие нового офиса мы сперва формируем костяк на базе наших собственных специалистов, готовых конвертировать свои знания в другую область. А уже потом постепенно мы добавляем в сложившуюся команду экспертов в данной области извне.
Таким образом, мы легко переносим культуру работы из проекта в проект и тем самым экономим время на выстраивании процессов, все участники знают, что и как делать, сразу приступают к работе. Команда — эффективная, слаженная, и двигается вперед.
Что касается возможности удаленной работы. Подразделение разработки старается сохранять концепцию работы из офиса. Для этого мы прилагаем всевозможные усилия, чтобы работа из офиса была эффективной, приятной и интересной. Свой офис мы сравниваем со съемочной площадкой культового фильма, где наши программисты среди коллег могут максимально проявить свой творческий потенциал, подобно как актеры проявляют себя, снимаясь в захватывающих масштабных сценах. Начинающие могут пообщаться и перенять опыт тех, кто уже сложился в этой профессии.
Я Божена! (с)
Еще такой вопрос — кто предпочтительнее — «звезда» или командный игрок? «Звезда» жизненно необходима в команде — на пилотных, исследовательских проектах, на мозговых штурмах. Но по мере того, как проект разрастается, стоит отдавать предпочтение командному игроку. Мы не говорим о тех случаях, в которых нам повезло — когда человек очень коммуникабельный, открыт ко всему новому. Мы говорим о капризных «звездах». Или вообще о любых людях, которые имеют достаточно сложный набор личных качеств. Они зачастую не хотят заниматься какими-то конкретными типами задач. Или, если вы наращиваете команду, и в ней появляются новые специалисты, разные мнения, они как эксперты могут подавлять идеи коллег.
Очень сложно «звезды» относятся и к смене процессов. Понятно, что команда на стадии стартапа и команда на стадии готового продукта — это разные истории, отличается и методология ведения проекта. И когда вы пытаетесь поменять эти процессы, «звезда» может «захворать» и начать развивать негативный фон среди других сотрудников.
Если со «звездой» не получается договориться, то самое эффективное — переключить ее на какой-то индивидуальный проект, который интересен на данный момент компании. Но если такого проекта нет, и вы перепробовали все, то, как ни печально расставаться с профессионалом, выведение «звезды» из коллектива приводит к оздоровлению всей команды.
Мы заведомо стараемся набирать людей, которые имеют большой потенциал, и готовы развивать свой профессионализм в данной области. Профессионализм — очень важный момент. Но, несмотря на то что мы IT-компания, мы ставим во главу угла личные качества и коммуникабельность и считаем, что это неотъемлемая часть современного командного игрока. Мы всячески стараемся развивать эти навыки в наших сотрудниках.
У нас есть научные учебные программы, есть кафедра на физтехе, было подписано соглашение с ВШЭ и МГТУ имени Баумана. И это прекрасный мотиватор для наших собственных сотрудников, очередное признание — реальная возможность для них повлиять на отрасль в целом. Сложившийся профессионал знает, как делать то, что он делает, хорошо. И когда такой эксперт готов выйти из локальной команды и делиться своим опытом, особенно полезно его поддержать в этом, «расшевелить» и подключить к учебным программам. Таким образом, профессионалы обкатывают свои личностные и коммуникативные навыки, становятся более сэлф-менеджмент людьми. А студенты получают прекрасных экспертов, с которыми они могут отрабатывать кейсы, применимые на практике, а не только в теории. На выходе мы имеем новых специалистов, которые приходят к нам в компанию, генерят новые идеи и создают новые интересные продукты для наших пользователей.
Автор: Parallels
