#management
Как мы помогаем сотрудникам справляться со стрессом.
В предыдущих постах мы писали о матричной структуре управления. Она подвижна и может вызывать стресс, ведь частая смена команды заставляет быстро перестраиваться, много общаться и работать с разными ожиданиями.
В комментариях Света попросила рассказать, как при этом компенсировать стресс. Чтобы на него ответить, мы спросили наших сотрудников о том, как они справляются со стрессом.
Виталий, руководитель проектов:
«У меня есть две причины стресса. Первая – не успеваю что-то сделать, а вторая – не знаю, как. В первом случае помогает приоритизация задач. Во втором — понимание, что я могу посоветоваться с коллегами и рассчитывать на их помощь».
Адэлина, дизайнер:
«Я хожу на бокс после работы. Он помогает сбросить стресс и приводит мысли в порядок».
Макс, коммерческий директор:
«Мне помогает работа над простой задачей с быстрым достижением результата».
Алия, руководитель Backend отдела:
«Я четко разделяю рабочее и личное время. Главное — не уносить рабочие проблемы домой и дать себе восстановиться. Мне помогает общение с близкими, свежий воздух, здоровый сон и хобби».
Айгуль, PR-менеджер:
«Люблю ходить на работу пешком и гулять во время обеда. Обычно хожу одна, выключаю уведомления и стараюсь не думать о работе. Ещё помогают встречи на мастермайнде, где мы делимся трудностями и решениями. Такое общение в группе помогает почувствовать, что я не одна».
Нет одного правильного ответа. Сколько людей — столько и способов борьбы со стрессом. В SmartHead мы делаем все, чтобы каждому было комфортно, и помогаем минимизировать напряжение. Вот некоторые наши принципы и активности:
🔹 Не плодим лишние правила, бюрократию и ограничения.
🔹 Регулярно обсуждаем на тет-а-тет встречах не только рабочие вопросы, но и эмоциональное состояние.
🔹 Поддерживаем культуру решения задач, а не поиска виновного.
🔹 Общаемся неформально: остаемся на пятничные посиделки, играем в кикер и настолки, организуем мастермайнды и групповые обсуждения.
🔹 Думаем о бытовом комфорте в офисе. Например, у нас есть регулируемые по высоте столы и подставки под монитор. Много растений (уверены, зелень даёт +100 к уюту).
Как мы помогаем сотрудникам справляться со стрессом.
В предыдущих постах мы писали о матричной структуре управления. Она подвижна и может вызывать стресс, ведь частая смена команды заставляет быстро перестраиваться, много общаться и работать с разными ожиданиями.
В комментариях Света попросила рассказать, как при этом компенсировать стресс. Чтобы на него ответить, мы спросили наших сотрудников о том, как они справляются со стрессом.
Виталий, руководитель проектов:
«У меня есть две причины стресса. Первая – не успеваю что-то сделать, а вторая – не знаю, как. В первом случае помогает приоритизация задач. Во втором — понимание, что я могу посоветоваться с коллегами и рассчитывать на их помощь».
Адэлина, дизайнер:
«Я хожу на бокс после работы. Он помогает сбросить стресс и приводит мысли в порядок».
Макс, коммерческий директор:
«Мне помогает работа над простой задачей с быстрым достижением результата».
Алия, руководитель Backend отдела:
«Я четко разделяю рабочее и личное время. Главное — не уносить рабочие проблемы домой и дать себе восстановиться. Мне помогает общение с близкими, свежий воздух, здоровый сон и хобби».
Айгуль, PR-менеджер:
«Люблю ходить на работу пешком и гулять во время обеда. Обычно хожу одна, выключаю уведомления и стараюсь не думать о работе. Ещё помогают встречи на мастермайнде, где мы делимся трудностями и решениями. Такое общение в группе помогает почувствовать, что я не одна».
Нет одного правильного ответа. Сколько людей — столько и способов борьбы со стрессом. В SmartHead мы делаем все, чтобы каждому было комфортно, и помогаем минимизировать напряжение. Вот некоторые наши принципы и активности:
🔹 Не плодим лишние правила, бюрократию и ограничения.
🔹 Регулярно обсуждаем на тет-а-тет встречах не только рабочие вопросы, но и эмоциональное состояние.
🔹 Поддерживаем культуру решения задач, а не поиска виновного.
🔹 Общаемся неформально: остаемся на пятничные посиделки, играем в кикер и настолки, организуем мастермайнды и групповые обсуждения.
🔹 Думаем о бытовом комфорте в офисе. Например, у нас есть регулируемые по высоте столы и подставки под монитор. Много растений (уверены, зелень даёт +100 к уюту).
❤8
А еще в конце года мы провели опрос: "Что больше всего нас поддерживает в работе?". В топе ответов — коллеги и кофе 🤍
❤14
#management
4 заблуждения о проектных рисках
Я нанимаю руководителей проектов в команду. Когда спрашиваю на собеседовании: «Как вы управляете рисками», — мне часто отвечают: «Нууу… Я думаю, что может пойти не так, и закладываю на это 30% от оценки». Такой подход сложно назвать управлением рисками.
Вот ещё 4 заблуждения и ошибки, с которыми я сталкиваюсь.
1️⃣ Про риски — это только к руководителю проекта
Руководитель проекта — не эксперт в технологиях разработки, и может многого в них не понимать. Поэтому часто выявить «технические» риски в рамках задачи может только исполнитель. Например, связанные с отсутствием опыта применения технологии.
Анализ таких рисков происходит на этапе оценки и планирования работ над задачей. Руководитель проекта может помочь исполнителю проанализировать их, задав правильные вопросы: «Из-за чего мы можем не достигнуть цели?», «Как нам этого избежать?».
2️⃣ Подумал о рисках — уже управляю
Если держать информацию о рисках в уме, о ней никто не узнает. Ну и через время она забудется. Если вы управляете рисками, то главное — как минимум описать их и обсудить с командой. Формат может быть любой: на бумаге или доске, в «ворде» или в таблице-реестре.
Описание – это первый шаг управления рисками. И только потом — анализ, выбор стратегии, составление планов А (снижения или уклонения) и Б (реагирования), учёт резервов.
4 заблуждения о проектных рисках
Я нанимаю руководителей проектов в команду. Когда спрашиваю на собеседовании: «Как вы управляете рисками», — мне часто отвечают: «Нууу… Я думаю, что может пойти не так, и закладываю на это 30% от оценки». Такой подход сложно назвать управлением рисками.
Вот ещё 4 заблуждения и ошибки, с которыми я сталкиваюсь.
1️⃣ Про риски — это только к руководителю проекта
Руководитель проекта — не эксперт в технологиях разработки, и может многого в них не понимать. Поэтому часто выявить «технические» риски в рамках задачи может только исполнитель. Например, связанные с отсутствием опыта применения технологии.
Анализ таких рисков происходит на этапе оценки и планирования работ над задачей. Руководитель проекта может помочь исполнителю проанализировать их, задав правильные вопросы: «Из-за чего мы можем не достигнуть цели?», «Как нам этого избежать?».
2️⃣ Подумал о рисках — уже управляю
Если держать информацию о рисках в уме, о ней никто не узнает. Ну и через время она забудется. Если вы управляете рисками, то главное — как минимум описать их и обсудить с командой. Формат может быть любой: на бумаге или доске, в «ворде» или в таблице-реестре.
Описание – это первый шаг управления рисками. И только потом — анализ, выбор стратегии, составление планов А (снижения или уклонения) и Б (реагирования), учёт резервов.
👍2
3️⃣ Каждый риск — плюс одна резервная неделя на задачу
При таком подходе со временем забудется, что в дедлайн заложены резервы. Если риск не реализовался, то сработает закон Паркинсона: «работа занимает всё отведённое ей время». Появятся улучшения, реальные сроки решения задач раздуются. И вы не сможете следить за использованием резервов. В итоге — расход бюджета проекта станет непрозрачным, заказчик будет меньше доверять вашей команде.
На самом деле, резервы нужно отделять от конкретных задач. Если план А требует 7 дней, а план Б – 3 дня, то дедлайн по нашей задаче — через 7 дней, а не через 10. Переход к плану Б и использование резервов нужно обсуждать в команде проекта после срабатывания риска.
А ещё рано говорить о резервах, пока не выбрана стратегия управления. Помогут в выборе стратегии вопросы: «Что можно сделать, чтобы риск не реализовался?», «Как нам раньше понять, что он точно реализуется?», «Что мы будем делать, когда он реализуется?» В зависимости от стратегии формируются планы А и Б. Всего стратегий четыре: снижение, уклонение, принятие и передача. Если нужно рассказать о них подробнее, напишите в комментариях.
4️⃣ Риски — это только про проблемы
Если учитывать только проблемы, можно упустить шанс сделать задачу быстрее или дешевле, заработать больше денег или улучшить свою репутацию перед клиентом. Ведь помимо негативных есть позитивные риски. Чтобы их найти, спросите себя: «Что может нам помочь?» и «Как можно быстрее достичь цели?». Следующие шаги те же, что и с негативными рисками. Нужно их проанализировать, выбрать стратегию и составить планы работы. Всего стратегий три: усиление, использование и принятие.
Управление рисками — это мощный инструмент для планирования работы. Перечисленные здесь рекомендации можно применить в любой сфере, даже при решении бытовых вопросов. Например, попробуйте их учесть при планировании ремонта, и вы удивитесь, сколько можно сэкономить нервов и даже денег!
#management
При таком подходе со временем забудется, что в дедлайн заложены резервы. Если риск не реализовался, то сработает закон Паркинсона: «работа занимает всё отведённое ей время». Появятся улучшения, реальные сроки решения задач раздуются. И вы не сможете следить за использованием резервов. В итоге — расход бюджета проекта станет непрозрачным, заказчик будет меньше доверять вашей команде.
На самом деле, резервы нужно отделять от конкретных задач. Если план А требует 7 дней, а план Б – 3 дня, то дедлайн по нашей задаче — через 7 дней, а не через 10. Переход к плану Б и использование резервов нужно обсуждать в команде проекта после срабатывания риска.
А ещё рано говорить о резервах, пока не выбрана стратегия управления. Помогут в выборе стратегии вопросы: «Что можно сделать, чтобы риск не реализовался?», «Как нам раньше понять, что он точно реализуется?», «Что мы будем делать, когда он реализуется?» В зависимости от стратегии формируются планы А и Б. Всего стратегий четыре: снижение, уклонение, принятие и передача. Если нужно рассказать о них подробнее, напишите в комментариях.
4️⃣ Риски — это только про проблемы
Если учитывать только проблемы, можно упустить шанс сделать задачу быстрее или дешевле, заработать больше денег или улучшить свою репутацию перед клиентом. Ведь помимо негативных есть позитивные риски. Чтобы их найти, спросите себя: «Что может нам помочь?» и «Как можно быстрее достичь цели?». Следующие шаги те же, что и с негативными рисками. Нужно их проанализировать, выбрать стратегию и составить планы работы. Всего стратегий три: усиление, использование и принятие.
Управление рисками — это мощный инструмент для планирования работы. Перечисленные здесь рекомендации можно применить в любой сфере, даже при решении бытовых вопросов. Например, попробуйте их учесть при планировании ремонта, и вы удивитесь, сколько можно сэкономить нервов и даже денег!
#management
🔥6👍4❤3
#management
Проектный треугольник: ограничения vs. качество
Мы работаем в условиях ограничений. Заказчик ожидает получить необходимый результат с соблюдением сроков и бюджета. Ему нужно планировать свою деятельность. Поэтому понятие проектного треугольника является базовым для наших процессов управления.
Но разговор о треугольнике и ограничениях будет неполным без учёта качества. Многим знакома ситуация, когда все три условия соблюдены: выполнены требования из задания, стоимость и сроки не превышены. Однако результат получился провальным. Ожидания и реальность не сходятся, качество результата низкое. Отсюда возникает вопрос: если треугольник — это «база», то где в нём качество? Стоит ли его туда вписывать?
Вот в этом сегодня и разберёмся, ответив на вопросы:
— В чем смысл треугольника
— Есть ли в нём место качеству
— И как он нам помогает на практике
Проектный треугольник: ограничения vs. качество
Мы работаем в условиях ограничений. Заказчик ожидает получить необходимый результат с соблюдением сроков и бюджета. Ему нужно планировать свою деятельность. Поэтому понятие проектного треугольника является базовым для наших процессов управления.
Но разговор о треугольнике и ограничениях будет неполным без учёта качества. Многим знакома ситуация, когда все три условия соблюдены: выполнены требования из задания, стоимость и сроки не превышены. Однако результат получился провальным. Ожидания и реальность не сходятся, качество результата низкое. Отсюда возникает вопрос: если треугольник — это «база», то где в нём качество? Стоит ли его туда вписывать?
Вот в этом сегодня и разберёмся, ответив на вопросы:
— В чем смысл треугольника
— Есть ли в нём место качеству
— И как он нам помогает на практике
Смысл треугольника
Его суть заключается во взаимной связи проектных ограничений: стоимости, содержания и сроков. Их легко описать и выразить количественно. Также любым из них можно манипулировать: изменение одного ограничения влечёт изменение других, и треугольник меняется. Например:
▫️ Хотим снизить стоимость проекта? Меняем содержание: пересматриваем требования и ищем другое решение.
▫️Нужно получить результат быстрее — добавляем ресурсы и пересматриваем стоимость.
Где качество
Раньше под качеством понимали соответствие результата требованиям технического задания. Фактически оно было частью содержания. Но сегодня это понятие гораздо шире. Если коротко, качество — это соответствие результата проекта его целям. Его можно описать следующими критериями:
▫️цель заказчика достигнута, он доволен клиентским сервисом,
▫️пользователи удовлетворены стабильным продуктом, хорошим UX, и тем, как решена их потребность,
▫️команде нравятся задачи и процесс работы.
Поэтому качество — это не часть содержания. Но и не дополнительная грань геометрической фигуры. Мы не манипулируем им аналогично стоимости, сроку и содержанию. Например:
▫️Не отказываемся от изменений, улучшающих продукт, только из-за того, что это противоречит начальным требованиям.
▫️Не жертвуем клиентским сервисом и удовлетворённостью заказчика, чтобы работать быстрее и не тратить время на коммуникацию.
▫️Не делаем хуже и не урезаем ресурсы на тестирование и код-ревью, чтобы вышло дешевле.
Качество допустимо показать внутри треугольника. Это стремление к результату, который удовлетворит всех в рамках заданных ограничений.
Границы треугольника и качество — понятия из разных плоскостей. Стороны треугольника — это фундаментальные количественные характеристики проекта. Качество продукта и процессов, удовлетворённость заинтересованных сторон, простите за каламбур, — качественные.
Подробный разбор темы качества можете послушать в выпусках нашего подкаста smarthead.space.
Применение на практике
Проектный треугольник помогает устанавливать отношение ограничений проекта и приоритетов. С его помощью мы можем показать клиенту, как манипуляции с требованиями и сроками влияют на стоимость. Или как фиксированный бюджет сужает границы возможной функциональности продукта.
Мы в SmartHead используем гибридную модель разработки: обычно мы фиксируем с заказчиком сроки, стоимость и верхнеуровневые требования проекта, а деталями содержания управляем, чтобы остаться «внутри треугольника». Уровень качества мы поддерживаем благодаря инженерной культуре и принципами совместной работы команды проекта. Если они не вписываются в требуемые заказчиком ограничения по стоимости, содержанию и сроку, с очень высокой вероятностью за такой проект мы не возьмёмся.
Треугольник — это в первую очередь характеристика проекта, то есть ограниченной деятельности. Но он также «работает» и в agile-подходах при длительном развитии продукта. Он может помочь определить приоритеты для оптимального достижения бизнес-целей. Наличие связей между ограничениями и отношение к качеству не зависят от методологии.
Вместо выводов хочу закончить мнением Светы, нашего руководителя проектов. Рассуждая на эту тему, она сказала:
«Кто вообще считает, что к проектному треугольнику надо качество присобачить? Все к геометрическим фигурам не сведешь. Качество должно быть в твоем сердечке 🤍.»
#management
Его суть заключается во взаимной связи проектных ограничений: стоимости, содержания и сроков. Их легко описать и выразить количественно. Также любым из них можно манипулировать: изменение одного ограничения влечёт изменение других, и треугольник меняется. Например:
▫️ Хотим снизить стоимость проекта? Меняем содержание: пересматриваем требования и ищем другое решение.
▫️Нужно получить результат быстрее — добавляем ресурсы и пересматриваем стоимость.
Где качество
Раньше под качеством понимали соответствие результата требованиям технического задания. Фактически оно было частью содержания. Но сегодня это понятие гораздо шире. Если коротко, качество — это соответствие результата проекта его целям. Его можно описать следующими критериями:
▫️цель заказчика достигнута, он доволен клиентским сервисом,
▫️пользователи удовлетворены стабильным продуктом, хорошим UX, и тем, как решена их потребность,
▫️команде нравятся задачи и процесс работы.
Поэтому качество — это не часть содержания. Но и не дополнительная грань геометрической фигуры. Мы не манипулируем им аналогично стоимости, сроку и содержанию. Например:
▫️Не отказываемся от изменений, улучшающих продукт, только из-за того, что это противоречит начальным требованиям.
▫️Не жертвуем клиентским сервисом и удовлетворённостью заказчика, чтобы работать быстрее и не тратить время на коммуникацию.
▫️Не делаем хуже и не урезаем ресурсы на тестирование и код-ревью, чтобы вышло дешевле.
Качество допустимо показать внутри треугольника. Это стремление к результату, который удовлетворит всех в рамках заданных ограничений.
Границы треугольника и качество — понятия из разных плоскостей. Стороны треугольника — это фундаментальные количественные характеристики проекта. Качество продукта и процессов, удовлетворённость заинтересованных сторон, простите за каламбур, — качественные.
Подробный разбор темы качества можете послушать в выпусках нашего подкаста smarthead.space.
Применение на практике
Проектный треугольник помогает устанавливать отношение ограничений проекта и приоритетов. С его помощью мы можем показать клиенту, как манипуляции с требованиями и сроками влияют на стоимость. Или как фиксированный бюджет сужает границы возможной функциональности продукта.
Мы в SmartHead используем гибридную модель разработки: обычно мы фиксируем с заказчиком сроки, стоимость и верхнеуровневые требования проекта, а деталями содержания управляем, чтобы остаться «внутри треугольника». Уровень качества мы поддерживаем благодаря инженерной культуре и принципами совместной работы команды проекта. Если они не вписываются в требуемые заказчиком ограничения по стоимости, содержанию и сроку, с очень высокой вероятностью за такой проект мы не возьмёмся.
Треугольник — это в первую очередь характеристика проекта, то есть ограниченной деятельности. Но он также «работает» и в agile-подходах при длительном развитии продукта. Он может помочь определить приоритеты для оптимального достижения бизнес-целей. Наличие связей между ограничениями и отношение к качеству не зависят от методологии.
Вместо выводов хочу закончить мнением Светы, нашего руководителя проектов. Рассуждая на эту тему, она сказала:
«Кто вообще считает, что к проектному треугольнику надо качество присобачить? Все к геометрическим фигурам не сведешь. Качество должно быть в твоем сердечке 🤍.»
#management
❤5👍5🔥1
К нам обратился Тайлер — предприниматель из Кремниевой долины. Мы разработали для него no-code e-commerce платформу для моментальных покупок. Платформа сокращает путь пользователя от знакомства с продуктом до покупки.
Платформа интегрирована с Shopify и представляет собой мобильное приложение. В приложении можно изучать товары и делать покупки с более удобным и быстрым UX, чем в веб-версиях типовых магазинов на Shopify.
Благодаря технологии App Clips для iOS-пользователей приложение не требует установки из магазина. Оно запускается автоматически при сканировании NFC-метки, QR-кода или при переходе по ссылке. Оплата осуществляется с помощью Apple Pay — не требуется регистрация, ввод данных карты и адреса доставки. По своей сути — это PoS-терминал на телефоне пользователя с отличным «нативным» для мобильной платформы UX.
Первую версию приложения мы выпустили за 2 недели. Клиент торопился пройти отбор в стартап-акселератор Y Combinator, и нам нужно было успеть пройти модерацию приложения в App Store. С этой задачей мы успешно справились. Более неожиданные проблемы ждали нас впереди :)
💡 Что с Android-версией?
В Android тоже есть технология для запуска приложений без установки из магазина — Instant Apps. Мы хотели с помощью неё реализовать на Android такой же сценарий, как с App Clips на iOS. Но оказалось, что Instant Apps по умолчанию выключена у пользователей. Чтобы её включить, пользователю нужно зарыться в неочевидных настройках Google Play. Предполагаем, что число таких пользователей очень мало. И это делает технологию практически бесполезной. Получается, что формально у Android есть аналог App Clips, но фактически его как будто нет.
Важно не только, что за функции есть в продукте, но и то, как они реализованы. И не только в операционных системах от IT-гигантов, но и в ваших приложениях.
Ну, а вместо Android-приложения мы реализовали веб-версию.
Платформа интегрирована с Shopify и представляет собой мобильное приложение. В приложении можно изучать товары и делать покупки с более удобным и быстрым UX, чем в веб-версиях типовых магазинов на Shopify.
Благодаря технологии App Clips для iOS-пользователей приложение не требует установки из магазина. Оно запускается автоматически при сканировании NFC-метки, QR-кода или при переходе по ссылке. Оплата осуществляется с помощью Apple Pay — не требуется регистрация, ввод данных карты и адреса доставки. По своей сути — это PoS-терминал на телефоне пользователя с отличным «нативным» для мобильной платформы UX.
Первую версию приложения мы выпустили за 2 недели. Клиент торопился пройти отбор в стартап-акселератор Y Combinator, и нам нужно было успеть пройти модерацию приложения в App Store. С этой задачей мы успешно справились. Более неожиданные проблемы ждали нас впереди :)
💡 Что с Android-версией?
В Android тоже есть технология для запуска приложений без установки из магазина — Instant Apps. Мы хотели с помощью неё реализовать на Android такой же сценарий, как с App Clips на iOS. Но оказалось, что Instant Apps по умолчанию выключена у пользователей. Чтобы её включить, пользователю нужно зарыться в неочевидных настройках Google Play. Предполагаем, что число таких пользователей очень мало. И это делает технологию практически бесполезной. Получается, что формально у Android есть аналог App Clips, но фактически его как будто нет.
Важно не только, что за функции есть в продукте, но и то, как они реализованы. И не только в операционных системах от IT-гигантов, но и в ваших приложениях.
Ну, а вместо Android-приложения мы реализовали веб-версию.
🔥16
#management
Живи как последний день… менеджера
Как руководителю понять, хорошо ли он справляется со своей работой?
Один из способов — задать себе вопрос "что будет с проектом/продуктом/командой/компанией/etc если меня завтра не станет?"
Помимо экзистенциального этот вопрос имеет еще и прикладной профессиональный смысл.
Живи как последний день… менеджера
Как руководителю понять, хорошо ли он справляется со своей работой?
Один из способов — задать себе вопрос "что будет с проектом/продуктом/командой/компанией/etc если меня завтра не станет?"
Помимо экзистенциального этот вопрос имеет еще и прикладной профессиональный смысл.
Проведите мысленный эксперимент в мельчайших подробностях.
— Знают ли члены команды, кто и что должен делать и какие стоят цели?
— Заказчики, пользователи, члены команды и другие заинтересованные лица начнут звонить друг другу с вопросом "Так, а ты знаешь где то-то и что с этим делать и почему оно вообще такое?"
— Ключевые договорённости по проекту согласованы и подписаны? Могут ли они быть нарушены?
— Кто в команде понимает, куда развивать компанию/продукт/людей?
— Знает ли команда о рисках и как реагировать на них или начнет придумывать решения "на ходу"?
— Какие есть неразрешенные конфликты интересов разных заинтересованных лиц? Начнут ли они мешать достижению целей?
— У вас есть человек себе на замену? Или его нужно долго искать, требования к нему уникальны, погружать в задачи его нужно будет долго?
— Какие еще кошмары вы можете себе представить, если покинете команду? :)
Если после этих и других подобных вопросов вы серьезно забеспокоились, то:
— Поздравляю, вы неравнодушны к своей работе.
— Вам есть чем заняться.
Если нет:
— У вас все классно. Может быть пора браться за что-то посложнее?
— Либо вы равнодушны к тому что будет после вас.
— Либо недостаточно компетентны чтобы заметить возможные проблемы и риски.
Главная задача руководителя — сделать себя ненужным. Эта мысль раскрывается в прекрасной заметке Александра Ложечкина. Советую обратить внимание и на остальное содержимое его блога.
С опытом и кругозором становится понятно, что всего учесть невозможно, но и не нужно. Цель сделать себя ненужным остается, но уровень решаемых задач повышается, а рядом формируется команда, которая всегда сама разберется с тем, что не успел руководитель (если он более или менее успешно стремился к этой цели).
#management
— Знают ли члены команды, кто и что должен делать и какие стоят цели?
— Заказчики, пользователи, члены команды и другие заинтересованные лица начнут звонить друг другу с вопросом "Так, а ты знаешь где то-то и что с этим делать и почему оно вообще такое?"
— Ключевые договорённости по проекту согласованы и подписаны? Могут ли они быть нарушены?
— Кто в команде понимает, куда развивать компанию/продукт/людей?
— Знает ли команда о рисках и как реагировать на них или начнет придумывать решения "на ходу"?
— Какие есть неразрешенные конфликты интересов разных заинтересованных лиц? Начнут ли они мешать достижению целей?
— У вас есть человек себе на замену? Или его нужно долго искать, требования к нему уникальны, погружать в задачи его нужно будет долго?
— Какие еще кошмары вы можете себе представить, если покинете команду? :)
Если после этих и других подобных вопросов вы серьезно забеспокоились, то:
— Поздравляю, вы неравнодушны к своей работе.
— Вам есть чем заняться.
Если нет:
— У вас все классно. Может быть пора браться за что-то посложнее?
— Либо вы равнодушны к тому что будет после вас.
— Либо недостаточно компетентны чтобы заметить возможные проблемы и риски.
Главная задача руководителя — сделать себя ненужным. Эта мысль раскрывается в прекрасной заметке Александра Ложечкина. Советую обратить внимание и на остальное содержимое его блога.
С опытом и кругозором становится понятно, что всего учесть невозможно, но и не нужно. Цель сделать себя ненужным остается, но уровень решаемых задач повышается, а рядом формируется команда, которая всегда сама разберется с тем, что не успел руководитель (если он более или менее успешно стремился к этой цели).
#management
Medium
О главной задаче руководителя
Люди, полагающие, что они никому не нужны, на самом деле часто самые нужные.
Эрих Мария Ремарк
Эрих Мария Ремарк
👍7
У нас в компании принято регулярно проводить тет-а-тет встречи с руководителем и с директором. Это помогает нам рефлексировать над работой и формировать доверительные отношения в команде. Практику тет-а-тет встреч предложила в 2016 году наш аналитик Лена. Нам понравилась идея, и мы решили попробовать. Описали порядок проведения встреч, сценарий и вопросы, которые можно обсуждать. Со временем мы отошли от строгих правил, и начали формировать собственные ценности, выработанные на практике. Каждый руководитель проводит тет-а-теты в подходящем для него и для сотрудника стиле — искренность главнее строгой структуры.
«Важно не то, как описан процесс, а то, как мы себя ведём в реальности», — Игорь (директор компании).
«Важно не то, как описан процесс, а то, как мы себя ведём в реальности», — Игорь (директор компании).
👍4
В инстаграме мы поделились некоторыми базовыми советами и принципами, которые мы сформировали, практикуя тет-а-теты. А в этом посте мы собрали мнения и комментарии сотрудников о том, как изменилась практика тет-а-тет встреч, и как она помогает им в работе.
🔹 Каким был твой первый тет-а-тет в качестве руководителя, и какой он сейчас?
Алия (руководитель отдела Backend-разработки): «Когда в SmartHead ввели практику тет-а-тет встреч, мы только учились их проводить и больше времени уделяли правилам и плану разговора. Став руководителем, я придерживалась такого же подхода, но постепенно тет-а-теты стали более свободными. Кроме работы, мы обсуждаем и личные вопросы. Мне важно быть в курсе происходящего, понимать, что тревожит человека».
🔹 Как подготовиться к тет-а-тету?
Римма (руководитель проектов): «Перед тет-а-тетом я вспоминаю или читаю в отчете, о чем мы говорили на прошлой встрече, рефлексирую и думаю о том, что хочу вынести на следующую встречу. Обычно я не коплю вопросы или обратную связь, а говорю в процессе работы».
🔹 Как тебе помогают такие встречи?
Игорь (директор): «Я провожу тет-а-теты со всеми сотрудниками, вне зависимости от того, работаю я с ними непосредственно на проектах или нет. Это даёт мне понимание того, что происходит в компании. Наличие такого формата легитимизирует неформальные беседы: у всех есть возможность лично поговорить с руководителем и со мной не только в рабочем формате».
🔹 Что будет, если отменить такую практику?
Рамиль (CTO): «Если отменить тет-а-теты, мне кажется, для текущих сотрудников ничего не изменится. Скорее всего, мы также будем обсуждать проблемы и обмениваться обратной связью, но при этом это не будет называться «тет-а-тетом». Новым сотрудникам будет сложнее. Также на тет-а-тет встречах руководитель транслирует то, что происходит в компании, какие есть изменения внутри, и как это повлияет на совместную работу. Мне нравится, что есть определенное время и место для подобных обсуждений».
🔹 Для нас важно, чтобы тет-а-тет встречи проходили искренне и доверительно. Поэтому мы иногда проводим их вне офиса: в парке или в кофейне. Но погода вносит свои коррективы :)
Биарслан (Frontend-разработчик): «Однажды мы решили провести тет-а-тет в парке недалеко от офиса: было лето и хорошая погода. Но спустя 10 минут хлынул сильнейший дождь, и мы с трудом вернулись обратно, промокнув до нитки. Тет-а-тет, конечно, пришлось перенести 😅».
🔹 В компании каждый сотрудник может получить обратную связь и помощь от руководителя и директора. Единственный, кто не проводит тет-а-тет в роли участника — это Игорь, наш директор.
«Так получается, что я должен брать энергию где-то вовне. У меня нет руководителя или коуча (хотя может и надо), но для меня это нормально. Мне помогает общение с близкими, психотерапевтом, но и обычные тет-а-теты с сотрудниками тоже. Тет-а-тет — это не односторонний разговор, где я просто слушаю и помогаю, это обмен обратной связью, мнениями и мыслями».
Считаете ли вы тет-а-теты хорошей практикой или с ужасом ждете встречи? Есть советы о том как сделать тет-а-теты круче? Поделитесь своим опытом в комментариях :)
Полезные материалы для подготовки к тет-а-тетам:
8 Questions You Should Be Asking Your Boss
Об обратной связи
Подборка из 101 вопроса, которые имеет смысл задать на тет-а-тет митинге.
10 ошибок при встречах 1:1
🔹 Каким был твой первый тет-а-тет в качестве руководителя, и какой он сейчас?
Алия (руководитель отдела Backend-разработки): «Когда в SmartHead ввели практику тет-а-тет встреч, мы только учились их проводить и больше времени уделяли правилам и плану разговора. Став руководителем, я придерживалась такого же подхода, но постепенно тет-а-теты стали более свободными. Кроме работы, мы обсуждаем и личные вопросы. Мне важно быть в курсе происходящего, понимать, что тревожит человека».
🔹 Как подготовиться к тет-а-тету?
Римма (руководитель проектов): «Перед тет-а-тетом я вспоминаю или читаю в отчете, о чем мы говорили на прошлой встрече, рефлексирую и думаю о том, что хочу вынести на следующую встречу. Обычно я не коплю вопросы или обратную связь, а говорю в процессе работы».
🔹 Как тебе помогают такие встречи?
Игорь (директор): «Я провожу тет-а-теты со всеми сотрудниками, вне зависимости от того, работаю я с ними непосредственно на проектах или нет. Это даёт мне понимание того, что происходит в компании. Наличие такого формата легитимизирует неформальные беседы: у всех есть возможность лично поговорить с руководителем и со мной не только в рабочем формате».
🔹 Что будет, если отменить такую практику?
Рамиль (CTO): «Если отменить тет-а-теты, мне кажется, для текущих сотрудников ничего не изменится. Скорее всего, мы также будем обсуждать проблемы и обмениваться обратной связью, но при этом это не будет называться «тет-а-тетом». Новым сотрудникам будет сложнее. Также на тет-а-тет встречах руководитель транслирует то, что происходит в компании, какие есть изменения внутри, и как это повлияет на совместную работу. Мне нравится, что есть определенное время и место для подобных обсуждений».
🔹 Для нас важно, чтобы тет-а-тет встречи проходили искренне и доверительно. Поэтому мы иногда проводим их вне офиса: в парке или в кофейне. Но погода вносит свои коррективы :)
Биарслан (Frontend-разработчик): «Однажды мы решили провести тет-а-тет в парке недалеко от офиса: было лето и хорошая погода. Но спустя 10 минут хлынул сильнейший дождь, и мы с трудом вернулись обратно, промокнув до нитки. Тет-а-тет, конечно, пришлось перенести 😅».
🔹 В компании каждый сотрудник может получить обратную связь и помощь от руководителя и директора. Единственный, кто не проводит тет-а-тет в роли участника — это Игорь, наш директор.
«Так получается, что я должен брать энергию где-то вовне. У меня нет руководителя или коуча (хотя может и надо), но для меня это нормально. Мне помогает общение с близкими, психотерапевтом, но и обычные тет-а-теты с сотрудниками тоже. Тет-а-тет — это не односторонний разговор, где я просто слушаю и помогаю, это обмен обратной связью, мнениями и мыслями».
Считаете ли вы тет-а-теты хорошей практикой или с ужасом ждете встречи? Есть советы о том как сделать тет-а-теты круче? Поделитесь своим опытом в комментариях :)
Полезные материалы для подготовки к тет-а-тетам:
8 Questions You Should Be Asking Your Boss
Об обратной связи
Подборка из 101 вопроса, которые имеет смысл задать на тет-а-тет митинге.
10 ошибок при встречах 1:1
❤5👍2
Выразительность как основа надежности кода
#development
Запись познавательного завтрака от нашего CTO Рамиля о мыслительных и практических приемах (на TypeScript), которые позволяют сделать код более надёжным через выразительность. Выразительный код проще понимать, изменять и рассуждать о его корректности.
#development
Запись познавательного завтрака от нашего CTO Рамиля о мыслительных и практических приемах (на TypeScript), которые позволяют сделать код более надёжным через выразительность. Выразительный код проще понимать, изменять и рассуждать о его корректности.
👍7❤🔥3🔥2👏1
#development #management
Об излишней декомпозиции
Принято считать, что декомпозиция — это хорошо. Она действительно полезна: позволяет устранить неопределённость — разбить большую непонятную задачу так, чтобы можно было охватить её частями. В процессе разбиения мы лучше понимаем состав работ и даже по ходу занимаемся проектированием.
Но излишняя декомпозиция может быть опасна. Она создаёт иллюзию, что фича состоит только из технических задач, на которые мы её разбили.
🔹 Декомпозиция — это накладные расходы. Не только на создание и работу с отдельными задачами, но и на то, что задачи нужно делать отдельно: поддерживать отдельный жизненный цикл, реализовывать и выкатывать по отдельности.
🔹 Искусственная необходимость декомпозиции может приводить к преждевременному проектированию и планированию. Для того, чтобы декомпозировать, нужно спроектировать. Но часто на старте недостаточно информации для проектирования и мы делаем «как-то». Но потом не переделываем по мере поступления информации. Ведь мы же уже декомпозировали, надо делать!
🔹 Декомпозиция создает иллюзию контроля. Сделал половину подзадач — значит сделал полфичи. Сделал все подзадачи — сделал целиком. Это не так. Чтобы сделать фичу, недостаточно сделать все её подзадачи. Фича обычно больше, чем совокупность подзадач. Результаты подзадач ещё нужно собрать — и понять, что фича целиком выполнена. Есть эмерджентность — ценность, которую даёт совокупность результатов подзадач, и которой нет в простой сумме этих результатов. Чтобы фича была сделана, эта ценность должна быть тоже реализована.
🔹 Часто декомпозиция просто не имеет смысла. Например, фича достаточно простая и её можно сделать целиком «за один присест».
Декомпозиция фичи уместна, когда мы её разделяем по принципу поставки: на части, которые сами по себе являются конечным результатом с точки зрения продукта или сценария использования.
Не нужно декомпозировать фичу на работы (например, «разработать фронтенд», «разработать бэкенд», «написать миграцию»), лучше декомпозировать на отдельные «куски ценности».
Декомпозиция не должна быть заменой документации или описанию задачи. Из описания должно быть понятно, что должно быть результатом и что нужно не забыть. Но не обязательно каждый из этих пунктов должен быть отдельной подзадачей.
Другой случай, когда задача сформулирована не в виде ценности, а в виде работы, которую нужно выполнить. Её бывает уместно декомпозировать на независимые подработы.
При кажущейся очевидности пользы декомпозиции, она легко может стать «пятой ногой». Как и любой другой инструмент управления, её стоит использовать осознанно.
Об излишней декомпозиции
Принято считать, что декомпозиция — это хорошо. Она действительно полезна: позволяет устранить неопределённость — разбить большую непонятную задачу так, чтобы можно было охватить её частями. В процессе разбиения мы лучше понимаем состав работ и даже по ходу занимаемся проектированием.
Но излишняя декомпозиция может быть опасна. Она создаёт иллюзию, что фича состоит только из технических задач, на которые мы её разбили.
🔹 Декомпозиция — это накладные расходы. Не только на создание и работу с отдельными задачами, но и на то, что задачи нужно делать отдельно: поддерживать отдельный жизненный цикл, реализовывать и выкатывать по отдельности.
🔹 Искусственная необходимость декомпозиции может приводить к преждевременному проектированию и планированию. Для того, чтобы декомпозировать, нужно спроектировать. Но часто на старте недостаточно информации для проектирования и мы делаем «как-то». Но потом не переделываем по мере поступления информации. Ведь мы же уже декомпозировали, надо делать!
🔹 Декомпозиция создает иллюзию контроля. Сделал половину подзадач — значит сделал полфичи. Сделал все подзадачи — сделал целиком. Это не так. Чтобы сделать фичу, недостаточно сделать все её подзадачи. Фича обычно больше, чем совокупность подзадач. Результаты подзадач ещё нужно собрать — и понять, что фича целиком выполнена. Есть эмерджентность — ценность, которую даёт совокупность результатов подзадач, и которой нет в простой сумме этих результатов. Чтобы фича была сделана, эта ценность должна быть тоже реализована.
🔹 Часто декомпозиция просто не имеет смысла. Например, фича достаточно простая и её можно сделать целиком «за один присест».
Декомпозиция фичи уместна, когда мы её разделяем по принципу поставки: на части, которые сами по себе являются конечным результатом с точки зрения продукта или сценария использования.
Не нужно декомпозировать фичу на работы (например, «разработать фронтенд», «разработать бэкенд», «написать миграцию»), лучше декомпозировать на отдельные «куски ценности».
Декомпозиция не должна быть заменой документации или описанию задачи. Из описания должно быть понятно, что должно быть результатом и что нужно не забыть. Но не обязательно каждый из этих пунктов должен быть отдельной подзадачей.
Другой случай, когда задача сформулирована не в виде ценности, а в виде работы, которую нужно выполнить. Её бывает уместно декомпозировать на независимые подработы.
При кажущейся очевидности пользы декомпозиции, она легко может стать «пятой ногой». Как и любой другой инструмент управления, её стоит использовать осознанно.
👍7❤2🤔1
#management
Об оценках трудоёмкости в разработке
Оценки трудоёмкости не нужны.
То, за сколько времени задача может быть завершена, зависит не только от количества непосредственной работы над ней в часах, но и от многого другого: результатов работы других людей, степени фокусировки на данной задаче, приоритетов, релизной политики и прочего. Задача на 2 часа чистого времени работы может быть отражена на таймлайне как 2 дня — и это не трудоёмкость, а продолжительность.
Здесь вообще не очень применимо понятие трудоёмкости. Мы поставляем ценность, а её величина не пропорциональна затраченному времени. То, сколько будет потрачено реальных часов на задачу (на исследования, разработку, тестирование, деплой, коммуникацию) — не так важно как то, когда результат этой задачи начнёт приносить пользу.
Грубо говоря, важно не сколько часов проведено за работой, а сколько задача лежит не сделанной. Тем более, когда речь о командной работе, где оценивать и складывать количество часов, которые будут потрачены участниками, имеет ещё меньше смысла.
А что может быть полезно?
🔹 Оценить масштаб задачи, фичи или проекта. Например, чтобы соотнести масштаб вложений в реализацию с приносимой пользой и решить что делать в начале, а что потом. Для такой оценки обычно достаточно порядка срока: займет задача день, неделю или месяц работы команды. Это именно оценка масштаба на основе здравого смысла, а не оценка трудоёмкости.
🔹 Если это по какой-то причине требуется, оценить срок завершения: когда фича будет доступна конечным пользователям. То есть наложить масштаб задачи на контекст выполнения с учётом зависимостей, количества доступных ресурсов и других факторов. Оценка здесь — не однонаправленный процесс: не только требуемый результат влияет на срок, но и желаемый срок влияет на конечный результат. При оценке необходимо найти баланс между видом результата и разумностью срока.
🔹 Задать или принять ограничения: дедлайн, количество ресурсов, набор требуемой функциональности.
🔹 Принять ответственность за выполняемую работу, стремиться к разумным срокам, даже если ограничения не заданы. Цель — не в том, чтобы «уложиться в оценку», а в том, чтобы сделать максимально важное за разумное время.
Конечно, бывают задачи, которые можно оценить в часах, и даже ситуации, когда это может быть нужно.
Но не стоит делать это автоматически и думать, что это нужно по умолчанию. В большинстве случаев, по моему опыту, требование оценок трудоёмкости вызвано недоверием, создаёт только иллюзию контроля, впустую тратит драгоценное время и негативно влияет на итоговое качество.
Если вам нужна оценка, понимаете ли вы оценка чего именно и зачем?
Об оценках трудоёмкости в разработке
Оценки трудоёмкости не нужны.
То, за сколько времени задача может быть завершена, зависит не только от количества непосредственной работы над ней в часах, но и от многого другого: результатов работы других людей, степени фокусировки на данной задаче, приоритетов, релизной политики и прочего. Задача на 2 часа чистого времени работы может быть отражена на таймлайне как 2 дня — и это не трудоёмкость, а продолжительность.
Здесь вообще не очень применимо понятие трудоёмкости. Мы поставляем ценность, а её величина не пропорциональна затраченному времени. То, сколько будет потрачено реальных часов на задачу (на исследования, разработку, тестирование, деплой, коммуникацию) — не так важно как то, когда результат этой задачи начнёт приносить пользу.
Грубо говоря, важно не сколько часов проведено за работой, а сколько задача лежит не сделанной. Тем более, когда речь о командной работе, где оценивать и складывать количество часов, которые будут потрачены участниками, имеет ещё меньше смысла.
А что может быть полезно?
🔹 Оценить масштаб задачи, фичи или проекта. Например, чтобы соотнести масштаб вложений в реализацию с приносимой пользой и решить что делать в начале, а что потом. Для такой оценки обычно достаточно порядка срока: займет задача день, неделю или месяц работы команды. Это именно оценка масштаба на основе здравого смысла, а не оценка трудоёмкости.
🔹 Если это по какой-то причине требуется, оценить срок завершения: когда фича будет доступна конечным пользователям. То есть наложить масштаб задачи на контекст выполнения с учётом зависимостей, количества доступных ресурсов и других факторов. Оценка здесь — не однонаправленный процесс: не только требуемый результат влияет на срок, но и желаемый срок влияет на конечный результат. При оценке необходимо найти баланс между видом результата и разумностью срока.
🔹 Задать или принять ограничения: дедлайн, количество ресурсов, набор требуемой функциональности.
🔹 Принять ответственность за выполняемую работу, стремиться к разумным срокам, даже если ограничения не заданы. Цель — не в том, чтобы «уложиться в оценку», а в том, чтобы сделать максимально важное за разумное время.
Конечно, бывают задачи, которые можно оценить в часах, и даже ситуации, когда это может быть нужно.
Но не стоит делать это автоматически и думать, что это нужно по умолчанию. В большинстве случаев, по моему опыту, требование оценок трудоёмкости вызвано недоверием, создаёт только иллюзию контроля, впустую тратит драгоценное время и негативно влияет на итоговое качество.
Если вам нужна оценка, понимаете ли вы оценка чего именно и зачем?
👍9💯3
#management
О плане
Как и с оценками, план-плану рознь. Часто план составляется с некорректными мотивами и в некорректной форме.
🔹 При составлении плана все испытывают большой стресс (берут на себя обязательства в условиях неопределенности, отсутствия корректного проектирования).
🔹 Формируются некорректные ожидания, в погоне за удовлетворением которых создается еще больший стресс, а цель принесения ценности подменяется целью соответствия плану.
🔹 Иллюзия наличия плана позволяет игнорировать необходимость делать контроль неочевидных параметров результата и процесса, что ведет к накоплению проблем, запоздалой реакции на них и замедлению процесса разработки.
Если в команде часто звучит «почему не успеваем?» или «давайте поднажмем, чтобы сделать по плану», то скорее всего у нас план курильщика.
О плане
Как и с оценками, план-плану рознь. Часто план составляется с некорректными мотивами и в некорректной форме.
🔹 При составлении плана все испытывают большой стресс (берут на себя обязательства в условиях неопределенности, отсутствия корректного проектирования).
🔹 Формируются некорректные ожидания, в погоне за удовлетворением которых создается еще больший стресс, а цель принесения ценности подменяется целью соответствия плану.
🔹 Иллюзия наличия плана позволяет игнорировать необходимость делать контроль неочевидных параметров результата и процесса, что ведет к накоплению проблем, запоздалой реакции на них и замедлению процесса разработки.
Если в команде часто звучит «почему не успеваем?» или «давайте поднажмем, чтобы сделать по плану», то скорее всего у нас план курильщика.
👍5🆒1