Многие привыкли к треугольнику Хопкинса (Быстро, Дёшево, Качественно), он же - треугольник ограничения проектов. Вместе с тем в бизнесе популярным стало: «Ох уж эти программисты: опять долго, дорого и не то».
Здесь мы рассмотрим, почему в ИТ делать некачественно - это долго и дорого, а высокое качество разработки снижает сроки и стоимость разработки. Без каких-то сложных терминов и простым языком.
Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в 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 Кб.
Так что не всё так просто, как в Вашей статье.
Это скорее уже подойдёт к другой статье, уже для ИТ-шников, где будет объясняться, что заказчик не полный олух и может посмотреть на рынок.
На самом деле, почему качество даёт скорость и снижает издержки, вы сможете по-настоящему почувствовать на серьёзных проектах, которые с помощью фрилансеров никто не делает. Ну, либо делает, но оно никогда не взлетает.
В остальном, я с вами полностью согласен. У нас были простенькие работы, на которых смотрели фрилансеров. Человек, который их подыскивал, потом достаточно эмоционально выразился об их наглости. У нас же ещё и техническая экспертиза есть, для нас некоторые разговоры выглядят ещё смешнее. Плюс есть статистика по тому, сколько какая работа реально стоит.
1. Утверждение, что треугольник подходит только для серийного производства, голословно и ничем автором не обосновано.
2. Треугольник как раз всегда 100% работает для отношений заказчик-исполнитель. И именно для этих отношений он всегда и подразумевался. Есть техпроцесс, на все этапы должно быть потрачено время. Это время должно быть оплачено.
Если заказчик хочет дешевле, то выкидываем из процесса или сокращаем время на одном или нескольких этапах, что 100% ведет к потере качества.
Вы с заказчиками видимо никогда не работали, а всегда были в башне из слоновой кости программирования. Да, программирование никто не сокращает, но сокращают время на разработку требований (ТЗ), на тестирование, на разработку документации пользователя и прочее, чтобы вписаться в бюджет заказчика.
Как бы я все ещё играющий тренер, поэтому сохраняю общение с одним-двумя заказчиками, на проектах которых у меня рост сотрудников происходит. Если мы говорим про «техпроцесс» в ИТ, то вы не совсем правы.
Обычно мы начинаем с объяснения, почему waterfall — это методическая абстракция, которая никак не должна работать, почему Scrum не гарантирует сроки и бюджет (либо не гарантирует наличие всего функционала), что такое инкрементно-итерационная разработка, почему нужно бить все на этапы, почему чёткие требования обязательны линь не первые несколько этапов, почему критично важно иметь сразу дорожную карту проекта, почему у заказчика поплывут требования по мере приобретения пользовательского опыта, почему мы такие строгие, жёсткие, но берём денег меньше, чем другие, и гарантируем результат бизнесу.
Кроме того, наши заказчики приходят к нам уже с негативным опытом. Им не сложно на их собственном опыте показать где и как были допущенные ошибки. Про треугольник они очень быстро понимают. Люди не очень компетентные в ИТ, но вот свой же бизнес они как-то построили, думать они умеют.
В статье подмена понятий.
Очевидно, что чем больше качество работы конкретных сотрудников, тем лучше. Не имеет никакого смысла снижать качество конкретных работ.
Но при этом, треугольник качество-сроки-бюджет на уровне проекта вполне имеет место, и этим надо управлять.
В IT низкое качество это может значить, что мы не фиксим некоторые не самые важные баги, не оптимизируем время выполнения части операций программы, ревью UI делается 1 итерация вместо 3х, и т.д.
Низкое качество - это дополнительные операции. В том числе и операции контроля. Например вы говорите о ревью UI, причем говорите о целых 3 итерациях. Это время и деньги.
А почему возникла необходимость в этом ревью? Кто что недоделал и кто что переложил на коллег?
Всегда считал, что присказку про "быстро-качественно-дешево" придумали исключительно для использования дизайнерами. Причем может использоваться как до (на этапе торговли):
— Почему так дорого?
— Зато быстро!
так и после (оправдание плохой работы):
— Что это ты мне такое нафигачил?
— А что вы хотели за такую цену и всего за неделю?
Риторика "оху... ж эти погромисты..." говорит только о бардаке в стане заказчика или в стане исполнителя, а скорее и там, и там.
В реале у нормального заказчика скоуп фиксирован, срок тоже, плюс-минус. Остается выбирать исполнителя, предлагающего минимальную цену. Сценарий "сделать за две копейки, но из говна и палок" отсекается постановкой задачи и критериями приемки, поэтому в нормальной "рыночной экономике" цена у всех поставщиков тоже будет более-менее одинаковой.
Если заказчик обладает экспертизой в ИТ, то я с вами согласен. А если нет, то чего ему остаётся делать? Например, заказчик это аффинажный завод? Золото делать и обрабатывать его они умеют, а вот в ИТ они не очень.
Ни задачу поставить, ни критерии приёмки описать, ни правильных людей нанять. Найм правильных людей требует очень большой экспертизы, которой на рынке очень не хватает.
Комментарий недоступен
его возьмут эникеем когда наконец-то развалится его контора
Так в чем измеряется качество работы разработчика? Есть разумная метрика, кроме количества потраченных часов?
Скоростью. Скоростью решения задач, скоростью внесения доработок. И объёмом накладных затрат. То есть сколько на час работы разработчика приходится часов тестировщика, менеджера проекта, аналитика либо ещё кого-то.
Хороший код быстро меняется и легко поддерживается. Плохой код сложно менять и часты случаи регресса. Код может быть плохим, даже если соблюдать все лучшие практики и ритуалы. Код может быть хорошим, даже если нарушены все мыслимые практики.
А вот количество потраченных часов — не самая лучшая метрика, лучше оперировать стоимостью в деньгах. Стоимость часа у каждого разная. Если итоговая (с тестированием, сдачей, поддержкой на продуктиве) стоимость разработки какого-то функционала с одним разработчиком 50К, с другим 100К, а в среднем на рынке у подрядчика 30К, то лишних вопросов не остаётся.
Лучше опираться на сквозные процессы, а не на искусственные метрики.
Адмирал Ясенхрен с нами!
Как жалко, что для решения таких проблем, приходится тратить адмиральский ресурс. Капитана уже не хватает же. :о)
Долго, дорого и не то. Нормальный процесс реализации крупных проектов. Не будет у заказчика "того" с первого раза. Это итеративный процесс. В котором аппетит приходит с едой. Реальность сроков, объективность задач и заполнение чеклиста.
Мы научились использовать инкрементно-итеративный подход. Он позволяет соблюдать и сроки и бюджеты, сохраняя гибкость.
Это не что-то новое в мире ИТ, но это сложный подход. Еще он требователен к архитектору, руководителю проекта и культуре производства внутри команды. Поэтому использовать методологии по инкрементно-итеративной модели могут не все команды.
Комментарий недоступен
Мы работали с Шеф-Маркетом, но сказать, что я делал это прямо своими руками, нельзя. Скорее, я иногда подключался к решению спорных вопросов с Сергеем Ашиным.
Мы помогали компании Шеф-Маркет решить их проблемы с ИТ в целом. На момент нашего прихода, их информационная система имела 3 версии API с перекрёстными ссылками друг на друга, плюс реализовывалась 4 версия API. Понадобился глубокий рефакторинг. Но в целом, наше участие было заметно в разработке сайта, мобильных приложений, клиентской системе, в аналоге ERP-системы, которая использовалась внутри ШМ. Мы проработали несколько нет, на последнем этапе просто отдавали в людей в аутстаф. Сейчас уже не работаем по собственной инициативе.
Высокое качество снижает стоимость разработки? Какое передергивание. Даже с мисками и с кузнецами. Создание инфраструктуры, оплата высококвалифицированного персонала почему-то выводится за скобки и бац - получилось дешевле. Чудеса. А кто платит за инфраструктуру? За обслуживание оборудования? За обучение, развитие и удержание персонала? Никогда качество не будет дешево, потому что требует огромных первоначальных вложений и высоких операционных расходов. И в ряде случаев даже многократная переделка низкоквалифицированным персоналом окажется дешевле.
Проблема в том что автор обобщил, крупняк, который у которого горизонт планирования не на день, определенно будет в выигрыше в БУДУЩЕМ, если все процессы будут реализованы на 100% от инфры, до методологий, тестирования, маркетингового плана и тп.
А так, в целом, рецепта универсального нет.
С низкой квалификацией - дешевле возможно, если времени много. Логичнее взять эксперта с наработками по теме, чем ждать пока научится на ошибках за ваш счет кучка начинающих.
Тут нет передергиваний. В ИТ стоимость исправление ошибок - высокая. Работаете некачественно - тратите много ресурсов на ошибки. Работаете качественно - не тратите много ресурсов на ошибки.
Как пример, представьте себе большую продуктовую ИТ-компанию со штатом из 1000 программистов. 400 из них пишут новый функционал, 600 исправляют ошибки за другими программистами и исправляют регресс. Основано на реальных событиях.
Поэтому, затраты на квалифицированные кадры, удержание и прочие — это такая мелочь на фоне всего остального. И беда в том, что найм квалифицированных кадров — требует экспертизы, организация работ — требует экспертизы, удержание — требует экспертизы. В Новосибирске есть компания Пуш-вуш, они как-то снесли всех HR-ов и полкоманды, как раз из-за ошибок при удержании и кратного роста стоимости разработки.
+1
Риторика "оху... ж эти погромисты..." говорит только о бардаке в стане заказчика или в стане исполнителя, а скорее и там, и там.
В реале у нормального заказчика скоуп фиксирован, срок тоже, плюс-минус. Остается выбирать исполнителя, предлагающего минимальную цену. Сценарий "сделать за две копейки, но из говна и палок" отсекается постановкой задачи и критериями приемки, поэтому в нормальной "рыночной экономике" цена у всех поставщиков тоже будет более-менее одинаковой.
Очень интересно вышло. Спасибо за минилекцию!
Качество разработки в первую очередь определяется качеством постановки задачи. Если постановку задачи делал малоопытный человек, то проблемы гарантированы и разработчики никакими своими процессами такой проект не спасут.
Огромное количество проблем современной разработки обусловлено именно падающей культурой определения требований.