Место ОТК в разработке ПО

Интрига

Давно размышляю о подходящем наборе ролей и о месте Отдела Технического Контроля (ОТК) в разработке программного обеспечения.

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

Начнем с простейшей модели, дабы понять правила игры, а потом, при необходимости, подставим реальные цифры, основанные на замерах.

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

Простейшая модель

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

Для упрощения задачи сделаем еще несколько предположений:

  1. Пренебрежем связанным капиталом. Смешно даже сравнивать стоимость рабочего места с годовой зарплатой программиста.
  2. 100 УЕС-ов позволяют компании жить и развиваться. Но если их не будет – предприятию будет нехорошо, ибо конкуренты не дремлют.
  3. Но все равно хочется сократить затраты на разработку, т.к. аутсорсеры предлагают поставлять те же 100 УЕС-ов за 200 условных единиц денег (УЕД)

Департамент разработки разбит на три сектора (три выделенных роли):

  • взаимодействия с заказчиками – отвечает за прием в производство того, что нужно бизнесу
  • аналитики – отвечает за то, чтобы то «что нужно» – обладало «нужным набором фич»
  • программирования -  отвечает за корректную реализацию «нужного набора фич»

Я специально не ввел ОТК. Почему – станет ясно позднее.

Для того, чтобы средние производительности секторов были равны 100 УЕС, необходимо, чтобы операционные затраты на отделы (зарплата + налоги + аренда + уборщица + кофейный автомат + …) были соответственно:

  • взаимодействия с заказчиками – 10 УЕД
  • аналитики – 20 УЕД
  • программирования – 50 УЕД. Это могут быть и 50 человек по единичке уе и пятеро по восемь. В данной модели нам интересно только соотношение между секторами.

Примечание. Если кто-то спросит про запас по производительности – то это цифири как раз с нужным запасом, который и позволяет поставлять продукт «точно вовремя».

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

Сделаем еще несколько предположений в модели:

  • Потерь бизнеса от поставленного брака нет (это просто идеальный мир). Нужно просто обеспечить генерацию ста качественных  УЕС-ов в месяц. Не более, но к сожалению, и не менее. И если каждый месяц поставляется 100 единиц качественной продукции, то бизнес доволен, сколько бы не было брака.
  • Пусть каждый отдел допускает в обработке заказа всего треть ляпов. Т.е. с вероятностью одна третья вносит в разрабатываемый УЕС дефект. Так конечно не бывает. Обычная норма: 60-80%. Но вдруг? Вдруг собрались звезды? Ну, или софт настолько прост, что ошибок мало?

Вероятность получить качественный продукт на выходе равна (2/3)*(2/3)*(2/3). Департамент разработки без Отдела Технического Контроля производит 70 брака и всего 30 качественных УЕС-ов. А надо 100.

Решение номер раз.

Пропорционально, в 10/3  увеличить сектора:

  • взаимодействия с заказчиками – 34 УЕД
  • аналитики – 67 УЕД
  • программирования – 167 УЕД

Сюрприз! Операционные расходы выросли до 268. Это, господа, много. Нет, это перебор. Это шах и мат департаменту. Т.е. это полный «П». Всех разогнать и обратиться к аутсорсерам.

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

Решение номер два.

Нужно ввести ОТК в сектор разработки (в переводе на русскопрограммерский  - нанять тестировщиков)! Ура, товарищи! Все ликуют и даже дамы бросают в воздух чепчики.

Сделаем еще несколько предположений.

  • ОТК в любом секторе отлавливает только ошибки своего сектора. Это очевидно и прекрасно согласуется с жизнью. Тестировщик, умеющий отлавливать недокументированные требования и нужды бизнеса только на основании своего опыта – это зверек редкий и обитает в черном разделе красной книги (вымершие виды). Таких спецов очень быстро переводят на другие работы.
  • ОТК отлавливает дефекты со 100% вероятностью. Так конечно не бывает. Но мы рассмотрим идеальную фирму, в которой работают настоящие самураи плаща, кинжала и бактрекера.
  • Дефектный УЕС проходит еще один цикл обработки и обязательного последующего контроля.
  • Исправленный модуль никогда не содержит ошибки. Так конечно тоже не бывает. Нормальное количество возвратов – это 4-6. Канер приводит цифры 6-8. Но как говорится мечтать, так мечтать.
  • Проверка стоит 1/3 от разработки

Изначально операционные расходы на разработку составляли 50 УЕД. Плюс нужно добавить на исправление дефектов 50 *(1/3), плюс нужно добавить на контроль.

(50+50*(1/3))+ (50+50*(1/3))*(1/3)=89

Не то чтобы это было замечательно, но пока приемлемо.

  • взаимодействия с заказчиками – 10 УЕД
  • аналитики – 20 УЕД
  • программирования – 89 УЕД

Однако стоп. Такой департамент будет выпускать всего (2/3)*(2/3)=44% качественной продукции. Мы ведь еще не забыли, что остальные департаменты тоже допускают ошибки!? Но мы грамотные. Мы знаем, как решать проблему недостаточной мощности. Нужно просто пропорционально увеличить сектора.

  • взаимодействия с заказчиками – 23 УЕД
  • аналитики – 46 УЕД
  • программирования – 203 УЕД

Сюрприз!!!

Итоговая сумма (272 УЕД) операционных расходов оказалась совсем не так хороша, как хотелось бы. Скажем по-другому. Это черт знает что и сбоку бантик. За такое надо давать расстрел через повешение без права переписки с конфискацией права на презумпцию невиновности.

Вместо выводов

Что любопытно. Типичнейший российский способ улучшения первого решения – переход ко второму. Попытки воззвать к человеческому разуму и объяснить, что создание отдела тестирования преждевременно и не даст желаемого эффекта - успеха не имеют. Каждый гордый российский управленец должен сожрать свои кактусы сам. И видимо не один десяток.

Продолжение следует

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

Секторов пять. Если без брака, то:

  • Прием заказов – 8
  • Аналитика – 20
  • Архитектура – 12
  • Программирование – 36
  • Поставка – 4

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

В первой модели мы брали увеличение расходов на отдел при внедрении ОТК чуть менее двойки. Реально же за счет большего числа возвратов этот коэффициент около тройки. При таком коэффициенте процент пропущенного брака будет в приемлемых 5-10%.

И, если хотите поиграть совсем уж по жизненным правилам, введите малюсенький штраф за поставленный брак. В размере  0.1 - 0.5 УЕД за один поставленный бракованный УЕС.

Приятного времяпровождения. Простенький фреймворк прилагается. Фреймворк посложнее разработайте сами.

PS.

Не будьте так серьезны. Это просто модель. Как говорил великий Фрейд: «Иногда бывают просто сны».

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.