Или управляй стейкхолдерами или проектом будут управлять они
Если ты не впереди команды по вопросам "Что" и "Когда" то про тебя скорее всего уже думают как про обузу
Ночью проснись но должен помнить и знать ответы на вопросы - "зачем" и "для кого". Рассказывай об этом команде с тем же чувством с которым ты рассказываешь про любимый сериал/фильм
Waterfall не умер. Он хорошо скрывается под маской скрама в большенстве организаций :) Копай глубже в механику итеративной разработки, знай разницу с инкрементальной. Пмбок 7 в помощь
Не гонись за "правами" пма. Мы про поиск способа делать то что должно быть сделано а не про то сколько у кого зарплата, какой пнл, маржа, есть ли у тебя полномочия нанять или уволить. Твоя идентичность в процессе "деланья" и чем сложнее "что" и страшнее "когда" тем ты сильнее. Остальное - инструменты но не цель нашей работы
В техчасти расти в шырь но не в глубь. Лучше ты сможешь порекомендовать 100 новых фильмов чем перескажешь один целиком и точно. Знать детали - ответственность команд. Мы же знаем суть - зачем, плюсы и минусы.
Кайфуй. Подними свой зад и найди тот проект который вставляет. Пофиг на процессы и команду, это исправляемо. Цели и миссия продукта который ты делаешь - нет. Если тебя не прёт проект это видят, не жди что другим будет по кайфу или что ты сможешь таких найти.
Подробнее про скрам я напишу в след статье. Но тут хочу добавить, что скрам позволяет команде ощущать самоорганизацию своей деятельности, ответственность за результат команды, имея при этом полезное регулярное командное взаимодействие, позволяет нам учиться друг у друга, быть действительно командой и выдавать результат.
Большего заблуждения о Скраме сложно и придумать.
Конкретная польза скрама это увеличение продуктивности команды в 3-8 раз по сравнению с работой по водопаду либо большенству старых методологий или самоклёпок.
Увеличение продуктивности достигается за счет насыщения команды информацией. То есть, улучшается коммуникация которая приводит к:
Уменьшению потерь на переделки, благодаря частым сессиям по выявлению ожиданий (Планинги, Демо);
Уменьшение потерь на стыковку и синхронизацию команды за счет регулярного выявления зависимостей и планированию на местах (Дейлики, Планинги);
Сокращение ошибок, и увеличение производительности труда за счет регулярной рефлексии и анализа проделанной работы (Ретроспектива, Демо)
В принципе, это всё про скрам. И этого достаточно что бы он работал и делал свою работу прекрасно. Главная беда это тренеры которые интерпретируют скрам не так, и применяют его не туда.
Очень часто вижу как скрам интепретируется разными авторами по разному и каждый раз далеко от реальности. Сам практикую скрам уже более двух лет и нареканий на него еще не было. Очень качественный фреймворк, при чем даже в условиях фикс прайса и вотерфола. Не понимаю почему скрам часто мешают с agile и путают принципы и практики. Для примера, в скраме самое главное это прозрачность процесса, и своевременность в принятии решений и поднятию проблем. Каждую неделю все в курсе всех событий, всегда актуален план на неделю и представление о следующих неделях. Вот и весь его профит. Считаю его идеальным фреймворком в первую очередь — КОММУНИКАЦИЙ. Не более того. Управление разработкой и скрам лежат в разных плоскостях. Тот же скрам использую для управления документированием проекта, его ресёрчем, дизайном. Главное это прозрачность в планировании, исполнении, произведению выводов. Прекрасный процесс
По-моему, самое лучшее ТЗ это то в котором написано с позиции пользователя. То есть, то что должно получиться если на продукт смотрят с точки зрения пользователя. Это уже не ТЗ а функциональная спецификация, и уже на её основе команда пишет техническую документацию или ТЗ в котором описывает что и как предполагается делать вплоть до моделей, эндпоинтов апи, архитектуры, стэка технологий. Чаще всего, функционалки достаточно что бы сделать типовый проект которые уже в компании делались не раз и имеют очень легкие отклонения в функционале. Если же проект не типовый то полному циклу.
Мой вариант который работает — тестировщик = пользователь. Он делает блек бокс тестирование билда который получается в результате спринта и который уходит клиенту. Весь фидбек группируется и уходит в беклог. Что то команда сама нашла и поправила, что то нет и надо планировать на спринт. Таким образом тестировщику не нужно знать что куда и как, он просто юзер, а точность бизнес логики функционала проверяется превентивно — описывая спецификацию на фичу, как функциональную так и техническую и последующая разработка через TDD и CI с интеграционными тестами, и пасивно бегающие юнит тесты проверяющие бизнес логику в целом. Если разработчиков ни кто не гонит, то даже джуны делая соизмеримые для себя задачи, делают их качественно и с полным циклом процесса, пускай даже убиваясь над тестами больше чем над разработкой. Качество получаемого продукта не сравнимое с ручным тестированием.
Скрам это хороший инструмент. Он не работает там где его не правильно поняли и не правильно используют.
Причина зачем нужны дейли — синхронизация и микропланирование. Мало кто делает дейли до конца и заканчивают только синхронизацией сами не понимая зачем. Регулярно звучат комментарии «по борде видно кто чо делает». Это так. Но правильный флоу дейли это проговорить структурировано о состоянии задач в прогрессе и о следующих планах и скорректировать эти планы конкретно на месте. Когда собрана вся команда, это сделать проще нежели решать через чат или через скайп. Эти 5-10 минут себя окупают, получается с глазу на глаз все согласовать на сегодня-завтра намного быстрее. Плюс, важна неформальная обстановка. Я предпочитаю проводить дейли на улице, благо офис позволяет и мы на 2м этаже а улица выходит в наш собственный дворик со столиком. В любое время года на улице хорошо. Жопе, спине и голове легче нежели ютится в каких то проходах или переговорках где витает атмосфера бюрократии.
Основная фишка скрама это команда>клиент&менеджер. Скрам дает команде картбланш. Команда имеет право решить что она будет делать и делать это так что бы ни кто их не трогал ровно спринт. Какие то новые вбросы, дедлайны? Пошли к черту. Что то надо поправить срочно на продакшене? Пошли к черту, нанимайте сапорт или девопс.
Самая главная фишка без которой не работает скрам вообще это Difinition of Done. У команды должен он быть. Команда выпустит фичи за спринт те которые она успеет и те которые будут на 100% соответстовать DoD. Они будут закончены, они будут протестированы, код будет отрефакторен, задокументирован, и готов как полноценный инкремент. Команда в конец спринта представляет конкретный инкремент готового функционала, а всё что в прогрессе остается в отдельных ветках. Всё.
Дальше уже право заказчика или менеджера интегрировать инкремент на продакшн или ждать новый. Базовыми метриками менеджер легко вычисляет скорость команды. Что потрачено у каждого 40ч, а задач поделано с оценками сумарно на 20ч, итого скорость 20ч или 50% от номинала. С каждым спринтом эта цифра будет стабилизироватся и будет отличное понимание Велосити. С ним уже можно работать, воспитывать людей или менять или добавлять кого то еще в команду, докручивать процессы, искать причины такого велосити. Вот где компетентность менеджера.
Чаще всего я вижу, что менеджеры пытаются быть сразу скрам мастерами и внешними менеджерами. Они начинают внутри спринта устраивать свое подобие вотерфола и классики, начинать вкидывать по ходу спринта еще задач потому что клиент ему на почту написал и в скайп продублировал. И это превращается уже не в скрам а в *скрамНО.
Беда скрама в том что его не правильно готовят. И не там применяют. И тем более, команда не готова к скраму, она не обучена по нему работать, и одни процессы скрама подменяются какими то похожими издалека подобиями. Если люди не могут понять истинной пользы и сути дейли, при этом активно скрамясь то я боюсь предположить как делаются оставшиеся скрам активности.
На ретроспективе наверное менеджер всем в лоб по очереди задает вопросы «Артём, что у нас на этом спринте было хорошо а что плохо?» и получает ответ «Ээээм, ну х%1 его знает».
Согласен абсолютно. Приходилось менеджерить проект от лица аутсорсеров для крупного холдинга который делал сайт для своих сотрудников коих несколько тысяч человек. Сумарно было около десятка менеджеров отделов и их 1-2 помощников. Всё сводилось к отфутболиванию, т.к. ни кто не был заинтересован в проекте. Взаимодействие с аутсорсером людям просто навязали сверху и они делали что-то только когда руководство пинает.
Фаза аналитики продлилась 4 месяца. Выход был найден так же, конклавом но т.к. все были в разных странах и городах, то митинг был проведен по тимвьюверу. Все отменили свои дела, сели за тимвьювер и смотрели на экран прототипировщика.
Достаточно было рабочего дня с запасом, что бы финализировать всё даже самое мелкое и согласовать между всеми.
Очень спорные ошибки, по моему мнению. Особенно утверждение, что пм должен — вместе с командой успешно реализовать проект. У кого то есть инструкция, что бы наверняка?!
Из самых важных проблем юных ПМ по моему мнению:
— Недостаточная согласованность (не убеждаются, что стороны имеют одинаковое понимание в аспектах, вопросах, процессах. Как на уровне исполнитель-заказчик, так и на уровне внутри компании. Типичный ответ джун пма при проблемах — «я думал он все понял» или «это же было очевидно»)
— Недостаточное документирование (мало пишут и много говорят. как следствие, детали размываются либо теряются. постановка задач личная, на пальцах, либо по скайпу в голос. мало пишут в таски, трекер, почту.)
— Не делегируют (пытаются все делать самостоятельно забирая на себя большие полномочия и возможности. как следствие, перегружены и считают, что другие с обязанностями справятся хуже либо не справятся вообще)
Это три основных которые ведут к самым популярным ошибкам и проблемам.
И последняя на закуску — пытаются подружится с клиентом. Это поведение жертвы. Как следствие, не могут клиенту отказать либо оспорить. Потом клиенты катаются на шее и не относятся к исполнителю как к профессионалу.
Вижу мы не находим общего в обсуждении мотивации. Посему, прошу – поправьте ссылки. По ним кракозябра. Просит открывать в интернет эксплорере, а у меня как у макоюзера с этим сложности.
Какая может быть мотивация в прозрачности?! Мы говорим о мотивах. У вас в команде мотив единственный – сделать отсюда до сюда и получить денежное вознаграждение. Если при слове мотивация вы начинаете ответ с премий, то вы либо не понимаете где мотивация либо не с того начали.
Я бы отметил два первостепенных элемента мотивации с которых следует начать всем:
1. Увеличить мотивацию работать с руководством за счет уменьшения отношения к руководству как «начальник=мудак»;
2. Увеличить мотивацию работать на клиента за счет уменьшения отношения к клиенту как «клиент=идиот»;
Поработайте в команде и послушайте что о вас думают люди, и что они думают о клиентах. Упростив два описанных фактора, мотивация команды на продуктивную работу увеличивается. Убрав начальник=мудак, люди меньше допускают ошибок и проблем, т.к. не дали, не предупредили, я на это не подписывался, мне за это не платят и т.п. И убрав клиент=идиот (который чаще всего вносится в команду от начальник=мудак), люди более настроены сделать в срок потому что клиенту надо, а не им надо что бы их не выгнали.
Начальник должен быть частью команды и должен разруливать проблемы, а клиент должен быть доступен и быть в пределах видимости команды. Вот с этих двух мотиваторов я бы начинал везде.
Для кого этот устав? Для команды или для менеджера?!
Вы написали уже 7 статей, но ни одна не была посвящена трем столпам на которых держится вся работа в 2015 году — мотивация, коммуникация, команда.
13 лет в пм, мои 10 копеек :)
Мы про "Что" и "Когда", а они про "Как"
HR не панацея. Пипл менеджмент маст
Коротко и ценно, лучше чем
Или управляй стейкхолдерами или проектом будут управлять они
Если ты не впереди команды по вопросам "Что" и "Когда" то про тебя скорее всего уже думают как про обузу
Ночью проснись но должен помнить и знать ответы на вопросы - "зачем" и "для кого". Рассказывай об этом команде с тем же чувством с которым ты рассказываешь про любимый сериал/фильм
Waterfall не умер. Он хорошо скрывается под маской скрама в большенстве организаций :) Копай глубже в механику итеративной разработки, знай разницу с инкрементальной. Пмбок 7 в помощь
Не гонись за "правами" пма. Мы про поиск способа делать то что должно быть сделано а не про то сколько у кого зарплата, какой пнл, маржа, есть ли у тебя полномочия нанять или уволить. Твоя идентичность в процессе "деланья" и чем сложнее "что" и страшнее "когда" тем ты сильнее. Остальное - инструменты но не цель нашей работы
В техчасти расти в шырь но не в глубь. Лучше ты сможешь порекомендовать 100 новых фильмов чем перескажешь один целиком и точно. Знать детали - ответственность команд. Мы же знаем суть - зачем, плюсы и минусы.
Кайфуй. Подними свой зад и найди тот проект который вставляет. Пофиг на процессы и команду, это исправляемо. Цели и миссия продукта который ты делаешь - нет. Если тебя не прёт проект это видят, не жди что другим будет по кайфу или что ты сможешь таких найти.
Большего заблуждения о Скраме сложно и придумать.
Конкретная польза скрама это увеличение продуктивности команды в 3-8 раз по сравнению с работой по водопаду либо большенству старых методологий или самоклёпок.
Увеличение продуктивности достигается за счет насыщения команды информацией. То есть, улучшается коммуникация которая приводит к:
В принципе, это всё про скрам. И этого достаточно что бы он работал и делал свою работу прекрасно. Главная беда это тренеры которые интерпретируют скрам не так, и применяют его не туда.
Причина зачем нужны дейли — синхронизация и микропланирование. Мало кто делает дейли до конца и заканчивают только синхронизацией сами не понимая зачем. Регулярно звучат комментарии «по борде видно кто чо делает». Это так. Но правильный флоу дейли это проговорить структурировано о состоянии задач в прогрессе и о следующих планах и скорректировать эти планы конкретно на месте. Когда собрана вся команда, это сделать проще нежели решать через чат или через скайп. Эти 5-10 минут себя окупают, получается с глазу на глаз все согласовать на сегодня-завтра намного быстрее. Плюс, важна неформальная обстановка. Я предпочитаю проводить дейли на улице, благо офис позволяет и мы на 2м этаже а улица выходит в наш собственный дворик со столиком. В любое время года на улице хорошо. Жопе, спине и голове легче нежели ютится в каких то проходах или переговорках где витает атмосфера бюрократии.
Основная фишка скрама это команда>клиент&менеджер. Скрам дает команде картбланш. Команда имеет право решить что она будет делать и делать это так что бы ни кто их не трогал ровно спринт. Какие то новые вбросы, дедлайны? Пошли к черту. Что то надо поправить срочно на продакшене? Пошли к черту, нанимайте сапорт или девопс.
Самая главная фишка без которой не работает скрам вообще это Difinition of Done. У команды должен он быть. Команда выпустит фичи за спринт те которые она успеет и те которые будут на 100% соответстовать DoD. Они будут закончены, они будут протестированы, код будет отрефакторен, задокументирован, и готов как полноценный инкремент. Команда в конец спринта представляет конкретный инкремент готового функционала, а всё что в прогрессе остается в отдельных ветках. Всё.
Дальше уже право заказчика или менеджера интегрировать инкремент на продакшн или ждать новый. Базовыми метриками менеджер легко вычисляет скорость команды. Что потрачено у каждого 40ч, а задач поделано с оценками сумарно на 20ч, итого скорость 20ч или 50% от номинала. С каждым спринтом эта цифра будет стабилизироватся и будет отличное понимание Велосити. С ним уже можно работать, воспитывать людей или менять или добавлять кого то еще в команду, докручивать процессы, искать причины такого велосити. Вот где компетентность менеджера.
Чаще всего я вижу, что менеджеры пытаются быть сразу скрам мастерами и внешними менеджерами. Они начинают внутри спринта устраивать свое подобие вотерфола и классики, начинать вкидывать по ходу спринта еще задач потому что клиент ему на почту написал и в скайп продублировал. И это превращается уже не в скрам а в *скрамНО.
Беда скрама в том что его не правильно готовят. И не там применяют. И тем более, команда не готова к скраму, она не обучена по нему работать, и одни процессы скрама подменяются какими то похожими издалека подобиями. Если люди не могут понять истинной пользы и сути дейли, при этом активно скрамясь то я боюсь предположить как делаются оставшиеся скрам активности.
На ретроспективе наверное менеджер всем в лоб по очереди задает вопросы «Артём, что у нас на этом спринте было хорошо а что плохо?» и получает ответ «Ээээм, ну х%1 его знает».
Фаза аналитики продлилась 4 месяца. Выход был найден так же, конклавом но т.к. все были в разных странах и городах, то митинг был проведен по тимвьюверу. Все отменили свои дела, сели за тимвьювер и смотрели на экран прототипировщика.
Достаточно было рабочего дня с запасом, что бы финализировать всё даже самое мелкое и согласовать между всеми.
Из самых важных проблем юных ПМ по моему мнению:
— Недостаточная согласованность (не убеждаются, что стороны имеют одинаковое понимание в аспектах, вопросах, процессах. Как на уровне исполнитель-заказчик, так и на уровне внутри компании. Типичный ответ джун пма при проблемах — «я думал он все понял» или «это же было очевидно»)
— Недостаточное документирование (мало пишут и много говорят. как следствие, детали размываются либо теряются. постановка задач личная, на пальцах, либо по скайпу в голос. мало пишут в таски, трекер, почту.)
— Не делегируют (пытаются все делать самостоятельно забирая на себя большие полномочия и возможности. как следствие, перегружены и считают, что другие с обязанностями справятся хуже либо не справятся вообще)
Это три основных которые ведут к самым популярным ошибкам и проблемам.
И последняя на закуску — пытаются подружится с клиентом. Это поведение жертвы. Как следствие, не могут клиенту отказать либо оспорить. Потом клиенты катаются на шее и не относятся к исполнителю как к профессионалу.
Я бы отметил два первостепенных элемента мотивации с которых следует начать всем:
1. Увеличить мотивацию работать с руководством за счет уменьшения отношения к руководству как «начальник=мудак»;
2. Увеличить мотивацию работать на клиента за счет уменьшения отношения к клиенту как «клиент=идиот»;
Поработайте в команде и послушайте что о вас думают люди, и что они думают о клиентах. Упростив два описанных фактора, мотивация команды на продуктивную работу увеличивается. Убрав начальник=мудак, люди меньше допускают ошибок и проблем, т.к. не дали, не предупредили, я на это не подписывался, мне за это не платят и т.п. И убрав клиент=идиот (который чаще всего вносится в команду от начальник=мудак), люди более настроены сделать в срок потому что клиенту надо, а не им надо что бы их не выгнали.
Начальник должен быть частью команды и должен разруливать проблемы, а клиент должен быть доступен и быть в пределах видимости команды. Вот с этих двух мотиваторов я бы начинал везде.
Вы написали уже 7 статей, но ни одна не была посвящена трем столпам на которых держится вся работа в 2015 году — мотивация, коммуникация, команда.