00:00 - @oleg40a почему начали обсуждать jira 02:52 - про jira головного мозга, первый критерий 04:30 - место jira в разработке ПО 06:30 - ticket и его содержимое 08:14 - mindset доставки ценности пользователю 09:07 - дисфункции с момента нарезки задач 09:58 - противорериче принципу autonomy, командная ответственность 11:14 - в каком смысле ситуация в которой приходится использовать jira как knowledge base это симптом дисфункции 14:54 - как jira стала такой 16:38 - отсылка к докладу анти jira 17:08 - аналогия между неправильным использованием тикет систем и заражением вирусом 20:30 - Software Engineering is a learning process, working code a side effect ( ссылка 1 , ссылка 2) 21:30 - как это связано с теорией X / теорией Y (authoritarian / participative) 23:05 - аналогия с лесным хозяйством и конвейером Ford 25:30 - @vfabr про понимание @modernsd чата, @oleg40a и других участников (понимание @oleg40a тут) 30:46 - заострение проблем при общении в чате для запуска мыслительного процесса 32:33 - какому поведению не рады в этом чате (прим. @materkey - чем-то напомнило статью) 38:40 - jira для фиксации расхождения реализации и спецификации 39:14 - @oleg40a как связаны jira, estimates, incentives и другие процессы 42:24 - @vfabr критерий можно ли перекладывать какую-то ответственность на Jira, как то что упрощает работу программиста приводит к тому что появляются новые проблемы 46:40 - @oleg40a как менеджеры ломают систему 48:04 - буллинг в этом чате как сигнал нарушения негласных правил 53:55 - цель чата с точки зрения @vfabr 01:03:40 - модель познания для инженера, инженерная культура 01:10:58 - вопрос @newyearisamagictime про опыт @vfabr 01:16:30 - позитивный сценарий использования чата @vfabr 01:19:10 - вопрос @materkey про определение энергии в модели @vfabr 01:22:00 - вопрос про методологию познания @vfabr 01:24:46 - вопрос @newyearisamagictime про оценку адекватности моделей (ответы: ссылка 1, ссылка 2)

- 00:21 - почему тема обратной связи важна - 02:10 - the power of feedback - 02:20 - что  такое обратная связь - 03:44 - проблема необъективности мнения при обратной связи между людьми - 05:49 - 4 вида обратной связи - 05:56 - вид "ты не прав" - 07:56 - вид "кто-то не прав" - 08:12 - вид "правила говорят что это не правильно" - 08:32 - вид "я не прав" - 09:20 - обратная связь в обычной жизни - 11:16 - проблема фиксации правил на работе - 13:08 - социальная и рабочая части правил - 14:20 - пример про code review ("что" бизнеса и "что" технической системы) - 18:00 - специальные правила для каждой задачи - 26:10 - как донести идею рабочих правил - 28:13 - добавление от @vitaly19842 про явное описание рабочих договоренностей - 29:30 - как понять что усвоены рабочие договоренности - 46:44 -  похожесть синхронизации понимания и тестов в TDD - 48:47 - что если люди не соглашаются менять процесс, отсылка к докладу работа с инновациями и рацпредложениями

