2019-06-30: РИТ-2019 - большая конференция о технологиях и счастье на работе

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

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

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

Конференция #RITfest прошла в конце мая и была очень содержательная. Как я отметил (в завершающем посте), я слышал только очень малую часть докладов из параллельно идущих 9+ треков, при чем был преимущественно на менеджерских докладах, а не технологических. Погрузиться в технологии, как я это сделал на #SaintHighLoad2019 у меня не получилось, и если вы хотите узнать про эти доклады, то читайте другие отзывы о конференции. В ленте Родиона Нагорнова это - итоги, отдельные посты доклад Георгий Могелашвили доклад Анатолий Иванов доклад Марина Корсакова и другие. И наверняка есть много других отзывов и конспектов, и это - прекрасно, люди делятся своими впечатлениями от выступлений.

Треки менеджерских докладов

Менеджерские доклады шли в два параллельных трека, Aletheia Business и Whale Rider, и были достаточно контрастны. Потому что на первом была большая серия докладов про новую корпоративную культуру, предполагающую вовлеченность сотрудников в искреннюю работу на цели компании и создание им условий для счастья на работе. А вот Whale Rider включала доклады предпринимателей и менеджеров, которые работают в культуре более традиционного менеджмента. Обе эти культуры сейчас существуют одновременно, и они обе уместны. В том числе потому, что разным людям нужно разное счастье, и работа в высокотехнологичной инженерной компании с хорошим управлением дает инженеру хорошие возможности самореализации и получения счастья, не всем нужна вовлеченность в решение бизнес-задач, многие предпочитают решать инженерные задачи. Другое дело, что культура вовлеченности и счастья активно развивается, она начала быть заметной относительно недавно, чуть больше пяти лет назад, а сейчас уже проявляется не только в небольших стартапах и у лидеров рынка, но и в enterprise-разработке больших компаний, таких как ЦФТ, а также в inhouse. И ее доля точно будет увеличиваться, и это будет создавать давление на рынок персонала. Потому что в IT рынок персонала уже давно дефицитный, и сейчас помимо интересных проектов и хорошей зарплаты, свободного графика и разнообразных плюшек все больше предложений, которые говорят об условиях для счастья на работе.

Мои доклады

Вообще у меня есть собственная модель развития культур ведения IT-проектов, которую я впервые сформулировал четыре года назад на AgileDays-2015 в докладе Развитие управления проектами и критериев качества в ИТ. С тех пор она развивается и обогащается. И, так получилось, что она послужила основой сразу двух докладов на РИТ++. Первый Социальный договор цифрового мира: работа должна обеспечивать счастье, а не только деньги как раз говорил о контрактах между компанией и разработчиком в разных культурах, о переходе сейчас к новому контракту, о котором шла речь в начале отчета: искренняя работа на цели компании в обмен на создание условий для счастья на работе. Отмечу, кстати, что эту формулировку я услышал от Александра Горника на AgileDays-2019, который призывал сотрудников не стесняться требовать от компании выполнения ее части этого нового контракта. По следам AgileDays и обсуждениям на Saint HighLoad я написал о новом контракте большую статью, и меня позвали в докладе раскрыть тему глубже и подробнее.

Помимо модели развития культур в IT и в докладе был небольшой обзор моделей того, как с условиями для счастья работать. Потому что совершенно понятно, что разным людям нужно разное счастье, и потому именно сам человек определяет, счастлив ли он, это не формулируется в рамках каких-то критериев и требований. Может показаться, что с такими субъективными критериями невозможно работать, но практика показывает, что это - вполне рабочая конструкция. Подобно тому, как многие компании говорят об удовлетворенности стейкхолдеров как критерии успеха проекта (об этом у меня был другой доклад пару лет назад), при том, что стейкхолдеры тоже меряют свою удовлетворенность субъективно. Доклад вызвал большой интерес, и, как я отмечал в посте на FB, обсуждение в кулуарах продолжалось еще два слота. Тема интересная, поэтому если вы хотите посмотреть видео до того, как его опубликуют организаторы, то можно написать мне, я пришлю ссылку. А здесь и здесь фото с доклада и обсуждения в числе других.

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

Кто хочет выступать?

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

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

А теперь я перехожу к постам репортажа с конференции.

