Руслан Раянов - Как создать свою CRM
При этом желательно иметь план внедрения модулей системы. Например, в этом году мы внедрим модули 1-5, а в следующем – 6-9 модули.
Из опыта вспоминаются ситуации, когда некоторые заказчики хотят выполнить очень большой проект за один этап, например, реализовать аналог Avito.ru. Желание заказчика понятно – он хочет избежать риска получить часть продукта, ведь ему нужен целостный продукт. Сам не понимая того, он движет проект к катастрофе, т.к. подобные проекты невозможно сделать одним куском за один раз. Здесь действует цикл «задумка – реализация – получение обратной связи – анализ». Вспомните, Windows не сразу стал тем, что он есть сейчас.
Есть и обратные примеры, когда разработка ведется фрагментарно. Новые функции появляются без всякого плана, спонтанно. Это тоже плохой вариант развития ситуации, поскольку теряется фокус и функции добавляются хаотично.
Очень важный момент. Обе эти ситуации порождает заказчик, а не исполнитель! Именно заказчик определяет стиль стратегического управления продуктом. Исполнителю остается только разве что пожимать плечами и подчиниться пожеланию заказчика. Если у вас большой проект, то имейте стратегический план его развития и не пишите большое ТЗ сразу на всю систему.
Итак, вы нашли исполнителя, написали совместно с ним ТЗ. Пора приступать к разработке CRM. В следующей главе мы рассмотрим, как управлять проектом со стороны заказчика, какие бывают подводные камни и как построить взаимодействие с командой разработки.
Глава 4. Реализация проекта и внедрение системы
Итак, начинаем проект по созданию CRM-системы. Что нужно сделать в первую очередь? Заключить договор. Заключение договора более предпочтительный способ, чем другие.
Работа по безопасной сделке, например, через fl.ru подразумевает использование третьей стороны в качестве арбитража между вами и исполнителем. Тем самым вы предоставляте доступ к своим коммерческим данным третьей стороне. На мой взгляд, подобные сервисы – это некоторый компромисс между официальными договорами и работой без договора.
Работа без договора. Здесь нюанс в том, что разработка системы предполагает длительное сотрудничество. В случае создания простого сайта визитки, возможно, лучше работать без договора (или по договору оферты). Но в случае создания большой серьезной системы у вас должны быть гарантии, что исполнитель не испарится внезапно.
Что прописывать в договоре? В первую очередь – это права на систему, сроки, бюджет и порядок приемки. Обычно такой договор составляется подрядчиком (скорее всего, у него есть типовой договор). Внимательно читайте эти пункты, особенно порядок приемки.
По цене и срокам. Если разработка системы делится на несколько этапов, то бессмысленно писать сроки и стоимость в основном договоре, т.к. ни одна из сторон не может дать точной оценки сроков и бюджета проекта. Это будет лишь вносить элемент неопределенности и нервотрепки в ваши взаимоотношения с исполнителем. Лучше писать стоимость по каждому этапу в очередном дополнительном соглашении к договору.
Аналогично и с техническим заданием. Если у вас ТЗ разбивается по этапам, то оформляйте его как часть дополнительного соглашения к договору.
Авторские права на систему должны принадлежать вам. При этом исполнитель сохраняет за собой право использования компонентов общего назначения и ядра системы, т.к. система обычно разрабатывается на базе платформы. Причем это может быть платформа третьей стороны, например, 1С-Битрикс, или являться собственностью исполнителя, как в нашем случае, arkAS.
Теперь перейдем к процессу взаимодействия с исполнителем.
Обычно от исполнителя выделяется человек, который будет взаимодействовать с вами. В его задачи обычно входит:
– обработка ваших запросов и пожеланий;
– подготовка отчетов по ходу проекта;
– решение внештатных ситуаций.
С вашей стороны хорошо бы иметь доступ не только к этому человеку, но и к команде разработки. Обычно разработчики менее подкованы в плане дозированный выдачи информации клиенту – вы сможете узнать более реалистичную картинку. Однако разработчики разговаривают на довольно специфичном языке. Будьте готовы к тому, что не всегда получится полное взаимопонимание с ними. Именно для этого и придумали должность бизнес-аналитика.
Важный момент. Не думайте, что вы сделали ТЗ, отдали группе разработки и можно забыть о проекте на пару месяцев. При таком подходе вы не получите нужного вам результата. Контролируйте минимум 1 раз в неделю как идут дела по проекту. При этом изучайте не только отчеты команды разработки, но и смотрите своими глазами тестовое приложение и пробуйте использовать тестовые функции. Тем самым вы сможете вовремя вносить корректировки в процесс развития функционала проекта. Ваша задача – постоянно давать обратную связь по разработанному функционалу.
Следующий важный момент – при планировании проекта менеджером вы должны четко обозначить свои приоритеты. Что нужно получить сначала? Что можно сделать уже на поздних этапах. Понимания ваши приоритеты, менеджер проекта сможет транслировать их на команду разработки.
Некоторые заказчики определяют все свои задачи важными и необходимыми для реализации. Это управленческий просчет. В проекте может быть много разных рисков (конфликт с исполнителем, проблемы с бюджетированием, выход за сроки, переработка уже сделанного функционала и многое другое). Желательно, чтобы при резком прерывании проекта у вас был минимально необходимый работающий функционал, который можно использовать в работе. Стремитесь к тому, чтобы ваша система уже через месяц работала хотя бы в тестовом режиме.
Документация. Она помогает понять заказчику, правильно ли его понимает исполнитель.
Документацию надо писать сразу. Одна из причин – резкая смена исполнителя. Исполнитель чем-то вас не устраивает или произошел конфликт. Пока у вас нет документации и исходного кода – считайте себя заложником.
Писать документацию проще по горячим следам. Требуйте документацию сразу же после тестирования. Причем требуйте документацию не только для пользователя, но и для программиста. С другой стороны, на оформление документации нужно выделить время. Поэтому не спрашивайте подробно написанных и оформленных документов. Подойдет просто текстовое описание и скриншоты.
Разработчики в первую очередь должны разрабатывать, а не писать документы. Лучше всего возложить оформление документации по использованию системы на тестировщика со своей стороны. Таким образом, вы сможете лучше контролировать процесс, а разработчики при этом будут минимум времени тратить на документацию и ее оформление.
