Многие привыкли к треугольнику Хопкинса (Быстро, Дёшево, Качественно), он же - треугольник ограничения проектов. Вместе с тем в бизнесе популярным стало: «Ох уж эти программисты: опять долго, дорого и не то».
Здесь мы рассмотрим, почему в ИТ делать некачественно - это долго и дорого, а высокое качество разработки снижает сроки и стоимость разработки. Без каких-то сложных терминов и простым языком.
Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп и один из идеологов концепции IT~BP — IT бизнес-партнёрства. https://itbp.org
Давайте с простого. Треугольник Хопкинса плохо работает не только в ИТ, он вообще чаще всего не работает, ведь у него очень узкая область применения. Например, мы делаем стальные миски из листового металла. Раньше для такой работы нужен был кузнец, каждая миска была уникальна, стоимость производства — высокая. Если нам нужно произвести партию из ста тысяч мисок, нужно много кузнецов, работа будет долгой и дорогой.
Сейчас для производства мисок хватит пресса и всего несколько операций на линии производства. Стоимость одной миски будет небольшой, они все будут одинаковыми и более качественными, чем миски, произведённые кузнецами. Кроме того, скорость производства мисок будет очень высокой.
Вот только нам понадобятся квалифицированные сотрудники для производства пресс-формы и обслуживания самого пресса, а ещё наличие электричества, проще говоря, инфраструктура. Без неё — долго, дорого и некачественно, с ней — быстро, дёшево, качественно.
Если вам пример показался слишком утрированным, то посмотрите, как в России производят кухонные ножи. Кузнецы и слесари против промышленного производства в 2022 году. Есть хорошие мастера, но промышленное производство всё равно выигрывает.
Идём дальше, треугольник Хопкинса действует только при изготовлении партий товара. Например, мы шьём партию курток. Мы можем использовать простые строчки, убрать промежуточный контроль качества, брать менее качественную ткань, как результат, получить более дешёвую и менее качественную партию товара в меньшие сроки. Помним, что работа людей — это и деньги, и сроки.
Но есть один нюанс. Вам эту партию товара низкого качества нужно будет ещё продать. Иначе говоря: «втюхать». Делать некачественно, но быстро и дёшево, можно только, если нет строгого и адекватного контроля качества итоговой продукции и у вас готовы покупать все, что угодно.
Когда контроль качества итоговой продукции есть, когда «втюхивать» не выходит, то получится обратный эффект. Много изделий уйдёт в брак. То есть будут дополнительные затраты денег и времени на выпуск бракованных изделий. Итог простой — долго, дорого и не то.
Что происходит в ИТ? В ИТ никто не производит партии товара, никто не делает «тиражирование». О каком тираже мы говорим, если для получения копии кода либо файла можно просто использовать комбинации клавиш «Ctrl + c» и «Ctrl + v»? Я утрирую, но стоимость копирования действительно очень мала.
Если вернуться к примеру с мисками, то ИТ делает для вас пресс и пресс-форму. Иначе говоря, ИТ даёт вам инфраструктуру, которая позволяет снизить себестоимость и нарастить объёмы. За счёт автоматизации процессов.
В цикле производства продукта в ИТ есть этапы:
Отладка. На этом этапе разработчик проверяет созданный им функционал на наличие ошибок и исправляет их. После этого функционал передаётся на тестирование.
Тестирование. На этом этапе произведённый функционал тестируется специалистом по тестированию. Если находятся ошибки, то функционал отдаётся на исправление, что подразумевает повторение процедуры отладки.
Регрессионное тестирование. На этом этапе проверяется, а не сломал ли новый функционал уже существующий и протестированный функционал. То есть не регрессировала ли система в целом. Найденные ошибки нужно исправлять, то есть повторять процесс отладки, тестирования и регрессионного тестирования.
Интеграционное тестирование. На этом этапе проверяется совместное действие функционала системы. Функционал может работать по отдельности, а вот совместно — нет. Если будут ошибки, то предыдущие этапы тестирования придётся повторить.
Если разработчик работает некачественно, то есть перекладывает ответственность на тестирование (разработка через багфикс), то итоговая стоимость начинает расти в разы.
Конечно, можно не тестировать, то есть переложить отладку на конечных пользователей. Их же тысячи на продуктиве. Но будет поток инцидентов и очень дорогой багфикс. А ещё запоротые партии продукта, которые производит процесс, подвергшийся некачественной автоматизации. То есть в совокупности затрат это будет очень дорого и очень долго.
Ещё есть состояние «технического дефолта». Это когда в системе накапливается столько недоработок и ошибок, что любое внесение изменений приводит к валу новых ошибок. Например, мы исправляет 1 ошибку, но получаем 10 новых. Исправляем 10 новых, но в замен получаем 200 свежих ошибок. Происходит крах системы, выйти из которого можно либо написав новую систему, либо проведя дорогостоящий реинжиниринг существующей системы.
В результате, те команды, которые привыкли работать качественно, производят функционал быстро и недорого. Потому что тратят меньше времени на исправление ошибок. Те команды, которые снижают планку качества, начинают работать дольше, стоимость производства функционала заметно растёт. А потом следует крах системы либо бизнеса в целом.
Чтобы разрабатывать качественно, нужны профессионализм и культура производства. Такие люди вам будут говорить, что можно качественно, быстро и недорого. Они знают, что падение скорости разработки и рост цены разработки — это проблемы качества. Плохо собранные требования, некачественно поставленная задача, непродуманная архитектура, разработка через багфикс, невнимательное тестирование и другое.
Профессионализм часто сочетается с требовательностью. С требовательностью к себе и другим. Профессионалы, обычно, не стесняются сказать человеку, что он делает что-то не так в их профессиональной области, объяснив при этом простым языком, почему они так считают. Даже если что-то не так делает заказчик.
Другие будут вам рассказывать, что, конечно, это долго и дорого, зато качественно. Пока их рыночную нишу не поглотит NoCode либо LowCode, как это сейчас произошло с лендингами, простыми сайтами и примитивными мобильными приложениями.
Подводя итоги
Можно сказать, что чем сложнее и объёмнее проект, тем строже нужно следить за качеством разработки. Если работать некачественно, то разрабатываемый продукт может просто не выйти в свет. Потому что развалится ещё по пути. Либо закончится бюджет. Или терпение заказчика.
Если вы дочитали до конца и поняли, что делать качественно это быстрее и дешевле, потому, что брака (и затрат на него) меньше, то спасибо вам.
В статье подмена понятий.
Очевидно, что чем больше качество работы конкретных сотрудников, тем лучше. Не имеет никакого смысла снижать качество конкретных работ.
Но при этом, треугольник качество-сроки-бюджет на уровне проекта вполне имеет место, и этим надо управлять.
В IT низкое качество это может значить, что мы не фиксим некоторые не самые важные баги, не оптимизируем время выполнения части операций программы, ревью UI делается 1 итерация вместо 3х, и т.д.
Низкое качество - это дополнительные операции. В том числе и операции контроля. Например вы говорите о ревью UI, причем говорите о целых 3 итерациях. Это время и деньги.
А почему возникла необходимость в этом ревью? Кто что недоделал и кто что переложил на коллег?
Как раз моя мысль в том, что не надо путать качество на уровне проекта и на уровне выполнения конкретных работ.
"Низкое качество - это дополнительные операции" - это про то, что работы делаются некачественно, а не про качество проекта.
Я из геймдева и честно говоря это довольно частая вещь, когда с точки зрения бизнеса выгодно выпускать некачественную игру, чтобы уложиться в бюджет или сроки. Это вообще ничего не говорит про качество самой разработки этой игры.
Про ревью UI - я в работаю в геймдеве уже лет 10, у нас 3 ревью UI это очень мало, обычно на сложный игровой UI нужно минимум с десяток итераций ревью :) Смысл не в том, сколько нужно этих итераций, а в том, что тут можно сэкономить на качестве, если так надо бизнесу.
В геймдеве я не большой эксперт, в чем-то могу ошибаться. Но в других областях, с точки зрения бизнеса, иногда выгоднее выпустить на рынок сырой проект, но очень быстро, после чего дорабатывать его на ходу.
Самый показательный пример это, наверное, табличный процессов Lotus 123, который доминировал на рынке, но отложил выпуск новой версии на полгода. Как результат, большая часть людей сейчас использует MS Excel, а компания Lotus продалась IBM.
Но тут вопрос даже не про качество, тут вопрос понимания, что такое «достаточно хорошо» с точки зрения бизнеса. И часто это вопрос не бюджета, а сроков и окон бизнес-возможностей.
Плюс, даже качественно реализованный проект может быть нежизнеспособным из-за неверной постановки либо неверной бизнес-идеи. То есть, как проект разработки оно может состояться, а как бизнес-проект — нет.
Ага, я про это же.
С играми бывает то же самое. Например, выпуститься надо самое позднее через год. Или надо игру спортировать на Switch, но при этом бюджет $0.5 млн и не больше. С такими ограничениями получается выпустить только сырой проект, с низким качеством. Если это «достаточно хорошо» с точки зрения бизнеса - ОК, пошли делать.
Приоритеты в треугольнике качество-сроки-бюджет ещё могут меняться в процессе работы над проектов, приходится менять планы.
Ну вот классический треугольник качество-сроки-бюджет - это про вот эту работу, на уровне управления проектом. А у вас в статье речь всё-таки про другое, что работать надо хорошо)