Мы работаем с заказными проектами, и почему-то заказчик частенько недоволен тем, что долго делаем работы, сделано не то, что нужно и прочее. И как в такой ситуации быть?
Разбираемся по порядку.
Начало.
Когда берём проект в работу, идёт достаточно длинный диалог с клиентом, выясняем, что же он хочет сделать, какие вопросы он решает на своем производстве и какие проблемы у него с текущими ИТ-решениями. А вот дальше начинается самое интересное.
Мы приблизительно понимаем как реализовать тот или иной функционал, но как конкретно мы его реализуем, понятия нет ни у кого. Дизайнер пока не представляет, как это будет выглядеть. Программист не представляет, какое архитектурное решение будет здесь наиболее уместным и не приведёт к катастрофе в дальнейшем, при доработке системы. Бизнес-аналитик ещё не знает всех сценариев использования этой системы. И это ещё не самое интересное! Все происходит как по методичке. Раз за разом ситуация повторяется.
Работаем.
Мы поговорили, поняли, чего хочет клиент. Но поняли мы это так, как понял это бизнес-аналитик. Он продумывает как будет работать, та или иная функция, рисует схемы взаимодействия и какие данные будут обрабатываться. Теперь мы переходим к дизайну.
Дизайнер продумывает как будет работать интерфейс, как выполнить в нем те задачи, которые ему рассказал бизнес-аналитик. Придумывает дизайнерские решения. Делает прототип. Показывает заказчику. Заказчику нравится красивая картинка, какие-то действия там уже происходят. Считай согласовано.
Следующий шаг: разработка. Как передал задачу бизнес-аналитик, как изобразил это дизайнер и как понял эти макеты, документы по проекту и схемы программист, так он это и делает. Заняло это всё 2 недели.
Сдаем проект!
Показываем заказчику результат. И вот незадача, при проверке на готовом продукте не хватает каких-то данных, которые обязательно надо учесть, ну и не предусмотрели какой-то сценарий работы с поставщиком… В целом все соответствует ТЗ и макетам, но не работает так, как надо. А ведь ради этого вся разработка и затевалась. А самое веселое, что это не поправить за день-два.
Решение, которое выбрал разработчик, не позволяет реализовать тот сценарий, который не учли по началу. На переделку надо ещё 2 недели, потому, что надо ещё те данные как-то хранить, и не просто хранить, а сохранять версии этих данных. Это ещё неделя-другая.
Результат.
Итого, надо доработать макеты т.к. тот сценарий сильно меняет логику работы. Документы по проекту нужно привести в соответствие с текущим пониманием процессов. Задачи в Jira нарезаем исходя из того, что надо все сжечь и заново построить. Кроме того надо изменить структуру базы данных, доработать свёрстанный интерфейс, переписать функционал с учётом всех новых требований. И протестировать это. Занимает это 4 недели сверху тех 2-х. Хотели сделать за 2 недели, заняло 6. Ошибка в планировании времени и сложности реализации будет более чем в 3 раза. И вот как считать клиенту стоимость проекта?
Выводы.
Какой вывод я могу сделать из этого?
А такой, что риски связанные с реализацией проекта в ит примерно в 3-5 раз выше чем в любой другой. Связано это с невероятным уровнем неопределенности на входе в проект.
Ну и сверху накладывается творческая специфика разработки, нужно соблюсти баланс при проектировании. Запроектируешь слишком широко, потом будешь много и долго писать, а это будет не востребовано. А сузишь архитектуру, получишь проблемы, что не сможешь нормально реализовать функционал и уж тем более работать с изменениями и расширениями продукта.
Этим постом я лишь хотел показать, что все не так радужно, как вам рассказывает менеджер по продажам и яркие заголовки на сайтах. Чтобы не было иллюзий и завышенных ожиданий. Есть сложности и от них никуда не уйдешь. Мы теряем из-за этого деньги и время. Но на таких ошибках мы научились быть более педантичными в своей деятельности.
Первый же такой проект научил нас писать ТЗ последовательно шаг за шагом, так, что в нем почти нет неопределенностей. Работаем только спринтами и никакая клиентоориентированность в данный отрезок времени не может быть оправданием изменениям задачи. Все изменения до начала спринта и после окончания только приветствуются. Такой подход приводит к результатам.