Afleveringen

  • Алексей Пименов

    Основатель и Аккредитованный Канбан тренер, консультант

    Аккредитованный тренер Kanban University, первый российский специалист уровня Accredited Kanban Consultant, преподаватель международного консорциума ICAgile. Тренер и консультант по темам Kanban Method и Business Agility. Спикер на тематических конференциях, автор статей, научный редактор книг, создатель и активный участник тематических сообществ.

    https://neogenda.com/

    http://pimenaus.ru/

    0:41 Эволюционные изменения и адаптация в канбан-методе

    2:00 Канбан-метод - это инструмент управления работами. Проактивное и реактивное развитие организации.

    3:57 Теория канбан-метода

    4:35 На что оглядывались при разработке канбан-метода?

    7:39 Литература для изучения

    11:20 Так ли уж ИТ-проекты отличаются от промышленного производства и как это влияет на применение канбан-метода?

    13:02 Канбан-метод - это "градусник" для измерения температуры процессов

    15:47 Как описывать деятельность на разных уровнях организации?

    16:25 Фрактальный подход к описанию клиентских сервисов

    19:05 Неудачный пример для применения канбан-метода

    20:23 Контекст применения канбан-метода

    22:31 Какие решения помогает принимать канбан-метод?

    23:23 Загрузка производственной системы и как обеспечить продвижение работы?

    25:30 Про современных менеджеров

    25:50 Как продвигать канбан-метод?

    27:31 Канбан-метод в условиях жестких дедлайнов

    31:30 Про консультантов и их ответственность

    35:05 Как выбирать консультантов?

    39:56 От чего зависит цена специалиста на рынке?

    45:50 Должен ли заказчик понимать тонкие различия между предлагаемыми методами и инструментами?

    48:10 Про чуйку в консалтинге и выход из контракта

  • Начало дискуссии см. https://www.facebook.com/alex.turkhanov/posts/10227359446308954

    0:20 Что такое продуктовый менеджмент 

    2:20 В чем заключается роль продуктового менеджера 

    6:20 Agile и продуктовый менеджмент 

    9:20 Архитектура продуктовых команд и производственные систем 

    12:50 Проблема "сшивки" предметных областей 

    17:20 Никакой магии и волшебных таблеток не бывает 

    17:38 Какие подходы к решению проблемы организации продуктовой разработки есть 

    27:47 Управление рисками в продуктовой разработке 

    33:45 Подводим итоги обсуждения 

    34:30 "Вишенка на торте" и нужна ли математика продуктовым менеджерам 

    36:25 Что такое эффективный продуктовый менеджер в российских условиях 

    37:30 Нужны ли процессы разработки? 

    39:00 Где и чему учиться  

    https://www.linkedin.com/in/pkapustkin/

    tutnet.ru  (Личный веб-сайт) 

    facebook.com/pkapustkin  (Блог) 

    [email protected]

  • Zijn er afleveringen die ontbreken?

    Klik hier om de feed te vernieuwen.

  • Топикстартер - статья "Как понятие проекта раздулось до полной потери смысла и что с этим делать?"  

    https://link.medium.com/t9P681CUZlb 

    Содержание эпизода

    1:11 Тема обсуждения 

    2:10 Источники практик проектного менеджмента 

    3:47 Мобилизационный аспект проектов 

    4:37 Особенности внутренней проектной организации 

    7:00 Проекты, которые не проекты 

    9:23 Почему деление на "это проекты, а это не проекты" непродуктивно? 

    12:24 Польза практик и инструментов проектного менеджмента 

    13:56 Про критерии приемки и deliverables (непереводимый термин) 

    15:52 Использование активов организации 

    17:10 Назначать задачи и контролировать их исполнение - это не задача проектного менеджера! 

    18:44  Про регулярный проектный менеджмент 

    20:45 Что такое активы организации? 

    24:27 Проблема слабой матричной организационной структуры 

    27:09 Разбираемся с понятием deliverable на примере 

    30:34 Разделение ответственности между проектным и линейным менеджером 

    32:38 Завершение  

    Контакты:  Александр Турханов, проектный менеджер и системный инженер [email protected] https://www.facebook.com/alex.turkhanov/ https://alex-turkhanov.medium.com/ https://ttttt.me/kill_aristotel 

    Антон Полисский https://www.facebook.com/anton.polisski https://www.linkedin.com/in/polisskiy/

  • Первое интервью с Александром Лучковым https://link.medium.com/jZ53slUJfmb 

    Этот выпуск

    0:17 Тема обсуждения и проблематика 

    3:00 Что происходит с системной архитектурой? 

    6:13 Чем системная архитектура отличается от модели предметной области? 

    8:17 Где проходит граница между системными описаниями и описаниями контекста? 

    11:06 Важна ли согласованность системных описаний? 

    16:39 Классы и экземпляры в системных описаниях 

    19:01 Как быть с имплицитными описаниями? 

    19:56 Как учитывать паттерны и культуру обращения с классами систем? 

    25:16 Можно ли потерять системную архитектуру? 

    29:11 Инженерная археология и brownfield systems architecture 

    32:48 Как системный архитектор взаимодействует с командой?

  • Видео сделано на основе одноименной статьи https://docs.google.com/document/d/1imCRD8texMpN9SfJzdlXrRZ_V-AusClcMNJZnwFpG7E/Несмотря на распространение идей, понятий, инструментов и методов проектного управления, само содержание дисциплины утрачено, а профессия проектного менеджера постоянно деградирует. Понятие проекта потеряло важнейший компонент своего изначального смысла - мобилизацию и реорганизацию ресурсов для достижения цели, из-за чего мы потеряли целое пространство рассуждений о путях достижения поставленных целей. Нам надо восстановить исходное значение понятия проект и перестать играть в словесные игры и запутывать друг друга. Только так мы сможем четко понимать, где проходит граница ответственности проектных менеджеров, за что они отвечают и способны ли они нести возложенную на них ответственность. Аннотация Проект является комплексом взаимосвязанных мероприятий, который направлен на пошаговое воплощение единого замысла, при этом на время исполнения проекта мобилизуются ресурсы одной или нескольких организаций в их уникальной комбинации. Отсутствие любой из значимых характеристик - замысла, временной мобилизации ресурсов или специальной организации этих ресурсов по отличным от основной деятельности правилам и практикам, - приводит к появлению вырожденных проектов. Проблема современного состояния дисциплины в том, что таких вырожденных по одной или даже нескольким характеристикам "проектов" стало слишком много. Обсуждение вырожденных проектов в логике классической дисциплины проектного менеджмента является бессмысленным, потому что вырожденные проекты не являются объектом исследования и управления этой дисциплины.Однако многочисленные попытки применять ее методы, инструменты и практики к управлению вырожденными проектами и анализировать результаты с почти неизбежным выводом о неэффективности проектного управления и т.н. "водопадного метода" создают неверное представление о ее возможностях, сценариях применения и уничтожают профессию проектного менеджера.В этой статье предлагается к обсуждению понятийный аппарат, с помощью которого можно понять границы ситуаций, в которых проектный менеджмент применим и может быть полезен. Приводятся аргументы, что без определения границ применимости мы как профессионалы проектного управления обречены на дальнейшую деградацию профессии.

  • Несмотря на то, что дисциплина инфостиля резко улучшает качество непосредственной коммуникации, ее совершенно недостаточно для организации коммуникации в больших проектах по причине того, что инфостиль не полностью поддерживает дисциплину кейс-менеджмента. Большие проекты требуют совместного применения дисциплин инфостиля и инженерии текста для построения объяснительных и доказательных текстов.

    Проблема трансдицисплинарной коммуникации в больших проектах - отсутствие инфраструктуры рутинного решения проблем.

    Проблемы решаются текстами-объяснениями и текстами-доказательствами. Эти тексты пишутся с помощью одних и тех же дисциплин (инфостиль и инженерия текста). Дисциплина инженерии текста больше подходит в качестве инфраструктурного решения проблемы трансдисциплинарной коммуникации в больших проектах.

  • https://miro.com/app/board/o9J_ktPEzpY=/

    Понимая, из чего состоят цепочки поставки ценности и какое место вы в них занимаете, можно либо перестроить текущий продукт, либо создать новый. Например, схожий продукт с меньшей стоимостью или большей ценностью. Такой системный подход к анализу рынка и разработке продукта позволяет за пару дней выявить почти все потенциальные варианты улучшений, доработок, нового позиционирования в привычной бизнес-среде и перейти к планированию бэклога.

    На семинаре на практических кейсах разбираем:

    - что такое value chain и как ее построить;

    - как найти точки кратного роста в цепочке поставки ценности;

    - как понимание цикла развития продукта помогает сократить издержки;

    - как оценить целесообразность доработок и превратить инсайты в задачи бэклога.

    https://youtu.be/X2F2Dy2mgsU

  • Чем системное проектирование отличается от модульной сборки? Где чаще всего допускают ошибку при чтении и интерпретации V-модели? Почему архитектор подсистемы не должен принадлежать ни одной команде разработки, а должен быть в команде управления проектом вместе с руководителем проекта?

  • Если у вас есть программно-насыщенный продукт (автомобиль, телефон, самолет, программно-аппаратный комплекс), с кучей неопределенностей по тому, как его разрабатывать, создавать и обслуживать, то вы не можете создать классический план проекта, выделить ресурсы, написать ТЗ на проектирование и внедрение и проконтролировать исполнение. Точнее, можете, но это бессмысленно. Альтернативой №1 будет строить продукт короткими итерациями и иметь только краткосрочные планы. Но при этом вы игнорируете долгосрочные риски разработки и эксплуатации. Альтернативой №2 является использование дисциплин системной инженерии и программного менеджмента для поискового решения проблем. В этом выпуске я делаю общий обзор того, как работает такое сценарное планирование и прохождение системных развилок.

  • Подкаст про цепочки доверия и архитектуру доверия.

    Межсубъектное доверие или доверие к системам? Семантические нюансы trust vs. confidence. Не бывает confidence к голосовому ассистенту.

    Цифровые инструменты поддержки доверия скомпроментированы, дискредитированы и в текущем виде не поддерживают процесс цифровой трансформации.

    Отсутствие очевидных решений проблем с безопасностью IoT. Кибербезопасность, устойчивость сетей к атакам, правовые проблемы и границы ответственности операторов.

    "Мышки, станьте ежиками!" Мы сползаем в ситуацию, когда мы все больше зависим от агентов, к которым нет доверия.

    Проблемы безопасности в США и identity theft.

    Дискредитация ЕЦП - 3,5 млн. инцидентов в России.

    Навес токсичных бизнес-практик, автоматизация фрода, неограниченное его масштабирования, снижение порога вхождения в криминальный бизнес.

    12 шагов решения проблемы.

    Как компании могут измениться? Кризис охватывает настолько много областей, что чисто технические решения проблем не помогут. Необходимо наращивать уровень решения проблемы, выходить в надсистемы.

    Проблема распадания картины при транссистемном переходе. Западные разработки в этой области - Cristiano Castelfranchi Trust Theory: A Socio-Cognitive and Computational Model (with Rino Falcone). 2010.

    Почему нельзя сводить доверие только к минимизации возможности? Надо фокусироваться на дополнительных возможностях, иначе контроль над бизнесом захватят безопасники, юристы и финансисты, а предприниматели и инженеры будут на вторых ролях.

    Архитектура доверия, которая шире архитектуры безопасности. Экономическая состоятельность проектов по инфобезу. Какой уровень доверия экономически обоснован?

    Цепочки доверия. Кто виноват в компроментации датчика? Цепочка доверия переходит в архитектуру доверия, адекватность схематизации.

    Различие между рисками и доверием. На чем концентрируемся - на опасностях или на возможностях заработать? Важность нейрофизиологии в принятии решений.

    С какими издержками будет сопряжено оспаривание, ситуация компроментации и т.п.? Защита интересов пользователя инструмента доверия. Два способа защиты - защита сувереном территории (сейчас основной) и покрытие убытков (сейчас не используется).

    Экономическая защита пользователей инструментов рисков. 

    Статья по ссылке.

  • Почему бизнес-аналитик или проектный менеджер вряд ли вырастет в системного архитектора, что такое "серый ящик", чем solution architect отличается от systems architect и от чего зависит количество итераций в проекте.

    Лучков Александр, практик-исследователь применимости системного подхода в области проектирования технических систем. Действующий участник российского отделения INCOSE.

  • Блок 4.

    Предсказания и научный метод как способ делать предсказания.

    Почему это работает, научный метод. Беспорядочно поливаем уе. Делаем как другие. Долго думаем делаем. Делаем проверяем правим, это не истинно системный подход, но где взять время на правильный системный подход. Кроме того в системе систем запроектировать ничего нельзя.

    Про баеса немножко и его сети.

    Ищем, почему может реализоваться ветка и почему она может не реализоваться. 

    Событие может наступить, а причины не будет. Цифровой двойник организации или цифровой сон организации?

    У вас не будет возможности как в науке полагаться на остальных, потому что текущее представление о мире хранит сеть агентов. 

    Биржа предсказаний на предприятии плохо работает, когда на ней мало экспертов. Как создать сеть адвокатов дьявола на предприятии?

    К вопросу об убедительности против доказательности.

    В итоге не верите себе. Это путь к болоту, где впрочем неплохо. 

    Загадка личной мотивации. Каждый сам отвечает в какой-то момент зачем его занесло на эту галеру.

    Вывод: хорошая стратегия может быть основана только на бирже предсказаний, где текущий курс действий постоянно ставят под сомнение другие эксперты. Иначе это не стратегия, а цифровой сон организации.

  • Блок 3. Ресурсы ограничены, сконцентрируйтесь.

    У вас может не быть второго шанса, внешние изменения сделают проект ненужным или слишком дорогим.
    Пока растете по всем фронтам, можно и помереть. Строго один шаг стратегии за раз.
    Концентрация в форме предсказаний о будущем. Предсказания должны быть проверяемые, надо указывать граничные условия, чтобы можно было понять, что пошло не так.
    Сделать будущее в форме тестов и приближений.
    Почему будущее нельзя спроектировать?
    Бонус - регулярная подпитка дофамина в мозг, на длинных проектах это спасает от того, чтобы сдаться, не дойдя до цели.

    Итог: спроектировать будущее нельзя, но можно двигаться к нему короткими шагами, постоянно проверяя на достаточно твердой почве мы находимся или нет.

  • Блок 2. Образ стратегии

    Что является стратегией, а что не является стратегией?

    Составляющие стратегии - куда, где находимся сейчас, путь и вехи движения. И главное - зачем?

    Вопрос "зачем" бесит больше всего в обсуждении, он же пробный камень любых хотелок.

    Записывайте цель в виде предсказаний о будущем. Фиксируйте предположения и проверяйте их.

    Вас жизнь все равно тащит в какой-то вариант реальности, вопрос будете сопротивляться или направлять движение?

    Люди, с которыми вы работаете над проектом, имеют свои представления, если вы их не знаете, то шансов прийти в нужную вам точку меньше, чем если знаете и управляете ими.

    Итог: не врать можно только одним способом - тебе должны верить.

    Итог: не врать можно верить только одним способом - тебе должны верить.

  • Блок 1. Зачем нам стратегия?

    Она позволяет оптимально расходовать ресурсы для достижения заданной цели.

    Она выявляет вранье. Мы врем куда хотим попасть и зачем мы туда хотим попасть. Стратегия выводит истинные мотивы наружу, делает их видимыми.

    Она позволяет увидеть конфликты интересов и что-то с ними сделать.

    Она позволяет избежать ситуации "хотели как лучше а получилось как всегда".

    Итого: стратегия нужна, чтобы приходить туда, куда вам надо, с минимумом усилий и не пожалеть об этом.