Русский
Русский
English
Статистика
Реклама

Из песочницы Ключи к успеху ИТ-проекта

Всем привет!

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



О себе


9 лет ИТ-консультант SAP ERP. Обязанности: проектирование, тимлидинг, тестирование и отладка, обучение, пилотирование.

Рамки применимости


Писал ориентируясь на проекты от 3-4 месяцев до 1 года со сложной межсистемной интеграцией.

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

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

Глоссарий


БА бизнес-аналитик
БЗ база знаний проекта
БТ бизнес-требования
ИТ архитектор и консультанты проектной команды
КП ключевой пользователь
МК младший консультант, эникейщик
ПР проектное решение
Прод продуктивная система
Разраб разработчик
СТ сценарии тестирования
СК старший консультант, проектировщик
ТЗ техническое задание

Ключи к успеху ИТ-проекта


Общий посыл налаженная коммуникация


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

Детальные и продуманные БТ


По БТ должно быть полное и синхронное понимание между бизнесом и ИТ. Для этого его должен составлять БА и КП (идеально, когда БА бывший КП).

Полный набор сценариев тестирования


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

Разделение труда внутри ИТ


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

Тоже касается содержания ТЗ/ПР в актуальном состоянии:

  1. СК пишет разрабу о корректировках и ставит МК в копию
  2. МК собирает и отражает изменения в режиме редактирования используя версионность
  3. СК принимает правки
  4. МК обновляет документацию в БЗ

Тестирование также следует делегировать МК.

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

Тестирование сценариев перед релизом


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

Общее пространство для команд интегрирующихся систем


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

Техническая адекватность принимающей стороны


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

Идеально, если принимающее лицо отлично знающий бизнес человек с последовательной и структурой логикой.

Модератор на пилот


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

Если будет порыв, есть идея описать проблемы, которые могут возникнуть, если описанные рекомендации не соблюдать.
Источник: habr.com
К списку статей
Опубликовано: 29.06.2020 22:07:32
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Анализ и проектирование систем

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

Успешный проект

Пилот

Должности на проекте

Категории

Последние комментарии

© 2006-2020, personeltest.ru