#MergeConf Юлия Черемохова из Skyeng. Провоцировать нельзя валидировать. Основной фокус доклада - про провокацию как способ перевести сотрудника в состояние "делаю то, что нужно компании" из состояния "у меня все нормально". Но первая часть была о способах поддержки сотрудника и валидации взаимодействия по нескольким уровням, начиная с валидацией присутствия и понимания и заканчивая самореализацией. Потому что провокация как инструмент констркутивна только при условии хорошего взаимодействия, а если отношения с сотрудником конфликтны, то провокация лишь усугубит ситуацию. Когда уместна провокация? Когда диагностика показывает, что у сотрудника не хватает ответственности, он приходит без результата и у него есть какие-то объяснения, которые он считает нормальными. Эту ситуацию надо отличать от ситуации, когда ожидаемый результат был невозможен или сомнителен, например, по тому, что задача была некорректна поставлена, например, вас просто неверно поняли, и это не верифицировали в момент постановки.
Есть три распространенные причины безответственности:
* Избегание: я код пишу, в совещаниях с заказчиком не участвую
* Беспомощность: не смог, не знал, мне не помогли
* Эффективная самореализация: делаем все что угодно, но не то что надо
В основе такого поведения лежат убеждения: что что-то - не мое дело, что мне должны помогать, что я делаю что хочу и компания должна приспособиться. Задача провокации - поколебать эти убеждения. Способ - придумать преимущество и довести до абсурда. Например, "конечно, ты не умеешь решать такие сложные задачи, и это - выгодно, мы не будем их тебе давать". Тут надо нащупать точку, где такое как бы присоединение к позиции будет конфликтовать с другими внутренними убеждениями, например, с тем, что все делают общее дело, или что сотрудник - профессионал, способный делать сложные задачи, поэтому такое доведение до абсурда вызовет у него внутренний протест. Но важно делать это корректно и лучше - с юмором. Задача - не уйти в конфликт, а пошатать эти убеждения, чтобы потом развернуть в желаемую сторону. В презентации и докладе были конкретные примеры.
Что я хочу отметить? Провокация - инструмент, который работает для детей. И то - ограничено. То, что он продолжает работать и для взрослых - фича современного мира. И тут несколько факторов. Если вспомнить времена трех мушкетеров или даже 19 век, то там за неудачную провокацию можно было получить дуэль с неясными последствиями, и это - останавливало. С детьми-то безопасно. И в компании руководитель чувствует относительную безопасность. А с другой стороны, реклама и политтехнологии активно используют инструменты манипуляции и провокации на различные действия - покупку товаров, поддержку нужных инициатив. И в этом причина, почему противостоять этому не учат в школе. Противостоять этому, кстати, достаточно просто - нужна уверенная самооценка, не зависшая от внешней похвалы. И методы обучения тоже есть, Анна Обухова рассказывает очень простой протокол авторизации результата, который служит именно для этого. Она его нашла в методичках педагогического университета имени Герцена для работы с детьми с отставанием в развитии. А вот при обучении обычных детей его не применяют. Почему? Есть версия, что класс, где все ученики им владеют, становится не управляемым для учителей и родителей - с ними можно взаимодействовать только из взрослой позиции, а система образования так не умеет. Но это уже - про исправление мира. Пока мы работаем в реальном мире, с теми людьми, которые в нем есть. И можно использовать их особенности для достижения рабочих задач. Помня про этику, но это отдельная не очевидная тема.
Есть три распространенные причины безответственности:
* Избегание: я код пишу, в совещаниях с заказчиком не участвую
* Беспомощность: не смог, не знал, мне не помогли
* Эффективная самореализация: делаем все что угодно, но не то что надо
В основе такого поведения лежат убеждения: что что-то - не мое дело, что мне должны помогать, что я делаю что хочу и компания должна приспособиться. Задача провокации - поколебать эти убеждения. Способ - придумать преимущество и довести до абсурда. Например, "конечно, ты не умеешь решать такие сложные задачи, и это - выгодно, мы не будем их тебе давать". Тут надо нащупать точку, где такое как бы присоединение к позиции будет конфликтовать с другими внутренними убеждениями, например, с тем, что все делают общее дело, или что сотрудник - профессионал, способный делать сложные задачи, поэтому такое доведение до абсурда вызовет у него внутренний протест. Но важно делать это корректно и лучше - с юмором. Задача - не уйти в конфликт, а пошатать эти убеждения, чтобы потом развернуть в желаемую сторону. В презентации и докладе были конкретные примеры.
Что я хочу отметить? Провокация - инструмент, который работает для детей. И то - ограничено. То, что он продолжает работать и для взрослых - фича современного мира. И тут несколько факторов. Если вспомнить времена трех мушкетеров или даже 19 век, то там за неудачную провокацию можно было получить дуэль с неясными последствиями, и это - останавливало. С детьми-то безопасно. И в компании руководитель чувствует относительную безопасность. А с другой стороны, реклама и политтехнологии активно используют инструменты манипуляции и провокации на различные действия - покупку товаров, поддержку нужных инициатив. И в этом причина, почему противостоять этому не учат в школе. Противостоять этому, кстати, достаточно просто - нужна уверенная самооценка, не зависшая от внешней похвалы. И методы обучения тоже есть, Анна Обухова рассказывает очень простой протокол авторизации результата, который служит именно для этого. Она его нашла в методичках педагогического университета имени Герцена для работы с детьми с отставанием в развитии. А вот при обучении обычных детей его не применяют. Почему? Есть версия, что класс, где все ученики им владеют, становится не управляемым для учителей и родителей - с ними можно взаимодействовать только из взрослой позиции, а система образования так не умеет. Но это уже - про исправление мира. Пока мы работаем в реальном мире, с теми людьми, которые в нем есть. И можно использовать их особенности для достижения рабочих задач. Помня про этику, но это отдельная не очевидная тема.
👍4
#MergeConf Елена Спиридонова из CUSTIS. Как executive search может решать сразу несколько задач ИТ-бизнеса. Для тех, кто не в теме, executive search - поиск редкого специалиста, обычно на позицию топ-руководителя или эксперта, с уникальными требованиями профиля. Такие специалисты могут существовать, но они не ищут работу, у них вообще не может быть резюме. При этом с ростом дефицита на рынке ИТ все больше позиций - архитекторы, аналитики высоких уровней или с конкретным опытом все больше становятся объектом такого поиска. В докладе был алгоритм и конкретные кейсы.
Шаги поиска.
1. Работа с заказчиком. Для чего нужен спец, что изменится, когда придет, что будет, если не придет. И главное - как будем встраивать, готов ли заказчик, часто - владелец или директор, тратить время на встройку.
2. Стратегия поиска. Их нет на сайтах, у них нет резюме, они не ищут работу. Используем РБК, Tadviser, habr. Авторы, блоги, подкасты, рекомендации.
3. Интервью и оценка. Люди работу не ищут. Но если пришли пообщаться - значит какой-то шанс есть. Вопрос - понять, за что можно зацепиться. Но и требования. Сulture fit. И что драйвит, обычно - не деньги. Амбиции, проекты, поднять направление с нуля, найти нового клиента и так далее. Третий не заканчиваем, пока не поймем, что интересно, и как соответствует.
4. Офер. Исходя из того, что узнали на 3.
5. Выход и адаптация. HR и собственник или другой заказчик должен быть рядом.
Искать можно самим или через агентство. Но, по опыту, с такими нестандартными вакансиями работает только топ-5 агентств, они все работают по предоплате, хотя бы частичной, которую не возвращают при отказе от проекта, а полный гонорар до 30% от годового дохода специалиста. А еще их надо погружать в контекст и вопросы взаимодействия внутри компании, включая встройку, тоже остаются. И у них есть большая сетка теплых контактов. А самим получается дешевле, бизнес-контекст уже знают, и можно проговорить особенности кандидата и обеспечить сопровождения, если решили брать кандидата, не смотря на это.
Но если делать самим, то надо понимать, что в технологии инструменты - 20%, а остальное - коммуникации и soft skill. Надо нарабатывать социальную сеть тех, кто в теме, кто готов порекомендовать специалиста. Для этого она активно ходит на конференции, не как HR, а как бизнес, общается. Надо уметь знакомится, общаться, такие специалисты не откликаются на письмо с предложением на работу, а вот если спросить про его выступления или подкасты, попросить помочь разобраться в теме, рассказать о проблеме и попросить рекомендовать, кто может помочь - они откликаются, и могут порекомендовать конкретного специалиста. А чтобы найти специалиста в моменте - используют публикации, пресс-релизы, выясняют, у кого есть опыт подобных проектов, если это - существенное требование. Или по социальной сетке, если речь идет о каком-то уникальном продукте, который используется в ограниченном числе банков или компаний - то кто конкретно вел проекты внедрения, компанию обычно можно узнать по прессе, а фамилии участников проекта - уже через знакомых.
У технологии есть ограничения, она бесполезна, когда заказчик - не настоящий. Или когда хотят замаскировать проблему, например, в описании вакансии виден CTO, но СТО в компании есть и его не хотят менять. Надо быть готовым, что не будет большого потока резюме, проекты 4-12 месяцев. И будет требоваться много времени - у HR и у собственника.
Шаги поиска.
1. Работа с заказчиком. Для чего нужен спец, что изменится, когда придет, что будет, если не придет. И главное - как будем встраивать, готов ли заказчик, часто - владелец или директор, тратить время на встройку.
2. Стратегия поиска. Их нет на сайтах, у них нет резюме, они не ищут работу. Используем РБК, Tadviser, habr. Авторы, блоги, подкасты, рекомендации.
3. Интервью и оценка. Люди работу не ищут. Но если пришли пообщаться - значит какой-то шанс есть. Вопрос - понять, за что можно зацепиться. Но и требования. Сulture fit. И что драйвит, обычно - не деньги. Амбиции, проекты, поднять направление с нуля, найти нового клиента и так далее. Третий не заканчиваем, пока не поймем, что интересно, и как соответствует.
4. Офер. Исходя из того, что узнали на 3.
5. Выход и адаптация. HR и собственник или другой заказчик должен быть рядом.
Искать можно самим или через агентство. Но, по опыту, с такими нестандартными вакансиями работает только топ-5 агентств, они все работают по предоплате, хотя бы частичной, которую не возвращают при отказе от проекта, а полный гонорар до 30% от годового дохода специалиста. А еще их надо погружать в контекст и вопросы взаимодействия внутри компании, включая встройку, тоже остаются. И у них есть большая сетка теплых контактов. А самим получается дешевле, бизнес-контекст уже знают, и можно проговорить особенности кандидата и обеспечить сопровождения, если решили брать кандидата, не смотря на это.
Но если делать самим, то надо понимать, что в технологии инструменты - 20%, а остальное - коммуникации и soft skill. Надо нарабатывать социальную сеть тех, кто в теме, кто готов порекомендовать специалиста. Для этого она активно ходит на конференции, не как HR, а как бизнес, общается. Надо уметь знакомится, общаться, такие специалисты не откликаются на письмо с предложением на работу, а вот если спросить про его выступления или подкасты, попросить помочь разобраться в теме, рассказать о проблеме и попросить рекомендовать, кто может помочь - они откликаются, и могут порекомендовать конкретного специалиста. А чтобы найти специалиста в моменте - используют публикации, пресс-релизы, выясняют, у кого есть опыт подобных проектов, если это - существенное требование. Или по социальной сетке, если речь идет о каком-то уникальном продукте, который используется в ограниченном числе банков или компаний - то кто конкретно вел проекты внедрения, компанию обычно можно узнать по прессе, а фамилии участников проекта - уже через знакомых.
У технологии есть ограничения, она бесполезна, когда заказчик - не настоящий. Или когда хотят замаскировать проблему, например, в описании вакансии виден CTO, но СТО в компании есть и его не хотят менять. Надо быть готовым, что не будет большого потока резюме, проекты 4-12 месяцев. И будет требоваться много времени - у HR и у собственника.
В воронке может быть 30-50 кандидатов, нанимают одного, бывает что вообще не нанимают. И процесс дает много дополнительного профита: получаешь знакомство с рынком, спектр вознаграждения, многое узнаешь о работе других компаний, получаешь сетку теплых контактов, которые не подошли к конкретной позиции, но могут подойти к другим. Или сейчас не готовы менять работу, но это может измениться. Самая долгая история контакта была около двух лет - человек устойчиво работал на своем месте, а потом в его компании началась реорганизация. Или, в другом кейсе, человек ушел из компании делать свое дело, а оно не полетело. А вот жесткий хантинг - не работает, если человек доволен своим местом - то он не уйдет. А если уходит - значит были какие-то реальные причины.
При найме важны не только хард, но и culture fit. Если понимаете, что по хардам - хорошо, а по культуре - не подходит, то явно обсуждает риск с кандидатом. И кандидат явно говорит - есть риск или нет. А дальше смотрят, что по бизнесу. И да, бывает, что кандидат не вписывается. Бывает, что идут на риск, тогда важна отстроить границы. Если кто-то не включает камеру на зумах никогда - проговаривается особенность. И строят модель взаимодействия с их учетом, такие кейсы тоже есть.
При найме важны не только хард, но и culture fit. Если понимаете, что по хардам - хорошо, а по культуре - не подходит, то явно обсуждает риск с кандидатом. И кандидат явно говорит - есть риск или нет. А дальше смотрят, что по бизнесу. И да, бывает, что кандидат не вписывается. Бывает, что идут на риск, тогда важна отстроить границы. Если кто-то не включает камеру на зумах никогда - проговаривается особенность. И строят модель взаимодействия с их учетом, такие кейсы тоже есть.
❤3👍3👏1
#MergeConf Андрей Гирин из Лидеры изменений. Болото операционки: чем больше шевелишься, тем сильнее увязаешь. Как реализовать стратегию и не утонуть в деталях. Проблема, что операционка кушает все врмя - распространенная. И доклад был про способ работы, методику OKR, чтобы так не происходило. Была методика, с шагами, иллюстрированная примерами. В конце был итог из 6 пунктов.
1. Сфокусировать компанию. Взять группы, которые про стратегию, и не засорять
2. Управлять целями, а не задачами. Задач - много, у них статусы и проблемы. Поэтому пусть люди идут
3. Отслеживать пульс - метрики, что компания не идет вразнос.
4. Выбирайте правильных людей, в зависимости от целей и задач.
5. Определите амбиции. Насколько можно инвестирвоать в конкретные направления в рамках стратегии.
6. Вовлекайте причастных. Их больше, чем ответственных, и они могут помочь или помешать. Никто не злой, но у причастных свои планы.
Если говорить про конкретные техники, то примером может быть распределение ресурсов. Например, для ИТ - договаривайтесь, сколько команда работает на перспективу, enabler; сколько - делает бизнес-фичи; сколько тратит на эксплуатацию, поддержание системы. Enabler может быть разный - можно смотреть на технологии, можно изучать клиентский опыт - и это тоже надо взвешивать и планировать. Или каденции - ритм работы: определяем годовые цели с декомпозицией на кварталы, каждую неделю - статус движения, раз в квартал - коррекция целей с учетом продвижения и изменений внешнего окружения. Про все техники и примеры я рассказывать не буду.
1. Сфокусировать компанию. Взять группы, которые про стратегию, и не засорять
2. Управлять целями, а не задачами. Задач - много, у них статусы и проблемы. Поэтому пусть люди идут
3. Отслеживать пульс - метрики, что компания не идет вразнос.
4. Выбирайте правильных людей, в зависимости от целей и задач.
5. Определите амбиции. Насколько можно инвестирвоать в конкретные направления в рамках стратегии.
6. Вовлекайте причастных. Их больше, чем ответственных, и они могут помочь или помешать. Никто не злой, но у причастных свои планы.
Если говорить про конкретные техники, то примером может быть распределение ресурсов. Например, для ИТ - договаривайтесь, сколько команда работает на перспективу, enabler; сколько - делает бизнес-фичи; сколько тратит на эксплуатацию, поддержание системы. Enabler может быть разный - можно смотреть на технологии, можно изучать клиентский опыт - и это тоже надо взвешивать и планировать. Или каденции - ритм работы: определяем годовые цели с декомпозицией на кварталы, каждую неделю - статус движения, раз в квартал - коррекция целей с учетом продвижения и изменений внешнего окружения. Про все техники и примеры я рассказывать не буду.
👍5🔥2
#MergoConf Анастасия Валуйская из VK. Эффективный менеджер как им не быть или все же быть?! Если кратко, то доклад о том, что понятие "эффективный менеджер" сейчас имеет резко отрицательные коннотации, которые основаны на реальных фактах. И потому не надо таким менеджером становиться, а надо управлять иначе.
А если подробнее, то когда-то Питер Друкер характеризовал эффективного менеджера как того, кто создает стратегию, принмиает риски, погружается в команду и управляет ей. Из тех времен пришла квалификация основных стилей управления на авторитарных с жестким управлением, либералов, которые за общую дружбу, как кот Леопольд и демократов, которые полагаются на команду, но при необходимости приходят на помощь, как Гэндальф. Судя по всему, это классификация Курта Левина (1939), правда у него либеральный стиль назывался попустительским (laissez-faire в оригинале). От себя отмечу, что у Белбина есть роли Шейпера и Координатора, которые в целом соответствуют авторитарному и демократическому стилю, при этом Белбин выделял свои роли экспериментально. А попустительство получится, если руководителем назначить Душу компании, есть у Белбина такая роль, очень полезная, но не руководящая. Впрочем, Анастасия не разбирала детали этой классификации, так что в контексте доклада все это не важно.
А дальше тема доклада резко развернулась в то, что сейчас эффективный менеджер - это менеджер, который пришел и провел неуместные реорганизации ради достижения каких-то показателей, которые испортили работу команды. Пример, с которым она сталкивалась сама - пришел эффективный менеджер и убрал отдел тестировщиков, да еще практически до выпуска крупной фичи. Они выкатились с багами и несколько месяцев их правили. Анастасия не рассказала продолжение, эффективные менеджеры иногда еще успевают получить премию за реорганизацию или свалить с повышением, а разгребают другие. При этом реорганизация часто - из лучших побуждений, в соотвтествии с учебниками, просто побочные эффекты не посчитаны. Книги по менеджменту содержат громажное количество примеро, ИТ тут не исключение. И есть мемы, Анастасия приводила комиксы сова - эффективный менеджмент, есть замечательная серия комиксов Дильберта на ту же тему.
Эффективным менеджером быть плохо, и Анастасия дала антипаттерны поведения в форме вредных советов.
* Заслуги - вам, провалы - подчиненным. Кейс - присвоили заслуги.
* Максимально нагружайте людей, особенно непонятными задачами. Чем больше загружен - тем эффективнее результат
* Усильте контроль, эффективный контроль - залог успеха, поставьте микроменеджемнт
* Никогда не рассказывайте команде планы, куда идет компания. Разработчик ведь перестанет писать код, узнав о целях, он будет думать о
* Не вникайте в предметную область. Кейс - человек в ИТ не знал, что есть фронт, бэк и дизайн. Отмечу, что этот вредный совет - основа английской управленческой практики 19 века: джентльмен может управлять чем угодно, ему не надо специально учиться. И именно такой подход лег в основу MBA. В отличие от немецкой традиции 19 века, воспринятой тогда же в России, где знание предмета считалось обязательным.
Дальше была часть о том, как реально управлять с пользой, а не быть не таким гротескным эффективным менеджером. По аналогии с проектным треугольником деньги-время-содержание, она предлагает люди-время-содержание.
* Тайм-менеджмент. Но! СБС - синдром бесполезных совещаний, практически эпидемия.
* Содержание. Пришла в ВК, маркировка рекламы - погрузилась, и в продукты
* Люди. Работа в косманде, мы все люди. Встречаются позитивные и негативные. Но есть и другие эмоции. Необходимо мириться, находить контакт и налаживать связи.
Сотрудники - разные, есть модель мотивации Герчикова, которая выделяет пять типов мотивации, есть другие модели. Важно понимать, что мотивации - различны, и работать ними. Работать можно по-разному. Например, есть сотрудники, которых хотят быть тимлидами. Она ввела позицию бади для фичи - получается маленький тимлид конкретной фичи, и это помогает.
А если подробнее, то когда-то Питер Друкер характеризовал эффективного менеджера как того, кто создает стратегию, принмиает риски, погружается в команду и управляет ей. Из тех времен пришла квалификация основных стилей управления на авторитарных с жестким управлением, либералов, которые за общую дружбу, как кот Леопольд и демократов, которые полагаются на команду, но при необходимости приходят на помощь, как Гэндальф. Судя по всему, это классификация Курта Левина (1939), правда у него либеральный стиль назывался попустительским (laissez-faire в оригинале). От себя отмечу, что у Белбина есть роли Шейпера и Координатора, которые в целом соответствуют авторитарному и демократическому стилю, при этом Белбин выделял свои роли экспериментально. А попустительство получится, если руководителем назначить Душу компании, есть у Белбина такая роль, очень полезная, но не руководящая. Впрочем, Анастасия не разбирала детали этой классификации, так что в контексте доклада все это не важно.
А дальше тема доклада резко развернулась в то, что сейчас эффективный менеджер - это менеджер, который пришел и провел неуместные реорганизации ради достижения каких-то показателей, которые испортили работу команды. Пример, с которым она сталкивалась сама - пришел эффективный менеджер и убрал отдел тестировщиков, да еще практически до выпуска крупной фичи. Они выкатились с багами и несколько месяцев их правили. Анастасия не рассказала продолжение, эффективные менеджеры иногда еще успевают получить премию за реорганизацию или свалить с повышением, а разгребают другие. При этом реорганизация часто - из лучших побуждений, в соотвтествии с учебниками, просто побочные эффекты не посчитаны. Книги по менеджменту содержат громажное количество примеро, ИТ тут не исключение. И есть мемы, Анастасия приводила комиксы сова - эффективный менеджмент, есть замечательная серия комиксов Дильберта на ту же тему.
Эффективным менеджером быть плохо, и Анастасия дала антипаттерны поведения в форме вредных советов.
* Заслуги - вам, провалы - подчиненным. Кейс - присвоили заслуги.
* Максимально нагружайте людей, особенно непонятными задачами. Чем больше загружен - тем эффективнее результат
* Усильте контроль, эффективный контроль - залог успеха, поставьте микроменеджемнт
* Никогда не рассказывайте команде планы, куда идет компания. Разработчик ведь перестанет писать код, узнав о целях, он будет думать о
* Не вникайте в предметную область. Кейс - человек в ИТ не знал, что есть фронт, бэк и дизайн. Отмечу, что этот вредный совет - основа английской управленческой практики 19 века: джентльмен может управлять чем угодно, ему не надо специально учиться. И именно такой подход лег в основу MBA. В отличие от немецкой традиции 19 века, воспринятой тогда же в России, где знание предмета считалось обязательным.
Дальше была часть о том, как реально управлять с пользой, а не быть не таким гротескным эффективным менеджером. По аналогии с проектным треугольником деньги-время-содержание, она предлагает люди-время-содержание.
* Тайм-менеджмент. Но! СБС - синдром бесполезных совещаний, практически эпидемия.
* Содержание. Пришла в ВК, маркировка рекламы - погрузилась, и в продукты
* Люди. Работа в косманде, мы все люди. Встречаются позитивные и негативные. Но есть и другие эмоции. Необходимо мириться, находить контакт и налаживать связи.
Сотрудники - разные, есть модель мотивации Герчикова, которая выделяет пять типов мотивации, есть другие модели. Важно понимать, что мотивации - различны, и работать ними. Работать можно по-разному. Например, есть сотрудники, которых хотят быть тимлидами. Она ввела позицию бади для фичи - получается маленький тимлид конкретной фичи, и это помогает.
👍2
Что делать
* стратегические субботы или ретро: цели и планы продукта, чем интересно заниматься, какие идеи
* регулярный аудит сфер физической, эмоиональной, умественной, духовной
* границы, без бесполезных совещаний
* эффективность - не самоцель, работайте в балансе.
Техника
* три простых дела. Если запланирвоали 4 дела и 3 сделали, четвертое пойдет легко, мозг настроен
* fresh or fried - сложное утром, простое - вечером.
* smart. выучить китайский - но нет времени. Мобильное приложение и заниматься - и результат есть, смалтолки получились
* work life balance.
Я в заключении конспекта хочу сказать, что феномен эффективного менеджера имеет много разных причин. Бывают искренние заблуждения и вера в теорию, бывает погоня за KPI, которые устроены так, что интересы компании не важны, и многое другое. Доведение до абсурда в форме вредных советов высмеивает, но не устраняет феномен, так же как фильм "Карнавальная ночь" не устранил многочисленных директоров домов культуры, которые вели себя подобно Огурцову. А самый интересный тут вопрос - о чем думал тот, кто назначал такого эффективного менеджера, зачем он выбрал именно его. Это может быть ошибка, а может - ценностное заблуждение, и во втором случае ситуации будут регулярно повторяться...
* стратегические субботы или ретро: цели и планы продукта, чем интересно заниматься, какие идеи
* регулярный аудит сфер физической, эмоиональной, умественной, духовной
* границы, без бесполезных совещаний
* эффективность - не самоцель, работайте в балансе.
Техника
* три простых дела. Если запланирвоали 4 дела и 3 сделали, четвертое пойдет легко, мозг настроен
* fresh or fried - сложное утром, простое - вечером.
* smart. выучить китайский - но нет времени. Мобильное приложение и заниматься - и результат есть, смалтолки получились
* work life balance.
Я в заключении конспекта хочу сказать, что феномен эффективного менеджера имеет много разных причин. Бывают искренние заблуждения и вера в теорию, бывает погоня за KPI, которые устроены так, что интересы компании не важны, и многое другое. Доведение до абсурда в форме вредных советов высмеивает, но не устраняет феномен, так же как фильм "Карнавальная ночь" не устранил многочисленных директоров домов культуры, которые вели себя подобно Огурцову. А самый интересный тут вопрос - о чем думал тот, кто назначал такого эффективного менеджера, зачем он выбрал именно его. Это может быть ошибка, а может - ценностное заблуждение, и во втором случае ситуации будут регулярно повторяться...
👍2
#MergeConf Эльвира Абзалова из Игрокрафт. Синхронизируй это! Как сделать команду сильной и слаженной на уровне ценностей. Ценности - это не менее важно, чем цели. А, возможно, и более. Потому что за поведением сотрудника, его действиями, стоят принципы, которыми он руководствуется в действии, а за принципами стоят ценности. Поэтому, работая с поведением - надо понимать, что для сотрудника важно. Если он вдруг выполняет свою работу "на отвяжись", либо его штормит и идет длинная неконструктивная переписка вместо работы, то, вполне возможно, какие-то из его ценности нарушены, а принципы говорят, что в этих случаях правильно вести себя именно таким образом. И надо вскрыть эти причины и далее работать с этим.
Ценности сотрудника должны соответствовать ценностям компании. А на практике у компании ценности часто придуманы топами и написаны как декларация, и на них не обращают внимание. И в результате у сотрудников нет мотивации, они работой не довольны, а компания не довольна их работой. Договариваться надо не только на уровне компании, но и на уровне команды: знать, что важно каждому участниками команды и договариваться о принципах работы. Не откидывать в сторону, а постоянно калибровать.
Как практически выяснять ценности сотрудников? Можно это делать в формате упражнений.
* Moving Motivators - выявление личных мотиваторов. Доска, сотрудники получают карточки и располагает по линии важности. Порядок, свобода, мастерство... А затем - насколько это удовлетворяю в работе, получаю ли.
* Culture design canvas. Картирование культурного кода команды. Как празднуем, как звучит в обучении, как лидерство на их основе. Netflix разработал документ по кольтуре - принципы работы, и сотрудники на них ориентируются.
* Командно-игровая сессия Ценности.
* Диагностика ценностей команды. Опираемся на историю, которая позволяет шкалировать.
И для начала - взять ценности, которые есть. Раскидать по уровням, чтобы это подвергалось оценке. И дальше оценить: насколько это важно для человека и насколько проявляется в работе, построить розочку. Для каждого челвоека, для команды в целом. Для оценки можно использовать готовые модели. Эльвира говорила про книгу Потенциал команды, Филлип Сандал и Алексис Филлипс, в которой ценности поделены на две группы: продуктивность и атмосфера, важны - обе.
И в завершении рассказа были два кейса, success story, когда за счет изменения ценностей, атмосферы получалось добиться впечатляющих изменений. Первый - крупная компания, там владелец говорил о низкой прибыли, а директор - что для прибыли нужно расширяться, без этого ничего нельзя сделать, а людей и так не хватает. Ключевым изменением было то, что директору был назначен наставник с очень высокой внутренней планкой качества. полученной на одном из прежних мест работы, принцип "делай лучше всех или не делай". И он сумел личным примером такого отношения вдохновить директора, от того такое отношение перешло к топам. И в результате удалось существенно изменить ситуацию без расширения. Второй кейс - служба обращение во ЖКХ, единое окно, где сотрудники были полностью демотивированы, замучены разбором жалоб, поток которых не иссякал. И у них сложилась культура вообще не реагировать, а при этом каждая жалоба повторялась многократно, ситуация усугублялась, люди начали разбегаться. Тут в проекте работал психолог с высоким чувством личной ответственности, которое он тоже смог передать - и оказалось, что с жалобами вполне можно разбираться, так что поток вторичных жалоб начал сокращаться. Люди увидели свет в конце тоннеля, отношение изменилось.
А в конце была игра, всем раздали карточки с ценностями, предложили у кого совпало с личными - выйти и рассказать, а если не совпало - посмотреть у соседей, поменяться. И примерно десять историй, очень разных мы услышали.
Ценности сотрудника должны соответствовать ценностям компании. А на практике у компании ценности часто придуманы топами и написаны как декларация, и на них не обращают внимание. И в результате у сотрудников нет мотивации, они работой не довольны, а компания не довольна их работой. Договариваться надо не только на уровне компании, но и на уровне команды: знать, что важно каждому участниками команды и договариваться о принципах работы. Не откидывать в сторону, а постоянно калибровать.
Как практически выяснять ценности сотрудников? Можно это делать в формате упражнений.
* Moving Motivators - выявление личных мотиваторов. Доска, сотрудники получают карточки и располагает по линии важности. Порядок, свобода, мастерство... А затем - насколько это удовлетворяю в работе, получаю ли.
* Culture design canvas. Картирование культурного кода команды. Как празднуем, как звучит в обучении, как лидерство на их основе. Netflix разработал документ по кольтуре - принципы работы, и сотрудники на них ориентируются.
* Командно-игровая сессия Ценности.
* Диагностика ценностей команды. Опираемся на историю, которая позволяет шкалировать.
И для начала - взять ценности, которые есть. Раскидать по уровням, чтобы это подвергалось оценке. И дальше оценить: насколько это важно для человека и насколько проявляется в работе, построить розочку. Для каждого челвоека, для команды в целом. Для оценки можно использовать готовые модели. Эльвира говорила про книгу Потенциал команды, Филлип Сандал и Алексис Филлипс, в которой ценности поделены на две группы: продуктивность и атмосфера, важны - обе.
И в завершении рассказа были два кейса, success story, когда за счет изменения ценностей, атмосферы получалось добиться впечатляющих изменений. Первый - крупная компания, там владелец говорил о низкой прибыли, а директор - что для прибыли нужно расширяться, без этого ничего нельзя сделать, а людей и так не хватает. Ключевым изменением было то, что директору был назначен наставник с очень высокой внутренней планкой качества. полученной на одном из прежних мест работы, принцип "делай лучше всех или не делай". И он сумел личным примером такого отношения вдохновить директора, от того такое отношение перешло к топам. И в результате удалось существенно изменить ситуацию без расширения. Второй кейс - служба обращение во ЖКХ, единое окно, где сотрудники были полностью демотивированы, замучены разбором жалоб, поток которых не иссякал. И у них сложилась культура вообще не реагировать, а при этом каждая жалоба повторялась многократно, ситуация усугублялась, люди начали разбегаться. Тут в проекте работал психолог с высоким чувством личной ответственности, которое он тоже смог передать - и оказалось, что с жалобами вполне можно разбираться, так что поток вторичных жалоб начал сокращаться. Люди увидели свет в конце тоннеля, отношение изменилось.
А в конце была игра, всем раздали карточки с ценностями, предложили у кого совпало с личными - выйти и рассказать, а если не совпало - посмотреть у соседей, поменяться. И примерно десять историй, очень разных мы услышали.
❤4👍3🔥2
В целом доклад - понятный, содержание ценностей действительно важно. Хотя для многих менеджеров и владельцев это является открытием, все-таки точка зрения, что у всех норальных людей более-менее одинаковые ценности и они совпадают с моими - очень распространена, для людей бывает открытием, насколько люди разные. Хотя, казалось бы, в школе он это видел у одноклассников. Но почему-то забыл.
У меня к материалу доклада есть следующие дополнения.
1. Эльвира назвала самую распространенную причину, почему ценности компании остаются пустой декларацией. Она в том, что руководство написало их для подчиненных, а не для себя. И не руководствуется ими при принятии решений: при выборе нового проекта, при распределении премий и иного вознаграждения, при назначении на должности. Люди видят, как к ценностям относится руководство - и поступают соответственно.
2. Люди по-разному понимают слова "ответственность", "справедливость", "эффективность", не говоря уже о тех, которые содержат оценку, например "хорошая работа" или "успешный проект". Поэтому надо раскрывать содержание слов. О том, как правильно раскрывать содержание ценностей хорошо написано в книге Марка Розина "Успех без стратегии": для каждой ценности должен быть сияющий идеал и заземление на повседневность в виде паттернов и антепаттернов поведения, и именно о них надо договариваться. Потому что для одного "пришел на встречу во время" означает "опоздал не больше 3 минут", а для другого "пришел за 3 минуты, чтобы подготовиться", не говоря о более сложных конструктах, таких как качественный проект. И все инструменты, типа отранжируй ценности, корректно работают только после того, как о содержании договорились. Проблема многих моделей и тестов в том, что они не учитывают эту разницу смыслов. Модель Спиральной динамики говорит, что есть восемь принципиальных конструкций ценностей, которые согласованным образом переопределяют смыслы понятий. У меня об этом есть несколько докладов и статей, если интересно - дам ссылки.
3. Если берешь чужую модель ценностей - надо понимать, в какой культуре она создавалась, какой смысл там вложен в слова, каковы представления про идеальную компанию и сотрудника. И сравнить это с вашей компанией. Я не знаю, какая модель заложена в книге "Потенциал команды", о которой говорила Эльвира, я ее не читал, но я анализировал многие известные модели ценностей - карту культур Хофстеде, модель Шнайдера, карту Инглхарта-Венцеля, и даже психологические модели DISC и Big Five, и они как раз показывают соответствие идеал, при чем выработанный на материале западной культуры. Об этом у меня тоже есть статьи (по ссылке - последняя).
У меня к материалу доклада есть следующие дополнения.
1. Эльвира назвала самую распространенную причину, почему ценности компании остаются пустой декларацией. Она в том, что руководство написало их для подчиненных, а не для себя. И не руководствуется ими при принятии решений: при выборе нового проекта, при распределении премий и иного вознаграждения, при назначении на должности. Люди видят, как к ценностям относится руководство - и поступают соответственно.
2. Люди по-разному понимают слова "ответственность", "справедливость", "эффективность", не говоря уже о тех, которые содержат оценку, например "хорошая работа" или "успешный проект". Поэтому надо раскрывать содержание слов. О том, как правильно раскрывать содержание ценностей хорошо написано в книге Марка Розина "Успех без стратегии": для каждой ценности должен быть сияющий идеал и заземление на повседневность в виде паттернов и антепаттернов поведения, и именно о них надо договариваться. Потому что для одного "пришел на встречу во время" означает "опоздал не больше 3 минут", а для другого "пришел за 3 минуты, чтобы подготовиться", не говоря о более сложных конструктах, таких как качественный проект. И все инструменты, типа отранжируй ценности, корректно работают только после того, как о содержании договорились. Проблема многих моделей и тестов в том, что они не учитывают эту разницу смыслов. Модель Спиральной динамики говорит, что есть восемь принципиальных конструкций ценностей, которые согласованным образом переопределяют смыслы понятий. У меня об этом есть несколько докладов и статей, если интересно - дам ссылки.
3. Если берешь чужую модель ценностей - надо понимать, в какой культуре она создавалась, какой смысл там вложен в слова, каковы представления про идеальную компанию и сотрудника. И сравнить это с вашей компанией. Я не знаю, какая модель заложена в книге "Потенциал команды", о которой говорила Эльвира, я ее не читал, но я анализировал многие известные модели ценностей - карту культур Хофстеде, модель Шнайдера, карту Инглхарта-Венцеля, и даже психологические модели DISC и Big Five, и они как раз показывают соответствие идеал, при чем выработанный на материале западной культуры. Об этом у меня тоже есть статьи (по ссылке - последняя).
🔥4👍1
#MergeConf Евгений Паромов из Evrone. FSD: 3 главных недостатка после 3 лет использования. В докладе было краткое изложение архитектурной методологии FSD, проблем, которые влечет его использование, если следовать букве концепции, и тех модификаций, которые использует Евгений для решения этих проблем. А в начале был рассказ о том, что такое - архитектурные методологии и зачем они нужны. Хорошо, когда архитектуру подбирают индивидуально для проекта, опираясь на требования. Но на старте проектирования требований часто нет, они прорабатываются позднее, а архитектура - нужна. Иначе получится комок грязи, спагетти-код или нечто подобное - это как раз примеры архитектур, которые складываются сами, если отдельно не думать. И тут появляются архитектурные методологии или шаблоны - набор эвристических принципов, следуя которым в среднем получаешь хорошую архитектуру, обеспечивающую надежный, расширяемый и переиспользуемый код.
Эту роль FSD выполняет: проект у мидлов с использованием FSD получается лучше, чем без этого. При этом шаблон - простой, без dependency injection, который сильно усложняет конструкции, и сделан для фронта, в то время, как большинство других - для бэка, а значит их примеры ты должен сначала переосмыслить, что сложно на начальном этапе. FSD делит код на слои:
* app - приложение в целом
* pages - экраны
* widgets - целостные компоненты интерфейса
* features - реализация действий пользователя, use case
* entities - бизнес-объекты проекта
* shared - библиотеки, не привязанные к объектам бизнеса
Каждый слой делится на срезы - slice, это модули. А slice делится на сегменты, тут типичный пример UI - model - api. Есть ограничение: реализация нижележащего слоя не должна обращаться ни к вышележащему, кроме того ни к смежным частям одного слоя, то есть один объект не может вызывать другой.
Евгений познакомился с FSD три года назад, успешно приносил и применял в командах, видел позитив. Потом он пришел в команду, где FSD начали применять до него, и обнаружил там множество очень маленьких фич, а еще активно живущий UI kit в нижнем слое, что порождало неустойчивость проекта. Он задумался: это особенности внедрения подхода в проекте, или какие-то проблемы заложены в самом подходе? Анализ выявил три проблемы.
Первая проблема - слишком изменчивый shared. Это происходит не всегда, а только в случаях. когда проект опирается на активно развиваемые библиотеки. Типичный кейс - развиваемый UI kit. И в результате надо либо сохранять совместимость, и тогда в UI kit множатся объекты, появляется button1, button2, button3, либо нужен частый рефакторинг при изменении shared-уровня, либо возникают фасады вместо конкретных классов, и это усложняет использование.
Тут как альтернативу можно посмотреть на шаблон Clean Architecture. В отличие от FSD, по нему есть книжка, где подробно объяснен не только сам шаблон, но и его основания. В нем слои другие: WebUI - infrastracture - application - domain. То есть инфраструктура поднята выше приложений, и потому она может активно развиваться. Но там мы не можем в реализацию сущности (domain) включить UI,иначе чем через dependency injection, а это сложно и потому во фронте - не прижилось.
Вторая проблема: entities не позволяет описать бизнес-модель. Потому что модель - это не только объекты, но и связи между ними. И важно отделить бизнес-модель от всего остального. А тут объекты не могут вызывать друг друга, связи, следуя шаблону, приходится выносить на уровень features, где они смешиваются с действиями пользователя. В этом отличие слоя entities FSD от domain в Clean architecture.
Решение FSD по использованию для связи только ключей приводит к постоянной нормализации-денормализации, потому что бэк часто работает в денормализованых конструкциях. А протокол между фронтом и бэком должен быть денормализованый, потому что если извлекать всю связанную информацию по ключу отдельными запросами, то получается медленно, запросы - не быстрые.
Эту роль FSD выполняет: проект у мидлов с использованием FSD получается лучше, чем без этого. При этом шаблон - простой, без dependency injection, который сильно усложняет конструкции, и сделан для фронта, в то время, как большинство других - для бэка, а значит их примеры ты должен сначала переосмыслить, что сложно на начальном этапе. FSD делит код на слои:
* app - приложение в целом
* pages - экраны
* widgets - целостные компоненты интерфейса
* features - реализация действий пользователя, use case
* entities - бизнес-объекты проекта
* shared - библиотеки, не привязанные к объектам бизнеса
Каждый слой делится на срезы - slice, это модули. А slice делится на сегменты, тут типичный пример UI - model - api. Есть ограничение: реализация нижележащего слоя не должна обращаться ни к вышележащему, кроме того ни к смежным частям одного слоя, то есть один объект не может вызывать другой.
Евгений познакомился с FSD три года назад, успешно приносил и применял в командах, видел позитив. Потом он пришел в команду, где FSD начали применять до него, и обнаружил там множество очень маленьких фич, а еще активно живущий UI kit в нижнем слое, что порождало неустойчивость проекта. Он задумался: это особенности внедрения подхода в проекте, или какие-то проблемы заложены в самом подходе? Анализ выявил три проблемы.
Первая проблема - слишком изменчивый shared. Это происходит не всегда, а только в случаях. когда проект опирается на активно развиваемые библиотеки. Типичный кейс - развиваемый UI kit. И в результате надо либо сохранять совместимость, и тогда в UI kit множатся объекты, появляется button1, button2, button3, либо нужен частый рефакторинг при изменении shared-уровня, либо возникают фасады вместо конкретных классов, и это усложняет использование.
Тут как альтернативу можно посмотреть на шаблон Clean Architecture. В отличие от FSD, по нему есть книжка, где подробно объяснен не только сам шаблон, но и его основания. В нем слои другие: WebUI - infrastracture - application - domain. То есть инфраструктура поднята выше приложений, и потому она может активно развиваться. Но там мы не можем в реализацию сущности (domain) включить UI,иначе чем через dependency injection, а это сложно и потому во фронте - не прижилось.
Вторая проблема: entities не позволяет описать бизнес-модель. Потому что модель - это не только объекты, но и связи между ними. И важно отделить бизнес-модель от всего остального. А тут объекты не могут вызывать друг друга, связи, следуя шаблону, приходится выносить на уровень features, где они смешиваются с действиями пользователя. В этом отличие слоя entities FSD от domain в Clean architecture.
Решение FSD по использованию для связи только ключей приводит к постоянной нормализации-денормализации, потому что бэк часто работает в денормализованых конструкциях. А протокол между фронтом и бэком должен быть денормализованый, потому что если извлекать всю связанную информацию по ключу отдельными запросами, то получается медленно, запросы - не быстрые.
👍3
Простое решение - разрешить связи - не работает. Потому что объекты включают UI и в результате тянут не просто данные другого объекта, но и все интерфейсы. Получается такая сильно связанная конструкция, а остальные слои вырождаются. Евгений такой вариант пробовал.
Третья проблема. На уровнях Widgets + Features + Entites - слишком много связей между модулями. Там пример TodoList - он размазывается по всем уровням, на уровне features превращается в множество команд. А рядом UserList - тоже много классов и файлов. И это все путается.
Какие решения предлагает Евгений, чтобы уйти от недостатков? Он в целом сохраняет структуру слоев и их деления, но предлагает ряд изменений.
1. Entities - не объект, а группа связанных сущностей, например, user=user+session+profile
2. Features - не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.
3. Для устойчивости приложения из сегмента domain, работы с бизнес-сущностью, запрещается импортировать shared.
4. Для связывания разных объектов используется dependency injection. Это самое сложное. Пример: UI TodoList требует календаря. И мы вызываем абстрактный render calendar. Его связывание с конкретной реализацией - на уровне page.
Вроде, проблемы решаются. Правда, у Евгения вопрос: это по-прежнему FSD, или уже другая архитектура?
Я хочу начать свой комментарий к докладу с ответа на этот вопрос. Но он будет длинным. Есть такая штука - парадигмы программирования: процедурная, объектная, реляционная, функциональная и другие. Процедурная восходит к книге Николаса Вирта "Алгоритмы + Структуры данных = Программы", это 1976. Позднее добавился UI. B весь старый enterprise - 1С, SAP и многое другое сделан именно в процедурной парадигме, хотя уже на объектных языках. Потому что объектные языки появились с C++, в 1980, объектно-ориентированное проектирование (OOAD) - только через 10-15 лет, а его окончательное оформление в DDD - вообще в 2003. И если почитать шаблоны корпоративного приложения Фаулера или другие книги, то он пишет, что шаблон RichObjects, объекты предметной области - он сложный, проще работать на DTO или использовать другие аналогичные шаблоны. Отличие объектного подхода - объединение данных и поведения в одном объекте с инкапсуляцией внутреннего устройства. А в FSD данные, слой entities, отделены от поведения. оно в features, подобно алгоритмам и структурам данных у Вирта. Отсюда и сложности, если мы пробуем использовать FSD, держа в голове еще и концепцию модели предметной области DDD - она-то сделана в объектной парадигме. А изменения, которые предлагает Евгений - в рамках этого направления. Так что, на мой взгляд, получилось нечто иное.
Но это - концептуальный ответ. А есть еще прагматический. Если речь идет про объяснения новичкам, то практичнее говорить про FSD с изменениями - есть референс и известный подход, ты не говоришь про велосипед. А вот если есть амбиции больше - то можно говорить про альтернативу. Представить свой подход на международных конференциях, написать книгу. Тогда лучше позиционировать как новый подход. например. полученный в результате синтеза FSD и Clean Architecture или гибрид FSD и богатой доменной модели DDD, или что-то подобное.
А если говорить о практике, то важно сопрягать подходы фронта и бека, при чем с учетом накладных расходов, которые требуют денормализованой передачи. Авторы фреймворков часто живут в мире бесконечно быстрых машин и сетей.
Третья проблема. На уровнях Widgets + Features + Entites - слишком много связей между модулями. Там пример TodoList - он размазывается по всем уровням, на уровне features превращается в множество команд. А рядом UserList - тоже много классов и файлов. И это все путается.
Какие решения предлагает Евгений, чтобы уйти от недостатков? Он в целом сохраняет структуру слоев и их деления, но предлагает ряд изменений.
1. Entities - не объект, а группа связанных сущностей, например, user=user+session+profile
2. Features - не use case по действиям, а блоки связанной функциональности для бизнеса, например TodoList. Фичи получаются большие, их надо структурировать.
3. Для устойчивости приложения из сегмента domain, работы с бизнес-сущностью, запрещается импортировать shared.
4. Для связывания разных объектов используется dependency injection. Это самое сложное. Пример: UI TodoList требует календаря. И мы вызываем абстрактный render calendar. Его связывание с конкретной реализацией - на уровне page.
Вроде, проблемы решаются. Правда, у Евгения вопрос: это по-прежнему FSD, или уже другая архитектура?
Я хочу начать свой комментарий к докладу с ответа на этот вопрос. Но он будет длинным. Есть такая штука - парадигмы программирования: процедурная, объектная, реляционная, функциональная и другие. Процедурная восходит к книге Николаса Вирта "Алгоритмы + Структуры данных = Программы", это 1976. Позднее добавился UI. B весь старый enterprise - 1С, SAP и многое другое сделан именно в процедурной парадигме, хотя уже на объектных языках. Потому что объектные языки появились с C++, в 1980, объектно-ориентированное проектирование (OOAD) - только через 10-15 лет, а его окончательное оформление в DDD - вообще в 2003. И если почитать шаблоны корпоративного приложения Фаулера или другие книги, то он пишет, что шаблон RichObjects, объекты предметной области - он сложный, проще работать на DTO или использовать другие аналогичные шаблоны. Отличие объектного подхода - объединение данных и поведения в одном объекте с инкапсуляцией внутреннего устройства. А в FSD данные, слой entities, отделены от поведения. оно в features, подобно алгоритмам и структурам данных у Вирта. Отсюда и сложности, если мы пробуем использовать FSD, держа в голове еще и концепцию модели предметной области DDD - она-то сделана в объектной парадигме. А изменения, которые предлагает Евгений - в рамках этого направления. Так что, на мой взгляд, получилось нечто иное.
Но это - концептуальный ответ. А есть еще прагматический. Если речь идет про объяснения новичкам, то практичнее говорить про FSD с изменениями - есть референс и известный подход, ты не говоришь про велосипед. А вот если есть амбиции больше - то можно говорить про альтернативу. Представить свой подход на международных конференциях, написать книгу. Тогда лучше позиционировать как новый подход. например. полученный в результате синтеза FSD и Clean Architecture или гибрид FSD и богатой доменной модели DDD, или что-то подобное.
А если говорить о практике, то важно сопрягать подходы фронта и бека, при чем с учетом накладных расходов, которые требуют денормализованой передачи. Авторы фреймворков часто живут в мире бесконечно быстрых машин и сетей.
#EnterpriseAgile Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только). Это был рассказ о работе с системой метрик, применяемый в hh, иллюстрированный конкретными примерами. Основная идея - метрики лишь показывают точки потенциальных проблем, и не автоматически, а после анализа показателей на предмет нежелательной динамики или соотношение метрик. А дальше нужно породить гипотезы - что может являться причинами, и проверить их через детальный анализ, погружение в реальную работу людей. При этом, если проблемы выявлены из общих метрик, то анализ ведут в каждом из сервисов, причины могут быть различны. Общие подтвержденные гипотезы становятся фокусом на уровне компании, частные - в сервисах, масштаб определяет приоритеты.
В докладе было конкретной дерево метрик из двух групп - ресурсы и поток.
1.1. ФОТ на доход или ключевую метрику сервиса (не для всех сервисов доход - целевая метрика)
1.2. Распределение ресурсов: стратегия, продукт, тех.налог, прочее. Классификация задач, дальше корректируется продуктом, так как большие задачи могут перекашивать.
2.1. 85% lead time feature. Полный - от discovery, постановки до АБ тест и пост-продакшн. 85 выбрано ретроспективно из анализа.
2.2. Эффективность потока - блокеры.
2.3. Средняя пропускная способность за неделю
В докладе были примеры. Разбор с тем, что увидели рост времени АБ-тестирования - там были гипотезы. И со сроками discovery в одном из потоков - она была волатильна и коррелировала с отпусками и болезнями, то есть мощности команды явно не хватало на стандартный поток и они добавили человека. При этом нет задачи работать на конкретную метрику, например, увеличение lead time - нормальная вещь, если поставлена задача улучшить фазу discovery. Метрики - лишь сигнал, а дальше надо погружаться, не работать напрямую. Именно люди работают с процессом и знают как поменять.
И в конце - шаги работы с метриками.
1. Начать собирать метрики
2. анализ и генерацию гипотез
3. провести анализ сервиса - проверить гипотезы
4. фокусы для сервисов
5. общие гипотезы для всех сервисов
6. задачи для всех и для конкретных сервисов
В докладе было конкретной дерево метрик из двух групп - ресурсы и поток.
1.1. ФОТ на доход или ключевую метрику сервиса (не для всех сервисов доход - целевая метрика)
1.2. Распределение ресурсов: стратегия, продукт, тех.налог, прочее. Классификация задач, дальше корректируется продуктом, так как большие задачи могут перекашивать.
2.1. 85% lead time feature. Полный - от discovery, постановки до АБ тест и пост-продакшн. 85 выбрано ретроспективно из анализа.
2.2. Эффективность потока - блокеры.
2.3. Средняя пропускная способность за неделю
В докладе были примеры. Разбор с тем, что увидели рост времени АБ-тестирования - там были гипотезы. И со сроками discovery в одном из потоков - она была волатильна и коррелировала с отпусками и болезнями, то есть мощности команды явно не хватало на стандартный поток и они добавили человека. При этом нет задачи работать на конкретную метрику, например, увеличение lead time - нормальная вещь, если поставлена задача улучшить фазу discovery. Метрики - лишь сигнал, а дальше надо погружаться, не работать напрямую. Именно люди работают с процессом и знают как поменять.
И в конце - шаги работы с метриками.
1. Начать собирать метрики
2. анализ и генерацию гипотез
3. провести анализ сервиса - проверить гипотезы
4. фокусы для сервисов
5. общие гипотезы для всех сервисов
6. задачи для всех и для конкретных сервисов
👍1
#EnterpriseAgile Анна Аверьянова из Робофинанс. Как OKR помог перезапустить бизнес! У Робофинанс с 2016 был бизнес в Испании - online выдача кредитов, в 2020 случился ковид, мораторий на платежи кредитов, с одной стороны, а с другой - поддержка ликвидности и онлайн. Они продолжили бизнес, но в 2021 выяснилось, что люди набирают кредиты и не платят. Поэтому по итогам года инвестор, он же владелец и ген.дир принял решения о закрытии бизнеса. Но такой бизнес нельзя закрыть одним днем, надо соблюсти требования регулятора, иначе можно лишиться лицензии и для других сегментов бизнеса. Поэтому был процесс на год, который решили вести по OKR, как и все остальное. Цель понятна - минимизация потерь. Было сделано 3 сценария от команды: реалистичный, негативный и позитивный. И в конце первого квартала увидели по метрикам, что развитие идет лучше даже оптимистичного сценария, и в принципе динамика позволяет предположить, что за год можно будет сохранить команду и выйти в плюс. Они пошли к владельцу, показали цифры, получили добро на попытку сохранения и поменяли цель. И у них получилось. У команды был стимул - им нравилось работать вместе и они точно хотели сохраниться. А пост-анализ показывает, что сыграли два внешних фактора: поменялся рынок потребления, то есть тех, кто брал кредиты, при этом часть конкурентов с рынка ушла. А OKR позволил во-время заметить изменение трендов, и пересобрать продукт под новый рынок.
👍5❤1
#EnterpriseAgile Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile. В PwC большое количество ИТ-системы были от головной компании. Поверх них кое-где были собственные решения с российской спецификой. Когда российская часть разводилась с головной, у него осталось лоскутное одеяло этих решений, а чтобы не допустить остановки бизнеса - перешли не Excel. А дальше надо было реанимировать ситуацию, и в компании создали центр продуктовой экспертизы, чтобы сделать это системно. Марина - его руководитель, в центре собраны архитекторы, devops, юридическое обеспечение и ряд других компетенций, а разработка идет отдельными командами, которую центр поддерживает. И еще просвещает в части продуктового подхода и unit-экономики. И у них получилось не просто разработать продукты, поддерживающие работу компании, но и начать выводить их на рыноК PwC этого вообще не делало. Такая вот success story. О конструкции разработки и функциях центра Марина рассказывала, но очень пунктиром, на слайдах подробности есть.
❤2
#EnterpriseAgile Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка. Одна из существенных черт Agile-методов - прозрачность. И рассказ был о том, как обеспечивают прозрачность работы ИТ для топов банка через запуск value stream. На входе была ситуация, когда руководство неплохо представляет, что происходит в проектах, такая культура в банке есть, но там задействована примерна 1/3 ИТ. А 2/3 были через пулы распределены по подразделениям бизнеса и чем именно они занимаются, руководству не понятно. Более того, как выяснилось в ходе проекта, бизнесу тоже было не понятно, бизнес с ИТ не общался, и обе стороны имели не высокое мнение о другом, как это часто бывает. А еще бизнес с удивлением выяснял суммы, в которые ему обходится ИТ-пул - бухгалтерия это распределяла на общие расходы, а в управленческой отчетности это не светили.
Средство решения - реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим - 10-15 команд. За 2024 запустили 13 value stream, на следующий год - еще столько же. Запуск - это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам - актуализация целей и задач на следующий год.
Получили:
* Структурирование работ, и людей по направлением
* У всех - единая мотивация
* Управление достижением цели
* value stream - продуктовые, операционные, процессные.
* Связь между целями и результатами деятельности. Воронка продаж, экономика
* Метрики - cycle time, ttm, радар agile-здоровья и оценка зрелости
Средство решения - реорганизация работы ИТ в value stream? как это описано в SAFe, в которых идет квартальное планирование от задач бизнеса. Каждый стрим - 10-15 команд. За 2024 запустили 13 value stream, на следующий год - еще столько же. Запуск - это определение границ, целей и задачи value stream, затем структурирование внутри. После этого идут циклы квартального планирования и реализации, и по результатам - актуализация целей и задач на следующий год.
Получили:
* Структурирование работ, и людей по направлением
* У всех - единая мотивация
* Управление достижением цели
* value stream - продуктовые, операционные, процессные.
* Связь между целями и результатами деятельности. Воронка продаж, экономика
* Метрики - cycle time, ttm, радар agile-здоровья и оценка зрелости
#EnterpriseAgile Анастасия Заруднева из Райффайзен Банк. Continuous Big Systems Replacement. Банк меняет основную систему, которая обрабатывает 15м операций в день, над ней работает 250 команд. Проект идет три года, они в середине пути. При этом существенная часть нового в параллельной эксплуатации, а часть уже ведут в новых системах, так что есть уверенность в успехе. Важно: новую систему пишут те же команды, что и развивают старые, потому что надолго вырвать команды из создания реально работающего продукта противоречит agile-подходу. Дополнительно за счет этого команды понимают продукт, знают алгоритмику.
Как декомпозировать?
* Если есть продукты - их можно выделять. привлечение, размещение
* По процессам. Вокруг таких систем есть системы-сателлиты, можно брать из них.
* По потребителям данных. Самый молодой и массовый стрим, там сложно.
В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта - депозиты ФЛ. На стрим - менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.
На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда - продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.
Как управлять таким переносом?
* Делать на маленькие шаги
* Исследовать через поставку
* Ставить целью спринта приближение к target-архитектуре
* Находить возможность parallel run
* Работать с потребителем данных
Как декомпозировать?
* Если есть продукты - их можно выделять. привлечение, размещение
* По процессам. Вокруг таких систем есть системы-сателлиты, можно брать из них.
* По потребителям данных. Самый молодой и массовый стрим, там сложно.
В направлении 3 стрима, 40 продуктов, примерно 15 в стриме. Пример продукта - депозиты ФЛ. На стрим - менеджер стрима, бизнес-аналитик и команды, которые пишут микросервисы. Переводят 4 продукта одновременно. Продукт-менеджеры сами решают, насоклько они проводят реинжиниринг при переносе в новую систему, будут ли они переписывать логику при переходе. Может быть выделена фича-команда или задачи помещены в общий бэклог. С бизнесом ежеквартально согласуется список продуктов, которые переносятся.
На слайде была архитектура: каналы -> продуктовая логика -> core -> главная книга -> распространение данных -> потребители (риски, отчетность и др.) Фича-команда - продуктовая умеет детать доработки для всех командах. Может параллельно работать старая и новая продуктовая логика. Новая главная книга работает параллельно со старой, но мастер пока старая.
Как управлять таким переносом?
* Делать на маленькие шаги
* Исследовать через поставку
* Ставить целью спринта приближение к target-архитектуре
* Находить возможность parallel run
* Работать с потребителем данных
#EnterpriseAgile Сергей Паршиков. Оценка производительности команды в корпоративной среде. Доклад - summary личного опыта в разных компаниях. Основная идея: волюнтаризм руководителя - зло, потому что рождает обиды. Нужна прозрачная система, о которой договорились. На мой взгляд, основная ценность в другом, автоматические системы есть у многих, и волюнтаризм руководителя - средство исправить их перекосы. А фишка этой системы - dashboard, где показатели можно смотреть оперативно и корректировать свое поведение, а если система дает странные результаты - то можно вести анализ и корректировать систему не дожидаясь, пока она сработает с обидами. Плюс - команда же сама договорилась о такой системе. Сергей говорил в докладе, но без акцентов.
Теперь подробнее. Для начала - каждый руководитель должен обеспечить базу, без которой мотивация будет работать плохо. Вот они:
* Интересные задачи. Всех заставляют заниматься рутиной. Ему везло - предлагали много свободы.
* Клевый коллектив
* Достойная оплата труда
* Комфортные условия работы
Если условия обеспечили - можно начинать требовать. Заряженные сотрудники - это как бегущие быки. Хорошо бегут, только сносят все вокруг. Важно поставить заборчики, чтобы направить энергию в нужное русло. Именно эту роль выполняет KPI как инструмент оценки.
С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять - объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит.
Когда он придумывал систему, то держал две метафоры.
* Самомотивация - игра в теннис об стенку, когда ты должен каждый раз корректировать по своим действиям
* Бежать за чемпионами - смотреть на метрики коллег и сравнивать себя. Нужна честная, прозрачная, а не субъективная оценка.
Что входит в квартальную оценку?
* Продуктовые и бизнес-метрики - это всем понятно
* Голос клиента - это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.
* Эффективность производство - на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.
* eNPS: Критика - нейтральное - промоутеры. Формула: Промоутеры - Критика.
* Visibility - публичные выступления. Когда ты подталкиваешь выступать - ты подталкиваешь к выбору интересных задач. А еще - писать в корпоративный час о запуске фич - внутренняя видимость. Это реально поменяло словарь - когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.
Дальше эти оценки взвешиваются для общей оценки. И есть dashboard мониторинга: снежинка, тренды, сравнительные характеристики. Dashboard видят все.
Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится - систему можно менять. Открытые оценки и сравнение - команды начали сравнивать, задавать вопросы - и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно.
Теперь подробнее. Для начала - каждый руководитель должен обеспечить базу, без которой мотивация будет работать плохо. Вот они:
* Интересные задачи. Всех заставляют заниматься рутиной. Ему везло - предлагали много свободы.
* Клевый коллектив
* Достойная оплата труда
* Комфортные условия работы
Если условия обеспечили - можно начинать требовать. Заряженные сотрудники - это как бегущие быки. Хорошо бегут, только сносят все вокруг. Важно поставить заборчики, чтобы направить энергию в нужное русло. Именно эту роль выполняет KPI как инструмент оценки.
С KPI есть две популярные системы: (1) волюнтаризм руководителя, который субъективно ставит продуктивность и соответствие культуре; (2) бездушная оценка системы, к которой добавляется личный фонд руководителя. В обоих волюнтаризм приводит к обидам. Реально, на мой взгляд, проблема в том, что руководители норовят не просто поставить оценки, они еще часто не хотят внятно объяснять причины, и вообще делать результаты прозрачными. Их можно понять - объяснить без обид психологически сложно и требует времени, но обиды дает это. Впрочем, идея Сергея это тоже лечит.
Когда он придумывал систему, то держал две метафоры.
* Самомотивация - игра в теннис об стенку, когда ты должен каждый раз корректировать по своим действиям
* Бежать за чемпионами - смотреть на метрики коллег и сравнивать себя. Нужна честная, прозрачная, а не субъективная оценка.
Что входит в квартальную оценку?
* Продуктовые и бизнес-метрики - это всем понятно
* Голос клиента - это тоже продуктовая, но это не предвзятый взгляд клиента. Клиенты ставят звездочки за функционал, и это транслируются.
* Эффективность производство - на прошлой конференции был отдельный доклад и в презентации есть QR код со ссылками.
* eNPS: Критика - нейтральное - промоутеры. Формула: Промоутеры - Критика.
* Visibility - публичные выступления. Когда ты подталкиваешь выступать - ты подталкиваешь к выбору интересных задач. А еще - писать в корпоративный час о запуске фич - внутренняя видимость. Это реально поменяло словарь - когда пишешь новости сам осознаешь что сделал, позиционируешь в других терминах.
Дальше эти оценки взвешиваются для общей оценки. И есть dashboard мониторинга: снежинка, тренды, сравнительные характеристики. Dashboard видят все.
Важно, что систему придумал не он сам, они о ней договорились, ее ведет Excel. Не нравится - систему можно менять. Открытые оценки и сравнение - команды начали сравнивать, задавать вопросы - и выяснили, что методики оценки разные, начали разбираться. А вот его самого топы оценивают субъективно.
👍7❤2
Публикую отчет по #EnterpriseAgile - https://mtsepkov.org/AgileEnterprise-2024 Общее впечатление от конференции таково: у крупных компаний, которые хотят использовать Agile-методы всерьез на масштабах компании - получается это делать, технологии набрали зрелость. Используется OKR для координации по целям и фокусировки на развитии, а из SAFe выделилось ядро полезное ядро: PI Planing для синхронизации и получения реалистичных планов на большом масштабе, до 10 тысяч человек и более, и value stream train - средство управление потоками создания ценности с трассировкой до стратегических целей вместо обычного управления потоками задач, где выполнение задачи еще не гарантирует получения ценности для компании и потребителя. И в целом получается, что компания - не механистичный исполнительный механизм, а конструкция со свободными элементами, обладающими собственной волей, но действующими скоординировано.
Отчет включает опубликованное в ходе конференции и три доклада, конспекты которых я опубликовать не успел. Это - меньше половины докладов конференции, так как параллельно шло два потока, а на части слотов нетворкинг я предпочел докладам. Вот список.
* Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только).
* Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка.
* Анна Аверьянова из Робофинанс. Как OKR помог закрыть бизнес!
* Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile.
* Сергей Паршиков. Оценка производительности команды в корпоративной среде
* Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
* Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
* Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке
Отчет включает опубликованное в ходе конференции и три доклада, конспекты которых я опубликовать не успел. Это - меньше половины докладов конференции, так как параллельно шло два потока, а на части слотов нетворкинг я предпочел докладам. Вот список.
* Дмитрий Баштинский из HeadHunter. Принимаем решения об изменении процессов на основе данных (и не только).
* Максим Соловьев и Екатерина Елманова из Россельхозбанка. Внедрение Value Stream для ускорения цифровизации Банка.
* Анна Аверьянова из Робофинанс. Как OKR помог закрыть бизнес!
* Марина Кубанина. Технологии Доверия (ex-PwC). Про лоскутные одеяла, развод и Agile.
* Сергей Паршиков. Оценка производительности команды в корпоративной среде
* Сергей Лебедев и Максим Матвеев из YADRO. Тернистый путь к звездам: как мышление меняет компанию
* Евгений Михин из Яндекса. Continuous budgeting в портфельном управлении Яндекса
* Алексей Грабарник из Газпромбанка. Lean-управление портфелем стримов в Газпромбанке
❤2🔥1
Собрал и опубликовал на сайте отчет по #MergoConf https://mtsepkov.org/MergeConf-2024-Msk Конференция впервые прошла в Москве. Два дня, 8 потоков, и среди докладов доклады были очень содержательные, конспект которых не поместился один комментарий. Я сам тоже выступал. А записей конференции не будет, так что пропущенные доклады пропали безвозвратно. Так что читайте мой конспект, хотя докладов в нем мало. А организаторам хочу пожелать успехов.
🔥6
#AnalystDays Татьяна Половинкина из НЕОФЛЕКС. В чем смысл цели? Офигенно крутой доклад про работу с целеполаганием по X-матрице Стратегия - Тактика - Задачи (гипотезы) - Результаты. Матрица - потому что у тебя не обычное дерево, ты на каждом шаге заполняешь взаимную зависимость и отсекаешь то, что оказывается малозначимым. По каждому такту - лайфхаки, и иллюстрация сквозным примером.
К докладу была интересная подводка про смену эпох и про приход человекоцентричного мира, которые не про счастье людей, а про счастливых людей, которые лучше работают в компаниях. Ее я прокомменитирую в конце. А сейчас - основное содержание.
Цель - желаемый осознанный результат. Но желаниям человека свойственна нерациональность и субъективность, нельзя сделать, чтобы человек захотел сделать хранилище данных, он может захотеть лишь самостоятельно. Средство для этого - осознанность. X-матрица - способ осознанной работы с целями. Стратегия - тактика - задачи - результаты. Хотя я бы назвал его способом рационально работать с целями, потому что эмоциональную и мотивационную компоненты он не охватывает.
Лайфхаки стратегии.
* Надо максимально узнавать видение, стратегию компании, чтобы реализоваться, чтобы понимать зону возможностей в компании. А компания должна регулярно транслировать, что происходит. Например, компания живет за счет выполнения проектов, и сотрудникам надо показывать возможности текущих проектов. И это - не однонаправленный вектор: инициативный сотрудник может попробовать расширить стратегию, включив в нее работу с продуктами - если видит в этом счастье. Но это непросто.
* Вплетите личную мотивацию в стратегические намерения компании.
- Хочу работать в известной компании - хочу прокачать свой бренд, личный и компании
- Хочу работать в востребованной компании с возможностью обучаться - хочу работать с профи.
- Хочу работать с друзьями и расти - приводите друзей, компания будет расти
* Нет плохой и правильной цели. Есть ценность для вас.
- Что изменится, если достигнешь цели
- Что будет, если не достигнешь
- Ресурсы которые потратим и сохраним.
Если человек хочет машину, чтобы замечали - может, ему достаточно просто перестать скромничать и его начнут замечать?
Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
* Проверка фокусировки. Хочу 1 млн прибыли - а что делать будешь сейчас? - буду путешествовать. Стоп. Или зарабатывать, или путешествовать. Ну или покажи связь.
* Тактика "от" и "к" - Чего хотите достигнуть и что сейчас мешает.
* Гибкость. Мелкие задачи, появляются новые возможности и ограничения. Нужен ли этот бой сейчас?
Лайфхаки задач.
* Цель - не средство. Не прочитать книгу, а стать книголюбом, или изучить и применять знания. Изучить курс - не цель.
* Помните, что задача - это гипотеза! Работайте по HADI циклу проверки гипотез
* Эффект Икеи или Брейнсторм. Когда хотите достичь цели - позвольте людям набросать гипотез, не давайте пути сами. Когда делаешь мебель своими руками - она чудесна. Так и с любыми путями.
* Людей, которые хотят знать алгоритмы, алгоритмы (ИИ) заменят в первую очередь.
Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются.
Лайфхаки результата.
* Проверка фокусировки. Метрики, которые мы будем измерять. Основанные на ценности, целе, результате, а не на исполнении задач. Но задачи тоже меряем - это оценивает затраченные ресурсы.
* Умение ошибаться. Это как отладка кода - мы же ошибаемся, и это не страшно. Так и со всем остальным. Надо извлекать выводы.
Матрица: какие задачи-гипотезы на какие метрики результата влияют. Там тоже индикатор - насколько гипотеза влияет, тут отсев гипотез.
К докладу была интересная подводка про смену эпох и про приход человекоцентричного мира, которые не про счастье людей, а про счастливых людей, которые лучше работают в компаниях. Ее я прокомменитирую в конце. А сейчас - основное содержание.
Цель - желаемый осознанный результат. Но желаниям человека свойственна нерациональность и субъективность, нельзя сделать, чтобы человек захотел сделать хранилище данных, он может захотеть лишь самостоятельно. Средство для этого - осознанность. X-матрица - способ осознанной работы с целями. Стратегия - тактика - задачи - результаты. Хотя я бы назвал его способом рационально работать с целями, потому что эмоциональную и мотивационную компоненты он не охватывает.
Лайфхаки стратегии.
* Надо максимально узнавать видение, стратегию компании, чтобы реализоваться, чтобы понимать зону возможностей в компании. А компания должна регулярно транслировать, что происходит. Например, компания живет за счет выполнения проектов, и сотрудникам надо показывать возможности текущих проектов. И это - не однонаправленный вектор: инициативный сотрудник может попробовать расширить стратегию, включив в нее работу с продуктами - если видит в этом счастье. Но это непросто.
* Вплетите личную мотивацию в стратегические намерения компании.
- Хочу работать в известной компании - хочу прокачать свой бренд, личный и компании
- Хочу работать в востребованной компании с возможностью обучаться - хочу работать с профи.
- Хочу работать с друзьями и расти - приводите друзей, компания будет расти
* Нет плохой и правильной цели. Есть ценность для вас.
- Что изменится, если достигнешь цели
- Что будет, если не достигнешь
- Ресурсы которые потратим и сохраним.
Если человек хочет машину, чтобы замечали - может, ему достаточно просто перестать скромничать и его начнут замечать?
Тактика - это вектор действия в направлении стратегической цели. Лайфхаки тактики.
* Проверка фокусировки. Хочу 1 млн прибыли - а что делать будешь сейчас? - буду путешествовать. Стоп. Или зарабатывать, или путешествовать. Ну или покажи связь.
* Тактика "от" и "к" - Чего хотите достигнуть и что сейчас мешает.
* Гибкость. Мелкие задачи, появляются новые возможности и ограничения. Нужен ли этот бой сейчас?
Лайфхаки задач.
* Цель - не средство. Не прочитать книгу, а стать книголюбом, или изучить и применять знания. Изучить курс - не цель.
* Помните, что задача - это гипотеза! Работайте по HADI циклу проверки гипотез
* Эффект Икеи или Брейнсторм. Когда хотите достичь цели - позвольте людям набросать гипотез, не давайте пути сами. Когда делаешь мебель своими руками - она чудесна. Так и с любыми путями.
* Людей, которые хотят знать алгоритмы, алгоритмы (ИИ) заменят в первую очередь.
Матрица: какие идеи на какие тактические вектора движения работают. Ставят баллы. И это отсекает гипотезы, которые в тактику не укладываются.
Лайфхаки результата.
* Проверка фокусировки. Метрики, которые мы будем измерять. Основанные на ценности, целе, результате, а не на исполнении задач. Но задачи тоже меряем - это оценивает затраченные ресурсы.
* Умение ошибаться. Это как отладка кода - мы же ошибаемся, и это не страшно. Так и со всем остальным. Надо извлекать выводы.
Матрица: какие задачи-гипотезы на какие метрики результата влияют. Там тоже индикатор - насколько гипотеза влияет, тут отсев гипотез.
👍3🔥2
Кейс, на котором дальше был разбор - ее стратегическая цель. Была 2 года назад - максимально расширить компетенцию SQL у сотрудников - они data-аналитики. У нее: изучение навыка, применение навыка, трансляция навыка (это обязательно, синхронизация с другими). Шаги задач и результатов - в презентации были матрицы идей с конкретными баллами. Картинка оценки часто удивляла, оказывалось, что гипотеза, которая кажется перспективной, набирала меньше всего.
Лайфхаки синхронизации
* Умение делегировать
* Поймай мяч. Кидаем проблему сотрудникам, они придумывают. И приходят за ресурсами - время, сервера - и это корректирует цель
Выводы.
* Вплетите личную мотивацию в стратегию компании. Человек не может работать над задачами без смысла
* Фокусировка
* Работа с гипотезами
* Синхронизация
Результат - человек: вовлеченный, осознанный и гибкий.
Есть ли трудности при применении подхода? Есть люди, которым трудно тратить время на осознание, легче попробовать. И им надо объяснить, в чем польза подумать над смыслом - меньше переделывать.
Выгорание - накопление конфликтов, его не бывает, если приносит удовольствие. ИТ-компания зарабатывает на проектах. И либо ты встраиваешься, либо переделываешь систему, например, перефокусируешься с проектов на продукты, и это расширяет область возможностей - но это очень зависит от твоих ресурсов.
Доклад очень хороший. Для тех, кто идет в жизни по плану. Есть альтернативная стратегия: ищем подходящие случаи. Там тоже нужна осознанность, нужно представить те варианты, которые ты видишь как перспективные, к которым внимателен в окружающем мире - это называется предпринимательская бдительность, об этом есть отдельные книги. А еще есть деление людей на дайверов и сканеров от Барбары Шер. Метод подходит для обоих, но наполнение будет сильно различаться, на мой взгляд.
А теперь - к началу доклада. Подводка была через идею эволюции миров: аграрный - индустриальный - информационный - человекоцентричный. Человекоцентриный - потому что ИИ пока лишь воспроизводит то, что придумано человеком. Важно, что человекоцентричность - не про любовь к людям, это то, что счастливые люди работают лучше. И если бы человек был счастлив в компании - он бы не искал счастья за стороне. Зарплата - способ купить счастье за счет денег.
Я тут не могу не прокомментировать. Про разделение информационного и человекоцентричного мира - интересная идея, но надо подумать про границы. На мой взгляд, есть одна граница между индустриальным миром и тем, что за ним. Я называю то, что за ним - цифровым миром, так как термин постиндустриальный уже приобрел иной смысл. Можно в индустриальном выделить отдельную фазу после фабрик (первая промышленная революция) и конвейера (вторая), открытую научно-технической револуцией 1960-х, и неточно назвать ее информационным. Или все-таки информационный мир - начало того, что будет после индустриального мира - и тогда именно он будет развиваться.
Лайфхаки синхронизации
* Умение делегировать
* Поймай мяч. Кидаем проблему сотрудникам, они придумывают. И приходят за ресурсами - время, сервера - и это корректирует цель
Выводы.
* Вплетите личную мотивацию в стратегию компании. Человек не может работать над задачами без смысла
* Фокусировка
* Работа с гипотезами
* Синхронизация
Результат - человек: вовлеченный, осознанный и гибкий.
Есть ли трудности при применении подхода? Есть люди, которым трудно тратить время на осознание, легче попробовать. И им надо объяснить, в чем польза подумать над смыслом - меньше переделывать.
Выгорание - накопление конфликтов, его не бывает, если приносит удовольствие. ИТ-компания зарабатывает на проектах. И либо ты встраиваешься, либо переделываешь систему, например, перефокусируешься с проектов на продукты, и это расширяет область возможностей - но это очень зависит от твоих ресурсов.
Доклад очень хороший. Для тех, кто идет в жизни по плану. Есть альтернативная стратегия: ищем подходящие случаи. Там тоже нужна осознанность, нужно представить те варианты, которые ты видишь как перспективные, к которым внимателен в окружающем мире - это называется предпринимательская бдительность, об этом есть отдельные книги. А еще есть деление людей на дайверов и сканеров от Барбары Шер. Метод подходит для обоих, но наполнение будет сильно различаться, на мой взгляд.
А теперь - к началу доклада. Подводка была через идею эволюции миров: аграрный - индустриальный - информационный - человекоцентричный. Человекоцентриный - потому что ИИ пока лишь воспроизводит то, что придумано человеком. Важно, что человекоцентричность - не про любовь к людям, это то, что счастливые люди работают лучше. И если бы человек был счастлив в компании - он бы не искал счастья за стороне. Зарплата - способ купить счастье за счет денег.
Я тут не могу не прокомментировать. Про разделение информационного и человекоцентричного мира - интересная идея, но надо подумать про границы. На мой взгляд, есть одна граница между индустриальным миром и тем, что за ним. Я называю то, что за ним - цифровым миром, так как термин постиндустриальный уже приобрел иной смысл. Можно в индустриальном выделить отдельную фазу после фабрик (первая промышленная революция) и конвейера (вторая), открытую научно-технической револуцией 1960-х, и неточно назвать ее информационным. Или все-таки информационный мир - начало того, что будет после индустриального мира - и тогда именно он будет развиваться.
👍3🔥1
Теперь отдельно про человекоцентричность. С одной стороны, я впервые засек в 2019 смену социального контракта сотрудника от компетентной работы за зарплату к искренней работы на цели компании в обмен на условия для счастья на работе, у меня об этом есть статьи и доклады. Но, с другой стороны, тут важная часть - счастье на работе. Я решительно не согласен с японской концепцией, в которой человек приходит в корпорацию на всю жизнь и работает исключительно на благо этой корпорации. И не имеет иного смысла жизни, вплоть до того, что при увольнении кончает жизнь самоубийством - кейсы известны. И с вариантом, к которому пришли некоторые американские компании (и не только они): мы все сделаем, чтобы вы могли круглосуточно не выходить с места работы, я тоже не согласен. Потому что жизнь человека не ограничивается работой. И там есть не только досуг и работа в профессиональных сообществах, но и социальные связи, а также рождение и воспитание детей. Конечно, есть концепт, что людей на Земле и так слишком много, поэтому рожать новых не нужно, но, по-моему, он доказал свою несостоятельность. Так что тут важны акценты. А Харари, на которого Татьяна ссылалась в вопросах, на мой взгляд, мыслит в рамках этих концептов. Так что индивидуальное и субъективное счастье - правильно.
👍6❤3🔥3