Текст книги "Как создать свою CRM"

Руслан Раянов

Как создать собственную CRM

Руководство по созданию CRM для вашего бизнеса

www.web-automation.ru 2015

Введение

Итак, вы наконец решили внедрить в своей организации CRM. В этом небольшом руководстве Вы найдете методику создания собственной CRM, адаптированной под ваш бизнес.

Тем, кто будет использовать готовую CRM, данное руководство поможет лучше понять собственные потребности в плане организации бизнес-процессов вашей компании (продажи, контрагенты, финансы, проекты и т.д.).

Давайте начинать, и в первой главе мы рассмотрим, что такое CRM и зачем она нужна.

Глава 1. Что такое CRM и зачем она нужна.

Если кратко, то CRM – это программа, предназначенная для учета, обработки и хранения информации о взаимоотношениях с вашими клиентами. Мы это понятие слегка расширим и будем считать, что это программа, позволяющая упростить управление вашими бизнес-процессами.

Допустим, вы продаете некоторые продукты. Сразу можно выделить процессы, которые возможно автоматизировать с помощью CRM:

– учет Поставщиков;

– закупка у Поставщиков;

– продажи;

– база Клиентов;

– база Сотрудников;

– отделы;

– финансовые транзакции (счета);

– система мотивации;

– брак;

– каналы сбыта.

В итоге CRM позволяет добиться следующих целей:

➢ уменьшение издержек. Автоматизация сложных вычислений и других операций. Уменьшение лишней коммуникации между сотрудниками и формализация бизнес-процессов.

➢ ускорение бизнес-процессов. Уведомления (почта, СМС), исключение ненужных рутинных задач из бизнес-процесса и упрощение операций обработки данных (например, поиск по базе клиентов).

➢ улучшение качества продукции. В основном за счет ведения метрик (рассмотрим далее).

➢ повышение прозрачности бизнеса. Данные по работе всех сотрудников заносятся в систему. Есть возможность делать на основании этих данных отчеты руководству для понимания ситуации на местах.

➢ управление на основе KPI. Для каждого процесса можно выделить показатели эффективности (метрики) и начать их отслеживать с помощью CRM (через панель метрик в личном кабинете руководителя). Внедрили инновацию – оцениваете изменение метрик.

➢ стандартизация бизнес-процессов. Все сотрудники работают по определенной схеме, которая заложена в CRM. Плюс работают правила отфильтровки неверных данных, что способствует унификации данных.

Теперь давайте определимся с выбором вашей CRM.

Возможны три варианта:

Использовать готовую CRM общего назначения.

Использовать готовое CRM – решение для вашей отрасли.

Создать собственную CRM.

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

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

В любом случае этот вариант достоин рассмотрения. Как минимум необходимо изучить 1-2 программы данного рода и посмотреть, подходят ли она вам.

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

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

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

Получается, что собственная CRM нужна компаниям, у которых либо сложные бизнес-процессы, либо тем, кто собирается оптимизировать свой бизнес в процессе эксплуатации CRM.

Конечно, разработка собственной CRM стоит дороже, чем внедрение готовой, т.к. программное приложение по сути пишется под потребности вашего бизнеса. Также сроки внедрения собственной CRM больше, чем готовой системы. Здесь важно определиться с краткосрочными и долгосрочными приоритетами. Что важнее? Скорость внедрения, стоимость, учет специфики бизнес-процессов, безопасность, удобство и др.

В дальнейшем мы рассмотрим третий вариант внедрения CRM – создание CRM под требования вашего бизнеса.

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

➢ концепция;

➢ техническое задание;

➢ проектирование и кодирование;

➢ тестирование и доработки;

➢ внедрение в эксплуатацию.

В следующей главе мы кратко поговорим о концепции проекта и как ее правильно составить.

Глава 2. Концепция проекта CRM.

Допустим, вы решили разработать собственную CRM. Для этого необходимо написать концепцию будущего проекта.