- 00:42 - прикладная цель систем менеджмента - 01:47 - проблема выбора нужного действия: стиль менеджмента + контекст - 03:16 - описание стиля который не подходит для работы над качеством, самообразованием, наставничеством, командообразованием, обменом знаниями - 05:10 - противоречие бэклога спринта и стратегических целей - 06:38 - как выглядит микроменеджмент - 08:13 - примеры стилей менеджмента с точки зрения мотивации сделать нужное действие: теория X / теория Y (authoritarian / participative) - 10:16 - что улучшает мотивацию сотрудника: autonomy, mastery, purpose - 12:27 - что делать с людьми которые привыкли к микроменеджменту - 15:06 - доверие - 16:24 - увольнения при изменениях - 17:30 - как увеличивать доверие в компаниях - 21:30 - соотношение практик контроля и гомеостаза - 23:40 - когда попытка сделать лучше может сделать хуже - 25:39 - распределение ответственности для выстраивания саморегулирующейся системы - 27:30 - признак чрезмерного контроля: прозрачность, планирование, предсказуемость - 28:20 - если touch time непредсказуем, то нет смысла трекать время - 29:30 - демотивация при внедрении time tracker'а в jira, удар по autonomy - 30:21 - деструктивная составляющая оценки задач, планирования и предсказуемости - 30:45 - эффект самоухудшения при чрезмерном контроле - 33:39 - пример последствий контроля от @vfabr - сложность системы растет быстрее чем экспертиза разработчика - 36:14 - вместо контроля, время менеджера можно тратить на рост: личный (не Personal Development Plan), команды, компании - 36:49 - плохие примеры реализации процессов личного роста в компании - 39:16 - негативная сторона тренда на усреднение навыков сотрудников в компании, польза diversity  - эффект комбинирования сильных сторон - 41:23 - примеры @vfabr - обмен знаниями при парном программировании - 42:30 - пример @vfabr - саботирование процессов сотрудниками - 44:43 - пример @oleg40a - навязывание корпоративов и формирование вражеского отношения к менеджменту - 45:22 - для командного роста нужен challenge - 45:40 - инструмент делегирования - delegation poker - 47:30 - если команда не справлялась с делегированием, а его стало еще меньше то значит у менеджмента чрезмерный контроль, чтобы освободить время менеджера для более важной работы требуется наоборот делать это чаще - 48:35 - командам важно углублять доменные знания - 50:25 - рост компании - культура, доверие, степень выгорания, sustainability - 52:20 - scrum / kanban - 53:16 - автономны ли на практике команды - 55:20 - спринты - 55:37 - общается ли любой член команды именно с заказчиком - 56:20 - скрам-мастера которые не работают на свою ненужность - 56:53 - фреймирование kanban'ом - 59:40 - вывод: можно брать элементы из разных подходов - те что похожи на теорию Y и имеют хорошее обоснование - 1:00:18 - обратная связь + теория массового обслуживания + учет количества информации для того чтобы задачи гарантированно заканчивались => больше задач получится сделать - 1:01:20 - отсылка к Extreme Programming, Basecamp / ShapeUp, Zerocracy / Puzzle Driven Development - 1:03:46 - значит можно проектировать свою систему - 1:04:16 - trunk based development, no staging - 1:06:00 - способность менять привычки - 1:08:10 - ci => отсутствие long lived веток. cd => отсутствие релизов, devops для тимлидов за час - 1:08:45 - code review - 1:08:57 - конкретный roadmap: отмена плохих практик, отсылка к Podlodka #132 —Дисфункции организаций - 1:10:20 - отмена scrum, спринтов, kpi, okr, регламентов, project manager - 1:12:16 - ротация - 1:15:10 - к чему можно свести большинство проблем - 1:19:35 - мысленный эксперимент: как можно ухудшить систему Материалы https://github.com/modernsd/works/blob/master/notes/2021-10-31.md

- 00:21 - вопрос про скорость выполнения задач и количество невыполненных задач - 02:33 - узкое место в тестировании - 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 - качество - 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 - когда не требуется возврат аналитику - 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 - сложности интеллектуального труда: придумать алгоритм и начать его реализовывать - 1:43:17 - итоги встречи Материалы https://github.com/modernsd/works/blob/master/notes/2021-10-24.md

- 00:00 - @vfabr что/как/результат в приложении к коммуникациям в команде - 03:30 - что такое коммуникация - 04:50 - схема коммуникации - 07:00 - что нужно фиксировать - 08:20 - где хранится информация/знания и сложность структурирования по положению компании на логистической кривой - 09:30 - добывание информации -> превращение в знания -> определение горизонта изменений -> фиксация - 10:40 - знание должно быть получено творческим путем - 13:48 - сжатие смысла - 17:14 - фиксация спецификации но не реализации - 20:00 - как передавать знания - 39:11 - @oleg40a знания по продукту vs сигналы, цель любой системы менеджмента дать понять человеку что он должен делать или не - делать - 42:20 - пример более сложной ситуации - 59:50 - островки разума - 1:06:05 - формальные/фактические правила - 1:06:40 - shadow IT, bring your own device - 1:13:00 - многоканальность vs омниканальность - 1:21:30 - как синхронизировать людей в одной/разных частях системы - 1:25:56 - резюме встречи и роль энтузиазма

