06:35 - что нужно программисту чтобы написать программу - информация из рассказа пользователя
07:18 - множество пар (начальные условия, конечные состояния)
09:03 - без полноты информации не получится алгоритм
09:45 - F = полнота информации = добытая инфоромация / достаточная информация, F ∈ [0,1]
10:09 - иногда достаточно набора граничных и проверочных значений
10:40 - полнота информации между пользователем и разработчиком, возврат при недостатке добытой инфоромации у разработчика
11:10 - полнота информации между разработчиком и компьютером
11:40 - E = экспертность разработчика в задаче, E ∈ [0,∞)
12:50 - R = качество резултата = F * E, R ⩾ 0
14:10 - избыточное качество
15:35 - оптимальное качество
15:43 - неоптимальное качество => возврат
17:00 - как понять будет ли возврат
17:49 - если понятно что будет возврат, то добиваемся полноты
19:46 - для увеличения полноты код почти не требуется
20:33 - если не хватает экспертности, то можно поменять тип работы на проектирование или - исследовательскую работу
22:10 - учет требований по срокам
23:54 - как уменьшить количество возвратов
26:03 - для исследования требуется другая полнота и экспертность и в результате этой работы увеличится - полнота и экспертность для исходной задачи
28:30 - заработок на умственном труде
29:49 - сложности при внедрении задач развивающих экспертность, конфликт с трендом на утилизацию
31:24 - как эта модель может помочь понять что делать
32:28 - учет скорости петли обратной связи
33:00 - учет тестирования, эффект перетестирования
38:28 - как в этой модели учитывается неидеальность кода разработчика
41:12 - автоматические тесты окупаются при частых возвратах
42:48 - учет роли аналитика и как определить где проблема
45:40 - когда не требуется возврат аналитику
47:40 - учет роли имитатора пользователя, типы возврата для этой роли
48:55 - общий принцип - где уменьшилось F в цепочке
49:45 - ограничение на производительность, пример когда дешевле убрать аналитика для экономии на - коммуникациях и упрощения горизонтального масштабирования за счет обучения разработчика
53:20 - когда требуется менять структуру системы, а когда оптимизировать точечно
58:10 - место доменных знаний команды в этой модели
59:00 - за чем именно наблюдать в системе, цепочки, обработчики и неизвестные значения
1:01:55 - резюмирование от @oleg40a
1:03:24 - продолжение от @vfabr - если много элементов в системе то меньше качество, так как больше - потерь информации
1:07:05 - зачем нужно пересечение экспертизы, как обойти проблему необходимости специализации для - уменьшения потерь информации
1:10:45 - учет сроков при выборе оптимизаций системы - переключение контекстов vs простой системы vs - обучение
1:13:20 - почему статистика будет работать плохо при изменениях в системе
1:14:12 - резюмирование от @oleg40a о том почему есть тренд на плоские организационные структуры
1:15:40 - вариант ответа что конкретно делать
1:19:46 - аналогия спринтов и bulk insert
1:20:40 - возражение @oleg40a на аналогию, темпоральные характеристики баз данных vs процесс накопления информации, нелинейность - времени на работу
1:24:04 - ответ @vfabr на возражение, связь итеративности и bulk
1:26:00 - прогнозирование на итерацию для того чтобы выбрать правильный тип работы
1:29:12 - возражение @oleg40a в ответ на возражение от @vfabr, аналогия с заточкой топора, как - менеджмент может мешать реализации изменений, упоминание Kanban Maturity Model
1:32:30 - типы компаний по реакции на изменения
1:34:47 - пример неэффективности оптимизации взаимодействия без изменения системы: обнажение - максимальной эффективности системы с work in progress лимитами
1:37:00 - после обнажения неэффективности остается только менять систему
1:38:00 - изменение системы на следующих уровнях
1:41:05 - сложности интеллектуального труда: придумать алгоритм и начать его реализовывать