Ольга Давыдова, Артем Каличкин ЦФТ. Fullstack HR, или Трансформация роли HR при цифровой трансформации

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

Пост на FB Ольга Давыдова, Артем Каличкин ЦФТ. Fullstack HR, или Трансформация роли HR при цифровой трансформации. Парный доклад, Ольга - HR, Артем - технарь. HR работают с софтскилл разработчиков. И, с одной стороны есть стоны разработчиков "хватит уже этого софтскилл, а с другой тимлиды понимают, что не хватит, потому что на код ревью по-прежнему такие комменты, от которых авторы кода плачут. И потому HR ищут разные способы работы с процессами. Например, осваивают проведение ретроспектив. Или структурируют и фасилитируют архитектурные и инженерные встречи. Началось это с помощи в проведении конкретной встречи, когда 30 архитекторов должны были договориться про рефакторинг, и они не только фасилитировали из нейтральной позиции, но и предварительно структурировали встречу, и Артем понял, что эффективность была много выше, чем если бы он готовил сам, а HR поняли, что получился формат, который можно тиражировать. А с другой стороны, HR осваивают инженерные практики. HR-процессах у них Kanban, и в компании считают, что он самый честный. Или проводят продуктоны для того, чтобы сократить срок вовлечения. И много других интересных кейсов и историй, в докладе и ответах на вопросы.

В ответах на вопросы: если задача большая, например, увеличить команду в несколько раз, то это уже не Kanban, это выделяется в отдельный подход и там Scrum, при чем полная команда, а не только HR, как и положено. И живут в Jira + Confluence. И в целом организационно они не разделены, идет тесное взаимодействие и сетевая структура, а не иерархия.

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

Марина Корсакова. Трансформация бизнес-культуры: преодолеть сопротивление, добиться результата

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

Для будущего надо придумать метафору, а еще придумать и поменять содержание в мелочах, на соответствующее культуре - и описание вакансий и форму приглашения на совещание. Но местами при этом в речи проявляются старые подходы, но завуалировано. Например, когда разговор идет о трансляции мидлам метафоры, то старый путь "собрать всех и рассказать, как они будут жить" - отвергается. Это - не работает, в чужой метафоре люди не живут, надо сделать так, чтобы они взяли эту метафору как свою! Но в речи тут же вылезает классическое "а для этого есть манипулятивные (в хорошем смысле) практики". Так вот, мое мнение - что это НЕ работает, в IT-среде, где люди умные - точно. Надо честно приходить из партнерской позиции, а не позиции манипулятора.

Но, повторюсь, в целом доклад интересный и содержательный.

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

После этого доклада я как раз поямал тему работы с корпоративной культурой написал такой пост: "На #RITfest2019 активно говорят про культурную трансформацию. Хочу порекомендовать тут книгу Марк Розин "Успех без стратегии", в котором очень интересно и содержательно об этом написано, в котором он сопоставляет классический менеджмент и альтернативу, названную им оппортунистическим подходом. Мой конспект http://mtsepkov.org/Rozin-NoneStrategy и он одобрен автором как качественное краткое изложение. Про корпоративную культуру раздел "Управление талантами - Хомо корпорациус", а перед ним есть интересный раздел "Управление эффективностью или счастье как цель". И все это перекликается с моим завтрашним докладом о том, что работа должна обеспечивать счастье, а не только деньги".

Anatoly Ivanov. Как вовлечь команды разработки в бизнес компании

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

Там две развилки: или найм супер-звезд, PO как мини-CEO, или вовлечение всей команды. Первый путь имеет естественные ограничения - таких людей мало. Но что важно: push для вовлечения не работает. Надо привлекать, pull, надо чтобы они сами туда шли и вовлекались, и смотреть на процесс вовлечение.

Финансовые графики успеха компании в общем доступе. Но! Они попробовали - оно НЕ сработало. Люди видят график на телевизоре - и не обращают особого внимания. А вот если финансы встроить в devops -графики, так, чтобы видеть потенциальное влияние деплоя новой фичи на финансовые показатели наряду с другими - тогда люди интересуются.

