Сокращение затрат на разработку – горизонтальная и вертикальная оптимизация

Мадорская Ю.М.

В финале, в фантастическом предсказании остается один программист, который автоматизировал все, включая и других программистов [1].

Однако пока до финала еще далеко руководители компаний ищут, как удержать рост пузыря затрат на разработку ПО, одновременно сократив time-to-market.

HR-ы просеивают поколение Z в поисках талантов, а матерые программисты, не рассчитывая делиться зарплатой с вновь прибывшими, стараются автоматизировать рутину – сборку и тестирование ПО. Топ-менеджмент непрерывно сканирует всю систему и видит все больше скрытых ресурсов в вертикальных связях [2], начиная  от постановки задач до выпуска системы и ее обновлений.

Существует два подхода к оптимизации разработки ПО – горизонтальный и вертикальный.

В первом случае — это наладка горизонтального конвейера разработки, сборки и тестирования ПО – DevOps. Разработчики занимаются этим с энтузиазмом, не выходя за рамки механизмов конвейера.

transformer

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

Основные источники мусорной нагрузки на конвейер это:

  1. Ошибки в требованиях.
  2. Отсутствие горизонтальной и вертикальной трассировки требований [4].
  3. Отсутствие сквозной автоматизации управления требованиями и трассировкой на базе data-centric подхода [3].

Проводя обучение аналитиков, мы видим на входе специалистов с опытом аналитической работы от 3 до 15 лет, которые совершают от 50 до 80% ошибок при исходной обработке требований.

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

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

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

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

Легкость исправления ПО по сравнению с перестройкой дома не отменяет затрат на это исправление: пересогласование, перекодирование, перетестирование, передокументирование и сдачу в эксплуатацию.

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

5 аналитиков создают типовую нагрузку на конвейер программистов  и тестировщиков из 25 человек.

5 аналитиков – 20-50 % мусора для 25 человек ниже по циклу, т.е. 5 аналитиков загружают мусорным программированием и тестированием 5-12 из 25 программистов и тестировщиков. С учетом цикличной переработки мусора и его связей в итоге выполняется в среднем х3 мусорной работы — это 60-150%, которые обычно покрываются за счет увеличения длительности проектов [2], переработок, подстегиваемых agile-ритуалами [5] и расширения штата.

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

Остается вертикальная оптимизация – инвестиции в квалификацию и инструментарий для аналитиков и настройка полного вертикального цикла. Коэффициент усиления инвестиций при вертикальной оптимизации равен в среднем 5 – вкладывать в аналитиков в 5 раз выгоднее, чем в программистов.

Профессиональные курсы и инструменты для аналитиков стоят примерно столько же, сколько и для разработчиков, gradle_pricesпоэтому при равной стоимости инвестиций в обучение и инструментарий, гораздо выгоднее оптимизировать работу аналитиков, переведя их на data-centric подход [3] с обеспечением сквозной трассируемости и автоматизацией аналитических задач, чем вкладывать в переработку мусора.

При таком подходе выигрывают все, ведь никому неинтересно уходить в переработки, наблюдая потом как твоя работа пилит на свалку, а выгорание лучших [6] при работе над крупным проектом – известный эффект. Помимо просто довольных заказчиков от качественного ПО сокращение мусорных циклов позволяет резко сжать time-to-market, а автоматизированная аналитика, построенная на трассировке требований, переводит компанию на новый уровень гибкости и реальной agility. Это командный win-win – выигрывают все, кроме конкурентов.

Немного про инструментарий

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

devprom_pricesДля российского рынка наиболее актуальны две системы такого рода – это отечественная  Devprom и зарубежная 3SL Cradle Enterprise. Это продукты разных ценовых категорий и, соответственно, разных возможностей и производительности. Выбор между ними зависит от размера проектов, необходимости легкой настройки корпоративных стандартов управления, ориентации на отечественный или зарубежный рынок и многих других факторов.

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

Мадорская Ю.М. Сокращение затрат на разработку – горизонтальная и вертикальная оптимизация. //Практика проектирования систем.-2019. [электронный ресурс] — Режим доступа: http://reqcenter.pro/devmoney/ , свободный. — Загл. с экрана

Литература

  1. How long until computer programmers will no longer be needed? // [электронный ресурс] — Режим доступа: https://www.quora.com/How-long-until-computer-programmers-will-no-longer-be-needed, свободный. — Загл. с экрана.
  2. Тимофеев А.Н. Почему падают ИТ-проекты?. //Практика проектирования систем.-2017. [электронный ресурс] — Режим доступа: http://reqcenter.pro/why-it-fails/, свободный. — Загл. с экрана.
  3. Мадорская Ю.М. Данные vs документы при разработке и управлении требованиями. //Практика проектирования систем.-2016. [электронный ресурс] — Режим доступа: http://reqcenter.pro/data-centric-design/, свободный. — Загл. с экрана.
  4. Мадорская Ю.М. Мозг системного аналитика глазами команды. //Практика проектирования систем.-2015. [электронный ресурс] — Режим доступа: http://reqcenter.pro/analysts-brain/, свободный. — Загл. с экрана.
  5. Teun Hompe Scrum and overtime. //[электронный ресурс] — Режим доступа: https://medium.com/@teunhompe/scrum-and-overtime-e8e8e45d6a04, свободный. — Загл. с экрана.
  6. Григорий Савенок. Предотвратить, а не тушить: как бороться с выгоранием в команде. // 2018.[электронный ресурс] — Режим доступа: https://vc.ru/hr/56768-predotvratit-a-ne-tushit-kak-borotsya-s-vygoraniem-v-komande