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

Всем привет!

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



О себе


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

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


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

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

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

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


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


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

Детальные и продуманные бизнес требования


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

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


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

Разделение труда внутри ИТ-команды


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

Тоже касается содержания технических заданий и проектных решений в актуальном состоянии:

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

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

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

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


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

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


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

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


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

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

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


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

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

Средняя зарплата в IT

120 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 3 620 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 7

    +6

    А вот эти сокращения они прям очень нужны на Хабре? Нельзя было оставить полные названия?

      0
      Сокращения намекают на серьезность намерений (увы, все остальное — нет). Кстати, такое часто встречал в окологосударственных проектах. Когда сокращений и воды по ГОСТам больше, чем описания проекта.
        0

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

      +4
      Ощущение будто читаешь тендерные документы на 100 страниц, где тоже куча сокращений, а в самом начале их список с расшифровкой. Учитывая текущий объём статьи, это явно было лишним.

      От заголовка и «9 лет — ИТ-консультант SAP ERP. Обязанности: проектирование, тимлидинг, тестирование и отладка, обучение, пилотирование.» ожидал получить хорошую и длинную статью об опыте работы на проектах, совершённых ошибках, описании того, что можно было бы исправить и т.д.

        0

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

        0

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

          0
          Сорректировал в полной версии сайта.

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

        Самое читаемое