Подход к внедрению программного обеспечения 2016

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

Популярные подходы к разработке

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

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

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

Проектная методология обычно определяет фазы проекта (например, дизайн или анализ), Deliverables, которые будут предоставлены в ходе проекта (часто в соответствии с определенными Toll Gates, позволяющими перейти из одной фазы в другую), Milestones и другие параметры, необходимые в ходе проекта.

Классический подход

Подход, который я считаю классическим, очень упрощенно включает в себя следующие фазы:

  1. Подготовка
  2. Определение решения
  3. Выполнение
  4. Поддержка

Ниже определенные фазы более подробно.

Подготовка

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

Определение решения

В ходе определения решения необходимо понять, как будет происходить решение проблемы, будет ли это новая разработка "с нуля" (С использованием каких платформ? Как с точки зрения архитектуры?), или она будет основана на неком стандартном продукте/платформе, TOBE процессы, происходящие с использованием этого продукта, список требований, список разработок и другое.

Выполнение

В ходе выполнения происходит непосредственно разработка/настройка программного продукта, выполняется тестирование, обучение и Go-Live.

Поддержка

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

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

Современные изменения

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

  • Итерационный подход (релизный)
  • Использование шаблонов/заготовок
  • Стандартизация

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

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

Стандартизация используется, чтобы упростить поддержку и ускорить доработку ПО.

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

Каким должен быть подход к внедрению ПО в 2016?

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

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

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

Все больше современных разработчиков ПО пытаются предвидеть тенденции на рынке (а иногда и создать их) и выпустить программные продукты исходя из прогнозов/собственного видения. А в современном мире Disruptive business это иногда и единственный успешный подход.

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

Я ожидаю в ближайшие несколько лет снижение длительности проекта по внедрению минимум в два раза.

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

Идеальный проект

Ниже я попытался привести образ идеального проекта внедрения ПО по инновационному подходу в 2016.

Подготовка

В ходе подготовки определяется business case, из-за которого происходит проект. Зачастую, этот проект возникает на базе знания функционала соответствующего продукта. Мы знаем, что есть продукт, функционал которого позволит принести критическую пользу без изменений в самом продукте.

Определение решения/Выполнение

Данные фазы представлены вместе, поскольку они происходят параллельно. Благодаря современным облачным технологиям ПО разворачивается за считанные минуты, производится первоначальная настройка. Вместе с ключевыми пользователями эксперты IT определяют TOBE процессы бизнеса с использованием стандартного функционала продукта, попутно фиксируя критические несоотвествия (Gaps), которые возникнут при обсуждения изменений бизнес процессов. Большинство несоответствий должны закрываться изменением бизнес процессов, остальные обходными путями. Изменение стандартного функционала должно быть самой последней мерой, когда другие использовать нецелесообразно.

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

Поддержка

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


В общем, это все. Живите в 2016.

{{ message }}

{{ 'Comments are closed.' | trans }}