2018-11-17: Highload - цифровой мир в настоящем, а не будущем

Материал из MaksWiki
Перейти к: навигация, поиск
Короткая ссылка: Highload-2018
О других конференциях
Фото Вадима Мадисона

Собрал свои заметки с Highload-2018 в единый пост. Сразу хочу предупредить, что он - совершенно не репрезентативный. Потому что на конференции - 19 треков докладов и митапов, и основное ее содержание - доклады про современные технологии разработки, обеспечивающие разработку высоконагруженных приложений. А я преимущественно был на докладах, посвященных организации IT-разработки. Там тоже было много очень интересных докладов, посвященных устройству цифрового мира, который для IT - настоящее, а не будущее. И эти доклады будут интересны не только для IT-шников, потому что все остальные в цифровом мире тоже окажутся и очень скоро. И он - неожиданный, например, из доклада Ольги Мегорской можно узнать, как Яндекс управляет работой 800 тысяч привлеченных людей, на потоке работ, в котором участвуют до 20 тысяч человек ежедневно при нулевых расходах на операционное управление. А из доклада Виктории Юркевич - о том как прагматично устроить менеджмент счастья сотрудников, обеспечив решение их профессиональных и личных проблем. Так что читайте.

Но сначала отмечу, что на 19 треках конференции было более 3000 участников. На фото - только один из залов, хотя и самый большой. Проходила она в Московской школе управления Сколково, занимая ее всю. И это здание дает отдельное, совершенно фееричное впечатление. А еще отмечу высокий уровень организации конференции - и докладов, и общения и питания. Что, впрочем, характерно для IT-конференций.

P.S. Обнаружил обалденные конспекты Николая Волынкина, которые сделаны прямо в ходе конференции https://github.com/NickVolynkin/highload-2018 Там как раз технические доклады, читайте!

Содержание

Доклады об устройстве цифрового мира

Джедайские техники в управлении командой, или Счастье бородатых айтишников. Victoria Yurkevich, Лаборатория Качества

Пост на FB

Крутой рассказ про преодоление проблем роста. До 60 человек была теплая ламповая обстановка, хотя компания - распределенная, из разных городов на удаленке. Потом стало не так, сотрудники стали замыкаться в проектах, появились обманутые ожидания - на собеседованиях-то компания презентовалась как теплая ламповая. Провели опрос, вскрыли проблемы, превратили их в задачи, начали решать, а руководителям дали обязанность работать с мотивацией сотрудников. Дальше выяснилось, что не все руководители с мотивацией умеют работать, хотя они хорошо руководят проектами. Проведи диагностику - чем руководители, у которых получается работать с сотрудниками отличаются от остальных. Проявились понятные софт-скилл компетенции: задавать вопросы, слушать, слышать, аргументированно высказывать мнение. И тут был первый не тривиальный ход - не насиловать руководителей, требуя от них этому научиться, тем более что такие скилы сложно приобретаются. Очевидное решение - нанять HR, по экономике они были готовы, но задумались - а как этих HR научить понимать IT-шников, особенно с учетом особенностей ситуаций на проектах - успешные руководители в своей работе с мотивацией сотрудников это учитывали.

И здесь они приняли второе нетривиальное решение - ввели в компании менеджеров счастья, отобрав их среди своих же сотрудников, обладающих необходимыми софт-скиллами. Менеджером счастья может стать любой, если прошел тест на нужные софт-скилы, и поговорит с ресурс-менеджером о своих целях. Сотрудник выбирает своего менеджера счастья, это не закреплено. Менеджер счастья - дополнительная роль, а не основная. У каждого из них 2-5 подопечных сотрудников, если больше 5 эффективность снижается, при этом у менеджера счастья есть свой менеджер счастья, который работает с его удовлетворенностью как сотрудника. В обязанности - раз в неделю беседовать с каждым из подопечных не менее получаса, опрос удовлетворенности, формирование и работа со списком проблем (решают не только они). Проблемы - не только профессиональные, но и личные, они помогают послать лекарство в регион, решить другие форс-мажоры, потому что когда у сотрудника снесло крышу в доме, то ему точно не до работы. Список проблем - публичный (но совсем личные можно не показывать), можно посмотреть, у кого были аналогичные и как их решали. А еще сотрудник, фиксируя время, одновременно фиксирует смайликами свое настроение и это - хороший маркер. Раз в месяц идет общее ревью счастья сотрудников.

Результат - текучка снизилась с 20 до 8%. 65% сотрудников заняты во внепроектной деятельности (online-мафия и прочее), для распределенной компании это важно. Руководители делегировали до 35% текущих задач. Удовлетворенность сотрудников компанией выросла с 3.5 до 4.5, а количество проблем, решенных в месяц - с 10% до 56%. И при этом уровень качества работы по оценке клиентов вырос с 3.67 до 4.91. Круто!

P.S. Доклад на странице конференции есть презентация и видео.

Обсуждение

Филипп Дельгядо Красиво, да. Добавлю в копилку орг. решений. Кстати, а как распределялся бюджет на "счастье"? Там же часть задач явно решалась финансами?
Yulia Mironova Бюджет на мотивацию был и так, и так. Проблема была в том, как вовремя понимать, куда важнее всего его направить прямо сейчас. Не общие банальные решения: "всем по сертификату в спа салон!", а знать, кто чем дышит.
Филипп Дельгядо Ещё раз спасибо за идею. А вы это решение в опенсорс будете выкладывать? Т.е. публиковать тесты, правила распределения бюджета по 'менеджерам счастья' и прочую машинерию?
Роман Юферев Шикарная и смелая идея. Спасибо, Максим!
Maksim Zaitsev Думал о такой системе обучения. Некий краудсорс внутренних знаний компании, где каждый может друг друга обучать.

Управление людьми как инженерная задача: экосистема краудсорсинга в Яндексе. Ольга Мегорская, Яндекс

Пост на FB
Слайды и видео

Это доклад о том, как реально будет устроено производство будущего - в тех областях, которые не покрыты автоматизацией. В краудсорсинг Яндекса вовлечено в этом году 800 тысяч человек, работает до 20 тысяч человек в день, при том, что платформа Толока, на котором это сделано появилась в 2014 году, а первые асессоры для поиска - в 2008. Эта система массовой обработки задач переменной мощности, которая первоначально использовалась для машинного обучения алгоритмов поиска и компьютерного зрения, разметки объектов на изображениях для автопилотов, автоматической и полуавтоматической модерации разговоров на яндекс-картах, актуализации информации об организациях, и многих других задачах. А еще для работы call-центра и реакции на упоминание Яндекса в соцсетях.

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

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

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

В общем, это был рассказ про кусочек того будущего, которое не просто придет, а уже наступило и стало настоящим для 800 тысяч людей.

Обсуждение.

Александр Турханов Станет, несмотря на взгляды классических HR, которые считают, что теплый ламповый менеджмент и лидерство останется навсегда. Все изменится и изменится быстро.
Максим Цепков Останутся, но изменятся. Мы об этом говорили. Потому что интересно научиться аналогичным методом решать задачи, для которых компетенций одного человека не хватает и которые требуют совместно работающей группы или команды. Группы точно можно формировать под задачу, при этом учитывая опыт прошлых взаимодействий и личностные характеристики и помогая организоваться включением отдельной роли. Наверное, и команды тоже. И там и лидерство и менеджмент в разных вариантах будет.
Плюс у них эта система управляется а не существует сама, и те, кто организуют решение задач классические менеджеры-технологи, организующие производство. Просто менеджеры-технологи новой эпохи.
Александр Турханов Максим Цепков очень напоминает Домодедово: https://hbr-russia.ru/liderstvo/lidery/a18741 Система Каменщика.
Александр Турханов Максим Цепков в армии США есть практика и софт для формирования task force под задачу как раз по таким принципам. Много критики я в ее адрес слышал, но она реально работает.
Александр Турханов Еще стоит учитывать, что есть 4 архитектуры команд. 2 типа делают работу, а два типа распространяют и поддерживают практики. И строить и управлять ими надо с помощью разных практик.
Архитектуры команд: команды-спагетти; группы с командиром; сообщества практик; целеориентированные социальные системы
Александр Турханов И еще - там не только взаимодействие надо учитывать, но и владение плюс совместимость технологий. Команда же всегда включает в себя инструменты.
Дмитрий Безуглый Александр Турханов А первоисточник Есть?
Александр Турханов Дмитрий Безуглый первоисточник по тому, как организовано управление человеческим капиталом в армии США и Евроконтроле?
Максим Цепков Александр Турханов Про Домодедово - нет, там другая конструкция, там симулятор для обкатки действий, такой цифровой двойник аэропорта. А у Яндекса - система решения реальных задач через краудсорсинг
Максим Цепков Александр Турханов Первоисточники интересны по всем трем коментам - про практику и софт для формирования task force под задачу армии США; про 4 архитектуры команд. 2 типа делают работу, а два типа распространяют и поддерживают практики. И строить и управлять ими надо с помощью разных практик; про владение и стоимость технологий. Первоисточник не в том смысле, что пруф, который подтвердит, что ты прав, а ссылку на книгу/статью/что-то еще, где соответствующие вещи разобраны достаточно детально и на хорошем, а не попсовом уровне. Практика показывает, что простым поиском это найти непросто - топ забивает поверхностные изложения.
Александр Турханов Максим Цепков там не симулятор, там цифровой двойник аэропорта, динамическая орг.структура, управление проф.траекториями. Полноценная архитектура предприятия.
Александр Турханов Максим Цепков ок, сделаю подборку. dau.acc.mil, к сожалению, прикрыли, но я поищу, наверняка где-то выложено.

Александр Зиза

Пост на FB

Проблематизирующий доклад с несколькими сообщениями. Основной тезис - про разделение нового цифрового мира, который Александр называет Big Data World, и старого Enterprise-мира. Цифровой мир - глобален и не ограничен организациями, он делает платформы, которые потенциально соединят потребителя и поставщика, подобно uber, airbnb или даже поиску google, при этом каждый, кто обращается может выступать в обоих ролях, и потому они реально глобальны, они весь мир видят как своих потребителей и сотрудников. А Enterprise-мир мыслит по-старому, даже в той части, которая говорит об инновациях, о создании новых предприятий - через инновационную идею, которую реализует создаваемая организация/стартап, и получит за это деньги.

И эти два мира друг друга не видят, не знают, и ЗНАТЬ НЕ ХОТЯТ. Цифровой мир уверен, что эти, из корпораций сами придут или вымрут, или, как жестче сказали в вопросах - уже умерли, только еще об этом не знают. А Корпорации не слишком понимают, чем эти IT-шники занимаются и почему так о себе воображают, но они когда потребуется - они их точно купят. Взгляд со стороны показывает, что стороны нуждаются друг, но навстречу друг другу они не двигаются. И, что интересно, это противоречие не получается снять даже внутри одной корпорации: SAP сделала SAP HANA как платформу цифрового мира, при том у них остался старый Enterprise SAP - и последние конференции SAP показывают, что у них внутри тоже образовалось два мира.

При этом корпоративный мир тоже развивается. Осваивает платформы коллективной деятельности: google docs, trello, realtime board. Я бы к этому добавил еще феномен телеграм-проектов, которые люди из корпоративного мира успешно делали посредством координации в телеграм, при том, что традиционными способами их бы просто не сделали.

Дальше было сообщение, что делать в такой паре миров. Полезно найти "об кого думать" - оппонента из другой тусовки. Да, вы будете с ними не соглашаться, но вы же будете и дополнять друг друга, и в обсуждении может получится неожиданный результат. Как иллюстрация тут была отсылка к Адизесу, продуктивные команды - из противоположных позиций: A+I - новая бизнес-модель, E+P - технологические инновации, и т.п. И в большинстве стартапов и крупных проектов тоже дополняющая руководящая пара, и дальше научиться в паре делать MVP. А еще полезна прокачка конструктивного мышления, которая дает способ конструировать бизнес-модели.

Следующее сообщение доклада было явно обращено к цифровому миру, представленному на конференции: пойдите навстречу корпоративному миру. Научитесь его понимать и отвечать на его языке. Купить костюм, чтобы одежда не служила препятствием для коммуникации. Он - нуждается в вас, хотя и не умеет коммуницировать. И он - достаточно открыт, ищет инновации, проводится много инициатив по поискам будущего и инновациям, таких как Остров 10-21 или конкурс лидеры России. Более того, на таких мероприятиях как Гайдаровский форум участие бесплатно, а там выступают и присутствуют люди, принимающие решения на уровне государства - и с ними можно поговорить, во всяком случае один раз - но им надо сказать оригинальное, все, что уже где-то было сделано они, скорее всего, не только знают, но и пробовали повторить, и что-то не сработало. А еще - там есть много денег, которые выделяет государство (вроде 1 трлн), а еще деньги есть у самих корпораций.

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

Возвращаюсь к содержанию доклада. Структура enterprise-мира была иллюстрирована многоуровневой пирамидой развертывания деятельности: миссия - идея - стратегия - цели+планирование - управление - технологии+производство - продукция+сбыт - деньги. У меня она вызывала возражение, и где-то в середине я понял, в чем именно. Это вытягивание в линейную структуру уровней детализации, которые происходят для разных сущностей - тех, которые OMG Essence называет альфами. Интересно представить пирамиду в этих терминах, и посмотреть на движение по детализации. Потому что параллельное продвижение по нескольким альфам вместо последовательного движения всего проекта по фазам - принципиальное открытие OMG Essence. А еще тут в одну пирамиду сведена структура функционирования, включая управления изменениями и развертывания, а это разные структуры. Но я над пирамидой еще подумаю содержательно - как оно раскладывается, все ли аспекты учтены.

Интересен список источников, которые были в докладе: Уилбер "Краткая история всего", Щедровицкие Георгий Петрович и Петр, Павел Мрдуляш, Воловик, Боровков, Остров 10-21, Программы МШУ Сколково. Пожалуй, на этом я закончу свой рассказ.

Инструменты управления большой командой. Дмитрий Безуглый

Пост на FB

