Блог

4.09.2018

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


И потом часто оказывается не очень доволен. Потому что конечные клиенты (пользователи) не очень рады этому решению, а временами и совсем отказываются им пользоваться.


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


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



Улучшить ситуацию можно, если начать чаще использовать слово “гипотеза”, т.е. набор предположений, которые сначала нужно качественно сформировать, потом эффективно проверить. А потом быть готовыми на основе результатов проверки нужным образом подкорректировать старую или сформулировать новую гипотезу. И снова повторить проверку.


А главное, это волшебное слово “гипотеза” позволяет разработчику перестать делать вид (хотя временами разработчика начинают даже верить в это), что он однозначно умеет сделать хорошее, нужное решение с первого раза.



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


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



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


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


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


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



В-третьих, как мы уже поняли, выдвинутую гипотезу (на то она и гипотеза) нужно проверить. И сделать это важно максимально быстро с минимально возможными затратами ресурсов.


Этот пункт порою оказывается самым сложным. Потому что вместо “проверки гипотезы” начинает подразумеваться “подтвердить гипотезу”. Ведь ресурсы уже потрачены, люди уже отработали, заказчик подтвердил, что все идет нормально. И вообще зачем переделывать, если все и так выглядит неплохо?.. Но мы то знаем, что если найденное решение не эффективно, то оно не сделает заказчика удовлетворенным в будущем.


В общем, именно для этой цели придуманы несколько методик вроде Lean Startup (бережливый стартап), которые позволяют тестировать гипотезы на реальных конечных клиентах (пользователях) с минимально возможными расходами. И быть готовыми морально не только подтверждать, но и опровергать гипотезы с минимальными потерями.   



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


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


А как подготовить, настроить заказчика на понимание и принятие этого подхода с гипотезами и правом на ошибки - тема для еще одного текста.