- 00:00 - когда тимлиду стоит учавствовать в devrel'стве - 02:10 - польза и вред от incentives в разработке ПО - 07:15 - партнерский подход в менеджменте труда, уровни доверия в команде - 09:43 - controversies about principal-agent theory - 17:10 - corporate social responsibility - 18:20 - суть devrel'ской практики, примеры групповых динамик, silos в devops  - 23:20 - можно ли подвести людей к изменениям и как адаптивность может этому мешать  - 26:00 - прогноз как компании будут отходить от agency theory и/или меняться - 30:30 - отсылка - 31:50 - scrum guide продается но часто требуется что то еще - 34:00 - требуемая степень утилизации разработчиков - 37:14 - влияние верований групп на восприимчивость к новым идеям - 39:25 - оценка текущего состояния научного прогресса - 45:30 - выгорание - 47:00 - еще варианты развития событий - 48:50 - непродолжительность эффекта методик, системных подходов в малых группах - 1:00:00 - истоки внимания к дисфункциям - 1:04:55 - реферальные программы как лакмусовая бумажка

- 0:00 - @vitaly19842 про результаты процессов обучения сотрудников - 01:05 - про книгу "Записки педагога" про гармоничное развитие личности и доказательную педагогику - 02:30 - кружок выступающих для эффективного донесения артефактов работы сотрудниками - 03:18 - как организовать финансирование кружка внутри компании для выступлений  - 10:30 - ценность, стоимость ценности для одного человека, а потом уже стоимость на всех - 14:00 - измерять обучение в штуках; если нужен ИП, то обязательно указывать ОКВЭД'ы главных трат - 17:20 - туториал от @vfabr ориентированный на менеджеров в IT, под призмой теории массового обслуживания, теории информации, кибернетики и тп. - 22:40 - удобная продолжительность занятия, упоминание андрагогики  - 26:10 - апроприация знания - 28:50 - сложность работы, нелинейность людей, проблема оценки задач, непрогнозируемость ⇒ задача менеджера чтобы мир был на отрезке был стабилен чтобы работа людям была под силу ⇒ линейность людей при выполнении задачи ⇒ предсказуемость, прогнозируемость - 42:50 - Dr. Alistair Cockburn - Characterizing people as non­linear, first­order components in softwaredevelopment, этнография в приложении к IT - 50:50 - @oleg40a "менеджеры как носители эффектов" - 51:30 - отсылка к выпуску ПУСКИ ЛИЦ - 52:10 - эффект "медленное сползание в унылое ***но" - 58:30 - проблемы больших компаний - 59:40 - коллективная выученная беспомощность - 01:02:50 - слепое копирование, внедрение ради KPI без замены неэффективных элементов рабочей системы; если такое поощряется компанией то это трудно остановить - 01:05:00 - ситуации когда язык маскирует смысл (цель, задача, релиз) пример релиз как процесс, релиз как дата, релиз как артефакт - 01:06:00 - пример когда упоминание модного слова заменяет аргументацию - 01:08:38 - пример когда полезное из scrum'а выкидывается - 01:10:10 - совещания - 01:10:50 - эффект "делегирование некомпетентности" - 01:12:05 - люди "вижу цель не вижу препятствий" - 01:14:58 - эффект "глупость толпы" - 01:23:16 - эффект "коллективный Даннинг — Крюгер" - 01:26:28 - эффект "Spotify", эффект "Авито" - 01:29:00 - эффект поленницы - 01:31:50 - технологические приемы развития глупости - 01:33:22 - the stupidity paradox (book preview), book review - 01:46:52 - как менеджер может делать сотрудников глупее - 01:49:48 - перспективы

