- Удовлетворить потребность пользователя.
- Если потребность сейчас не удовлетворяется, то мы дописываем код, исходя из этой необходимости пользователю.
- 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 в текущем виде не поможет: там слишком много корзин, а связи между ними непонятны. Нужна логическая система, понимание.
- Как стать лучше: только учиться.
- Люди разводят работу, чтобы не стать ненужными. Они думают, что в отсутствии работы они умрут.
- В открытом мире они не умрут. Наоборот, они будут более востребованы, чтобы охотиться на работу (возможно, что в другом месте).
- Пока менеджмент находится на уровне алхимиков, а не химиков: мало логического обоснования и математического аппарата.
- Пятая дисциплина Сенге (читай всю, а особенно посмотри пример про пивзавод - максимизация эффективности отдельных этапов не дает максимизации эффективности всей системы).
- Экстремальное программирование Кент Бек
- Популярная информатика Чурсин Николай