Процессы в ИТ: Долго, дорого и не то
Многие привыкли к треугольнику Хопкинса (Быстро, Дёшево, Качественно), он же - треугольник ограничения проектов. Вместе с тем в бизнесе популярным стало: «Ох уж эти программисты: опять долго, дорого и не то».
Здесь мы рассмотрим, почему в ИТ делать некачественно - это долго и дорого, а высокое качество разработки снижает сроки и стоимость разработки. Без каких-то сложных терминов и простым языком.
Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп и один из идеологов концепции IT~BP — IT бизнес-партнёрства. https://itbp.org
Давайте с простого. Треугольник Хопкинса плохо работает не только в ИТ, он вообще чаще всего не работает, ведь у него очень узкая область применения. Например, мы делаем стальные миски из листового металла. Раньше для такой работы нужен был кузнец, каждая миска была уникальна, стоимость производства — высокая. Если нам нужно произвести партию из ста тысяч мисок, нужно много кузнецов, работа будет долгой и дорогой.
Сейчас для производства мисок хватит пресса и всего несколько операций на линии производства. Стоимость одной миски будет небольшой, они все будут одинаковыми и более качественными, чем миски, произведённые кузнецами. Кроме того, скорость производства мисок будет очень высокой.
Вот только нам понадобятся квалифицированные сотрудники для производства пресс-формы и обслуживания самого пресса, а ещё наличие электричества, проще говоря, инфраструктура. Без неё — долго, дорого и некачественно, с ней — быстро, дёшево, качественно.
Если вам пример показался слишком утрированным, то посмотрите, как в России производят кухонные ножи. Кузнецы и слесари против промышленного производства в 2022 году. Есть хорошие мастера, но промышленное производство всё равно выигрывает.
Идём дальше, треугольник Хопкинса действует только при изготовлении партий товара. Например, мы шьём партию курток. Мы можем использовать простые строчки, убрать промежуточный контроль качества, брать менее качественную ткань, как результат, получить более дешёвую и менее качественную партию товара в меньшие сроки. Помним, что работа людей — это и деньги, и сроки.
Но есть один нюанс. Вам эту партию товара низкого качества нужно будет ещё продать. Иначе говоря: «втюхать». Делать некачественно, но быстро и дёшево, можно только, если нет строгого и адекватного контроля качества итоговой продукции и у вас готовы покупать все, что угодно.
Когда контроль качества итоговой продукции есть, когда «втюхивать» не выходит, то получится обратный эффект. Много изделий уйдёт в брак. То есть будут дополнительные затраты денег и времени на выпуск бракованных изделий. Итог простой — долго, дорого и не то.
Что происходит в ИТ? В ИТ никто не производит партии товара, никто не делает «тиражирование». О каком тираже мы говорим, если для получения копии кода либо файла можно просто использовать комбинации клавиш «Ctrl + c» и «Ctrl + v»? Я утрирую, но стоимость копирования действительно очень мала.
Если вернуться к примеру с мисками, то ИТ делает для вас пресс и пресс-форму. Иначе говоря, ИТ даёт вам инфраструктуру, которая позволяет снизить себестоимость и нарастить объёмы. За счёт автоматизации процессов.
В цикле производства продукта в ИТ есть этапы:
Отладка. На этом этапе разработчик проверяет созданный им функционал на наличие ошибок и исправляет их. После этого функционал передаётся на тестирование.
Тестирование. На этом этапе произведённый функционал тестируется специалистом по тестированию. Если находятся ошибки, то функционал отдаётся на исправление, что подразумевает повторение процедуры отладки.
Регрессионное тестирование. На этом этапе проверяется, а не сломал ли новый функционал уже существующий и протестированный функционал. То есть не регрессировала ли система в целом. Найденные ошибки нужно исправлять, то есть повторять процесс отладки, тестирования и регрессионного тестирования.
Интеграционное тестирование. На этом этапе проверяется совместное действие функционала системы. Функционал может работать по отдельности, а вот совместно — нет. Если будут ошибки, то предыдущие этапы тестирования придётся повторить.
Если разработчик работает некачественно, то есть перекладывает ответственность на тестирование (разработка через багфикс), то итоговая стоимость начинает расти в разы.
Конечно, можно не тестировать, то есть переложить отладку на конечных пользователей. Их же тысячи на продуктиве. Но будет поток инцидентов и очень дорогой багфикс. А ещё запоротые партии продукта, которые производит процесс, подвергшийся некачественной автоматизации. То есть в совокупности затрат это будет очень дорого и очень долго.
Ещё есть состояние «технического дефолта». Это когда в системе накапливается столько недоработок и ошибок, что любое внесение изменений приводит к валу новых ошибок. Например, мы исправляет 1 ошибку, но получаем 10 новых. Исправляем 10 новых, но в замен получаем 200 свежих ошибок. Происходит крах системы, выйти из которого можно либо написав новую систему, либо проведя дорогостоящий реинжиниринг существующей системы.
В результате, те команды, которые привыкли работать качественно, производят функционал быстро и недорого. Потому что тратят меньше времени на исправление ошибок. Те команды, которые снижают планку качества, начинают работать дольше, стоимость производства функционала заметно растёт. А потом следует крах системы либо бизнеса в целом.
Чтобы разрабатывать качественно, нужны профессионализм и культура производства. Такие люди вам будут говорить, что можно качественно, быстро и недорого. Они знают, что падение скорости разработки и рост цены разработки — это проблемы качества. Плохо собранные требования, некачественно поставленная задача, непродуманная архитектура, разработка через багфикс, невнимательное тестирование и другое.
Профессионализм часто сочетается с требовательностью. С требовательностью к себе и другим. Профессионалы, обычно, не стесняются сказать человеку, что он делает что-то не так в их профессиональной области, объяснив при этом простым языком, почему они так считают. Даже если что-то не так делает заказчик.
Другие будут вам рассказывать, что, конечно, это долго и дорого, зато качественно. Пока их рыночную нишу не поглотит NoCode либо LowCode, как это сейчас произошло с лендингами, простыми сайтами и примитивными мобильными приложениями.
Подводя итоги
Можно сказать, что чем сложнее и объёмнее проект, тем строже нужно следить за качеством разработки. Если работать некачественно, то разрабатываемый продукт может просто не выйти в свет. Потому что развалится ещё по пути. Либо закончится бюджет. Или терпение заказчика.
Если вы дочитали до конца и поняли, что делать качественно это быстрее и дешевле, потому, что брака (и затрат на него) меньше, то спасибо вам.
Так а сами то процессы где? Ваш опыт какой? А так в статье набор банальностей: делайте лучше и не делайте хуже. Ваш заголовок украл 5 минут моей жизни
Какой из процессов вас интересует? Беда в том, что их много, они могут быть большими и с длинным описанием. Возможно, уже есть статьи на эту тему.
Что до набора банальностей. Если бы люди их понимали и не делали бы столь банальных ошибок, ничего такого писать не пришлось бы.
Угу, водолей очередной
- до вас слишком долго доходит, что вы свернули не туда;
+ вы привыкли всё доводить до конца;
+ вы неравнодушный и социально активный человек;
дочитал до конца. Понял, что это не про меня. Я сижу на окладе. Если сделал быстро и качественно, мне дадут другую работу. Если нет моей работы, дадут чужую. Поэтому работаю без лишней торопливости.
С точки зрения наёмного сотрудника такая позиция действительно может быть. Очень многое зависит от того, что будет происходить, если вы начинаете делать больше, чем от вас ожидают. Если просто повышают норму, не соблюдая баланс интересов, то такой взгляд на вещи будет в чем-то обоснован.
Но, можно столкнуться с тем, что норма в организации упадёт ниже рыночной, и организация закроется, придётся искать новое место работы. Либо организация просто возьмёт новых работников и нормы для них с рынка, опять придётся искать новую работу.
С другой стороны, бывают компании, в которых чем больше вы делаете, тем больше получаете. То есть соблюдается баланс интересов работника и работодателя. Здесь имеет смысл делать качественно, быстро и недорого.
Но, честно говоря, обычно вопрос о том, чем пожертвовать, то есть «скоростью», «качеством» либо «бюджетом», обычно ведётся не с наёмными сотрудниками, а между подрядчиком и заказчиком.
И, честно говоря, на месте заказчика мы бываем все, в простых бытовых ситуациях. Неумеха окажет нам услугу долго и дорого, потому, что придется переделывать. Профессионал отработает быстро и чётко, за работу придётся платить лишь один раз. Как-то так. :о)
Выскажусь с позиции заказчика.
Начну с примера, похожего на Ваши миски.
В 2019 году я захотел построить дачу. Как человек, далекий от строительства, я изначально предполагал, что достаточно рассказать словами, что мне нужно, и прораб все организует и построит. Но по сети полазив, понял, что все совершенно не так: нужен проект, причем хороший, иначе могут нагородить такое, что всю жизнь будешь чинить.
Нашел проектную фирму, которая по моему эскизу оценила, что разработка рабочих чертежей будет стоить 260 тысяч рублей. Причем, чертежам будет предшествовать архитектурный проект и что-то еще, всего 4 книги. И работа 3 месяца. А дом-то обычный, совковая ломаная крыша и размер 8х10 метров, только внутренняя планировка моя.
Тогда я нашел проектировщика-фрилансера, который за три недели мне все сделал за 22 тысячи рублей. И всего одна книга - внешний вид и рабочие чертежи.
А дальше еще смешнее - когда я с фрилансером рассчитался (мы в кафе сидели), то мы немного поболтали и выяснилось, что он работает как раз в той самой проектной фирме, и если бы я там заказал свой проект, то он бы его и делал! И получил бы от фирмы 15 тысяч.
А еще дальше еще смешнее - когда я передал проект строительной компании и приехал на стройку с проверкой, то выяснилось, что никакого прораба на стройке вообще нет, а строители - это случайные люди, которых по объявлению наняла компания для стройки моего дома. И проект они даже не открывали - просто перерисовали размеры в тетрадку в клеточку и строят по своему разумению!
Это я к затронутому Вами вопросу основательности и качества разработки.
* * *
Я часто привлекаю программистов-фрилансеров для небольших программных работ. И скажу Вам, что самые дорогие отнюдь не самые хорошие. И даже наоборот: они наловчились напускать тумана и у них куча прошлых разработок, которые они впихивают в ваш заказ, даже если они не вполне подходят, в результате чего все работает неустойчиво и очень медленно.
Вот реальный пример: за 55 тысяч рублей "матерый" фрилансер сделал страницу со скриптом, которая весит 3 Мб.
А другой за 4000 рублей сделал тоже самое, но она весит 88 Кб.
Так что не всё так просто, как в Вашей статье.