NK
Как рождается техдолг
Бизнес приходит с какой-либо идеей — и он пробует ее сделать сразу и быстро. То есть с помощью ..., пустых банок из-под колы и палок. Бизнес-управленцы пробуют каким-то образом решить эту проблему в минимальные сроки.
Они привлекает либо аутсорсеров, либо от других своих проектов отвлекает разработчиков. В общем, буквально экономят на всём, пытаются за копейки сделать какой-нибудь мини MVP, с помощью которого проверить гипотезу. Допустим.
И неожиданно, точнее вполне ожидаемо, что в существующем каком-то продукте, на который высаживается эта проверка гипотезы, накапливаются остаточные явления от этих гипотез — одна-две-три-четыре, пока бизнес не нащупает работающую гипотезу.
Эти остаточные явления можно назвать культурными наслоениями. И это в принципе, наверное, оправданный подход, потому что пока вот эти супер дорогие программисты построят все по-правильному — и бабло в канализацию спустишь, и идея убежит, и все сроки пройдут. А так ты быстро на коленке собрал работающее MVP.
И погнали. «Оно» работает с помощью каких-то негров с опахалами, шамана, бивня мамонта, летающей китайской крысы и панголина.
Продукт обрастает вот такими культурными наслоениями, костылями и чем-то еще. Проблема еще заключается в том, что, так как гипотезы проверяются часто из «la merde» и палок, этим занимаются либо разные программисты, либо программисты работают по остаточному принципу. И они к этому относятся «а давайте-ка я тут попробую один метод программирования, а сейчас попробую другую концепцию». И в результате получается месиво подходов.
Вроде бы у тебя есть и решение, внутри которого кодом записано, как должен работать продукт. Но с другой стороны, там столько всего намешано, что, казалось бы, там функциональности с гулькин нос. Если все просто переписать, можно было бы вполне спокойно развивать продукт, но там ведь наскоками дают тебе пять минут раз в месяц позаниматься этим, ты прибегаешь туда и пока ты расковыряешь все эти зависимости… Документации же нет от слова совсем. Откуда там документация?
Соответственно, всё что ты можешь с этим сделать, как разработчик, делаешь исключительно так, как получится — и потом еще раз приходишь через месяц, тоже какие-то вещи подкрутить. И вот такой клубок получается.
Сами гипотезы-то быстро проверяются — берут программиста из какого-нибудь проекта, выдергивают его на пол дня, он быстро-быстро налепил и убежал, потом берут другого программиста или вообще фрилансера какого-нибудь.
В результате получается система, в которой столько всего накручено. Если выстрелила гипотеза, надо же развивать продукт, масштабировать, а нельзя, не получается, потому что цена разработки новой фичи, даже самой простой, удвоилась, утроилась, если не удесятерилась.
Готово!
Бизнес приходит с какой-либо идеей — и он пробует ее сделать сразу и быстро. То есть с помощью ..., пустых банок из-под колы и палок. Бизнес-управленцы пробуют каким-то образом решить эту проблему в минимальные сроки.
Они привлекает либо аутсорсеров, либо от других своих проектов отвлекает разработчиков. В общем, буквально экономят на всём, пытаются за копейки сделать какой-нибудь мини MVP, с помощью которого проверить гипотезу. Допустим.
И неожиданно, точнее вполне ожидаемо, что в существующем каком-то продукте, на который высаживается эта проверка гипотезы, накапливаются остаточные явления от этих гипотез — одна-две-три-четыре, пока бизнес не нащупает работающую гипотезу.
Эти остаточные явления можно назвать культурными наслоениями. И это в принципе, наверное, оправданный подход, потому что пока вот эти супер дорогие программисты построят все по-правильному — и бабло в канализацию спустишь, и идея убежит, и все сроки пройдут. А так ты быстро на коленке собрал работающее MVP.
И погнали. «Оно» работает с помощью каких-то негров с опахалами, шамана, бивня мамонта, летающей китайской крысы и панголина.
Продукт обрастает вот такими культурными наслоениями, костылями и чем-то еще. Проблема еще заключается в том, что, так как гипотезы проверяются часто из «la merde» и палок, этим занимаются либо разные программисты, либо программисты работают по остаточному принципу. И они к этому относятся «а давайте-ка я тут попробую один метод программирования, а сейчас попробую другую концепцию». И в результате получается месиво подходов.
Вроде бы у тебя есть и решение, внутри которого кодом записано, как должен работать продукт. Но с другой стороны, там столько всего намешано, что, казалось бы, там функциональности с гулькин нос. Если все просто переписать, можно было бы вполне спокойно развивать продукт, но там ведь наскоками дают тебе пять минут раз в месяц позаниматься этим, ты прибегаешь туда и пока ты расковыряешь все эти зависимости… Документации же нет от слова совсем. Откуда там документация?
Соответственно, всё что ты можешь с этим сделать, как разработчик, делаешь исключительно так, как получится — и потом еще раз приходишь через месяц, тоже какие-то вещи подкрутить. И вот такой клубок получается.
Сами гипотезы-то быстро проверяются — берут программиста из какого-нибудь проекта, выдергивают его на пол дня, он быстро-быстро налепил и убежал, потом берут другого программиста или вообще фрилансера какого-нибудь.
В результате получается система, в которой столько всего накручено. Если выстрелила гипотеза, надо же развивать продукт, масштабировать, а нельзя, не получается, потому что цена разработки новой фичи, даже самой простой, удвоилась, утроилась, если не удесятерилась.
Готово!
