Руслан Раянов
Как создать свою CRM
Мое мнение – это часто бывает потерей времени. Обычно цель такой встречи – получить ощущение, что исполнитель – реальный человек и, в некоторых случаях, «прощупать» его в плане адекватности и подтвердить, что он не кинет заказчика. Но проблема в том, что именно «кидала» больше готов к подобным встречам, чем команда технарей-разработчиков.
Есть ли информация, которую вы можете получить только при личной встрече и не можете получить при конференц-связи по скайпу?
Используйте личную встречу, если вы точно знаете, что она может вам дать и у вас есть некая методика получения этого.
Теперь давайте поговорим о предметной области вашего бизнеса. Очень хорошо, если у вас есть небольшой мануал по вашей предметной области, который раскрывает основные понятия и процессы вашего бизнеса. Будет полезно объяснить разработчикам, зачем нужен тот или иной функционал разрабатываемой CRM.
Без понимания предметной области разработчики будут ваять, сами не зная что. Они будут просто механически делать то, что им скажут. Этот подход чреват ошибками. Разработчик должен хотя бы частично представлять как будет работать заказчик, какие у него будут потребности. Это значительно улучшит качество продукта. При этом, зная потребности конечного клиента, исполнитель сможет предложить лучшие решения реализации в вашей системе.
Мы уже упоминали о макетировании. При ведении проекта старайтесь общаться с командой разработки визуальным языком. Если оказалось, что в ТЗ было описано недостаточно, то рисуйте наброски того, что нужно получить. Если что-то не работает как планировалось, то скиньте исполнителю скрин с комментариями для поправки. Сейчас довольно много хороших программ для создания скриншотов с возможностью вставки текста и стрелки на скриншоте (примеры программ – Яндекс.Диск, clip2net). Также при ошибках лучше указывать URL проблемы и дополнительные данных (пользователь, какая операция выполнялась и когда зафиксирована ошибка).
Теперь о процессе внедрения системы.
На этом этапе система делится на DEV и PROD версию. Первая нужна для тестирования разработчиками, вторая – для промышленной эксплуатации системы. Такое разделение позволяет избежать внесения случайных ошибок при сопровождении системы.
При внедрении системы:
– получите постоянный доступ к исходному коду. Пусть исполнитель настроит для вас такой доступ и даст инструкцию как его использовать. В качестве средства такого доступа может быть FTP (протокол для доступа к файлам) или SVN (средство командной разработки).
– делайте резервное копирование для сохранности ваших данных. При этом данные лучше хранить в удаленном хранилище (т.е. не на сервере, где работает приложение). Делать бекап базы лучше не менее 1 раза в день. Копирование на удаленное хранилище можно делать 1 раз в неделю. В качестве такого хранилища подойдет Dropbox или Яндекс Диск.
– проверяйте работу периодически запускаемых на сервере скриптов (например, скрипт создания бекапов).
– делайте мониторинг доступности веб-приложения. Есть замечательные бесплатные сервисы вроде Uptime Robot.
– проверяйте работу почты и уведомлений. У почты бывают сбои, поэтому обязательно проконтролируйте работу почтовых уведомлений на основной версии приложения.
Перед тем как мы перейдем к следующей главе, хотелось бы рассказать о тех принципах, которыми руководствуются исполнители при разработке программного обеспечения. Я считаю, что если у заказчика есть представление об этих принципах и он ими пользуется при принятии решений по системе, то это значительно улучшает результат.
