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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как отдавать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все ревью не слишком работают в моменте, но 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 в телеграмме, где обсуждаются эти темы.