- 0:00 - заявленная тема - как организовать обучение в it компании, сначала фундаменатьные вещи, а потом конкретная реализация - 2:30 - начало про психологию на основе черновика книги от @vfabr - 4:30 - экстренные решения - 5:30 - как связаны мыслительный процесс и эмоции - 12:00 - переход от зоопсихологии на людей - 13:00 - про зоны актуального и ближайшего развития - 17:00 - акт изобретения - 21:00 - результат сравнения систем обучение в нескольких странах - 26:00 - имплицитное и эксплицитное научение - 28:20 - любопытство - 33:00 - зачем нужно обучение - 34:11 - инновации - 36:55 - problem solving - 39:50 - пример когда окупилось время на обучение - 41:40 - что требуется для начала построения обучения в компании - 42:40 - пример того как можно начать обучение в компании - 47:30 - выбор количества человек в группе используя сравнение детского сада, школы и вуза - 50:30 - как понять есть ли у сотрудников мотивация к началу такого процесса обучения - 52:00 - пример начала с фундаментальной темы в которой большинство сотрудников на одном уровне понимания - 53:00 - вариант организации домашней работы - 56:00 - описание цикла для реализации дальнейших шагов - 1:00:00 - обратная связь от автора вопроса про обучение - 1:02:40 - ответ на вопрос про то на сколько привязывать обучение к конкретным задачам - 1:07:00 - вопрос про то является ли задачей обучения отказ от убеждений - 1:09:20 - ответ - 1:14:17 - чат прервался - 1:14:51 - чат продолжился - 1:15:33 - от чего зависит мотивация людей делать рационализаторское предложение - 1:17:10 - аналогия со станком, закон Йеркса — Додсона - 1:22:40 - что если никто из участников не направляет обучение - 1:30:30 - вопрос от @oleg40a про то на сколько нужно обучение похожее на сертификации в it - 1:37:00 - вопрос про перечень технологий в описании вакансий и то как это согласуется с принципами инженерной работы

- 00:00 - @vitaly19842 о школе кадрового резерва - 01:30 - про соревновательность в обучении - 03:00 - перерывы  - 04:00 - выбор времени старта работы - 04:40 - про разминку перед работой - 06:30 - про разнообразие оборудования у обучающихся - 07:24 - про стеснение, смущение и психологический комфорт у студентов - 08:40 - theory first vs practice first - 09:35 - понятие рациональности, когда лучше не делать если можно не делать - 13:33 - @vfabr про вариант понимания задач психологии и triune brain гипотетическая модель мозга (судя по wiki отвергнута) - 19:40 - рефлекс, эмоция, мышление для адаптации к внешнему миру - 20:50 - основные эмоции которые позволяют долго что-то делать и гармоны для вызова эмоций - 25:08 - иллюстрация того что описывал ранее @vitaly19842 - 26:30 - финская модель обучения - 29:27 - сравнение с другими системами - 31:30 - идея силы стимула и качества педагога - 37:00 - обсуждение мотивации у студентов вуза - 40:00 - доказательная педагогика или ее отсутствие - 43:17 - edu scrum - 49:00 - еще немного про разницу российского и финского образования - 51:00 - тенденции вокруг международной программы по оценке образовательных достижений учащихся - 57:46 - смена темы: вопрос об эффективности процессов, заваливание проблем временем и метрики эффективности - 1:02:08 - начало ответа от @dphil - 1:07:40 - нужна ли в командах постоянная оценка для улучшения качества оценки - 1:10:00 - иллюстрация того как выглядит идеальная эффективность - 1:11:40 - дополнительные элементы в процесс для синхронизации в разработке - 1:14:30 - негативные изменения в поведении людей при внедрении метрик влияющих на incentives, не влияющих на то доволен или нет конечный пользователь, пример про змей - 1:17:00 - критерий для sustainable business - счастье пользователей, выстраивание целей от этого - 1:18:20 - проблема okr - 1:21:00 - девятки в SLA, DORA метрики - 1:22:00 - стоймость обучения сотрудника, среднее время работы в компании - 1:25:20 - еще раз про необходимость физического обоснования того как клиенту (внутреннему или внешнему) будет лучше от внесения чего-то нового в систему - 1:29:30 - про STATIK ( видео, статья, книга (eng), книга (rus)) и создание дискомфорта, стрессора для внесения изменений в компанию - 1:34:20 - скорость культурных сдвигов в обществе Материалы https://github.com/modernsd/works/blob/master/notes/2021-05-11.md

