Короткая ссылка: GorodIT-2019

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

Развитие IT в Томске

Вместе с тем я хотел бы заметить, что говоря о движении в будущее люди мыслят его в прежней функциональной структуре, у них картины принципиальных изменений, которые требуют совершенно иной кооперации. И каждый из выступающих говорил о своих достижениях, и упрекал других в том, что те движутся недостаточно быстро. Как пример. Один из руководителей компаний на треке бизнеса говорил о том, как его томская компания, сохраняя разработку в Томска открыла подразделение в Питере, потому что там можно найти готовые кадры аналитиков, маркетинга и других необходимых специализаций, и подразделение в Сан-Франциско. И давал упрек университетам, где они сделали базовую кафедру по подготовке, что уже два года мучаются, и никакого профита, все очень медленно. Похожие слова и упреки в недостаточной подготовке специалистов, плохой профориентации звучали от других представителей бизнеса. Наоборот, ректоры и представители университетов говорили о своих успехах, например, развернутой крутой пилотной программе подготовке по IT, бросали упрек бизнесу: а где амбиции построить в Томске новый Google или хотя бы Яндекс. Заметим, правда, что они-то всего лишь развернули программу на 70 специалистов, а не "новый MIT или Стэнфорд" и на гранты. Впрочем, А что такое 70 человек? Одна московская компания открыла филиал, и все. В Томске - 500 IT-компаний. у них тоже свои проблемы, та же конструкция базовых кафедр (которая вовсе не новая, а воспроизводит систему физтеха) сталкивается уже с системой образования: завкафедрами сделали руководителей компаний, а у тех нет нормативно необходимых научных степеней, и нормально решить этот вопрос не получилось. Ну и так далее, и все это, по сути, в режиме монологов, бизнесмены и профессора выступали на разных тактах круглых столов, а не в дискуссии.

Отмечу, что при этом в стране есть примеры совершенно другого взаимодействия. Например, в Ульяновске я 4 года назад в рамках конференции "Стачка" (мой отчет) был свидетелем круглого стола, на котором вопросы подготовки кадров для IT решались в совершенно практическом залоге, при этом за столом обсуждения сидели представители региона, университеты, школы и бизнес одновременно. Одна из обсуждавшихся тем: профориентацию школьникам в области IT дают учителя информатики, которые обычно вовсе не являются состоявшимися IT-шниками и выпускниками топовых ВУЗах по специальности, хотя многие из них искренне стремятся хорошо научить детей. И в качестве меры было предложена организация стажировок учителей информатики в IT-компаниях, и прямо на встрече придумали и собрали кооперацию для того, чтобы такие стажировки могли быть зачтены учителям как обязательная профессиональная переподготовка, а не легли дополнительной нагрузкой. Может быть, именно эта задача в Томске не актуальна, потому что в выступлениях звучало, что в Томские ВУЗы поступают абитуриенты со всей Сибири, хотя дополнительная ориентация школьников на IT наверняка не помешает. Я про принципиальный подход к обсуждению и решению проблем. Кроссфункциональными командами, как велит Agile. Или, если это слово инженерам режет ухо - междисциплинарными группами, как это называлось раньше. Впрочем, при решении новых вопросов был бы уместен Agile во всей полноте, а не только в виде кроссфункциональной команды, с регулярным производством измеримого результата, отличного от протоколов обсуждений, а выраженного в проведенных экспериментах.

Кстати, эксперименты о том, откуда получить недостающие кадры могут быть самые разные. В том числе - уже проведенные другими, в свое время EPAM много рассказывал, как они ставили обучение. И на одной из конференций они рассказывали, что открывая региональные офисы обнаружили очень перспективный источник тестировщиков в виде выпускников филфаков местных педвузов, у которых есть два базовых навыка: внимание к деталям и умение работать с текстами. Быстренько адаптировали под их уровень вводные курсы, и за месяц-другой обучения получали нормальных специалистов. О гуманитариях, желающих стать IT-шниками на ГородIT говорили, но скорее, в залоге недоумения, а не о перспективном ресурсе. И это как раз свидетельство того, что пока в голове у людей довлеет классическое функциональное разделение труда, и образ систематической подготовке к профессии, свойственный классическому инженерному образованию, а не приходящему цифровому миру. Который эти подходы уже обрушил: невозможно готовить классических инженеров в условиях, когда новые фреймворки разработки, со своими концептами и парадигмами появляются раз в квартал. Потому что систематичное обучение такому фреймворку - курс на полгода, а хороший полугодовой курс готовится 3-7 лет, об этом есть опыт индустрии. Тем не менее фреймворки весь мир разработчиков осваивает.

