Многие привыкли к треугольнику Хопкинса (Быстро, Дёшево, Качественно), он же - треугольник ограничения проектов. Вместе с тем в бизнесе популярным стало: «Ох уж эти программисты: опять долго, дорого и не то».
Здесь мы рассмотрим, почему в ИТ делать некачественно - это долго и дорого, а высокое качество разработки снижает сроки и стоимость разработки. Без каких-то сложных терминов и простым языком.
Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп и один из идеологов концепции IT~BP — IT бизнес-партнёрства. https://itbp.org
Давайте с простого. Треугольник Хопкинса плохо работает не только в ИТ, он вообще чаще всего не работает, ведь у него очень узкая область применения. Например, мы делаем стальные миски из листового металла. Раньше для такой работы нужен был кузнец, каждая миска была уникальна, стоимость производства — высокая. Если нам нужно произвести партию из ста тысяч мисок, нужно много кузнецов, работа будет долгой и дорогой.
Сейчас для производства мисок хватит пресса и всего несколько операций на линии производства. Стоимость одной миски будет небольшой, они все будут одинаковыми и более качественными, чем миски, произведённые кузнецами. Кроме того, скорость производства мисок будет очень высокой.
Вот только нам понадобятся квалифицированные сотрудники для производства пресс-формы и обслуживания самого пресса, а ещё наличие электричества, проще говоря, инфраструктура. Без неё — долго, дорого и некачественно, с ней — быстро, дёшево, качественно.
Если вам пример показался слишком утрированным, то посмотрите, как в России производят кухонные ножи. Кузнецы и слесари против промышленного производства в 2022 году. Есть хорошие мастера, но промышленное производство всё равно выигрывает.
Идём дальше, треугольник Хопкинса действует только при изготовлении партий товара. Например, мы шьём партию курток. Мы можем использовать простые строчки, убрать промежуточный контроль качества, брать менее качественную ткань, как результат, получить более дешёвую и менее качественную партию товара в меньшие сроки. Помним, что работа людей — это и деньги, и сроки.
Но есть один нюанс. Вам эту партию товара низкого качества нужно будет ещё продать. Иначе говоря: «втюхать». Делать некачественно, но быстро и дёшево, можно только, если нет строгого и адекватного контроля качества итоговой продукции и у вас готовы покупать все, что угодно.
Когда контроль качества итоговой продукции есть, когда «втюхивать» не выходит, то получится обратный эффект. Много изделий уйдёт в брак. То есть будут дополнительные затраты денег и времени на выпуск бракованных изделий. Итог простой — долго, дорого и не то.
Что происходит в ИТ? В ИТ никто не производит партии товара, никто не делает «тиражирование». О каком тираже мы говорим, если для получения копии кода либо файла можно просто использовать комбинации клавиш «Ctrl + c» и «Ctrl + v»? Я утрирую, но стоимость копирования действительно очень мала.
Если вернуться к примеру с мисками, то ИТ делает для вас пресс и пресс-форму. Иначе говоря, ИТ даёт вам инфраструктуру, которая позволяет снизить себестоимость и нарастить объёмы. За счёт автоматизации процессов.
В цикле производства продукта в ИТ есть этапы:
Отладка. На этом этапе разработчик проверяет созданный им функционал на наличие ошибок и исправляет их. После этого функционал передаётся на тестирование.
Тестирование. На этом этапе произведённый функционал тестируется специалистом по тестированию. Если находятся ошибки, то функционал отдаётся на исправление, что подразумевает повторение процедуры отладки.
Регрессионное тестирование. На этом этапе проверяется, а не сломал ли новый функционал уже существующий и протестированный функционал. То есть не регрессировала ли система в целом. Найденные ошибки нужно исправлять, то есть повторять процесс отладки, тестирования и регрессионного тестирования.
Интеграционное тестирование. На этом этапе проверяется совместное действие функционала системы. Функционал может работать по отдельности, а вот совместно — нет. Если будут ошибки, то предыдущие этапы тестирования придётся повторить.
Если разработчик работает некачественно, то есть перекладывает ответственность на тестирование (разработка через багфикс), то итоговая стоимость начинает расти в разы.
Конечно, можно не тестировать, то есть переложить отладку на конечных пользователей. Их же тысячи на продуктиве. Но будет поток инцидентов и очень дорогой багфикс. А ещё запоротые партии продукта, которые производит процесс, подвергшийся некачественной автоматизации. То есть в совокупности затрат это будет очень дорого и очень долго.
Ещё есть состояние «технического дефолта». Это когда в системе накапливается столько недоработок и ошибок, что любое внесение изменений приводит к валу новых ошибок. Например, мы исправляет 1 ошибку, но получаем 10 новых. Исправляем 10 новых, но в замен получаем 200 свежих ошибок. Происходит крах системы, выйти из которого можно либо написав новую систему, либо проведя дорогостоящий реинжиниринг существующей системы.
В результате, те команды, которые привыкли работать качественно, производят функционал быстро и недорого. Потому что тратят меньше времени на исправление ошибок. Те команды, которые снижают планку качества, начинают работать дольше, стоимость производства функционала заметно растёт. А потом следует крах системы либо бизнеса в целом.
Чтобы разрабатывать качественно, нужны профессионализм и культура производства. Такие люди вам будут говорить, что можно качественно, быстро и недорого. Они знают, что падение скорости разработки и рост цены разработки — это проблемы качества. Плохо собранные требования, некачественно поставленная задача, непродуманная архитектура, разработка через багфикс, невнимательное тестирование и другое.
Профессионализм часто сочетается с требовательностью. С требовательностью к себе и другим. Профессионалы, обычно, не стесняются сказать человеку, что он делает что-то не так в их профессиональной области, объяснив при этом простым языком, почему они так считают. Даже если что-то не так делает заказчик.
Другие будут вам рассказывать, что, конечно, это долго и дорого, зато качественно. Пока их рыночную нишу не поглотит NoCode либо LowCode, как это сейчас произошло с лендингами, простыми сайтами и примитивными мобильными приложениями.
Подводя итоги
Можно сказать, что чем сложнее и объёмнее проект, тем строже нужно следить за качеством разработки. Если работать некачественно, то разрабатываемый продукт может просто не выйти в свет. Потому что развалится ещё по пути. Либо закончится бюджет. Или терпение заказчика.
Если вы дочитали до конца и поняли, что делать качественно это быстрее и дешевле, потому, что брака (и затрат на него) меньше, то спасибо вам.
Так а сами то процессы где? Ваш опыт какой? А так в статье набор банальностей: делайте лучше и не делайте хуже. Ваш заголовок украл 5 минут моей жизни
Какой из процессов вас интересует? Беда в том, что их много, они могут быть большими и с длинным описанием. Возможно, уже есть статьи на эту тему.
Что до набора банальностей. Если бы люди их понимали и не делали бы столь банальных ошибок, ничего такого писать не пришлось бы.
Вы написали для рекламы, уж если честно.
Бизнесу что мелкому, что крупному (субъективно) продают в том числе и удобные вам в первую очередь процессы. Статьи, сколько помню мало кто читает и даже если бы билгейтс писал, каждый считает себя умнее. Полезнее наверное на реальных кейсах показать как подняли бюджет на качество, те продали. И про крах бизнеса - есть примеры свои или тоже все абстрактно?
А так вода - качественное качество, согласен с коллегой выше. Убираем ойти, вставляем установку сантехники - получился универсальный шаблон.
У вас, к сожалению, много противоречий. Вы не увидели процессы, но говорите, что я их продаю. При этом ещё говорите, что это универсальный шаблон. А как можно продавать универсальный шаблон? Вот я его описал, что мне тут допродать-то можно?
Принцип, чем качественнее, тем дешевле и быстрее, действительно универсальный, будет работать во многих областях. Но он настолько простой и очевидный, что многие люди, почему-то с трудом его понимают.
Кейсы есть, в своих предыдущих статьях я их описывал. Но, сразу предупреждаю, объем текста там не маленький.
Вы как то текст странно читаете.
Шаблон это плохо, если не поняли. Реклама даже хреновая - тоже привлекает внимание, потому что на слуху, вам об этом намекнули, вы в бой кинулись. Ну ок.
По тексту - обобщение, это плохо. Вы там грозите бизнесу разорением, а если это стартап, а если это частник, а если ему нужен модуль для говносистемы написанной 1000 лет назад, где качественно переписать может просто быть больше всей ценности компании. Короче, покупайте мерседес - лада говно.
И если бизнес крупный - и он ведется на статьи, вместо того чтобы иметь в штате консультанта, которому не надо рассказывать примитив выше - ну как бы ... я не видел такого )
И серьезно, ну хоть вики возьмите мифический человеко-месяц описание хотя бы. Регулярно на vc очередная фирма пишет почему дорого это хорошо на свой лад, в книге хоть по полкам разложено детально все (а заказчики - ну хз, не видел чтобы погружались в процесс, если не из IT, конечно).
Кейсы читал - там годная реклама.
Беда в том, что это не реклама. У текста фактически нет продающего посыла, он не нужен этому тексту.
Мифический человеко-месяц — это книга немного не о том, это сборник журнальных статей Брукса, которые лучше прочитать не в кратком пересказе, а в исходнике. Только тогда эта книга начинает приобретать ценность.
Что для клиентов. Реальный мир — штука сложная и интересная. Вот есть большой и успешный завод, у завода есть руководство. В руководстве сидят умные, сильные и компетентные люди. Но у них не получается в ИТ.
Этим людям приходится объяснять, почему в рамках завода работает одно, а вот в ИТ это уже не работает, там партии товара не выпускают. Причём объяснить эту очевидную вещь может только человек одного с ним уровня, остальные сгорают ещё на подлёте, какими бы умными они не были. Разница потенциала слишком высокая, они не выдерживают даже давления от простого общения.
У Максима Батыева в его книгах есть очень интересное правило: «То, что очевидно вам - не очевидно другим». Поэтому часто приходится разговаривать про очевидные вещи. Для одной стороны, для другой стороны, помогая им нащупать общую позицию.
Не знаю что у вас за завод, но обычно засылается БА, потом уже когда хотя бы частично на одной волне, начинаются разговоры.
Брукс это нормальное обоснование того, что вжух может не получится, но надо естественно предварительно включить мозг, чтобы донести до клиента.
Все остальное - демагогия, кмк. Против рекламы ничего не имею.
Бизнес-аналитики не всегда могут справиться из-за коммуникационного и культурного разрыва. :о)
вот то что вы в комментах пишите, на порядок полезней по-моему ) вот как раз эту хрень - как выходить, как обосновывать конкретные работы, как рекламить (помимо vc), ну наверное большому проценту было интересно. Как по полкам раскидать, чтобы тебя потом не нажучили за перерасход...
Кстати, да - Вы ответили на мой вопрос "Для кого и для чего написана эта статья?" )
Да хотя бы процесс минимизации багфикса до этапа тестирования. Или процесс сбора требований перед постановкой задачи в пул. И не надо говорить, что на эти темы написано десятки книг и ответ дать невозможно. Если процесс существует в реальности, он должен быть понятен и объекту и субъект данного процесса. В противном случае - это набор бесполезной писанины (это к моменту о "сложности")
Есть такое понятие, как разработка через багфикс. От неё помогает правильный учёт затрат на задачи. То есть считать надо совокупность всех затрат, включая тестирование и багфикс. После чего прожимать затраты вниз, ликвидируя источники их возникновения.
Затем можно переходит к такой вещи, как культура производства. Скорее всего, у вас не проблема в процессах, а проблема в отсутствии взаимного уважения в «команде» разработки. Люди работают не как «команда разработки», а как «стадо разработки», занимаясь локальной оптимизацией, не воспринимая проект либо продукт в целом, делая лишь то, что удобно им, не думая о других.
Если вопрос культуры производства уже решён, можно работать над процессами. Например, QA специалист может писать тесты ещё до того, как разработчик приступает к разработке, чтобы разработчик мог использовать их при отладке, не привлекая QA. Это заметно снижает затраты на итерации тестирования.
Есть ещё работа архитектора, который бьёт продукт либо проект на модули с внутренними границами, которые предотвращают регресс. Это немного иной процесс. Кроме него, такую работу может делать ещё и QA в его старом понимании (там были очень развиты навыки программирования).
И никогда не забывайте, что процессы выполняют люди. Любой самый хороший процесс можно испортить выполнением. Поэтому, сначала нужно понять откуда берутся эти самые ошибки, чтобы понять, что с ними можно сделать:
1) https://vc.ru/dev/440224-kak-pisat-kod-chtoby-tebya-ne-uvolili
2) https://vc.ru/life/445172-pochemu-vse-lomaetsya-dazhe-u-horoshih-programmistov
3) https://vc.ru/life/451990-pochemu-oshibayutsya-programmisty
4) https://vc.ru/life/477354-samoregulyaciya-v-it-minimalno-dopustimaya-effektivnost-raboty
Если вы более точно укажите стадию, на которой вы находитесь, я смогу более точно вам ответить.