О да! Выделить рабочую от заказчика этот бывает тот еще квест. При чем даже если людей выделяют, то часто внедрение нового ПО идет в дополнение к основным обязанностям. Тем самым люди перегружаются, ничего не успевают, отмахиваются от внедренцев.
Об этом стоит говорить с Заказчиков при старте проекте. На уровне РП. Доносить до Заказчика, что должна быть рабочая группа и что у сотрудников должно быть выделено время на внедрение.
И не забывать включать обучение, инструкции в скоуп работ.
Спасибо, за кейс. Что бы такого избежать, на этапе оценки стоит привлекать спецов. Даже если сейл уверен в своих знаниях, валидация со стороны команды не будет лишней.
Еще момент, это закладывать риски, сколько закладывать зависит от первоначальных вводных: насколько вам знаком Заказчик, насколько есть опыт в сфере, и не забывать про команду - кто это будет реализовывать. Это сложно, но возможно.
Еще хочется отдельно отметить, про определение стейкхолдеров. Есть кто платит, а есть кто будет пользоваться. "Большие дяди" о которых вы говорите, скорей всего являются спонсорами и вероятно они озвучивают бизнес требования. Стоит выявить у Заказчика тех людей, которые будут предъявлять функциональные требования.
В нашей сфере я использую следующие способы. Если позволяет ситуация, предлагаю начать с MVP. На этапе проработки MVP мы покажем, как мы работаем. Это Заказчику позволяет наглядно увидеть, за что он платит. И после реализации поймем работаем ли дальше вместе или нет.
Детализирую скоуп работ и вместе с Заказчиком обсуждаем, какие работы можем исключить. Или, например, с целью уменьшения бюджета, часть работ Заказчик может взять на себя.
Таков мой опыт. Я наблюдала (и участвовала) в ситуациях, когда наобещаем вначале, а по итогу, не попадаем практически ни в одно обещание. И в результате все недовольны: заказчик, который ожидал другой результат, или этот результат но за другие деньги/за другое время; команда, которая работала сверхнормы, или с постоянно меняющимися требованиями и тп. Ваш пример очень интересный, после того как ввязались успешно разбирались?
Я считаю свои 70% времени по количеству выполненных задач/вопросов. Пока не использую никакой инструмент - так что можно сказать "на глазок".
Согласна с тем, что вы написали. Добавлю, что не обязательно ждать когда работодатель придет и скажет про работу, можно самому пойти к нему и поговорить о своей загрузке. Мне кстати это помогло, сейчас нормализую рабочий день.
Чувство ответственности я ценю в себе и ценю в команде. Однако, когда это становится уже гиперответсвенностью, с этим уже нужно работать.
Понимаю о чем говорите, и от этого еще грустнее становится. Мне кажется нужно обсуждать со своим РП, лидом. Плохо что они не понимают, но может быть разговорами получится хоть чуть-чуть переубедить.
В тему встречала поясняющую картинку
Есть же еще не такой распиаренный термин MMP (minimal marketable product). Это вот как раз стадия продукта, когда он конкурентно способный.
Как в статье написано, если Заказчик готов на такой подход :)
Полазила по сайту - интересно. Спасибо за ссылку!
Спасибо большое! У вас крутой опыт.
Про "скопировать механизм в новую" очень знакомо. Сама афигевала от таких предложений.
И про невидимость лишней функциональности - плюсую. И по разделение команды Заказчика.
В общем и целом, согласна с вами.
О да! Выделить рабочую от заказчика этот бывает тот еще квест. При чем даже если людей выделяют, то часто внедрение нового ПО идет в дополнение к основным обязанностям. Тем самым люди перегружаются, ничего не успевают, отмахиваются от внедренцев.
Об этом стоит говорить с Заказчиков при старте проекте. На уровне РП. Доносить до Заказчика, что должна быть рабочая группа и что у сотрудников должно быть выделено время на внедрение.
И не забывать включать обучение, инструкции в скоуп работ.
Спасибо, за кейс. Что бы такого избежать, на этапе оценки стоит привлекать спецов. Даже если сейл уверен в своих знаниях, валидация со стороны команды не будет лишней.
Еще момент, это закладывать риски, сколько закладывать зависит от первоначальных вводных: насколько вам знаком Заказчик, насколько есть опыт в сфере, и не забывать про команду - кто это будет реализовывать. Это сложно, но возможно.
Еще хочется отдельно отметить, про определение стейкхолдеров. Есть кто платит, а есть кто будет пользоваться. "Большие дяди" о которых вы говорите, скорей всего являются спонсорами и вероятно они озвучивают бизнес требования. Стоит выявить у Заказчика тех людей, которые будут предъявлять функциональные требования.
А наличие опыта компании не помогает показать что у вас адекватное предложение?
Отзывы других Заказчиков? Бывают, что новый Заказчик просит рекомендации от уже существующих.
Проблематику понимаю.
В нашей сфере я использую следующие способы. Если позволяет ситуация, предлагаю начать с MVP. На этапе проработки MVP мы покажем, как мы работаем. Это Заказчику позволяет наглядно увидеть, за что он платит. И после реализации поймем работаем ли дальше вместе или нет.
Детализирую скоуп работ и вместе с Заказчиком обсуждаем, какие работы можем исключить. Или, например, с целью уменьшения бюджета, часть работ Заказчик может взять на себя.
Спасибо за комментарий. Учту!
Таков мой опыт. Я наблюдала (и участвовала) в ситуациях, когда наобещаем вначале, а по итогу, не попадаем практически ни в одно обещание. И в результате все недовольны: заказчик, который ожидал другой результат, или этот результат но за другие деньги/за другое время; команда, которая работала сверхнормы, или с постоянно меняющимися требованиями и тп. Ваш пример очень интересный, после того как ввязались успешно разбирались?
Спасибо за комментарий!
Я считаю свои 70% времени по количеству выполненных задач/вопросов. Пока не использую никакой инструмент - так что можно сказать "на глазок".
Согласна с тем, что вы написали. Добавлю, что не обязательно ждать когда работодатель придет и скажет про работу, можно самому пойти к нему и поговорить о своей загрузке. Мне кстати это помогло, сейчас нормализую рабочий день.
Чувство ответственности я ценю в себе и ценю в команде. Однако, когда это становится уже гиперответсвенностью, с этим уже нужно работать.
Опасаюсь выгорания команды. Можно конечно поработать когда горит сверхурочно, но на постоянной основе это может быть опасно
А почему время на прокрастинировать не должно быть подотчетным?
Ну невозможно же все 8мь часов быть продуктивным, чай налить тоже нужно :)
Вы правы. Но статья не про формальный трудовой кодекс.
Согласна. Тут не в методологии дело, а в управлении.
Спасибо за совет, работаю над собой!
Прикольная история, спасибо что поделились. Тут либо готов мириться с таким специалистом и тогда сам меняешь подход к нему, либо расставаться.
Мне ближе первый путь - так что я солидарна с вашими управленцами, скорей всего поступила бы также.
Понимаю о чем говорите, и от этого еще грустнее становится. Мне кажется нужно обсуждать со своим РП, лидом. Плохо что они не понимают, но может быть разговорами получится хоть чуть-чуть переубедить.
Полностью согласна. Руководитель не радоваться должен, что сотрудник перерабатывает, а для него это должно быть тревожным звоночком.