После «жаркого» пилотирования на прошедшей неделе мозг, видимо, подрасслабился и зацепился за вопрос: «А что нужно было сделать, чтобы все проходило спокойно и без всех этих нервяков?»
Варианты ответов, которые он нагенерил, я и постараюсь изложить.
О себе
9 лет — ИТ-консультант SAP ERP. Обязанности: проектирование, тимлидинг, тестирование и отладка, обучение, пилотирование.
Рамки применимости
Писал ориентируясь на проекты от 3-4 месяцев до 1 года со сложной межсистемной интеграцией.
Решив не рисковать утонуть в достижении перфекционизма, потеряв начальный запал на написание — пришлось отказаться от претензий на высокий уровень структурности, последовательности и полноты. По тем же соображениям текст писал только «из личного опыта», созвучные по теме тексты перед публикацией не читал.
Поэтому в определенной мере рассчитываю на комментаторов, чтобы, возможно, написать вторую редакцию, в которой вышеупомянутые критерии были уже на должном уровне.
Глоссарий
БА — бизнес-аналитик
БЗ — база знаний проекта
БТ — бизнес-требования
ИТ — архитектор и консультанты проектной команды
КП — ключевой пользователь
МК — младший консультант, эникейщик
ПР — проектное решение
Прод — продуктивная система
Разраб — разработчик
СТ — сценарии тестирования
СК — старший консультант, проектировщик
ТЗ — техническое задание
Ключи к успеху ИТ-проекта
Общий посыл — налаженная коммуникация
Необходимо добиться синхронности между бизнесом и ИТ в восприятии бизнес-требований, сценариев тестирования, проектного решения и того, как это будет выглядеть в реализации.
Детальные и продуманные БТ
По БТ должно быть полное и синхронное понимание между бизнесом и ИТ. Для этого его должен составлять БА и КП (идеально, когда БА — бывший КП).
Полный набор сценариев тестирования
Максимальное количество максимально детальных сценариев должно быть известно и проработано до написания решения. Сценарии должны писаться, начиная от самых часто встречающихся к самым редким. Последние, в случае их дорогой автоматизации, должны иметь продуманное ручное управление.
Разделение труда внутри ИТ
В проектной команде должно быть разделение по интеллектуальной сложности работ. Хорошо, если проектировщик имеет навык без лишних затрат стилистически выверенно оформлять документацию. Иначе, лучше наведение «красоты» отдать человеку с младшей должностью.
Тоже касается содержания ТЗ/ПР в актуальном состоянии:
- СК пишет разрабу о корректировках и ставит МК в копию
- МК собирает и отражает изменения в режиме редактирования используя версионность
- СК принимает правки
- МК обновляет документацию в БЗ
Тестирование также следует делегировать МК.
Плохо знаю как вне SAP, но здесь очень часто используется принцип консультант-комбайн, который делает все (проектирование, тестирование, написание документаций)
В результате страдают качество, сроки (и «деньги») и растут риски, связанные с тем, что все завязано на 1 человека.
Тестирование сценариев перед релизом
- Тестирование необходимо проводить в приближенной к проду среде (в идеале — в копии прода).
- Обязательно участие людей, которые непосредственно будут работать с функционалом (желательно перед этим провести ликбез по решению).
Общее пространство для команд интегрирующихся систем
При наличии сложной интеграции на проекте крайне важно создать общее поле проектного контекста и обеспечить «близость к телу». В идеале — вся проектная команда должна находится в одном помещении. Иначе нужен отдельный человек или удобный инструмент, который бы обеспечивал синхронизацию между командами.
Техническая адекватность принимающей стороны
Формальное согласование бизнесом ПР — это бич проекта. Принимающая сторона должна полно и детально представлять себе решение. В случае, если проект касается глубокой модернизации существующего функционала, то бизнес должен отлично знать и его.
Идеально, если принимающее лицо — отлично знающий бизнес человек с последовательной и структурой логикой.
Модератор на пилот
Нейтральное для ИТ и бизнеса лицо с задатками третейского судьи. Выстраивает план пилотирования, составляет протоколы тестирования, ведет учет замечаний и их исправлений.
Если будет порыв, есть идея описать проблемы, которые могут возникнуть, если описанные рекомендации не соблюдать.
ссылка на оригинал статьи https://habr.com/ru/post/508826/