Встречи с бизнесом. Важно, чтобы команда разработки участвовала на встречах с бизнесом. Ahmed Sidky, глава ICAgile. Его назначили R&D - менеджером в крупную игровую компанию, и произошло столкновение теории с практикой. Встречи должны быть эффективны - а это значит мало участников. Но на встречах с бизнесом должно быть по-другому - только еще надо слышать их идеи - и люди начнут вовлекаться. Вроде бы такая встреча - громадные затраты времени. Но! у них число фич, которые переделывались снизилось практически до нудя,потому что люди понимают назначение своих фич для бизнеса.

В ответах на вопросы - как часто такие встречи? В зависимости от темпа изменений в бизнес-направлении раз в 1-2 недели и полчаса-час. Если надо обсуждать, то час, в полчаса не укладывается...

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

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

Формат user stories. Why What Who. Очень часто пишутся формально, а не по существу. Тут ключевой вопрос Зачем. И тут у них, что у каждого участника команды есть право заблокировать разработку фичи, если непонятно, зачем ее делают. Это была очень тяжелая часть, потому что останавливается процесс. Но, реально потери от того, что команда делает непонятное - больше, потому что возникают переделки. Культура сложилась в части команд - и этого достаточно при культуре обмена сотрудников между командами.

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

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

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

Но! во всей этой истории есть подвох. Это все не про конкретные процессы, они должны проникнуть в культуру. И потому это не быстро.

В ответах на вопросы. Как рассказывать на демо технические вещи? Их рассказывают быстро и без технических подробностей, на бизнес-уровне. А в целом про содержание Демо обратную связь должен давать бизнес, и он - дает.

В вопросах - как наладить у бизнеса понимание особенностей разработки и его вовлечение? Ответ - проведите хакатон, в котором бизнес поработает внутри команд и проникнется духом разработки.

Сергей Кожемякин из AGIMA. Управление производством на основе анализа данных в агентстве заказной разработки

Пост на FB Сергей Кожемякин из AGIMA. Управление производством на основе анализа данных в агентстве заказной разработки. Рассказ о большой системе показателей, на основе которых идет управление проектами. Здесь и большие таблицы удовлетворенности клиентов, соответствия ожиданиям, и аудит соответствия процессов команды регламентам. Основа всех этих показателей - рентабельность, ради которой и работает компания, и ее вычисление каскадировано до тимлидов, арт-директоров и руководителей проектов. Задача руководителя проекта - продать больше, а тимлида - сделать эффективнее. Но при этом у руководителя проекта рентабельность входит как пороговое значение, чтобы не продавали нерентабельные проекты. Все это вынесено в KPI, вознаграждение состоит из фиксированной части и бонусной, в которую и выведена рентабельность. Понятные сложности - заставить технарей быть экономистами, аккуратный тайм-трекинг своих затрат. И понятная мотивация - конференции, повышение зарплаты, мероприятия для команды.

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

Дмитрий Смирягин. Бюрократ и художник. Искусство баланса в процессном управлении

Пост на FB Дмитрий Смирягин. Бюрократ и художник. Искусство баланса в процессном управлении. Забавный доклад. Сначала Дмитрий рассказал, что бизнес сейчас должен быстро реагировать на изменения, что типовые задачи практически исчезли, надо решать уникальные задачи, все проекты уникальны. И потому регламенты не работают, что на конвейере сейчас никто трудиться не будет. Приводил примеры Apple и Кодак и многие другие.

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

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

Да, Дмитрий из НРД, но это - опыт предыдущего места работы.

Комментарий Timur Batyrshin Отличный термин, "ситуативное управление", не знал о нём. Такое чувство, что аджайлом очень часто называют именно его, и как раз в этих случаях говорят, что "аджайл не работает".

Максим Цепков Да, именно так. В IT еще термин Code&Fix - когда просто в пожарном режиме пишут фичи и исправляют ошибки, без всякой целевой фокусировки.

Андрей Смирнов. Почему не надо становиться руководителем

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

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

Зарплаты. Люди думают, что руководители много получают. Это так на начальном периоде, а с ростом стажа зарплаты выравниваются, есть такая статистика. А еще тимлид не может работать дистанционно из Таиланда или из дома. И календарь встреч у него сумасшедший.

Владимир Рахтеенко. Бизнес со смыслом: как построить компанию, которая переживет 20-летие

