Сегодня мы поговорим о распространенной ошибке, которая погубила немало интересных стартапов.
Рассмотрим пример.
У нас есть компания, производящая программное обеспечение для малого бизнеса, позволяющее оцифровать процесс постановки задач. В системе присутствуют сотрудники компании, которые могут ставить друг другу задачи, сгруппированные по проектам. Иными словами, программа приводит в порядок часть бизнеса.
Каждая компания такого рода неизбежно заваливается разнообразными рекомендациями от клиентов.
Например: было бы очень круто, если бы наши пользователи не регистрировались в системе, а логинились с помощью вконтакта. Или: было бы здорово, если бы мы могли заводить в систему наших клиентов и открывать им доступ к части задач с особой настройкой прав. Или: было бы хорошо реализовать возможность создания задач по заранее созданным шаблонам. Или: в программе есть возможность прикреплять документы к задачам, хорошо бы было сделать так, чтобы документы можно было перетаскивать в браузер мышкой, как в gmail.
Возникает огромное пространство для написания дополнительного функционала.
При этом очень часто руководство таких компаний упускает из виду некоторые обстоятельства:
1. Значительная часть функционала, который, с точки зрения клиентов, хорошо бы было добавить, не принесет никакой финансовой отдачи, поскольку клиент принимает решение о покупке продукта или о продолжении пользования продуктом на основании совершенно других факторов, даже не задумываясь о наличии приятных фишек.
2. Почти каждый функциональный блок неразрывно связан с рядом других. Он использует общую информацию из баз данных, влияет на внешний вид множества страниц и.т.д. Соответственно, при доработке зависимых модулей требуется перерабатывать и вновь написанный. В результате усложнение системы приводит к росту количества ошибок и сильно снижает скорость внедрения действительно важных доработок.
3. Написание дополнительного функционала усложняет пользование системой, делает ее менее понятной.
4. Любая доработка конкурирует за время разработчиков и бюджет компании с другими потенциально возможными доработками.
При этом даже менеджеры, хорошо понимающие данные обстоятельства, часть попадают в плен ряда ловушек:
- А мне самому нравится, как это будет!
- Ну, у нас в данный момент очень важных задач нет, займемся пока этим!
- А у конкурентов-то этого нет!
- Клиенты просят, значит это действительно очень важно!
- И так далее.
На самом деле, важно только то, сколько дeнeг принесет данная доработка на горизонте нескольких лет за счет увеличения конверсии (интересующийся -> купивший) и уменьшения оттока.
Есть простая проверка того, насколько нужен тот или иной функционал.
Представьте, что вы познакомились где-то с интересным потенциальным клиентом. На конференции отраслевой, например. У вас есть 10-15 минут, чтобы описать функционал своего продукта. Расскажете ли вы сами про планируемую доработку? Можете ли вы представить, что у вас спросят, скажем, можно ли закачивать файлы перетаскиванием с рабочего стола в браузер? Представьте себя на месте клиента. Вы уже работаете в программе. Можете ли вы представить себе, что смените программу по причине наличия планируемой функции у конкурента и отсутствия у вас?
Если ответ на все вопросы – „нет”, с вероятностью 80-90% доработка не будет иметь значимого влияния на структуру продаж и общую удовлетворенность пользователей.
Безусловно, данные рассуждения касаются прежде всего небольших и средних компаний с ограниченными бюджетами. Конечно, вышесказанное не означает, что бизнес не должен слушать своих клиентов. И естественно, что некоторые приятные дополнения, не имеющего прямого влияния на структуру продаж, могут иметь место в роли генераторов WOW-эффекта – когда пользование продуктом приводит пользователя в такой восторг, что он с удовольствием начинает рекомендовать его всем своим друзьям.
Тем не менее, в условиях ограниченности ресурсов очень важно строго подходить к любой идее дописать что-нибудь полезное и интересное. Если мы не ходим в рестораны с размером счета в свой недельный доход, то почему же можно убить неделю работы разработки на функционал, который будет радовать нас пару часов, а потом будет только отъедать ресурсы на поддержание его корректной работы по мере развития других модулей продукта.
Данный принцип внимания к трудозатаратам лежит в основе грамотного личного тайм-менеджмента.
Можно очень много и усердно работать, но при этом тратить время на вещи, которые приятно и интересно делать и которые совершенно не приближают вас даже к целям на год-полтора.
В следующий раз поговорим о других возможных ошибках при выстраивании приоритетов разработки, ну и немного поговорим о личном тайм-менеджменте, проведя ряд анaлoгий.