Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

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. Если менеджер постоянно чувствует только убыток сил и напряжение, это скажется на качестве продукта и процессов. Поэтому на любой стадии развития проекта следите, получаете ли вы удовольствие от того, чем занимаетесь.
LinkedIn

Похожие статьи

9 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Про "

Расплывчатые культурные ценности

" написано довольно-таки расплывчато. Избегать обсуждения конфликтных тем — это все-таки культурные правила, а не ценности. И кто будет эти культурные ценности продвигать в коллективе, если там все на удаленке?

Классная статья! Спасибо!

Очень «мягкая» статья. Обычно проблема в другом, на старте бизнеса никто не знает выгорит ли он и все процессы максимально удешевлены. Чаще всего, в успешном бизнесе, команда которая делала продукт и команда которая распивает его дальше не одно и тоже. Это не значит что их увольняют, но часто они не имеют достаточной квалификации в дальнейшем масштабировании продукта. Но имеют хорошое понимание продукта. Если эти люди имеют процент, скорее всего предприниматель не опытный, опытный предприниматель не обещает обычным работникам процент, он платит им за текущую работу, это выгоднее. И как сказали ниже, бизнес процессы маленьких компаний, отличаются от бизнес процессов больших компаний.

Главные причины провала растущих проектов — технический долг, отсутствие фидбека на ранних этапах разработки и то что описано в пункте 3 (бизнес и разработка не синхронизированы).

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

Годно.
Соавторам — успехов!

Задача менеджера — самому понимать перспективы компании и доносить сначала до руководства

 — все же руководству стоит изначально понимать перспективы и правильно коммуницировать их в идеале по структуре, где не более 2-3 уровней подчинения

спасибо, очень полезная и толковая статья!

Подписаться на комментарии