Проблема новой версии

Как играть реальностью, используя несколько цифр и точку

IT = прогресс, IT = хайтех, IT = продвинутость – эти и другие подобные “аксиомы” сейчас на слуху.

Если вы спросите практически любого айтишника про то, какие задачи он решает в фирме, то вы с гарантией услышите комбинацию из чего-то вида “мы элита, мы работаем с информацией, а всё ведь по сути информация, поэтому мы по сути главные”.

Благодаря такому позиционированию наблюдается интересный эффект – когда что-то, являющееся сугубо айтишной темой, переносится из мира дистрибутивов и протоколов в неизменном виде в мир людей, порождая чудесные, весёлые, а иногда и откровенно опасные действия.

Одним из таких вопросов является т.н. “проблема новой версии”.

Постулат прост и выглядит примерно так:

Версия 3.0 лучше версии 2.0, потому что 3 ведь больше, чем 2. Версия 2.1 лучше версии 2.0, потому что 1 больше чем 0.

Свобода лучше несвободы наличием свободы, добавил бы Лев Щаранский.

Подразумевается, что в новой версии программного обеспечения всегда:

  • Исправляются проблемы
  • Улучшается работа существующих функций
  • Добавляются новые функции

Ну, или почти всегда.

Примеров – масса. Например, каждая версия Windows, судя по оценкам т.н. “независимых тестировщиков”, загружается быстрее, чем предыдущая. Ещё каждая версия быстрее делает типовые операции – типа отправки документа на печать. Ещё меньше потребляет ресурсов, потому что “внутри всё оптимизировали”. Можете проверить, поставьте Windows 95 OSR2 на систему с 4 МБ RAM и Windows 10 на систему с 4 ГБ RAM, и сравнив.

