На сайте DOU.UA вышла статья Дениса Шаматажи (Project manager в REDMADROBOT) в соавторстве с Мэри Ротарь (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. На финальном собеседовании мне сказали, что с хард и софт скиллами все хорошо, но с точки зрения культурного соответствия я отличаюсь от команды, поэтому не подхожу.
Что делать
Кандидат может быть хорош как специалист, просто его качества не соответствуют культуре и атмосфере конкретной компании. Поэтому важно выбирать людей не только по скиллам и опыту, но и по личным качествам, учитывая культурную составляющую.
Выводы
- Быстрый взлет проекта совсем не гарантирует хорошую «траекторию полета», и расслабляться точно не нужно.
- Проблемы накапливаются быстро, поэтому чем дольше игнорировать тревожные сигналы, тем больше вы рискуете качеством конечного продукта.
- В большом проекте работа кипит, но если перестать доносить до команды стратегические цели, то люди теряют инициативу и мотивацию, и качество снижается.
- Даже если процессы или инструменты хорошо работали на первом этапе, они не обязательно подойдут для стадии роста.
- Если менеджер постоянно чувствует только убыток сил и напряжение, это скажется на качестве продукта и процессов. Поэтому на любой стадии развития проекта следите, получаете ли вы удовольствие от того, чем занимаетесь.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]