Если потребность сейчас не удовлетворяется, то мы дописываем код, исходя из этой необходимости пользователю.
OKR сюда не вписывается.
Что может сделать менеджер с потоком задач?
Изменить содержимое задач. Примеры:
Делать меньше или больше.
Делать то, что нужно или не нужно пользователю
Изменить порядок выполнения задач. Примеры:
Брать по одной задаче за раз.
Или вообще не делать некоторые задачи.
Изменить скорость выполнения задач. Примеры:
Является ли наш фреймворк средством контроля нерадивых работников?
Если так, то это входит в конфликт с тем, что все современные фреймворки доверяют команде.
OKR не влияет на #1 и #2. Но и про #3 не говорит.
Как разобрать практику и добраться до принципа?
Анализ: определяем, что мы исследуем.
OKR - что мы хотим получить и как мы протестируем (проверим), получили мы это или нет.
Синтез: где и как это можно использовать и можно ли использовать вообще.
Сформулировать тесты до работы полезно: это дешевле и можно подумать как сделать то же самое с меньшими ресурсами.
Проблема не в блоках обработки информации, а в каналах передачи информации.
В каналах возникают потери информации и они приводят к тому, что мы можем начать делать не то, что нужно пользователю.
Best practices ввел Тейлор, с оговоркой, что они применяются только к физическому труду, а не интеллектуальному.
Совет: разбирай best practices до составляющих и пойми основную идею, чтобы понимать зачем best practices были придуманы.
Если их применять в лоб к интеллектуальному труду, то работать они не будут из-за разного контекста.
Best practices применительно к физическому труду работают из-за того, что этот труд находится ближе к физическому миру, чем труд интеллектуальный, а законы физического мира одинаковы (а значит и контекст одинаков для физического труда).
Менеджер не может управлять действиями людей, он может управлять только взаимодействиями людей.
Как улучшать систему?
Смотреть где самое узкое место и если затраты на улучшение меньше получаемого эффекта, то улучшаем.
Повторяем поиск узкого места пока это экономически целесообразно.
Метафора практик и корзин
Есть 200-300 практик. Один или два автора берут 20-30 из них и обьединяют в непротиворечивую систему (корзину).
Так появились Scrum (впихнем все work items сразу), Kanban (work items берутся по одному, а не впихиваются все сразу, а если они маленькие, то появляется continuous integration), Less и т.п.
Цель: построить свою систему, уложить в своей голове и понимать почему это работает. Если понимаешь до уровня физических законов, то все ок.
Teamlead roadmap в текущем виде не поможет: там слишком много корзин, а связи между ними непонятны. Нужна логическая система, понимание.
Как стать лучше: только учиться.
Метафора охоты на работу
Люди разводят работу, чтобы не стать ненужными. Они думают, что в отсутствии работы они умрут.
В открытом мире они не умрут. Наоборот, они будут более востребованы, чтобы охотиться на работу (возможно, что в другом месте).
Метафора химиков и алхимиков
Пока менеджмент находится на уровне алхимиков, а не химиков: мало логического обоснования и математического аппарата.
Упоминаемые книги
"Пятая дисциплина" Питер Сенге (читай всю, а особенно посмотри пример про пивзавод - максимизация эффективности отдельных этапов не дает максимизации эффективности всей системы).