Почему требование «быстро, недорого, вчера» — это норм

Клиент не доволен продуктом? Сроки постоянно сдвигаются? Команда теряет мотивацию? Есть универсальное решение! Шутка. Мы не в дешевой рекламе. Универсального решения нет. Есть только мое, субъективное.

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

Что в статье?

Всем электронный hello! Немного о карьерной себе. Меня зовут Леся, и я проджект-менеджер в полезном цифровом агентстве WPP.DIGITAL

Вошла в IT около 5 лет назад и пока что отсюда не вышла. Начинала как аккаунт в стартапе с продуктом на стыке IoT и AI. После уже работала как PM внутри краудфандинговой платформы для креаторов. Сейчас в основном веду стартапы. Думаю, что в других агентствах их также много. Сейчас объясню почему.

Основная часть агентских IT-компаний в РФ работает с малым и средним бизнесом. Пруфом может служить статистика Рейтинга Рунета 2023 –

Поэтому в статье я говорю именно про работу с «обычными» проектами, с которыми работают остальные 83% студий ежедневно. Назовем эти проекты среднестатистическими.

Разбег внутри таких проектов большой. С одной стороны, уверенно стоящий на ногах «взрослый» средний бизнес, где есть свои техдиректор, техкоманда, бизнес-аналитик, продакт и т. д. и т. п. С другой стороны, стартап, где есть только business owner и собственно все.

Скорее всего, уверенно стоящий на ногах средний бизнес сейчас редко передает всю разработку на аутсорс. Это связано с тем, что у них есть ресурсы растить свой in-house, им так удобнее, спокойнее, увереннее. Или есть еще причины, которые мне неизвестны. Но факт в том, что такой бизнес отдает на аутсорс небольшой пул задач. Там есть своя особенная коммуникация и правила ведения таких проектов, но дальше речь пойдет не о них. Тут про второй тип бизнеса — про стартапы.

Так вышло, что я всю IT-карьеру работала внутри стартапов или со стартапами. Моя стандартная dream team выглядит примерно так:

1. ЛПР-ы, в составе которых business owner и/или менеджер по развитию продукта;
И
2. outsource-команда, состоящая из project-менеджера, devлида, четверти devOps-ера, 4-х разработчиков и 2-х тестеров.

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

Первое действие, когда получаешь такой запрос —«мы так не работаем, поговорим, когда у тебя будет норм ТЗ, пока». Раньше я так и поступала. Наивно полагала, что клиент вернется с ТЗ через пару дней и мы начнем плодотворно работать. Ждала долго. От 1 месяца до 4-х. ⅔ клиентов просто не возвращались. Позже оказалось, что они просто уходили к другим командам. Оставшаяся ⅓ возвращалась минимум через 3 недели все еще со слабо проработанными тех. требованиями.

Но не уровень ТЗ был главной проблемой. Ко времени возвращения клиента мы уже не могли выделить ресурсы на его проект прямо сейчас. Клиент не хотел находиться в долгом листе ожидания именно своей проектной команды. Решал уйти к другим. Итог подхода — отток клиентов, денег, простой специалистов.

После полугода работы по такому принципу, начала искать поломку в работе команды. Проанализировала свою коммуникацию, пообщалась с «ушедшими» клиентами. Поняла, что слишком многого хотела от владельца стартап-продукта. Откровением для меня стала загруженность business owner-а. На нем перманентно завязано +100500 вопросов разного уровня сложности, не считая его основной деятельности — ежедневного буста всего продукта. Это нормально, если он приходит с запросом «хочу вот такую реализацию, быстро, недорого, вчера». Задача клиента как раз купить эту техническую экспертность.

С того момента руководствуюсь принципом — ТЗ должен делать не business owner, а мы, аутсорс-команда. Сейчас сделать клиенту ТЗ — это моя задача №1. Именно с этого этапа начинается настоящая клиентоориентированность — понять боль и потребность, а после упаковать все это в максимально понятные требования для разработки.

Железное и неизменное ТЗ — розовые пони в клубничном джеме. На ТЗ может повлиять буквально все: от аномально жаркой погоды до войны. У меня была ситуация, когда клиенту на середине разработки нужно было трансформировать продукт из b2c в b2b. Мы пошли на это. Такие форс-мажоры со стороны клиента решаются работой через agile-практику.

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

И тут я усвоила для себя вторую истину: полностью избежать подобного рода ситуаций не получится. В ТЗ, скорее всего, будут темные пятна, которые проджект и devлид просто не увидят во время согласования ТЗ.

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

При расчете сроков разработки не закладывать время на риски — как вы уже догадались, снова розовые пони в клубничном джеме. Выше описала риск темных пятен в ТЗ. Этот риск не стопроцентной вероятности, но на ⅔ моих проектов он наступал.

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

Тут проджект может испугаться, что клиент уйдет, и принять его условия. Так было, например, у меня. Итог — разработка 100% не укладывалась в срок. Продукт не то что в космос не улетел, но даже встать на ноги был не в состоянии.

Теперь я максимально честно и твердо говорю клиенту о сроках. А если слышу «странно работаете, если столько багов», то предлагаю клиенту звонок-презентацию. Там я демонстрирую причины багов и объясняю, почему они неизбежны и будут продолжаться дальше. Если есть решения по сокращению ошибок — предлагаю. После таких звонков-презентаций обычно претензий к работе команды не остается.

Фух, как будто все! Суммируем сказанное.

Работа со стартапами — это гибко, сложно, но от этого и интересно. Аргументы типа «слишком мало информации для старта работ», «у нас другие процессы», «мы так не привыкли» — это оправдания неготовности быть гибким и полезным. Think about it & lets talk, жду вашу обратную связь.