Умер ли рынок разработки сайтов?

Tilda, Wix, inSales, Битрикс24 и куча прочих конструкторов — все они позволяют без особых заморочек создать сайт или интернет-магазин для мелкого и даже среднего бизнеса. Эти инструменты не стоят на месте, и скоро вы сможете на их базе собрать внушительный инструмент без помощи веб-студий. Да, это действительно приведет к тому, что мелкие студии будут хвататься за любую возможность, демпинговать, а в итоге заваливать проекты из-за отсутствия ресурсов, промахов в оценке, сложного пресейла и еще по куче причин. Да, эта ситуация какое-то время будет досаждать крупным рыбам. Да, еще добавит огня перегретый рынок труда в нашей отрасли и сложности в хантинге действительно хороших кадров.

Но рынок не умирает, он трансформируется в новый формат, а само написание кода в нем становится важной, но не главной ценностью. На первый план выходит управление продуктом — менеджмент.

Ниже представим к какому распределению ролей в команде мы пришли в Интаро и будем рады узнать, как дела обстоят у коллег.

Мы привыкли, что проект-менеджер — и танцор, и певец, и на ТЗ игрец (мы даже в КП заявляли выделенного менеджера проекта, как преимущество). Но с развитием компании и команды также растет уровень и сложность проектов. Крупный бизнес ищет на рынке экспертизу, подкрепленную хорошей базой разработки, которая должна уже быть по умолчанию (к сожалению, пока далеко не у всех). На проектах такого масштаба классическая схема распределения ролей не справляется. Трудозатраты на сбор и глубокую проработку требований к системе/проекту/задаче могут занимать едва ли не больше, чем сама разработка. При такой загрузке менеджер не успевает заниматься бизнес аналитикой, аналитикой продукта, администрировать проект и коммуницировать с заказчиком одновременно. В результате повышенной нагрузки неизбежно будет страдать качество. Так в нашей компании назрело решение разделить роли аналитика и менеджера проекта.

Аналитик

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

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

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

Менеджер проекта

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

Разделение ролей проект-менеджера и аналитика было в нашей компании необходимым и взвешенным, но анализируя пул проектов за последний период также пришло понимание важности введения роли продюсера проекта.

Продюсер

Он, руководствуясь программой проектов, оптимальным образом распределяет роли в команде исходя из сильных сторон каждого специалиста и их загрузки. Причем, команда может быть и распределенной, расположенной удаленно друг от друга и от продюсера. Это может быть: подрядная команда backend-разработчиков, frontend-разработчик на аутсорсе, дизайнер и менеджер in-house — не столь важно. Самое главное, что бы центр компетенций находился у продюсера и у компании.

С учетом того, что при новом разделении ролей на одном блоке работ обязанности могут пересекаться, важно не допустить столкновения интересов внутри команды. Для этого стоит четко сформулировать зоны ответственности каждого специалиста и наладить сотрудничество.

Для кого подходит

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