8 основних причин, чому у зростаючому проекті падає якість

Стаття написана у співавторстві з Мері Ротарь , Co-Founder IAMPM.

Привіт, я Денис Шамантажи, Project/Product Manager. В IT працюю 7 років, спеціалізуюся на менеджменті, оптимізації процесів і масштабуванні проектів. Зі свого досвіду помітив: якщо компанія починає бурхливо рости, то здається, що успіх і розвиток будуть продовжуватися нескінченно. Але тут виникають проблеми, і разом із зростанням з'являється бардак, просідає якість продукту і робочих процесів, як наслідок — втрата клієнта. Як цього не допустити?

Я виділив 8 причин, які заважають підтримувати потрібний рівень якості в зростаючому проекті.

1. Команда перестала розуміти, яку цінність приносить продукту

Поки що в проекті не більше 10 осіб, всі процеси, цілі та завдання максимально прозорі. Люди працюють в одному приміщенні, бізнес-оунер або CEO завжди поруч, і з ними можна обговорити будь-яке питання. Розробка та дизайн бачать цілі бізнесу і, відповідно, можуть запропонувати нове рішення для продукту.

Команда росте, оунер зайнятий глобальними справами і не може приділяти стільки часу процесам, скільки раніше. Тому делегує роботу РМ'у: наприклад, СЕО говорить, яка у нього є мета і завдання, а РМ розбиває завдання на технічні вимоги і віддає розробці.

Далі виникає неприємна ситуація: розробники, дизайнери, ВА, DevOps перестають бачити, яку користь їх робота приносить бізнесу. Команда просто виконує щоденні завдання, втрачаючи ініціативу і мотивацію.

Що робити

Повідомляти команді, яку цінність принесе виконання конкретної задачі. Хоча як продакт я можу сам знайти фічу для опрацювання, краще збирати ідеї від команди. Розробники та дизайнери бачать якісь нові бібліотеки і тенденції у своїй галузі, тому можуть дати хорошу ідею, якщо розуміють мета завдання і користь для продукту.

2. Стратегія націлена тільки на найближчу перспективу

Учасники команди повинні розуміти цілі поточних завдань і паралельно з цим знати вектор розвитку на майбутнє.

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

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

Наведу приклад. Я працював в американському сервісі по продажу нерухомості. У системі були різні фічі: відеодзвінки, автоматичний підбір потенційних покупців, email та sms-розсилки.

Уявімо ідеальну ситуацію: всі ці функції однаково популярні і приносять гроші. Зазвичай команді ставлять завдання так: «Будемо розвивати нову фічу — можливість стрімінг в сервісі» — і все.

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

Робота буде продуктивніше, якщо команда побачить довгострокову мету своїх дій, наприклад:

в освоєнні нового: ринків, аудиторії, перекладі продукту з В2С в В2В.
поліпшення того, що є.

Як приклад довгострокової стратегії оптимізації можна привести Spotify: компанія довго була неприбутковою і все ще знаходиться на межі балансу.

Що вони роблять, щоб збільшити відсоток прибутку? Один з напрямків — компанія викладає більше подкастів, за які не потрібно платити музичним правовласникам. За рахунок такої оптимізації сервіс зменшує витрати і отримує більше прибутку.

Якщо стратегічні моменти не озвучувати, люди втрачають мету, не розуміють, навіщо працюють, чому виникають аврали, а іноді відчувають себе самотньо, особливо на удаленке, тому що не бачать, чим їх завдання важливі для проекту в цілому.

Що робити

Завдання менеджера — самому розуміти перспективи компанії і доносити спочатку до керівництва, а потім до команди, в якому векторі розвивається проект. Приділяйте час для виступаючи з відділами розробки, дизайну, QA, куди зараз рухається компанія, наприклад: «Ми хочемо освоїти нову цільову аудиторію».

3. Бізнес і розробка не синхронізовані

Часто СЕО або оунер — колишні технарі, і на перших порах, поки команда невелика, оунер особисто переводить бізнес-цілі вимоги для розробки.

Коли проект виростає, постановка завдань передається на менеджерів. Не у всіх власників або PM'ів є технічний бекграунд , тому виникають труднощі з формулюванням завдань для команди.

Проблеми з'являються, коли технічні вимоги описані виключно в категоріях бізнесу, наприклад, у вигляді user story: «Я як користувач повинен мати можливість оплатити замовлення з допомогою Google Рау». Тоді у команди занадто багато простору для творчості, тому що описана не завдання, а дуже високорівневий фреймворк. І не завжди рішення, яке придумає розробник, співпаде з потребою замовника.

Важливо не тільки розуміти цілі бізнесу, але і прописати за ним функціональні вимоги до системи. Чим краще бізнес-цілі відповідають завданням для розробників, тим вищою буде якість вихідного продукту.

Якщо на вимоги дивляться тільки з однієї точки зору — бізнесу або розробки, це швидко позначиться на якості продукту.

Що робити

Заздалегідь продумувати, як трансформувати запити бізнесу в технічні завдання. У команді потрібна людина, яка буде переводити бізнес-запити до мети, а потім «мапить» у функціональні вимоги для розробників.

4. Дисбаланс у керівництві

Коли компанія зростає, то люди, які спочатку перебували «у керма», найчастіше переходять в управління. Наприклад, розробник стає тимлидом або СТО. Якщо в керівництві переважають технарі, на проекті неминуче буде перекіс в технічну сторону.

