Козлов Эдуард | Умная веб-разработка с 2004 года
Козлов Эдуард | Умная веб-разработка с 2004 года

Нужен ли бизнес-анализ в веб-разработке?

Смотреть на Youtube

Смотреть в ВК

Текст видео

Сегодня давайте поговорим про то, без чего невозможен успешный запуск ни одного ИТ проекта. Это, конечно же, Техническое Задание. В веб-разработке мы техническое задание делим обычно на два типа документов:

  1. Техническое задание от клиента. В нем описана логика работы, цели и задачи внедряемого ИТ решения: разработки сайта, какого-то модуля для сайта.
  2. ТЗ для разработчиков. В нем описываются методы реализации, методы взаимодействия данных и т.д.

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

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

Первый тезис, который нужно понять в веб-разработке: клиенту писать ТЗ на уровне разработчика бесполезно и даже вредно.

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

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

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

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

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

Прокомментировать

Ваш адрес email не будет опубликован.