Конференция и доклады

Организация самой конференции - тоже свидетельство традиционного подхода. Два дня, менеджерский и разработческий. Казалось бы, если у вас проблема с sofskill, а разработчиков хватает - запусти эти треки параллельно, пусть разработчики ходят не только на свои доклады. Хотя, быть может, я тут не справедлив и замысел в эту сторону есть, только другой: послать перспективных разработчиков на оба дня, и пусть в первый день у них не будет альтернативы менеджерским докладам, более жесткий push новых знаний получается :) А второй день - не только разработческий, там отдельные треки аналитиков, дизайнеров, тестировщиков, devops.

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

Заглянул на доклад Ольги Павловой, которая как раз много говорила о soft skill, ответственности за выполняемую задачу и разумную инициативу, послушал обзор прогресса в AI Григория Сапунова.

А в первый день после круглых столов я был на секции проектного управления, и там по паре докладов вел прямой репортаж в FB. Темы были острые и вызвали обсуждение (которое в отчет я копирую не полностью, смотрите посты по ссылкам).

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

Миф про рептильный мозг. Что есть два отдела, и рептильный мозг - он за низменное, а основной мозг - за возвышенное. Поэтому когда видишь агрессивное поведение - значит просто рептильный мозг сильно развит. Это - миф. Действительно, есть два отдела мозга, появившиеся в разное время. Но рептильный мозг реально ни за какое поведение не отвечает, все поведение - продукт коры головного полушария. А многие коучи зацепились это не как за метафору, а как за факт.
Миф о вреде иерархий: иерархии выдумали менеджеров чтобы управлять коллективами, они не естественны и это самый неправильный способ управления. Бирюзовые организации и другие книги. Проговаривается мысль про то, что все организации равноценны и адекватны внешнему контенту. Но при этом коннотации наименований - явно отрицательные. Там примеры из книжек, и приписывание свойств. Миф разворачивает сам себя, подталкивает к выводам.
- Тут отмечу, что рассказывая миф, он использует попсовую версию мифа. А развенчивание мифа - из истории, стайный период существования людей. С аналогом на павианов - там сложно организованная иерархия, а отличие от горилл, и этологи это показывают. Понятно, что не менеджеры эту иерархию придумали. Тезисы.
  1. Иерархия благополучно возникает в свободных объединениях людей, например, у подростков и это наблюдали. А также, например, в церковных организациях. То есть иерархия не связана напрямую с ограничением свободы. При этом, кстати, иерархия используется, в том числе, в добровольных армейских объединениях для защиты какой-либо идеи. То есть люди добровольно, своей свободной волей строят иерархии, потому что она эффективна.
  2. Зафиксировано, что стайным животным свойственно возникновение сложной иерархии. И значит, у людей тоже есть предпосылки для работы в иерархически организованных структурах в механизмах базового уровня - это НЕ является "насилием для природой", а лишь одной формой организации, выработанной природой.
- Миф, с которым спорил автор - это однозначно негативное окрашивание иерархической организации в пользу других, таких как свободное лидерство или консенсусная организация без лидеров или лидерство-служение. Кстати, таких идеалов - много и часть из них осуждают любое лидерство как насилие.
Миф про Cynefin framework как способ выбора проекта подхода. Впрочем, тоже изложен в популярной версии. Очень правильный тезис про то, что позиция в кеневин фреймворка зависит от экспертного уровня исполнителя. При этом проблема именно в попсовой версии кеневина, которую я несколько раз слышал/читал. Там быстро выходят на то, что у вас социальная система, много стейкхолдеров, а значит - запутанная, а значит надо использовать эксперименты, вперед в agile. В этом миф.

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

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