По сути, концепция – это документ, на основании которого вы будете общаться с подрядчиками-кандидатами.Очень важно составить ее правильно, чтобы на ранней стадии отсеять неподходящих подрядчиков.

Что должна содержать концепция проекта:

➢ Краткое описание проекта (1 предложение).

➢ Состав модулей (определение ролей и их функций).

➢ Требования к технологиям.

➢ Параметры проекта (сроки, стоимость).

➢ Требования к команде разработки + состав брифа для нее.

Пройдемся подробнее по каждому пункту.

Краткое описание проекта.

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

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

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

Плохие примеры:

Создание сайта

Нужна программа

CRM

Хорошие примеры:

Нужна студия на разработку движка CRM

Разработка CRM на заказ

Разработка CRM на заказ, только Москва.

Состав модулей (определение ролей пользователей и их функций).

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

После того, как вы определили роли в системе, кратко опишите их.

Например, роль – продавец. Продавец имеет следующие функции: создание коммерческого предложения, просмотр базы клиентов, обработка потенциальных клиентов и их предзаказов, печать документов для заказов.

Требования к технологиям

Если у вас на предприятии уже используются сервера, то подумайте о том, чтобы будущая CRM была совместима по технологиям с существующей инфраструктурой. Это необязательное требование, но лучше заранее продумать этот момент. К примеру, если у вас на сервере используется ПО MS Windows, то нет смысла делать свою CRM на технологиях, которые подразумевают использование серверов Linux. Если все ваши системы будут сделаны на одних и тех же технологиях, это снизит стоимость поддержки IT-решений.

Если нет никакой привязки к технологиям, то тоже лучше кратко укажите этот момент к концепции. Будет меньше вопросов.

Параметры проекта.

Указывайте всегда вилки оценки стоимости и сроков.

Точную стоимость указывать бессмысленно, т.к. в ходе проекта будут новые дополнения и развитие функционала. Нужен просто порядок цен и сроков, чтобы подрядчик это соотносил со своими возможностями / ресурсами.

Т.е. сейчас задача не стоит в том, чтобы точно оценить бюджет и сроки. Нужно просто понимание контуров проекта. Для заказчика и для подрядчика.

Есть еще один параметр проекта – качество. Но его довольно сложно описать кратко в концепции. Как вариант, вы можете требовать некоторых гарантий. С другой стороны, гарантии вам выдают продавцы от IT компаний, а обеспечить их будут разработчики. И здесь иногда возникает некоторое рассогласование обещаний продавцов и фактического сервиса компании.

Требования к команде разработки.

Укажите, кто именно вам нужен. Если у вас есть IT-директор или технический специалист, то привлеките его к этой работе.

Какой должен быть состав команды разработки?

Какой компетенцией они должны обладать?

Есть ли пожелания по взаимодействию с командой? (например, условие – хотим иметь возможность напрямую общаться с разработчиками, а не только через менеджера).

В какие часы/дни специалисты должны быть доступны?

Какие средства связи использовать (скайп, телефон)?

Личные встречи?

После всех вопросов напишите, что конкретно вы хотите получить от исполнителя, если его заинтересовал проект.

Вообщем, вам нужен от него заполненный бриф.

Что может включать бриф:

– ваша оценка проекта (сроки, бюджет)

– ответы на вопросы

– технологии

– порядок работ

– город, ФИО, контакты

– портфолио, кейсы

– предложения по созданию CRM

А теперь давайте рассмотрим, какими качествами должна обладать хорошая концепция:

➢ краткость и лаконичность. Без «воды». Если написано слишком много и беспорядочно, то есть вероятность, что многие даже не прочтут вашу концепцию, либо поймут ее неверно.

➢ структурированность. Структура рассмотрена выше.

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

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

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

Об этом мы и поговорим в следующей главе.

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

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

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

В прошлой главе мы составили концепцию проекта. Этот документ мы будем использовать как основной для поиска исполнителя.

Я бы выделил три канала поиска кандидатов на разработку:

