2020-03-10: TeamLeadConf - модели softskill и современное управление

Короткая ссылка: TeamLeadConf-2020

Ссылки сюда (3) →

О других конференциях

Прошедшая в феврале TeamLeadConf была для меня оказалась посвящена разнообразным soft skill моделям и современному менеджменту. Но это - для меня, потому что я именно так выбирал доклады, да еще был сильно занят на собственных докладах и воркшопов. В результате я был всего на шести докладах :(

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

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

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

Доклады в целом

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

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

С моделями софтскилл, которые я слышал на конференции, тоже все не просто. В целом о существовании софтскилл моделей и связанных с ними концептов люди осведомлены. Примерно так же, как о существовании паттернов программирования. Возьмем, например, тему общения с командой. Про 1:1 (one to one) и эмпатию люди знают. Но что им с этой осведомленности, если софтскилл профиль не позволяет. Грамотная штука - или брать в тимлиды с учетом этого профиля, или как Юркевич на highload рассказывала - сделали они отдельных менеджеров счастья помимо руководителей проектов именно поэтому (смотри доклад и мой конспект). Так что осведомленность далеко не всегда означает применение, часто встречается ситуация "пробовали, не получается" или "не пробовали, а зачем?"

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

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

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

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

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

Мои выступления

На этой конференции мой доклад Модель Белбина для IT: сила и слабость разных команд занял третье место, и это очень приятно. Идея рассказать возникла у меня на Питерской TeamLeadConf, когда при обсуждении в кулуарах конкретных кейсов модель Белбина позволила прояснить ситуацию сразу в нескольких. И кратко рассказав о ней, я получил вопрос "а почему об этом нет докладов?". Так что для конференции я пересобрал старый доклад, перестроив изложение от проблем конкретных команд вместо простого рассказа модели. И получилось удачно, после обсуждения в дискуссионной зоне было много вопросов. И довольно неожиданно для меня было узнать про конкретный опыт применения модели в компаниях. Слушатели рассказали, что эту модель применяют в Спортмастере уже полтора года и делились конкретным опытом. Основной профит - в том, что модель дает язык для разговора про компетенции разработчиков и про сильные и слабые стороны команды. Она не является волшебной таблеткой, и не изменяет ситуацию на рынке труда. Как было сказано в обсуждении: "Генераторов - очень мало, сильных - почти нет, это объективно. Но мы видим картину и можем ее обсуждать и с ней работать."

Кроме доклада у меня был воркшоп Работа с культурой компании - модель Спиральной динамики. Он тоже получил высокие отзывы тех немногих участников, что на него пришли. Наверное, если бы я сделал по этой теме доклад, людей было бы больше. С другой стороны, у меня уже есть несколько докладов по Спиральной динамике, в частности Спиральная динамика для аналитика - работа на стыке культур (AnalystDays-9 осень 2018) и Спиральная динамика: понимай ценности и действия людей и организаций (Лекторий тут рядом 2018-09), и мне хотелось сделать не только лекцию, но и обсуждение с практикой. Думаю, это получилось, особенно благодаря немногочисленности участников. А вообще по Спиральной динамике я сейчас публикую статьи в рамках серии «Менеджмент цифрового мира» с подробным раскрытием темы. Так что можно читать, погружаться и спрашивать.

Оригинал Анатолия Иванова

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

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

На этом я закончу рассказ о своих выступлениях. Я еще как эксперт участвовал в митапе "Доки против знаний", который мы проводим в рамках подготовки Knowledge Conf, но там готовится отдельный материал по результатам обсуждения.

Так что перехожу к обзору выступлений.

Анатолий Левенчук. Системное мышление для инженеров и менеджеров

Оригинал на FB

Пост на FB TeamLeadConf2020 сегодня открылся пленарным докладом Анатолий Левенчук (Anatoly Levenchuk). Пленарные доклады - новая практика конференции, по сути это жесткое побуждение участников придти на конкретный доклад для расширения кругозора. И я полагаю, это - полезная практика, потому что есть вещи, которые кажутся непрактичными и потому не слишком нужными, и благополучно игнорируются, а это побуждает все-таки послушать и отнестись к докладу. Впрочем, по избранной обратной связи мнения разделились, и наряду с теми, кто проникся расширением кругозора тимлида, которое давал доклад, были отзывы про странную непрактичную штуку. Но, я думаю, организаторы поступили правильно.

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

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

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

3. Кругозорные дисциплины: что вообще бывает. Командная работа, какие роли. Системная инженерия, менеджмент, педагогика, предпринимательство...

4. Фундаментальные трансдисциплины: системное мышление, научное мышление, онтологика, функциональная грамотность.

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

5. За основу взяли они Cистемную инженерию. Она развивается, 10к человек в мире. И это важно, многие из системных подходов остановились в развитии, а в нынешнем мире это недопустимо. Сейчас есть свежий учебник и только запущенный online-курс по нему, в котором учебник подкреплен практическими задачами.

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

Основная схема системного подхода - Целевая система, ее окружение и надсистемы. Needs - нужды надсистемы по отношению к системе, против них требования. С 1980х - включение людей, стейкхолдеры и обеспечение жизненного цикла.

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

Театральная метафора. Работать хорошо == хорошо исполнять роль. И надо понимать, какая роль требуется, и какую сотрудник сейчас играет.

Продавец и покупатель: интерес - цена, и предпочтения разные. Модель требования: разбираться с ролями, интересами, предпочтениями и ролями. Одному побыстрее, другому - помощнее, но это - и помедленнее.

Фокус на важное. Но! Важное слабо отличимо от неважного, оно не выделено в физическом мире.

Исходный ход - не целевая система. Целевая - это исполняемый на проде код в нужном окружении.

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

Часть-целое. Путается с специализацией, изготовлением, класс-экземпляр. У коровы Маргариты есть хвост, а корова - в стаде. Значит у стада есть хвост коровы Маргариты. Но они как-то слабо связаны...

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

Программисты редко делают принципиальные схемы - dataflow, не поддерживают разговор. Хорошо делают сборки (зависимости) и размещение на серверах.

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

Системы сами не растут и не породят следующих. В отличии от биологии. Об этом заботятся обеспечивающие системы.

Стейкхолдеры == внешние проектные роли. Три области Essence переведены как Предпринимательство - Инженерия - Менеджмент.

Минимальные роли:

• системный инженер (целевая)
• Предприниматель (надсистема)
• CTO/CIO (метод, системы в обеспечении)
• Project (команда, системы в обеспечении)

Комментарий от Анатолия. Тот самый онлайн-курс -- https://system-school.ru/sm2019. Чат поддержки курса (и там припинен пост со ссылкой на бесплатный учебник): https://t.me/systemsthinking_course

Валера Разгуляев. Автономия, обещания, доверие и другие принципы работы Вкусвилла

Пост на FB Второй пленарный доклад - Валера Разгуляев "Автономия, обещания, доверие и другие принципы работы Вкусвилла". Казалось бы, зачем доклад из ВкусВилл на IT-конференции, да еще и пленарный? Реально это был очень полезный доклад, потому что вопросы доверия, автономности исполнителей - очень актуальны для IT-компаний и опыт большой компании реального сектора - очень ценный. А в докладе было довольно много контринтуитивных решений. И Валеру после выступления часа четыре спрашивали про детали.

ВкусВилл быстро рос при этом отстраивал классическую управленческую пирамиду. И она вызывала сложности

• Увеличения в затраты зарплат руководителей. от 29% (2/7) до 78/203 - 38%. Там пирамида с удвоением оклада.
• Хотя система управления дорогая - она еще и теряет эффективность. Удлинение и искажение коммуникаций. Каждый уровень 30% потерь при хорошей системе.
• И дикий перегруз руководства. Вечно что-то не доработали.
• Потеря инициативы и мотивации снизу. Суперпрограммы повышения не работают.
• Войны между отделами. Конфликты там, где должно быть сотрудничество.

Много недоработок, в системе, по сути неуправляемая ситуация.

Вывод: ты можешь управлять только собой и своим вниманием на окружающих.

• А когда на это смотришь - ты еще и плохо управляешь. Кричишь "вперед", но держишь тормоз. Отпусти тормоз.

Войны между отделами. Уроки разборки.

• Начинается - с проблемы, случается всегда в момент взаимодействия двух людей/команд/подразделений. Не в собственной зоне.
  • Коллега, решает свои задачи, устраивает вам проблему. Пример. Маркетинг придумает - как увеличить продажи.
  • Классная акция, продажи в 3 раза, только товара нет. У логистика проблема.
  • В следующий раз - предупредил, то привез побольше но не того.
  • А потом совсем подробно предупредил - только логистик был в отпуске
• Проблемы - висят между, потому что "кто потрогал - тот и виноват". И они растут. До большого начальника сверху.
• Универсальное решение: если ответственных двое, то никто - надо кого-то назначить. Только кого бы он не назначил, этот будет считать, что его несправедливо наказали из-за другого. И потому винит коллегу, меньше общается, а проблемы - растут.
• Кумулятивный эффект. Крайняя ненависть: коллеги ходят на работу получать зарплату, чтобы нагадить им. Общение запрещено.
• А там еще штраф ответственному...

Замкнутый круг надо размыкать. Первое - вы идете и начинаете общаться. Если руководитель - запускает коммуникацию внизу. И коммуникация запускает круг в обратную сторону, размыкает проблемы. Системное решение "Обещание" Гэри Хэмел - "Сначала увольте начальников". Из Morning Star.

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

Обещание и поручение. "Быстренько пообещай три вещи" - не работает. Ты не отдаешь ответственность.

• Обещать готов только тогда, когда готов выполнить. И это - разница.
• Что тебе нужно, чтобы взять обещание? И именно тогда соединяется права и ответственность.
• Очень часто они разбежались: у кого права - не занимается, потому что более разные дела. А у кого ответственность - нет прав и ничего сделать не может. В иерархической структуре часто разорвано, ответственность делегируется вниз без прав.
• Лучшая оценка обещаний - субъективно заказчиком. Дикий субъективизм, а не объективные оценки. У объективности нет ответственности.

Оправдание "Я не виноват меня самого подвели" - убирается принципом "если исполнитель не выполняет свое обещание - виноват заказчик".

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

Иерархия обещаний - от покупателей.

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

Ответственности нужна свобода. Мы убиваем:

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

Как отдавать

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

Доверие - передача другому лицу права сделать тебе плохо. Именно это - настоящее доверие.

• Экономия 40% денег, 60% времени. По сравнению с проектами других компаний. По их опыту, и по американским источникам.
  • Громадные издержки на договоренность об ответственности исчезают
• приятное мотивирующее место работы
• знание проблем и их реальное решение
• готовность брать на себя ответственность

Доверие важнее денег.

• За все платит конечный клиент, потребитель.
• По цепочке идет ценность в обмен на деньги. Без доверия цепочка не пройдет.
• Салат Чука убрали красители, глютамат натрия, сорбат натрия, бензоат натрия - менее приятная, на 30% хуже продается.
  • Но они торгуют им.
• Бюрократические процедуры и обходные пути - которые на доверии.

Почему мы не доверяем

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

Парадоксальное решение - доверять всем по умолчанию.

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

Во ВкусВилле - везде камеры в магазинах, да еще ИИ с распознаванием.

• Доверие и Контроль НЕ антонимы. Доверяй но проверяй - нормально.
• Никого нельзя проверить, пока не доверимся.
• Зато если проверили - то начинаем больше доверять.
• Это называется прозрачность - все всё видят. Большинство фоток с камер идет прямо в магазин.

Убивают доверие

• Штрафы
• Закрытость информации - наверное, обманывают
• Обман и нечестность. Если тех обманываешь - значит и тех
• Статусность - различие правил
• гордыня - приписки успехов и передача другим неудач
• микроуправление
• слухи
• недоверие порождает недоверие

ВкусВилл: любой продукт надо вернуть без чека и паспорта, открытый и попробованный. Иногда можно не возвращать - послать фото. Зеленый арбуз. Микрик на полном доверии: холодильник, стеллаж и касса. В любой офис от 400 сотрудников. Цены и поставки каждый день, покупатели управляют ассортименту. Не воруют. Флуктуации на уровне ошибок учета, иногда в кассе больше денег. Наличные оставляют на стойке. Некоторые руководители компаний, где стоит, удивляются, что не воруют "оказывается, нашим можно доверять" Нет штрафов за недостачу, нет службы безопасности, нет приемо-передачи. сотрудники сами: ставят цену на товар, определяют выкладку магазина, могут продать по любой цене, сами отвечают на обращение. Вместо скриптов - результат, главное - быть довольны. Нет бюджета, свободный график работы людей - в рамках часов магазина. В офисе вообще проще. Можно закрыть магазин через неделю, если не пошло. Если открывающий магазины будет регулярно открывать неправильно - ему не дадут открывать. А если естественный брак - не вопрос.

Свободная явка на собрания: любой может придти и может не приходить.

• По статистике - половина собраний руководители делают для самооценки. У них - не катит.
• Даже на совет управляющих можно придти.
• Нет личных секретарей.
• Льгот мало, но они - у всех.
• humanchech.ru потмоу что много 45+
• 50% оплата любого спорта,
• полная оплата такси и сотового, без лимитов.
  • когда начали приносить счета, были большие - они просто начали всем рассылать сортировка по убыванию. Прозрачность лечит.

Недостачи 0.5% от выручки. Да, каждую неделю кого-то увольняют за воровство: знают, что кто-то может оказаться недостойным.

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

Зарплаты открыты просто потому, что каждый может зайти в 1С и все увидеть. Хотя на стенке не висит.

В кризис - они увеличили доверие. Там надо было резко срезать зарплаты на 30%. Он пришел к сотрудникам и честно об этом сказал: или уйдут или сократят. Себе он срезал вдвое. На следующий день все договорились: уменьшаем на 30%, кто-то уйдет - разделят его зарплату.

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

Что делать, если у людей есть полномочия и ответственность, но они не делают? Ответ: заказчик виноват, он НЕ спрашивает - значит его устраивает. Если ему не все равно - спрашивай, есть право спросить с пристрастием.

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

Иван Лукьянов из Авито. Настоящие задачи руководителя

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

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

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

Фреймворки ревью

• OKR review: раз в месяц прогресс по метрикам, планы на квартал, почему цели сильные
• Team helth review: раз в квартал/полгода анкета на 30 вопросов про продукт, бэклог, качество кода и т.п. И эксперты то же заполняют про команду. Результаты на ретро, соотнести внутреннее и внешнее восприятие.
• Operational review: операционное ревью, one2one с руководителем о том, как закрыли спринт, сколько бэклога сожгли, достигли ли цели

Все ревью не слишком работают в моменте, но 2-3 дают динамику

• Самое печальное: когда все немного фигово и ничего не меняется.
• Вижу проблему и нет ресурсов - нормально. А вот когда проблемы не видно - тяжело.

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

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

Вы и ваш вклад.

• Основная ценность - у руководителя есть собственный контекст и собственное видение.
  • Все решения - не просто исполнение. А принятие собственного решения.
  • Чем выше вы по иерархии, тем тупее объяснение фейла "я просто исполнял все что сказали"
• Постоянно общаться с другими подразделениями, чтобы расширить границы своего контекста
• расширять контекст других, донося им результаты

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

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

Антон Морев. Создание ценностей по стилям коммуникаций

Пост на FB Anton Morev. Создание ценностей по стилям коммуникаций.

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

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

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

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

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

Уже сейчас, при подготовке этого отчета, я еще раз посмотрел типологии. Disc в основных описаниях говорит о четырех типах и без всяких дихотомий. На конкретных сайтах дихотомии иногда рисуют, но их основания - сомнительны, иногда там еще склеивают несколько признаков в один. Что интересно, в истории DISC на профильном сайте есть ссылка на Interpersonal circumplex, которую как раз вводил Лири. И вот там изложения дихотомий довольно похожи на те, что были в докладе.

Дмитрий Смирягин. Почему часто хочется работать, а иногда нет

Пост на FB Дмитрий Смирягин. Почему часто хочется работать, а иногда нет. Доклад был из двух частей. В первой было четыре гормональных механизма мотивации: Дoфамин, Окситоцин, Эндорфин, Серотонин. Вырабатываются рептилоидным мозгом. Механизм выработан эволюцией, работает на бессознательном уровне, прямого доступа нет. Но есть косвенный, в ответ на определенные ситуации. Когда вырабатывается - стимулирует когнитивную деятельность. При этом есть последовательное влияние, например, при пробежке 42 км: Дофамин (предвкушение) - Эндорфин (бег) - Окситоцин (одобрение командой на финише) - Серотонин (одобрение коллег - ты молодец).

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

От себя добавлю, что эта модель близка к модели Хелен Фишер, у нее вместо Эндорфина - Тестостерон. По модели Хелен Фишер есть тест, связывающий гормоны с предпочтительными видами деятельности. Тест и описания типов на русском гуглятся, а сайте Хелен есть статьи с научными обоснованиями теста, правда косвенными http://helenfisher.com/articles.html смотреть надо статьи 2015 и 2013 года.

Вторая часть доклада рассказывала систему мотивации от анонимного бизнес-консультанта с 5 типами:

• Финансист. Заработать больше, мотиватор - деньги. Их мало, но с ними - просто. Вознаграждение, конкретное, четкое, более, чем справедливое
• Результатник. Человек, ориентированные на результат. Вся деятельность для результата, если есть проблема - я ее решу. Абстрактное мышление, модели. Люди - ресурсы для достижения цели. На собеседовании говорит что было сделано, как круто, какие сложности преодолены. Ему нужны амбициозные задачи.
• Звезда. Поощрение, похвала. Выделение над толпой, всегда надо быть идеальным, нести корону. Эгоцентричное мышление.
• Романтик: свобода, развитие, смысл, новизна, идея, миссия.
• Служащий. Балансирует работу и рабочее время. Низкая склонность к риску, стабильность. Уход от реорганизаций

Для тех, кто хочет подробностей, поиск позволил найти источник (или версию источника): Михаил Рыбаков в книге "Как навести порядок в своем бизнесе" рассказывает эту систему, указывая автора - Ольгу Паратнову (книга есть в инете). Впрочем, статей самой Ольги с изложением системы не найдено, только ссылки на то, что на тренингах рассказывают 5 типов мотивации. Названия несколько отличаются: Денежник и статусник вместо Финансиста и Звезды, но содержание совпадает. При этом никаких ссылок на основания системы это не видно, кое-где наоборот указывают, что это просто удобная в работе метафора. Я отмечу, что эти 5 типов более-менее напоминают пять типов мотивации Герчикова (тоже гуглится), перенесенные на руководителей или самостоятельных творческих сотрудников - сам Герчиков исследовал мотивацию сотрудников-исполнителей, так что типы несколько отличаются. Впрочем, могут быть и другие источники.

Асхат Уразбаев. Гибкое управление Data Science-продуктами

Пост на FB Асхат Уразбаев. Гибкое управление Data Science-продуктами. Слушая доклад, я получил истинное удовольствие от того, как Асхат разворачивает применение Agile-методов с учетом особенностей Data Science проектов. Потому что проблемы - те же самые, которые в свое время вызвали появление Agile для разработки, только в более концентрированном виде: в результате проекта получается вовсе не то, что нужно бизнесу, 80% проектов не доходят до прода, есть коммуникационные барьеры между инженерами и заказчиком. При этом инженеры с удовольствие делают проекты - им в радость построить модель и покрутить данные, а то, что результат оказывается не нужным их не слишком волнует, они получают удовлетворение от процесса.

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

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

Любопытна работа с MVP. Это некоторый baseline, и его часто можно собрать на коленке. Например, для задачи распознавания компаний по логотипам baseline - засунуть эту картинку в google и взять первую строку выдачи, делается дешево. Потом с ним можно сравнивать свою модель - если окажется недостаточно, потому что практика показывает, что часто такое решение удовлетворяет бизнес.

Одна из засад - модель всегда выдает результат, и потому ее правильность сложно оценить. Как способ борьбы - парное программирование. Или в виде review, друг друга, или просто через независимое решение одной задачи и сравнение результата. А еще - A/B тестирование как часть pipeline.

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

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

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

(нет элементов)

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

— Максим Цепков • 00:32, 10 марта 2020 • нет комментариев