Сроки
В разработке ПО существует неразрешимое противоречие — это оценка сроков.
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
С другой стороны, разработка порою в душе не е... вообще не знает, сколько надо времени, особенно если
- новая функциональность нетипична
- есть зависимости на другие команды
- будет задействована новая технология
- ТЗ надо сильно уточнять
- надо разобраться в логике легаси-кода
Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.
Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже.
Короче, предсказание сроков — это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии — честно, результат будет такой же. Херня полная.
Самый рабочий подход — это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.
Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10.
Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать… ну а всё-таки, сколько дней-то займёт?"
В итоге просто называешь какую-то магическую цифру и молишься Ктулху.
Вишенка на торте — это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо.
Метрика "успел/не успел" многим кажется хорошим фактором оценки работы программиста. Почему так? Потому что других вообще нет, и тут мы плавно переходим к следующему пункту
Оценка работы программиста
Противоречие: бизнесу абсолютно необходимо оценивать качество и скорость работы программиста, но это абсолютно невозможно сделать объективно.
Ни одной качественной метрики работы программиста не существует. Кто-то в древности пробовал оценивать количество написанных строк кода, но это совсем наивный подход.
Кто-то придумывает kpi для всей команды: скорость потраченных сторипоинтов за спринт, покрытие кода, количество вылезших багов на прод и тд. Но во-первых, это не оценивает конкретного программиста, а во-вторых, эти, казалось бы, конкретные цифры основываются на абсолютно эфемерных вещах.
Сторипоинт — это само по себе что-то нечёткое, люди постоянно спорят, что это такое, и часто приходят к упрощениям (а-ля "день работы"), так еще и с помощью них пытаются магически угадать сроки, а это смотри пункт 1. И не надо мне говорить про усреднение понимания этой оценки за несколько спринтов: в разных спринтах порой совершенно разные задачи, а часто еще и разные люди над ними работают.
Количество багов на проде зависит от покрытия тестами, от того, в какое легаси пришлось забраться в этот раз и т.д., т.е. нечеткий показатель.
Покрытие тестами — плохой показатель. Вопрос холиварный. Моё мнение, что есть места, связанные с деньгами или ключевыми вещами бизнеса, где надо покрывать вообще всю логику, но если есть богом забытый раздел внутренней админки, который не особо важен и 99% не будет меняться в будущем — там тестов надо чуть-чуть, если они вообще нужны.
Еще добавлю, любую метрику в цифрах при желании можно накрутить, причем обычно в ущерб системе, так как локальная оптимизация всегда вредит системе в целом.
Ктулху Фхтагн!
Есть такие вещи, как качество кода — абсолютно субъективный показатель, и тоже не везде в это качество надо упарываться, зависит от проекта и задачи.
Тимлид зачастую знает, кто плох, кто хорош (оценка производится опять же субъективно с помощью нейросети между ушей), но как оценить самого тимлида? Вдруг его нейросеть плохая? Вдруг он прикрывает друганов?
Выводы
Нет никаких выводов.
Можно пытаться уменьшить разброс сроков, уменьшая скоуп задач и поручая задачи тем, кто такое раньше уже делал, но это не всегда возможно.
Можно давать разработчикам некий процент от прибыли, чтобы у них была мотивация, и не оценивать вообще, но и это не всегда возможно.
В общем, на мой взгляд эти противоречия абсолютно неразрешимы, но если вы вдруг знаете какой-то магический способ, напишите в комментариях, что я дурак и ничего не понимаю, я всё это аккуратно соберу и сделаю пост в своём телеграм канале, в котором изначально и родилась идея для этой статьи.
Комментарии (125)
kost_tr
20.07.2023 06:44+3Мне нравиться вариант с оценкой через проработку архитектора и аналитика
Архитектор с помощью руководителя проекта (владельца продукта) делает границы технической реализации (определяет каналы, компоненты, технологии и технологические риски) - такие архитекторы есть, я их видел
Аналитик делает бизнес процессы (по шагам) и схему макетов (конечно лучше с дизайнером)
На основе результатов нарезаются технические и бизнес Истории
Итог отдаётся лидам разработки и тестирования (эти люди обычно знают реальные возможности разработки, они же знают их темную сторону), можно в 2-3 независимым, если есть возможность.
Такая оценка близка к правде
Соглашусь, что идеальных архитекторов, аналитиков, разработчиков и тестировщиков не бывает, но если у них горят глаза, обычно результат отличный
Shavadrius
20.07.2023 06:44+1Это если есть архитектор и аналитик. Часто - это одно и то же лицо и, к сожалению, ты.
Нужно как можно скорее делать MVP и напильником его, напильником, пока поток денег от заказчика не иссякнет.
Никогда нельзя заложить достаточно гибкости, чтобы не пожалеть об отсутствии гибкости в будущем...
kost_tr
20.07.2023 06:44Тут тоже есть инструмент, он немного спорный, но мне помогает
Дерево целей, это подход когда ты по ТЗ или наброскам ТЗ (таких к сожалению больше) обозначаешь цели и минимальные шаги по достижению. Сверяешь а бьется ли, бывает, что не бьется:))) И наполняешь набор из Историй
Тут уже только экспертиза и уточняющие вопросы разработке
Инструмент хороший, но надо потренироваться:)
OlegZH
20.07.2023 06:44+2С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
Если бы всё фичи были бы заранее известны, пронумерованы, поименованы и закодированы, то не надо было бы ничего заранее разрабатывать. Неразрешимое противоречие заключается, скорее всего, в том, что все всегда начинают с чистого листа (как будь-то до нас ничего не было и даже мы сами ничего ещё не делали, хотя... нет! делали! есть же "легаси"!), но никто не хочет пронумеровать, поименовать и закодировать.
А так было бы здорово иметь каталог фич (типа Периодической таблицы химических элементов) и знать заранее все характеристики.
AlchemistDark
20.07.2023 06:44Иногда фич так много, что они ни в какую таблицу не вылазят. А ещё даже MVP не готов...
OlegZH
20.07.2023 06:44-4С другой стороны, разработка порою
в душе не е...вообще не знает, сколько надо времени, особенно еслиновая функциональность нетипична
есть зависимости на другие команды
будет задействована новая технология
ТЗ надо сильно уточнять
надо разобраться в логике легаси-кода
Сразу возникает вопрос. Почему функциональность какой-то фичи может оказаться нетипичной? Разве набор фич не может быть ограниченным? Возьмите какую-нибудь задачу. Попробуйте расписать разного рода сценарии. Разве их не будет весьма ограниченное количество? Вот и надо один раз закодировать каждый сценарий (в виде рабочего компонента) и потом брать из готового каталога. Разве не так?
А команды? Кто распределял нагрузку между командами, что бы были такие патологические зависимости? Зачем же существует модульное проектирование? Неужели фича размывает границы между модулями? Если это так, то надо. вообще, новую систему делать. Разве не так?
Новая технология? Стоп. Когда что-то разрабатывается, то, разве, не утверждается список используемых технологий? Каждая новая технология содержит свой уникальный набор собственных внутренних нетипичных фич (см. п.1), которые будут размывать изначальную модульность (см. п.2).
Уточнение ТЗ представляется (лично мне) признаком ошибочности его составления. Например. (Я немного утрирую.) Сначала создавалась система, которая не предполагала никакого участия пользователей в редактировании материалов некоторого сайта. Затем, захотелось добавить новую "фичу" — редактирование. Но это же — совершенно другая система, другая идеология! При этом, заранее можно сеть и просчитать каждый вариант системы, для каждого варианта предложить свою архитектуру и разговаривать с заказчиком на уровне архитектуры, не на уровне фич. Разве не так?
А ещё пресловутое "легаси"... Все привыкли к тому, что берётся и правится уже существующий действующий код. Только зачем так делают? Меняется, ведь, спецификация системы. Значит, нужно повторить те же шаги. что и были раньше сделаны, но уже с новыми вводными данными. Тут ещё проблема в том, что всё делают в рамках одного языка программирования. А система должна описываться (проектироваться) на одном языке, а реализовываться при помощи генерации программного кода на другом языке. И править нужно первичное описание, а не конечную реализацию. Разве не так?
mixsture
20.07.2023 06:44Попробуйте расписать разного рода сценарии. Разве их не будет весьма ограниченное количество? Вот и надо один раз закодировать каждый сценарий (в виде рабочего компонента) и потом брать из готового каталога. Разве не так?
Их будет весьма ограниченное количество, это правда. Только бизнесу то нужен 1. А на проработку всех сценариев вы потратите х100 ресурсов. Я не видел пока бизнеса, который на такое согласен.
OlegZH
20.07.2023 06:44Только бизнесу то нужен 1.
Стоп. Почему, только 1? Если есть какая-то деятельность, подлежащая автоматизации, то там будет столько сценариев, сколько имеется предметных ситуаций.
AlchemistDark
20.07.2023 06:44С таким подходом ни один стартап не взлетит...
OlegZH
20.07.2023 06:44А почему этим должен заниматься стартап?
AlchemistDark
20.07.2023 06:44Но ведь стартапы тоже разрабатывают ПО и тоже сталкиваются с проблемами из статьи.
OlegZH
20.07.2023 06:44Противоречие: бизнесу абсолютно необходимо оценивать качество и скорость работы программиста, но это абсолютно невозможно сделать объективно.
Учёные давно занимают вопросами построения всевозможных систем. И всё, что подлежит оценке, оценивается (включая и временные затраты). Только никто этим не пользуется при разработке ПО.
В этом смысле, было бы крайне любопытно посмотреть на руководителя какой-нибудь конторы, который возьмёт только что сделанную и сданную заказчику успешно функционирующую систему, разложит по полочкам её составные части, выявит все зависимости, выделит смысловое ядро и построит движок, на котором могла бы "крутиться" такая система. А потом сравнит реальные произведённые затраты и те затраты, которые могли бы быть потрачены, если бы вот эта самая постфактум-разработка была бы проделана в реальности. "Движок" — это и есть то, что фактически нужно сделать. Вы продаёте заказчику "движок". Меняется ТЗ — меняется и "движок". Хотите ещё большей гибкости — создавайте "дижок" "движков". И, заметьте, это всё предельно очевидно. Разве не так?
SiGGthror
20.07.2023 06:44Учёные давно занимают вопросами построения всевозможных систем. И всё, что подлежит оценке, оценивается (включая и временные затраты).
И конечно нет никаких примеров когда их оценка была максимально далека от реальности? Мне в голову приходит как минимум 2.
OlegZH
20.07.2023 06:44+1В общем, на мой взгляд эти противоречия абсолютно неразрешимы ...
Самое главное противоречие — это противоречие между глубокой практичностью программистов на деле, и совершенной абстрактностью тех же программистов на словах. Почему, когда программист хочет поделиться какой-то проблемой, он произносит только общие слова? Почему программист не приводит конкретных примеров? Можно было бы посмотреть реальный проект, оценить способы и сроки исполнения, попробовать сделать то же самое при помощи других подходов, сравнить результаты, сформулировать выводы. Разве не так?
LaserPro
20.07.2023 06:44+12Потому что это невозможно. Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи. Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя. У них разный опыт. И они выбрали разные пути решения. И Вася был после кранча/болезни, а Петя после отпуска. И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки. И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после. А ешё за это время поменялся контракт взаимодействия с внешним сервисом. И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
OlegZH
20.07.2023 06:44Потому что это невозможно.
В обычной ситуации, скорее всего, невозможно. Но мы с Вами тут сидим и рассуждаем, что-то себе представляем. то есть — находимся в необычной ситуации.
Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Да, конечно. Но разве процесс проектирование не направлен на то, чтобы (в пределе) формализовать все "устные договорённости"?
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя.
Это у Вас есть какой-то тикет. Но, представьте, что нужно что-то сделать, так надо, сначала, назвать, что именно. Мы должны указать место, где должны быть произведены изменения, и описаны сами требуемые изменения. Как только это место найдено в спецификации (и на языке спецификации), Вася или Петя делают одно и то же и закрывают тикет. Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
И они выбрали разные пути решения.
Почему? Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений? Надо же понимать, что различные пути решения затрагивают различные аспекты уже существующей архитектуры, а какие-то требуют её изменения. Не все решения оказываются, таким образом, допустимыми.
И Вася был после кранча/болезни, а Петя после отпуска.
формализация процесса разработки ПО (на мой непросвещённый взгляд) должна гарантировать независимость разработки от такого рода привходящих обстоятельств, поскольку, при необходимости что-то сделать, каждый будет заглядывать в одни и те же места спецификации, руководствоваться одними и теми же положениями общих для всех документов.
И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки.
Вполне естественно, что, если Вася и Петя пойдут разными путями, то они получат и разные результаты. Вопрос в том, что должно происходить в тот момент, когда каждый из них принимает какое-то решение и собирается его реализовать. Вот тут и нужно провозгласить, что именно планируется сделать, и выяснить потенциальные недостатки, не дожидаясь конечного результата. Как можно пытаться кодировать то, что может быть забраковано? Пускать в реализацию, кажется, можно только то, что принято и утверждено.
И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
А ешё за это время поменялся контракт взаимодействия с внешним сервисом.
Кранты! Снизу постучали. Опять.
И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Если общая таблица оценок существует (построена), то варианты разработки выбираются из неё и только из неё. Если имеются неучтённые факторы, то нужно строить новую таблицу оценок. Всё, о чём я говорю, это вопросы целостности (непротиворечивости) описания. Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
LaserPro
20.07.2023 06:44+8Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
То что работает в мире "идеальных сферических сотрудников в вакууме" разбивается о скалы реальности.
Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
за такие слова в современно agile мире выгоняют с собеседований. Хотя это и правда так. Но так уж устроен мир разработки, такие тенденции сейчас на хайпе. И да, вы правы, это сложно, быть разработчиком. Ну так за решение сложностей компания и платит.
Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
Идеальный тикет именно такой. Жаль их не существует. Ибо проработка тикета до списка однозначных действий - и есть больше половины реализации. Об этом кстати сказано в обсуждаемой статье.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
проектирование проводится на нескольких уровнях. И детальное проектирование на нижних уровнях часто входит в тикет, или само по себе является отдельным тикетом.
Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений?
Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов. Вы не поверите, но когда я пишу письмо кому-нибудь, и мне нужно написать всего одну первую строчку приветствия (строго описанный тикет, не так ли?) у меня и то будет с лету 5-10 вариантов. А если хорошо подумать, то и гораздо больше.
если Вася и Петя пойдут разными путями, то они получат и разные результаты.
результат заказывает бизнес. И он часто оочень примерно знает какой ему нужен результат. Допустим бизнес хочет а-а-а-а-автомобиль. И даже четко описывает требования - 4 колеса, 4 двери, двигатель, коробка передач, руль, сиденья, фары и т.д. и т.п. Угадайте сколько возможных вариаций автомобилей можно ззапроектировать/произвести? Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям. А время на реализацию проекта будет разным. Т.е. разный результат - это нормально, пока он решает задачи бизнеса.
Как можно пытаться кодировать то, что может быть забраковано? Пускать в
реализацию, кажется, можно только то, что принято и утверждено.Манифест agile с вами несогласен) Любой код, любые принятые и утвержденные требования в будущем могут измениться и быть "забракованы". Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
с какой стати-то отменить? т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Простите, но мир так устроен. Есть компании, где всё идеально, и под каждую таску автоматически разворачивается отдельный тестовый стенд, со всеми сотнями сервисов, инфраструктурой, петабайтами обезличенных production-like данных... И есть реально существующие компании где часто нет тестеров, нет стендов, есть фиксированное количество стендов, стенды отличаются от прода, каждый стенд уникален как снежинка, развернуть и настроить стенд занимает от недели до месяца... Есть ли у компании ресурсы (а это может быть очень дорого) или есть ли руководства понимание/желание сделать хорошо - зависит не от разрабов и не от тимлидов, и даже не от ПО и ПМ-ов.
OlegZH
20.07.2023 06:44Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
Совершенно верно. Но переход на личности приветствую. Сейчас это очень нужно.
... Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов.
Для меня вопрос в том, что именно идёт в дело, что именно превращается в код. Придумать несколько решений можно, но почему-то Петя делает одно, а Вася — другое. Кто-то же даёт отмашку? Или каждый поработал самостоятельно и принёс решение?
Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям.
Мне трудно иметь дело с отвлечёнными примерами. Всё-таки, кажется, что на практике в Ваших тикетах встречаются более конкретные указания.
Манифест agile с вами несогласен)
Скорее всего, это так и есть. Но я не стремлюсь специально вступать с чем-то в противоречие. Я просто рассуждаю. Могу войти и в противоречие.
Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
А вот это уже очень интересно. Допустим, произошли изменения. Какие-то. Весь вопрос в том, что с эти делать. Как Вы будете "выпиливать" фичу из готового продукта? И какие варианты видоизменения могут считаться допустимыми? Как быть. если эти изменения потребуют видоизменения архитектуры самого приложения? Там, ещё, зависимости разные...
т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Подождите! В Вашем примере "Вася пилил фичу до рефакторинга всей подсистемы". Зачем же пришёл Петя уже после рефаторинга и снова стал пилить ту же фичу? Давайте уточним условия задачи.
Простите, но мир так устроен.
Да он устроен так, как устроен. Вы правильно это описываете. Даже я это понимаю, хотя опыта соприкосновения с этим миром не имею. (Когда-то давно соприкоснулся, но... один раз не считается.)
Меня же, например, интересует, почему положительный опыт не тиражируеся. И что было бы, если бы, например, agile не было бы? Что было бы вместо agile? Старый-добрый каскад? Всё крутится вокруг того, если способ сделать мир немного проще.
indestructable
20.07.2023 06:44+3Но разве процесс проектирование не направлен на то, чтобы (в пределе) формализовать все "устные договорённости"
Формализация договоренностей - это, собственно, и есть написание кода. И описание тикета всегда условно, и всегда содержит много неявных условий. Поэтому не выйдет.
OlegZH
20.07.2023 06:44И ещё. Давайте не будем ходить далеко.
Представим себе, что в нашем ведении находится разработка форума, вроде того, где мы сейчас сидим. Текущий способ редактирования сообщений представляется не очень удобным (нужно куда-то бегать мышкой, "скроллить" и ловить всплывающие меню). Хочется как-то модернизировать. Но как?
Ключевой вопрос — это вопрос о том, что является (должно быть) единицей обработки. Традиционно считается, что единицей обработки является отдельное сообщение (пост). Мы можем вручную вырезать нужный фрагмент и оформить цитату. Но удобнее сразу иметь возможность прокомментировать конкретный фрагмент, неправда ли? Для этого надо, чтобы единицей обработки было отдельное предложение. Тогда каждый пост можно будет развернуть в виде набора атомарных постов, и реализовать наборы типовых операций над отдельными предложениями или их наборами. В результате, Вы получаете обратно Ваш текст, но уже размеченный Вашим собеседником. И так — для каждого Вашего собеседника. Да и в пользовательском интерфейсе не надо будет решать проблему линейного/иерархического отображения реплик, а пользователь сам будет определять, в каком виде реплики будут отображаться (автоматически).
Выбор единицы обработки определяет архитектуру системы.
Или, другой например. Вот, когда мы смотрим ленту Хабра и переходим на новую страницу, что происходит? К БД посылается запрос, получить соответствующий набор статей на момент совершения запроса. Это означает, что, пока Вы сидите на одной странице, проходит время, за которой на Хабре появились новые статьи, происходит сдвиг. В результате, Вы снова получаете ряд уже виденных Вами на предыдущей странице статей. Спрашивается, это что: "баг" или "фича". Нужно ли это исправлять? Например, можно было бы запомнить самую последнюю статью на момент захода пользователя на Хабр, а все новые статьи отображать на отдельной странице ("новые"). И тогда не будет никаких сдвигов, всё будет логично и понятно. Разве не так?
Но! Кто-то сделал то, что сейчас работает? Интересно, как этот разработчик объяснял себе странное поведение ленты? И что будет делать этот разработчик, если дать ему новый тикет, попросив его переделать отображение ленты?
vedenin1980
20.07.2023 06:44+1Выбор единицы обработки определяет архитектуру системы.
Мне кажется, вы уходите куда-то не туда. В любом форуме есть бек и есть фронт. Если мне нужно реализовать возможность цитирование предложений (хотя на самом деле удобнее выделенного текста, так как выделить преложение из поста очень нетривиальная задача, которая не решается алгоритмически в общем случае) я это сделаю на фронте, а бек получит всего-лишь набор тегов с цитатой и новым сообщением. С точки зрения 99% программы никакой "единицы обработки" в виде предложений не будет, а будет просто механизм добавления нового поста под старым.
ИМХО, у вас оверинженериг получается.
OlegZH
20.07.2023 06:44Вот и приходится мучиться. Вот бы однажды попытаться что-то-нибудь своё сделать на эту тему...
Gryphon88
20.07.2023 06:44Жаль, что в статье ничего нового. Вопрос простой: а как решают в других инженерных профессиях? Разработка была задолго до IT, и тоже как-то надо было сроки угадывать, даже более строго, прототипирование и тестирование в железе жручее и тоже плавающее.
LaserPro
20.07.2023 06:44+5Да никак не решают. Вы же слышали про долгострои и переносы сроков в куче других областей. И в самолетостроении, машиностроении, и гражданском строительстве, и в "законотворчестве", искусстве. С ростом сложности, все больше неопределенности. Чем дольше срок, тем больше погрешность. Чем больше творческого и умственного труда, тем больше неопределенности. Зачастую менеджмент, просто не видит разницы между программированием и простым механическим, физическим трудом.
"Законы Мёрфи", наверное, тоже все читали.
mixsture
20.07.2023 06:44+1Разница многих областей с ИТ в том, что там часто делают "то же самое" с небольшими изменениями. А в ИТ почти всегда хотят уникальное. Поэтому мы сравниванием "производство" vs "полноценное r&d + производство". И вот это r&d все меняет. И оценке поддается очень плохо, т.к. является "грязной проблемой".
Собственно, r&d всегда такой в мире. Просто мы ошибочно равняем ИТ к производству.OlegZH
20.07.2023 06:44+1А в ИТ почти всегда хотят уникальное.
Вот почему очень нужны примеры. Хочется увидеть это уникальное.
AlchemistDark
20.07.2023 06:44У меня есть четыре банковских приложения и они все разные. Иногда даже разный функционал.
OlegZH
20.07.2023 06:44А Вы можете кратко описать эти приложения (если есть возможность ничего не разглашать)? В чём принципиальная разница между ними? И можно ли найти что-то общее (в плане реализации)?
AlchemistDark
20.07.2023 06:44Я их не разрабатывал, я клиент этих банков, так что вряд-ли могу что-то секретное разгласить.
Попробую описать (очень примерно):
ВТБ: на главном экране вверху ссылка на репозиторий, где можно скачать обновлённое приложение, потом идёт витрина с продуктами банка и только ниже список моих счетов. Потом идёт список возможных способов оплаты (СПБ, QR). Ниже идёт список уникальных продуктов банка и курс валют. Кроме того есть выплывающая снизу навигационная панель.
Росбанк: на главной сначала идёт список счетов и только потом витрина с услугами, потом поиск банкоматов. Вместо перечня способов оплаты идёт меню «быстрые действия», потом курсы валют. Панели навигации нет совсем, да и в принципе главный экран беднее экрана ВТБ. Хотя и не факт, что это плохо.
Альфа-банк: на главной вверху ссылка на репозиторий, потом список счетов, но не полностью. На полный список ведёт отдельная ссылка. Вместо витрины идут «персональный предложения банка», типа не «кредит под 100500% годовых», а «Вам одобрен кредит под всего 100500% годовых». Ниже идут предложения типа «Пригласи друга и выиграй 1000₽». И ниже идёт ещё что-то вроде смеси витрины и рекламы.
Панель навигации тут не всплывающая, а фиксированная. И там есть отдельная страница «Витирина».
Тинькофф описать сложно. Сравнивать его приложение с приложениями других банков это как сравнивать кнопочный телефон со смартфоном. В разное время там могут появляться и казуальные игры, и статьи по психологии и многое другое. В него встроены сервисы для покупки любых билетов от кино до самолётов, доставки еды и чёрт знает чего там на самом деле нет. Есть даже бот-секретарь, который отвечает на телефонные звонки (если его включить).
В плане реализации там наверное много общего. В конце концов основной функционал один и тот же (открыть/закрыть/пополнить счёт, перевести деньги) но вот второстепенные функции, дизайн и логика навигации по экранами (а соответственно и логика приложения) сильно разные.
thevlad
20.07.2023 06:44В других инженерных профессиях это решается, тем что делается примерно одно и то же, постепенно, итеративно с "минимум научной новизны" на каждой итерации изделия. Или по крайней мере балансировкой, и пониманием что лишняя "научная новизна", может утопить проект.
nronnie
20.07.2023 06:44+2Недавно на "Радио-Т" было "правило 80/20 для контракторов": на любую задачу возьми минимум 80 часов, а потом умножь их на 20 :))
Gryphon88
20.07.2023 06:44А там не было про то, как убедить заказчика оплачивать этот длительный банкет?)
nronnie
20.07.2023 06:44Ну, если серьезно, то я работал когда-то с финнами. У них, по сути, вообще без разницы какой срок ты назначишь. День, два, неделя, месяц - им вообще пофиг. Но, не дай боги всей Вальхаллы, если ты не сделаешь в оговоренный срок, то тебе полный песец - порвут на части.
boldape
20.07.2023 06:44+5Я не помню как называется феномен когда много людей давали оценку количеству конфет в большой банке. Суть в том что никто не угадал при чем сильно не угадали, но участников было достаточно, что бы среднее значение оценки было ну очень близко к точному. Попросите много людей анонимно оценить срок И степень уверенности оценки. Дальше переведите уверенность в диапазон от 0 до 1. Поделите оценку на уверенность. Сложите все вместе и посчитайте среднее. Если феномен имеет место быть в реальности то чем больше оценок у вас будет тем точнее будет результат. Анонимность важна т.к. устраняет корреляции в оценках, но это противоречит устоявшейся практике командной оценки где нужна единогласная оценка. Этот способ организационно сложный и требует понимания всех участников зачем они это делают, ведь всегда нужно больше тасков закрыть, а эта деятельность не помегает их закрывать поэтому проще читать ТЗ по диагонали как можно быстрее и дать не совсем уж явно рандомную оценку тоже побыстрее, что бы наконец вернуться к текущим задачам.
У нас часто так, планирование спринта, покер, все показывают оценки, часто бывает разброс и большой. Крайние оценки начинают спрашивать, почему вы видите задачу не так как другие, суть в том что вежливо склоняют через переговоры прийти к единому мнению. А зачем вам всем обезличенное единое мнение? Попросили мое мнение я его дал, а потом такие ну не очень то твое мнение хорошее, давай меняй. Я в такие моменты вообще не спорю сразу соглашаюсь на любую предложенную цифру, потому что во первых это не мое мнение я свое не поменяю, а во вторых задача будет сделано не раньше чем будет сделана, а про цифры все забудут и очень быстро. Мало того после решения начать работу над задачей на эти цифры вообще никто не смотрит. Так зачем тогда тратить время на обсуждения? Просят помочь с оценкой я стараюсь как могу, но почему то у меня остаётся неприятное ощущения от процесса и помогать уже и не особо то и хочется. Твоя оценка выбивается давай ка ты ее поменяешь на удобную нам, да пожалуйста, а зачем тогда мое мнение спрашивали?
Apxuej
20.07.2023 06:44Статистический эффект имеет место быть, однако такой способ будет работать, только если исходить из предположения, что все в команде будут давать честную оценку. Т.е. ту, которую считают реальной. Если кому-то выгодно завысить оценку срока выполнения, а в целом это выгодно всем кто не собирается надолго задерживаться в компании, так как нужно будет выполнить тот же объём работы за более продолжительный промежуток времени. В итоге бизнес станет менее конкурентоспособным и это в конце концов негативно отразится на доходах компании. Причём отделить саботажников от реально понимающих людей нереально так как у нас анонимность.
thevlad
20.07.2023 06:44Усреднение имеет смысл, если центр распределения оценок близок к реальному результату. Если большинство ошибается, или на самом деле право некоторое меньшинство, усреднение нечем не поможет.
ayevdoshenko
20.07.2023 06:44+4Проблема в том, что даже в адекватно прописанном в ТЗ и знакомом по опыту функционале всегда остается много неопределенности, если даже вам вдоль и поперек знакома фича по предыдущему опыту - это вовсе не означает что вы:
Точно идентифицировали фичу - вполне может быть, что заказчик подразумевает нечто иное.
Фичи практически никогда не бывают одинаковыми - иначе, как и было подмечено, разработчики бы тупо собирали ПО из давно сделанных кирпичиков - но нет, каждый раз свои нюансы.
Практически ни один проект не обходится без внесения изменений в процессе разработки - как бы там ни божился заказчик и как бы опытен ни был аналитик/архитектор.
Из известных мне и более-менее рабочих способов гадания на сроки - это закладка риска: то есть определяешь сколько по твоему мнению на разработку фичи нужно времени и добавляешь на неопределенность еще 15-20% времени - как раз на то, что фичу неправильно понял, фича будет меняться и/или возникнут другие непредвиденные обстоятельства.В целом это работает, но не в минимум двух случаях:
Нет опыта реализации подобного - соответственно не от чего отталкиваться. Частично решается тем, что проводишь экспресс изучение темы - хотя бы где и что надо узнать из технологий и сколько времени уйдет на уже изучение исходя из объема материала - плюсуешь к времени разработки. Работает плохо, но лучше, чем ничего.
-
Большие системы подчиняются законам математического хаоса, бишь нелинейны - и все факторы неизвестности в них вызывают мультипликативный рост сложности. Если проект большой - даже при хорошей декомпозиции на задачи это не значит, что общее время выполнения этих задач влезет в те самые 15-20% прибавки на риск - увы, но тут разброс растет в геометрической прогрессии. Поэтому, собственно, рассчитывать на точность оценки крупного проекта вообще не стоит - тут надо идти итерациями, от MVP.
cliver
20.07.2023 06:44В разработке ПО существует неразрешимое противоречие — это оценка сроков.
Просто этой конкретно проблемой часто не занимаются из-за лени менеджеров и прочих ЛПР и "особенностей" бизнеса. С технической точки зрения можно попытаться решить приблизительно следующим образом
Требуем разработчиков оценивать время выполнения работ, собираем статистику
Чтобы устранить влияние прочих факторов, даем стимулы для разработчика:
Выполнишь задание быстрее - получишь больше
Добавляем еще за достоверную оценку времени своей работы (если угадал - получил премию за оценку)
После сбора статистики строим вероятностную модель распределения оценок
Вводим в эту модель функцию риска неправильной оценки сроков (бизнес-требования)
Получаем конечную цифру срока для заказчика
Тут может показаться, что награждать разработчиков за быстрое время выполнения - скользкий путь, но надо понимать, что тут как раз уже наступает реальное противоречие между хотелками бизнеса и приоритетами разработчика. Как эту проблему решать - это уже немного другой вопрос. Во всяком случае стимулы из п.2 нужны для того чтобы
не возникало желания работать "на расслабоне"
у разработчика не возникало желания оттянуть время выполнения до своей оценки, чтобы получить премию за оценку
laatoo
20.07.2023 06:44+1в переводе: берем тык пальцем в небо от разраба, добавляем разброс разных тыков, получаем средний разброс тыка, берем статистику тыков, считаем тыки нормально распределенным значением, 2-3 разброса тыков от тыка, и вдруг получаем конечный срок.
считали на тыках а получили срок?)
это не работаетcliver
20.07.2023 06:44Это работает, просто бизнесу нецелесообразно заниматься этой ерундой (в большинстве случаев). Поэтому никто не занимается и продолжают тыкать. Никто не хочет переводить вопрос из разряда словоблудия менеджеров в техническую плоскость, да и не надо.
Я вообще в первом комментарии не написал, что стоит так поступать. Я написал, что стоило бы сделать, если технически попытаться решать такой вопрос.
laatoo
20.07.2023 06:44докажите что это работает, и вы перевернете индустрию.
спойлер: вы не докажете.
то что вы делаете - вы строите модель распределения тыков. причем тут срок?
cliver
20.07.2023 06:44Чтобы доказать что это работает, нужно лишь доказать, что оценка времени выполнения задания программистом дает информацию о реальном времени выполнения им задания.
Вы утверждаете противное? Во всяком случае, строго говоря, нужно исследование на состоятельность этой нулевой гипотезы.
laatoo
20.07.2023 06:44нужно лишь доказать что оценка времени выполнения задания программистом дает информацию о реальном времени выполнения им задания
дает, конечно: коэфициент корелляции где-то между 0 и 1 в каждом отдельном случае
ayevdoshenko
20.07.2023 06:44Вам же объяснили уже, что в большой системе - нелинейные зависимости между входящими данными и результатом. Так же точно происходит с предсказанием погоды - это же уже исследовалось, и даже понятно почему так происходит - погуглите Эдварда Лоренца с его "эффектом бабочки".
LaserPro
20.07.2023 06:44+2Требуем разработчиков оценивать время выполнения работ, собираем статистику
статистика - это когда у вас есть данные о распределении соотношения значений величны какого-то выходного параметра, и значений каких-то входных параметров. Если что это "неканоничное" определение.
Так вот входные параметры - это буковки, которые составляют описание таски. Плюс текущее состояние проекта и его кода. Плюс состояние документации. Плюс опыт и знания разрабов. И вот уже это - неразрешимая проблема. Вы просто не сможете качественно классифицировать входные параметры, чтобы по ним собирать статистику значений выходных параметров.
Чтобы устранить влияние прочих факторов, даем стимулы для разработчика
это просто смешно. Вы недооцениваете разрабов. Любые подобные метрики "оптимизируются" на раз-два. У вас начнётся банальная "инфляция" оценок - ставишь огромную оценку, и у тебя есть время и для того чтобы "оценка" оказалась "верной", и даже чтобы "выполнить задание быстрее". Возможно даже будет оставаться время на сериалы и леваки. Хотя тут у вас прямо очевидное логическое противоречие. Ведь если выполнил быстрее - значит оценка неверна %))
После сбора статистики строим вероятностную модель распределения оценок
И она вам показывает что:
одна и та же задача "добавь в систему новый отчет" может занимать как 2 часа, так и 2 недели, так и 2 месяца. Средняя оценка в 2 недели - в большинстве случаев будет неверной.
"вероятностная модель распределения оценок" вообще не совпадает с результирующим распределением времени затраченного на выполнение.
Получаем конечную цифру срока для заказчика
которая имеет мало общего с реальностью.
cliver
20.07.2023 06:44Любые подобные метрики "оптимизируются" на раз-два. У вас начнётся банальная "инфляция" оценок - ставишь огромную оценку, и у тебя есть время и для того чтобы "оценка" оказалась "верной", и даже чтобы "выполнить задание быстрее".
Вы не привели контрпример. Если разраб будет оттягивать оценку на поздний срок, он будет гораздо больше терять за медлительность работы. Выплаты разрабам за быстроту работы не связаны с их оценками.
Хотя тут у вас прямо очевидное логическое противоречие. Ведь если выполнил быстрее - значит оценка неверна
Нет противоречия. За быстроту работы получаете больше, чем теряете за неугаданную оценку.
LaserPro
20.07.2023 06:44Выплаты разрабам за быстроту работы не связаны с их оценками.
А что такое "быстрота работы"? Разве не выполнение в соответствии с оценкой или быстрее? И если нет оценки - то нет и "быстроты".
Или вы предлагаете количество набираемых символов в секунду считать?cliver
20.07.2023 06:44Я повторяю опять. Прочитайте https://habr.com/ru/articles/749206/#comment_25770458
Я не рекомендую так поступать. Я лишь описал возможный способ решения проблемы технически. Я не утверждал что это делать целесообразно. Как судя по тому что получилось нецелесообразность в большинстве случаев бросается в глаза. Если у вас критика технического подхода описанного выше - приводите контрпримеры. Если можете написать лучший технический подход - напишите какой.
LaserPro
20.07.2023 06:44Вы в своем "техническом" подходе вводите какие-то абсолютно нетехнические термины, вида "быстрое время выполнения" (время не бывает "быстрым", мы же не теорию относительности обсуждаем) , "быстрота работы" и "медлительность работы". И даже не можете объяснить что они значат и как именно вы предлагаете их считать.
И почему-то предлагаете мне "сперва добиться" и придумать техническое решение задачи, которая на данном этапе развития не имеет такого решения (о чем и пишет автор обсуждаемой статьи, и с чем я согласен, исходя из своего личного многолетнего опыта)cliver
20.07.2023 06:44Я в одном комментарии не мог всю теорию вывести, просто привел приблизительное направление решения. Естественно точно, с доказательствами я не смогу на 10 минут все написать. Вот именно из-за этих нюансов, нецелесообразность бросается в глаза. И в большинстве случаев не надо заниматься этой ерундой.
Выплата разрабу - некая монотонно убывающая функция от времени выполнения задания.
Премия за оценку - тоже некоторая функция от разности между оценкой и реальным значением. Соответственно, нужно подобрать эти функции так чтобы у разрабов не возникало желания схитрожопить с манипуляцией оценками и времени своей работы.
cliver
20.07.2023 06:44И почему-то предлагаете мне "сперва добиться" и придумать техническое решение задачи, которая на данном этапе развития не имеет такого решения
Дело не в том, что она не имеет решения. Дело в том, что ее решение вероятно оказывается сложнее чем сам процесс разработки. И даже если ее решить и получить результат, вероятно мы не получим значительного выигрыша с точки зрения бизнеса, по сравнению с затраченными усилиями или прочими подходами. На выходе получаем - нецелесообразность.
Есть большая разница между "проблема не имеет решения" и проблема имеет решение, но решать ее нет смысла в определенном контексте.
cliver
20.07.2023 06:44Вы в своем "техническом" подходе вводите какие-то абсолютно нетехнические термины, вида "быстрое время выполнения" (время не бывает "быстрым", мы же не теорию относительности обсуждаем) , "быстрота работы" и "медлительность работы". И даже не можете объяснить что они значат и как именно вы предлагаете их считать.
Согласен, термины не технические. Если у вас есть желание дальше в эту дыру лезть, могу попытаться дать более строгие определения.
Идея в том, чтобы
"Нагрузить разрабов", для этого ввести стимул оплаты в зависимости от времени выполнения. Соответственно, у разраба нет резона манипулировать своей работоспособностью, так как это ему стоит денег.
Ввести стимул за точную оценку выполнения задания, чтобы разраб не называл числа с потолка
Далее получаем, что чтобы получить нужные числа, похоже приходится вводить какие то бредовые условия, которые вряд ли совместимы с текущими принятыми в данной организации и другим порядком вещей.
piton_nsk
20.07.2023 06:44"Нагрузить разрабов", для этого ввести стимул оплаты в зависимости от времени выполнения
Для этого надо уметь точно предсказывать срок, т.е. получается замкнутый круг.
Про то что разрабу станет выгодно сроки завышать уже написали, ну и еще вылезет много всяких проблем. Например выгодно будет брать простые задачи типа поменять надпись на условной кнопке, а сложные брать никто не захочет, т.к. там оценку дать намного сложнее и в итоге это будет бить по карману.
cliver
20.07.2023 06:44Для этого надо уметь точно предсказывать срок, т.е. получается замкнутый круг.
Я не понимаю, почему вы вдруг решили что нужно предсказывать срок. Размер оплаты - некая монотонно убывающая функция от времени выполнения задания.
Про то что разрабу станет выгодно сроки завышать уже написали
Почему выгодно? Выгодно остаться без премии за хорошую оценку сроков? Выгодно ждать и оттягивать до своей завышенной оценки и недополучать деньги за медленность работы?
piton_nsk
20.07.2023 06:44Как вы можете понять что работа сделана медленно или быстро, если вы не можете достоверно оценить сроки?
Я может что-то не так понял, разве у вас размер оплаты это просто функция одного параметра (времени на выполнение задачи)?
cliver
20.07.2023 06:44Я может что-то не так понял, разве у вас размер оплаты это просто функция одного параметра (времени на выполнение задачи)?
Да
piton_nsk
20.07.2023 06:44+1Ну и кто тогда будет делать длительные по времени задачи? Это же в чистом виде удар по своему кошельку. А если брать поправку на сложность/длительность задач, то мы возвращаемся в начало замкнутого круга)
cliver
20.07.2023 06:44Я не предлагаю для всех задач одну и ту же функцию использовать. Можно умножить на подходящую константу.
Вы просто поймите, что этот огород только для того, чтобы сказанные числа и оценки действительно имели значение, а не были просто спекуляциями. Может есть другие способы, просто если вы захотите вытрясти из людей некоторые числа, они будут ориентироваться на свои интересы, а не на интересы изначальной задачи оценки сроков.
Типа из серии, сегодня нет хорошего кофе, поэтому работаем "на расслабоне", оценки по срокам завышаем.
cliver
20.07.2023 06:44Например выгодно будет брать простые задачи типа поменять надпись на условной кнопке, а сложные брать никто не захочет, т.к. там оценку дать намного сложнее и в итоге это будет бить по карману.
За сложные задачи можно и цену увеличить, на то они и сложные. Да, согласен в этом ракурсе появляются новые проблемы. Поэтому я и не предлагал лезть в эту "дыру".
Похоже это все ведет к такой области как дизайн механизмов. Несмотря на название, это не про механику.
cliver
20.07.2023 06:44Разве не выполнение в соответствии с оценкой или быстрее?
Нет. Я же написал, что выплаты разрабам за быстроту работы не связаны с их оценками.
ayevdoshenko
20.07.2023 06:44А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты - нам нужна функция - что на входе и как рассчитывается результат этой функции : ))) А так - это напоминает старинный мем:
1. Быстрота
2. .....
3. PROFIT!!!111cliver
20.07.2023 06:44Я вам должен всю теорию в одном комментарии был написать? Я же написал "приблизительно". Естественно все нюансы нужно учесть, чтобы просто так не получилось схитрожопить с оценками. Если у вас более изящный подход есть, огласите.
ayevdoshenko
20.07.2023 06:44"Приблизительно ворочать мешки" и "ворочать мешки" - это две большие разницы. Именно здесь чаще всего и возникают недопонимания между заказчиками, которые же приблизительно точно знают чего хотят - и программистами, которые должны уже однозначно точно дать указания компьютеру что он должен делать : ) Впрочем, это лирика. А насчет долженствований - да я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной по озвученной мной и некоторыми другими участниками нашей беседы причинам. Поэтому надо смотреть "конкретный код", а не оперировать очередными неопределенностями - такая у нас работа.
cliver
20.07.2023 06:44я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной
Проблема 1
Как заставить разработчиков не манипулировать временем выполнения (оттягивать срок выполнения)?Проблема 2
Как заставить разработчиков не манипулировать временем оценки?Для этого и предложил вещи из пункта 2. Опять же могу ошибаться, но контрпримера обхода пока не увидел.
piton_nsk
20.07.2023 06:44Не наказывать за ошибку в оценке? Тогда не будут и манипулировать.
cliver
20.07.2023 06:44Какой смысл тогда будет думать и что-то оценивать, если можно просто генерировать случайное число, все равно же никакой разницы нет.
Я не утверждаю что такой подход работать не будет, просто это может значительно ухудшить результаты.
piton_nsk
20.07.2023 06:44+2Если вы будете наказывать людей за ошибки, это уже так себе идея, если вы будете наказывать людей за ошибки других людей, то это идея прям совсем плоха. Разработка ПО это коллективный труд и не все от одного человека зависит. Легаси, кривая архитектура, отсутствие опыта работы с конкретными либами/фреймворками/местными костылями.
Какой смысл тогда будет думать и что-то оценивать, если можно просто генерировать случайное число, все равно же никакой разницы нет.
А зачем тогда вообще думать и что-то оценивать, если тебя за неизбежную ошибку в оценке наказывают? Никакой формальной методики для оценки сроков нет. Понятно что если что-то делается в 10 раз, оценить можно, а если нет? Тут однозначно надо заложить запас)
cliver
20.07.2023 06:44Я вообще нигде не писал наказывать, я писал давать премию за хорошую оценку. Премия - дополнительная доплата, некоторая функция от оценки времени и реального времени выполнения задания.
В ваших словах наказывать - я понял как отсутствие премии. Премии в смысле контекста этой модели, а не той премии что к зарплате идет и распространяется на все. Плохое слово может выбрал.
zloddey
20.07.2023 06:44+3Работают два программиста на одной кодовой базе по Вашей модели. Вася делает каждую очередную задачу максимально быстро и получает премию. Петя делает задачи медленнее и не получает премию. Вася молодец, а Петя нет? Выглядит так.
С другой стороны, если посмотреть, как именно Вася добивается скорости, то мы увидим что-то подобное:
Максимально дряной код, без структуры и порядка
Отсутствие документации и тестов на этот код
Что-то сломано по соседству с его кодом. Васе пофиг на совместимость - лишь бы максимально быстро сделать текущую фичу
Т.е., самый быстрый способ сделать текущую задачу всегда есть. Но на долгой дистанции он неотличим от саботажа. А тот, кто пытается поддерживать код в нормальном состоянии (Петя), получает двойную нагрузку (весь легаси + свежее говно от Васи), и за все свои усилия "награждается" лишением/уменьшением премии.
tommyangelo27
20.07.2023 06:44+2Напомнили мне историю из жизни. На одной из прошлых работ руководство решило давать премии за переработки. Фирма была по сути аутсорсом, выставляла клиентам счета на основании отработанного сотрудниками времени, то есть фирме было выгодно, чтобы сотрудники нарабатывали как можно больше часов.
В стандартном рабочем месяце примерно 160 часов. Условием максимальной премии было отработать 700+ часов за 3 месяца. Тогда помимо зарплаты человек получал премию $9000 плюс двойную часовую ставку за часы сверх стандартных 40 в неделю.
У нас нашлось несколько человек, готовых повпахивать, один товарищ даже 3 премии за год сделал.
Через год премию отменили, потому что клиенты начали разбегаться от компании, где каждый релиз сопровождается тонной багов, за починку которых пытались клиента забиллить ещё раз ????. Причём баги чинить зачастую приходилось другой команде, так как "эффективных" обычно кидали на новые проекты, чтобы побыстрее сдать и взять новые.
zloddey
20.07.2023 06:44+2Да, это жиза. Любые попытки привязать индивидуальные метрики разработчиков к фактическим метрикам процессов и баблосу кончаются катастрофой. Но, тем не менее, поток наивных экспериментаторов, готовых наступать на эти грабли раз за разом, не иссякает.
Jianke
20.07.2023 06:44премии за переработки...
клиенты начали разбегаться от компании, где каждый релиз сопровождается тонной багов
Потому что: переработки => усталость => падение внимательности => глупейшие баги на ровном месте.
ayevdoshenko
20.07.2023 06:44+1Матерь божья! Да всё просто: если у вас есть формула расчета правильных сроков - будь она хоть стохастической, хоть какой - то, собственно, вопрос манипуляций отпадает сам собой. Потому что есть ОБОСНОВАННАЯ оценка.
А если никто не может назвать и ОБОСНОВАТЬ правильность оценки срока, то все дальнейшие рассуждения - гроша выеденного не стоят по сути. Даже и оценки постфактум - фигня, потому что в процессе разработки не только злонамеренное сачкование может быть, а и масса других факторов, например, проблемы с железом, с документацией, с неизвестными дотоле багами в подключаемых сторонних библиотеках, с непреднамеренными факапами, с затягиванием сроков поставки каких-то ресурсов - схем там процессов, или данных, доступов - да тут просто прорва факторов.И в конце концов, друзья мои, именно ТОТ СРОК, ЧТО ВЫШЕЛ ПО ФАКТУ - И ЕСТЬ РЕАЛЬНЫЙ СРОК РАЗРАБОТКИ : ) Именно в нем и "учтено" всё то, что могло произойти и произошло таки! А всё остальное - если бы, да кабы.
cliver
20.07.2023 06:44А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты
https://habr.com/ru/articles/749206/comments/#comment_25770760
Если нужны конкретные функции - могу попробовать написать.
cliver
20.07.2023 06:44"вероятностная модель распределения оценок" вообще не совпадает с результирующим распределением времени затраченного на выполнение.
Да, в общем случае не совпадает. Мне следовало написать - вероятностная модель взаимного распределения оценок времени и реальных значений затраченного времени.
cliver
20.07.2023 06:44статистика - это когда у вас есть данные о распределении соотношения значений величны какого-то выходного параметра, и значений каких-то входных параметров. Если что это "неканоничное" определение.
Не нравится слово "статистика" - замените на "данные". Это все придирки к словам. Я понимаю, что если более строго подходить к слову "статистика" - это функция от неких собранных данных.
Так вот входные параметры - это буковки, которые составляют описание таски. Плюс текущее состояние проекта и его кода. Плюс состояние документации. Плюс опыт и знания разрабов. И вот уже это - неразрешимая проблема. Вы просто не сможете качественно классифицировать входные параметры, чтобы по ним собирать статистику значений выходных параметров.
С учетом этого всего сам разраб и оценивает. А в вышеприведенной модели всего несколько входных параметров: разраб, время его оценки и реальное время выполнения.
одна и та же задача "добавь в систему новый отчет" может занимать как 2 часа, так и 2 недели, так и 2 месяца. Средняя оценка в 2 недели - в большинстве случаев будет неверной
Нигде в своем изначальном комментарии я не употреблял словосочетание "cредняя оценка".
ayevdoshenko
20.07.2023 06:44Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо? Эта проблема не только перед заказчиком стоит, но и перед разработчиком.
Усреднение разных оценок не поможет. Разработчики все с разным опытом, да и опыт одного и того же разработчика изменяется со временем. Это раз. Второе - это то, что любая оценка даже опытнейшего разработчика строится на неопределенности - ну то есть в лучшем случае понимает это, а в худшем - занимается самообманом, который выльется в срыв озвученных сроков, что повсеместно и происходит с малоопытными, но - или, скорее - "потому и" - уверенных в своих оценках, специалистами.
Конечно, бывают проекты, в которых требования достаточно точны и даже имеется опыт их реализации - их оценивать легче и можно не перезакладываться сильно на риск, но даже в таких проектах факторы неверных толкований и вероятных изменений не отменяются и создают риск не влезть в неучитывающий их срок.
Конечно, если вы пишите из года в год примерно одно и то же на типовой платформе, плюс как-то научились контролировать грейд специалистов (обязательной сертификацией/аттестацией, например), то статистический подход еще может помочь, но это довольно узкая область разработки ПО. Подавляющее же число разработок ПО слабо походят на друг друга.
И в любом случае, это про те случаи, когда проект небольшой, по большей части состоит из знакомого по опыту функционала и требования прописаны достаточно детально, а часто - ТЗ состоит из дефиниций "хотелок", без каких-либо деталей и/или требуется "запилить" что-нибудь из разряда "как у Гугла" - только вот заказчик не понимает, что Гугл разрабатывал свою машинерию 30 лет огромными командами и сделал кучу неудачных подходов, прежде чем получил результат.
cliver
20.07.2023 06:44Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо?
Я не утверждал что нужно стимулировать разработчиков. Просто если вы хотите получить какую то цифру, желательно имеющую значение, нужно чтобы у людей был стимул делать точную оценку и делать работу максимально быстро (а не по настроению или наличию хорошего кофе). Если эти условия убрать - вы скорее всего не получите нормальных количественных оценок или многократно ухудшите их.
Не забываем https://habr.com/ru/articles/749206/#comment_25770458
ayevdoshenko
20.07.2023 06:44+1А я еще раз повторю - чтобы говорить об искажениях оценки надо знать для начала - какая оценка эталонная : ) А когда неизвестно что есть Истина - нельзя сказать и что есть Ложь.
piton_nsk
20.07.2023 06:44Вы пишите что разработчиков стимулировать не нужно, а в следующем предложении что у людей должен быть стимул.
cliver
20.07.2023 06:44Вы тред не читали внимательно.
На "Тут вовсе не рассматривается вопрос стимуляции разработчиков", я ответил что нужно лишь для получения хорошей оценки, а просто так кого-то "стимулировать" даром не нужно. К сожалению, такое "стимулирование" вытекает из требований к хорошей оценке.
vedenin1980
20.07.2023 06:44Мне кажется тут от частичной проблемы (ИНОГДА бывает так что сроки очень сильно расходятся с оценкой) сделали глобальную проблему (НИКОГДА невозможно оценить с нужной погрешностью).
По момему опыту это не так. В большинстве случаев задачи типовые и можно либо найти что-то аналогичное, либо оценить сроки сверху и снизу.
Да, 100% попадание добиться невозможно, но если условно в 90% мы укладывается в среднее, в 9% мы укладываемся в максимальную оценку сверху и в 1% случаев мы выходим за максимальной оценки сверху это НЕ СТРАШНО, так как статистически в рамках команды в большинстве спринтов мы будем выдавать необходимый результат.
Условно если мы делаем ремонт дома, мы не сможем предсказать точные сроки каждого этапа, так как всегда может оказаться, что окажется, что проводку делал кто-то с альтернативно растущими руками и на ее замену потребуется на порядок больше времени. Нам важно, что в сроки в ЦЕЛОМ не вышли за оговоренные рамки. Поэтому стоит с одной стороны разбивать на мелкие задачи, с другой стороны как можно раньше оценивать самые опасные части.
ayevdoshenko
20.07.2023 06:44+1Ну да, для типовой разработки это более-менее работает - вот вы пишите типовые конфигурации 1С, к примеру, имеете штат сотрудников, чьи навыки работы с типовыми инструментами 1С экзаменуете периодически - и да, можете вполне адекватно предсказывать разработку. Но это очень далеко не всё, что происходит в разработке ПО - как раз таки подавляющее большинство - это новые предметные области с новыми подходами и новыми требованиями - и здесь, в этой обширнейшей нише расчеты сроков становятся заметно неточными, потому что нет типовых решений.
vedenin1980
20.07.2023 06:44вот вы пишите типовые конфигурации 1С,
Вот я писал на Java/JavaScript последние 20 лет в крупнейших компаниях в мире (в своей рыночной нише — по для телекома, поиск отелей, вебстриминг для взрослых, предсказание онлайн рекламы, по для аудиторских компаний, банк евросоюза). И не поверите — большинство задач это решение типовых задач типовыми инструментами.
подавляющее большинство — это новые предметные области с новыми подходами и новыми требованиями
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть какие-то данные, нужно взять типовые инструменты, сделать типовую аналитику с типовым фронтов и с типовым беком, сделать интеграцию типовыми способами и т.д.
ayevdoshenko
20.07.2023 06:44+1Как минимум тогда интересно - каким образом вебстриминг, например, и банковская система является типовой относительно друг друга? Вы хотите сказать, что банковские расчеты и логика - это такой вид вебстриминга?
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть
какие‑то данные, нужно взять типовые инструменты, сделать типовую
аналитику с типовым фронтов и с типовым беком, сделать интеграцию
типовыми способами и т. д.Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит - значит ли это, что разница между камнем, положим, и человеком - невелика? : )
vedenin1980
20.07.2023 06:44Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит — значит ли это, что разница между камнем, положим, и человеком — невелика
Нет, речь о другом. Представьте вы автомеханик, с одной стороны можно сказать, что существует почти бесконечное количество комбинаций разных двигателей/коробок/ходовой/прочих деталей и почти бесконечное количество поломок и т.п. C другой стороны, в реальности все похожее и относительно быстро вы изучите настолько, что в 99% случаев вы уже что-то когда-то похожее решали (особенно при десятках лет опыта).
В программировании тоже самое — очень-очень многое это типовые задачи вида сделать авторизация на сайте с такими вот правми, сделать такие вот отчеты, вот такие объекты должны сохраняться. Все строится из типовых крипичиков и единственное отличие это бизнес логика, которая тоже обычно сводиться к доволько стандартным запросам (аля построить обычный sql и на его основе типовой график).
ayevdoshenko
20.07.2023 06:44Вы своими словами как бы отрицаете реальность: что, мол, технологии каменного века - суть всё то же самое что и современные нам, "ведь всё ж типовое". Этак вас послушать, так и никакого развития нету, а вы - легко правой пяткой настрочите нам ИИ покруче всех - а чего там, всёж те же самые битики ж туда-сюда перекладываются.
Бэкенд-фронтенд - и в продакшн!
vedenin1980
20.07.2023 06:44Я этого не говорил. Я говорил, что в 99% случаев программные задачи уже много раз много кем решались. На каждого сотрудника OpenAI существует сотни и тысячи программистов, которые условно перекладывают json'ы и выводят данные пользователю на страницу.
ayevdoshenko
20.07.2023 06:44И что с того, что задачи решались много раз кем-то, когда речь про вашу оценку? Это вы много уже раз решали все задачи? Или даже ваши коллеги по компании, которые вам подскажут?
И по-порядку:
Технологий - разных - великое число, и их становится только больше, и спрос на них постоянно растет. Обойтись json'ом и знанием SQL можно только в узкой нише. Да, есть набор технологий, которые присутствуют практическом в каждом проекте, однако это не равно тому, что именно они определяют проект и из них следуют все иные, задействуемые на проектах, технологии. Я не знаю с чем вы там работает, что у вас так славно всё выводится из очень небольшого набора технологий, хотя, вот, то же упоминание стриминга - вы что, серьезно его json'ом передавали? Я сам имел дело с видеостримингом и прекрасно знаю, что без понимания работы кодеков, без понимания строения видеоданных, без понимания специфичных протоколов передачи стрима, никакого видеостриминга не получится, и знания json и SQL тут нерелевантны. Или вам выдали готовую библиотеку с ручками, которую вы и дергали, представляя себе, что вся обработка видео - это не более, чем обращение к API? Так это другой уровень, на котором - да - всё напоминает
гвоздиjson.И, конечно, легко воображать себя Львом Толстым и знатоком всех технологий, но на практике - если ваша работа действительно разнообразна, а не так как я и писал - имеет более-менее типовой характер, то вы постоянно сталкиваетесь с отсутствием опыта в некоторых областях, который невозможно вывести из вашего иного опыта, ибо при всем том, что действительно в основе все те же биты, но организованы они сильно по-разному, и через это приобретают принципиально иные качества.
Про востребованность технологий я тоже не с потолка беру - сейчас чуть не каждый пятый хочет то аналитическую базу с нехилыми объемами данных, где где реляционные базы данных уже не вывозят, то нейросеть, то свой ГИС-сервис, то еще что. Причем ожидания, само-собой, на уровне качества сервисов ведущих вендоров, представляя себе, по-видимому, как раз как и вы, что сделать такую штуку - как два пальца об асфальт - оно ж "все одно и то же".
Второе - логика. Опять - логика в каком-нибудь, например, сайте - интернет-витрине, и логика в комплексной системе, которая охватывает модули работы с поставщиками, учетные системы, склады, логистику, системы мотивации продавцов, маркетинговые системы, кучу еще модулей и, наконец - собственно интернет-витрину - это две большие разницы. И эта логика диктует и выбор других технологических компонентов, других архитектур, других подходов. Но кроме этой технологической нагрузки и сама логика по сложности своей опять же нелинейно растет, ввиду множества связей между модулями - наивно полагать, что срок разработки сложной многомодульной системы - равен произведению срока разработки одного модуля на их количество, даже будь они примерно одинаково трудоемки - нет, так не выйдет, потому что модули не сами по себе будут работать, они связаны, и вы неизбежно столкнетесь и с задачей интеграции их в единую систему, с задачей управления этим сложным конгломератом - как на этапе разработки, так и в дальнейшем - при сопровождении и развитии этой системы, и, собственно, с задаче согласованной работы всей этой системы.
Так что я вполне обоснованно утверждаю, что, образно говоря, "автомобиль" - это не такая разновидность "лошади", хотя - да, обе как бы могут быть транспортом. Но по этому признаку - использования в качества транспорта - отождествлять их совершенно некорректно. А не образно говоря: ПО другому ПО - рознь. И потому, в том числе, и не существует универсальной и надежной методики расчета срока разработки ПО.
Thomas_Hanniball
20.07.2023 06:44На мой взгляд, большинство задач в МИРЕ это у нас есть какие-то данные, нужно взять типовые инструменты, сделать типовую аналитику с типовым фронтов и с типовым беком, сделать интеграцию типовыми способами и т.д.
За сколько времени вы сможете написать мне CRM-систему? Создание CRM вроде как типичная задача, состоящая из типичных компонентов, разработка её выполняется в типичных средах разработки, типичными девелоперами. А значит для вас, специалиста с таким большим опытом работы, не составит труда мне сообщить, сколько же времени понадобится для написания CRM системы.
OlegZH
20.07.2023 06:44За сколько времени вы сможете написать мне CRM-систему?
Очень интересный вопрос!
Вы не уточните, что Вы понимаете под CRM-системой? Чтобы лучше понимать условия задачи. Будем считать это своеобразным пет-проектом. ;-)
Xeldos
20.07.2023 06:44Вы не уточните, что Вы понимаете под CRM-системой?
Ну типичную CRM-систему. "Вы же специалист?" (c)
vedenin1980
20.07.2023 06:44Ну типичную CRM-систему. "Вы же специалист?"
Если типичную CRM систему без всяего ТЗ — за день я найду open source CRM систему и переделаю логотип.
За сколько времени вы сможете написать мне CRM-систему? Создание CRM вроде как типичная задача, состоящая из типичных компонентов, разработка её выполняется в типичных средах разработки, типичными девелоперами.
Вы путаете типичность и трудозатраты (и вообще затраты). Произвести любой автомобиль, серийную яхту или серийный самолет это тривиальная задача, которая компания их производящяя делала тысячи раз. НО себестоимость и цена там может быть очень даже не маленькая. Типично не значит бесплатно или дешево.
Если я у вас попрошу типичную стоимость и время производства серийной машины, яхты, дома или веротолета (не уточняя что именно я хочу) вы сможете мне ответить кроме от ста $ до миллиарда $?
OlegZH
20.07.2023 06:44Ну типичную CRM-систему. "Вы же специалист?" (c)
Не я здесь специалист. Но если я сделаю свою CRM-систему, то стану специалистом. Как-то так.
mixsture
20.07.2023 06:44в 90% мы укладывается в среднее
извините, но это какое-то альтернативное среднее. Среднее обычно работает так, что половина ниже, половина выше. В случае с проектами 50% в сроки не уложились.
Ваши 90, предположу — очень похожи на "запас". Можно представить в виде гауссова распределения и попыткой средним + интервалами в несколько сигм покрыть нужный процент случаев.
vedenin1980
20.07.2023 06:44извините, но это какое-то альтернативное среднее. Среднее обычно работает так, что половина ниже, половина выше.
Смотря как оценивать, точнее с какими допусками. Среднее в данном случае не среднее-арифмитическое, а попытка оценки task максимально объективно в story point'ах (без накидования максимально допустимого запаса).
Если у нас есть story point'ы (0.5, 1, 2, 3,5 и 8) и мы говорим, что 0.5 это рабочий день, 1 — 2 дня, 3 — неделя, 5 — полторы недели, 8 — весь двухнедельный спринт.
И c помощью planning poker мы распределили story point'ы по задачам. Вот если мы укладываемся в наши story point такой оценки — у нас все хорошо. Если мы не укладываемся даже в оценку сверзу — то у нас либо что-то случилось (дев. сервер лег на неделю) или мы совсем промахнулись с оценками.
P.S. Нужно понимать, что разработчики не должны постоянно работать на максимально возможной производительности, иначе они быстро "сгорят", то есть любая оценка всегда должна закладывать возможность спокойно сделать задачу с учетом отдыха/кофе брейков и т.п. Попытка "выжимать" из программистов все соки ставя все более короткие сроки это вообще не очень здоровая практика с точки зрения менеджмента (ну если не случилось реального аврала, который никак не было избежать).
laatoo
20.07.2023 06:44+2Если у нас есть story point'ы (0.5, 1, 2, 3,5 и 8) и мы говорим, что 0.5 это рабочий день, 1 — 2 дня, 3 — неделя, 5 — полторы недели, 8 — весь двухнедельный спринт.
можете объяснить таинственный смысл конвертации человекочасов в сторипоинты и обратно?
thevlad
20.07.2023 06:44Можно брать "доверительный интервал" куда вы будете попадать с 90% процентной вероятностью. Но тут есть проблемы, что либо интервал может быть довольно широкий, либо оставшиеся 10% будут улетать в "тяжелые хвосты" (условно говоря нестандартные задачи с ошибкой трудоемкости на порядок), и хоронить все остальные оценки.
eton65
20.07.2023 06:44В большинстве случаев задачи типовые и можно либо найти что-то аналогичное, либо оценить сроки сверху и снизу
В большинстве случаев, скорей всего, не будет достаточной экспертизы для такой оценки. Вот в соседней статье жалуются на выступления спикеров из топовых компаний на конференциях — даже они не могут сделать сравнения разных технологий. Что уж говорить про основную массу компаний/разработчиков.
OlegZH
20.07.2023 06:44А, ведь, что такое интегрирование? Это суммирование измеримых объектов. А как мы получаем измеримые объекты? Правильно! Разбиваем исходный объект на очень маленькие кусочки и аппроксимируем эти кусочки правильными (заведомо измеримыми) объектами. Всего-то и требуется: найти в программировании такие элементарные операции, которые требуют (при прочих равных) заранее известного времени выполнения. Делов-то! ;-7
ayevdoshenko
20.07.2023 06:44Это рассуждения недавнего школьника, познавшего Силу интегрирования и теперь воображающего себе, что сейчас он и тестикулы Бога проинтегрирует : )
eton65
20.07.2023 06:44Всего-то и требуется: найти в программировании такие элементарные операции, которые требуют (при прочих равных) заранее известного времени выполнения. Делов-то!
Так это (декомпозиция) уже давно сделано — называется "язык(и) программирования". Только выполнить обратное действие (композицию) с вашей легкостью и с вашим результатом пока не получается.
Но это было бы возможно как коммерческий проект в какой-то нише в стиле low-code/no-code. Что в принципе сейчас и пытаются делать.
OlegZH
20.07.2023 06:44Не (очень) получается, потому, что язык прорапмирования — это не совсем та декомпозиция, которая нужна. Речь идёт о типовых задачах.
И ещё. У меня нет ни лёгкости, ни результата. Я ничего не предлагаю. Лишь констатирую некоторые факты и обстоятельства.
Хотя... было бы здорово что-то предложить дельное, а не только слова.
eton65
20.07.2023 06:44найти в программировании такие элементарные операции
Я понял, речь про бизнес-задачи — но их тоже сотни, тысячи, миллионы. Если взять узкую нишу — да, можно ограничится небольшим их числом. Но что тогда делать на стыке двух ниш? Трех?
slonopotamus
20.07.2023 06:44+2необъяснимый оптимизм разработчиков и заказчиков
Дело не в разработчиках или заказчиках. Люди в принципе склонны к чрезмерному оптимизму.
tommyangelo27
20.07.2023 06:44+2Если бы люди умели правильно оценивать время — никто бы не опаздывал на поезда или самолёты.
А ведь это задача всяко проще разработки ПО.
ayevdoshenko
20.07.2023 06:44Это нормальная биологическая стратегия выживания : ) Другое дело, что при всем оптимизме, надо понимать, что твои оценки не имеют под собой достаточных оснований, и воспринимать их и работать с ними надо соответствующе, без возложение чрезмерных надежд.
А оптимизм при этом терять не надо : ) Надо всего лишь принять, что нет способа точно предсказать будущее, а если ты себя и не обманываешь этим - то открываются уже новые возможности!
murkin-kot
20.07.2023 06:44Статья пустая, исключительно ради поднятия шума. Но шум удался. Это означает, что автор задел весьма громко звучащие струны в сознании отписавшихся комментаторов. Проблема действительно важная, хотя решения ни автор, ни комментаторы так и не предложили. А раз решения нет, то и струны постоянно шевелятся, монотонным гулом напоминая всем о несовершенстве мира.
Но решение, разумеется, есть. Только оно не в рамках существующей системы. Именно в этом заключается проблема, из-за которой решения всё ещё нет.
Наверх вылазят кто? Как вы думаете?
Те, кто вылез, чем достигли высот? Как вы думаете?
И когда такие особи встречаются со сложной задачей, которую за них никто не решит, то способны ли они на такой подвиг? Как вы думаете?
Ну вот поэтому задача до сих пор и не решена. И вы даже знаете её решение - надо что-то поменять на самом верху. Вы ведь так думаете?
varanio Автор
20.07.2023 06:44Очень интересно, но ничего не понятно
murkin-kot
20.07.2023 06:44Мелочь качество ПО в принципе не потянет, не те ресурсы. Их удел - использовать готовое. А готовое делают большие конторы. Но там свои правила, эволюционно складывавшиеся в течении столетий. В большинстве случаев эти правила поощряют простые подходы, вроде нанять эксперта, который нам всё красиво нарисует. Но эксперт не сможет изменить целеполагание. А целеполагание тоже простое - надо взять максимум с хомячков. Наиболее эффективны в этом плане (после насильственного отъёма) стратегии на основе манипуляции эмоциями. Вот в эту сторону и совершенствуется мир корпораций. Ну а сложные системы, к которым относится и набор задач по разработке качественного ПО, остаются в тени, ведь зарабатывать через качество (включая составляющую, ответственную за соблюдение сроков) намного менее прибыльно в сравнении с альтернативами.
В итоге мир пришёл к "приемлемому" качеству, то есть доступному при небольших затратах на обеспечение оного. Так выгоднее всего.
И вторая часть - совершенствоваться в сторону "soft skills" бывает важно для топов. А на "hard skills" в области ПО ни времени, ни желания не остаётся. Поэтому сами они в принципе не смогут ничего улучшить, даже если бы захотели. Могут позвать экспертов, но те ведь обучены на массовом рынке, где востребованы решения узких прикладных задач, а не изменение парадигмы взаимодействия людей в обществе.
Так что рынок не хочет улучшений. А альтернатив рынку в мире, по сути, нет. То есть без перемен именно наверху ничего нам не светит.
eton65
20.07.2023 06:44Это не неразрешимая проблема разработки — это неразрешимая проблема жизни: как успеть сделать хорошо и за хорошую оплату, если требуют очень быстро, качественно и недорого.
OlegZH
20.07.2023 06:44Эту проблему, очевидно, решает готовая библиотека компонентов. Но никто не готов заниматься её созданием. Это и есть настоящая неразрешимая проблема.
eton65
20.07.2023 06:44Даже если представить, что такая библиотека существует, то она будет настолько объемная и сложная, что вопрос сложности все равно останется. Ну и вопрос — а развиваться она будет? Что там будет с консистентностью, обратной совместимостью, межплатформенной совместимостью, багами и т.д.? Сложность никуда не уйдет, хотя может быть несколько и уменьшится.
OlegZH
20.07.2023 06:44Зачем нужно развитие того, что является по построению достаточно полным?
Обратная совместимость чего с чем?
Межплатформенная совместимость? Этот вопрос исходит из того, что библиотека делается на неоктором существующем языке программирования, в то время, как наука чётко предписывает создание специализированного языка под решение каждой конкретной задачи, и уже трансляцию кода на этом языке к од целевой машины.
eton65
20.07.2023 06:44Зачем нужно развитие того, что является по построению достаточно полным?
В смысле полным? Мир остановился в развитии, нет новых технологий, моделей поведения — так что ли? Ведь это новое будет требовать и новых программных решений.
наука чётко предписывает создание специализированного языка под решение каждой конкретной задачи
Это какая такая наука? И это как получается — у вас будут тысячи и миллионы языков?
vmityuklyaev
15 мисок риса от товарищей разработчиков этому господину и -15 социального рейтинга от господ менеджеров
morgart2012
даа ????️