Пост на FB Владимир Рахтеенко. Бизнес со смыслом: как построить компанию, которая переживет 20-летие. Это концептуальный доклад о создании компании, которая может развиваться вечно. Для меня это личный доклад, потому что я же - со-учредитель компании CUSTIS, в которой Володя - генеральный директор. И, с одной стороны я это много лет знаю и чувствую, а, с другой, очень важная целостное изложение, с которым можно сверить свои представления. И восстановить уровень понимания, потому что доклад получился очень глубокий. И эта история, думаю, будет интересна тем. кто думает об осмысленном изменении мира с помощью своего бизнеса. Рассказанный способ - не единственный, мы все - разные и у нас разные смыслы деятельности. Но, во-первых, это вполне достойный образец, а, во-вторых, глубина проработки должна быть соразмерной, и можно использовать этот доклад как образец. Поэтому дальше в комментариях конспект.

Доклад интересен для

• Созидатели - те, для кого интересно созидание как восхождение на лестницу
• Кто верит, что если долго и настойчиво делать одно и то же, то вы достигните многого. Ежи
• Человек в одиночку слаб, а в команде соратников сделаешь много больше.

Не интересен

• кто на краткосрочный денежный и социальный успех
• кто верит, что деньги и есть успех

Почему бизнес, а не наука? Потому что он дает самостоятельность, а еще не дает заиграться, ты делаешь то, что действительно нужно людям

Как делаем:

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

Кто нужен

• Главный актив - социальная сетка, не только внутри и но и во вне.
• Хороший механизм свой - чужой.
• Цель важнее собственных амбиций, они ради цели готовы меняться
• Постоянно анализируют, как устроен мир
• У таких людей есть собственные стратегии. Долгосрочные.

Как узнать - изучайте его хобби. Потому что там проявляется ценности. Но окончательный диагноз - только когда переживешь несколько кризисов.

Взаимная ресурсность: с ним сделаешь больше, чем без него почему-либо, и он должен понимать это про вас - он видит, почему с вами сделает больше, чем без вас.

Пример с учредителями. "Брачный контракт", хотя это оксюморон

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

О чем договориться на берегу.

• Цели и задачи бизнеса. Смыслы важнее денег. Если деньги - подозрительно.
• Функции и полномочия основателей. Самый крепкий - когда один за рынок, а другой за организацию и технологии. Но в тяжелых бизнесах это мало, но тогда щепите позиции
• Границы совместной собственности. Это тяжелый разговор. Что точно внутри, что снаружи, что в пограничной зоне
• Механизмы и сроки принятия решений. На старте - только консенсус, но решать надо быстро, особенно на старте
• Правила выхода - они способствует тому, чтобы хорошо договариваться

Миссия. Нужна для совместного движения

• Личное предназначение. Для чего живете на планете
• Анализ куда движется общество и понять, что предназначение будет нужно 20-50 лет, понять что ваше, что не ваше. Критерий - ты батарейка-энерджайзер. Слушайте тело, не должно быть желание бросить все. Если организм говорит "не мое" - кончится плохо.

У него: База Системная инженерия, проекты большого масштаба.

• Миссия - карта и компас. Без фанатизма, сначала будет 20 миссия, 80 обеспечения, в зрелом 50-50 - повезло
• Решение конфликта из миссии: поднимаемся вверх до целей, и из нее решаете
• Два рубежа обороны - совместные цели, потом предназначение.

Эффективность бизнеса - в развитии, в преодолении, в непрерывности развития.

Типология проектов по Майстеру: Мозги - Седина - Процедуры. Эффективность в процедурах - 100%, Седина - 50% в Мозги - нет места эффективности. Там важен результат любой ценой. И это - зона низкой конкуренции. Включать чистое мышление - сложно и затратно, потому таких людей не так много.

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

Пример развития копании: раньше для проектов типа Мозги, то инвестиционный лаг был около года. Прошлая волна реорганизации горизонт инвестирования стал 5-7 лет, и это цели другой сложности.

Мы - про бизнес - должны быть долгоживущие продукты и услуги. Где

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

Майстер показал, что каждый из проектов Мозни-седина-Процедуры требует совей системы управления и если вы их смешали - идет постоянный раздрай. Если вы знаете, то вы это развели в компании, dissolution. Если не знаете - вечные компромиссы, solution, и проблемы вылезают в новой области.

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

