Почему мы используем другой подход к автоматизации?

Как происходит автоматизация?

1. Заказчиком формулируются ключевые требования к учетной системе.
   
2. После консультаций с нашим руководителем проектов, выбирается типовая конфигурация, которая максимально соответствует ключевым требованиям.
   
3. Заказчик работает на установленной конфигурации и формулирует требования по доработке текущей конфигурации и сообщает его руководителю проекта.
   
4. Требования заказчика трансформируются руководителем проекта в короткие задачи, которые выполняются сотрудниками параллельно.
   
5. Решенные задачи руководителем проекта проверяются на соответствие условий и внедряются у заказчика. Заказчик, работая на измененной конфигурации, может сообщить два решения, либо работа по автоматизации требований выполнена, либо сообщить «мотивированный отказ». В последнем случае, автоматизация возвращается на 4 шаг.
   
6. Операции 3-5 происходят часто и регулярно (1-2 недели) до тех пор пока все требования заказчика не будут удовлетворены.
   

Что такое RMS и зачем она нужна?

RMS (Requirements Management System) - система управления требованиями, это многопользовательская и мультизадачная технология реализации внедренческих услуг клиентам средствами рабочей силы удаленных сотрудников. Главная парадигма RMS: появилось требование клиента, оно должно быть удовлетворено. Ключевые особенности:

• Параллельная разработка: При работе над учетной системой требования заказчика трансформируются на множество небольших независимых задач, которые могут выполнять наши сотрудники параллельно. Скорость создания рабочей учетной системы возрастает многократно, а риск, что требование не будет удовлетворено, уменьшается, поскольку каждый сотрудник выполняет решение своей небольшой задачи, которая не зависит от результатов других сотрудников. Кроме того, работа в RMS организована таким образом, что как только изменение фиксировано одним из сотрудников, оно становится доступно другим сотрудникам и заказчику. В результате, снято ограничение на количество специалистов, которые могут участвовать в разработке одной учетной системы. Чем больше требований в единицу времени попадает в RMS, тем больше специалистов включается в работу параллельно. Такой подход позволяет заказчику экономить значительную часть времени и средств, уделяя больше времени для управления качеством через «мотивированный отказ».
• Работа 24 часа в сутки: Вам может показаться это не правдоподобным, но это так. Благодаря привлечению удаленных сотрудников, проживающих в различных часовых поясах, география которых простирается от Владивостока до Киева, работа над учетной системой не прекращается ни на минуту, как будто в офисе заказчика постоянно присутствует высококвалифицированный специалист в отдельном кабинете, но способный выполнять множество задач одновременно.
• Контроль работ он-лайн: Заказчик в любой момент дня и ночи, может зайти он-лайн в RMS, проверить в каком состоянии находится разработка учетной системы, проверить, сколько денежных средств было потрачено и на что именно.
• Защита информации: При тестировании своих решений мы можем использовать ваши данные, ТОЛЬКО если наш сотрудник приедет к вам в офис, в других случаях ваша коммерческая информация никогда не выйдет за пределы вашего офиса.
• Минимальные трудозатраты на коммуникацию: Для пользы всего проекта, не важно, что формулировка требования заказчика в RMS может быть плоха, важно, чтобы требование или вопрос попал в RMS (web-интерфейс, e-mail, icq или по телефону).
• Итеративное внедрение: В RMS существует понятие «недельная итерация», при работе с сотрудниками в RMS существует понятие «ежедневный коммит». «Недельная итерация», как правило, это встреча с представителем заказчика с установкой измененной учетной системы в информационную базу заказчика. Каждая недельная итерация является результатом множества «ежедневных коммитов». «Ежедневный коммит» - это результат изменения объектов конфигурации, выполненный отдельным сотрудником, согласно требований в RMS. За счет ежедневного фиксирования изменений по задачам, включая промежуточные результаты, осуществляется снижение риска невыполнения проекта в целом. Отклонения от нормального хода работ становятся заметны на самых ранних стадиях, когда еще достаточно возможностей для устранения отклонений.
• Итерационное планирование: В RMS существует «Календарь», в котором наглядно представлено, в какие дни, какие задачи должны быть решены. Сроки решения - это компромисс между потребностью заказчика и возможностями сотрудников исполнителя. Возможности сотрудников исполнителя определяются в открытом среди сотрудников конкурсе концепций, сроков и времени.
• Разработка требований и использование похожих решений: Область процессов «Управление требованиями» подразумевает, что организация-разработчик получила требования от заказчика, а область процессов «Разработка требований» — что организации-разработчику известны потребности заказчика, но эти потребности должны быть трансформированы в требования. За несколько лет работы, в RMS накоплено множество решений. Статистика показывает, что подавляющее большинство потребностей заказчиков, в общем, схожи. Отличия, лишь, в деталях реализации. Кроме того, к опыту решенных задач в RMS прибавляется опыт решенных задач всех участников проекта. В результате, заказчику достаточно, лишь, сообщить в RMS о потребности, кратко сформулировав суть потребности, требование к решению создается в RMS руководителем проектов. Когда в относительно короткий срок заказчик получает готовое решение, ему достаточно сообщить, какие детали в готовом решении работают против его ожиданий (мотивированный отказ). Этот «мотивированный отказ» является мощным инструментом заказчика в управлении качеством оказываемой исполнителем услуги.

Сколько это стоит?

Что нужно сделать, чтобы получить готовое решение, удовлетворяющее ваши требования?

• Бесплатно зарегистрироваться в Системе управления требованиями (RMS) в качестве заказчика.
  
• Ответить на дополнительные вопросы Управляющего. Управляющий назначит роль Контактного лица контрагента.
  
• Договориться с Управляющим, каким способом вы сможете передать файл конфигурации, в которую необходимо будет внести изменения, согласно вашим требованиям. Следует, также, сообщить, будете ли пользоваться CVS для оперативного получения изменений.
  
• Сформулировать в RMS требование или несколько требований, которые, как вы считаете, можно реализовать за неделю. Для формулировки требований достаточно пользоваться обычной терминологией предметной области.
  
• Получить из нашего CVS готовое решение, произвести оплату за сделанную работу, либо мотивировать отказ от оплаты.

Термины

Техническое задание - исходный документ для проектирования учетной системы, содержит технико-экономическое обоснование разработки, основные технические требования, предъявляемые к учетной системе, и исходные данные для разработки; в ТЗ указываются стадии разработки документации.

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

Руководитель проекта - Сотрудник компании ООО «Белов и партнеры», преобразующий требования заказчиков к учетной системе в требования для других сотрудников, контролирующий и отвечающий за сроки и качество выполняемых работ

Решенная задача -Изменения в конфигурации учетной системы или в ее внешних объектах, а так же, выполненные работы по тестированию, документированию, консультированию, произведенные согласно требованиям руководителя проекта или непосредственно Заказчика и оформленные в виде отчета о проделанной работе в RMS.

Мотивированный отказ - Требование заказчика, сформулированное в виде отчета:

1. Какие действия выполняются
2. Что ожидается получить в результате
3. Что получается фактически
4. В чем не соответствие ожиданий

Управляющий - Сотрудник компании ООО «Белов и партнеры», несущий ответственность перед заказчиком за сроки и качество выполненных работ, в компетенции которого находятся все вопросы коммуникаций, в том числе финансовые

CVS - Concurrent Version System. Система, позволяющая хранить версии файлов, историю изменений версий, выдавать по запросу хранимые версии и/или результаты их слияния

Коммит (commit) - процесс фиксирования изменений в репозиторий системы управления версиями.