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 Рay». Тогда у команды слишком много простора для творчества, потому что описана не задача, а очень высокоуровневый фреймворк. И не всегда решение, которое придумает разработчик, совпадет с потребностью заказчика.

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

Если на требования смотрят только с одной точки зрения — бизнеса или разработки, это быстро отразится на качестве продукта.

Что делать

Заранее продумывать, как трансформировать запросы бизнеса в технические задания. В команде нужен человек, который будет переводить бизнес-запросы в цели, а затем «мапить» в функциональные требования для разработчиков.

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. На финальном собеседовании мне сказали, что с хард и софт скиллами все хорошо, но с точки зрения культурного соответствия я отличаюсь от команды, поэтому не подхожу.

Что делать

Кандидат может быть хорош как специалист, просто его качества не соответствуют культуре и атмосфере конкретной компании. Поэтому важно выбирать людей не только по скиллам и опыту, но и по личным качествам, учитывая культурную составляющую.

Выводы

1. Быстрый взлет проекта совсем не гарантирует хорошую «траекторию полета», и расслабляться точно не нужно.
2. Проблемы накапливаются быстро, поэтому чем дольше игнорировать тревожные сигналы, тем больше вы рискуете качеством конечного продукта.
3. В большом проекте работа кипит, но если перестать доносить до команды стратегические цели, то люди теряют инициативу и мотивацию, и качество снижается.
4. Даже если процессы или инструменты хорошо работали на первом этапе, они не обязательно подойдут для стадии роста.
5. Если менеджер постоянно чувствует только убыток сил и напряжение, это скажется на качестве продукта и процессов. Поэтому на любой стадии развития проекта следите, получаете ли вы удовольствие от того, чем занимаетесь.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU