Руслан Раянов: Как создать свою CRM

Аналогично и с техническим заданием. Если у вас ТЗ разбивается по этапам, то оформляйте его как часть дополнительного соглашения к договору.

Авторские права на систему должны принадлежать вам. При этом исполнитель сохраняет за собой право использования компонентов общего назначения и ядра системы, т.к. система обычно разрабатывается на базе платформы. Причем это может быть платформа третьей стороны, например, 1С-Битрикс, или являться собственностью исполнителя, как в нашем случае, arkAS.

Теперь перейдем к процессу взаимодействия с исполнителем.

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

– обработка ваших запросов и пожеланий;

– подготовка отчетов по ходу проекта;

– решение внештатных ситуаций.

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

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

Следующий важный момент – при планировании проекта менеджером вы должны четко обозначить свои приоритеты. Что нужно получить сначала? Что можно сделать уже на поздних этапах. Понимания ваши приоритеты, менеджер проекта сможет транслировать их на команду разработки.

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

Документация. Она помогает понять заказчику, правильно ли его понимает исполнитель.

Документацию надо писать сразу. Одна из причин – резкая смена исполнителя. Исполнитель чем-то вас не устраивает или произошел конфликт. Пока у вас нет документации и исходного кода – считайте себя заложником.

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

Разработчики в первую очередь должны разрабатывать, а не писать документы. Лучше всего возложить оформление документации по использованию системы на тестировщика со своей стороны. Таким образом, вы сможете лучше контролировать процесс, а разработчики при этом будут минимум времени тратить на документацию и ее оформление.

Мелкие и крупные правки. В проекте всегда бывают правки. Написание вами подробного ТЗ не значит, что все будет именно так, как написано в ТЗ. По мере развития проекта вы получаете дополнительную информацию, у вас появляются новые идеи. Возникает желание что-то улучшить. Как быть в этом случае? Если в договоре стоит фиксированная сумма, то вносить большие доработки в приложение без соответствия ТЗ будет некорректным.

При малых правках в большинстве случаев исполнитель идет навстречу заказчику и вносит их в систему.

Если грядут большие перемены, то следует составить новое ТЗ как дополнительное соглашение к договору и изменить план разработки.

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