Поисковики. Ищем подрядчика через поисковые системы. Сразу попадаем на его сайт и изучаем его предложение, портфолио и т.д.

Биржи. Заходим на биржу фрилансеров типа fl.ru и выкладываем свою концепцию. Исполнители сами пишут вам свои предложения.

Рейтинги. Вы находите рейтинг поставщиков CRM и исходя из него выбираете. Понятно, что выбирая поставщика с высоким местом в рейтинге, вы имеете дело с высоким ценовым сектором.

Более простой способ – опубликовать проект на бирже. Исполнители сами вас найдут.

Важно, чтобы в концепции вы сразу написали о том, кто вам подходит, а кто – нет. Также укажите максимально конкретно, какую информацию и в каком виде вы хотите получить от кандидата.

После того как вы получите 3-10 предложений от подходящих кандидатов, вам предстоит выбрать из них одного. Хотя в некоторых случаях, если ваш бюджет позволяет, вы можете начать работу над ТЗ параллельно несколькими кандидатами. Через некоторое время будет понятно с кем проще и продуктивнее работать. При этом вы никого не обманываете, т.к. другие исполнители получат деньги за проделанную часть работы.

Какие критерии отбора я бы выделил в первую очередь:

➢ Скорость и полнота ответа. Это показывает, насколько заинтересован исполнитель в проекте. Нет заведомо пустых обещаний (например, сделаем и внедрим за 1-2 недели).

➢ Демо и портфолио. Вам необходимо понять какой backend есть у исполнителя. Делал ли он подобные проекты?

➢ Ценовой диапазон и сроки. Насколько их оценки соотносятся с вашей оценкой? Они не должны отличаться более чем в 3 раза.

Какие действия рекомендуется сделать при выборе исполнителей:

– Просмотреть их сайт, портфолио, кейсы, демонстрации.

– Проверить отзывы исполнителя. Свяжитесь с людьми, которые оставили эти отзывы.Поговорите с ними по скайпу, телефону.

– Дают ли они сразу полезную информацию по проекту? Есть ли у них четкий план по созданию вашей CRM?

– Поищите информацию об исполнителе через поисковые системы и социальные сети. Соотносятся найденные данные с тем образом, который строит исполнитель на своем сайте?

Допустим, вы выбрали одного исполнителя и решили с ним работать. Что дальше? Настало время написать ТЗ.

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

Разработка ТЗ для создания CRM на заказ – это довольно большая и объемная работа, которая требует не только фиксации требований заказчика, но и проработки предметной области клиента, предпроектирования некоторых модулей системы, создания тестовой функциональности с учетом специфики процессов.

Отнеситесь к написанию ТЗ с полной серьезностью. От качества ТЗ в дальнейшем зависит качество реализации системы. К тому же ТЗ может служить прототипом для будущей документации по системе.

Что же должно включать полноценное ТЗ?

➢ Структуру будущего продукта. Для CRM – это состав кабинетов пользователей и их функционала (страниц). Структура – это исходный элемент для всех остальных работ по ТЗ.

➢ Макеты и текстовое описание всего функционала по структуре. Макеты визуализируют ТЗ. Это снижает риски недопонимания между заказчиком и исполнителем Чаще всего исполнители тяготеют к техническому языку, а заказчики – к бизнес-целям. Макеты позволяют общаться на одном языке – все видят один и тот же интерфейс и общаются не на абстрактном уровне, а на уровне кнопок, таблиц, меню и т.д.

➢ Требования по интеграции. Если система связана с внешними ресурсами, то вы должны прописать, как именно система будет взаимодействовать с ними и в каком объеме. Например, интеграция с 1С. Не пишите в ТЗ «Сделать интеграцию с 1С» – 1С содержит сотни таблиц в базе данных. Очень трудоемко сделать интеграцию всех объектов 1С с приложением, да вам это и не нужно в большинстве случаев. Лучше указать, какие именно объекты надо синхронизировать с приложением (клиенты, заказы, единицы измерения, товары и т.д.). Указывайте также предпочтительный способ реализации (например, через веб-сервисы) – это позволит избежать недоразумений на стадии разработки.

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

