История одного проекта обновления, где опыт — сын ошибок трудных (и хорошо, что не наших)

12.07.24

Управление проектом - Кейсы проектов

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

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

 

Точка отсчета

С заказчиком мы общались с 2021 года. Всё у него было более-менее хорошо: собственная ИТ-команда с программистами и аналитиками, наработанные отношения с подрядчиками — в общем, не было смысла отдавать обновление на аутсорс кому-то ещё.

А потом потребовался переход 1С:ERP с 2.4 на 2.5. Собственно, речь не про этот переход — наша оценка не подошла по срокам, поэтому договорились вернуться уже к регулярному обновление, когда будет свежая программа. 

Время шло, в компании случились кадровые перестановки, появились новые подрядчики по 1С и… случился тот самый момент. Переход был болезненный: не уложились в техокно — были «пробуксовки» с обработчиками обновления, регулярно появлялись ошибки непосредственно после обновления. В общем, получили негативный опыт.

 

Приходим к взаимопониманию

Из той истории, заказчик пришел к нам уже с другим уровнем понимания задачи обновления.  Просто результата «ERP обновлена до 2.5.x.y» было уже недостаточно.

Исходная ситуация: обновление с 2.5.8 до актуального релиза ветки 2.5.12, в конфигурации несколько сотен добавленных и измененных объектов, форм и модулей, 500 внешних отчетов и обработок, одно расширение, около 300 пользователей, база более 100 гб, технологическое окно — с 21.00 субботы до 6.00 утра понедельника. Доработки ведутся практически постоянно.

 


Отчет из оценки

 

Что хотел заказчик:

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

И главное — понимание, как будет выглядеть весь проект «от и до». Потому что, когда они начинали обновление с 2.4 на 2.5, у них с исполнителем было разное понимание и процесса, и результата.

С нашей стороны были встречные пожелания:

  • Присутствие методолога со стороны клиента (мы знали, что он есть).
  • Общая среда общения между командой клиента и нашей командой, где можно было оперативно общаться по поводу ошибок.

 

План-график-контрольная среда

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

 


План-график работ проекта

 

В нашем случае первую часть работы делает программа «1С:Автоматизированное обновление измененных конфигураций» и её операторы: продукт находит и переносит доработки, делает автоматическое тестирование перенесенных доработок — отслеживание движения документов, открытие форм и работу элементов интерфейса, а специалисты проверяют результат.

 


Модификации конфигурации такие, что на автоматизированное обновление и тестирование ушло почти 4 недели

 

Есть расширения — нужно расширенное тестирование

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

Отлично, если сохранилось ТЗ на все эти доработки, можно сразу понять, чего хотели, почему так доработали и как оно должно работать корректно. Если же ТЗ нет — то приходится выяснять, доработка это или частичное обновление. Мы привыкли работать в условиях, когда изменения были сделаны кем-то и когда-то, и никто не может описать всей картины.

 


Непредвиденная ситуация

 

От непредвиденных ситуаций никто не застрахован, поэтому страховаться надо. Например, к целевому релизу не подходит платформа на сервере клиента. По договоренности заказчик сам должен был следить за обновлением платформы, но — он же ждет от специалистов исполнителя, как экспертов, что мы предупредим, акцентируем внимание, что надо её актуализировать. Или, например, закончилось место на сервере — и пока его не добавят, работа встаёт.

 

Отыгрывать роли до конца

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

В таких проектах очень выручает наличие методолога со стороны заказчика. Одно только наличие методолога — это признак того, что с той стороны будут грамотные пользователи. Плюс методолог выступает вторым контуром тестирования, исключая моменты, когда в дефекты записывались особенности нового релиза, то есть «ошибки» записывали в ошибки только после его проверки. 

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

 

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

Конфигурация заказчика дорабатывается постоянно. К моменту обновления рабочей базы пришлось повторить цикл предыдущих работ в меньшем масштабе: перенести, адаптировать, повторно протестировать. Учесть, что за прошедшее с начала проекта время могли выйти новые релизы и понять, стоит ли на них до-обновиться, в нашем случае это надо было сделать с 147 до 178 релиза. Изменения были не глобальные, главное — учесть с точки зрения организации, что эти доработки будут.

IT-отдел клиента выпускает свой доработанный релиз конфигурации к четвергу. Нам со своей стороны нужно успеть подстроиться и сделать обновление, пока доработка остановлена.
После обновления рабочей базы пользователям в первые дни требовалась молниеносная реакция техподдержки. Чтобы не 2-3 суток, а прямо сразу подключались консультант и разработчик. Это могут быть как самые напряженные дни, так и самые простые — если все предыдущие этапы готовились правильно.

 


Конец — делу венец

 

По трудозатратам получилось, что 10% пришлось на автоматизированное обновление и тестирование, 70% — дальнейшая работа консультантов и подключаемых разработчиков, 20% на специалистов со стороны клиента.

 

Итого: как организовать сложное обновление с подрядчиком, чтобы оно прошло успешно

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

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

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

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

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

Если нужно будет что-то доработать по ходу обновления — сразу заложите часы на разработчика. На стадии промышленной эксплуатации зарезервируйте хотя бы на первые 2-3 дня выделенных специалистов для быстрой техподдержки.

Не совмещайте роль линейного руководителя с ролью администратора проекта. Хороший специалист «вывезет», но удовольствия ему это не доставит :)

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

обновление 1С проект обновления управленеи проектами

См. также

Личная эффективность Продуктовый подход Работа с заинтересованными сторонами Бесплатно (free)

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

18.11.2024    257    0    Radio_Analyst    0    

1

Кейсы проектов Руководитель проекта Бесплатно (free)

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

28.10.2024    745    0    paalferov    1    

5

Кейсы проектов Бесплатно (free)

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

09.09.2024    618    0    user1231217    1    

4

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

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

02.09.2024    1318    0    user1669221    2    

7

Кейсы проектов Бесплатно (free)

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

28.05.2024    652    0    Radio_Analyst    0    

4

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

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

08.02.2024    1096    0    izybaevda    0    

5

Кейсы проектов Бесплатно (free)

Когда проект ограничен по времени, и уже через два месяца заказчик физически не сможет работать в старой системе, нет времени обкладываться бумажками – нужно быстро подготовить новую систему к переходу. Расскажем о том, как гибкие технологии SCRUM и ТБР помогли за два месяца адаптировать 1С:ERP под существующие бизнес-процессы компании.

07.02.2024    3098    0    izybaevda    18    

16

Анализ предметной области Работа с заинтересованными сторонами Анализ потребностей и поиск решений Платформа 1С v8.3 1С:Управление холдингом Россия Бухгалтерский учет Налоговый учет Управленческий учет Бесплатно (free)

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

07.02.2024    1482    0    1C_Community    0    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. RocKeR_13 1366 12.07.24 15:34 Сейчас в теме
Расширения почти всегда добавляют трудозатрат. Если по основным цепочкам все понятно — запустил перепроведение документов и только, то в расширении нужно погружаться и понимать для чего оно было сделано, какие бизнес-процессы нужно закрыть.

Что-то не понял этот момент: а если изменения (допустим, те же самые, что и в расширении) сделаны в основной конфигурации, то не нужно понимать, для чего они сделаны и какие бизнес-процессы нужно этими изменениями закрывать?
Оставьте свое сообщение