Кратко о докладе Константина Волкова.
Мой пересказ)
Переговоры способом - Конструктивной конфроктации.
Часто мы приходим на переговоры с решением. Сложно разнести проблему и решение. Переговоры могут занимать около часа. Оказывается можно уложиться быстрее - "семисекундная точка согласия". И она точно есть. Представьте, что можно достичь согласия за 7 секунд!
Это очень короткий срок. Как? С помощью мысли, которая должна быть высказана предельно ясно, ничего лишнего, вырезать лишние слова, каждое слово должно быть подобрано идеально.
Подготовка нужна!
Люди практически никогда не готовятся к переговорам. Вы знаете, что предстоит тяжёлый разговор, но вы не готовитесь. Например, самый сложный кейс у меня занял 8 часов, 3 часа подготовка с консультантом, и 5 часов изусение нюансов. Это был разговор "последний шанс", перед увольнением человека. Мы сохранили хорошие отношения с этим человеком и хорошие отношения внутри компании. Уважение основа!
Уважительный разговор одинаково зеркалит на обоих собеседников.
Нужно готовиться обоим сторонам. Если конечно другая сторона не готова, 50% успеха у вас есть за счёт вашей подготовки.
Что делать?
Определяем - Ваши цели и проблемы.
Узнаем - И цели и проблемы собеседника.
Нужно искать пересечение. И мы обычно не интересуемся целями собеседника.
Если спрашивать "чего же ты хочешь на самом деле?" Чаще всего мы услышим искренний ответ.
Когда вы не попадаете в цель собеседника, он вас даже не слышит, как в сказке три девицы под окном... Мы все помним про "родить богатыря", про предложения двух других не помним. Если мы скажите, то что нужно, ваш собеседник скажет сразу да!
Все разговоры имеют цель. Даже бесполезные митинги. Если вы начнёте говорить о цели, то ваши разговоры станут более конструктивными.
Чего хотел кресный отец в фильме?
Дружбу. Для него важны связи и они его волнуют. Кресный отец принимает дружбу. Попадание в метку цели - открывает для вас пространство новых решений, которые изначально были недоступны.
Программисты - проблемный народ. Даёшь им деньги, условия, они всё равно выгорают. Что делать?)
А если спросить у программиста?
Ответ - дайте спокойно поработать, не мешайте!
Все инженеры мечтают делать успешные проекты. Отсюда - тренд - успешный успех.
Достичь успеха очень просто - обмани, укради, но успешный успех недолговечен.
Адизес нас говорит - нужно добиваться устойчего успеха, который ты каждый день можешь воспроизводить. Его можно добиться комплементарной командой.
Самая распространённая команда - семья, муж и жена. Залог успешной командной работы это участие каждого участника, комплементарность.
Самое сложное - договориться.
Ещё и сложным людям о сложном, сложно договориться.
Залог успеха такой команды - это взаимное уважение.
Иерархия потребностей специалистов. Самый верх это вовлеченность, где-то в середине личное развитие. И всё построено на личном уважение друг к другу. Какое уважение в компаниях, когда руководители говорят вот выйдет новый chatgpt и мы просто всех уволим!
Нужно создавать взаимное уважение с безопасной средой - это залог обучения и развития.
Тренируемся в общение!)
#CodeFest14 #уважение #доклад
Мой пересказ)
Переговоры способом - Конструктивной конфроктации.
Часто мы приходим на переговоры с решением. Сложно разнести проблему и решение. Переговоры могут занимать около часа. Оказывается можно уложиться быстрее - "семисекундная точка согласия". И она точно есть. Представьте, что можно достичь согласия за 7 секунд!
Это очень короткий срок. Как? С помощью мысли, которая должна быть высказана предельно ясно, ничего лишнего, вырезать лишние слова, каждое слово должно быть подобрано идеально.
Подготовка нужна!
Люди практически никогда не готовятся к переговорам. Вы знаете, что предстоит тяжёлый разговор, но вы не готовитесь. Например, самый сложный кейс у меня занял 8 часов, 3 часа подготовка с консультантом, и 5 часов изусение нюансов. Это был разговор "последний шанс", перед увольнением человека. Мы сохранили хорошие отношения с этим человеком и хорошие отношения внутри компании. Уважение основа!
Уважительный разговор одинаково зеркалит на обоих собеседников.
Нужно готовиться обоим сторонам. Если конечно другая сторона не готова, 50% успеха у вас есть за счёт вашей подготовки.
Что делать?
Определяем - Ваши цели и проблемы.
Узнаем - И цели и проблемы собеседника.
Нужно искать пересечение. И мы обычно не интересуемся целями собеседника.
Если спрашивать "чего же ты хочешь на самом деле?" Чаще всего мы услышим искренний ответ.
Когда вы не попадаете в цель собеседника, он вас даже не слышит, как в сказке три девицы под окном... Мы все помним про "родить богатыря", про предложения двух других не помним. Если мы скажите, то что нужно, ваш собеседник скажет сразу да!
Все разговоры имеют цель. Даже бесполезные митинги. Если вы начнёте говорить о цели, то ваши разговоры станут более конструктивными.
Чего хотел кресный отец в фильме?
Дружбу. Для него важны связи и они его волнуют. Кресный отец принимает дружбу. Попадание в метку цели - открывает для вас пространство новых решений, которые изначально были недоступны.
Программисты - проблемный народ. Даёшь им деньги, условия, они всё равно выгорают. Что делать?)
А если спросить у программиста?
Ответ - дайте спокойно поработать, не мешайте!
Все инженеры мечтают делать успешные проекты. Отсюда - тренд - успешный успех.
Достичь успеха очень просто - обмани, укради, но успешный успех недолговечен.
Адизес нас говорит - нужно добиваться устойчего успеха, который ты каждый день можешь воспроизводить. Его можно добиться комплементарной командой.
Самая распространённая команда - семья, муж и жена. Залог успешной командной работы это участие каждого участника, комплементарность.
Самое сложное - договориться.
Ещё и сложным людям о сложном, сложно договориться.
Залог успеха такой команды - это взаимное уважение.
Иерархия потребностей специалистов. Самый верх это вовлеченность, где-то в середине личное развитие. И всё построено на личном уважение друг к другу. Какое уважение в компаниях, когда руководители говорят вот выйдет новый chatgpt и мы просто всех уволим!
Нужно создавать взаимное уважение с безопасной средой - это залог обучения и развития.
Тренируемся в общение!)
#CodeFest14 #уважение #доклад
Текущая культура микросервисов провоцирует зоопарк технологий. Каждый участник команды хочет применить свою технологию, и мы говорим, не проблема, давай. И тогда приходится поддерживать весь процесс - написания, поддержки и итог, микросервис перестаёт быть простым.
Распределенная систем это микросервис, сделать хороший интеграционный тест невозможно, для таких систем. Мы пишем как бы это протестировать, но это не бесплатно.
Ещё мы думаем, что программист инженер с высшим образованием, он же умный и он любой трюк может поддержать. Но это не так, мы можем определять только те смыслы, которые годами сформировались. А вот у нас новое, а человек годами с монолитом работал. И для нового ему нужны месяцы - чтобы разобраться, и годы чтобы начать работать.
Микросервисы не прощают плохие архитектурные решения, хаки, растёт тех долг. Не можем копит тех долг, может возникнуть ситуация, когда через пару недель не будет работать наш микросервис.
Микросервисы - это круто! Нам дали деньги и залили на миллионы рпс, проекты ценой огромных инвестиций в том числе в обучение людей. Как мы с этим кодом будем работать - это проблема. В огромных компаниях оно хорошо работает. И вот нам говорят, давайте сделаем микросервисы, но распил монолита не будет проще. Микросервисы не могут быть заменой монолита, ибо добавляют новый уровень сложности. Например, Вася говно кодил в монолит, и потом всё встало, а в микросервисах можно их изолировать. Микросервисы вот оно круто. Да, но нет.
Проблема сложности ПО. Когда выбираем архитектору, языки, тулинги, это все не бесплатно. Наш мозг это не бесплатно и нужно время чтобы научиться думать о больших штуках.
В монолите есть архитектурные границы. Культура в микросервисах, та что есть сейчас не даёт нам простоту.
Код стоит писать так, чтобы он рассказывал историю без вас, как суфлера. Если вы думаете нужны ли вам стандарты создания кода - нужны, делайте!
Нужен большой опыт тим лидов и архитекторов.
Когнитивная сложность монолита и микросервисов разная для сеньора и джуна.
#CodeFest14 #микросервисы #доклад #ГригорийПетров
Распределенная систем это микросервис, сделать хороший интеграционный тест невозможно, для таких систем. Мы пишем как бы это протестировать, но это не бесплатно.
Ещё мы думаем, что программист инженер с высшим образованием, он же умный и он любой трюк может поддержать. Но это не так, мы можем определять только те смыслы, которые годами сформировались. А вот у нас новое, а человек годами с монолитом работал. И для нового ему нужны месяцы - чтобы разобраться, и годы чтобы начать работать.
Микросервисы не прощают плохие архитектурные решения, хаки, растёт тех долг. Не можем копит тех долг, может возникнуть ситуация, когда через пару недель не будет работать наш микросервис.
Микросервисы - это круто! Нам дали деньги и залили на миллионы рпс, проекты ценой огромных инвестиций в том числе в обучение людей. Как мы с этим кодом будем работать - это проблема. В огромных компаниях оно хорошо работает. И вот нам говорят, давайте сделаем микросервисы, но распил монолита не будет проще. Микросервисы не могут быть заменой монолита, ибо добавляют новый уровень сложности. Например, Вася говно кодил в монолит, и потом всё встало, а в микросервисах можно их изолировать. Микросервисы вот оно круто. Да, но нет.
Проблема сложности ПО. Когда выбираем архитектору, языки, тулинги, это все не бесплатно. Наш мозг это не бесплатно и нужно время чтобы научиться думать о больших штуках.
В монолите есть архитектурные границы. Культура в микросервисах, та что есть сейчас не даёт нам простоту.
Код стоит писать так, чтобы он рассказывал историю без вас, как суфлера. Если вы думаете нужны ли вам стандарты создания кода - нужны, делайте!
Нужен большой опыт тим лидов и архитекторов.
Когнитивная сложность монолита и микросервисов разная для сеньора и джуна.
#CodeFest14 #микросервисы #доклад #ГригорийПетров
Мнообразие ТимЛидов.
Евгений Антонов.
Инфраструктура Яндекса.
Шизо вакансии - на 80% писать код и на 80% быть тим лидом, на 80% (?..)
Где-то продакт, где-то аналитик, где-то тестировщик, где-то релиз инженер...
И всё это играющий тренер. Всё это приводит к овертаймам. Код пописал, а вечером на выходных заняться процессами. Это безумие и выгорание, ты искреннее стараешься, но всё хуже и хуже справляешься.
Демотивация ответственного за мотивацию.
Что делать?
Уменьшить скоуп
Или уменьшить качество.
Задать себе вопрос, что нравится делать, куда готовы расти и развиваться?
Адизес описал график жизни компании.
Вы приходите в компанию на опреденном этапе жизни этой компании.
Предлагаю - 4 стадии, которые могут случиться:
✅Сбор команды
✅Поддержка текущей команды
✅Развитие команды
✅Кризис
4 вида тим лидов :
Создающий бизнес, чтобы он заработал.
Из оффлайн, например, переход в онлайн и ничего нет, надо построить с нуля.
Кажется, если ты создаёшь с нуля нужно много уметь. Тут предлагаю срезать качество. Например, Хотим бегать, можно и не покупать спец вещи, берём что есть и побежали. Для новых команд нужно, как можно быстрее создаться. Нужны навыки найма и знания, как какие процессы найма работают. Делать простые супер капитанские вещи.
Люди - 4 стадии формирования команды. Притирка в команде. Сделать так, чтобы команда не развалилась - задача тим лида.
Что делать с архитектурой?
Набирая команду, берете норм экспертов. Уметь привлекать внешний консалтинг. Я знаю того мужика, который знает.
Поддерживающий.
Команда уже есть, надо приходить и немного пинать. Тут проще, команда есть. Достаётся чаще всего, то что уже работает или можно свалить на предыдущего тим лида, если что-то не так.
Нужна дисциплина. Кто-то думал, что будет тим Лидом, но он не стал. Или кто-то хочет что-то пропихнуть.
Сознательность.
Зашли, посмотрели, опросили, сознательное внедрение, а не переламывание через хребет. Учится делегировать, чтобы команда работала без вас, вклад в долгосрочность команды.
Администратор - склонность к административности.
Если у вас каждая снежинка летает, там где она хочет)
Простая точка входа в тим лидерство.
Развивающий
Кажется нужен широкий кругозор при быстром росте команды. Либо срезать скоуп, либо срезать качество. Качество на больших масштабах нельзя срезать.
Всех нанял, выгорел и уволился.
Знание релевантной области необходимо.
Продвинутый уровень рекрутинга и делигирования. Стандарт междукомандного взаимодействия.
Долгосрочное планирование.
Антикризисный
Все поругались, сложные процессы. Нужны быстрые и жёсткие решения. Невозможно решить проблему поцелуями во все места, по любому кто-то будет недоволен.
Нужно уметь микроменеджерить (тут можно!)
Тушить сейчас нужно уметь.
Чёрный пояс по увольнению.
Управлять рисками и быть к ним готовым, они 100% случаться и вас затронут. Не будет лёгкого безболезненного труда.
Лидерские качества (сериал Тед Лассо).
Коммуникация - не только поговорить, но и под ковром разбираться в корпоративной политике. Хотеть и уметь разбираться в политике.
Будьте хорошим тим лидом, а плохим не будьте)
#CodeFest14 #типыТимЛидов #доклад
Евгений Антонов.
Инфраструктура Яндекса.
Шизо вакансии - на 80% писать код и на 80% быть тим лидом, на 80% (?..)
Где-то продакт, где-то аналитик, где-то тестировщик, где-то релиз инженер...
И всё это играющий тренер. Всё это приводит к овертаймам. Код пописал, а вечером на выходных заняться процессами. Это безумие и выгорание, ты искреннее стараешься, но всё хуже и хуже справляешься.
Демотивация ответственного за мотивацию.
Что делать?
Уменьшить скоуп
Или уменьшить качество.
Задать себе вопрос, что нравится делать, куда готовы расти и развиваться?
Адизес описал график жизни компании.
Вы приходите в компанию на опреденном этапе жизни этой компании.
Предлагаю - 4 стадии, которые могут случиться:
✅Сбор команды
✅Поддержка текущей команды
✅Развитие команды
✅Кризис
4 вида тим лидов :
Создающий бизнес, чтобы он заработал.
Из оффлайн, например, переход в онлайн и ничего нет, надо построить с нуля.
Кажется, если ты создаёшь с нуля нужно много уметь. Тут предлагаю срезать качество. Например, Хотим бегать, можно и не покупать спец вещи, берём что есть и побежали. Для новых команд нужно, как можно быстрее создаться. Нужны навыки найма и знания, как какие процессы найма работают. Делать простые супер капитанские вещи.
Люди - 4 стадии формирования команды. Притирка в команде. Сделать так, чтобы команда не развалилась - задача тим лида.
Что делать с архитектурой?
Набирая команду, берете норм экспертов. Уметь привлекать внешний консалтинг. Я знаю того мужика, который знает.
Поддерживающий.
Команда уже есть, надо приходить и немного пинать. Тут проще, команда есть. Достаётся чаще всего, то что уже работает или можно свалить на предыдущего тим лида, если что-то не так.
Нужна дисциплина. Кто-то думал, что будет тим Лидом, но он не стал. Или кто-то хочет что-то пропихнуть.
Сознательность.
Зашли, посмотрели, опросили, сознательное внедрение, а не переламывание через хребет. Учится делегировать, чтобы команда работала без вас, вклад в долгосрочность команды.
Администратор - склонность к административности.
Если у вас каждая снежинка летает, там где она хочет)
Простая точка входа в тим лидерство.
Развивающий
Кажется нужен широкий кругозор при быстром росте команды. Либо срезать скоуп, либо срезать качество. Качество на больших масштабах нельзя срезать.
Всех нанял, выгорел и уволился.
Знание релевантной области необходимо.
Продвинутый уровень рекрутинга и делигирования. Стандарт междукомандного взаимодействия.
Долгосрочное планирование.
Антикризисный
Все поругались, сложные процессы. Нужны быстрые и жёсткие решения. Невозможно решить проблему поцелуями во все места, по любому кто-то будет недоволен.
Нужно уметь микроменеджерить (тут можно!)
Тушить сейчас нужно уметь.
Чёрный пояс по увольнению.
Управлять рисками и быть к ним готовым, они 100% случаться и вас затронут. Не будет лёгкого безболезненного труда.
Лидерские качества (сериал Тед Лассо).
Коммуникация - не только поговорить, но и под ковром разбираться в корпоративной политике. Хотеть и уметь разбираться в политике.
Будьте хорошим тим лидом, а плохим не будьте)
#CodeFest14 #типыТимЛидов #доклад
Когда ввели такую практику, поняли много разных нюансов, например, что недостотаточно автотестов, не всё покрыто ими.
Пример из жизни.
Причина инцидента сломались скрипты, и тогда решили руками Билд выкладывать, и кое что отвалилось, оказывается просто тупой инцидент, я руками не тот файл выложил)
Релиз ничего не знает про фичи, всё что попало в релиз ветку, то и едет в релиз.
Охота на ведьм - культура компании позволяет нам адекватно подходить к работе. Если накосячил, то здоровая атмосфера от руководства и оно понимает, что есть всегда % инцидентов.
Считаем экономический эффект инцидента, это отдел аналитики, и это к Топ менеджерами, для анализа ситуации.
#CodeFest14 #релизы #доклад
Пример из жизни.
Причина инцидента сломались скрипты, и тогда решили руками Билд выкладывать, и кое что отвалилось, оказывается просто тупой инцидент, я руками не тот файл выложил)
Релиз ничего не знает про фичи, всё что попало в релиз ветку, то и едет в релиз.
Охота на ведьм - культура компании позволяет нам адекватно подходить к работе. Если накосячил, то здоровая атмосфера от руководства и оно понимает, что есть всегда % инцидентов.
Считаем экономический эффект инцидента, это отдел аналитики, и это к Топ менеджерами, для анализа ситуации.
#CodeFest14 #релизы #доклад
Верни мне мой, 2007!
На конференции в Новосибирске #CodeFest14 , месяц назад на закрытие было прекрасное выступление Александра Кирсанова.
Его выступление заставляет задуматься, таких олдов, как я)))
А куда мы катимся? А вообще насколько это нормально, в айти поперли гуманитарии, юристы, доктора? Айтишник теперь стал обзывательством и все хотят ими быть, как в 90-х все хотели быть экономистами и юристами. А кто нас вообще учить и лечить будет, если все уйдут в айти?
И во мне действительно постоянно борятся две Наташи, та что вложила огромное количество сил в инженерное образование, опыт реализации проектов, изучение технологий. И бузит, что теперь это не надо, и можно легко войти в айти?)))
И другая, которая такая, типа хочет идти в ногу со временем.
Александр в игровой форме доносить много скрытых смыслов в своём выступление, и даже спустя месяц, я понимаю, что есть о чем ещё подумать, поспорить, и переосмыслить, потому что мир раскручивается и изменяется быстрее, чем я.
Рекомендую к просмотру, уделите 45 минут своего времени 👀
Но помните, что потом можно зависнуть на долгое время осмысляя 🧠
#капитанНЕочевидность #верните2007
#доклад #мирвокруг #правдажизни
https://youtu.be/C-5ZEcK_E30?si=M2K6HfbeuwGkKKZs
На конференции в Новосибирске #CodeFest14 , месяц назад на закрытие было прекрасное выступление Александра Кирсанова.
Его выступление заставляет задуматься, таких олдов, как я)))
А куда мы катимся? А вообще насколько это нормально, в айти поперли гуманитарии, юристы, доктора? Айтишник теперь стал обзывательством и все хотят ими быть, как в 90-х все хотели быть экономистами и юристами. А кто нас вообще учить и лечить будет, если все уйдут в айти?
И во мне действительно постоянно борятся две Наташи, та что вложила огромное количество сил в инженерное образование, опыт реализации проектов, изучение технологий. И бузит, что теперь это не надо, и можно легко войти в айти?)))
И другая, которая такая, типа хочет идти в ногу со временем.
Александр в игровой форме доносить много скрытых смыслов в своём выступление, и даже спустя месяц, я понимаю, что есть о чем ещё подумать, поспорить, и переосмыслить, потому что мир раскручивается и изменяется быстрее, чем я.
Рекомендую к просмотру, уделите 45 минут своего времени 👀
Но помните, что потом можно зависнуть на долгое время осмысляя 🧠
#капитанНЕочевидность #верните2007
#доклад #мирвокруг #правдажизни
https://youtu.be/C-5ZEcK_E30?si=M2K6HfbeuwGkKKZs
YouTube
Александр Кирсанов. Раньше деревья были выше, а IT круче. Или нет?
Как далеко шагнуло программирование, имеет ли смысл сейчас оглядываться на инженеров прошлого века, чтить классику Дядюшки Боба и придерживаться устоявшихся паттернов? Попробуем ответить на эти и другие фундаментально-филосовские вопросы с помощью путешествия…
Немного конспектов с выступлений на #uicdev2024 #управление #доклад
Перестройка, перезапуск команд
Рогожников Максим, Т-банк
2022 осень, предложение перейти в команду и перезапустить и перестроить.
Создание из одной команды или множества команд, новой орг структуры.
Как понять, что пора перезапускать?
1.Когда одна большая команда 10-12 разработчиков и они знают всё. Они много держат контекста в голове, что-то точнее держать невозможно.
2.Никто не знает как сделать поставку в срок. Приходится собирать картину у команды. Никакого доверия и предсказания поставки.
3.Бизнес ставит запросы сделать всё!
4.Нет единого человека который бы отвечал за сервис.
Когда не надо перезапускать команду?
Когда бизнес счастлив, и его всё устраивает!
Если ваш продукт приносит доход, то вам не нужно делать перезапуск. Перестройка, это политический процесс, нужен спонсор изменения.
Варианты:
1.Джон Коттер - 8 шагов модель
Есть мультик, где мишка и айсберг. Что-то идёт не так, делаем команду реформаторов, куда идём и дальше по классике...
2. Adkar осознание, желание, знание, способность, закрепление результата.
Как соотносится с практикой?
Осознание проблемы.
VSM - event storming - визуально показать, как доставляется ценность поставки.
Коммуникации - связи людей в команде, кто лидер, скрытые лидеры, друзья, не друзья и т.д.
И как оно мапится на доставку ценности.
Перестройка - это политическое решение. Нужен спонсор, который доносит почему делаются изменения.
Команде говорим, что грядут изменения. Чем раньше начинается формирование реформаторов, которые лояльны к изменениям.
Куда двигаемся и как?
Зона ответственности команды. Как идёт поставка знаем и какие системы делаем, вот и получаем команду. Общение с лидером и формируются гипотезы проблем.
Архитектура - все её знает, но никто не рисует. С4, стикеры, миро - целевая картина, как что будет разделено и как будет развиваться, иначе комок грязи.
Иначе не получите нужных комитов.
Выбор как будет нарезана команда. Teams topology. Систем, сервисов, платформ и т.п.
Уровень ролей и людей. Какие роли нужны команде, чтобы поддерживать и развивать сервисы. Ролей хватало, чтобы выполнять весь функционал.
Backlog - как разделить на команды. Как в новые команды будет поступать бэклог задач. У кого-то много, у кого-то нет. Нужно управлять потоками задач.
Ритуалы - насколько хорошо решают поставленные задачи и цели. Можно посмотреть по VSM, scrum, kanban - нужно понимать какие минимально нужны ритуалы.
Распределение людей - разделить на команды людей. Какого уровня, кто и что должен делать.
Публичный этап - с 1 числа живём по новому! Сообщить людям и отвечать на вопросы. Куда и как движемся, стоит звать спонсора, который поможет.
Закрепление 1-2 месяца будет хаос, все захотят всё вернуть назад. Нужна команда реформаторов, которая отвечает на вопросы и помогать.
Собирать обратную связь-кто-то будет радоваться, кто-то будет хейтить. Постоянная история и мониторинг за тем, кто что хочет добавить, что работает, что нет.
Что в итоге?
Статистика, всё прекрасно! Но есть другие вещи. В новых командах будет фокус на команду, и сузится контекст, коммуникация будет хороша только внутри, между команд появятся проблема синхронизации, поставок и т.д. Новый пул проблем межкомандного взаимодействия.
Ссылка на презентацию - https://t.me/way_to_cto/6
Перестройка, перезапуск команд
Рогожников Максим, Т-банк
2022 осень, предложение перейти в команду и перезапустить и перестроить.
Создание из одной команды или множества команд, новой орг структуры.
Как понять, что пора перезапускать?
1.Когда одна большая команда 10-12 разработчиков и они знают всё. Они много держат контекста в голове, что-то точнее держать невозможно.
2.Никто не знает как сделать поставку в срок. Приходится собирать картину у команды. Никакого доверия и предсказания поставки.
3.Бизнес ставит запросы сделать всё!
4.Нет единого человека который бы отвечал за сервис.
Когда не надо перезапускать команду?
Когда бизнес счастлив, и его всё устраивает!
Если ваш продукт приносит доход, то вам не нужно делать перезапуск. Перестройка, это политический процесс, нужен спонсор изменения.
Варианты:
1.Джон Коттер - 8 шагов модель
Есть мультик, где мишка и айсберг. Что-то идёт не так, делаем команду реформаторов, куда идём и дальше по классике...
2. Adkar осознание, желание, знание, способность, закрепление результата.
Как соотносится с практикой?
Осознание проблемы.
VSM - event storming - визуально показать, как доставляется ценность поставки.
Коммуникации - связи людей в команде, кто лидер, скрытые лидеры, друзья, не друзья и т.д.
И как оно мапится на доставку ценности.
Перестройка - это политическое решение. Нужен спонсор, который доносит почему делаются изменения.
Команде говорим, что грядут изменения. Чем раньше начинается формирование реформаторов, которые лояльны к изменениям.
Куда двигаемся и как?
Зона ответственности команды. Как идёт поставка знаем и какие системы делаем, вот и получаем команду. Общение с лидером и формируются гипотезы проблем.
Архитектура - все её знает, но никто не рисует. С4, стикеры, миро - целевая картина, как что будет разделено и как будет развиваться, иначе комок грязи.
Иначе не получите нужных комитов.
Выбор как будет нарезана команда. Teams topology. Систем, сервисов, платформ и т.п.
Уровень ролей и людей. Какие роли нужны команде, чтобы поддерживать и развивать сервисы. Ролей хватало, чтобы выполнять весь функционал.
Backlog - как разделить на команды. Как в новые команды будет поступать бэклог задач. У кого-то много, у кого-то нет. Нужно управлять потоками задач.
Ритуалы - насколько хорошо решают поставленные задачи и цели. Можно посмотреть по VSM, scrum, kanban - нужно понимать какие минимально нужны ритуалы.
Распределение людей - разделить на команды людей. Какого уровня, кто и что должен делать.
Публичный этап - с 1 числа живём по новому! Сообщить людям и отвечать на вопросы. Куда и как движемся, стоит звать спонсора, который поможет.
Закрепление 1-2 месяца будет хаос, все захотят всё вернуть назад. Нужна команда реформаторов, которая отвечает на вопросы и помогать.
Собирать обратную связь-кто-то будет радоваться, кто-то будет хейтить. Постоянная история и мониторинг за тем, кто что хочет добавить, что работает, что нет.
Что в итоге?
Статистика, всё прекрасно! Но есть другие вещи. В новых командах будет фокус на команду, и сузится контекст, коммуникация будет хороша только внутри, между команд появятся проблема синхронизации, поставок и т.д. Новый пул проблем межкомандного взаимодействия.
Ссылка на презентацию - https://t.me/way_to_cto/6
Telegram
На пути к CTO
Сегодня я выступаю на UICDEV с рассказом о перезапуске команд.
Делюсь полезными ссылками из доклада:
STATIK
Карта потока ценности (Value Stream Mapping, VSM)
Event storming
Наш Айсберг тает. Джон Коттер
ADKAR
⢑⢆⢊⡉ ⠃⢂ ⣄⠜⠃⡡⢨⠬⡠⠍ ⡄⠘⠆⢰⢠⠔⡢⢠⠢⢘⠔ ⡠⡅⠋⡢⠕ ⠉⠱ ⡑⢒⡉⠡⡅…
Делюсь полезными ссылками из доклада:
STATIK
Карта потока ценности (Value Stream Mapping, VSM)
Event storming
Наш Айсберг тает. Джон Коттер
ADKAR
⢑⢆⢊⡉ ⠃⢂ ⣄⠜⠃⡡⢨⠬⡠⠍ ⡄⠘⠆⢰⢠⠔⡢⢠⠢⢘⠔ ⡠⡅⠋⡢⠕ ⠉⠱ ⡑⢒⡉⠡⡅…