Процессы в ИТ: Долго, дорого и не то

Многие привыкли к треугольнику Хопкинса (Быстро, Дёшево, Качественно), он же - треугольник ограничения проектов. Вместе с тем в бизнесе популярным стало: «Ох уж эти программисты: опять долго, дорого и не то».

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

Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп и один из идеологов концепции IT~BP — IT бизнес-партнёрства. https://itbp.org

Давайте с простого. Треугольник Хопкинса плохо работает не только в ИТ, он вообще чаще всего не работает, ведь у него очень узкая область применения. Например, мы делаем стальные миски из листового металла. Раньше для такой работы нужен был кузнец, каждая миска была уникальна, стоимость производства — высокая. Если нам нужно произвести партию из ста тысяч мисок, нужно много кузнецов, работа будет долгой и дорогой.

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

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

Если вам пример показался слишком утрированным, то посмотрите, как в России производят кухонные ножи. Кузнецы и слесари против промышленного производства в 2022 году. Есть хорошие мастера, но промышленное производство всё равно выигрывает.

Идём дальше, треугольник Хопкинса действует только при изготовлении партий товара. Например, мы шьём партию курток. Мы можем использовать простые строчки, убрать промежуточный контроль качества, брать менее качественную ткань, как результат, получить более дешёвую и менее качественную партию товара в меньшие сроки. Помним, что работа людей — это и деньги, и сроки.

Когда контроль качества итоговой продукции есть, когда «втюхивать» не выходит, то получится обратный эффект. Много изделий уйдёт в брак. То есть будут дополнительные затраты денег и времени на выпуск бракованных изделий. Итог простой — долго, дорого и не то.

Что происходит в ИТ? В ИТ никто не производит партии товара, никто не делает «тиражирование». О каком тираже мы говорим, если для получения копии кода либо файла можно просто использовать комбинации клавиш «Ctrl + c» и «Ctrl + v»? Я утрирую, но стоимость копирования действительно очень мала.

Если вернуться к примеру с мисками, то ИТ делает для вас пресс и пресс-форму. Иначе говоря, ИТ даёт вам инфраструктуру, которая позволяет снизить себестоимость и нарастить объёмы. За счёт автоматизации процессов.

В цикле производства продукта в ИТ есть этапы:

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

• Тестирование. На этом этапе произведённый функционал тестируется специалистом по тестированию. Если находятся ошибки, то функционал отдаётся на исправление, что подразумевает повторение процедуры отладки.

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

• Интеграционное тестирование. На этом этапе проверяется совместное действие функционала системы. Функционал может работать по отдельности, а вот совместно — нет. Если будут ошибки, то предыдущие этапы тестирования придётся повторить.

Если разработчик работает некачественно, то есть перекладывает ответственность на тестирование (разработка через багфикс), то итоговая стоимость начинает расти в разы.

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

Ещё есть состояние «технического дефолта». Это когда в системе накапливается столько недоработок и ошибок, что любое внесение изменений приводит к валу новых ошибок. Например, мы исправляет 1 ошибку, но получаем 10 новых. Исправляем 10 новых, но в замен получаем 200 свежих ошибок. Происходит крах системы, выйти из которого можно либо написав новую систему, либо проведя дорогостоящий реинжиниринг существующей системы.

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

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

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

Можно сказать, что чем сложнее и объёмнее проект, тем строже нужно следить за качеством разработки. Если работать некачественно, то разрабатываемый продукт может просто не выйти в свет. Потому что развалится ещё по пути. Либо закончится бюджет. Или терпение заказчика.

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