Помню одного практика NLP перезеркалил в неудобную позу, потом спросил, как товарищ так неудобно сел

DHE гораздо экологичней, NLP суть манипуляция

NLP - инструмент. Вы можете забивать молоком гвозди, а можете ударить человека. Все зависит от того, как мы им пользуемся.

Marina Simonova. Моя история. Искали Скрам Мастеров для одной компании. Приходит на собеседование человек, рассказывает как сильно он хочет им стать. И в конце рассказа говорит: "Есть один момент, я ненавижу людей, скажите, это же не помешает?"

Marina Simonova. Моя история. Искали Скрам Мастеров для одной компании. Приходит на собеседование человек, рассказывает как сильно он хочет им стать. И в конце рассказа говорит: "Есть один момент, я ненавижу людей, скажите, это же не помешает?"

🙊🙈😂

Не помешает))) Хаха)

из интровертов в целом неплохие СМы получаются) А от интроверсии до мизантропии полшага))

Marina Simonova. Моя история. Искали Скрам Мастеров для одной компании. Приходит на собеседование человек, рассказывает как сильно он хочет им стать. И в конце рассказа говорит: "Есть один момент, я ненавижу людей, скажите, это же не помешает?"

Что бы доставать разработчикав как раз это и надо)

Хм. А зачем их доставать?

Кода работу затягивают

😳

Кода работу затягивают

попробуйте не рычать на собаку?

достаточно сесть и понять, что основной вид деятельности разработчика - не нажимание кнопок, но работа с неопределенностью и принятие ответственности за конечный результат

когда на входе не совсем понятные требования - все как раз начинает затягиваться

В моем случае с требованиями все хорошо. У разработчиков возникают трудности и сроки которые согласованны с ними увеличиваются почти в два раза. Понимаю что они не бездельничают но и тянуться это не может бесконечно

декомпозируйте)

Траллирует дэвушка ) Или она ошиблась каналом )

В моем случае с требованиями все хорошо. У разработчиков возникают трудности и сроки которые согласованны с ними увеличиваются почти в два раза. Понимаю что они не бездельничают но и тянуться это не может бесконечно

А у Вас Скрам? Какие там могут быть сроки? там же Спринты?

Спринты. Задачи по спиртам стоят. Но постоянно переносятся из одного спиринта в другой. Опоздания по срокам на месяц

а спирты бутиратные?

Спринты. Задачи по спиртам стоят. Но постоянно переносятся из одного спиринта в другой. Опоздания по срокам на месяц

а команда разработки видит в этом проблему?

Видит, но сделать не чего пока не может

о, было у меня такое, перенос задач из текущего спринта в следующий. правда потом я это называл уже не скрамом, а полным ватерфолом. было ещё наплевательское отношение к срокам на всех уровнях - от босса до конечного разраба. разрабу главное отмазку придумать и делать на легке. а босс важным видом приходит, собирает всех вместе, "декомпозирует" эпики, ставит сроки, о которых сам же потом забывает. в итоге всем на всё плевать. тут охота узнать, топы в курсе этой проблемы(что сроки 2х валятся)? они сами интересуются о сроках? это же дело с обычным понятием "обещание". Команда дает обещание, что сделает что-то к такому сроку. Если обещание не выполнено, нужно реагировать: пусть проводят ретро, изучают почему. главное - чтоб они сами это понимали, что валить сроки - это плохо. лучше перестраховаться, чем "обмануть" бизнес. И да, если бизнес давит во время определения сроков по оценкам задач - команде приходится давать маленькие значения, за которых 100% не будет отвечать. это всё как-то неосознанно происходит.

Возможно, изначально при планировании спринта задается не корректно время на реализацию.

Возможно, изначально при планировании спринта задается не корректно время на реализацию.

время не корректно - потому что разроаботчики не могли учесть всех проблем На верху это знают. По сути я в команде системный аналитик и за сроки отвечает РП. но не могу спокойно смотреть как затягивается работа и нет возможности идти дальше

по поводу обещаний - команда при токсичном поведении топов перестает давать обещания, топы начинают спускать сроки сверху)

Обычно при планировании спринта. разработчики при обсуждении по сути должны были учесть возможные проблемы. И тут уже решается-не включать в спринт, либо включать и учесть немного больше времени на спринт с учетом этих возникших проблем.

Ранее я просто обычно брал очень хороший запас времени. И выдавал Бизнесу - при этом бизнес уже в курсе времени и не дергает.

Ранее я просто обычно брал очень хороший запас времени. И выдавал Бизнесу - при этом бизнес уже в курсе времени и не дергает.

