Автор: Ігор Прокопенко, СЕО Fulcrum

1 квітня 2004 року журналісти зі США отримали пресреліз від компанії Google про революційну на той час безплатну вебпошту Gmail. Розробники обіцяли обсяг пам’яті в 1 Гб (а це в 500 разів більше, ніж пропонували тогочасні аналоги) та низку інших проривних сервісів. Знаючи любов Google до першоквітневих жартів, журналісти телефонували в компанію, щоб підтвердити інформацію. Новина виявилася не жартом. Пошта продовжила роботу 2 квітня і продовжує працювати досі. А за 14 років кількість користувачів Gmail перевалила за 1 млрд. 

Успіх електронної пошти пояснюють проєктом “20% часу”, за якого інженери могли витрачати 20% свого робочого часу на заняття, не пов’язані з основною роботою, але які б допомогли їм у розвитку. Це нововведення Ларрі Пейджа та Сергія Бріна сприяло створенню таких сервісів як Google Transit, Google News, Orkut та AdSense. 

Річ у тім, що свобода дій розробників у різних компаніях - від аутсорсингових, до продуктових чи окремих стартапів - стимулює їх до інновацій, підвищує мотивацію, а відтак - зростає ріст будь-якого проєкту на успіх. Натомість незадоволені працівники, навпаки, завдають компанії збитки - тільки в США бізнес втрачає через це $550 млрд щороку. Тоді як мотивований персонал на 12% продуктивніший. Аби від роботи вигравав і бізнес, і девелопери отримували задоволення, важливе емоційне включення працівників у проєкт. Як це реалізувати в ІТ-секторі - нижче в матеріалі.

Челенджі 

Що болить розробникам? Їхні нерозкриті таланти. Зазвичай розробники з досвідом мають власні амбіції, своє бачення й розуміння, в який спосіб можна реалізувати певне завдання.

Тому в нашій компанії попит на цікаві проєкти ми задовольняємо челенджами, шукаємо перспективні ідеї, втілювати які нам подобається самим, та намагаємося максимально креативити технічно (бо якщо проєкт надто легкий для розробника - він нецікавий). Також намагаємося підбирати такі проєкти, якими б “горіли” розробники. Приміром, у проєкті з геймінгу є кілька девелоперів, яких якраз цікавить ця сфера.

Більшість наших клієнтів - це стартапи з різних сфер. Тому багато проєктів стають викликом. Наприклад, продукт SubbXi був одним з найскладніших рішень, які ми розробляли. Команда після нього справді виросла професійно. Ідея була в тому, щоб створити онлайн-редактор для відео, в якому користувачі могли б у режимі реального часу робити асинхронне субтитрування на різних мовах, лишати коментарі тощо. Також мала бути доступною можливість різних ролей: перекладача, сабскриптора і т.д. Це був челендж, бо в ньому був складний back-end, але це той проєкт, який хочеться постійно ставити в приклад.

Включення якнайраніше

Залучати розробника у середині проєкту – не дуже хороша практика. Як і “перекидати” від одного клієнта чи розробки до інших. І це зрозуміло: потрібен час і ресурси, щоб ознайомитися із завданням та зрозуміти логіку, чому саме такий алгоритм, код і як усе працює. До того ж дороблювати чужий код - це як дописувати за іншим письменником книжку.

Тому наші розробники долучаються до продукту ще на етапі discovery фази. Занурюються в тему, ринок, продукт, користувацький досвід. Тобто вони не просто кодять по брифу, а самі його й формують. І головне знають бізнес-цілі проєкту, тобто мислять категоріями, як зробити так щоб продуктом користувалися і як встигнути до релізу, 

Хороша комунікація 

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

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

Для нас показовим у цьому плані проєктом стало створення Buff - програми лояльності для геймерів. По суті, це маркетплейс, де користувачі можуть купувати й продавати віртуальні речі, накопичувати “валюту”, вести “перемовини” з іншими гравцями тощо. У ньому вже зареєстровано понад 200 тисяч користувачів з усього світу.

Що тут драйвило: девелопери мали прямий контакт з клієнтом, а той їх чув. Ми зі свого боку планували й втілювали деякі додаткові елементи функціоналу. Приміром, запропонували додати одну гру і це спрацювало - привабило більше користувачів. А одну схему купівлі-продажу віртуальних товарів можна було здешевити та зробити ефективнішою - ми це презентували, пояснили замовнику і втілили врешті в життя. Люди, в яких вірять і яким дають карт-бланш, працюють з більшою віддачею, щоб виправдати довіру. 

Свобода

2010 року одним з бестселерів The New Times стала книга Деніела Пінка про мотивацію. Автор - журналіст, ведучий і спічрайтер одного з віце-президентів США - називає секретом продуктивності й задоволення від роботи поєднання майстерності, високої цілі та автономності або свободи в діях. Останнє означає контроль над своїм життям і кар’єрою. Якщо людина може сама обирати завдання, проєкти або час їхнього виконання, це вже додає творчості в роботу. 

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

Також не практикуємо так званого “чайка менеджменту”, коли СЕО, СТО чи інший керівник приходить, усе критикує і йде. По-перше, це знецінює зусилля девелопера. По-друге, це приносить хаос у проєкт. Команда працювала за певним планом, були дедлайни, дашборд, обов’язки. Тут раптом хтось ззовні вирішує, що має бути інакше і не просто вирішує, а закидає сумнів і зникає. Ми такого намагаємося уникати. Даємо свободу, але за нею й відповідальність. І це додає “вогню” в робочі процеси.

Зворотний зв’язок

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

Бачать, як спрацьовують їхні ідеї на практиці або ж, навпаки, що ігнорування їхніх порад виливається в неуспіх бізнесу. Як це у нас сталося з однією платформою, яка мала б поєднувати інфлюенсерів, блогерів, товари, які вони продають, та покупців. Однак, стартап не “вигорів”, хоча ще на етапі розробки ми радили продумати інші варіанти монетизації та функціональності. Замовник потім визнав, що ситуація могла б бути іншою, якби вони взяли до уваги пропозиції. 

2013-го в ЗМІ з’явилася низка публікацій: мовляв, система Google “20% часу” не працює. За 10 років від часу її впровадження команд і людей стало багато, тож ефективність підходу почала прямо порційно спадати. Однак, у компанії офіційно про скасування не заявляли. Мало того, низка інших техногігантів Apple, LinkedIn, 3M, Atlassian власноруч сформували на свій лад підхід до системи й досі отримують не лише інновації від працівників, але й прибутки від реальних втілених проєктів. 

Так, 2015-го австралійська Atlassian на ІРО продала всі свої акції, заробивши $531,3 млн. Таким успіхом компанія зобов’язана флагманським продуктам, Jira та Confluence, якими користується близько 10 млн користувачів у 190 країнах світу. Сервіси були розроблені якраз у “вільні від роботи” години. Адже економісти та Нобелівські лавреати вже неодноразово доводили: правильна мотивація, свобода, цінність самого продукту та емоційне включення в проєкт здатні гарантувати значно кращий результат, ніж високі прибутки. Парадокс? Можливо. Але якщо це приносить результат, то чому не отримувати від цього задоволення?