Рубрика "Покер и бизнес". Выпуск 2.

ПРО AlexOm +6496 0614

Сегодня мы поговорим о распространенной ошибке, которая погубила немало интересных стартапов.

Рассмотрим пример.

У нас есть компания, производящая программное обеспечение для малого бизнеса, позволяющее оцифровать процесс постановки задач. В системе присутствуют сотрудники компании, которые могут ставить друг другу задачи, сгруппированные по проектам. Иными словами, программа приводит в порядок часть бизнеса.

Каждая компания такого рода неизбежно заваливается разнообразными рекомендациями от клиентов.

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

Возникает огромное пространство для написания дополнительного функционала. 

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

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

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

3. Написание дополнительного функционала усложняет пользование системой, делает ее менее понятной. 

4. Любая доработка конкурирует за время разработчиков и бюджет компании с другими потенциально возможными доработками.

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

  • А мне самому нравится, как это будет!
  • Ну, у нас в данный момент очень важных задач нет, займемся пока этим!
  • А у конкурентов-то этого нет!
  • Клиенты просят, значит это действительно очень важно!
  • И так далее.

На самом деле, важно только то, сколько дeнeг принесет данная доработка на горизонте нескольких лет за счет увеличения конверсии (интересующийся -> купивший) и уменьшения оттока.

Есть простая проверка того, насколько нужен тот или иной функционал.

Представьте, что вы познакомились где-то с интересным потенциальным клиентом. На конференции отраслевой, например. У вас есть 10-15 минут, чтобы описать функционал своего продукта. Расскажете ли вы сами про планируемую доработку? Можете ли вы представить, что у вас спросят, скажем, можно ли закачивать файлы перетаскиванием с рабочего стола в браузер? Представьте себя на месте клиента. Вы уже работаете в программе. Можете ли вы представить себе, что смените программу по причине наличия планируемой функции у конкурента и отсутствия у вас? 

Если ответ на все вопросы – „нет”, с вероятностью 80-90% доработка не будет иметь значимого влияния на структуру продаж и общую удовлетворенность пользователей.

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

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

Данный принцип внимания к трудозатаратам лежит в основе грамотного личного тайм-менеджмента. 

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

В следующий раз поговорим о других возможных ошибках при выстраивании приоритетов разработки, ну и немного поговорим о личном тайм-менеджменте, проведя ряд анaлoгий. 

18

Бонусы Pokeroff

Holdem Manager 2 в подарок!
VIP
Групповые тренировки с ПРО
Курс МТТ от гения
Нет комментариев
    Добавить комментарий
    Комментировать без регистрации
      

    На указанную почту придет ссылка для подтверждения

    Отменить

    Узнай первым
    о важных новостях

    Мы будем присылать уведомления
    горячих новостях и статьях!

    Так будут выглядеть оповещения, которые появятся на экране.

    Хочу знать!Буду оставаться в неведении

    Livechat