- 00:00 - начало про платформенные команды - 02:05 - проблемы при стандартизациях в разработке, effectiveness vs efficacy vs efficiency - 10:00 - применение little's law к платформенным командам или почему платформенная команда это костыль - 11:00 - выделение команды vs использование slack time для обучения окружающих - 16:30 - о статье фаулера про внутренний SaaS - 18:00 - про core team (не SaaS) - 19:30 - групповые динамики - илитаризм, социальное расслоение - 20:30 - иллюстрация негативных групповых динамик scala сообщества - сорта программистов - 23:00 - проблема с обучением других - 23:30 - устаревание представления о контектсе продуктовой разработки у платформенных команд - 25:45 - проблема предварительного обобщения; как автономность перечеркивается зависимостью на команды - 29:04 - комбинаторный взрыв при выделении общего - 31:00 - обилие конфигурационных параметров -> программирования больше а не меньше - 32:39 - компетенций команды часто не хватает на инфру - 34:10 - configuration as code - 34:40 - платформенных гильдий, команд будет становится все больше так как компетенций продуктовых команд будет все меньше и меньше - 36:20 - проблема организационных и процессных решений архитектурных проблем - 38:34 - системы для программистов сложно делать из-за требовательности - 43:30 - необходимость оставлять возможность - 45:42 - платформенная (внутренний SaaS) vs core (распил целого продукта) vs интеграционая команды - 46:52 - критерий конкурентности - 52:59 - больше контекста от автора вопроса - 57:10 - неявное финансирование, как прояснить целесообразность платформенной команды - ответить на вопрос получиться ли сделать стартапом, по lean стартап методологии; другие компании могли бы этим воспользоваться? неверифицируемость окупаемости приводит к паразитизму, job security - 1:00:30 - временное решение vs системное решение; проблема отсутствия обучения других или его замедление при создании таких "костылей" - 1:04:10 - conway law под вопросам для некоторых общих частей - 1:12:00 - система генерирующая задачи vs система выполняющая задачи и все ли задачи нужно делать - 1:15:30 - расширение трассы -> больше пробок - 1:17:00 - подведение итогов - 1:21:00 - вопрос на следующий раз про реализацию работы архитектора Материалы Статья про изъян со средними числами

