В рассказе нет технических деталей, он больше про организацию: как выстроить процесс, чтобы заказчики, исполнители и пользователи на проекте обновления — спокойно работали, спокойно ходили на обед и даже спокойно спали.
Точка отсчета
С заказчиком мы общались с 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 дня выделенных специалистов для быстрой техподдержки.
Не совмещайте роль линейного руководителя с ролью администратора проекта. Хороший специалист «вывезет», но удовольствия ему это не доставит :)
Результат обновления — не только конфигурация на целевом релизе, но и комфорт заказчика во время процесса.