К этому порядку вещей все привыкли настолько, что считают его абсолютно и 100% всегда работающим. В результате имеется интереснейший синдром “апгрейд-прокрастинации”, когда человек бесконечно что-то обновляет и патчит, чтобы вот-вот начать работать, и никогда не начинает, потому что надо всё пропатчить и обновить на последние версии, потому что нет смысла же с устаревшими продуктами-то работать, ведь они ж априори неэффективные, в отличии от новых, а вот когда пропатчим, уж тогда… уж тогда-то зверски работать начнём.   Штука в том, что этот подход таит в себе ключевую проблему – новой версии, в силу того, что она новая, автоматически присваивается целый букет “типовых” свойств, который запросто может быть крайне далёк от реальности. Да, в новой версии могут исправить проблемы. А могут и не исправить. Могут добавить новые функции – но вполне могут и выпустить новую версию без них. Ведь её все равно поставят, и на неё все равно обновятся, потому что новое = лучшее, и точка. Кто не обновился – тот отстал. Тот, т.к. новая версия эффективнее, неэффективен.   Вы вполне можете наткнуться на ситуацию, когда версия, допустим, 5.0 будет не функциональнее версии 4.0 – производитель отделается текстом про “множественные улучшения”, программисты объяснят “там под капотом стало всё гораздо лучше, это снаружи не видно, но реально всё очень улучшили”, и в результате в сухом остатке новая версия будет просто новой.   И, что показательно, этого хватит, чтобы её стали использовать. Ведь она новая, а новая – она всегда функциональнее, в ней поправили ошибки… ну и так далее.   Перенос этой конструкции из IT в другие сферы приводит к тому, что любое новое автоматически подсознательно получает все эти “унаследованные” свойства, по сути не обладая ими.   Вот новый шампунь – он новый, потому что новый. Формула та же, эффективность, как обычно, измеряемая специальным методом, на 71% выше у 38% из группы в 59 человек, выбранных среди 189 людей со средним возрастом 31 год. Неудобные числа? Ну, так случайно совпало – главное, что он новый. Это новая версия предыдущей версии шампуня.   Вот машина той же марки, но модели 2016го года. Видите, она новее, а значит лучше. Что значит “по каким параметрам”? По разным. Она эффективнее, лучше, она новая, у неё улучшено существующее, добавлено новое. Всё это подразумевается, потому что новая.   В результате имеется удивительная по простоте рабочая схема – делать можно что угодно, главное подавать как новое, и потребители сами допридумают себе в голове удивительные преимущества. Этот самообман будет им приятен, потому что они будут ощущать своё приобщение к новому, и защищать его. Ведь если признаться, что новое было куплено взамен старого просто потому что “новое = лучше”, а по факту не так, то выйдет, что человек-то лажанулся, что он лох, а это неприятно и стыдно. Поэтому достаточно, чтобы продукт модельной линейки этого года был визуально отличим от предыдущего, а свойства ему допридумают. Машина? Ну, “раз обновили, то не могли ж просто так – видимо топлива поменьше жрать стала”. Удивительно, но это даже необязательно выдумывать, сами допридумают, по аналогии с реальными характеристиками.   В результате “у нового поколения мобильников доработан радиомодуль”, и так каждый раз, каждое поколение, а связь держат сопоставимо. Батарейка “эффективнее расходуется”, но ёмкость её только растёт. “Всё более экономичные автомобили” десятилетиями топчутся в тех же диапазонах расхода топлива. Всё новое, всё блестящее, обновись обязательно, кто ж версией 17.0 пользуется, если уже 17.2 есть, ха-ха, она эффективнее, потому что 2 больше, чем 0.   Прогресс идёт, числа версий щёлкают, модельные ряды обновляются, вопросы про конкретику улучшений считаются провокационными и на них отработанно пишут “раз вы подвергаете малейшему сомнению то, что версия 17.2 лучше 17.0, вы ретроград, вы против любого прогресса, вы за возврат в каменный век и никак иначе”.   Прогресс марширует по арене цирка, на каждом кругу обновляя надпись на плакате “Текущая версия”.   Можно ли что-то поменять? Нет, потому что данный логический парадокс удобен всем участникам. Производители могут даже не тужиться, чтобы соврать про мифические улучшения – их придумают покупатели, чтобы показать другим, что обновились не просто так. Покупателям надо как-то показывать, что они развиваются и находятся в тренде – для этого отлично подходит ритмичная смена изделий и товаров на актуальные модели. Лицам же, которые делают ретроспективу вида “слушайте, но ведь если посмотреть назад, нам раз в полгода революционные изменения в товаре Х обещают, а за лет 10 ничего не поменялось серьёзного по сути, кроме дизайна”, можно выставить публичное “фи”. И добить, например, обвинением в “не можешь держать темп нормальных современных нововведений, не тянешь уже, ха-ха”.   Замечу, что в данной ситуации производитель может даже не напрягаться, чтобы сделать что-то плохо работающее. Т.е. он вообще может не напрягаться. Ему надо сделать что-то, визуально отличающееся от предыдущего, чтобы у потребителя сработал триггер “Новая версия” – дальше всё допридумывается по аналогии.   Логическая ловушка “раз это МОЖЕТ быть и БЫВАЕТ в новой версии, то это ЕСТЬ в ЭТОЙ новой версии” экономит силы и время всем – поэтому её любят.   Что дальше?

Потом доработают

