Как создать свою CRM
Шрифт:
Важный момент. Не думайте, что вы сделали ТЗ, отдали группе разработки и можно забыть о проекте на пару месяцев. При таком подходе вы не получите нужного вам результата. Контролируйте минимум 1 раз в неделю как идут дела по проекту. При этом изучайте не только отчеты команды разработки, но и смотрите своими глазами тестовое приложение и пробуйте использовать тестовые функции. Тем самым вы сможете вовремя вносить корректировки в процесс развития функционала проекта. Ваша задача – постоянно давать обратную связь по разработанному функционалу.
Следующий важный момент –
Некоторые заказчики определяют все свои задачи важными и необходимыми для реализации. Это управленческий просчет. В проекте может быть много разных рисков (конфликт с исполнителем, проблемы с бюджетированием, выход за сроки, переработка уже сделанного функционала и многое другое). Желательно, чтобы при резком прерывании проекта у вас был минимально необходимый работающий функционал, который можно использовать в работе. Стремитесь к тому, чтобы ваша система уже через месяц работала хотя бы в тестовом режиме.
Документация. Она помогает понять заказчику, правильно ли его понимает исполнитель.
Документацию надо писать сразу. Одна из причин – резкая смена исполнителя. Исполнитель чем-то вас не устраивает или произошел конфликт. Пока у вас нет документации и исходного кода – считайте себя заложником.
Писать документацию проще по горячим следам. Требуйте документацию сразу же после тестирования. Причем требуйте документацию не только для пользователя, но и для программиста. С другой стороны, на оформление документации нужно выделить время. Поэтому не спрашивайте подробно написанных и оформленных документов. Подойдет просто текстовое описание и скриншоты.
Разработчики в первую очередь должны разрабатывать, а не писать документы. Лучше всего возложить оформление документации по использованию системы на тестировщика со своей стороны. Таким образом, вы сможете лучше контролировать процесс, а разработчики при этом будут минимум времени тратить на документацию и ее оформление.
Мелкие и крупные правки. В проекте всегда бывают правки. Написание вами подробного ТЗ не значит, что все будет именно так, как написано в ТЗ. По мере развития проекта вы получаете дополнительную информацию, у вас появляются новые идеи. Возникает желание что-то улучшить. Как быть в этом случае? Если в договоре стоит фиксированная сумма, то вносить большие доработки в приложение без соответствия ТЗ будет некорректным.
При малых правках в большинстве случаев исполнитель идет навстречу заказчику и вносит их в систему.
Если грядут большие перемены, то следует составить новое ТЗ как дополнительное соглашение к договору и изменить план разработки.
Если вы работаете по нефиксированной сумме оплаты, то вы можете сразу менять свои требования к системе. Исполнитель вносит на очередной итерации нововведения по системе.
Старайтесь как можно меньше делать крупных необдуманных изменений в системе. Напишите небольшую концепцию на это изменение и отложите на некоторое время. Если это изменение действительно важно, то вы обязательно вернетесь к нему в будущем.
Всем
Как владельцу проекта вам следует помнить о параметрах проекта: стоимость, сроки, качество, объем работ.
При возникновении проблемы по одному из параметров, вы можете изменять другие и тем самым влиять на проект, чтобы довести его до конечного состояния,
Например, вы не можете закрыть проект в ранее планируемые сроки. В таком случае можно где-то пожертвовать качеством, нанять дополнительно программистов, часть функций убрать.
Не зная о параметрах проекта, очень просто впасть в состояние «Хочу сделать CRM очень качественную, за 50 тыс руб, желательно за 1-2 недели и при этом одна должна содержать все функции 1С». Самое печальное – это не шутка, такие проекты (чаще социальные сети и доски объявлений) встречаются на биржах .
Также важно учитывать человеческий фактор. Нередко проблема именно в личном конфликте участников проекта. Важно знать цели участников проекта. Заказчик должен понимать, что требуется для работы исполнителю. Исполнитель должен понимать, зачем вам нужен проект. Дайте исполнителю всю необходимую информацию и расскажите, для чего вам нужен проект и как вы будете использовать его результаты.
Общение – важная часть взаимодействия. Не скатывайтесь полностью на переписку. Да, в некотором смысле она удобнее, но отсутствие живого контакта влияет на понимание между сторонами. Бывает, что заказчик «садится на уши» исполнителю и перегружает его несущественной информацией. Это заставляет исполнителя избегать заказчика и ограничивать с ним общение.
В нашей практике были разные проекты. Кто-то из заказчиков предпочитал связываться с нами только по электронной почте. А с некоторыми мы на протяжении всего проекта много общались и занимались подготовкой большого количества различных документов. С точки зрения рисков проекта, второй вариант предпочтительнее, но все же надо стремиться к золотой середине.
Также стоит упомянуть о личных встречах. Для людей, привыкших вести бизнес по старой схеме, это является необходимым шагом в ведении проекта.
Мое мнение – это часто бывает потерей времени. Обычно цель такой встречи – получить ощущение, что исполнитель – реальный человек и, в некоторых случаях, «прощупать» его в плане адекватности и подтвердить, что он не кинет заказчика. Но проблема в том, что именно «кидала» больше готов к подобным встречам, чем команда технарей-разработчиков.
Есть ли информация, которую вы можете получить только при личной встрече и не можете получить при конференц-связи по скайпу?
Используйте личную встречу, если вы точно знаете, что она может вам дать и у вас есть некая методика получения этого.
Теперь давайте поговорим о предметной области вашего бизнеса. Очень хорошо, если у вас есть небольшой мануал по вашей предметной области, который раскрывает основные понятия и процессы вашего бизнеса. Будет полезно объяснить разработчикам, зачем нужен тот или иной функционал разрабатываемой CRM.