Количеством багов, увеличением времени работы и недовольством пользователя.

Продуктивно, да)))

Вообще продуктивность тема отдельная, как и чем замерять, микроменеджмент ни где и никогда не работал. Ваша отсылка к строчкам. Сторипоинты и список фитч не про продуктивность а про вклад. Если их начинают использовать как продуктивность - проекту можно ставить клеймо - хромой. При таком подходе не выйдет нормального.

Как-то мнение у вас о ЕГРН меняется ))

Да не то чтобы, это скорее в целом ощущение от работы людей в разных местах. Про ЕГРН отдельно я не думала, так как он нам достался от другого подрядчика и спрашивать за его софт не с кого.

Мы страдаем от слабо документированной бизнес-логики, вот от этого страдаем сильно.

wow

Итак разберём это на основании принципов кодирования наименований документов ЕСКД:
1.  Согласно ГОСТ 2.104-2006 Единая система конструкторской документации (ЕСКД). Основные надписи (с Поправками), Раздел 6 пункт 1. Графа 1 основной надписи заполняется как в графе 1 - наименование изделия и наименование документа, если этому документу присвоен код. Для изделий народнохозяйственного назначения допускается не указывать наименование документа, если его код определен ГОСТ 2.102, ГОСТ 2.601, ГОСТ 2.602, ГОСТ 2.701.

2. Согласно ГОСТ ГОСТ 2.201-80 (http://www.pntd.ru/2.201.htm)
2.1. Устанавливается следующая структура обозначения изделия и основного конструкторского документа:
2.2. Четырехзначный буквенный код организации-разработчика назначается по кодификатору организаций-разработчиков.

2.4. Код классификационной характеристики присваивают изделию и конструкторскому документу по классификатору изделий и конструкторских документов машиностроения и приборостроения (Классификатору ЕСКД).

Структура кода классификационной характеристики:
2.5. Порядковый регистрационный номер присваивают по классификационной характеристике от 001 до 999

В коде документа должно быть не более четырех знаков, включая номер части документа.

Примеры:
АВГБ.061341.021 СБ,
АВТБ.061341.021 ТУ1,
АВГБ.061341.021 ИЭ12.

В вашем случае:
ИРЦВ - 4-х буквенный код разработчика документа.
42 5100 5 - Классификационный код изделия.
001 - Код экземпляра документа
ВЭ - код типа документа согласно классификатору типов программных и конструкторских документов.

Далее идёт версия документа и прочее.

Классификатор ЕСКД можно найти тут:
https://classinform.ru/ok-eskd/kod.html

Таким образом классификационный код 42 5100 5 соответствует:
42 - Устройства и системы контроля и регулирования параметров технологических, процессов, средства телемеханики, охранной и пожарной сигнализации
425 - Средства охранной, пожарной и охранно-пожарной сигнализации
4251 - Извещатели охранные и охранно-пожарные

Так что это похоже на какую-то систему пожарной охраны.
005 - Получается номер документа.

Для того, чтобы замерять продуктивность разработки, надо уметь планировать разрабоку с очень хорошим качеством.
Для того, чтобы планировать разработку - нужен техпроект или архитектурное описание, на основании которого можно оценить затраты ресурсов.
Для того, чтобы был достаточно проработанный техпроект, нужны соответствующие компетенции по техническому проектированию в отрасли. А их очень мало. Потому, что:
1. Научная база организации труда проектировщиков ПО - крайне хреново у нас оформлена. У нас нет методичек соответствующего уровня и качества. Этому явное подтверждение - куча споров о том "Какая нотация лучше". Вместо ссылок на исследования.

2. Это в т.ч. обусловленно требованием к срокам разработки и внедрения продуктов. Они меньше, чем требуется для проработки методической базы на научной основе и проработки самой научной основы. Методы проектирования - до сих пор сводятся к тому, что "- У вас должен быть кто-то гениальный, кто тащит разработку и принимает дешёвые и правильные решения".

Т.е. цепочка причин-следствий в итоге сводится к :
1. Если завтра не сделаем хоть что-то - всё пропало, поэтому некогда разрабатывать сегодня - внедряйте завтра.
2. Разработать нужно сегодня, поэтому проектировать некогда. Разрабатывайте
3. Проектировать сегодня некогда, значит некогда и разбираться в причинах неудач ИТ-проектов. Потому, что "Разрабатывайте сегодня, внедряйте завтра".
4. Исследовать причины провалов и методы улучшения качества труда в целом, даже в рамках отраслей - некогда. Потому, что "Разрабатывайте сегодня, внедряйте завтра".

Видимая мной мотивация за этим стоит следующая:
"Кто быстрее удовлетворяет текущие потребности клиента - зарабатывает больше. Кто больше зарабатывает - тот хороший. Поэтому доставка ценности клиенту должна занимать, включая проектирование и разработку - 0 времени."

При этом не важно насколько компетентен клиент в оценке того, что является для него ценностью. Чем менее компетентен клиент - тем больший объём услуг он может потенциально потребить. Поскольку для достижения целей менее компетентному требуется в среднем больше ресурсов, чем компетентному.

Следовательно причина в росте затрат на разработку и сопровождение - компетенция потребителя конечных услуг. Чем она выше - тем дальше потребитель может прогнозировать свои действия и следовательно запрашивать услуги ЗАРАНЕЕ. Чем более "заранее" потребитель может запросить услугу - тем больше временного ресурса на её проработку и повышение качества до достаточного уровня с точки зрения сратегии потребителя.

Как заключение могу сделать вывод, что нотациями, диаграммами, конфлюенсами и прочим - лечить некомпетентность потребителя конечной услуги - дело весьма гиблое.
Лечить плохую документацию и плохую разработку я бы предложил через повышение уровня грамотности конечного потребителя.

Александр, вы мое сообщение про ЕГРН скопировали и отсюда у меня вопрос. Ваше сообщение применительно к нему или это просто общее?

Ошибся ответом)

было вот к этому

Я о другом говорил. О продуктивности разработчика, конкретного, или аналитика к примеру.

А так в целом полностью согласен с вашими тезисами. Только они к другой теме.

Да забили уже все мерить эту продуктивность.

Почему же к другой?