Елена Корякина, директор департамента облачных технологий компании Parallels: «Коммуникабельность — неотъемлемая часть современного IT-специалиста как командного игрока»
Выдержки из выступления на форуме RIW-2016 Елены Корякиной, директора департамента облачных технологий компании Parallels Откуда берутся идеи для новых продуктов? Какие они проходят стадии развития? Как формируется проектная команда? И почему IT-специалист должен быть коммуникабельным?
Выработку идей стимулирует креативная среда Думаю, надо начать с того, что идеи порождает личность. А личность развивается в процессе общения. Поэтому для нашей компании важно построить профессиональную команду, обеспечить эффективное взаимодействие между людьми и поддерживать креативную среду, чтобы идеи не умирали в головах наших сотрудников, а превращались в реальные продукты. На этом пути мы придерживаемся пяти базовых принципов.
Первый принцип: быть ближе к народу. Приоритеты, которыми руководствуется наша компания для разработки определенных направлений, определяют бизнес-подразделения, руководство. Но техническую экспертизу никто не отменял. Поэтому бизнес обращается к нам на самых ранних этапах создания нового продукта. Для команды это крайне важно, потому что она понимает, что может влиять на принятие конечного решения.
Второй принцип: быстрая реакция на новости индустрии. Нужно помнить о том, что время — это успех. И всегда держать руку на пульсе.
Третий принцип: вся команда, которая работает над проектом, должна знать своего пользователя. Она должна понимать, что пользователь хочет видеть в следующих версиях, что ему не нравится на текущий момент. Сейчас у нас большая команда, поэтому программ-менеджеры и аналитики тщательно анализируют результаты 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-компания, мы ставим во главу угла личные качества и коммуникабельность и считаем, что это неотъемлемая часть современного IT-специалиста как командного игрока. Мы всячески стараемся развивать эти навыки в наших сотрудниках.
Источник: Russiajob.net - подработка в свободное время для пенсионеров
У нас есть научные учебные программы, есть кафедра на физтехе, было подписано соглашение с ВШЭ и МГТУ имени Баумана. И это прекрасный мотиватор для наших собственных сотрудников, очередное признание — реальная возможность для них повлиять на отрасль в целом. Сложившийся профессионал знает, как делать то, что он делает, хорошо. Когда такой эксперт готов выйти из локальной команды и делиться своим опытом, особенно полезно его поддержать в этом. Таким образом, профессионалы обкатывают свои личностные и коммуникативные навыки. А студенты получают прекрасных экспертов, с которыми они могут отрабатывать кейсы, применимые на практике, а не только в теории. На выходе мы имеем новых специалистов, которые приходят к нам в компанию, генерят новые идеи и создают интересные продукты для пользователей.