➢ Особые требования. Сюда можно отнести требования по производительности (хотя в некоторых случаях это сложно спрогнозировать, т.к. приложение работает не изолированно, а в некоторой среде), требования к браузерам, требования по дизайну и др.

➢ При составлении требований указывайте список браузеров и их версии, для которых должно работать приложение. Некоторые версии (например, IE8) не поддерживают такие порталы как ВКонтакте.

➢ Если говорить о дизайне CRM, то главная его задача – это не мешать пользователю. На мой взгляд, здесь не нужно придумывать велосипед – можно взять готовый шаблон и использовать его.

➢ Проработка «узких мест». Если в вашем проекте есть сложные механизмы, то лучше их проработать на этапе ТЗ. Это снижает риски проекта. В случае если не найдется приемлемого решения, то лучше изменить что-то на этапе ТЗ, а не на этапе разработки системы. Почему? Это дешевле. Раньше обнаружена ошибка – дешевле ее исправить. Самые дорогие ошибки – на этапе эксплуатации. Пример: автоматическая генерация пароля. В начале проекта вы сделали так, что пароль генерируется слишком простой. Сейчас изменить это несложно. Теперь представьте, что у вас система запущена, и в ней работают 100 пользователей. Будет довольно непросто сменить всем пароли (поменять данные в базе, оповестить пользователей, часть пользователей не поймет что произошло и у вас появятся дополнительные расходы на техподдержку).

Как лучше всего организовать процесс написания ТЗ?

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

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

На мой взгляд, наиболее предпочтительна следующая схема взаимодействия: исполнитель и заказчик работают совместно над ТЗ (например, через сессии по скайпу). Причем исполнитель руководит этим процессом, а заказчик выступает в роли источника знаний о системе. Иными словами, исполнитель спрашивает, а заказчик отвечает. Только исполнитель фиксирует изменения ТЗ. Заказчик периодически анализирует ТЗ. Все понятно? Ничего не упущено? Надо что-то дополнить?

Используя такой подход, мы достигаем того, что обе стороны держат под контролем содержимое и форму ТЗ.

Также стоит упомянуть о случаях, когда очень трудоемко написать ТЗ сразу. Система настолько сложна и быстро меняется, что нет смысла писать сразу большое ТЗ. В этом случае необходимо определить область действия ТЗ. Делайте ТЗ только на конкретную часть системы, например, на блок «База клиентов» или процесс «Обработка заказа от клиента».

При этом желательно иметь план внедрения модулей системы. Например, в этом году мы внедрим модули 1-5, а в следующем – 6-9 модули.

Из опыта вспоминаются ситуации, когда некоторые заказчики хотят выполнить очень большой проект за один этап, например, реализовать аналог Avito.ru. Желание заказчика понятно – он хочет избежать риска получить часть продукта, ведь ему нужен целостный продукт. Сам не понимая того, он движет проект к катастрофе, т.к. подобные проекты невозможно сделать одним куском за один раз. Здесь действует цикл «задумка – реализация – получение обратной связи – анализ». Вспомните, Windows не сразу стал тем, что он есть сейчас.

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

Очень важный момент. Обе эти ситуации порождает заказчик, а не исполнитель! Именно заказчик определяет стиль стратегического управления продуктом. Исполнителю остается только разве что пожимать плечами и подчиниться пожеланию заказчика. Если у вас большой проект, то имейте стратегический план его развития и не пишите большое ТЗ сразу на всю систему.

Итак, вы нашли исполнителя, написали совместно с ним ТЗ. Пора приступать к разработке CRM. В следующей главе мы рассмотрим, как управлять проектом со стороны заказчика, какие бывают подводные камни и как построить взаимодействие с командой разработки.

Глава 4. Реализация проекта и внедрение системы

Итак, начинаем проект по созданию CRM-системы. Что нужно сделать в первую очередь? Заключить договор. Заключение договора более предпочтительный способ, чем другие.

