Конечно, программной инженерией это предсказательное нормирование труда никак не ограничится. Как всегда, начинается это в программной инженерии, затем лет через десять проникнет в машиностроение, а лет через двадцать доберётся и до стройки. Ну, или всё это будет много быстрее, мы ж уже не в двадцатом веке.
Но пока можно поспекулировать на том, что в производстве софта work load тесно связан с cognitive load, и мы можем пробовать начинать работать и с управлением жизненным циклом -- разбираться с практиками на каких-то объективированных основаниях, напрягая этим компьютер, а не себя, любимых. Практика = дисциплина+технология. Работы и их трудоёмкость связаны с практиками, а в практиках с дисциплиной связана когнитивная нагрузка, cognitive load. Так что очень грубо можно пробовать вытаскивать из оценок трудоёмкости и какие-то связи с когнитивной нагрузкой для тех или иных практик.
Вот кластеризации слов (терминов дисциплин из каких-то практик), полезных для оценки трудоёмкости -- как видите, кластеры из слов, используемых в описаниях issue действительно получаются семантически осмысленными, они отражают различные практики:
Конечно, в заключении статьи авторы пишут we would like to evaluate empirically the impact of our prediction system for story point estimation in practice. This would involve developing the model into a tool (e.g. a JIRA plugin) and then organising trial use in practice.
Автомобиль без водителя, рентген без рентгенолога, issue tracker без инженерного менеджера. Конечно, комментируемая работа это только первая капля из дождичка, и по факту ничего серьёзного ещё не произошло. Опубликовали сомнительные по абсолютной величине результаты, пригласили всех желающих поработать над темой, сделать лучше, если смогут. Но дождичек таких работ продолжает идти, и он затопит и инженерный менеджмент в том числе. Никто не уйдёт обиженным, догонят всех.