Это - единственный доклад, о котором я не успел написать в ходе конференции. Потому что в нем - очень много содержания, которое правильно включить в отчет. Зато ретроспективно можно еще и правильно его позиционировать. Александр Зиза в своем докладе говорил о сформировавшемся четком разделении мира на цифровой мир будущего и корпоративный мир прошлого. Ольга Мегорская (Olga Megorskaya) рассказывала, как цифровой мир совершенно иначе решает задачи организации того производства, которые может решить регулярный менеджмент, задачи обычного разделения труда, и это обеспечивает новый уровень решений. А Дима ставил вопросы и показывал пути решения в цифровом мире тех задач, которые пока не решены, а находятся в процессе становления - задач организации совместного мышления для большого количества людей, необходимые для выполнения сложных проектов, таких как атомный или космический. Потому что для этих задач нужно не разделение труда, а разделение мышления, описываемое по-английски совсем другим словом - sharing, а не division. А теперь - про сам доклад.

Все знают про групповую динамику. Forming - Storming - Norming - Performing. Присматриваемся, потом боремся за распределение территорий, потом нормируемся и делаем дело. В синергии команда выдает двухкратную производительность, а еще - делает те задачи, которые не-команда не делает. А потом, о чем рассказывают реже, идет период бронзовения - они друг друга любят и знают, какие замечательны. И надо что-то засунуть, чтобы убрать бронзовение. Или просто понимать, что у команды ограниченный срок жизни.

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

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

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

Ключевое различия команды

  • вместе круче, чем сумма составляющих - неординарные цели
  • самоорганизована, автономны по управлению - достижение неординарных целей не организуется снаружи
  • 7 +-2 человека
  • устойчивы, но ограничены по времени 2-3 года. Дальше либо новый challenge и новый виток, либо такая бронзовеющая группа

Компетенции, необходимые команде для того, чтобы отвечать на принципиально новые вызовы

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

Ограничение на размер команды - принципиально, в сочетании с требованием решать неординарные и непредсказуемые задачи. Что делать, если надо больше 10 человек? Для масштабных проектов. Как запустить все вместе? Известны два варианта компаний: (а) стадо команд, (б) треугольник иерархии над командами, оба не дают синергии для решения реально сложных задач, хотя для части задач это вполне подходит.

Казалось бы, можно попробовать тщательно подбирая команду, выйти из этого ограничения. Но получается очень медленно. Ядро Facebook 60 человек, и нового члена команды подбирают 3 года. Есть Холакратия с ее кругами. Но там Дима видит свои сложности коммуникации, и тоже ограничения по скорости роста. Цифровые компании для ядра принципиально больше не становятся 20-60-200 максимум.

Но что четко видно, так это ограничения старой структуры и ее разрушение. Раньше IT было отдельно как поддерживающая структура и CIO в совете директоров были на не-ведущих позициях. И при этом на масштабе корпорации time to market принципиально не получается быстрее 6 месяцев даже при идеальной структуре. Когда стало нужно быстрее - внутри надо заводить agile продуктовых самоорганизующихся команда, которая сама делает все до конца, цифровую ценность. Тут же в сад идут описанные пирамиды. Вся структура разрушается, потому что все должно быть в тех структурах, которые делают цифровой актив, не согласуя ни с кем, не делая онтологии и прочее.

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

Что тут есть? Есть опыт NASA - как они строят команду? Если мы не можем мерить результаты, они меряют состояние внутри

  • Сегмент развития
    • выражение признательности -- взаимное уважение и удовольствие от работы
    • внимание к общим интересам -- сотрудничество и мотивация
  • Сегмент целеполагания
    • сногсшибательные решения (магия создаваемых решений) -- 100% вовлеченность
    • выражение обоснованного оптимизма -- устойчивая находчивость

и так далее, 8 пар по 4 сегментам, слайд надо будет внимательно посмотреть.

Какие следствия для компании?

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

Возвращаясь к холакратии. Дима видит проблему с числом связей. Оператор на экране видит максимум 14 точек, известно из тренировок авиадиспетчеров. Если самолетов больше - они выпадают из внимания, при чем этот процесс рационально не контролируется. А в примерах схем холакратии есть больше связей, при этом схемы отражают ролевую коммуникацию, человек может совмещать роли. С моей точки зрения, в этом есть правда, но, с другой стороны, предположенная холакратией конструкция основна на том, что при коммуникации в определенном круге ты можешь свернуть представления об остальных до коллективных субъектов, не раскрывая внутренних связей, так что, может тут нет столь жесткого ограничения.

Еще в принципе есть вариант, когда назначают супергероя, который в силу личных способностей потянет сильно больше. Дима сам таким супергероем был на команду 40 человек и его хватило на 8 месяцев, но потом смог восстановиться. И он встречал тех, кто тянули больше, год-два и выгорали безвозвратно. И, что наиболее обидно, очень сомнительно, что достигнутые результаты конкретного проекта стоили такой затраты заложенного в человеке потенциала.