Специфическая ситуация на рынке труда, которая сложилась в IT-разработке, привела к возникновению целой субкультуры, кратко описываемой русским словосочетанием “тяп-ляп”.   Кратко говоря, выгодно сделать что-то как можно быстрее, чтобы “застолбить” кусок рынка, и по реакции на этот экспресс-продукт оценить – стоит ли доделывать, стоит ли развивать функционал.   Разрабатывается продукт Х, и ещё находясь в альфа-версии (т.е. не обладая 100% заложенного на уровне проектирования функционала), выбрасывается на потребителя. Ключевые пункты следующие – “это не кривое поделие, это мы вам даём возможность первыми соприкоснуться с новыми технологиями и решениями. да, все проблемы – на вашей совести, продукт не доделан”. В обмен на чувство сопричастности к прогрессу и развитию выдаётся нерабочий продукт. Да, разработчики могут с этого получить нужную и полезную информацию об использовании продукта – но именно могут, а не “обязательно получат и обработают, а после на её основании сделают какие-то действия”. А возможно, интерес к продукту будет низким, и его так и забросят.   В IT это обыденность. Оформленная в методологии экспресс-разработки, но с ключевой сутью “тяп-ляп”. Понятно, что выгодно, понятно, что кто первый, тот и прав – суть-то остаётся, “осознанно делаем некачественный продукт, потом разрулим как-нибудь, наверное”.   Перетаскивание этого во вне-IT-сферы приводит к совершенно волшебным по своей силе мысли решениям.   Вот, например, фирма Х рекламирует новый самолёт. Он будет лететь 50.000 километров со скоростью 3 маха, нести при этом 10 тонн нагрузки. Разработка оценивается в 50 миллиардов долларов. На неё просят 5 лет. Деньги выделяются, процесс стартует. Через 10 лет фирма Х показывает результат. Это самолёт, летящий 1.000 километров со скоростью 280 км/час, несущий два бидона. Модель “Кукурузник”. Все в шоке, и тут выходит человек и говорит:
Главное, что летает. Главное, что самолёт, а не, например, микроволновка или губная гармошка. Это значит, что ребята всё правильно делают. Ведь получился самолёт. И он летает – этого не отнять. А это главное для самолёта – тут со мной все согласятся. Следовательно, какая разница, что сейчас – потом доработают.
По сути проект полностью загублен – сорваны сроки, а у результирующего изделия ни один из реальных параметров не совпадает с теми, которые были в ТЗ.   Но благодаря “Потом доработают” проект магически превращается в успешный. Просто потом доработают. Ведь теоретически могут? Могут. А значит доработают.   Бессмысленно спрашивать что-то вида “И как вы себе это представляете?” или говорить “Проект-то уже пропал”. Не имеет смысла акцентироваться на несовпадении отдельных параметров. На всё это будет отвечаться то же самое – что это, по сути, альфа-версия. И она уже есть. А раз уже есть – то ребята работают. А значит доделают. Ведь могут же в принципе?   В результате такого подхода, притащенного из сферы “сделаем сто онлайн-игр про то, как надо бегемотом попасть в крокодила, какая-нибудь да выстрелит, вот её и доведём до ума – ведь с птичками и свиньями ж вышло”, реальный фильтр на невыполненные проекты теряется. Они все становятся зависшими в “ребята потом доработают”. Проекты, сожравшие все ресурсы и давшие на выходе нуль полезного, объявляются замороженными, дорабатываемыми, и в общем чтобы не обидно никому было. Мир набивается успешными руководителями успешных проектов, у которых хорошая статистика (как у боксёров, которых “выводят в топ”, устраивая “бои с мешками”) и нуль неудачных проектов. Только вот делать ничего не умеют. Но очень хорошая статистика, нуль неудач.   Схема совершенно бронебойная – она отменяет неудачи как класс. Всё объявляется постоянно дорабатываемым, поэтому никаких претензий в текущий момент времени быть не может. Такое, в общем-то, в части “постоянно дорабатываемым” для программного обеспечения вполне реально – его, софта, жизненный цикл подразумевает доработку, поиск ошибок, оптимизацию.   Но вот с самолётом получается как-то откровенно плохо. Потому что то, что самолёт когда-то, возможно, будет доработан – никак не объясняет, почему в данный конкретный момент времени, после затраты нужного числа ресурсов, не достигнут нужный результат. И не возвращает ресурсы и время.   Целые системы сбыта поддерживаются в устойчивом состоянии благодаря этой “логике”. “Вы купите товар сейчас – а потом другой товар, по его мотивам, станет даже ценным и полезным. И вот за это обещание отдайте денег сейчас”.   Можно ли что-то поменять в этой ситуации? Нет, потому что всех всё устраивает. Получается комфортный мир без проблем и неудач, где что угодно превращается в победу и успех, просто добавляя “ну так это сейчас оно не работает – а вот как доделаем, так заработает”. Заминая то, что по сути это явка с повинной “Мы осознанно делаем говно”. И что смакованием преимуществ некоего виртуального идеала, который когда-нибудь, не исключено, вполне возможно, в принципе будет, закрывается то, что сейчас ничего нет.   Что дальше?