Анализируйте бизнес клиентов. Смотрите ,как разрывы влияют на их бизнес. Лидеры отрасли, они ее двигают. Какая у них проектная деятельность, готовы ли работать из нечетких постановок, работа из замысла бизнеса. К каким формам кооперации они готовы, насколько вы им нужны. Отсечение: готовность к совместной постановки задачи от проблем. "Мы платим, вы играете" - не работает.

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

Маркер - крупная корпорация хочет измениться, но говорит, что не может меняться. И со 2-3 раза надо уходить. А они тебя ловят на проблему.

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

Синхронизируйте стратегии развития компании и сотрудников.

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

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

В ответах на вопросы. Сложность проектов

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

Он мечтает построить развивающуюся компанию-сообщество.

Дмитрий Круглов. Инженерная культура. Что в нее нужно включить и как ее внедрять

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

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

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

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

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

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

При росте: можно строить иерархию, управленческую вертикаль, а можно строить сетевую структуру взаимодействия команд Редактировать или удалить это

Примеры инженерной культуры Spotify Zalando Netflix Skyscanner

Как сформулировать инженерную культуру? Есть 5 областей деятельности, по поводу которых нужно дать ответы: Архитектура, Инфраструктура, Процессы, технологии, Люди. Ответы - не практические, не выбор технологий или требований, а ценностно-поведенческие, как мы в этих областях работаем. Примеры технологических ценностей: инновационность против надежности. Право на эксперименты - есть или нет. Облако - возможно или нет. Инфраструктура: контроль, эффективность, безопасность. Что важно - скорость, стабильность или экономия денег. Сколько серверов и другой инфраструктуры можно использовать разработчикам для экспериментов. Ценность к сотрудникам: доступность информации, личное мнение, отношение к ошибкам, личный результат. В зависимости от фокусов у вас будет различная культура. Могут быть индивидуальные гонки профессионалов кто круче, а может быть командная работа на результат. Отношение к ошибкам может стимулировать эксперименты, в том числе на пользователях, а где-то эксперименты на пользователях и клиентах недопустимы, нужно тщательное тестирование. И, вообще говоря, нужна детализация второго порядка - в каких областях доступны инструменты, а в каких - нет.

Евгений Романовский, Собака Павлова. Ролевые игры. Практика управления требованиями профессиональных продуктов

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

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

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

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

Это было про неудачные пути. Теперь про то, что работает. Это у них кристаллизуется по пути лайфхаки - практики - методы, с примерами проектов.

Медицинская карта пациента. Они сдавали работу профессиональным врачам, и немедленно получали фидбэк. Они знают, что нужно. Но! подходит не для всех продуктов, только когда есть проф.пользователи.

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

У владельца продукта было свое видение, по медицинской методологии, и путь продукта. Не было только самого продукта. И они (а) собрали неполные вводные, (б) как-то размыто описали пользователей, и попросили сделать 100 экранов мобильного приложения - любые, нарисуйте варианты. А параллельно посадили дизайнера заказчика, он собирался собирать цвета и логотипы. Его тут же заставили нарисовать UI-кит за 1 день. Тут один пришел "мне надо подумать", а второй "мне нравится" - "ок - ты думай, а ты рисуй". А дальше надо было сделать структуру - дизайнеры ее сложили. Тут пришел заказчик, увидел, сказал "ОК, дальше я сам". Факап в этом проекте, но метод - рабочий, и они его дальше неоднократно использовали, правда не в том объеме.

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

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

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

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

Анна Селезнёва. Эмоциональное выгорание. История успеха

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

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

От себя посоветую доклады Anna Obukhova, где она об этом говорит: "Утомленные Аджайлом: как коучить уставшую команду" и другие. Там есть про диагностику - по витамину D3 и другим, надо сделать анализы, способ постоянной поддержки себя через протокол актуализации результата и другие подробности. Впрочем, профессиональное знание биологии и нейрофизиологии (это два из шести высших образований у Анны) тоже не спасает, потому что о себе Анна говорит "два раза выгорала, сейчас пытаюсь не выгореть в третий". Но, думаю, помогает диагностировать и восстанавливаться - сейчас у Анны батарейка явно есть.

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

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

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

— Максим Цепков • 00:52, 30 июня 2019 • нет комментариев