Процесс. 1. Сбор информации
Увы, даже не смотря на то, что я работаю в отличной компании и супер профессиональной команде, процесс работы пока еще оставляет желать лучшего. Поэтому начну-ка я записывать свои мысли относительно организации процесса создания веб-продукта на условных примерах.
Начну с самого начала. Приходит крупная задача. Начинаются обсуждения, чего, куда, как и сколько. В общем-то стандартная процедура, в ходе которой формируется общее понимание условий задачи между всеми участвующими в ее решении.
Тут нужно остановиться и понять, ту ли задачу мы решаем. Часто бывает, что менеджер или маркетолог уже за всех подумал и буквально нарисовал собственное видение придуманного им бизнес-процесса. Если он хорошо знает отрасль и насколько возможно разбирается в технологиях, это очень хорошо, с ним просто найти общий язык и быстро понять, чего он хочет на самом деле. Увы, такие постановщики задач встречаются очень редко.
Вероятнее всего, есть перманентная необходимость повысить объемы отъемов денег у населения. И вот наштурмовавшись вдоволь, отдел маркетинга (сюда можно подставить любого заказчика) выносит команде собственное видение решения задачи вместо определения сути проблемы, которую они хотели бы решить.
Например, давайте навешаем баннеров или сделаем еще один раздел на сайте. Нормальная постановка, вроде бы все логично. Кроме баннеров, разумеется. Раздел, дескать, будет нам приносить в месяц +100500 рублей, это все точно подсчитано и аргументировано кучей цифр и графиков. Отдел будет выполнять и перевыполнять планы, получать бонусы, пользователи получат дополнительный функционал, в общем, все станет круто и хорошо.
На этом месте стоит остановиться. И подумать. Крепко подумать. В идеальном мире, возможно такая стратегия увеличения оборотов бы сработала и все были бы довольны. Но для сколько-нибудь адекватных прогнозов нужно детальное исследование рынка, потребностей и уникальности предоставляемого контента. Такие вещи весьма сложны и трудоемки, я уж не говорю об уникальных специалистах, которые могли бы адекватно их производить с хотя бы приблизительной долей уверенности в результате.
Короче говоря, предложенные задачи далеко не всегда являются решением исконной проблемы. А точнее, задача достаточно редко является точным отражением проблемы. На этом этапе нужно держать в голове разницу между ними и пытаться понять исходную проблему. Как это сделать? Есть несколько путей. Можно плотно общаться с заказчиком и по шагам постепенно определять необходимости и путь их возникновения. И, если это возможно, корректировать постановку задачи уже на этом этапе. Другой, менее точный метод состоит в анализе конкурентов, что у них с подобной темой и почему. Он не приведет к каким-то адекватным результатам, если имеются расхождения в понимании задачи, но позволит хотя бы сократить количество ошибок при решении хоть и другой, но вроде бы обозначенной заказчиком проблемы. Ну и сэкономит этим немножко времени перед тем, как придется все переделывать.
Я рекомендую семь раз отмерить, а точнее как можно более глубоко обсудить задачу, чтобы в голове у всех возникло одинаковое видение ситуации. И с высоты каждого члена команды в зависимости от его компетенции проанализировать, что мы еще могли не учесть, какой информации не хватает, а какая не относится к делу. Маркетолог со стороны продаж и прибылей, дизайнер со стороны удобства пользователя, разработчик со стороны времени и ликвидности разработки. После этого обычно возникает некий гештальт у каждого участника процесса и в будущем он избавляет от кучи правок и переделок. Да и сама задача выкристаллизовывается в нечно понятное и ожидаемое. Круто, если на этом этапе сделать некоторую модель, на которой можно проверить адекватность ожидаемых результатов от выбранной стратегии.
Обычно такой моделью у нас служит прототип. О ней и о наших способах проверки ее на жизнеспособность в другой раз.
Начну с самого начала. Приходит крупная задача. Начинаются обсуждения, чего, куда, как и сколько. В общем-то стандартная процедура, в ходе которой формируется общее понимание условий задачи между всеми участвующими в ее решении.
Тут нужно остановиться и понять, ту ли задачу мы решаем. Часто бывает, что менеджер или маркетолог уже за всех подумал и буквально нарисовал собственное видение придуманного им бизнес-процесса. Если он хорошо знает отрасль и насколько возможно разбирается в технологиях, это очень хорошо, с ним просто найти общий язык и быстро понять, чего он хочет на самом деле. Увы, такие постановщики задач встречаются очень редко.
Вероятнее всего, есть перманентная необходимость повысить объемы отъемов денег у населения. И вот наштурмовавшись вдоволь, отдел маркетинга (сюда можно подставить любого заказчика) выносит команде собственное видение решения задачи вместо определения сути проблемы, которую они хотели бы решить.
Например, давайте навешаем баннеров или сделаем еще один раздел на сайте. Нормальная постановка, вроде бы все логично. Кроме баннеров, разумеется. Раздел, дескать, будет нам приносить в месяц +100500 рублей, это все точно подсчитано и аргументировано кучей цифр и графиков. Отдел будет выполнять и перевыполнять планы, получать бонусы, пользователи получат дополнительный функционал, в общем, все станет круто и хорошо.
На этом месте стоит остановиться. И подумать. Крепко подумать. В идеальном мире, возможно такая стратегия увеличения оборотов бы сработала и все были бы довольны. Но для сколько-нибудь адекватных прогнозов нужно детальное исследование рынка, потребностей и уникальности предоставляемого контента. Такие вещи весьма сложны и трудоемки, я уж не говорю об уникальных специалистах, которые могли бы адекватно их производить с хотя бы приблизительной долей уверенности в результате.
Короче говоря, предложенные задачи далеко не всегда являются решением исконной проблемы. А точнее, задача достаточно редко является точным отражением проблемы. На этом этапе нужно держать в голове разницу между ними и пытаться понять исходную проблему. Как это сделать? Есть несколько путей. Можно плотно общаться с заказчиком и по шагам постепенно определять необходимости и путь их возникновения. И, если это возможно, корректировать постановку задачи уже на этом этапе. Другой, менее точный метод состоит в анализе конкурентов, что у них с подобной темой и почему. Он не приведет к каким-то адекватным результатам, если имеются расхождения в понимании задачи, но позволит хотя бы сократить количество ошибок при решении хоть и другой, но вроде бы обозначенной заказчиком проблемы. Ну и сэкономит этим немножко времени перед тем, как придется все переделывать.
Я рекомендую семь раз отмерить, а точнее как можно более глубоко обсудить задачу, чтобы в голове у всех возникло одинаковое видение ситуации. И с высоты каждого члена команды в зависимости от его компетенции проанализировать, что мы еще могли не учесть, какой информации не хватает, а какая не относится к делу. Маркетолог со стороны продаж и прибылей, дизайнер со стороны удобства пользователя, разработчик со стороны времени и ликвидности разработки. После этого обычно возникает некий гештальт у каждого участника процесса и в будущем он избавляет от кучи правок и переделок. Да и сама задача выкристаллизовывается в нечно понятное и ожидаемое. Круто, если на этом этапе сделать некоторую модель, на которой можно проверить адекватность ожидаемых результатов от выбранной стратегии.
Обычно такой моделью у нас служит прототип. О ней и о наших способах проверки ее на жизнеспособность в другой раз.