Изменения

А теперь - о докладах. Только надо отметить ([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 структур.

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

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

* тенденции сотрудничества в code review. Все хотим code review. В метрике - как быстро делают (4-5 часов - долго), объем реинжиниринга и так далее.

'''[https://www.facebook.com/mtsepkov/posts/2142993122424297 Работа со сроками как часть инженерной культуры. Nikolay Krapivnyy Badoo]'''. Работа по срокам, их оценка и умение отслеживать - крутейший инструмент развития разработчиков. Сроки - на полном цикле, не отдать в QA, а когда код на проде начал наносить непоправимую пользу. А в чем в этой схеме роль тимлида? Он становится тренером, как спортивный тренер - он не играет вместо игроков. Вопрос - зачем это разработчику? А именно за тем, что они становятся способными решить задачу целиком, а не свой кусок, получают новые области для развития. Они порождают инженеров, которые умеют решать задачи из программистов, которые умеют только писать код. Не все хотят играть в эту игру, во-первых, нужны soft skill, и нужна адаптация людей.

'''Сергей Добриднюк''' А почему работа со сроками это soft skills ? Я думал самый что ни на есть hard skills. Анализ прецедентов, создание цепочек производство, работа по планированию и балансировке ресурсов, решение оптимизационной задачи классическими математическими методами.. Тут все инженерия и математика, а ни разу ни социология.. И такие проекты есть - например в авиации - скоп проекта может составлять миллионы работ, а в атомной отрасли - сроки до 20ти лет планируются. И что интересно - все отлично может попасть и в сроки, и в бюджеты

'''[https://www.facebook.com/mtsepkov/posts/2143054805751462 Ведение кросс-командных проектов. Павел Аксёнов из ozon]'''. Проблемы - понятны: много стейкхолдеров, разные инструменты ведения задач и документации у разных команд, координация планов, сквозное тестирование. Дальше был рассказ, как это все вести, со всякими приемчиками и техниками. На верхнем уровне абстракции все это известно давно, но вот арсенал инструментов - меняется, например, чатики - относительно свежий и до конца не отрефлексированный инструмент с точки зрения того, что именно в него выносить и как это влияет на остальное. Впрочем, этого в докладе не было. Рассказ был построен на основе их карточки ведения проектов. Многое - известно и понятно: примерный план проекта, протоколы встреч, бизнесовый чеклист запуска. Из интересного.

* Открытые вопросы по встречам. - они даже важнее чем план!

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

'''[https://www.facebook.com/mtsepkov/posts/2144397808950495 Развитие команды и рефлексия как управленческая коммуникация тимлида. Александр Зиза]'''. Заметки с доклада.

: '''Максим Цепков''' Ну, это есть разные психотерапевты, так же как разные юристы. Как в том анекдоте: приходит стажер к шефу и говорит "Я закончил дело этого клиента, все решил! - Ты идиот, этот клиент кормил нас 10 (20, 50) лет!"

'''[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/2144746365582306 Методология как конструктор: инструкция по сборке. Филипп Дельгядо]''' начал с цитаты: "Все методологии основаны на страхе: вы боитесь чего-либо, и делаете методологию, чтобы этих страхов избежать" - Кент Бек

: Филипп Дельгядо Ну, вообще можно заменить слово страх на "сильная негативная эмоция". Содержание не изменится, а вот читаться будет хуже. Все-таки доклады (и популярные книги) больше про "запоминаемость", чем про "корректность".

'''[https://www.facebook.com/mtsepkov/posts/2144941355562807 Как не потерять все полимеры, став руководителем в новой компании. Алексей Петров]'''. Рассказ о том, с чего начать новому руководителю. Надо составить профиль сотрудников и профиль проблем внутри и снаружи.