Навіть в IT-компанії особисті якості комунікабельність — невід'ємна частина командного гравця



Звідки беруться ідеї для нових продуктів? Еволюція та стадії розвитку ідеї. Які принципи формування проектної команди? Інструменти стимулювання нових ідей. Про все це ми розповідали на минулому форумі RIW/16. У цій статті ви знайдете витяги з виступу Олени Корякіною, директора департаменту хмарних технологій компанії Parallels. До речі, презентація доступна посилання.

image
— Думаю, треба почати з того, що ідеї породжує особистість. А особистість розвивається в процесі спілкування. Тому для нашої компанії важливо побудувати професійну команду, забезпечити ефективну взаємодію між людьми та підтримувати креативну середу, щоб ідеї не вмирали в головах наших співробітників, а перетворювались в реальні продукти.

Наші принципи
Перший принцип — бути ближче до народу. Пріоритети, якими керується наша компанія для розробки перспективних напрямів, які визначають бізнес-підрозділи, керівництво. Але технічну експертизу ніхто не відміняв. І тому бізнес звертається до нас на самих ранніх етапах створення нового продукту. Для команди це дуже важливо, тому що вона розуміє, що може впливати на прийняття кінцевого рішення.

Другий принцип — швидка реакція на новини індустрії. Треба весь час пам'ятати про те, що час — це успіх. І завжди тримати руку на пульсі.

Третій принцип — вся команда, яка працює над проектом, повинна знати свого користувача. Вона повинна розуміти, що користувач хоче бачити в наступних версіях, що йому не подобається на поточний момент. Зараз у нас велика команда, тому програм-менеджери і аналітики ретельно аналізують результати 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-компанія, ми ставимо в основу особисті якості комунікабельність і вважаємо, що це невід'ємна частина сучасного командного гравця. Ми всіляко намагаємося розвивати ці навички у наших співробітників.



У нас є наукові навчальні програми, є кафедра на физтехе, було підписано угоду з ВШЕ і МГТУ імені Баумана. І це прекрасний мотиватор для наших власних співробітників, чергове визнання — реальна можливість для них вплинути на галузь в цілому. Склався професіонал знає, як робити те, що він робить, добре. І коли такий експерт готовий вийти з локальної команди і ділитися своїм досвідом, особливо корисно його підтримати в цьому, «розворушити» і підключити до навчальних програм. Таким чином, професіонали відпрацьовують свої особистісні та комунікативні навички, стають більш селф-менеджмент людьми. А студенти отримують прекрасних експертів, з якими вони можуть відпрацьовувати кейси, застосовні на практиці, а не тільки в теорії. На виході ми маємо нових фахівців, які приходять до нас в компанію, генерує нові ідеї і створюють нові цікаві продукти для наших користувачів.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.