Шаблон способа организации у Димы - штаб. Команда из 3-4 человек. Руководитель + Главный инженер, Product + Тех.дир. Если есть команды, надо еще 1 человека. Бывает 4-5, но там не независимые люди, а дубли-ученики. Иначе у управленческой команды не остается ресурсов на взаимодействие.

Но если штаб состоит из лидеров, то требуются дополнительные компетенции

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

Дальше идет ссылка на Peter Hawkins и его подход Systematic team leadership для развития большой команды. Там есть важные выводы:

  • команды нужно растить, а не строить по проектам
  • команды нельзя скопировать

И надо различать 4 вида компетенций

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

Способы развития членов команды - soft и premium skill

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

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

Разные доклады об организации разработки

Что такое DevOps. Иван Евтухович

Пост на FB

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

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

Право на эксперименты. Если проверить новую идею на проде - пара часов - это интересно. А если неделю - никто и заморачиваться не будет.

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

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

Обсуждение.

Иван Евтухович Максим Цепков State of DevOps report гугли, а в книге accelerate описано, как они это делают
Филипп Дельгядо Да, по моему опыту, доставка малыми квантами быстрее и надежнее
Иван Евтухович Филипп Дельгядо есть классная серия постов у Александр Турханов про это, прямо с формулами и цифрами, я прямо зачитываюсь

Заметки по мастер-классам Александра Зизы

Помимо большого доклада Александра Зизы, он весь первый день конференции проводил мастер-классы совместно с Вирной Штерн. И здесь пара интересных заметок, сделанных пробегая мимо.

Пост на FB
Александр Зиза. Интересное замечание про OKR. В современных условиях руководитель может сформулировать цель, но не может ее декомпозировать и передать вниз. И вот часть Key results - способ как раз запросить у сотрудников те результаты, которые они полагают разумными для достижения к этой цели, эти результаты напрямую из цели не требуют. Это - конечно, не весь подход, но вот такого взгляда я не слышал. А это интересно, и объясняет актуальность именно сейчас.
Пост на FB

К вопросу о широте кругозора современных IT-шников. Пробегаю мимо мастер-класса Александр Зиза, он рассказывает про холоны. И говорит: кто хочет прочитать подробнее - Кен Уилбер "Краткая история всего", там первые 100 страниц про холоны, потмоу интегральный подход, тоже очень полезно. То есть книга рекомендуется не как какая-то философия, а как часть профессионального образования.

Фабрика по выпеканию кода или как мы оптимизируем процессы в заказной разработке. Kirill Vetchinkin

Пост на FB

У них был Scrum для разработки-тестирования, а аналитика и поставка до прода были за рамками и не видны. И они сделали общую Kanban-доску на весь процесс, начали по принципам Lean искать точки потерь и работать с ними. Очень много проблем оказалось в аналитике: аналитики не понимали сложной архитектуры, делали аналитику впрок и она сгнивала, или наоборот, делали недостаточно к спринту, выдавали неподготовленную задачу на груминг, что теряло время всех участников собрания... На общей доске это стало проявлено и можно было работать с ними. Например, обязательный review аналитики при чем не по маленьким задачам, а по фиче целиком, чтобы оценить архитектуру, уход от простых текстов на описание с диаграммами через confluence + draw.io. Еще прием - стендапы у доски по задачам. а не людям, с вопросами "а почему задача так долго висит - привлекали внимание аналитиков к тем задачам, где на поздних стадиях разработки потребовалось взаимодействие с заказчиком, это часто провисало.

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

Presale. Приходит заказчик, говорит: вот требования, 70 страниц текста, сколько будет стоить и когда сделаете? Скоуп довольно размытый обычно. Подходы: по аналогам или экспертная оценка. Аналоги - могут оказаться ложными, а экспертная оценка завязана на оптимист/пессимист. У них сейчас база разработанных блоков, и база типовых работ, которые достаточно точные оценки. И оценка идет по относительно малой части работы. Впрочем, думаю, если таких задач много, то проблемы будут именно с ними: они не являются типовыми и с ними - максимальная неизвестность.

В обсуждении. Yuri Veretelnikov Так а итог какой? Какие показатели сдвинулись в правильном направлении и насколько? Как это в p&l сконвертировалось?

