TeamLeadConf-2019 - История изменений

MaksTsepkov в 11:56, 20 мая 2021

2021-05-20T11:56:24Z

MaksTsepkov в 11:54, 20 мая 2021

2021-05-20T11:54:56Z

MaksTsepkov в 21:13, 5 апреля 2019

2019-04-05T21:13:45Z

MaksTsepkov в 20:45, 5 апреля 2019

2019-04-05T20:45:19Z

MaksTsepkov в 20:43, 5 апреля 2019

2019-04-05T20:43:42Z

Внесённые изменения

MaksTsepkov в 20:40, 5 апреля 2019

2019-04-05T20:40:21Z

MaksTsepkov в 20:39, 5 апреля 2019

2019-04-05T20:39:48Z

MaksTsepkov в 20:39, 5 апреля 2019

2019-04-05T20:39:24Z

MaksTsepkov: Новая страница: «Конференция [http://teamleadconf.ru TeamLeadConf] первый раз прошла всего год назад в Москве и сразу оказ…»

2019-04-05T20:33:13Z

Новая страница: «Конференция [http://teamleadconf.ru TeamLeadConf] первый раз прошла всего год назад в Москве и сразу оказ…»

Внесённые изменения

@@ Строка 8: / Строка 8: @@
 ==OKR: инструкция по применению. Егор Толстой==
-[https://www.facebook.com/mtsepkov/posts/2142958265761116 Пост на FB]: '''OKR: инструкция по применению. Егор Толстой]'''. Это - действительно инструкция. Лет 10-15 назад доклады подобного уровня были на тему, как внедрить task tracker или continious integration. Вопрос "зачем" при этом ставится слабо - об этом есть книги, и это уже в культуре. И по отношению task tracker и CI тогда, и OKR сейчас. С моей точки зрения, это - сдвиг. При этом и тогда и сейчас это в культуре не у всех, а на фронтире, но предполагается, что интересующимся - google и книги в помощь. Ну или другие, более ранние доклады, в которых это рассматривалось. При этом контекст назначения и окружения в докладе присутствует: речь идет о компании, состоящей из зрелых самодвижущихся команд, у которых есть миссия, долгосрочные цели и направления работы, так что вопрос "зачем мы здесь собрались" понятен, и "зарабатывать деньги" ответом не является. И дальше нужен инструмент, как сделать, чтобы команду не штормило, чтобы на поставленных целях удерживался фокус, как обеспечить интеграцию движения отдельных команд в движение компании в целом, при поставленных общих миссии и целях компании, и как обеспечить координацию между командами. Вот для этого - ORK, который Google адаптировал под культуру IT, в частности - отвязал от денег, это супер-важно. И Андрей Емельянов, который в Авито это первым внедрял в своей команде ездил в google знакомиться с опытом из первоисточника. Что интересно, OKR внедрялся с одной команды, а не сверху по компании. Потом - подключение смежных команд со связанными целями. И только после этого - масштаб на компанию в целом. Сейчас, спустя 3 года, у них к этой системе подключено 130 структур.
+[https://www.facebook.com/mtsepkov/posts/2142958265761116 Пост на FB]: '''OKR: инструкция по применению. Егор Толстой'''. Это - действительно инструкция. Лет 10-15 назад доклады подобного уровня были на тему, как внедрить task tracker или continious integration. Вопрос "зачем" при этом ставится слабо - об этом есть книги, и это уже в культуре. И по отношению task tracker и CI тогда, и OKR сейчас. С моей точки зрения, это - сдвиг. При этом и тогда и сейчас это в культуре не у всех, а на фронтире, но предполагается, что интересующимся - google и книги в помощь. Ну или другие, более ранние доклады, в которых это рассматривалось. При этом контекст назначения и окружения в докладе присутствует: речь идет о компании, состоящей из зрелых самодвижущихся команд, у которых есть миссия, долгосрочные цели и направления работы, так что вопрос "зачем мы здесь собрались" понятен, и "зарабатывать деньги" ответом не является. И дальше нужен инструмент, как сделать, чтобы команду не штормило, чтобы на поставленных целях удерживался фокус, как обеспечить интеграцию движения отдельных команд в движение компании в целом, при поставленных общих миссии и целях компании, и как обеспечить координацию между командами. Вот для этого - ORK, который Google адаптировал под культуру IT, в частности - отвязал от денег, это супер-важно. И Андрей Емельянов, который в Авито это первым внедрял в своей команде ездил в google знакомиться с опытом из первоисточника. Что интересно, OKR внедрялся с одной команды, а не сверху по компании. Потом - подключение смежных команд со связанными целями. И только после этого - масштаб на компанию в целом. Сейчас, спустя 3 года, у них к этой системе подключено 130 структур.
 А дальше в докладе много техники, как это устроено. Полная прозрачность, которая и есть основная цель OKR. Квартальный ритм, примерно месяц в начале квартала по нескольку часов в неделю у команды. Интегрирован с Agile, цели спринта должны быть позиционированы относительно OKR и на демо это показывают. Как планировать, как формулировать цели, и так далее - смотрите доклад, когда опубликуют.
@@ Строка 24: / Строка 24: @@
 [[Файл:TeamLeadConf-2019-p3.jpg|400px|right]]
-[https://www.facebook.com/photo.php?fbid=2142973502426259&set=a.660825517307739&type=3 Пост на FB]: '''Как измерить производительность программиста? Yuliya Kurapatenkava из Spotify]'''. Небольшая завязка о том, что 2.5 года она услышала от разработчика, что для него "деньги - не мотивация, хочу стать senior". И тогда это вошло в диссонанс с тем, что учили института и что говорила мама об устройстве мира, она начала смотреть исследования и узнала, что есть точка перегиба, уровень, по достижению которого влияние материальной мотивации существенно падает. И надо строить мотивацию по-другому. В вопросах было - как уровень перегиба выявлять, потому что он - разный. Они это определяют.
+[https://www.facebook.com/photo.php?fbid=2142973502426259&set=a.660825517307739&type=3 Пост на FB]: '''Как измерить производительность программиста? Yuliya Kurapatenkava из Spotify'''. Небольшая завязка о том, что 2.5 года она услышала от разработчика, что для него "деньги - не мотивация, хочу стать senior". И тогда это вошло в диссонанс с тем, что учили института и что говорила мама об устройстве мира, она начала смотреть исследования и узнала, что есть точка перегиба, уровень, по достижению которого влияние материальной мотивации существенно падает. И надо строить мотивацию по-другому. В вопросах было - как уровень перегиба выявлять, потому что он - разный. Они это определяют.
 А дальше был рассказ про устройство круга роста разработчиков (на фото).
@@ Строка 48: / Строка 48: @@
 ==Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy из Badoo==
-[https://www.facebook.com/mtsepkov/posts/2142993122424297 Пост на FB]: '''Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy Badoo]'''. Работа по срокам, их оценка и умение отслеживать - крутейший инструмент развития разработчиков. Сроки - на полном цикле, не отдать в QA, а когда код на проде начал наносить непоправимую пользу. А в чем в этой схеме роль тимлида? Он становится тренером, как спортивный тренер - он не играет вместо игроков. Вопрос - зачем это разработчику? А именно за тем, что они становятся способными решить задачу целиком, а не свой кусок, получают новые области для развития. Они порождают инженеров, которые умеют решать задачи из программистов, которые умеют только писать код. Не все хотят играть в эту игру, во-первых, нужны soft skill, и нужна адаптация людей.
+[https://www.facebook.com/mtsepkov/posts/2142993122424297 Пост на FB]: '''Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy Badoo'''. Работа по срокам, их оценка и умение отслеживать - крутейший инструмент развития разработчиков. Сроки - на полном цикле, не отдать в QA, а когда код на проде начал наносить непоправимую пользу. А в чем в этой схеме роль тимлида? Он становится тренером, как спортивный тренер - он не играет вместо игроков. Вопрос - зачем это разработчику? А именно за тем, что они становятся способными решить задачу целиком, а не свой кусок, получают новые области для развития. Они порождают инженеров, которые умеют решать задачи из программистов, которые умеют только писать код. Не все хотят играть в эту игру, во-первых, нужны soft skill, и нужна адаптация людей.
 Я от себя отмечу, что умение работать со сроками и подобные soft skill - это горизонтальная планка для T-shape людей. То есть в идеале, конечно, она достаточно жирненькая горизонтальная палочка, у некоторых превращающаяся в ножку, но практически фишка именно в том, чтобы процессы позволяли держать правильный баланс.
@@ Строка 79: / Строка 79: @@
 ==Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза==
-[https://www.facebook.com/mtsepkov/posts/2144397808950495 Пост на FB]: '''Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза]'''. Заметки с доклада.
+[https://www.facebook.com/mtsepkov/posts/2144397808950495 Пост на FB]: '''Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза'''. Заметки с доклада.
 Коммуникация просто на основе опыта не слишком конструктивна: у разных людей - разный опыт, и они слабо сравнимы. А вот когда мы переводим опыт в ценности и смыслы, то коммуникация возможна и конструктивна, их можно соотносить.
@@ Строка 115: / Строка 115: @@
 ==Во имя нового продукта. Евгений Россинский==
-[https://www.facebook.com/mtsepkov/posts/2144727402250869 Пост на FB]: '''Во имя нового продукта. Евгений Россинский]''' год назад рассказывал о том, как ivi из функциональных подразделений к Value Stream команды выпуска конечного продукта. А в этом году у них встала задача существенно переписать весь продукт с изменением архитектуры, чтобы обеспечить новые возможности бизнеса, в частности повсеместное управление общей рекомендательной системой и переход на дизайн-систему при том, что платформенно-независимые стеки им не подходят. Они попробовали ее сделать, сохранив value stream - оно не получилось, потому что зоны ответственности за продукт по value stream не делятся, коммуникации когда делаем новый продукт нужны функциональные, синхронизация рассыпалась. Они провели большую ретроспективу, выявили много боли. В том числе, связанной с тем, что для разработки нового продукта нужно тщательное архитектурное проектирование и документирование. И в результате поняли, что value stream хорош по развитию готового приложения, но плох для разработки с нуля. В результате они вернулись к функциональному подразделению компании. При этом, естественно, вернулись все боли, которые ранее полечил value stream и, более того, местами пришлось перейти на ручное управление доработкой старого продукта - полностью остановить ее было невозможно. А еще возник дефицит ответственных архитекторов, оказалось, что хотя многие разработчики мечтали про рефакторинг, далеко не все идеи рефакторинга оказались рабочими. Это компенсировали подключением QA, которые обеспечивали детализацию постановок до нужного уровня и консультации по ним - сделали Летучие отряды возмездия. В целом, начав в апреле они к октябрю сделали основные релизы. И после этого - снова вернулись к value stream, к январю к ним вернулись. В целом был большой стресс, но они справились, горды результатом и постепенно переходят в себя. В целом очень интересная динамика развития.
+[https://www.facebook.com/mtsepkov/posts/2144727402250869 Пост на FB]: '''Во имя нового продукта. Евгений Россинский''' год назад рассказывал о том, как ivi из функциональных подразделений к Value Stream команды выпуска конечного продукта. А в этом году у них встала задача существенно переписать весь продукт с изменением архитектуры, чтобы обеспечить новые возможности бизнеса, в частности повсеместное управление общей рекомендательной системой и переход на дизайн-систему при том, что платформенно-независимые стеки им не подходят. Они попробовали ее сделать, сохранив value stream - оно не получилось, потому что зоны ответственности за продукт по value stream не делятся, коммуникации когда делаем новый продукт нужны функциональные, синхронизация рассыпалась. Они провели большую ретроспективу, выявили много боли. В том числе, связанной с тем, что для разработки нового продукта нужно тщательное архитектурное проектирование и документирование. И в результате поняли, что value stream хорош по развитию готового приложения, но плох для разработки с нуля. В результате они вернулись к функциональному подразделению компании. При этом, естественно, вернулись все боли, которые ранее полечил value stream и, более того, местами пришлось перейти на ручное управление доработкой старого продукта - полностью остановить ее было невозможно. А еще возник дефицит ответственных архитекторов, оказалось, что хотя многие разработчики мечтали про рефакторинг, далеко не все идеи рефакторинга оказались рабочими. Это компенсировали подключением QA, которые обеспечивали детализацию постановок до нужного уровня и консультации по ним - сделали Летучие отряды возмездия. В целом, начав в апреле они к октябрю сделали основные релизы. И после этого - снова вернулись к value stream, к январю к ним вернулись. В целом был большой стресс, но они справились, горды результатом и постепенно переходят в себя. В целом очень интересная динамика развития.
 ==Методология как конструктор: инструкция по сборке. Филипп Дельгядо==
@@ Строка 149: / Строка 149: @@
 ==Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров==
-[https://www.facebook.com/mtsepkov/posts/2144941355562807 Пост на FB]: '''Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров]'''. Рассказ о том, с чего начать новому руководителю. Надо составить профиль сотрудников и профиль проблем внутри и снаружи.
+[https://www.facebook.com/mtsepkov/posts/2144941355562807 Пост на FB]: '''Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров'''. Рассказ о том, с чего начать новому руководителю. Надо составить профиль сотрудников и профиль проблем внутри и снаружи.
 Системно, с деталями, например, про базовые качества:

@@ Строка 8: / Строка 8: @@
 ==OKR: инструкция по применению. Егор Толстой==
-'''[https://www.facebook.com/mtsepkov/posts/2142958265761116 OKR: инструкция по применению. Егор Толстой]'''. Это - действительно инструкция. Лет 10-15 назад доклады подобного уровня были на тему, как внедрить task tracker или continious integration. Вопрос "зачем" при этом ставится слабо - об этом есть книги, и это уже в культуре. И по отношению task tracker и CI тогда, и OKR сейчас. С моей точки зрения, это - сдвиг. При этом и тогда и сейчас это в культуре не у всех, а на фронтире, но предполагается, что интересующимся - google и книги в помощь. Ну или другие, более ранние доклады, в которых это рассматривалось. При этом контекст назначения и окружения в докладе присутствует: речь идет о компании, состоящей из зрелых самодвижущихся команд, у которых есть миссия, долгосрочные цели и направления работы, так что вопрос "зачем мы здесь собрались" понятен, и "зарабатывать деньги" ответом не является. И дальше нужен инструмент, как сделать, чтобы команду не штормило, чтобы на поставленных целях удерживался фокус, как обеспечить интеграцию движения отдельных команд в движение компании в целом, при поставленных общих миссии и целях компании, и как обеспечить координацию между командами. Вот для этого - ORK, который Google адаптировал под культуру IT, в частности - отвязал от денег, это супер-важно. И Андрей Емельянов, который в Авито это первым внедрял в своей команде ездил в google знакомиться с опытом из первоисточника. Что интересно, OKR внедрялся с одной команды, а не сверху по компании. Потом - подключение смежных команд со связанными целями. И только после этого - масштаб на компанию в целом. Сейчас, спустя 3 года, у них к этой системе подключено 130 структур.
+[https://www.facebook.com/mtsepkov/posts/2142958265761116 Пост на FB]: '''OKR: инструкция по применению. Егор Толстой]'''. Это - действительно инструкция. Лет 10-15 назад доклады подобного уровня были на тему, как внедрить task tracker или continious integration. Вопрос "зачем" при этом ставится слабо - об этом есть книги, и это уже в культуре. И по отношению task tracker и CI тогда, и OKR сейчас. С моей точки зрения, это - сдвиг. При этом и тогда и сейчас это в культуре не у всех, а на фронтире, но предполагается, что интересующимся - google и книги в помощь. Ну или другие, более ранние доклады, в которых это рассматривалось. При этом контекст назначения и окружения в докладе присутствует: речь идет о компании, состоящей из зрелых самодвижущихся команд, у которых есть миссия, долгосрочные цели и направления работы, так что вопрос "зачем мы здесь собрались" понятен, и "зарабатывать деньги" ответом не является. И дальше нужен инструмент, как сделать, чтобы команду не штормило, чтобы на поставленных целях удерживался фокус, как обеспечить интеграцию движения отдельных команд в движение компании в целом, при поставленных общих миссии и целях компании, и как обеспечить координацию между командами. Вот для этого - ORK, который Google адаптировал под культуру IT, в частности - отвязал от денег, это супер-важно. И Андрей Емельянов, который в Авито это первым внедрял в своей команде ездил в google знакомиться с опытом из первоисточника. Что интересно, OKR внедрялся с одной команды, а не сверху по компании. Потом - подключение смежных команд со связанными целями. И только после этого - масштаб на компанию в целом. Сейчас, спустя 3 года, у них к этой системе подключено 130 структур.
 А дальше в докладе много техники, как это устроено. Полная прозрачность, которая и есть основная цель OKR. Квартальный ритм, примерно месяц в начале квартала по нескольку часов в неделю у команды. Интегрирован с Agile, цели спринта должны быть позиционированы относительно OKR и на демо это показывают. Как планировать, как формулировать цели, и так далее - смотрите доклад, когда опубликуют.
@@ Строка 24: / Строка 24: @@
 [[Файл:TeamLeadConf-2019-p3.jpg|400px|right]]
-'''[https://www.facebook.com/photo.php?fbid=2142973502426259&set=a.660825517307739&type=3 Как измерить производительность программиста? Yuliya Kurapatenkava из Spotify]'''. Небольшая завязка о том, что 2.5 года она услышала от разработчика, что для него "деньги - не мотивация, хочу стать senior". И тогда это вошло в диссонанс с тем, что учили института и что говорила мама об устройстве мира, она начала смотреть исследования и узнала, что есть точка перегиба, уровень, по достижению которого влияние материальной мотивации существенно падает. И надо строить мотивацию по-другому. В вопросах было - как уровень перегиба выявлять, потому что он - разный. Они это определяют.
+[https://www.facebook.com/photo.php?fbid=2142973502426259&set=a.660825517307739&type=3 Пост на FB]: '''Как измерить производительность программиста? Yuliya Kurapatenkava из Spotify]'''. Небольшая завязка о том, что 2.5 года она услышала от разработчика, что для него "деньги - не мотивация, хочу стать senior". И тогда это вошло в диссонанс с тем, что учили института и что говорила мама об устройстве мира, она начала смотреть исследования и узнала, что есть точка перегиба, уровень, по достижению которого влияние материальной мотивации существенно падает. И надо строить мотивацию по-другому. В вопросах было - как уровень перегиба выявлять, потому что он - разный. Они это определяют.
 А дальше был рассказ про устройство круга роста разработчиков (на фото).
@@ Строка 48: / Строка 48: @@
 ==Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy из Badoo==
-'''[https://www.facebook.com/mtsepkov/posts/2142993122424297 Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy Badoo]'''. Работа по срокам, их оценка и умение отслеживать - крутейший инструмент развития разработчиков. Сроки - на полном цикле, не отдать в QA, а когда код на проде начал наносить непоправимую пользу. А в чем в этой схеме роль тимлида? Он становится тренером, как спортивный тренер - он не играет вместо игроков. Вопрос - зачем это разработчику? А именно за тем, что они становятся способными решить задачу целиком, а не свой кусок, получают новые области для развития. Они порождают инженеров, которые умеют решать задачи из программистов, которые умеют только писать код. Не все хотят играть в эту игру, во-первых, нужны soft skill, и нужна адаптация людей.
+[https://www.facebook.com/mtsepkov/posts/2142993122424297 Пост на FB]: '''Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy Badoo]'''. Работа по срокам, их оценка и умение отслеживать - крутейший инструмент развития разработчиков. Сроки - на полном цикле, не отдать в QA, а когда код на проде начал наносить непоправимую пользу. А в чем в этой схеме роль тимлида? Он становится тренером, как спортивный тренер - он не играет вместо игроков. Вопрос - зачем это разработчику? А именно за тем, что они становятся способными решить задачу целиком, а не свой кусок, получают новые области для развития. Они порождают инженеров, которые умеют решать задачи из программистов, которые умеют только писать код. Не все хотят играть в эту игру, во-первых, нужны soft skill, и нужна адаптация людей.
 Я от себя отмечу, что умение работать со сроками и подобные soft skill - это горизонтальная планка для T-shape людей. То есть в идеале, конечно, она достаточно жирненькая горизонтальная палочка, у некоторых превращающаяся в ножку, но практически фишка именно в том, чтобы процессы позволяли держать правильный баланс.
@@ Строка 79: / Строка 79: @@
 ==Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза==
-'''[https://www.facebook.com/mtsepkov/posts/2144397808950495 Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза]'''. Заметки с доклада.
+[https://www.facebook.com/mtsepkov/posts/2144397808950495 Пост на FB]: '''Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза]'''. Заметки с доклада.
 Коммуникация просто на основе опыта не слишком конструктивна: у разных людей - разный опыт, и они слабо сравнимы. А вот когда мы переводим опыт в ценности и смыслы, то коммуникация возможна и конструктивна, их можно соотносить.
@@ Строка 115: / Строка 115: @@
 ==Во имя нового продукта. Евгений Россинский==
-'''[https://www.facebook.com/mtsepkov/posts/2144727402250869 Во имя нового продукта. Евгений Россинский]''' год назад рассказывал о том, как ivi из функциональных подразделений к Value Stream команды выпуска конечного продукта. А в этом году у них встала задача существенно переписать весь продукт с изменением архитектуры, чтобы обеспечить новые возможности бизнеса, в частности повсеместное управление общей рекомендательной системой и переход на дизайн-систему при том, что платформенно-независимые стеки им не подходят. Они попробовали ее сделать, сохранив value stream - оно не получилось, потому что зоны ответственности за продукт по value stream не делятся, коммуникации когда делаем новый продукт нужны функциональные, синхронизация рассыпалась. Они провели большую ретроспективу, выявили много боли. В том числе, связанной с тем, что для разработки нового продукта нужно тщательное архитектурное проектирование и документирование. И в результате поняли, что value stream хорош по развитию готового приложения, но плох для разработки с нуля. В результате они вернулись к функциональному подразделению компании. При этом, естественно, вернулись все боли, которые ранее полечил value stream и, более того, местами пришлось перейти на ручное управление доработкой старого продукта - полностью остановить ее было невозможно. А еще возник дефицит ответственных архитекторов, оказалось, что хотя многие разработчики мечтали про рефакторинг, далеко не все идеи рефакторинга оказались рабочими. Это компенсировали подключением QA, которые обеспечивали детализацию постановок до нужного уровня и консультации по ним - сделали Летучие отряды возмездия. В целом, начав в апреле они к октябрю сделали основные релизы. И после этого - снова вернулись к value stream, к январю к ним вернулись. В целом был большой стресс, но они справились, горды результатом и постепенно переходят в себя. В целом очень интересная динамика развития.
+[https://www.facebook.com/mtsepkov/posts/2144727402250869 Пост на FB]: '''Во имя нового продукта. Евгений Россинский]''' год назад рассказывал о том, как ivi из функциональных подразделений к Value Stream команды выпуска конечного продукта. А в этом году у них встала задача существенно переписать весь продукт с изменением архитектуры, чтобы обеспечить новые возможности бизнеса, в частности повсеместное управление общей рекомендательной системой и переход на дизайн-систему при том, что платформенно-независимые стеки им не подходят. Они попробовали ее сделать, сохранив value stream - оно не получилось, потому что зоны ответственности за продукт по value stream не делятся, коммуникации когда делаем новый продукт нужны функциональные, синхронизация рассыпалась. Они провели большую ретроспективу, выявили много боли. В том числе, связанной с тем, что для разработки нового продукта нужно тщательное архитектурное проектирование и документирование. И в результате поняли, что value stream хорош по развитию готового приложения, но плох для разработки с нуля. В результате они вернулись к функциональному подразделению компании. При этом, естественно, вернулись все боли, которые ранее полечил value stream и, более того, местами пришлось перейти на ручное управление доработкой старого продукта - полностью остановить ее было невозможно. А еще возник дефицит ответственных архитекторов, оказалось, что хотя многие разработчики мечтали про рефакторинг, далеко не все идеи рефакторинга оказались рабочими. Это компенсировали подключением QA, которые обеспечивали детализацию постановок до нужного уровня и консультации по ним - сделали Летучие отряды возмездия. В целом, начав в апреле они к октябрю сделали основные релизы. И после этого - снова вернулись к value stream, к январю к ним вернулись. В целом был большой стресс, но они справились, горды результатом и постепенно переходят в себя. В целом очень интересная динамика развития.
 ==Методология как конструктор: инструкция по сборке. Филипп Дельгядо==
-'''[https://www.facebook.com/mtsepkov/posts/2144746365582306 Методология как конструктор: инструкция по сборке. Филипп Дельгядо]''' начал с цитаты: "Все методологии основаны на страхе: вы боитесь чего-либо, и делаете методологию, чтобы этих страхов избежать" - Кент Бек
+[https://www.facebook.com/mtsepkov/posts/2144746365582306 Пост на FB]: '''Методология как конструктор: инструкция по сборке. Филипп Дельгядо]''' начал с цитаты: "Все методологии основаны на страхе: вы боитесь чего-либо, и делаете методологию, чтобы этих страхов избежать" - Кент Бек
 Человек, который может полгода делать отчеты и не сойти с ума - редкая компетенция :)
@@ Строка 149: / Строка 149: @@
 ==Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров==
-'''[https://www.facebook.com/mtsepkov/posts/2144941355562807 Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров]'''. Рассказ о том, с чего начать новому руководителю. Надо составить профиль сотрудников и профиль проблем внутри и снаружи.
+[https://www.facebook.com/mtsepkov/posts/2144941355562807 Пост на FB]: '''Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров]'''. Рассказ о том, с чего начать новому руководителю. Надо составить профиль сотрудников и профиль проблем внутри и снаружи.
 Системно, с деталями, например, про базовые качества:

← Предыдущая		Версия 21:13, 5 апреля 2019
Строка 168:		Строка 168:
	Про проблемы лучше начать с новичков - они еще не привыкли к проблемным местам. Начинать лучше с проблем команды, а не бизнеса - иначе тебя воспримут не как тимлида, а воспримут как kpi-менеджеру.		Про проблемы лучше начать с новичков - они еще не привыкли к проблемным местам. Начинать лучше с проблем команды, а не бизнеса - иначе тебя воспримут не как тимлида, а воспримут как kpi-менеджеру.

−	[[Категория:Конференции]]	+	<noinclude>[[Категория:Конференции]]</noinclude>

← Предыдущая		Версия 20:45, 5 апреля 2019
Строка 1:		Строка 1:
−	Конференция [http://teamleadconf.ru TeamLeadConf] первый раз прошла всего год назад в Москве и сразу оказалась очень интересной, содержательной и востребованной (мой отчет [[TeamLeadConf-2018]]). В сентябре она была в Петербурге (мой отчет [[TeamLeadConf-2018-Spb]]), а в феврале - снова в Москве и собрала сильно больше тысячи участников. Потому что конференция реально представляет передний край управления командами в IT, и это - актуально.	+	Конференция [http://teamleadconf.ru '''TeamLeadConf'''] первый раз прошла всего год назад в Москве и сразу оказалась очень интересной, содержательной и востребованной (мой отчет [[TeamLeadConf-2018]]). В сентябре она была в Петербурге (мой отчет [[TeamLeadConf-2018-Spb]]), а в феврале - снова в Москве и собрала сильно больше тысячи участников. Потому что конференция реально представляет передний край управления командами в IT, и это - актуально.

	[[Файл:TeamLeadConf-2019-p1.jpg\|400px\|right]][[Файл:TeamLeadConf-2019-p2.jpg\|400px\|right]]		[[Файл:TeamLeadConf-2019-p1.jpg\|400px\|right]][[Файл:TeamLeadConf-2019-p2.jpg\|400px\|right]]

← Предыдущая		Версия 20:40, 5 апреля 2019
Строка 160:		Строка 160:
	Про проблемы лучше начать с новичков - они еще не привыкли к проблемным местам. Начинать лучше с проблем команды, а не бизнеса - иначе тебя воспримут не как тимлида, а воспримут как kpi-менеджеру.		Про проблемы лучше начать с новичков - они еще не привыкли к проблемным местам. Начинать лучше с проблем команды, а не бизнеса - иначе тебя воспримут не как тимлида, а воспримут как kpi-менеджеру.

−	[Категория:Конференции]]	+	[[Категория:Конференции]]

@@ Строка 5: / Строка 5: @@
 Я выступал с докладом '''[[Модели softskill для тимлида (TeamLeadConf-2019)|Модели softskill для тимлида]]''', в которой был обзор разных моделей, которые полезно знать: типов личности MBTI, командных ролей Белбина, типов менеджмента по Адизесу вместе с его жизненным циклом компании, ситуационного лидерства в двух вариантах, развития команд Такмана, краткий обзор развития моделей мотивации, включая нейрофизиологическую модель Хелен Фишер и модель ценностей Спиральной динамики. Но основная цель - показать, что модели - достаточно зрелые и формальные, чтобы их стоило использовать, подобно тому, как разработку стоит вести на фреймворках.
-А теперь - о докладах. Только надо отметить ([https://www.facebook.com/mtsepkov/posts/2145067115550231 пост]), что я был далеко не на всех докладах, на ряде слотов приходилось разрываться между желаниями, а часть докладов я пропустил, делая свой и участвуя вчера в митапе по управлению знаниями, посвященному новой [http://KnowledgeConf.ru #KnowledgeConf] (26.04 в Москве), которая обещает быть очень интересной - это я уже пишу как член ПК, отбиравший доклады. О ней же я рассказывал в интервью RadioQA (второе фото). Но доклады будут доступны в записи, а хорошее общение - бесценно.
+А теперь - о докладах. Только надо отметить ([https://www.facebook.com/mtsepkov/posts/2145067115550231 пост]), что я был далеко не на всех докладах, на ряде слотов приходилось разрываться между желаниями, а часть докладов я пропустил, делая свой и участвуя вчера в митапе по управлению знаниями, посвященному новой [http://KnowledgeConf.ru '''#KnowledgeConf'''] ('''26.04''' в Москве), которая обещает быть очень интересной - это я уже пишу как член ПК, отбиравший доклады. О ней же я рассказывал в интервью RadioQA (второе фото). Но доклады будут доступны в записи, а хорошее общение - бесценно.
 '''[https://www.facebook.com/mtsepkov/posts/2142958265761116 OKR: инструкция по применению. Егор Толстой]'''. Это - действительно инструкция. Лет 10-15 назад доклады подобного уровня были на тему, как внедрить task tracker или continious integration. Вопрос "зачем" при этом ставится слабо - об этом есть книги, и это уже в культуре. И по отношению task tracker и CI тогда, и OKR сейчас. С моей точки зрения, это - сдвиг. При этом и тогда и сейчас это в культуре не у всех, а на фронтире, но предполагается, что интересующимся - google и книги в помощь. Ну или другие, более ранние доклады, в которых это рассматривалось. При этом контекст назначения и окружения в докладе присутствует: речь идет о компании, состоящей из зрелых самодвижущихся команд, у которых есть миссия, долгосрочные цели и направления работы, так что вопрос "зачем мы здесь собрались" понятен, и "зарабатывать деньги" ответом не является. И дальше нужен инструмент, как сделать, чтобы команду не штормило, чтобы на поставленных целях удерживался фокус, как обеспечить интеграцию движения отдельных команд в движение компании в целом, при поставленных общих миссии и целях компании, и как обеспечить координацию между командами. Вот для этого - ORK, который Google адаптировал под культуру IT, в частности - отвязал от денег, это супер-важно. И Андрей Емельянов, который в Авито это первым внедрял в своей команде ездил в google знакомиться с опытом из первоисточника. Что интересно, OKR внедрялся с одной команды, а не сверху по компании. Потом - подключение смежных команд со связанными целями. И только после этого - масштаб на компанию в целом. Сейчас, спустя 3 года, у них к этой системе подключено 130 структур.

@@ Строка 1: / Строка 1: @@
 Конференция [http://teamleadconf.ru TeamLeadConf] первый раз прошла всего год назад в Москве и сразу оказалась очень интересной, содержательной и востребованной (мой отчет [[TeamLeadConf-2018]]). В сентябре она была в Петербурге (мой отчет [[TeamLeadConf-2018-Spb]]), а в феврале - снова в Москве и собрала сильно больше тысячи участников. Потому что конференция реально представляет передний край управления командами в IT, и это - актуально.
 Я выступал с докладом '''[[Модели softskill для тимлида (TeamLeadConf-2019)|Модели softskill для тимлида]]''', в которой был обзор разных моделей, которые полезно знать: типов личности MBTI, командных ролей Белбина, типов менеджмента по Адизесу вместе с его жизненным циклом компании, ситуационного лидерства в двух вариантах, развития команд Такмана, краткий обзор развития моделей мотивации, включая нейрофизиологическую модель Хелен Фишер и модель ценностей Спиральной динамики. Но основная цель - показать, что модели - достаточно зрелые и формальные, чтобы их стоило использовать, подобно тому, как разработку стоит вести на фреймворках.
-А теперь - о докладах. Только надо отметить ([https://www.facebook.com/mtsepkov/posts/2145067115550231 пост]), что я был далеко не на всех докладах, на ряде слотов приходилось разрываться между желаниями, а часть докладов я пропустил, делая свой и участвуя вчера, участвуя в митапе по управлению знаниями, посвященному новой #KnowledgeConf Но доклады будут доступны в записи, а хорошее общение - бесценно.
+А теперь - о докладах. Только надо отметить ([https://www.facebook.com/mtsepkov/posts/2145067115550231 пост]), что я был далеко не на всех докладах, на ряде слотов приходилось разрываться между желаниями, а часть докладов я пропустил, делая свой и участвуя вчера в митапе по управлению знаниями, посвященному новой [http://KnowledgeConf.ru #KnowledgeConf] (26.04 в Москве), которая обещает быть очень интересной - это я уже пишу как член ПК, отбиравший доклады. О ней же я рассказывал в интервью RadioQA (второе фото). Но доклады будут доступны в записи, а хорошее общение - бесценно.
 '''[https://www.facebook.com/mtsepkov/posts/2142958265761116 OKR: инструкция по применению. Егор Толстой]'''. Это - действительно инструкция. Лет 10-15 назад доклады подобного уровня были на тему, как внедрить task tracker или continious integration. Вопрос "зачем" при этом ставится слабо - об этом есть книги, и это уже в культуре. И по отношению task tracker и CI тогда, и OKR сейчас. С моей точки зрения, это - сдвиг. При этом и тогда и сейчас это в культуре не у всех, а на фронтире, но предполагается, что интересующимся - google и книги в помощь. Ну или другие, более ранние доклады, в которых это рассматривалось. При этом контекст назначения и окружения в докладе присутствует: речь идет о компании, состоящей из зрелых самодвижущихся команд, у которых есть миссия, долгосрочные цели и направления работы, так что вопрос "зачем мы здесь собрались" понятен, и "зарабатывать деньги" ответом не является. И дальше нужен инструмент, как сделать, чтобы команду не штормило, чтобы на поставленных целях удерживался фокус, как обеспечить интеграцию движения отдельных команд в движение компании в целом, при поставленных общих миссии и целях компании, и как обеспечить координацию между командами. Вот для этого - ORK, который Google адаптировал под культуру IT, в частности - отвязал от денег, это супер-важно. И Андрей Емельянов, который в Авито это первым внедрял в своей команде ездил в google знакомиться с опытом из первоисточника. Что интересно, OKR внедрялся с одной команды, а не сверху по компании. Потом - подключение смежных команд со связанными целями. И только после этого - масштаб на компанию в целом. Сейчас, спустя 3 года, у них к этой системе подключено 130 структур.
@@ Строка 17: / Строка 19: @@
 * Бесит цель, которую я не знаю, что не выполню. Надо сменить парадигму, от синдрома отличника избавляемся. Но цели в целом достижимые
 * Цели не спускаются сверху, а вырабатываются командой - сопричастность, плюс понимание реальной зоны.
 '''[https://www.facebook.com/photo.php?fbid=2142973502426259&set=a.660825517307739&type=3 Как измерить производительность программиста? Yuliya Kurapatenkava из Spotify]'''. Небольшая завязка о том, что 2.5 года она услышала от разработчика, что для него "деньги - не мотивация, хочу стать senior". И тогда это вошло в диссонанс с тем, что учили института и что говорила мама об устройстве мира, она начала смотреть исследования и узнала, что есть точка перегиба, уровень, по достижению которого влияние материальной мотивации существенно падает. И надо строить мотивацию по-другому. В вопросах было - как уровень перегиба выявлять, потому что он - разный. Они это определяют.