Дальше идет разворачивание тезиса на примере ремонта в квартире. Для него - громадное количество неопределенности, но он точно считает, что там надо достаточно много от классического подхода. А еще - ему не нужно делать ремонт по-комнатно и жить в процессе (хотя такой способ тоже есть. Я тут отмечу, что реальный ответ на выбор подхода следующий: эффективен тот подход, которым ты владеешь и которому умеешь обучить других, поставить в процессе. У Сазерленда, кстати, есть пример в книге как он делал ремонт своего дома по Скраму и получилось быстрее, чем у соседей. При этом потом один из сосед нанял ту команду, что делала ремонт ему, но запустил обычный процесс - и получилось как обычно долго...
Пример одной из крупных корпораций. Два мира: определенности наверху, программное управление, и мир неопределенности внизу. Дружат их высокомотивированные менеджеры. Связка держится на высокоэффективных менеджерах, мотивированных на достижение результата. Я тут отмечу, что смотря на все крупные корпорации хорошо видно, что несмотря на усилия менеджеров все программы реально задерживаются. Хотя бонусы менеджерам все равно выплачиваются...
Каркас гибридного метода. Длинный горизонт - диаграмма Ганта, а внутри - управленческие циклы, и там можно agile. С моей точки зрения, тут уместность диаграмм Ганта - надежность прогнозирования. Agile четко говорит, что в условиях, когда ты не можешь уверенно прогнозировать продвижение работ, диаграмма Ганта становится самообманом, и ее поддержка - бесполезной тратой времени. И с этим надо смириться, и искать альтернативные методы. Так что тут вопрос выбора: можно разбить на четкие этапы, выстроить их в диаграмме Ганта и далее ей следовать. А можно и НЕ разбивать на этапы, а всего лишь разбить на задачи, примерно оценить трудоемкость, и исполнять их, прикидывая сроки по оставшемуся количеству. И это будет agile, который сильно проще. Понятны потенциальные проблемы - последовательность выполнения, из-за чего отштукатуренные схемы придется вскрывать для прокладки электропроводки, и проблема с предсказуемостью потребности в специалистах. Но их НЕ обязательно решать диаграммой Ганта, а можно и по-другому.
Важная проблема - что бизнеc-кейс часто выносят за пределы проекта. Например, задержку сроков не оценивают с точки зрения накладных расходов. В примере с ремонтом - любая задержка означает, что тебе дольше жить на съемной квартире, а бригаде, которая делает ремонт на это точно наплевать. Я тут отмечу, что вынос бизнес-кейса за пределы проекта - как раз проблема классического PM - в PMbook это включено на уровень программ. А вот современные agile-подходы как раз нацелены на втягивание бизнес-кейса внутрь задачи.

Алексей Мирютов. Масштабируем гибкость. Продукт пошел, мощность бэклога выросла - стало нужно масштабироваться, работа больше одной команды. Компонентные команды не могут выпускать ценность, функциональные - тоже. Только фичи тимы. Но не обязательно полные fullstack. Надо чтобы команда могла выпускать ценность, а не для всякой задачи нужны все, а fullstack команда - непросто! У них 8 команд fullstack выпускают команды, а еще 12 команд неполные, и они решают задачи, для которых отсутствующие специализации не нужны. Фреймворк - LeSS Huge. И дальше был подробный рассказ, как у них это устроено на 200 человек. При том, что внешние мероприятия в режиме телеконференций на 600 человек.

Активно используется DoR, DoD, бизнесовый DoD, на слайдах были примеры.
А еще есть проблемы, что профессионал в команде одинок по своим технологиям. И командам надо помогать в самоорганизации и организации профессиональных сообществ. у них head of process, head of platform (это как раз про технологии), SM, Manager (servant leadership) - и между ними разделение ответственности за разные сферы управления, в презентации было.
И везде - метрики. При чем метрики именно в варианте, доступном для всех команд. И опыт показывает, что хорошие команды реально ориентируются на собственные метрики. Конечно, не все, но тут надо помогать и работать с культурой, а не просто подгонять команду. Все не феерично, есть проблемы в областях требований и с релизами, но они с этим активно работают.

Завершал трек Алекс Трошин, подробно рассказывая процесс в финам, в деталях со скринами с таск-трекера.

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

В своем докладе Эволюция технологий управления компаниями в цифровом мире я как раз рассказывал про те принципиальные изменения, связанные с приходом цифрового мира. В результате которых старые подходы к функциональной организации труда по специализациям перестают работать. Во всяком случае, на переходном этапе, то есть с в ближайшие тридцать лет. И про те новые подходы, которые уже проявились - agile и его развитие в IT, бирюзовые организации, активная работа с мотивацией, самореализацией и освоение софтскилл. И выходом в контракт об условиях для счастья на работе в обмен на искреннюю работу на цели компании, который уже не обсуждается как светлое будущее, а является предметом реализации и предложений на рынке труда со стороны некоторых компаний. Доклад был очень широким и потому обзорным, объединяя темы минимум трех других моих докладов Мыслить проектно: история и современность (SECR-2018), Эволюция технологий управления (ПИР Сибирь-2019) и Социальный договор цифрового мира: работа должна обеспечивать счастье, а не только деньги (РИТ-2019).

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

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