Наведу приклад. На одному з моїх останніх проектів оунер був сильним технарем. Паралельно з ним в керівництві СТО. Коли компанія почала зростати, то один почав продавати, а другий — менеджить розробників.

Відповідно до дизайну ставилися за принципом «чим простіше, тим краще». Перший час не вистачало грошей, щоб взяти відразу трьох: дизайнера, фронтенда і QA, тому вирішили обійтися без дизайнера. Все одно, мовляв, у нас В2В-стартап, дизайн не так важливий, пізніше знайдемо людини.

Зростання продовжилося, і оунер каже: «Ми можемо виділити гроші ще на одного фахівця в команді. Звичайно, дизайнера не вистачає, але QA нам зараз важливіше».

В результаті ми все-таки росли, але, якби у нас дизайнер, могли б зробити більш якісний продукт і отримати більше клієнтів.

Що робити

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

5. Інструменти не годяться для масштабування

Причина начебто очевидна, але про неї часто забувають. У стартапах майже завжди обирають безкоштовні сервіси і додатки, які можна швидко впровадити. Тому починають, наприклад, не з Jira, а з Trello, Asana або Basecamp.

Інструменти і сервіси вибирають за принципом, щоб працювати відразу, «тут і зараз». Для команди з трьох чоловік простіше за 5 хвилин поставити Trello, ніж довго настроювати всі інтеграції в Jira.

З часом людей стає більше, і команда виростає з Trello. Коли важко орієнтуватися в сотнях карток, вести облік, відстежувати зміни, потрібно шукати новий софт. Проблема в тому, що за час використання ви інвестували в попередній інструмент багато інформації: дизайни, опису, вимоги, обговорення. Чим більше аналітики і знань накопичилося в Trello — тим складніше буде зробити перехід.

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

Що робити

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

6. Процеси не підготовлені для зростання

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

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

Якщо заздалегідь не продумати, як масштабувати процеси, з'являється ризик піти в одну із сторін:

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

Одного разу я працював у проекті з оунером, який раніше був CPO в IBM. Там йому не подобалася сильна бюрократія в процесах, тому він пішов і став робити власний продукт. Він хотів створити компанію, в якій буде лампова атмосфера, нетворкінг, люди зможуть швидко обмінюватися інформацією. Загалом, inspired by startup.

Все було добре, поки команда не переросла кількість в 120 чоловік і ситуація, коли оунер по дорозі з Остіна до Фенікса обговорює зі мною, що хотів би зробити, не перестала працювати. Ми схаменулися в той момент, коли якість роботи впало і компанія почала втрачати клієнтів і фінанси. Довелося «на коліні» вибудовувати додаткові процеси, встромляючи в них «милиці». Трансформація проекту зайняла багато часу. В підсумку ми все-таки вийшли на плато продуктивності, але втратили час і клієнтів.

Що робити

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

Вибирайте той варіант масштабування, який підійде вашій компанії:

Будувати в ієрархічному порядку, розділивши працівників за напрямами: команда дизайнерів, розробників, департаменти фронтів і бэкендов.
З'єднувати в окремі команди (інтеграції, продажу) з РМ'ом у кожній з них або створювати крос-функціональні команди, відповідальні за один модуль. Тоді для кожного модуля буде свій менеджер і набір завдань.

Наприклад, Spotify спочатку будували процеси ієрархічно, а потім перейшли на максимальне дроблення з маленьким командам.

Щоб при масштабуванні не втрачалася якість, відразу простраивайте комунікацію між командами. Заздалегідь виробляйте загальні правила, code style, мову дизайну та програмування. Коли є загальне розуміння, люди можуть працювати автономно і синхронно в маленьких командах без постійного моніторингу, погодження та конфліктів.

7. Розпливчасті культурні цінності компанії

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

Якщо загальноприйнятих культурних правил немає або цінності нечіткі, то з ростом компанії обов'язково почнуться конфлікти.

У моєму минулому проекті вся команда працювала віддалено, тому що учасники жили в 12 часових зонах. Найзахідніший спеціаліст жив в Сіетлі, а східний — в Тайбеї. У нас не було ніякої можливості синхронізуватися всім разом через колосальної різниці в часі, і ми рідко зідзвонювалися однією командою.

Проект швидко зростав, і у нас не було часу будувати командну культуру. Потім в команду прийшли сильні бекенд-розробники з африканських країн: Гани, Гвінеї, Кот-Д'івуару.

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

У підсумку це формування правил і цінностей зайняло дуже багато часу і нервів.

Що робити

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

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

8. Неправильний рекрутинг

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

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

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

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

Що робити

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

Висновки

Швидкий зліт проекту зовсім не гарантує хорошу «траєкторію польоту», і розслаблятися точно не потрібно.
Проблеми накопичуються швидко, тому чим довше ігнорувати тривожні сигнали, тим більше ви ризикуєте якістю кінцевого продукту.
У великому проекті робота кипить, але якщо перестати доносити до команди стратегічні цілі, то люди втрачають ініціативу і мотивацію, і якість знижується.
Навіть якщо процеси або інструменти добре працювали на першому етапі, вони не обов'язково підійдуть для стадії зростання.
Якщо менеджер постійно відчуває тільки збиток сил і напруга, це позначиться на якості продукту і процесів. Тому на будь-якій стадії розвитку проекту стежте, чи отримуєте ви задоволення від того, чим займаєтеся.

Опубліковано: 11/06/20 @ 10:00
Розділ Різне

SEO Блог