Внедрение типовых конфигураций с тонкой настройкой под заказчика

08.12.15

Бизнес-анализ

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

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

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

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

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

С помощью баг-трекера вам не удастся получить ответы на основные вопросы об эффективности вашей команды:

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

Выстраивание процесса

Вряд ли существует универсальный рецепт эффективного процесса разработки, но точно есть путь, как такой процесс выстроить именно в вашей команде или организации. Этот путь называется Kanban и состоит он из нескольких простых шагов.

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

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

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

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

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

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

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

Индивидуальные проектные артефакты

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

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

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

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

kanban канбан требования внедрение кастомизация

См. также

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

Методики быстрореагирующего производства и QRM-ячейки применимы не только к станкам, но и к проектным командам. О том, как за счет разделения проектного офиса на многофункциональные QRM-ячейки обеспечить равномерную загрузку работу сотрудников, вырасти в два раза и существенно повысить лояльность заказчиков и коллектива, пойдет речь в статье.

14.02.2024    556    0    user1270271    2    

7

Управление ожиданиями на проекте

Работа с заинтересованными сторонами Бесплатно (free)

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

08.02.2024    452    0    izybaevda    0    

5

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    6698    0    user1578851    16    

16

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

Внедрение изменений Бесплатно (free)

Переход на свободное программное обеспечение – серьезное испытание и для бизнес-пользователей, и для ИТ-подразделения. Нужно учесть много факторов, найти компромиссы и поменять привычки. О «пяти стадиях принятия неизбежного» и успешном преодолении трудностей при переводе ИТ-инфраструктуры автодилерских центров на Linux расскажем в статье.

29.01.2024    2417    0    user1063453    2    

5

Зачем нужны аналитики на проектах автоматизации

Анализ потребностей и поиск решений Бесплатно (free)

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

18.01.2024    1590    0    user1754524    19    

12

Радио "Аналитик", 7 выпуск 2 сезона. Про работу аналитика с бизнесом и повышение бизнес-компетенций с Константином Семёновым

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений

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

28.11.2023    414    0    Radio_Analyst    0    

2

Радио "Аналитик", 4 выпуск 2 сезона. Про решение проблем с Анастасией Московкиной

Анализ потребностей и поиск решений

В четвертом выпуске второго сезона подкаста Радио “Аналитик“ поговорили, как анализировать и приоритизировать проблемы, как работать с неопределенностью и решениями, которые приняли без нас.

17.10.2023    357    0    Radio_Analyst    0    

2
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. informa1555 2646 08.12.15 20:15 Сейчас в теме
А что за софтина? Я для 1Ски на СКД писал канбан деск для пр-ва примерно в таком же виде.
2. davealone 165 09.12.15 09:54 Сейчас в теме
3. Артано 760 09.12.15 09:56 Сейчас в теме
(1) На скринах видно же - софт от "Devprom", и если мне не изменяет память, автор является участником команды этой компании. Так что можем считать эту статью хорошим прикладным рекламным примером
4. пользователь 09.12.15 11:43
Сообщение было скрыто модератором.
...
5. gigabyte_artur 09.12.15 12:28 Сейчас в теме
В качестве баг-треккеров пользовался указанной программой, СППР (http://v8.1c.ru/model/) и Битрикс-24 (https://www.bitrix24.ru).
Битрикс-24 хорош тем, что он быстрый, лёгкий и достаточно универсальный. Подходит для частной практики и небольших проектов.
СППР - напротив, очень мощный и тяжелый продукт. Мы несколько часов настраивали проект, но силы окупились с лихвой. Преимущество в лёгкой кастомизуемости (1С всё же...) и обширной аналитике на любой вкус.
Указанной программой пользуемся несколько недель. Пока сильно непривычно и хочется вернуться на СППР...
6. ivanov660 4330 09.12.15 16:02 Сейчас в теме
Внесу некоторые замечания:
1. Никак не соглашусь что баг-трекер это просто. Возможно Вы не пользовались полным функционалом, или не стали навастривать среду полностью, или просто реклама (правильная фраза - необходим порядок и настройка окружения).
2. Мы используем систему баг трекинга JIRA для которой атласины предоставляют широки функционал и набор плагинов. Для ведения документации необходимо использовать конфлюэнс. Хоть не люблю рекламу, но где-то на этом портале Лустин выкладывал ролик демонстрирующий полноценный вариант подхода к разарботке на 1с с помощью продуктов атласиан и в частности jira.
Оставьте свое сообщение