Максим Цепков Показатели в конце были, но не супер-большие, процентов 15 целиком по трудоемкости - потому что основная трудоемкость у них именно в разработке, а там и так хорошо было. По идее, должен был улучшится ttm, потому что простои на аналитике и из-за аналитиков сократились, но цифр не было, или я их прослушал.
Yuri Veretelnikov Ну т.е. они сделали робкий шаг от функциональной структуры в сторону виртуальных продуктовых команд, но пока не протащили это в оргструктуре компании, похоже. Интересно будет, во что трансформируется это на горизонте нескольких лет, перерастет качество в структуру или нет
Максим Цепков Нет, не сделали, как я понимаю. Аналитики и разработка по-прежнему отдельно. Они запустили канбан поверх этого - канбан нормально относится к тому, что на разных фазах у задачи разные исполнители. В целом это нормально.
Yuri Veretelnikov Ну доска-то у них общая, плюс стендапы общие по всем задачам, потому и написал "виртуальные". Лан, ждем новостей

Сам себе HR: что и как развивать. Тахир Базаров

Пост на FB

Рассказ-размышление из очень широкой культурной рамки. Чем и интересен, несмотря на то, что часть рассказываемого ты вполне себе представлял. А еще - большим количеством историй и любопытных фактов.

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

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

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

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

Целеполагание, 4Ц - из интересной книги Юрьева и группы соавторов "Стратегическая психология глобализации".

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

Можно ли из ситуации видеть ее последствия? Тут важно различать два варианта.

  • Самореализующиеся пророчества: когда мы сами конструируют ситуации, и она меняется.
  • Некоторые люди, находясь внутри ситуации способны видеть последствия - ответственность

Событие: готовишь совещание для перелома, совещание произошло, а последствий - нет. Случилось или нет?

Воля. Стремление, преодолевающее препятствия. А еще - препятствие внутри, преодолевающее его стремления. Самомотивация, самонастройка и принятие ответственности.

Были интересные слайды о том, что важно для руководителей и сотрудников на уровне знаний, установок и действий. Интересно, что руководителям необходимы знания, что люди-разные, человек ленив, стремимся к комфорту, человек эгоистичен, а установки о том, что человек талантлив, диалогичен, развивающийся; доверяй но проверяй. А для сотрудников кластерный анализ выявил две категории А и Б, в которых лично я опознал два давно известных типа мотивации МакГрегора: X-исполнители и Y-предприниматели (не путать с поколениями X и Y, это совсем другая теория).

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

Круглый стол по роли HR в IT

В продолжение доклада Тахира Базарова был круглый стол с обсуждением роли HR в IT и связанных с этим проблемах. Это получилось неожиданно, вместо ответов на вопросы участников возникло острое обсуждение о принципиальной ограничениях HR даже с хорошим психологическим и другим soft-скилл образованием в профессиональной работе в IT в силу их непонимания специфики диджитал-мышления, в котором люди и технологии очень сильно переплетены, и к организации социальных систем подходят с инженерной точки зрения, при этом, однако, хорошо понимая особенности человека. Например, книга Канемана "Думай медленно, решай быстро" о ловушках мышления практически входит в состав профессиональной литературы продвинутых IT-специалистов, и не только она. Круглый стол очень хорошо показал тот самый разрыв между цифровым и корпоративным миром, о котором говорил Александо Зиза в своем докладе. К сожалению, содержательно конспектировать у меня не получилось.

Доклады о технологиях

Что мы знаем о микросервисах? Vadim Madison, Avito

Пост на FB

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

О том, как это устроено у них - был рассказ. Детали реализации тут не столь важны, презентация интересна как чеклист важных аспектов, о которых стоит подумать и решить системно для всех сервисов, а не делать каждый раз индивидуально. Включая такие вещи, как нагрузочное тестирование и тестирование на первых пользователях. Они не могут запустить сервис на 0.1% пользователей, не взирая на то, что отвалится, они запускают на 10 пользователях и тщательно смотрят, что происходит, а потом - медленно увеличивают. И с нагрузкой - выясняют реальную, а не тестовую нагрузку, тоже аккуратно в продакшн доводя ее до предельной и оценивая метрики.

Обсуждение

Филипп Дельгядо Слушая доклады Авито возникает ощущение, что в какой-то момент в компании потеряли управление архитектурой и разработкой. А DevOps стали крайними и пытаются как-то скомпенсировать управляемость своими инструментами. Решения интересные, но лучше бы порядок навести на более низком уровне.
Филипп Дельгядо Но идея использовать neo4j вместо какого-нибудь EA Sparx - на грани гениальности
Александр Турханов Чем оно на грани гениальности？
Филипп Дельгядо Удобно, технологично и позволяет делать сложные задачи.
Максим Цепков Филипп Дельгядо В одном из докладов (не на highload) я слышал кайфное объяснение, чем микросервис отличается от сервиса: когда у тебя микросервис, и его надо доработать или поправить, а знания об устройстве утеряны, или ты не понимаешь. как это доработать в том, что сделано, или просто лень разбираться в коде - тебе не жалко этот микросервис выкинуть и написать новый, тесты заработали - меняем. А вот сервис выкинуть жалко, ну или он не настолько покрыт тестами для безопасного применения такого метода :) Так что, может, с архитектурой это просто фича, а не баг?
Филипп Дельгядо У них не микросервисы, у них обычные сервисы. Это в Авито их называют "микро".
Максим Цепков А почему? В смысле - как ты проводишь границу сервис - микросервис?
Филипп Дельгядо Вот как ты выше указал ) когда переписать можно быстро и легко. Типа до 5 человекомесяцев трудозатрат (а реально - не больше одного).
Виталий Юшкевич Слышал как-то давно определение в виде игры цифр. Микросервис - это когда:
  • команда из 7 человек может написать сервис не больше чем за неделю
  • один человек может поддерживать не менее 7 сервисов и помещать каждый у себя в голове