ну эт как раз альтернатива лечь полностью под бизнес)

Почему же сразу лечь). Всегда надо брать запас времени.

время не корректно - потому что разроаботчики не могли учесть всех проблем На верху это знают. По сути я в команде системный аналитик и за сроки отвечает РП. но не могу спокойно смотреть как затягивается работа и нет возможности идти дальше

И вы как системный аналитик до сих пор не провели анализ корневой проблемы? И предлагаете рычать и спускать споки сверху?

И вы как системный аналитик до сих пор не провели анализ корневой проблемы? И предлагаете рычать и спускать споки сверху?

👍

И вы как системный аналитик до сих пор не провели анализ корневой проблемы? И предлагаете рычать и спускать споки сверху?

да наверное это мой косяк, потому что проблемы находится одной области, а разработчик каждый раз пишет что возникли проблемы и ему надо больше времени, или выводит не работающий или полусырой функционал и я возвращаю ему на доработку

Вообще любые возникающие проблемы надо обсуждать и решать сразу. В будущем это поможет

Мне вот это выражение понравилось """Мы думаем, что всё отлично заработает с первого Спринта В первом Спринте у Команды обычно полный бардак. Необходимо время, чтобы Команда начала эффективно взаимодействовать. Сразу сказать, что Скрам не работает, легко: «Эй, смотрите на этот бардак! Команда не сделала ничего полезного за этот Спринт, они половину времени спорили о цифрах на стикерах!» Но будьте терпеливы, дайте Команде время, чтобы совершить ошибки и научиться на них."""

Спринты. Задачи по спиртам стоят. Но постоянно переносятся из одного спиринта в другой. Опоздания по срокам на месяц

Вы оцениваете задачи? Мы бъем стори так, чтобы они ложились в Спринт. Используем DoR. Это как раз помогает.

время не корректно - потому что разроаботчики не могли учесть всех проблем На верху это знают. По сути я в команде системный аналитик и за сроки отвечает РП. но не могу спокойно смотреть как затягивается работа и нет возможности идти дальше

Все задачи у нас декомпозируют и оценивают команды. Нет выделенных аналитиков.

да наверное это мой косяк, потому что проблемы находится одной области, а разработчик каждый раз пишет что возникли проблемы и ему надо больше времени, или выводит не работающий или полусырой функционал и я возвращаю ему на доработку

А у Вас проводятся PBR? Это когда команды разработки детализируют себе задачи на один-два Спринта вперед? По моей практике это 80% успеха. Если они недосточно проработаны, возникают ошибки с оценкой и пониманием задачи.

И как следствие они не успевают сделать их в Спринт.

Вы оцениваете задачи? Мы бъем стори так, чтобы они ложились в Спринт. Используем DoR. Это как раз помогает.

оцениваем задачи в рамках спринта их важность и обьем

А у Вас проводятся PBR? Это когда команды разработки детализируют себе задачи на один-два Спринта вперед? По моей практике это 80% успеха. Если они недосточно проработаны, возникают ошибки с оценкой и пониманием задачи.

именно)

оцениваем задачи в рамках спринта их важность и обьем

Их нужно оценивать до планирования Спринта. Иначе как Вы поймете сколько и каких задач можно брать в Спринт? Важность оценивает Владелец Продукта, объем работ ВСЕ ЧЛЕНЫ команды

Их нужно оценивать до планирования Спринта. Иначе как Вы поймете сколько и каких задач можно брать в Спринт? Важность оценивает Владелец Продукта, объем работ ВСЕ ЧЛЕНЫ команды

Они оценивают. Включают объем работы. Но на спринте этот объем не могут выполнить.

Они оценивают. Включают объем работы. Но на спринте этот объем не могут выполнить.

Мы в DoR ограничиваем максимальный размер задач в 13, хотя за Спринт по идее можно сделать 21.

Они оценивают. Включают объем работы. Но на спринте этот объем не могут выполнить.

Значит надо брать меньше задач. Как вариант.

Согласен.

Я думаю идет неправильная оценка объема работ. В этом и проблема

По сути команда должна на второй части Планирования (на котором она отвечает на вопрос КАК) разобрать задачу на техтаки. В конце планирования она должна быть в состоянии рассказать Продакт Овнеру или Скрам-мастера КАК они собираются сделать эту задачу.

Т.е они уже на второй части в день планирования должны понять что не сделают ее вовремя :)

И я всегда рекомендую командам техтаски оценивать в часах

Это удобно.

дочитал, что было "тех")

