Пожалуй, прошедшая конференция SECR стала для меня первой конференцией, на которой я из-за общения в кулуарах пропустил много докладов, на которые планировал пойти. И еще больше докладов, на которые я не пошел, потому что они конкурировали с другими докладами, или с общением, а по названию или аннотации я их не отметил к посещению. Это происходит потому, что на SECR - замечательные участники, с которыми интересно разговаривать и можно узнать много содержательного.
Из отзыва Тимофей Левицкого на конференцию, показывающего особенности аудитории SECR: Всё-таки полезно ездить по конференциям. Особенно выступать. Столько нового узнаёшь! Приехал поведать коллегам, как правильно "дружить" стартапы и корпорации. Хорошо, вовремя сообразил, что на SECR ходит много хорошо подготовленных слушателей, которым интересно не потому, что ух ты всё такое новое, а потому, что они знают 80% ответа (и поэтому у них хорошие вопросы). Вот благодаря вопросам многое удалось прояснить). И почему "песочница" обычно не работает, и почему "акселератор" может внезапно сам замереть... Ольга Самарина, спасибо!
Зато многие доклады мне придется смотреть: Филипп Дельгядо "Каждой фазе проекта – своя методология. Как и зачем", Евгений Зиндер "Архитектурное мышление и планирование software-продуктов для цифровых предприятий", Кирилл Улитин " Исследование эмоциональных откликов при чтении документа", где инструмент исследования - нейрошлем, Игорь Дёмин "Кратчайшая история криптоанархии", Сергей Нужненко "Проектирование системы, как процесс мышления", Светлана Мухина "Коучинг Скрам Мастеров. Истории успеха и другие происшествия", Ксения Антонова "DeepDive with experts: share to improve", и другие.
Так что не полагайтесь на мои отзывы, а смотрите записи, когда они появятся. Или не появятся, потому что Стас Фомин, который ведет съемку, на закрытии конференции сказал, что хочет подтверждения актуальности его съемок докладов в виде комментариев на http://0x1.tv/Category:SECR и будет выкладывать видео по мере появления комментариев на этом сайте, или на facebook/вконтакте - в конце каждой публикации там ссылка на странички. Так что просьба ко всем, кто меня читает и смотрит видео конференций - вспомните о своих просмотрах и напишите комментарии, лучше, думаю, в соцсетях - так другие тоже увидят.
А теперь - мои впечатления о докладах, которые я писал на FB в ходе конференции. По части из них много заметок, поэтмоу в отдельных разделах.
Пост на FB Анатолий Левенчук. Стейкхолдерское мастерство - подробный рассказ в театральной метафоре. Стейкхолдер: действующее лицо из театральной метафоры. Принц Гамлет и есть - исполнитель. В театре - понятно, обращаемся к роли или актеру. А в жизни - путаем.
Но дальше - следующие шаги. Лидер в театральной метафоре - это режиссер. Курсы лидерства - есть, там режиссеров учат заталкивать людей в требуемые роли. В то время, как люди не хотят. А вот актеров занимать роли - не учат. Вернее, настоящих-то актеров учат - держать в голове 20 ролей, не сливаться с ними, подирать роли для своего амплуа. А вот в жизни сотрудников - не учат занимать роли. А это нужно.
Чему нужно учить:
Большинство педагогов работают как мастер - соло. Без разделения труда и разделения работ. Моделирование - мало и неформальное.
А правильно - инженерный подход. Не "я сам себе мастер", а "мы сами себе инженеры" - коллективная работа. Множество ролей, множество обучающих и так далее. Человек не проще атомной станции - и работать надо соответственно.
Модель личности
У нас - киберличность, а не личность - экзокортекс, экзотело.
Внимание - можно не медитировать, а просто за полминуты записать. Те же вечные ценности, но другими методы.
Психотехника удержание внимания на двух фокусах.
Каждый учебник - учебник игры по роли. Группа - вместе играем пьесу. Скооперируйся с другими группами для большого представления. Включая мертвых - они участвуют через книжки.
А когда режиссер-лидер заталкивает себя в роль - понимай, что происходит и сознательно соглашайся или отказывайся. И если уж согласился - играй честно.
Вообще пересказывать сложно, но - как есть. А так - будет запись, смотрите.
Анатолий Левенчук Вот слайды: https://www.slideshare.net/ailev/ss-119256332 (для страдающих от Роскомпозора -- https://yadi.sk/i/3sKV-D10PiDGMQ)
Из обсуждения. Вадим Овечкин Генеральный директор - роль?
Пост на FB Александр Турханов. Распределенное лидерство и SysArchi. Очень интересный опыт. Александр Турханов читает курс системного лидерства в школе Анатолия Левенчука. Рассказывал он про распределенное лидерство в строгой модели - мы делим лидерские обязанности между стейкхолдерскими ролями, которые при этом могут совмещаться в одном человеке, или быть распределены между разными людьми. При этом случай совмещения и возникающих взаимодействий тоже разбирался на конкретном примере: Александр-business-actor ставит Алксандру-спикеру задачу выступления на конференции, исходя из собственных интересов. И обозначено не просто переключение между позициями, а смена онтологии, свойственной каждой позиции. И еще отдельная позиция, Player, который отвечает за смену позиции, и которых тоже у человека может быть несколько. При этом позиции стейкхолдеров нормативно закреплены в культуре, мы имеем 200-300 стейкхолдерских позиций на отрасль. А Archimate и его редактор SysArchi позволяет все это формально описывать, и эта часть тоже была в докладе.
Доклад был на английском - это часть эксперимента SECR, позволяющая докладчикам и слушателям прокачать свой скилл английского языка. И поэтому я не постил впечатления в темпе доклада - этого я пока не умею. А то бы было много больше.
В комментарии Александр Турханов раскрыл тезисы:
Мы инженеры и должны такой софт сделать, я расскажу как.
Слайды https://yadi.sk/i/DgjcxXh3yPjQIA
Пост на FB Анатолий Левенчук. Как и какое мышление нужно развивать. Журнал выступления - оно того стоит.
Позиционирование: Ты - говоришь мысли другим деятелям, или деятель сам, воплощаешь свои мысли в реальность?
Сколько процентов занимаетесь будущим, а сколько - текучкой? Винни-Пух знал, что есть другой способ подниматься по лестнице и точно его бы вспомнил, если бы так не бумкало в голове. А вы готовитесь к будущему - у вас текучка сильно булькает?
Чем не займетесь: помним, что не всех извозчиков взяли в таксисты? А сейчас и таксисты исчезнут, и nvidia уже презентовала автомобильный компьютер, который провел автомобиль 180 километров по силиконовой долине. И суперкомпьютер, чтобы учить этот компьютер ездить по дорогам.
Будущее - как туман: вблизи все в прозрачно, в трех метрах может быть невидимая стена, а все изменения приходят сбоку. Не новый тип лошадей пришел в извозчичье хозяйство. И Яндекс в такси сбоку пришел. Различать прорывные и подрывные технологии. Цифровой фотоаппарат заменил пленочный. А потом пришел смартфон и заменил не только фотоаппарат, а еще многое другое и даже сказки на ночь рассказывает.
ИИ - контринтуитивные суждения
Миф целеполагания: все важное приходит сбоку, поэтому неизменно идти к конкретной цели - обман. Цель вообще можно поставить только в ограниченной области прозрачности тумана. Надо уметь жить, не выставляя точных целей. Но оптимизируя полезность и многое другое - как в играх.
Критерий новизны: мнения экспертов разошлись, им непонятно, что там есть. Это было мнение для инвестфондов: выдавать гранты там, где мнения разделились. Потому что когда все "за" - там будет громадное количество конкурентов и мало профита.
Переход от стратегии к стратегированию - потому что движения в тумане, а он не линеен.
Моя реплика: Оказывается, я все делаю правильно: я не строю планы по достижению целей, я подвешиваю желаемые образы будущего, и дальше ищу подходящие случаи. Вообще Мизес называл этот подход "предпринимательской бдительностью".
Мы работаем не с начальником, а с таск-трекером. Потому что начальник - не помнит, а такс-трекер - помнит все задачи. А вот если мы начинаем не слушаться таск-трекера - тут-то приходит начальник :)
Закат профессий. Разотождествляйтесь с профессией. А вот компетенции - останутся. Особенно базовые - онтологии, психопрактики, когнитивное мышление.
Требования к базовому мышлению
Пирамида абстракций. Фундаментальные дисциплины.
А дальше - кругозор. Представление о всех областях деятельности: требования (use case 2.0, jobs-to-be-done и т.п.), управление работами (проектное, потоковое), системное лидерство, баа концепций и так далее.
Видим реальные объекты, поднимаемся по уровням абстракции, мыслим, возвращаемся в реальную жизнь.
domain driven design - тип онтологических процедур и надо это понимать, чтобы его использовать.
Трехдневные курсы не работают без базового образования. А вот двухчасовые доклады - работают, они дают список чеклистов.
Дисциплины по трем сферам деятельности:
Вы понимаете такое деление, мыслите в этих дисциплинах?
Научное мышление. Содержание изменилось
Вычислительное мышление: содержание изменилось. deep learning, язык отражает пространство смыслов.
Работа и со схемой, а со схемоидами. А схемоиды - это псевдокод. Нужны и схемы и схемоиды - интуиция и логическое мышление, гипотезы из схемоидов, проверка логикой, и так далее, перемещение по спектру формальности. И надо учить всем частям спектра и, главное, перемещению по спектру определенности - а этому не учат.
Фундаментальное образование - методологические дисциплины
Применять результаты образования - в жизни. Курсов не достаточно. Курсы - для жизни, а не для образования.
Надежда - на себя, а не на государство. Университеты - закрыть, те, кто умеют учить - соорганизуются и будут учить лучше государства. Он выдает курсы образования гораздо быстрее, чем в государственной системе.
Когнитивисткие дисциплины
Люди читают мой учебник и не могут вычитать то, что там написано. Не дают ответы, которые практически есть в учебнике - 97% неправильных ответов с курса на курсере.
Обучение: нельзя поднимать то место, где у вас совсем ноль, не получится. Можно прокачивать то. что у вас уже есть, но недостаточно - прокачивая, поднимаешь следующее. Есть много стратегий чтения книг, мышления. Getting Things Done - одна из них. Изучайте стратегии, выбирайте их.
Denis Beskov Он вроде все это рассказывал В ТЕЧЕНИЕ ПОСЛЕДНИХ 5 лет (на самом деле минимум 7)
Denis Beskov О, в программе был заявлен как мастер-класс. Неужели Анатолий реально продемонстрировал на себе или на людях в зале развитие мышления?
Но нужно быть реалистом: с проверкой результатов обучения в таких двухчасовых ориентационных курсах всё плохо (что, вставлять проверку того, поняли ли люди идею фундаментального образования и необходимости кругозора?). И её нельзя автоматизировать, так что это ещё и дорого (а когда можно автоматизировать, то это всё равно дорого). И мало кто на неё пойдёт, так что это ещё и утопично. И контекст этих часа пятидесяти -- это контекст конференции, где этих докладов пять треков в параллель, так что любые результаты (кроме экстраординарных) смоются в забвение.
Анатолий Левенчук Вот слайды -- https://www.slideshare.net/ailev/ss-119256910 (для страдающих от Роскомпозора -- https://yadi.sk/i/UpV8v-WFOEbX8Q)
Эта связка - потому что доклады были подряд, и обсуждения их в постах на FB тоже оказались взаимосвязаны.
Пост на FB Мой доклад Мыслить проектно: история и современность (SECR-2018). В посте Димы Безуглого продолжается большое обсуждение, читайте...
Дмитрий Безуглый О проектном мышлении, о том что у них не получалось разрабатывать по RUP, не получалось по agile ..и что нужно чтобы получилось ))
Дмитрий Волошин водопад!
Taya Saburova Гибридные методологии?
Наталья Свешникова Инструменты меняются, но проблема, похоже, все-таки в головах, и носим мы ее с собой из проекта в проект
Максим Цепков Дима, я не понял интерпретацию доклада. У кого "у них не получалось"? Доклад был про отраслевой опыт и изменение культур ведения программных проектов, я об этом рассказываю с 2015 года, и, кстати, визуальный ряд доклада появился тогда. При этом тема - развивается, это не повторение старых докладов. А если говорить конкретно об опыте моих проектов и проектов нашей компании, то мы их успешно делаем и наши клиенты это оценивают. При этом RUP я с самого начала оценивал как бессмысленные процедуры, и не пытался применить в силу явной работоспособности, а вот Scrum в свое время дал определенный импульс развития, а потом - сильно изменился внутри. И сейчас компания продолжает меняться. А в отрасли - как было 20-30% успешных докладов - так и есть. RUP и выросший из этого PMBOK не смог это повысить, повысив при этим стоимость, а Agile - дает примерно те же цифры, но дешевле и добавляет самонаведение на цель. А фокус доклада был не на этом, а на том, что в последнее время (с 2012) принципиально изменилась рамка проекта - хотя далеко не все люди это осознали.
Дмитрий Безуглый Давай по правде проекты проваливались, проваливаются и будут проваливаться. Более того успешные проекты делаются и делались и большая часть успешных продуктов появилась до Agile и продолжает появляются без Agile )) Agile is not silver bullet . Особенно agile for teams. До тех пор пока нет приемлемой статистики по успешности проектов все заявления о стандарте же факто не являются доказательством лучшей эффективности или целесообразности. Диалектику я не забываю ))
Про порог входа верно , но в целом вход в agile начинается со 2 у уровня CMMI "не тушкой, так чучелком" и по сути представляет улучшение его же. Но на полный 3-й уровень ни в одной своей ипостаси в не поднимается, хотя есть элементы и 4-ого и 5-ого. Но снижение порога имеет свою цену ..
Пост на FB Дмитрий Безуглый. Прикладная цифровая революция. От разделения труда к совместному мышлению. У доклада получилось два слоя, и один - очень крут. Это про интерпретацию Кеневин (Cynefin) фреймворка как пути технологии, от области хаоса где работают фантазеры и визионеры, через запутанную (complex) область исследователей и сложную (complicated) область инженеров, делающих решение в простую область готовых изделий для конечных пользователей. При этом современный digital-мир требует протаскивания новых продуктов и технологий по всей этой области вместо прежнего традиционного разделения труда между различными институтами. И происходит это за счет того, что операционная стоимость организации производства за счет digital-технологий (3d-принтинг, облачные инфраструктуры и многое другое) почти обнуляется. А это, в свою очередь, обрушивает традиционный цикл улучшений Деминга и многое другое из классического менеджмента, которые вообще не смотрят на исследования, теоретическую работы и визионерство, потому что они были вынесены из производства в другие институты.
Это - реально крутая и прорывная часть. А еще был слой, связанный с сильными эмоциональными нападками на Agile в его поп-варианте, который представлялся как единственный, и в этом варианте сильно отменил инженерную культуру. Я не знаю, насколько это спровоцировал мой предыдущий доклад, где я наоброт, показывал несоответствие классической инженерной культуры в современных условиях, и необходимость ее переосмысления для современности. Собственно, то, что делает Дима в основном содержании доклада - и есть это переосмысление, и, более того, место и роль Agile-практик там тоже указано. Но переосмысление надо сравнивать с идеальными объектами, а не с плохим использованием - иначе оно не доказательно. Про плохую практику и так все понимают, и надо либо показывать, что у теории не может быть хорошей практики - а это не соответствует действительности, либо сравнивать и теорию и практику параллельно. Собственно, такая двухслойная структура сильно мешает восприятию, на прогоне доклада ее не было и он воспринимался гораздо лучше. И отзыв в ходе доклада я не смог написать по этой же причине - поверхностный слой вытесняет содержание.
Обсуждение.
Дмитрий Безуглый Ты прав, меня спровоцировали твои голословные утверждения основанные на плохой практике на предыдущем докладе о не работающей инженерной культуре. И как раз поверхностность доминирующей культуры Agile пропаганды сильно мешает результативности трансформаций.
Повторюсь Инженерные практики - это 4-й 5-й уровень процессов и я его видел объективно работающим. Более того он прекрасно интегрирует в себя итеративный и исследовательсткий подход.
Сергей Нужненко Как раз у меня в докладе обсуждалась проблема планировщика против исполнителя. AGILE хорош, но его плохо применяют, причем в статистически значимых количествах плохо (хотя в подобных количествах и хорошо). Кто виноват?
А эти доклады я объединяю, потому что доклад Сергея Кушнира по сути дает частный пример для того, о чем рассказывал Алексей Пименов.
Пост на FB Алексей Пименов. LeanKanban подход к оценке и прогнозированию проектов. Начался с сильного утверждения: на основе анализа мирового опыта выполнения проектов: нет корреляции между оценками проектов и реальными сроками выполнения.
Поэтому идея: вместо оценки и диаграмм Ганта использовать SLA. Основа - спектральные диаграммы LEAN, которые позволяют ретроспективно выявить потоки характерных проектов, и работать с ними.
Дальше делаем типологию и чеклист классификации. И дальше накладываем на спектральную диаграмму - и проверяем, что получилась характерная диаграмма нужного распределения. Нормальное, пуассоново, и обобщенное распределение Вейбла - ширина пика и отстояние пика от матожидания. Из этих данных можно извлекать полезное для предсказуемости.
Например, если много коротких запросов - точно можно вычленить для оптимизации.
Но! Проблема есть толстых хвостов: fat tail. Вы обеспечиваете сервис заказчику, прилетает толстый хвост и убивает компанию.
Почему прилетает толстый хвост? Есть вариант, что в процессе реализации прилетают все новые запросы. А также многочисленные возвраты на доработку или рефакторинг.
Делаем диаграмму потоков работ. Проблемные точки
Влияние блокировок и других проблемных точек перевешивает влияние трудозатрат.
Leak time против время касания проекта. Не путать время касания с трудозатратами - потому что может быть очень малые трудозатраты.
Эффективность потока: время касания к времени производства. Обычно лишь 5-15% И надо признаться, что наши проекты больше стоят, чем идут - при том, что мы следим, чтобы "все работали".
Компания, работающая на накопление знаний - сервисно-ориентированная. Разработка софта - такая же.
В сервисе может быть несколько способов обслуживания. Эскалатор. Если все стоят на каждой ступеньке, одинаковое обслуживание - поднимется больше, но все одинаково. Если справа стоят, проходят слева - то в целом поднимется меньше, но некоторые - быстрее.
Дальше очень часто есть варианты проектов одного типа. Надо провести анализ
Дальше делаем классы проектов: горящие, обычные и фоновые.
А дальше - еще ставим лимиты, сколько мы делаем каких проектов. Горящих проектов не может быть слишком много. Если проект уходит в толстый хвост - ему можно поднять класс обслуживания. И можно отслеживать и принимать решения.
Данных много не надо. Был кейс с рекрутерами - данных за два месяца хватило. И нашли любопытный толстый хвост. Когда программист-кандидат разослал резюме в несколько мест, получил оферы и приходит к начальству и требует повышения, ему дают - и закрытие вакансии у всех вылетело в толстый хвост.
Про 5-15% - исследование Microsoft по проектам своих и партнеров примерно в 2009. Его опыт подтверждает.
Подход cocoma - на выделенную команду. А реально есть разброс по ресурсам и впихивания заказчиками работ. И это нарушает детерминистический подход - его ломает плохой менеджмент. А здесь мы смотрим, что реально у нас получается с нашим плохим менеджментом, и прогнозируем из этого.
В ответах на вопросы: для первой статистики в среднем достаточно 30 проектов/ответов на запросы. То есть немного!
Пост на FB Сергей Кушнир. Reliable Scrum: итеративная разработка и жесткие сроки. Практический доклад про решение в команде. Ситуация - команда работает с крупными задачами, которые помещаются 1-2 в спринт, при этом идет поток багов и срочных задач. И воронка проблем затягивалось, было несколько попыток решения. А дальше было решение - выделение отдельного буфера для дополнительных задач, контроль за ним, параллельно с основными задачами, за которыми тоже идет контроль. И всякие нарушения, например, впихивание задач хитрого product owner - мгновенно стало видно. В целом решение успешно, производительность выросла, и воронка пошла раскручиваться. При этом, что интересно, люди не верили и не верят, даже внутри компании, что такие относительно простые решения могли так изменить ситуацию, и ищут подвох.
Что интересно - эти практические изменения очень хорошо укладываются в общую теорию, которую Алексей Пименов (Alexey Pimenov) излагал на первом докладе. По сути они ввели два класса обслуживание с отдельными потоками и SLA, и стали за этим следить. Просто они это сделали без теории, но и без изобретения велосипедов - они использовали отдельные практики для эволюционных изменений. В частности, в докладе много ссылок на Максима Дорофеева.
Пост на FB Игорь Агамирзян - размышления о развитии разработки. Фантастическое ускорение процесса разработки и не менее фантастическое ухудшение качества. По очень многим приложениях прикладная система использует ресурсы процессоров и памяти максимум на 1% от достижимого при аккуратном программировании. Объем приложения FB за последние 2 года вырос в 2 раза. А функционал? И сейчас у нас кризис практического программирования. Экстенсивный рост, при чем без роста функционала.
Пост на FB Орхан Гасымов. Современная микросервисная архитектура. Несколько шагов преобразования от классического монолитного приложения. (1) делим монолит на маленькие сервисы, которые можно масштабируемо поднимать. Нужен реестр сервисов и маршрутизатор с балансировкой нагрузки, а вместо больших серверов получаем много легких. (2) Сами сервисы делим на Command и Query, шаблон CQRS. (3) Команды реализуем через event sourcing - пишем журнал/очередь команд-событий, и их обработчики. Никаких синхронных вызовов между сервисами. (4) Обработчики событий - через паттерн reactor - идет один основной обработчик, который все тяжелые запросы раскидывает на внешние потоки. И каждый отдельный элемент этой конструкции - легкий. Модуль - просто набор функций. В целом - реализуем реактивный манифест.
Пост на FB Александр Леонов, Анатолий Кушниренко, Никита Бесшапошников. Введение в кооперативное программирование: персональная ответственность - коллективный результат. Совершенно неожиданно - доклад был про обучение 6-летних детей программированию в детских садах в Сургуте. Успешно. При этом дети работают кооперативно: каждый пишет программу для своего робота, а роботы работают в общем поле и должны действовать согласовано. И 6-летки реально решают сложные задачи, у них цель - довести к 3 классу до полной программы 11-летней школы. Решаются сложные задачи - синхронизации, управления кланами роботов. При этом команды детей соорганизуются, друг другу помогают, но при этом программу своему роботу каждый должен написать сам. Круто!
При этом занятия ведут обычные воспитатели, обычно 40-летние женщины, после переподготовки. но! Они знают группу, если ты группу не знаешь - максимум 6 человек. Потому что если 6-летний ребенок застрял, то есть 1.5 минуты, чтобы ему помочь, иначе он выпал...
Пост на FB Александр Колесников. Поддержка работы управления проектами. TFS - наше все. Потому что (и это - за рамками доклада). И вокруг - лоскутное одеяло разных систем, потому что TFS не хватает - например, тренд за год не посмотреть. И они снаружи прикрутили Grafana для мониторинга состояния проекта - и оно получилось. Об этом и был доклад. При этом примеры графиков в докладе - высокотехнологичные, примерно такие, которые используются для мониторинга нагрузки на продуктовые сервера и другую инфраструктуру. НО IT-шники - вполне разбираются. Мониторят ход проектов так же, как мониторят продуктовые сервера, предсказывают клиентские обращения и многое другое.