Берём DEMO и препарируем им альфу "Работа"
Сегодня на встрече сообщества Школы системного менеджмента был чудесный доклад Александра Турханова "Программный менеджмент -- онтика организации работ". Он был про структуру альфы "Работа", которая становится видна из альфы "Команда" в методе описания DEMO. Основной слайд 16 (https://www.dropbox.com/s/drx0w84xca7zlrr/Capability%2016-Nov-17%20%28full%20version%29.pptx?dl=0) -- "как смотреть на полосочку работы из диаграммы Гантта, если учитывать DEMO". Мне более чем понравилось, это хороший пример методологической работы. Удалось записать доклад (https://youtu.be/MHH-bLdrg7o):
Для курсантов Школы понимание доклада будет хорошим тестом на понимание всего курса системного менеджмента. При этом понимать нужно немного больше, чем курс -- хорошо бы понимать хотя бы основы DEMO и какие-то азы управления проектами, программами, кейсами.
Про DEMO подробней -- http://ailev.livejournal.com/644440.html
Ещё я помянул, что обязательство не равно обещанию -- это разбирается в теории обещаний: https://en.wikipedia.org/wiki/Promise_theory. Не так чтобы я сразу рекомендовал её использовать со всеми прилагающимися формализмами, но раз уж мы заговорили о разнице между "могу сделать/есть capability", "меня попросили", "я обещал", "я сделал", "сделанное у меня приняли", то можно обратить внимание и на разницу между "обещанием" и "обязательством" -- In Philosophy and Law a promise is often viewed as something that leads to an obligation. Promise Theory rejects that point of view. Bergstra and Burgess have shown that the concept of a promise is quite independent of that of obligation and indeed is simpler. Вот айтишники уже там окапываются: https://www.infoq.com/news/2017/11/jonas-reactive-summit-keynote
Самый конец дискуссии (про направления развития софта поддержки деятельности) вообще огонь. Работы (изменения) поддерживать должен трекер, технологии удерживаются системой управления конфигурацией (версии это наше всё!), команда поддерживается мессенджером (в котором каждый "чатик" -- это команда кейса). Логиниться, конечно, через телефон (а не пароль-логин! это ж "мессенджер" с наворотами с точки зрения участника команды) -- и opt-out (то есть в кейсы/чаты тебя затаскивают, и ты уходишь, если это не твой кейс -- возможно, вываливаясь при этом в дискурс-по-DEMO, ведь не ото всех дел ты можешь отказаться). И где-то над трекером есть система планирования, которая не даёт тебе заняться всеми сразу известными делами, в ней живёт канбан, ограничивающий WIP. К этой системе потихоньку с разных сторон все мессенджеры и issue trackers ползут, хотя и медленно.
Спасибо Александру за доклад, он удивил меня этим докладом не меньше, чем когда из буквально одного слайда родил за полгода двухдневный тренинг по системному лидерству (ближайший у него 2-3 декабря 2017, https://ailev.livejournal.com/1385713.html).
Click to viewДля курсантов Школы понимание доклада будет хорошим тестом на понимание всего курса системного менеджмента. При этом понимать нужно немного больше, чем курс -- хорошо бы понимать хотя бы основы DEMO и какие-то азы управления проектами, программами, кейсами.
Про DEMO подробней -- http://ailev.livejournal.com/644440.html
Ещё я помянул, что обязательство не равно обещанию -- это разбирается в теории обещаний: https://en.wikipedia.org/wiki/Promise_theory. Не так чтобы я сразу рекомендовал её использовать со всеми прилагающимися формализмами, но раз уж мы заговорили о разнице между "могу сделать/есть capability", "меня попросили", "я обещал", "я сделал", "сделанное у меня приняли", то можно обратить внимание и на разницу между "обещанием" и "обязательством" -- In Philosophy and Law a promise is often viewed as something that leads to an obligation. Promise Theory rejects that point of view. Bergstra and Burgess have shown that the concept of a promise is quite independent of that of obligation and indeed is simpler. Вот айтишники уже там окапываются: https://www.infoq.com/news/2017/11/jonas-reactive-summit-keynote
Самый конец дискуссии (про направления развития софта поддержки деятельности) вообще огонь. Работы (изменения) поддерживать должен трекер, технологии удерживаются системой управления конфигурацией (версии это наше всё!), команда поддерживается мессенджером (в котором каждый "чатик" -- это команда кейса). Логиниться, конечно, через телефон (а не пароль-логин! это ж "мессенджер" с наворотами с точки зрения участника команды) -- и opt-out (то есть в кейсы/чаты тебя затаскивают, и ты уходишь, если это не твой кейс -- возможно, вываливаясь при этом в дискурс-по-DEMO, ведь не ото всех дел ты можешь отказаться). И где-то над трекером есть система планирования, которая не даёт тебе заняться всеми сразу известными делами, в ней живёт канбан, ограничивающий WIP. К этой системе потихоньку с разных сторон все мессенджеры и issue trackers ползут, хотя и медленно.
Спасибо Александру за доклад, он удивил меня этим докладом не меньше, чем когда из буквально одного слайда родил за полгода двухдневный тренинг по системному лидерству (ближайший у него 2-3 декабря 2017, https://ailev.livejournal.com/1385713.html).