Попробуйте визуализировать в виде дорожки. В ToDo история, оцененная в Стори поинтах (не или в попугаях, собаках ), а по дорожке уже техтаски, оцененные в часах. мы разбиваем их до уровня человека. Т.е. одну таску может оченить в часах разработчик и взять ее в работу. Поток техтасок идет по дорожке, виден прогресс на Дейли. Как только заканчивается поток, стори переносим в Done

дочитал, что было "тех")

Стори с SP, а ужее ее на Спринт-бэклоге бить на часы, да.

оцениваем задачи в рамках спринта их важность и обьем

Проблема в оценке. Разработчики нормально не оценивают задачи. Не видят возможные проблемы в реализации. Из за этого и страдаете. Главное - грамотная постановка задач.

Проблема в оценке. Разработчики нормально не оценивают задачи. Не видят возможные проблемы в реализации. Из за этого и страдаете. Главное - грамотная постановка задач.

Это тоже важно. Если задача непонятная, разработчики на Общем PBR с представителями команд в "Покере планирования" (карты с числами Фибоначчи) могут выкинуть карты с бомбой (есть там акая) - задача уходит назад к Продакту.

Иногда такое у нас бывает, редко конечно. PO задачу вытащит на PBR, команды для прояснения вопросы начинают задавать, а он начинает "плавать". И он сам принимает решение убрать ее из PBR.

буду плотнее работать с разработчиками. и буду вводить более четкую оценку задачь по объему работы Спасибо за советы! Если есть еще коментарии, пиши. Рада что такой живой отклик получила)

Спршивай, чем смогу помогу.

буду плотнее работать с разработчиками. и буду вводить более четкую оценку задачь по объему работы Спасибо за советы! Если есть еще коментарии, пиши. Рада что такой живой отклик получила)

И да. Оценку должны проводить разработчики. Посмотри про "Покер планирования". У нас очень хорошо зашел.

#whois Коллеги, всем добрый день! Меня зовут Дарья, работаю в Санкт-Петербурге, менеджер проектов в IT компании. Уровень у меня скорее начинающий, опыта не очень много. Для сообщества могу быть полезна в следующих темах: работа с распределенными командами, работа с мультикультурными командами, мотивация и рост в команде. Для меня сообщество - кладезь полезной информации, а также возможность задать вопрос коллегам, получить обратную связь, поделиться опытом, обсудить интересные темы. Про группу узнала из канала Романа Ковалевского @Roman_Kovalevsky

#whois Коллеги, всем добрый день! Меня зовут Дарья, работаю в Санкт-Петербурге, менеджер проектов в IT компании. Уровень у меня скорее начинающий, опыта не очень много. Для сообщества могу быть полезна в следующих темах: работа с распределенными командами, работа с мультикультурными командами, мотивация и рост в команде. Для меня сообщество - кладезь полезной информации, а также возможность задать вопрос коллегам, получить обратную связь, поделиться опытом, обсудить интересные темы. Про группу узнала из канала Романа Ковалевского @Roman_Kovalevsky

работа с мультикультурными командами —— с индусами?)

мультикультурные это американцы скорее

Дарья образно

это может быть СПБ + индусы :)

или СПБ+ США

мультикультурные - это когда в команде несколько разных культур:) международные в общем

😄

спс кеп :)

а какие культуры были то?)

мультикультурные - это когда в команде несколько разных культур:) международные в общем

это накладывало специфику на общение или только на проектирование системы под определенный регион?

спс кеп :)

какой вопрос, такой и ответ😂

это накладывало специфику на общение или только на проектирование системы под определенный регион?

на общение - конечно у нас коллеги из офиса в США поэтому на повседневном общении конечно отражается

а какие культуры были то?)

коллеги - США клиенты - США, Индия, Австралия, Россия, Дания

о я ж говорил индусы :)

у нас они американизированные (живут в США), поэтому приравняю их к США :)

у нас они американизированные (живут в США), поэтому приравняю их к США :)

США тоже не гомогенна в плане культуры, мягко говоря :)

США тоже не гомогенна в плане культуры, мягко говоря :)

в Европе с этим тоже все отлично — два нативных итальянца, живут в 50 км друг от друга, общаются на английском. Потому что разные диалекты и не понимают друг друга на итальянском)

вот карта для понимания

Да, у меня знакомый на севере Италии работал, то же самое рассказывал :)

Работаю в IT свере уже 6 лет в US. Поменял 4 компании. По моему опыту это выглядит так developer команда примерно 90% людей имиигрантов. Accounting/marketing/scrum master 90% американцы. Design 50/50. High level management/investors тоже американцы