Филипп Дельгядо Хм, то, что команда из семи человек пишет неделю, один пишет три дня :) Так что странное определение.
Максим Цепков Филипп Дельгядо У одного из наших заказчиков есть интересный опты по переписыванию с нуля своих собственных больших приложений (не супер-больших, 1 команда, 10+ лет развития) с полной сменой архитектуры и технологии (потому что 10 лет назад технологии были сильно другими), но с преемственностью функционала, миграцией и мягкой заменой. Утверждается, что переписать - 1/10 от полной трудоемкости разработки. Интересно, для (микро)сервисов этот коэффициент сохраняется?
Филипп Дельгядо А вот это хороший заход. В 1/10 не всегда верится (хотя если есть уже фиксированная постановка, то уже 1/3, если есть тесты, то ещё в два раза меньше, так 1/6 и выходит).
Геннадий Круглов Чтобы не нужно было переписывать нужно просто писать нормально. Делать трассировку требований, тестами покрывать. Поддерживать качество кода. Иначе звучит примерно так - мы написали большой кусок непознаваемого нечто, его уже не переписать, он слишком большой. И это не микросервис. А если маленький кусочек непознаваемого нечто, то лучше переписать и не мучаться с ним. Это микросервис.
Максим Цепков Практика отрасли состоит в том, что на взирая на этот общеизвестный тезис, проекты пишут очень по-разному, разработчики уходят, коды - теряются, и со всем этим надо жить. Так происходит уже 60 лет, и все это время раздаются призывы "писать нормально" и появляются теории, как именно это делать. И одна из идей, которые некоторые вкладывают в микросервисы - признать именно практику отрасли нормальной, позволяющей писать быстрее, и столь же быстро переписывать по необходимости.
Геннадий Круглов Я другой смысл вкладывал в свои слова. Понятно, что энтропия нарастает. Но если заботиться о качестве, то момент когда нужно будет переписывать можно отсрочить. А может быть этот момент никогда не настанет. И таких примеров масса. А если сразу писать как попало, то переписывать придётся однозначно и в ближайшей перспективе. Многие сейчас такой подход воспринимают как индульгенцию от плохого кода.
Vlad Tsypin Кто должен (или в идеале) писать подобные тесты и в какой момент времени? Плюс это зависит от того, для какой цели писался код - если это бизнес-логика или платформа, то да, а если какой-то лендинг или заплатка - то ИМХО незачем
Геннадий Круглов Это зависит. В текущем проекте мы пишем не только модульные тесты но и Behavior. При этом на демо показываем бизнесу Behavior тесты. Это заходит. Аналитики от бизнеса (бизнес-аналитики) а иногда и сами заказчики видят, как отрабатывают процессы. Да, модульные и Behavior тесты пишут разработчики, а нагрузочные и функциональные пишут тестировщики.
Геннадий Круглов Что касается момента времени. Сразу. Модульные тесты - это часть разработки. Их нужно сразу закладывать в косты. Нет тестов, нет кода. Зрелый бизнес это понимает.
Vlad Tsypin Геннадий Круглов вот я с позиции бизнес-аналитика и продакта одновременно смотрю

Геннадий Круглов Vlad Tsypin У нас устроено так. Бизнес-аналитики, разумеется, пишут бизнес-требования. На их основе разрабатываются ФТ и НФТ. На основе ФТ разрабатываются Behavior тесты, в том числе. Требования трассируются. Бизнес-аналитики работают в тесном взаимодействии с аналитиками от разработки. Поэтому на демо всегда можно увидеть как реализованы БТ, Behavior тесты - очень хороший способ продемонстрировать работу бэк-энда, сервисов, микросервисов, процессов. Мы так стартуем проекты и пишем тесты сразу, со старта.

