#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 есть статусы руководителей отделов и статусы руководителей проектов, на которых присутствуют и вертикальные, и горизонтальные руководители. А ещё в этом помогает просто живое общение: даже «кухонные» разговоры помогают синхронизироваться.
🔸 Транслируйте принципы принятия решений, а не регламенты.
В быстро меняющихся обстоятельствах принципы работают лучше, чем четкие правила. Об этом хорошо и подробно изложено в книге Рэя Далио «Принципы». Чтобы сформулированные принципы оставались полезными, регулярно пересматривайте их с учетом изменения контекста.
🔸 Разработайте рациональные принципы распределения ресурсов и четко их придерживайтесь.
Не допускайте конкуренции горизонтальных руководителей за ресурсы. Для этого хорошо периодически проверять адекватность распределения ресурсов. Далеко не всегда принцип «кто первый пришел, того и ресурс» работает на пользу компании.
🔸 Компенсируйте психологический стресс сотрудников.
Матричная структура подвижна, команды очень часто пересобираются, а значит, разрушаются сформированные отношения с сокомандниками, и сотруднику приходится строить новые отношения в проектной команде. Это противоречит базовой потребности человека в стабильных взаимоотношениях и вызывает внутреннее напряжение.
О каком пункте рассказать подробнее?
#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