Привет!
Здесь мы делимся подходами и практиками в менеджменте #management и разработке #development. Опытом компании, tips and tricks.
Послушать наши голоса можно в подкасте SmartHead Space 🎙
Стать частью команды SmartHead 👉 https://smarthead.ru/#vacancies
По организационным вопросам — @doctorsolberg
Здесь мы делимся подходами и практиками в менеджменте #management и разработке #development. Опытом компании, tips and tricks.
Послушать наши голоса можно в подкасте SmartHead Space 🎙
Стать частью команды SmartHead 👉 https://smarthead.ru/#vacancies
По организационным вопросам — @doctorsolberg
Telegram
SmartHead Space
Привет! Это подкаст про развитие в IT и за ее пределами.
Канал, где собраны наши лучшие практики в менеджменте и разработке 👉 https://news.1rj.ru/str/smarthead
Канал, где собраны наши лучшие практики в менеджменте и разработке 👉 https://news.1rj.ru/str/smarthead
#development
Ни для кого сейчас не новость, что пользовательский опыт (UX, опыт взаимодействия) важен. Важно не только что можно делать с помощью продукта, но и как — насколько просто и удобно. Хороший UX в интерфейсах ведёт пользователя к решению задачи, помогает не отвлекаться на борьбу с неудобным интерфейсом, снижает когнитивную нагрузку, формирует положительное эмоциональное подкрепление.
Developer Experience (DX) — это частный случай UX, когда в качестве пользователя выступает разработчик, а в качестве продукта — язык программирования, фреймворк, технология, сервис или любой другой инструмент.
Продукт с хорошим DX ведёт разработчика, даёт возможность сфокусироваться на решении задачи, а не возиться в конфигурации инструмента. Хороший DX повышает удобство и скорость разработки, даёт уверенность в отсутствии ошибок и комфорт в работе.
Ни для кого сейчас не новость, что пользовательский опыт (UX, опыт взаимодействия) важен. Важно не только что можно делать с помощью продукта, но и как — насколько просто и удобно. Хороший UX в интерфейсах ведёт пользователя к решению задачи, помогает не отвлекаться на борьбу с неудобным интерфейсом, снижает когнитивную нагрузку, формирует положительное эмоциональное подкрепление.
Developer Experience (DX) — это частный случай UX, когда в качестве пользователя выступает разработчик, а в качестве продукта — язык программирования, фреймворк, технология, сервис или любой другой инструмент.
Продукт с хорошим DX ведёт разработчика, даёт возможность сфокусироваться на решении задачи, а не возиться в конфигурации инструмента. Хороший DX повышает удобство и скорость разработки, даёт уверенность в отсутствии ошибок и комфорт в работе.
#development
Что отличает инструмент с хорошим DX?
— Быстрый старт. Он не требует много времени в начале, а погружает по мере необходимости.
— Отличная документация. Понятный quick start, хорошая структура, полнота и актуальность.
— Хорошая коммуникация с пользователем через интерфейсы взаимодействия, в том числе cli и API.
— Адекватные параметры по умолчанию. Инструмент не требует большой конфигурации, возможно следует принципу Convention over Configuration. Он не заставляет разработчика принимать решения там, где это не требуется. А там, где требуется изменить поведение по умолчанию, даёт возможность это сделать.
— Следование стандартам индустрии и идиомам платформы. Стиль кода или наименование методов в API не вызывают удивления.
— Open source и использование возможностей сообщества разработчиков.
Хорошим DX следует не только пользоваться, но и производить самим. При разработке стоит задумываться о DX и разработчиках, которые пользуются нашим кодом.
Что отличает инструмент с хорошим DX?
— Быстрый старт. Он не требует много времени в начале, а погружает по мере необходимости.
— Отличная документация. Понятный quick start, хорошая структура, полнота и актуальность.
— Хорошая коммуникация с пользователем через интерфейсы взаимодействия, в том числе cli и API.
— Адекватные параметры по умолчанию. Инструмент не требует большой конфигурации, возможно следует принципу Convention over Configuration. Он не заставляет разработчика принимать решения там, где это не требуется. А там, где требуется изменить поведение по умолчанию, даёт возможность это сделать.
— Следование стандартам индустрии и идиомам платформы. Стиль кода или наименование методов в API не вызывают удивления.
— Open source и использование возможностей сообщества разработчиков.
Хорошим DX следует не только пользоваться, но и производить самим. При разработке стоит задумываться о DX и разработчиках, которые пользуются нашим кодом.
#management
Мы часто слышим от руководителей и собственников бизнеса тезисы вроде «Без цели нет развития. Четко пойми чего ты хочешь, поставь цель, определи шаги ее достижения и вперед!» У них много производных:
— Нужно улучшить результаты отдела? Установи планы и метрики для подчиненных, задай цели им!
— Нужны продажи? Сделай план продаж и пусть люди работают на его достижение!
— Не можешь четко сказать, что ты хочешь и поставить цель? Так бизнес не делается, ты не прав. Это все игры и самореализация, а не бизнес.
Давайте разберемся и поставим эти утверждения под сомнение.
Мы часто слышим от руководителей и собственников бизнеса тезисы вроде «Без цели нет развития. Четко пойми чего ты хочешь, поставь цель, определи шаги ее достижения и вперед!» У них много производных:
— Нужно улучшить результаты отдела? Установи планы и метрики для подчиненных, задай цели им!
— Нужны продажи? Сделай план продаж и пусть люди работают на его достижение!
— Не можешь четко сказать, что ты хочешь и поставить цель? Так бизнес не делается, ты не прав. Это все игры и самореализация, а не бизнес.
Давайте разберемся и поставим эти утверждения под сомнение.
#management
Бизнес — это деятельность, направленная на систематическое получение прибыли. Постановка целей не гарантирует, что вы начнете зарабатывать больше. Какие проблемы возникают на этапе разработки целей:
— Цели не всегда возможно поставить качественно, например, по SMART. Во многих сферах бизнеса и ситуациях мы не настолько хорошо владеем контекстом и управляем влиянием факторов, чтобы ставить аргументированные и достижимые цели.
— Вы можете проработать их до мельчайших деталей. Но качественная проработка и декомпозиция цели до атомарного уровня занимает огромное количество времени.
— Очень часто самым важным компонентом цели ставят срок. Но иногда другие факторы гораздо важнее. Например, способ ее достижения.
— Поставить цель мало. Ее нужно сбалансировать с другими процессами, чтобы не допустить «провалов» по другим фронтам, которые в данную цель не попали. Банальный пример — поставить амбициозные цели по продажам услуг и обнаружить, что при выполненной цели качество услуг сильно упало, а сотрудники производственных отделов обновили резюме на HH.
Даже после постановки цели могут принести много проблем. Например, с любой нетривиальной целью в нагрузку идет рюкзак стресса. Зафиксировав четкую цель, сложно отказаться от следования к ней, даже если она уже потеряла актуальность. Особенно если над одной целью работает группа людей. Часто встречается когнитивное искажение невозвратных потерь. Это ведет к тому, что вы не получаете удовлетворения от процесса и быстро выгораете.
Когда цель зафиксирована руководством «сверху» часто проще «вдарить» ценой ресурса своего организма и потом всегда иметь возможность сказать: «Ну я приложил все возможные усилия!». Но правильнее было бы пойти и сказать: «Знаете, я не понимаю, откуда вы взяли эту цель и почему я в нее должен верить. Кажется, у нас должны быть немного другие цели».
Если цель не достигнута — это удар по самооценке. Упорство — это хорошо, но не когда оно приводит к потере здравого смысла. Если создание внешних признаков достижения поставленной цели становится важнее её сути или начинает противоречить целям более высокого уровня (например, повышения благосостояния компании) стоит остановиться и подумать, нужна ли она.
Культ целеориентированности — причина огромного количества депрессий и профессиональной деформации. Можно считать нормальным, когда состоявшиеся профессионалы «выгорают», отказываются от гонки за целями и занимаются ремеслом на Бали. А можно ведь просто до этого не доводить 🙂
Как может быть иначе? Ответим в следующем посте.
Бизнес — это деятельность, направленная на систематическое получение прибыли. Постановка целей не гарантирует, что вы начнете зарабатывать больше. Какие проблемы возникают на этапе разработки целей:
— Цели не всегда возможно поставить качественно, например, по SMART. Во многих сферах бизнеса и ситуациях мы не настолько хорошо владеем контекстом и управляем влиянием факторов, чтобы ставить аргументированные и достижимые цели.
— Вы можете проработать их до мельчайших деталей. Но качественная проработка и декомпозиция цели до атомарного уровня занимает огромное количество времени.
— Очень часто самым важным компонентом цели ставят срок. Но иногда другие факторы гораздо важнее. Например, способ ее достижения.
— Поставить цель мало. Ее нужно сбалансировать с другими процессами, чтобы не допустить «провалов» по другим фронтам, которые в данную цель не попали. Банальный пример — поставить амбициозные цели по продажам услуг и обнаружить, что при выполненной цели качество услуг сильно упало, а сотрудники производственных отделов обновили резюме на HH.
Даже после постановки цели могут принести много проблем. Например, с любой нетривиальной целью в нагрузку идет рюкзак стресса. Зафиксировав четкую цель, сложно отказаться от следования к ней, даже если она уже потеряла актуальность. Особенно если над одной целью работает группа людей. Часто встречается когнитивное искажение невозвратных потерь. Это ведет к тому, что вы не получаете удовлетворения от процесса и быстро выгораете.
Когда цель зафиксирована руководством «сверху» часто проще «вдарить» ценой ресурса своего организма и потом всегда иметь возможность сказать: «Ну я приложил все возможные усилия!». Но правильнее было бы пойти и сказать: «Знаете, я не понимаю, откуда вы взяли эту цель и почему я в нее должен верить. Кажется, у нас должны быть немного другие цели».
Если цель не достигнута — это удар по самооценке. Упорство — это хорошо, но не когда оно приводит к потере здравого смысла. Если создание внешних признаков достижения поставленной цели становится важнее её сути или начинает противоречить целям более высокого уровня (например, повышения благосостояния компании) стоит остановиться и подумать, нужна ли она.
Культ целеориентированности — причина огромного количества депрессий и профессиональной деформации. Можно считать нормальным, когда состоявшиеся профессионалы «выгорают», отказываются от гонки за целями и занимаются ремеслом на Бали. А можно ведь просто до этого не доводить 🙂
Как может быть иначе? Ответим в следующем посте.
👍1
#management
Как может быть иначе?
Можно поставить бегуну цель «пробежать стометровку за 9 секунд на ближайшей Олимпиаде». И он будет усердно тренироваться, чтобы ее достичь. Но профессиональный спорт высоких достижений — не наша область деятельности. Но готовы ли мы за достижение карьерных целей постоянно платить здоровьем, важными отношениями и чувством собственного достоинства? Или хотим просто «хорошо себя чувствовать и быстро бегать»? Вероятно, нам лучше действовать от намерения вроде «бегать быстрее».
Это намерение соответствует нашему внутреннему желанию. Оно не создает неоправданных ожиданий и иллюзий, не нагружает нас стрессом и чувством вины в случае тактических неудач. А ведь они отнимают энергию, которую мы могли бы потратить на то чтобы становиться лучше.
При этом, если мы честны с собой и достаточно компетентны, то качество деятельности при работе от намерения будет не хуже, чем при работе к цели.
Чем намерение отличается от желания?
Желание — это фантазия. Желать мы можем что угодно, лежа на диване. Иногда нам достаточно просто представить свое красивое будущее или посмотреть мотивирующее видео на ютьюб, чтобы ощутить удовлетворенность и ничего не предпринимать.
Намерение — это желание + готовность действовать. Ошибочно считать, что отсутствие целей и наличие желаний — это тоже продуктивный образ деятельности в бизнесе, хотя образом жизни это вполне может быть. Намерение требует воплощения, активных действий, влияющих на внешний мир, приближающих исполнение желания.
Итого:
1. Целеполагание — это инструмент реализации собственных намерений. Им нужно пользоваться с умом, там, где он принесет больше пользы чем вреда. Не забывайте задаваться вопросом: «Эти вред / польза возникают в тактической перспективе или в стратегической?». Совсем без целей адекватная жизнь в рынке невозможна. Но лучше не ставить их, чем ставить «плохие».
2. Для благоприятного существования крайне важно соответствие цели внутреннему намерению.
3. В стратегической перспективе намерение приводит к лучшим результатам, чем цепочка целей. При этом с меньшими затратами энергии.
Как может быть иначе?
Можно поставить бегуну цель «пробежать стометровку за 9 секунд на ближайшей Олимпиаде». И он будет усердно тренироваться, чтобы ее достичь. Но профессиональный спорт высоких достижений — не наша область деятельности. Но готовы ли мы за достижение карьерных целей постоянно платить здоровьем, важными отношениями и чувством собственного достоинства? Или хотим просто «хорошо себя чувствовать и быстро бегать»? Вероятно, нам лучше действовать от намерения вроде «бегать быстрее».
Это намерение соответствует нашему внутреннему желанию. Оно не создает неоправданных ожиданий и иллюзий, не нагружает нас стрессом и чувством вины в случае тактических неудач. А ведь они отнимают энергию, которую мы могли бы потратить на то чтобы становиться лучше.
При этом, если мы честны с собой и достаточно компетентны, то качество деятельности при работе от намерения будет не хуже, чем при работе к цели.
Чем намерение отличается от желания?
Желание — это фантазия. Желать мы можем что угодно, лежа на диване. Иногда нам достаточно просто представить свое красивое будущее или посмотреть мотивирующее видео на ютьюб, чтобы ощутить удовлетворенность и ничего не предпринимать.
Намерение — это желание + готовность действовать. Ошибочно считать, что отсутствие целей и наличие желаний — это тоже продуктивный образ деятельности в бизнесе, хотя образом жизни это вполне может быть. Намерение требует воплощения, активных действий, влияющих на внешний мир, приближающих исполнение желания.
Итого:
1. Целеполагание — это инструмент реализации собственных намерений. Им нужно пользоваться с умом, там, где он принесет больше пользы чем вреда. Не забывайте задаваться вопросом: «Эти вред / польза возникают в тактической перспективе или в стратегической?». Совсем без целей адекватная жизнь в рынке невозможна. Но лучше не ставить их, чем ставить «плохие».
2. Для благоприятного существования крайне важно соответствие цели внутреннему намерению.
3. В стратегической перспективе намерение приводит к лучшим результатам, чем цепочка целей. При этом с меньшими затратами энергии.
👍1
#development #management
В своей работе мы особое внимание уделяем качеству. О подходе к его обеспечению рассказал наш технический директор Рамиль Аминов.
https://habr.com/ru/post/549130/
В своей работе мы особое внимание уделяем качеству. О подходе к его обеспечению рассказал наш технический директор Рамиль Аминов.
https://habr.com/ru/post/549130/
Хабр
Качество вместо контроля качества
Говоря о качестве, обычно имеют ввиду некое соответствие требованиям. Часто под требованиями подразумевают те, что явно выдвинул заказчик, аналитик или кто-то другой, кто ставит задачи. Хуже, если они...
👍2
#development
Бывает, что разработчику жалко выкинуть или переписать свой код. Он шел к нему, писал, тратил своё время. К тому же, задача в таск-трекере сделана и закрыта.
Но в реальности невозможно избежать изменений. Не только потому, что сложно сделать хорошо с первого раза. А потому, что изменения и развитие в «живых» проектах и продуктах — это необходимость. Если не улучшать продукт, то отстанешь от конкурентов.
Цель разработки — не в написании кода самого по себе, а в решении с помощью него более высокоуровневых задач. Код должен иметь достаточную гибкость и устойчивость к изменениям, чтобы новые задачи можно было решать проще.
Не стоит рассматривать кодовую базу как нечто, что мы построили и сдали. Нужно относиться к ней как к среде, в которой мы живём. Нужно её обустраивать, делать комфортной и удобной для работы, не захламлять и оставлять место для чего-то нового.
В такой парадигме и выкидывать код, как старый хлам, приятно.
Бывает, что разработчику жалко выкинуть или переписать свой код. Он шел к нему, писал, тратил своё время. К тому же, задача в таск-трекере сделана и закрыта.
Но в реальности невозможно избежать изменений. Не только потому, что сложно сделать хорошо с первого раза. А потому, что изменения и развитие в «живых» проектах и продуктах — это необходимость. Если не улучшать продукт, то отстанешь от конкурентов.
Цель разработки — не в написании кода самого по себе, а в решении с помощью него более высокоуровневых задач. Код должен иметь достаточную гибкость и устойчивость к изменениям, чтобы новые задачи можно было решать проще.
Не стоит рассматривать кодовую базу как нечто, что мы построили и сдали. Нужно относиться к ней как к среде, в которой мы живём. Нужно её обустраивать, делать комфортной и удобной для работы, не захламлять и оставлять место для чего-то нового.
В такой парадигме и выкидывать код, как старый хлам, приятно.
👍2
#management
Как осознанно подойти к управлению ожиданиями в проектной деятельности? И зачем?
Do и Don't управления ожиданиями в новой статье нашего руководителя отдела по управлению проектами Максима Никитцова.
Открытый микрофон — в комментариях, поделитесь своими принципами, правилами и лайфхаками в управлении ожиданиями!
Как осознанно подойти к управлению ожиданиями в проектной деятельности? И зачем?
Do и Don't управления ожиданиями в новой статье нашего руководителя отдела по управлению проектами Максима Никитцова.
Открытый микрофон — в комментариях, поделитесь своими принципами, правилами и лайфхаками в управлении ожиданиями!
vc.ru
Об управлении ожиданиями в проектной деятельности
Привет! Меня зовут Максим Никитцов, я руководитель проектов в компании SmartHead. Мы занимаемся заказной разработкой цифровых продуктов. Как и всем в индустрии нам важно, чтобы заказчики были довольны проделанной работой. Это возможно, если результат принесёт…
👍1
#development
Наш друг и партнер Максим Аршинов опубликовал классную статью. Она про то, как делать MVP быстро и достаточно качественно, чтобы потом не выкидывать. Один из подходов — использовать максимум готовых решений. Вот и мы ссылку даем, а не свое пишем 🙂
Хочется отметить важный тезис об Impact mapping. Часто сталкиваемся с тем, что недостаточно четкое и трассируемое понимание конечных бизнес-целей приводит к «плохим» требованиям. Они, в свою очередь, приводят к «плохому» продукту, который дольше разрабатывать и сложнее развивать.
Работая над новыми продуктами, мы должны понимать, как каждая конкретная фича явным образом связана с достижением конечной бизнес-цели?
А еще про качество в MVP мы говорили с Максимом в подкасте SmartHead Space. Если послушать удобнее чем прочитать, то держите ссылки: Яндекс.Музыка, Apple Podcast и SoundCloud.
Наш друг и партнер Максим Аршинов опубликовал классную статью. Она про то, как делать MVP быстро и достаточно качественно, чтобы потом не выкидывать. Один из подходов — использовать максимум готовых решений. Вот и мы ссылку даем, а не свое пишем 🙂
Хочется отметить важный тезис об Impact mapping. Часто сталкиваемся с тем, что недостаточно четкое и трассируемое понимание конечных бизнес-целей приводит к «плохим» требованиям. Они, в свою очередь, приводят к «плохому» продукту, который дольше разрабатывать и сложнее развивать.
Работая над новыми продуктами, мы должны понимать, как каждая конкретная фича явным образом связана с достижением конечной бизнес-цели?
А еще про качество в MVP мы говорили с Максимом в подкасте SmartHead Space. Если послушать удобнее чем прочитать, то держите ссылки: Яндекс.Музыка, Apple Podcast и SoundCloud.
Хабр
Как запустить MVP и не превратить его в технический долг
Последние пять лет я работаю в аутсорсинге, поэтому часто занимаюсь запуском новых продуктов. Чаще всего жизненный цикл создаваемых нами приложения начинается с разработки так называемого MVP (...
👍1
#management
Матричная структура: плюсы и минусы.
Часть 1 из 3. Что это за структура?
В SmartHead матричная структура управления. Такая структура помогает создавать гибкие команды и быстро перестраиваться, но есть и подводные камни. В этой серии постов мы расскажем, как их обойти. Начнем с матчасти: что такое матричная структура управления и как она работает.
Матричная структура подразумевает двойное подчинение сотрудника: в вертикальной плоскости и горизонтальной.
Матричная структура: плюсы и минусы.
Часть 1 из 3. Что это за структура?
В SmartHead матричная структура управления. Такая структура помогает создавать гибкие команды и быстро перестраиваться, но есть и подводные камни. В этой серии постов мы расскажем, как их обойти. Начнем с матчасти: что такое матричная структура управления и как она работает.
Матричная структура подразумевает двойное подчинение сотрудника: в вертикальной плоскости и горизонтальной.
Вертикальная плоскость строится вокруг компетенций и подходов. Она отвечает за достижение стратегических целей: повысить показатели эффективности и удовлетворенности, увеличить выручку, развить компетенции, внедрить новые подходы. Вертикаль представляет собой отделы направлений разработки, дизайна, маркетинга во главе с руководителем. Как у нас: руководитель отдела frontend-разработки принимает решение о найме, организует обмен лучшими практиками, следит за технологическим вектором и за качеством работы сотрудников, их развитием и «майндсетом».
Горизонтальная плоскость организована вокруг проектов или продуктов. За процессами и проектными ограничениями следит руководитель проекта. В команде работают сотрудники разных отделов: UX/UI-дизайнеры, разработчики, тестировщики. Горизонталь фокусируется на тактических задачах: сдать проект в срок и качественно, выпустить фичу, закрыть текущую потребность клиента. Команда работает автономно, поэтому ориентируется на конечный результат проекта и гибко реагирует на изменения, при этом остаётся в рамках общекорпоративных принципов.
Матричная структура хороша для проектной деятельности. Но иногда подход используется и в компаниях, построенных вокруг одного продукта (возможно, вы уже слышали про кейс Spotify. Однако, не всё так просто: зачастую в матричных структурах возникает конфликт интересов горизонталей и вертикалей. Скоро расскажем, почему так происходит.
Горизонтальная плоскость организована вокруг проектов или продуктов. За процессами и проектными ограничениями следит руководитель проекта. В команде работают сотрудники разных отделов: UX/UI-дизайнеры, разработчики, тестировщики. Горизонталь фокусируется на тактических задачах: сдать проект в срок и качественно, выпустить фичу, закрыть текущую потребность клиента. Команда работает автономно, поэтому ориентируется на конечный результат проекта и гибко реагирует на изменения, при этом остаётся в рамках общекорпоративных принципов.
Матричная структура хороша для проектной деятельности. Но иногда подход используется и в компаниях, построенных вокруг одного продукта (возможно, вы уже слышали про кейс Spotify. Однако, не всё так просто: зачастую в матричных структурах возникает конфликт интересов горизонталей и вертикалей. Скоро расскажем, почему так происходит.
👍2
#management
Матричная структура: плюсы и минусы.
Часть 2 из 3. Конфликт плоскостей.
Как мы писали выше, особенность матричных структур — это столкновение интересов горизонтальной и вертикальной плоскостей. Его можно свести к конфликту тактики и стратегии. Что важнее: успеть сделать фичу к релизу или внедрить технологию и увеличить продуктивность в будущем? Адаптировать джуна или привлечь опытного разработчика и снять риски качества и сроков?
Конфликт — это нормально. Матричная структура провоцирует конфликты, и они помогают найти наилучшие решения. Проблемой становится не сам конфликт, а неспособность разрешить его конструктивно. У превращения конфликтов в проблемы могут быть следующие предпосылки:
❗️ Нечетко разделена ответственность между плоскостями.
То есть непонятно, кто должен принять решение при пересечении интересов. Что можно решить автономно, а что нужно обсудить совместно. Например, кто согласовывает сроки отпуска дизайнера: руководитель проекта, который отвечает за процессы, или руководитель отдела, обсуждавший с ним условия работы?
❗️ Не соблюдается принцип win-win при решении конфликта.
Вместо этого горизонталь и вертикаль соревнуются и ищут того, кто должен проиграть. На самом деле выгодных для обеих плоскостей решений гораздо больше, чем кажется на первый взгляд.
❗️ Приоритет постоянно смещается в сторону тактики или стратегии.
Например, установка «сделать проект любой ценой» тормозит стратегическое развитие. Или матричная структура «слабая»: горизонтальная плоскость управления есть, но имеет мало влияния. В таком случае принятые подходы не учитывают ограничения проекта, а руководитель проекта становится скорее простым «администратором» или «передатчиком информации» и слабо влияет на процесс работы, качество продукта и удовлетворенность конечных пользователей.
❗️ Отсутствует культура гибкости.
В компании не принято искать компромиссы, а у руководителей недостаточно развиты soft skills и умение разрешать конфликты.
Расскажите в комментариях, знакомы ли вам эти предпосылки?
Матричная структура: плюсы и минусы.
Часть 2 из 3. Конфликт плоскостей.
Как мы писали выше, особенность матричных структур — это столкновение интересов горизонтальной и вертикальной плоскостей. Его можно свести к конфликту тактики и стратегии. Что важнее: успеть сделать фичу к релизу или внедрить технологию и увеличить продуктивность в будущем? Адаптировать джуна или привлечь опытного разработчика и снять риски качества и сроков?
Конфликт — это нормально. Матричная структура провоцирует конфликты, и они помогают найти наилучшие решения. Проблемой становится не сам конфликт, а неспособность разрешить его конструктивно. У превращения конфликтов в проблемы могут быть следующие предпосылки:
❗️ Нечетко разделена ответственность между плоскостями.
То есть непонятно, кто должен принять решение при пересечении интересов. Что можно решить автономно, а что нужно обсудить совместно. Например, кто согласовывает сроки отпуска дизайнера: руководитель проекта, который отвечает за процессы, или руководитель отдела, обсуждавший с ним условия работы?
❗️ Не соблюдается принцип win-win при решении конфликта.
Вместо этого горизонталь и вертикаль соревнуются и ищут того, кто должен проиграть. На самом деле выгодных для обеих плоскостей решений гораздо больше, чем кажется на первый взгляд.
❗️ Приоритет постоянно смещается в сторону тактики или стратегии.
Например, установка «сделать проект любой ценой» тормозит стратегическое развитие. Или матричная структура «слабая»: горизонтальная плоскость управления есть, но имеет мало влияния. В таком случае принятые подходы не учитывают ограничения проекта, а руководитель проекта становится скорее простым «администратором» или «передатчиком информации» и слабо влияет на процесс работы, качество продукта и удовлетворенность конечных пользователей.
❗️ Отсутствует культура гибкости.
В компании не принято искать компромиссы, а у руководителей недостаточно развиты soft skills и умение разрешать конфликты.
Расскажите в комментариях, знакомы ли вам эти предпосылки?
👍2
#management
Матричная структура: плюсы и минусы.
Часть 3 из 3. Как сделать хорошо?
Мы рассказали, что такое матричная структура, и почему в ней возникают проблемы. Сегодня поговорим о том, что нужно сделать, чтобы конфликты в матричной структуре развивали, а не разрушали команду.
🔸 Интегрируйте и тактику, и стратегию в общие цели.
Не принимайте решения «по умолчанию», рассматривайте каждую ситуацию с учетом контекста и целей и избегайте перевеса в сторону тактики или стратегии. И руководителю отдела, и руководителю проекта должно быть понятно, как их решения влияют на общую цель. Почему тактический шаг приблизит нас к стратегической цели? Почему эта стратегия даст больше тактических преимуществ?
Иногда для ответа на эти вопросы нужно думать на уровне выше. В этом помогут мыслительные фреймворки, например, impact mapping или системное мышление.
🔸 Четко разделяйте ответственность вертикальных и горизонтальных руководителей.
Зафиксируйте зоны ответственности и обязанности каждого руководителя и донесите их до всех. Сотрудники должны понимать, кому задать вопрос и кто ставит задачи.
🔸 Создайте пространство для синхронизации вертикалей и горизонталей.
В этом помогут планерки с участием и тех, и других. В SmartHead есть статусы руководителей отделов и статусы руководителей проектов, на которых присутствуют и вертикальные, и горизонтальные руководители. А ещё в этом помогает просто живое общение: даже «кухонные» разговоры помогают синхронизироваться.
🔸 Транслируйте принципы принятия решений, а не регламенты.
В быстро меняющихся обстоятельствах принципы работают лучше, чем четкие правила. Об этом хорошо и подробно изложено в книге Рэя Далио «Принципы». Чтобы сформулированные принципы оставались полезными, регулярно пересматривайте их с учетом изменения контекста.
🔸 Разработайте рациональные принципы распределения ресурсов и четко их придерживайтесь.
Не допускайте конкуренции горизонтальных руководителей за ресурсы. Для этого хорошо периодически проверять адекватность распределения ресурсов. Далеко не всегда принцип «кто первый пришел, того и ресурс» работает на пользу компании.
🔸 Компенсируйте психологический стресс сотрудников.
Матричная структура подвижна, команды очень часто пересобираются, а значит, разрушаются сформированные отношения с сокомандниками, и сотруднику приходится строить новые отношения в проектной команде. Это противоречит базовой потребности человека в стабильных взаимоотношениях и вызывает внутреннее напряжение.
О каком пункте рассказать подробнее?
Матричная структура: плюсы и минусы.
Часть 3 из 3. Как сделать хорошо?
Мы рассказали, что такое матричная структура, и почему в ней возникают проблемы. Сегодня поговорим о том, что нужно сделать, чтобы конфликты в матричной структуре развивали, а не разрушали команду.
🔸 Интегрируйте и тактику, и стратегию в общие цели.
Не принимайте решения «по умолчанию», рассматривайте каждую ситуацию с учетом контекста и целей и избегайте перевеса в сторону тактики или стратегии. И руководителю отдела, и руководителю проекта должно быть понятно, как их решения влияют на общую цель. Почему тактический шаг приблизит нас к стратегической цели? Почему эта стратегия даст больше тактических преимуществ?
Иногда для ответа на эти вопросы нужно думать на уровне выше. В этом помогут мыслительные фреймворки, например, impact mapping или системное мышление.
🔸 Четко разделяйте ответственность вертикальных и горизонтальных руководителей.
Зафиксируйте зоны ответственности и обязанности каждого руководителя и донесите их до всех. Сотрудники должны понимать, кому задать вопрос и кто ставит задачи.
🔸 Создайте пространство для синхронизации вертикалей и горизонталей.
В этом помогут планерки с участием и тех, и других. В SmartHead есть статусы руководителей отделов и статусы руководителей проектов, на которых присутствуют и вертикальные, и горизонтальные руководители. А ещё в этом помогает просто живое общение: даже «кухонные» разговоры помогают синхронизироваться.
🔸 Транслируйте принципы принятия решений, а не регламенты.
В быстро меняющихся обстоятельствах принципы работают лучше, чем четкие правила. Об этом хорошо и подробно изложено в книге Рэя Далио «Принципы». Чтобы сформулированные принципы оставались полезными, регулярно пересматривайте их с учетом изменения контекста.
🔸 Разработайте рациональные принципы распределения ресурсов и четко их придерживайтесь.
Не допускайте конкуренции горизонтальных руководителей за ресурсы. Для этого хорошо периодически проверять адекватность распределения ресурсов. Далеко не всегда принцип «кто первый пришел, того и ресурс» работает на пользу компании.
🔸 Компенсируйте психологический стресс сотрудников.
Матричная структура подвижна, команды очень часто пересобираются, а значит, разрушаются сформированные отношения с сокомандниками, и сотруднику приходится строить новые отношения в проектной команде. Это противоречит базовой потребности человека в стабильных взаимоотношениях и вызывает внутреннее напряжение.
О каком пункте рассказать подробнее?