Vlad Tsypin Геннадий Круглов это прекрасно, когда есть ресурсы на это:) и видимо масштабы проекта. Спасибо за пояснения, осмыслю и попробую по возможности
Геннадий Круглов Vlad Tsypin Ресурсы есть, проект большой. И мы работаем с деньгами. Но на самом деле, ресурсы есть почти всегда. Бизнес должен понимать цену регресса. Весёлая agile разработка приводит к регрессу и бардаку. Мы это видим по докладам. В общем, у регресса и хаоса всегда есть цена.
Vlad Tsypin Геннадий Круглов вот тут согласен. Я не против эджайл, а против хипсторства:)) и фигак-фигак-продакшн
Геннадий Круглов Vlad Tsypin Однозначно. На своём примере могу сказать. Мы делали решение в одном крупном банке. Моя команда писала тесты, а соседние - нет. Мне за это прилетало постоянно. Начальству это не нравилось. Но в итоге мой функционал выжил и получил развитие, и это было ядро решения. А ребята из соседних команды в какой-то момент начали срывать сроки, потому что всё стало отъезжать.
Геннадий Круглов Vlad Tsypin Золотые слова. Я тоже не против эджайл. Мы и работаем по эджайл. Но работаем профессионально.

Разгоняем обработку событий до 1.6М/сек. Опыт Badoo. Александр Крашенинников

Пост на FB

Были на Hadoop, перешли на ClickHouse. Общая таблица событий, разнородность атрибутов - за счет полей массив ключей и массив значений. Для расчета метрик - специальный механизм ClickHouse, который считает овеществленные агрегаты. Их тоже хранят в обобщенных таблицах - для пары (event+timestamp) массив метрик и их значений. А триггер на эту таблицу еще делает поток изменений метрик, 500k точек метрик на 1.6М событий в секунду. В Hadoop примерно это делали вручную. По таблице метрик - аналитические запросы и ловля аномальных изменений метрик. Переход на ClickHouse Ускорение в несколько раз по памяти и CPU.

Эволюция архитектуры торгово-клиринговой системы Московской биржи. Сергей Костанбаев

Пост на FB

Ядро торговой системы - на центральном сервере, на голом C, статические массивы, никакой динамической памяти, загрузка из базы данных только на этапе инициализации, в один поток. Сам сервер - HP с аппаратным дублированием, потому считалось, что не убиваемо. Потом выделили отдельно информационный поток, для этого сделали slave-обработку транзакций? что позволило уйти от эксклюзивного железа. Нагрузка росла экспотенциально, а в 2010 пришли торговые роботы, в результате чего после больших транзакций, существенно влияющих на цену, в течении 50мс сваливается поток корректирующих транзакций, вплоть до 200к в пике. Ускоряться по железу уже было невозможно, а просто поделить на узлы тоже не получалось, потому что в одном потоке была работа с кошельками и с сделок с фин.инструментами, их надо делить по-разному. И он рассказывал архитектуру, в которой получилось это сделать без существенного изменения кода. Прием - разделение обработки на фазы, за каждую фазу - свой кусочек кода, транзакции лежат в кольцевом буфере и зафиксирован текущий статус. При этом сами кусочки код обработки - остались. Это в несколько раз ускорило обработку, во-первых, а, во-вторых, следующим тактом позволило отсадить работу с кошельками на отдельные сервера. В целом получилась достаточно сложная конфигурация, но проблему увеличения очередей - решили, и с ростом нагрузки справляются. В докладе были конкретные цифры, кому интересно - надо будет дождаться презентации.

Система управления современной АЭС. Вадим Подольный

Пост на FB
Доклад на сайте

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

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

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

И прикольное название. Ядро системы - CoreShock, а внешняя часть - WhereShock от русского вершки и корешки :)

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

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

Дополнение от Андрей Евсюков. Ещё очень интересно применили технологию VR! Есть физическая панель, где сидит оператор, с мониторами и пультом управления, но это дорогая штука. Они сделали шлем, где показывается точно такая же панель и виртуальный пульт управления)

[ Хронологический вид ]Комментарии

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

— GreenEkatherine • 21 ноября 2018 в 18:06

Даниэль Канеман "Думай медленно, решай быстро" (он с одной "н"). Там многое про то, что человек принимает решения вовсе не из рациональных соображений, и так же о том, что интуиция неверно работает со статистикой и других когнитивных искажениях. Еще можно просто смотреть и читать про когнитивные искажения https://ru.wikipedia.org/wiki/Список_когнитивных_искажений

— Максим Цепков • 21 ноября 2018 в 18:21

Спасибо, в таком случае в статье фамилию автора и название книги тоже нужно исправить.

— GreenEkatherine • 21 ноября 2018 в 21:32

Войдите, чтобы комментировать.

— Максим Цепков • 12:03, 17 ноября 2018 • 3 комментария
Источник — «https://mtsepkov.org/index.php?title=Блог:Максима_Цепкова/2018-11-17:_Highload_-_цифровой_мир_в_настоящем,_а_не_будущем&oldid=8164»