Работа по безопасной сделке, например, через fl.ru подразумевает использование третьей стороны в качестве арбитража между вами и исполнителем. Тем самым вы предоставляте доступ к своим коммерческим данным третьей стороне. На мой взгляд, подобные сервисы – это некоторый компромисс между официальными договорами и работой без договора.

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

Что прописывать в договоре? В первую очередь – это права на систему, сроки, бюджет и порядок приемки. Обычно такой договор составляется подрядчиком (скорее всего, у него есть типовой договор). Внимательно читайте эти пункты, особенно порядок приемки.

По цене и срокам. Если разработка системы делится на несколько этапов, то бессмысленно писать сроки и стоимость в основном договоре, т.к. ни одна из сторон не может дать точной оценки сроков и бюджета проекта. Это будет лишь вносить элемент неопределенности и нервотрепки в ваши взаимоотношения с исполнителем. Лучше писать стоимость по каждому этапу в очередном дополнительном соглашении к договору.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем хотелось бы, чтобы проекты выполнялись четко, быстро, качественно и полном объеме. Но в любом проекте бывают различные проблемы.

Как владельцу проекта вам следует помнить о параметрах проекта: стоимость, сроки, качество, объем работ.

При возникновении проблемы по одному из параметров, вы можете изменять другие и тем самым влиять на проект, чтобы довести его до конечного состояния,

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

Не зная о параметрах проекта, очень просто впасть в состояние «Хочу сделать CRM очень качественную, за 50 тыс руб, желательно за 1-2 недели и при этом одна должна содержать все функции 1С». Самое печальное – это не шутка, такие проекты (чаще социальные сети и доски объявлений) встречаются на биржах .

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

Общение – важная часть взаимодействия. Не скатывайтесь полностью на переписку. Да, в некотором смысле она удобнее, но отсутствие живого контакта влияет на понимание между сторонами. Бывает, что заказчик «садится на уши» исполнителю и перегружает его несущественной информацией. Это заставляет исполнителя избегать заказчика и ограничивать с ним общение.

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

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

Мое мнение – это часто бывает потерей времени. Обычно цель такой встречи – получить ощущение, что исполнитель – реальный человек и, в некоторых случаях, «прощупать» его в плане адекватности и подтвердить, что он не кинет заказчика. Но проблема в том, что именно «кидала» больше готов к подобным встречам, чем команда технарей-разработчиков.

Есть ли информация, которую вы можете получить только при личной встрече и не можете получить при конференц-связи по скайпу?

Используйте личную встречу, если вы точно знаете, что она может вам дать и у вас есть некая методика получения этого.

Теперь давайте поговорим о предметной области вашего бизнеса. Очень хорошо, если у вас есть небольшой мануал по вашей предметной области, который раскрывает основные понятия и процессы вашего бизнеса. Будет полезно объяснить разработчикам, зачем нужен тот или иной функционал разрабатываемой CRM.

Без понимания предметной области разработчики будут ваять, сами не зная что. Они будут просто механически делать то, что им скажут. Этот подход чреват ошибками. Разработчик должен хотя бы частично представлять как будет работать заказчик, какие у него будут потребности. Это значительно улучшит качество продукта. При этом, зная потребности конечного клиента, исполнитель сможет предложить лучшие решения реализации в вашей системе.

Мы уже упоминали о макетировании. При ведении проекта старайтесь общаться с командой разработки визуальным языком. Если оказалось, что в ТЗ было описано недостаточно, то рисуйте наброски того, что нужно получить. Если что-то не работает как планировалось, то скиньте исполнителю скрин с комментариями для поправки. Сейчас довольно много хороших программ для создания скриншотов с возможностью вставки текста и стрелки на скриншоте (примеры программ – Яндекс.Диск, clip2net). Также при ошибках лучше указывать URL проблемы и дополнительные данных (пользователь, какая операция выполнялась и когда зафиксирована ошибка).