- -
- 100%
- +
Важный момент. Не думайте, что вы сделали ТЗ, отдали группе разработки и можно забыть о проекте на пару месяцев. При таком подходе вы не получите нужного вам результата. Контролируйте минимум 1 раз в неделю как идут дела по проекту. При этом изучайте не только отчеты команды разработки, но и смотрите своими глазами тестовое приложение и пробуйте использовать тестовые функции. Тем самым вы сможете вовремя вносить корректировки в процесс развития функционала проекта. Ваша задача – постоянно давать обратную связь по разработанному функционалу.
Следующий важный момент – при планировании проекта менеджером вы должны четко обозначить свои приоритеты. Что нужно получить сначала? Что можно сделать уже на поздних этапах. Понимания ваши приоритеты, менеджер проекта сможет транслировать их на команду разработки.
Некоторые заказчики определяют все свои задачи важными и необходимыми для реализации. Это управленческий просчет. В проекте может быть много разных рисков (конфликт с исполнителем, проблемы с бюджетированием, выход за сроки, переработка уже сделанного функционала и многое другое). Желательно, чтобы при резком прерывании проекта у вас был минимально необходимый работающий функционал, который можно использовать в работе. Стремитесь к тому, чтобы ваша система уже через месяц работала хотя бы в тестовом режиме.
Документация. Она помогает понять заказчику, правильно ли его понимает исполнитель.
Документацию надо писать сразу. Одна из причин – резкая смена исполнителя. Исполнитель чем-то вас не устраивает или произошел конфликт. Пока у вас нет документации и исходного кода – считайте себя заложником.
Писать документацию проще по горячим следам. Требуйте документацию сразу же после тестирования. Причем требуйте документацию не только для пользователя, но и для программиста. С другой стороны, на оформление документации нужно выделить время. Поэтому не спрашивайте подробно написанных и оформленных документов. Подойдет просто текстовое описание и скриншоты.
Разработчики в первую очередь должны разрабатывать, а не писать документы. Лучше всего возложить оформление документации по использованию системы на тестировщика со своей стороны. Таким образом, вы сможете лучше контролировать процесс, а разработчики при этом будут минимум времени тратить на документацию и ее оформление.
Мелкие и крупные правки. В проекте всегда бывают правки. Написание вами подробного ТЗ не значит, что все будет именно так, как написано в ТЗ. По мере развития проекта вы получаете дополнительную информацию, у вас появляются новые идеи. Возникает желание что-то улучшить. Как быть в этом случае? Если в договоре стоит фиксированная сумма, то вносить большие доработки в приложение без соответствия ТЗ будет некорректным.
При малых правках в большинстве случаев исполнитель идет навстречу заказчику и вносит их в систему.
Если грядут большие перемены, то следует составить новое ТЗ как дополнительное соглашение к договору и изменить план разработки.
Если вы работаете по нефиксированной сумме оплаты, то вы можете сразу менять свои требования к системе. Исполнитель вносит на очередной итерации нововведения по системе.
Старайтесь как можно меньше делать крупных необдуманных изменений в системе. Напишите небольшую концепцию на это изменение и отложите на некоторое время. Если это изменение действительно важно, то вы обязательно вернетесь к нему в будущем.
Всем хотелось бы, чтобы проекты выполнялись четко, быстро, качественно и полном объеме. Но в любом проекте бывают различные проблемы.
Как владельцу проекта вам следует помнить о параметрах проекта: стоимость, сроки, качество, объем работ.
При возникновении проблемы по одному из параметров, вы можете изменять другие и тем самым влиять на проект, чтобы довести его до конечного состояния,
Например, вы не можете закрыть проект в ранее планируемые сроки. В таком случае можно где-то пожертвовать качеством, нанять дополнительно программистов, часть функций убрать.
Не зная о параметрах проекта, очень просто впасть в состояние «Хочу сделать CRM очень качественную, за 50 тыс руб, желательно за 1-2 недели и при этом одна должна содержать все функции 1С». Самое печальное – это не шутка, такие проекты (чаще социальные сети и доски объявлений) встречаются на биржах .
Также важно учитывать человеческий фактор. Нередко проблема именно в личном конфликте участников проекта. Важно знать цели участников проекта. Заказчик должен понимать, что требуется для работы исполнителю. Исполнитель должен понимать, зачем вам нужен проект. Дайте исполнителю всю необходимую информацию и расскажите, для чего вам нужен проект и как вы будете использовать его результаты.
Общение – важная часть взаимодействия. Не скатывайтесь полностью на переписку. Да, в некотором смысле она удобнее, но отсутствие живого контакта влияет на понимание между сторонами. Бывает, что заказчик «садится на уши» исполнителю и перегружает его несущественной информацией. Это заставляет исполнителя избегать заказчика и ограничивать с ним общение.
В нашей практике были разные проекты. Кто-то из заказчиков предпочитал связываться с нами только по электронной почте. А с некоторыми мы на протяжении всего проекта много общались и занимались подготовкой большого количества различных документов. С точки зрения рисков проекта, второй вариант предпочтительнее, но все же надо стремиться к золотой середине.
Также стоит упомянуть о личных встречах. Для людей, привыкших вести бизнес по старой схеме, это является необходимым шагом в ведении проекта.
Мое мнение – это часто бывает потерей времени. Обычно цель такой встречи – получить ощущение, что исполнитель – реальный человек и, в некоторых случаях, «прощупать» его в плане адекватности и подтвердить, что он не кинет заказчика. Но проблема в том, что именно «кидала» больше готов к подобным встречам, чем команда технарей-разработчиков.
Есть ли информация, которую вы можете получить только при личной встрече и не можете получить при конференц-связи по скайпу?
Используйте личную встречу, если вы точно знаете, что она может вам дать и у вас есть некая методика получения этого.
Теперь давайте поговорим о предметной области вашего бизнеса. Очень хорошо, если у вас есть небольшой мануал по вашей предметной области, который раскрывает основные понятия и процессы вашего бизнеса. Будет полезно объяснить разработчикам, зачем нужен тот или иной функционал разрабатываемой CRM.
Без понимания предметной области разработчики будут ваять, сами не зная что. Они будут просто механически делать то, что им скажут. Этот подход чреват ошибками. Разработчик должен хотя бы частично представлять как будет работать заказчик, какие у него будут потребности. Это значительно улучшит качество продукта. При этом, зная потребности конечного клиента, исполнитель сможет предложить лучшие решения реализации в вашей системе.
Мы уже упоминали о макетировании. При ведении проекта старайтесь общаться с командой разработки визуальным языком. Если оказалось, что в ТЗ было описано недостаточно, то рисуйте наброски того, что нужно получить. Если что-то не работает как планировалось, то скиньте исполнителю скрин с комментариями для поправки. Сейчас довольно много хороших программ для создания скриншотов с возможностью вставки текста и стрелки на скриншоте (примеры программ – Яндекс.Диск, clip2net). Также при ошибках лучше указывать URL проблемы и дополнительные данных (пользователь, какая операция выполнялась и когда зафиксирована ошибка).
Теперь о процессе внедрения системы.
На этом этапе система делится на DEV и PROD версию. Первая нужна для тестирования разработчиками, вторая – для промышленной эксплуатации системы. Такое разделение позволяет избежать внесения случайных ошибок при сопровождении системы.
При внедрении системы:
– получите постоянный доступ к исходному коду. Пусть исполнитель настроит для вас такой доступ и даст инструкцию как его использовать. В качестве средства такого доступа может быть FTP (протокол для доступа к файлам) или SVN (средство командной разработки).
– делайте резервное копирование для сохранности ваших данных. При этом данные лучше хранить в удаленном хранилище (т.е. не на сервере, где работает приложение). Делать бекап базы лучше не менее 1 раза в день. Копирование на удаленное хранилище можно делать 1 раз в неделю. В качестве такого хранилища подойдет Dropbox или Яндекс Диск.
– проверяйте работу периодически запускаемых на сервере скриптов (например, скрипт создания бекапов).
– делайте мониторинг доступности веб-приложения. Есть замечательные бесплатные сервисы вроде Uptime Robot.
– проверяйте работу почты и уведомлений. У почты бывают сбои, поэтому обязательно проконтролируйте работу почтовых уведомлений на основной версии приложения.
Перед тем как мы перейдем к следующей главе, хотелось бы рассказать о тех принципах, которыми руководствуются исполнители при разработке программного обеспечения. Я считаю, что если у заказчика есть представление об этих принципах и он ими пользуется при принятии решений по системе, то это значительно улучшает результат.
Принципы разработки программного обеспечения:
– Простота – это хорошо. Стремитесь выбирать простые решения.
– Декомпозиция. Сложное раскладывайте на простое.
– Быстрая обратная связь. Сделайте быстро функционал, получите обратную связь и доработайте его на основании этой обратный связи. Лучше короткие шаги, чем затяжной прыжок.
– Код важнее документации.
– Нет ничего постоянного. Делайте так, чтобы потом было просто менять.
– Главный ориентир – это цели клиента на проект. Помните, зачем вам нужен проект.
– Ничего лишнего. Сравните свой проект с самолетом. Убирайте все лишнее, что не дает пользу проекту.
В следующей главе мы поговорим об этапе сопровождения проекта. После ввода в эксплуатацию проект на самом не деле не заканчивается, а только начинает свое движение в реальной среде. Мы поговорим о развитии функционала проекта, получении обратной связи от пользователей системы.
Глава 5. Сопровождение и развитие CRM
Вы ввели свою CRM-систему в эксплуатацию. Пользователи начали в ней работать. Проект по внедрению закончен.
Наступает этап сопровождения системы, который состоит из следующих действий:
➢ Разработка новых функций и модулей системы.
➢ Повышение удобства работы с системой.
➢ Обслуживание системы.
➢ Анализ работы системы.
Рассмотрим их более подробно.
Разработка новых модулей подразумевает развитие системы с помощью команды разработки. Хорошо, если компания-разработчик поддерживает продукт на этом этапе. Если нет – не беда при наличии проработанной документации.
При разработке новой функциональности помните, что вы должны критически подходить к каждой новой функции: действительно ли она так необходима? Как она соотносится общими планами на развитие продукта?Проработав эти вопросы, вы в итоге получите более сбалансированную систему.
Откуда появляются доработки по системе?
Во-первых, это пожелания пользователей и потребности бизнеса. Процессы не стоят на месте, они развиваются, следовательно, должна меняться и ваша система.
Во-вторых, вы можете автоматизировать те бизнес-процессы, которые ваша система ранее не охватывала. Например, сначала вы автоматизировали процесс продажи, затем вам захотелось упростить работу HR отдела, чуть позже – внедрить систему мотивации на основе показателей, вычисляемых из данных, хранящихся в системе.
В-третьих, это может быть исправление ошибок. Не бывает идеального софта. И чем сложнее софт, тем больше он подвержен ошибкам. Ошибки в любом случае будут всплывать по ходу работы системы. И их надо оперативно исправлять.
Повышение удобства работы с системой подразумевает тесное общение с пользователями системы. Если с системой неудобно работать, то это может привести к следующим последствиям:
– возникновение ошибок пользователей;
– замедление бизнес-процессов;
– искажение метрик по процессам;
– репутационные риски, если к вашей системе есть доступ у клиента;
– тихий бунт сотрудников против системы. Они будут вести работу по старинке, а в систему будут добавлять фиктивные данные (для руководства).
Простейшими средствами повышения удобства пользования системой можно считать:
– Скорость работы программы
– «Защита от дурака»
– Возможность отменить некоторые операции
– Минимум кликов и переходов до цели
– Отображение статусов любой операции
– Приятный дизайн
– Четкий фокус на конкретной операции
Попробуйте сами поработать от каждой роли и, вероятнее всего, у вас уже появится список возможных доработок по системе.
Слушайте своих пользователей – они могут дать ценную информацию как улучшить процесс работы с системой.
Обслуживание системы включает в себя следующие работы:
– Оказание технической поддержки пользователей. В процессе работы у пользователей возникают вопросы по работе с системой. Важно оперативно решать такие вопросы. Техническую поддержку обычно оказывают разработчики, сопровождающие проект. Конечно, это не сами разработчики продукта, но это те лица, которые специализируются на решении вопросов по конкретному продукту.
– Обучение пользователей. Новых пользователей необходимо обучать. Если система сложная, то можно и не обойтись только чтением текстовой документации. Поэтому проводятся семинары по изучению продукта.
– Обслуживание сервера. Эта задача ложится на системного администратора. Основные задачи, которые решает системный администратор (или «сисадмин») это:
– Обслуживание и проверка бекапов
– Мониторинг ресурсов сервера
– Мониторинг доступности приложения
– Профилактические работы на сервере
– Если есть внешние системы, то необходимо оплачивать их услуги. Например, это могут быть СМС агрегаторы, продление домена или аренды сервера и т.д. Рекомендую занести важные события в Google Calendar и настроить уведомления для самых критичных событий на телефон.
– Периодическая проверка работы форм на сайте, общего тестирования, работы рассылок. Рекомендуется хотя бы 1 раз в 2 недели проводить такие работы, потому что при взаимодействии с внешними системами случаются различные сбои.
И, наконец, анализ работы системы. Вы анализируете действия пользователей с целью понять как они используют ваш функционал. Возможно, они выполняют свои задачи не так как вы предполагали или какие-то функции игнорируют из-за того, что не знают о них или им просто неудобно с ними работать.
Какие средства использовать для анализа?
Можно просто понаблюдать за работой операторов. Попросите их выполнить простые типовые задачи и оцените насколько хорошо они владеют системой.
Другой вариант – это использование веб-аналитики. Вы ставите специальный код в веб-приложение и отслеживаете действия пользователей в системе. Для этого можно использовать средства общего назначения такие как Яндекс Метрика или Google Analytics, либо использовать встроенные в CRM средства отслеживания действий пользователя.
Как вы понимаете, после ввода в эксплуатацию все только начинается, и именно здесь проявляются основные достоинства выбранного способа – создания CRM под свои требования. Вы можете ее развивать как вам угодно, при этом вы полностью контролируете ход ее совершенствования. С развитием вашего бизнеса, ваша система развивается параллельно, что служит хорошим фундаментом для дальнейшего роста бизнеса.
Заключение
Вот мы и подошли к концу этого небольшого руководства. Если вы не начали свой проект по ходу чтения этой книги, предлагаю вам приступить к написанию концепции вашего проекта.
Мы подготовили небольшой бриф, чтобы упростить задачу составления концепции.
Вы можете найти бриф по адресу (в формате Excel) либо взять из приложения 2 к данной книге.
Остались вопросы по материалу? Задавайте свои вопросы на нашем сайте (http://web-automation.ru) или через профиль в социальной сети (http://vk.com/hecrus). Также вы можете присылать свои концепции для получения обратной связи.
Последнее –Если вам понравилась книга – напишите пожалуйста отзыв http://web-automation.ru/book/how-create-crm/. Ну а если очень понравилась – то сделайте пожалуйста пост в социальной сети с ссылкой на книгу – книга бесплатная и мы не продвигаем ее через какие-то рекламные площадки. Поэтому ваш пост очень поможет доставить эту книгу тем, кому она действительно нужна.
Всего доброго и удачных вам проектов!
Приложение 1. Основные термины и понятия в веб-разработке.
Доступно по адресу www.web-automation.ru/glossary/. Для удобства Вы можете сохранить отдельно этот список (либо на диск, либо в социальной сети).http://www.web-automation.ru/books/glossary/
Авторизация – процесс входа пользователя на сайт (для гурманов – процесс проверки прав на выполнение определенного действия).
Архитектура – документ, определяющий структуру и организацию вашей системы.
База данных – место где хранятся данные веб-приложения (сайта).
Бекап, резервная копия – копия вашей базы данных или приложения. Делается для того, чтобы снизить риски потери важных данных.
Бизнес-процесс – последовательность действий, направленных на определенный результат. Имеет следующий параметры: действия, участники, ресурсы, цель и результат, триггер.
Биржа – сайт, на котором могут встретиться Заказчики и Исполнители.
Браузер – программа, с помощью которой просматривают страницы в интернете.
Бриф – краткая анкета для получения первичной информации по проекту.
Веб-приложение – программа работающая в браузере.
Веб-сервер – сервер, который обрабатывает запросы вашего веб-приложения.
Веб-сервис – веб-приложение, предназначенное для обработки специфических программных запросов. Например, это может быть программное извлечение данных из 1С.
Веб-аналитика – инструмент для изучения поведения пользователей на сайте.
Верстка – способ организации страницы сайта.
Воронка продаж – визуальное распределение базы клиентов по статусам (заявки, лиды, горячие лиды, клиенты).
Дизайн – средство для правильной подачи информации.
Интерфейс – совокупность возможностей, элементов управления и графеских элементов для пользователя или роли. Интерфейс – это способ взаимодействия пользователя с системой.
Конверсия – процент посетителей, достигших определенной цели на сайте к общему числу посетителей. Целью может быть заполнение формы, щелчок на кнопке или переход на определенную страницу.
Контрагент – лицо (или компания), с которой взаимодействует ваша компания.
Контент – текстовое или визуальное содержание вашего сайта.
Концепция – совокупность основных данных по вашей системе (система взглядов на систему).
Логин – идентификатор человека в системе.
Личный кабинет – совокупность страниц, предназначенных для определенной роли в системе. Закрытый раздел сайта.
Макетирование, макет – графическое отображение некоторого объекта (страницы) для более простого его понимания.
Платежный шлюз – система, позволяющая принимать платежи через различные каналы связи (Яндекс Деньги, Веб-мани, Карты, SMS и др.)
Проектирование – процесс решения, как именно внутри будет работать ваша система.
Прототип – частично работающий продукт, направленный на проработку некоторой задачи.
Пользователь – зарегистрированный член вашей системы, имеющий свой логин и пароль.
Рассылка – часть системы, предназначенная для массовой отправки пользователям системы некоторых сообщений по СМС или email.
Роль – совокупность пользователей, имеющих сходный интерфейс работы в системе. У каждой роли есть свои функции и права в системе. Примеры: продавец, оператор, администратор, контролер.
Сайт – программа, которая позволяет отображать информацию в интернете и обрабатывать различные данные.
Синхронизация – процесс обновления данных в двух источниках данных (базах данных) с целью передачи данных из одного в другой.
Скриншот – снимок экрана. Делается при помощи клавиши Print Screen либо с помощью специализированных программ (Яндекс.Диск, clip2net и др.)
ТЗ (Техническое задание) – документ, закрепляющий требования на разработку продукта.
Тонкий клиент – это по сути браузер. Т.е. это программа, которая отправляет запросы на сервер и выводит данные пользователю. На компьютере не надо ничего лишнего ставить, чтобы работала такая система. Именно поэтому такой клиент называется тонким.
Толстый клиент – в отличии от тонкого клиента, для работы пользователя нужно уставить программу на компьютер.
Функционал – перечень функций определенной страницы или модуля.
Хостинг – место на диске, хостинг компании. Это место используется для хранения вашего веб приложения. Является упрощенным вариантом размещения вашего веб приложения.
Юзабилити – область знаний об удобстве использования сайтом.
1С – ERP система, включающая в себя большой комплекс различного функционала (Бухгалтерия, склад и др.)
API – программный интерфейс некоторой системы. Используется для взаимодействия с другими системами через программный код.
ASP.NET – средство для разработки веб-приложений.
arkAS – платформа для разработки веб-приложений, ориентированную на бизнес-среду. Разработана на ASP.NET.
Bootstrap – технология для визуального отображения содержания вашего сайта.
CMS – система управления контентом. Позволяет создавать и редактировать содержимое вашего сайта, не применяя навыки программирования или верстки.
CRM – система по работе к клиентами (в узком смысле).
DEV версия – тестовая версия продукта. Предназначена для тестирования и разработки продукта.
HTML разметка – тело страницы, которая отображается в браузере.
Internet Information Service – веб-сервер от Microsoft.
jQuery – средство для создания интерактивного интерфейса веб-приложения.
Prod версия – основная версия продукта. Предназначена для использования конечными клиентами системы.
SMS агрегатор – платный сервис, позволяющий отправлять СМС.
SQL Server – Система управления базами данных. Разработчик – компания Microsoft.
SSL (HTTPS) – защищенный протокол доступа к секретной информации, обычно используется для доступа к личному кабинету пользователя в системе.
VPS – сервер, на котором работает ваше приложение. Обычно это Windows или Linux. ASP.NET работает только на Windows Server.
Приложение 2. Бриф на создание концепции проекта
Название проекта
Концепция
Суть проекта
Кабинеты (роли) и их функции
Роль 1
Функция 1
Функция 2
Функция 3
Роль 2
Функция 1
Функция 2
Функция 3
Технологии
База данных
Сервер
Язык программирования и платформа
Сроки
Бюджет
Приоритеты
Требования к исполнителю