Блог Интеграл

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

Важно сразу договориться о последующем использовании результатов совместной работы с заказчиком. Это взаимная работа, где заказчик предоставляет экспертизу, а вы преобразуете ее в программное решение. Крупные заказчики обычно претендуют на исключительные права на использование результатов проекта (часто с целью дальнейшей продажи в своей отрасли). Если вы не являетесь конкурентом заказчика, объясните, что ваш бизнес ориентирован на другие цели. Предложите внести в договор запрет на копирование проектных наработок. В случае сложных проектов иногда эффективнее начать с чистого листа, чем адаптировать уже существующие решения. Оговорите с заказчиком, какие части проекта можно демонстрировать публично (Например: фрагменты инструкций).

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

Минимально жизнеспособный продукт (MVP) — продукт с ограниченным функционалом, достаточным для удовлетворения первых потребителей. *****Главная цель*****: получение обратной связи для формирования гипотез дальнейшего развития. Вы, как заказчик, можете ждать лучшего решения. Но на старте стоит начать с низкого уровня удобства и постепенно двигаться к совершенству.

Клиент должен быстрее начать пользоваться результатом – так, вы получите фидбэк и сможете корректировать продукт, приближая его к идеалу. Удовлетворенность заказчика при этом будет постепенно расти.

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

Не рекомендуется участвовать в составлении ТЗ, потому что это накладывает на вас дополнительную ответственность.

Если в программировании у вас есть преимущество в скорости и эффективности: лучше концентрируйтесь на реализации конкретных решений, чем на составлении ТЗ.

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

План дисциплинирует и вас, и заказчика, устраняет разногласия на ранней стадии.

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

Самая быстрая работа – это организация структуры данных, которая занимает пару часов. Самая долгая – это разработка и верстка рабочих мест. Наибольшие риски связаны с интеграцией, при которой происходит длительное решение неожиданных проблем. Например, импорт двух таблиц из 8 колонок каждая займет у вас не более 4 часов. Трудоемкость импорта данных заказчика зависит от количества атрибутов. Максимальное время, требуемое на импорт, можно приблизительно рассчитать: 15 минут на каждый атрибут.

Со временем вы научитесь быстро оценивать затраты на проект, а на первых порах лучше засекать время выполнения задач, обращая внимание на проблемы.

После первой встречи с заказчиком вы создаете документ, фиксируя:

• краткое описание задачи;
• перечень объектов и процессов, предполагаемых в рамках проекта.

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