01:00 - начало разбора таблицы Feels Like Faster vs. Is Actually Faster 01:45 - starting vs finishing 03:30 - less slack vs more slack 04:48 - parallelizing work vs serializing work 05:55 - "filling up" timeboxes vs clear, overarching timbox goals 07:46 - higher work in progress vs lower work in progress (to a point) 10:30 - "getting ahead" of the work vs starting together 14:25 - specialization vs t-shaped (to a point) 16:40 - shipping and jumping to next project vs leaving to respond to feedback 19:18 - cutting corners (we'll fix it later) vs quality focus (fix it now) 22:08 - refactor as special effort vs regular refactoring 23:38 - analysis paralysis 24:25 - handling off to test. starting new work vs pairing with test. finishing together 26:13 - hiring more people vs tooling, infrastructure, environments, quality 30:39 - throwing new team members into fray vs careful and safe onboarding 33:15 - individual assignments vs team goals, pairing, swarming, mobbing 35:42- chase efficiency vs encourage messy but effective collaboration 41:35 - heads on keyboards immediately vs team conducts research together 43:18 - larger batches ("less resetting") vs smaller batches 47:11 - keep everyone heads down vs quiet/focused time punctuated by collab 48:58 - метрики не во главе угла а для на подумать 50:00 - design then build vs participatory design, UX/dev pairing 52:40 - shared ops vs embedded ops (w/ some shared services) 56:00 - отсылка к видео разбору CALMS 58:23 - output velocity vs impact velocity 01:02:14 - stakeholder reviews and approvals vs partners in the trenches, regular participation 01:05:22 - "find a way around the blocker" vs swarm on the blocker 01:11:10 - разбор вопроса про ответственность за производительность: иллюстрация 1, иллюстрация 2 01:43:28 - обсуждение после ответа на вопрос Материалы: https://github.com/modernsd/works/blob/master/notes/2021-04-13.md

00:50 - вопрос про проектный офис, стратегирование, планы, подбор фреймворка 04:41 - ответ 09:35 - резюмирование ответа 11:50 - пример сценария на основе матричной структуры 14:40 - поощрение vs централизация инициативы 19:38 - оценка перспективности бизнес идеи: стартапы vs некоторые продуктовые компании 26:40 - бюджетирование это хорошо или плохо 33:10 - предварительный анонс тем онлайн митапов 35:20 - исследование токсичного поведения в компании 42:46-47:46 - вырезанный кусок 48:50 - организация преподавания в компании 59:50 - снова про проекты 01:03:00 - про рабочие встречи у которых нет четкой темы 01:09:42 - вопрос про процессы и cargo scrum - время vs фокус, PDCA 01:16:46 - scrum как обертка, пример ситуации когда командам он неактуален 01:23:20 - трата сил на оценки задач 01:32:00 - продуктовая грамотность vs инженерная культура 01:37:30 - влияние предсказательной силы 01:39:00 - огорчение от осознания неэффективности действий программистов внизу цепочки 01:41:00 - костыль в виде A/B тестов 01:43:33 - пример внедрения A/B тестов в Badoo (ледокол неизвестности) 01:48:00 - про горизонт окупаемости в 10 лет 01:50:00 - Net Income Per Employee (NIPE) и тп 01:52:47 - методы приоретизации тасок на примере Weighted Shortest Job First (WSJF) 01:58:30 - полезно ли вообще логирование времени

2021-03-30 00:00 - как реагировать на инциденты, постмортемы, резервирование 18:20 - аналогия с пробоем конденсатора 21:00 - что такое постмортем 22:55 - логистическая кривая 24:53 - предсказание пробоя 25:24 - принцип разбора ошибок 27:20 - нужна постоянная тренировка поиска корневых причин на ошибках, редкий постмортем малополезен 32:09 - много постмортемов => более надежная система 37:21 - подытог 39:05 - спираль качества 40:20 - нужен ли поиск виновных 49:20 - проблема экспоненциальных процессов 51:08 - нет единой корневой причины 53:00 - время жизни без техобслуживания и минусы автоматизации 58:21 - социотехническая система должна делаться с запасом возможностей - не слишком надежна, а достаточно надежна 01:00:36 - стабильность vs ригидность и jira sunk cost fallacy 01:02:40 - итерации в найме 01:07:20 - еще раз про поиск виновных 01:09:00 - нельзя просто так взять и стать blameless 01:13:28 - и еще раз про поиск виновных

2021-03-23 3:44 - начало 6:03 - формулировки вопросов: про типы задач и про задачи-research'и, proof of concept и т.п. 9:20 - начало ответа: про смысл исследования и фреймирование инструментами 14:00 - выбор информационной модели 15:28 - как должен выглядеть результат research задачи 17:00 - про 2 этапа исследования: получение модели проблемы и выбор инструмента 19:00 - почему у research такой цикл 19:50 - на сколько мелко бить задачи (разработка, проектирование, исследование) 26:30 - отличия research задач от проектирования и разработки 27:55 - definition of done исследования (вопрос, ответ, обоснование) 41:28 - что такое информационная модель 50:25 - что делать с рисками в оценке времени 57:31 - вопрос про платформенные команды 1:19:00 - тесты 1:39:00 - итог про тестирования 1:43:00 - ценность разных точек зрения 1:46:00 - еще про тестирование 1:47:40 - важность наличия тестовой системы 1:59:00 - про риск при выкатке 2:11:00 - мониторинговые тесты

2021-03-16 03:54 - гендерное неравенство 35:00 - экспертиза: вглубь vs вширь 41:56 - навык получения доменных знаний 49:30 - обучение через "изобретение велосипеда" 53:57 - стиль обучения YCombinator 57:00 - ориентиры для развития 1:12:18 - игра с нулевой суммой 1:23:58 - когда не поздно делать карьерный pivot 1:27:15 - survivorship bias 1:28:18 - хорошо где нас нет 1:29:00 - отсылка на главу про планирование (Глава 2) 1:30:00 - цели: в работе vs вне работы 1:33:55 - деньги как ресурс для достижения целей 1:41:50 - разрешение противоречий личных интересов и интересов компании 1:44:22 - польза фундаментальных знаний и необходимость reality check 1:50:27 - проще изучать не значит игнорировать остальное 1:53:32 - истории самому себе => интерес 1:56:00 - мультидисциплинарность 2:02:00 - квадраты незнания 2:20:25 - Web 2.0 2:27:38 - распределенные базы данных 2:47:15 - xmpp

2021-03-10

2021-03-09 00:00 - обучение выступлениям 04:54 - прозрачность и github effect 10:20 - доклады по запросу и их монетизация 21:00 - что делать когда пришел в команду а там все плохо 23:00 - пример когда результата нет в команде 23:50 - первое изменение возможно через 3 месяца 24:05 - проверить наличие обратных связей 25:06 - проверить обмен информацией между бизнесом и разработкой 26:40 - понять про потоки, СМО и т.п. (см выпуск про ПУСКИЛИЦ от Олега Сороки) 27:00 - scrum vs kanban 28:55 - закон Литтла для систем без тренда 30:00 - время выполнения 32:20 - замер до того как что-то делать 35:30 - система в которой будут улучшения 37:50 - по очереди: чтобы работало => правильно => быстро 38:15 - аналогия со стрельбой из орудия 39:40 - фейлы как источник информации, запуск изменений, показ примера 43:30 - начать с стрельбы и коррекции 45:05 - повторение того что нужно делать в начала 46:21 -  4-16 часов на задачу 47:20 - кто дробит задачи: дальность стрельбы 54:17 - estimates, результат, в конце проектирования декомпозиция с оценками, в конце исследования ответ на вопрос 57:10 - картбланш для тимлида, пример как перехватить инициативу 1:00:00 - возможные возражения, ttm меньше, но прогнозирование больше 1:03:50 - в итоге начнет работать закон Литтла и можно будет пользоваться простыми инструментами из книжек 1:08:00 - мелкие брать, крупные нет  => возможность оптимизации 1:13:50 - арбитр 1:16:00 - карт-бланш 1:21:02 - найм ответственного 1:25:48 - вопрос про scrum 1:28:00 - выдают 0 задач но помогают другим 1:31:40 - недопонимание при вкидывании крупных задачах 1:33:20 - почему 2 дня 1:45:20 - разница с канбаном, пример из книги 1:48:30 - переключение контекста и планирование 1:50:00 - оперирование числом задач вместо оценок, вместо графиков для предсказуемости: число задач 1:55:23 - уязвимость систем после оптимизации, эффективность vs стабильность 1:57:04 - цвета задач для blameless 2:01:05 - взгляд со стороны как арбитр встреч в зуме

2021-03-02 Олег Сорока описал свою модель разработки программного обеспечения "ПУСКИ ЛИЦ". Потоки Уровни Системы Контексты Истории Люди Идеи Цели Менеджеру полезно понимать про каждый из этих наборов: некоторые наборы знать хорошо, а об остальных хотя бы иметь представление, чтобы не применять слепо готовый фреймворк (SCRUM и т.п.). Конспект доклада от автора – Олега Сороки

2021-02-23 00:00 - Виталий Шароватов - как давать расти ( текст + доклад) 08:00 - cld как мост в сторону системных вещей 11:10 - кто такой тимлид 13:20 - на developer experience у тимлида нет времени 15:00 - фокус на том что кроме кода, либо кодить либо управлять 20:38 - тезис про 75/75 процентов 23:42 - может ли cto не иметь тех опыта 26:00 - должности vs роли vs компетенции 30:00 - карго культы в разработке по 32:40 - как нанимать  38:00 - test driven найм 39:00 - роль референсов в найме, уровень мудачества 44:00 - руководство по общению с собой 45:00 - испытательный срок, положение об испытании 52:00 - что делать рукрутеру если найм сломан - обучать нанимающих менеджеров 57:00 - уровень доверия тимлиду, уменьшение затрат на найм 59:00 - требования к вакансии: какая работа vs stack 1:07:17 - задача о разборчивой невесте в приложении к найму 1:10:00 - понимание какая работа требуется от кандидата чтобы понять нужен ли найм 1:12:40 - если не устраивает результат то можно делать наоборот, анонс доклада @vfabr про практики

2021-02-16 00:00 - роль степени близости к чаяниям пользователя для бизнес результата 02:51 - дисфункция когда задачи менеджмента это минимизация факапов 04:20 - почему стараются делать продуктовые команды, минимизация потерь информации 07:40 - value-stream map vs текущая орг структура 08:17 - вопрос про активности заранее чем возникнет проблема у пользователя 09:35 - ответ: фичи как побочный эффект, отсылка к ТРИЗ, пример refund в Amazon 14:30 - вопрос какая есть альтернатива платформенным командам 15:29 - инвестиция в архитектуру (Conway's law) с учетом бизнес-составляющей, в знание домена и пользователя, формат команд в зависимости от того что получится, Logistics/Payments/UX, а не по Java/DBA/Admin 18:55 - вопрос как поделить input от запрос по командам 19:31 - трансляция user journey в user story, product owners, аналитики, ux servant 22:20 - вопрос product role vs команды 22:40 - есть доменные эксперты и кто то из них выполняет роль транслятора в user story; роль следует из того что пользователю нужен какой-то продукт и роль ux servant, интерпретатор пользователя 24:14 - product как компонент информационной системы, если продукты говорят что, а разработчики как, то через какое то время продукты будут не успевать генерировать что; 26:50 - как обеспечить наблюдаемость продакт принес не то или разработчик сделал не то, чтобы понять кого не хватает 28:42 - баланс полномочий и ответственности усли нужно убрать продакта 30:00 - как понять в каком состоянии находится система, проблемные места 31:00 - что если все растут 31:48 - стопор если упереться в количество знаний 33:20 - если нет времени умнеть, то нужно ограничивать поток задач 34:00 - блокер таких изменений если нет ощущения их необходимости, если есть поток ресурсов 38:00 - опыт @vfabr что тот кто в самом верху не против инициировать изменения, главные противники изменений среднее звено 41:54 - отсылка к STATIK (видео, статья, книга (eng), книга (rus)) и kanban maturity model (1, 2, 3) 43:39 - учет хрупкости, ригидности и гибкости при большом зазоре между уровнями компании, отделов, команды, человека; 45:20 - эволюционность vs трансформационный подход, эффект отторжения 46:25 - credibility для способности внести изменения 47:10 - bring your own device, shadow it, гильдии, trello 50:25 - inversion of control для процессов 52:00 - как способствовать переходу количества изменений в качественное изменение 57:00 - вопрос как научиться строить value-stream map 59:24 - value-stream mapping vs разделение по domain областям 1:03:00 - unknown unknown => t-shape; known unknown => specialization 1:05:00 - изменения, эволюция ментальных моделей => t-shape/роли 1:07:00 - сделать хоть что-то с тем что есть чтобы появились вопросы и стало понятно что учить