Хорошая тема, кстати, запишу в блокнотик и тоже напишу отдельно.
Если коротко, то отличие только одно, но принципиальное.
Это не ТЗ. ТЗ будет у вас плохое и там и там, если вы его сами не напишете (я в пресейле 15 лет и когда до сих пор я вижу конкурсное ТЗ хорошего качества, мне хочется прыгать и хлопать в ладошки, потому что это бывает 1 раз на 50 где-то).
Это не заказчики. Закачик что во внутреннем ИТ, что на аутсорсе для нас - бизнес. А там ребята не шарят во всем этом ИТ, им надо сделать быстро, качественно и недорого))
Репутация... ну я тоже не заметил. За факап внешнего подрядчика могут грохнуть и лишить потенциальной выручки, а внутреннего сотрудника - уволить. Для меня, как РП и то и то - равно
А вот важное для меня, это отношение бизнеса:
РП заказной разработки - это бизнес единица в своей компании. Он приносит бабки, он их зарабатывает. Поэтому его слушают в его компании.
РП внутреннего ИТ - тратит деньги. Он как муха, летает, грузит вопросами, ноет что-то - отстань, не до тебя вообще.
вот это меня долго задевало, у меня больше внешнего опыта и я привык зарабатывать, а не тратить. Тут можно поспорить, граница зыбкая (экономя деньги бизнеса, ИТ помогает зарабатывать), да. Мой опыт такой.
Да, очень хорошо вас понимаю. У вас отличный пример, когда менеджер идет полностью на поводу у клиента, подставляя команду под нереальные сроки.
А, впрочем, может и нет: у вас же просто спросили оценку, обоснование, а после - просто еще раз уточнили, осознали и приняли :)
Я еще напишу про "чайка-менеджеров" поподробнее, это большая тема. И о том, что можно сделать чтобы защитить команду. И про то, что менеджер, в моем понимании, должен быть помощником команде и прикрывать ее от безумия бизнеса (безумие условно, но разработчику лучше не знать, что там заказчик рвет и мечет. Менеджер для этого есть, а инженер должен тихонько сидеть и пилить согласно плана и своей оценке).
Ваш первый вариант, когда платит заказчик, а страдают нервы исполнителей, очень часто на моих глазах приводил к выгоранию всеми командами. В худшем случае - команда разбредалась. А поиск команды в текущих условиях - удовольствие крайне дорогое.
Поэтому не всегда ради заказчика стоит рисковать нервами команды. С одним заказчиком мы отлично использовали все методы: и переносы сроков и фазирование и добросить ресурсы, параллельно договариваясь с командой, кто может поработать в выходные, и обещая, что какашка, которую мы сдаем как MVP, превратится во чтото полезное в следующей итерации.
И на моей практике, такие разговоры и занимают бОльшую часть времени РП. А вовсе не перетаскивание колбасок по Гантту. А на курсах я про это нигде не встречал. Поэтому и пишу.
MVP + допилить - да, стандарт. А я считаю, что это только один из трех вариантов. Когда приходит 10 задач, а ресурсов есть на 5 (а так часто бывает и в проектных офисах и во внутреннем ИТ), просто запилить MVP по всем можно и не успеть - все равно ресурсов то только на 5.
вот тут и начинается игра "кто умрет" и поиск ресурсов. Выстрелить может любой, по опыту.
Что до коммуникаций - все просто. Заказчик считает, что MVP - это одно, команда считает - другое. РП надо поговорить и с теми, и с теми (о да, заказчиков бывает много и у каждого свое представление о счастье). С разрабов желательно получить несколько вариантов, чтобы была переговорная вилка для заказчика. Далее идем по заказчикам, получаем замечания, затем к команде, к линейному (сроки, приоритеты), затем к заказчику...
Я готов ответственно сказать на личном опыте и опыте моих менеджеров: если РП сокращает коммуникации, отделываясь формальным общением, это приводит к недоверию на проекте между всеми сторонами (заказчик-РП-команда). Это может быть некритично, если проект разовый, РП сделал в срок и все ок. Это может быть критично, если это не просто РП, но он отвечает за развитие продукта заказчика.
Прочитал вашу дискуссию ниже, интересно. согласен с @Batalmv
у меня есть несколько правил решения
Я пишу.
не отвечает - звоню
если радом, мне не сложно зайти. Если человек занят - когда можно подойти. Если никогда - переходим к п4
Иду к руководителю и прошу помочь, иначе произойдет тото и тото (список рисков)
Если руководитель забивает (так бывает), я еще раз, вежливо, делаю п3 (вдруг у человека время появилось), затем повторяю эскалацию Руководителю.
Если руководитель опять забивает (так тоже бывает), я пишу письмо Руководителю, что есть проблема, коллега не может ответить. Прошу обеспечить ответ или найти другого специалиста, иначе будет плохо (задержка, перерасход или что там еще).
далее, с частотой 2 раза в неделю я иду по этому кругу уже письменно. Письменно - это если кто-то из тех, кто забил, решит меня обвинить, что я ничего не делал.
Я еще это называю правилом 4 звонков и 1 смс и 1 письма: если есть срочный вопрос, а человек не отвечает, я звоню 4 раза, пишу смс , что срочно. Если не отвечает - пишу письмо. Желательно в сс все заинтересованные лица.
После этого практически всегда очень быстро реагируют коллеги. А если не реагируют, то к РП потом никаких вопросов нет - вся переписка есть.
Это и есть способ поставить себя.
в вашем случае про межгород (елки-палки, неужели где то это остается еще) вижу тоже самое:
есть ограниченная коммуникация. она создает риски (я не могу все время звонить).
я думаю над вариантами решения (их всегда много)
попросить выделить мне отдельный номер
договориться об использовании мессенджера
договориться о компенсации за сотик (честно говоря, копейки для конторы)
выделить специалиста рядом
чтото еще
предлагаю руководителю
если он не решает - см алгоритм выше
если несмотря на все это, меня делают виноватым... ну тогда и правда - чего делать то тут, РП сейчас всем нужны - можно просто сменить место.
Планированию на проекте мне проще будет научить, чем той самой can do attitude, о которой я писал в статье. У меня нулевые менеджеры учатся делать сметы за 3 месяца (это включая навык защиты у заказчика), а расставлять колбаски в гантте и того быстрее. Чего там: получил оценку у лидов, накинул риски, туда-сюда, согласовал - и в план. Все.
А вот can do attitude они учатся годами. Там психологии уже много.
Чтобы спланировать спринт много ума не надо. Чтобы понять, что делать, когда тебя долбят со всех сторон РПшнику нужно, кроме умения приоритизировать, еще и справиться с внутренними страхами (что заругают, что уволят и тп). Тут РПО местами должен быть не просто руководителем, а психологом, еслих хочется, чтобы команда росла.
Не могу сказать что работа РП простая: ты всегда между нескольких огней. Но ее вполне можно выстроить так, чтобы жизнь не казалась грустной. Тут для меня классическая история про психологию отношений. Смена работы, как и смена партнера - в первую очередь должна происходить не как результат бегства, а как результат изменения себя, многократных предложений по изменению процессов в компании и, только потом, можно сменить компанию.
И тогда, скорее всего, на новом месте получится запустить многое из того, что не получалось на старом. Потом будут новые проблемы, но это будет новый виток.
По моему опыту меньше всего получается сделать, если я просто сижу и грущу, что ничего сделать нельзя и ничего и не делаю.
слушайте, конечно не надо перегибов на местах, когда от РП требуют вообще всего, а взамен не просто кукиш, а обвинение во всех грехах и лишение премий.
Из такой компании, по моему, надо просто уходить (я, кстати, отдельно напишу, истории, как подставляют РП). Обычно, все не настолько запущено, как вы написали. Ну , у меня , по крайней мере :)))
почитал, спасибо за ссылку. Для меня там рассказ про то, что успешный проект - тот, который ориентируется не только на классические бюджет-сроки (ресурсы - это тоже про бюджет), но и на метрики "приживаемости". История хорошая, конечно, но есть пара нюансов:
метрики надо еще выделить. кто готовил ФЭО под новые проекты знает, что иногда, при очевидной необходимости проекта, ФЭО делается тяжело.
далеко не всегда можно оценить бюджет правильно для достижения именно тех метрик, которые хочется увидеть. Вот тут как раз и тема моей статьи:
есть формально успешный проект - метрики выполнены, дом взорвали, все свободны.
есть формально неуспешный проект - метрики не выполнены, но есть mvp и выделяется допбюджет на допиливание. После чего появляется продукт. И пусть к качественным продуктам для меня - всегда в этом пункте.
мысль поддерживаю: внедрять и оценивать внедрение надо по четким метрикам. По правильному, эти метрики должны биться с OKR компании. То бишь, с ее стратегией.
На практике я вижу, что определение метрик очень затруднено и решение в 50% случаев принимается волевым решением руководства "потому что так надо", на основании внутренней убежденности, что работа должна быть сделана.
Кроме того, в инновационной деятельности, по определению, не очень ясны метрики. Или, скорее, метрики ясны, а вот посчитать ресурсы и бюджет для достижения сразу невозможно.
Хороший пример - Госуслуги. Сейчас - это отличный сервис, отлаженные процессы, отличное приложение. Но можно вспомнить Госуслуги после первого внедрения. Я помню, я тогда попытался оплатить штраф через них, это был конец нулевых, если не ошибаюсь. Это были слезы. Но MVP сделали. А потом многократно допиливали.
Так что я бы добавил фазирование. Классическая тема стартапа: сперва делаем mvp, затем дорабатываем - рулит и в заказной разработке и во внедрении новых продуктов, потому что предусмотреть все подводные камни сразу невозможно.
Вот именно эту тему я и буду раскрывать в бложике, по мере сил. Понимаю, что вопрос глубоко философский и опираться я могу только на личный опыт, но зато его много, да и обсудить будет что :)
я собеседовал , наверное, менеджеров 30 за последнее время. И опыт был не 1-2 года, а прямо 4 даже (заявленных). Очень мало кто отвечает про то что "успешный проект" - это такой сферический конь в вакууме и показатели если не только бюджет/скоуп/деньги. Потому и захотелось высказаться на тему
В данной выше ситуации РП облажался ровно один раз, когда вначале принял проект (вместо полностью уволенной команды) и попытался сходу сдать этап, не оценив масштаба бедствия и не предупредив о невыполнимости показателей. Но он тогда был еще молодой и зеленый, так что простительно.
В дальнейшем, решение о продолжении работ принималось и его руководителем, CTO и CEO компании. Там был хороший уровень эскалаций. Более того, решение продолжать или нет, принимались каждые 1-2 месяца, исходя из общения с заказчиком.
В статье есть две крайности, просто чтобы дать понять, как оно в жизни бывает. Оно бывает по-разному. Уверен, если бы мы тогда замерили то, что я научился замерять сейчас (удовлетворенность клиента и удовлетворенность команды), результаты были бы крайне интересные и подтверждающие мои тезисы.
А вот то, что вы написали про успешность в конце камента, и есть посыл моей статьи. Менеджеры проектов часто боятся показать неуспешными, я сам таким был. Линкед ин пестрит успешным успехом. Но так бывает не всегда. И не надо за этим гнаться. Надо честно делать свою работу. А уже рубиться или нет - каждый сам пусть выбирает.
Вы знаете. Суть моей статьи как раз в том, что есть две крайности
Я работаю строго по должностной и отстаньте от меня со своими дополнительными задачами.
Я спасаю мир, я делаю вообще все: и то, что мне поручили, и то, что не поручали я делаю тоже
Первый подход превращает команду в формалистов. Я видел людей, которые так работают. Как Руководители проектов - они не эффективны, у них плохие отношения с заказчиками (без исключения, в моем опыте).
Второй подход очень нравится руководству, но ведет к выгоранию или к увольнению - это когда герой не справляется.
По моему опыту очень большого числа внедрений, нужно искать баланс. Где надо - уметь подстраховать и подумать чуть больше, чем это предусмотрено должностной инструкцией или ТЗ. Но уметь и сказать "нет" заказчику или руководителю.
Как найти этот баланс, опять таки, по моему опыту, не знает ни один РП, который приходит в профессию. Все набивают свои шишки.
Хорошая тема, кстати, запишу в блокнотик и тоже напишу отдельно.
Если коротко, то отличие только одно, но принципиальное.
Это не ТЗ. ТЗ будет у вас плохое и там и там, если вы его сами не напишете (я в пресейле 15 лет и когда до сих пор я вижу конкурсное ТЗ хорошего качества, мне хочется прыгать и хлопать в ладошки, потому что это бывает 1 раз на 50 где-то).
Это не заказчики. Закачик что во внутреннем ИТ, что на аутсорсе для нас - бизнес. А там ребята не шарят во всем этом ИТ, им надо сделать быстро, качественно и недорого))
Репутация... ну я тоже не заметил. За факап внешнего подрядчика могут грохнуть и лишить потенциальной выручки, а внутреннего сотрудника - уволить. Для меня, как РП и то и то - равно
А вот важное для меня, это отношение бизнеса:
РП заказной разработки - это бизнес единица в своей компании. Он приносит бабки, он их зарабатывает. Поэтому его слушают в его компании.
РП внутреннего ИТ - тратит деньги. Он как муха, летает, грузит вопросами, ноет что-то - отстань, не до тебя вообще.
вот это меня долго задевало, у меня больше внешнего опыта и я привык зарабатывать, а не тратить. Тут можно поспорить, граница зыбкая (экономя деньги бизнеса, ИТ помогает зарабатывать), да. Мой опыт такой.
Если у кого то есть другой - рад послушать :)
Да, очень хорошо вас понимаю. У вас отличный пример, когда менеджер идет полностью на поводу у клиента, подставляя команду под нереальные сроки.
А, впрочем, может и нет: у вас же просто спросили оценку, обоснование, а после - просто еще раз уточнили, осознали и приняли :)
Я еще напишу про "чайка-менеджеров" поподробнее, это большая тема. И о том, что можно сделать чтобы защитить команду. И про то, что менеджер, в моем понимании, должен быть помощником команде и прикрывать ее от безумия бизнеса (безумие условно, но разработчику лучше не знать, что там заказчик рвет и мечет. Менеджер для этого есть, а инженер должен тихонько сидеть и пилить согласно плана и своей оценке).
Ваш первый вариант, когда платит заказчик, а страдают нервы исполнителей, очень часто на моих глазах приводил к выгоранию всеми командами. В худшем случае - команда разбредалась. А поиск команды в текущих условиях - удовольствие крайне дорогое.
Поэтому не всегда ради заказчика стоит рисковать нервами команды. С одним заказчиком мы отлично использовали все методы: и переносы сроков и фазирование и добросить ресурсы, параллельно договариваясь с командой, кто может поработать в выходные, и обещая, что какашка, которую мы сдаем как MVP, превратится во чтото полезное в следующей итерации.
И на моей практике, такие разговоры и занимают бОльшую часть времени РП. А вовсе не перетаскивание колбасок по Гантту. А на курсах я про это нигде не встречал. Поэтому и пишу.
MVP + допилить - да, стандарт. А я считаю, что это только один из трех вариантов. Когда приходит 10 задач, а ресурсов есть на 5 (а так часто бывает и в проектных офисах и во внутреннем ИТ), просто запилить MVP по всем можно и не успеть - все равно ресурсов то только на 5.
вот тут и начинается игра "кто умрет" и поиск ресурсов. Выстрелить может любой, по опыту.
Что до коммуникаций - все просто. Заказчик считает, что MVP - это одно, команда считает - другое. РП надо поговорить и с теми, и с теми (о да, заказчиков бывает много и у каждого свое представление о счастье). С разрабов желательно получить несколько вариантов, чтобы была переговорная вилка для заказчика. Далее идем по заказчикам, получаем замечания, затем к команде, к линейному (сроки, приоритеты), затем к заказчику...
Я готов ответственно сказать на личном опыте и опыте моих менеджеров: если РП сокращает коммуникации, отделываясь формальным общением, это приводит к недоверию на проекте между всеми сторонами (заказчик-РП-команда). Это может быть некритично, если проект разовый, РП сделал в срок и все ок. Это может быть критично, если это не просто РП, но он отвечает за развитие продукта заказчика.
Прочитал вашу дискуссию ниже, интересно. согласен с @Batalmv
у меня есть несколько правил решения
Я пишу.
не отвечает - звоню
если радом, мне не сложно зайти. Если человек занят - когда можно подойти. Если никогда - переходим к п4
Иду к руководителю и прошу помочь, иначе произойдет тото и тото (список рисков)
Если руководитель забивает (так бывает), я еще раз, вежливо, делаю п3 (вдруг у человека время появилось), затем повторяю эскалацию Руководителю.
Если руководитель опять забивает (так тоже бывает), я пишу письмо Руководителю, что есть проблема, коллега не может ответить. Прошу обеспечить ответ или найти другого специалиста, иначе будет плохо (задержка, перерасход или что там еще).
далее, с частотой 2 раза в неделю я иду по этому кругу уже письменно. Письменно - это если кто-то из тех, кто забил, решит меня обвинить, что я ничего не делал.
Я еще это называю правилом 4 звонков и 1 смс и 1 письма: если есть срочный вопрос, а человек не отвечает, я звоню 4 раза, пишу смс , что срочно. Если не отвечает - пишу письмо. Желательно в сс все заинтересованные лица.
После этого практически всегда очень быстро реагируют коллеги. А если не реагируют, то к РП потом никаких вопросов нет - вся переписка есть.
Это и есть способ поставить себя.
в вашем случае про межгород (елки-палки, неужели где то это остается еще) вижу тоже самое:
есть ограниченная коммуникация. она создает риски (я не могу все время звонить).
я думаю над вариантами решения (их всегда много)
попросить выделить мне отдельный номер
договориться об использовании мессенджера
договориться о компенсации за сотик (честно говоря, копейки для конторы)
выделить специалиста рядом
чтото еще
предлагаю руководителю
если он не решает - см алгоритм выше
если несмотря на все это, меня делают виноватым... ну тогда и правда - чего делать то тут, РП сейчас всем нужны - можно просто сменить место.
А я, кстати, отвечу.
Планированию на проекте мне проще будет научить, чем той самой can do attitude, о которой я писал в статье. У меня нулевые менеджеры учатся делать сметы за 3 месяца (это включая навык защиты у заказчика), а расставлять колбаски в гантте и того быстрее. Чего там: получил оценку у лидов, накинул риски, туда-сюда, согласовал - и в план. Все.
А вот can do attitude они учатся годами. Там психологии уже много.
Чтобы спланировать спринт много ума не надо. Чтобы понять, что делать, когда тебя долбят со всех сторон РПшнику нужно, кроме умения приоритизировать, еще и справиться с внутренними страхами (что заругают, что уволят и тп). Тут РПО местами должен быть не просто руководителем, а психологом, еслих хочется, чтобы команда росла.
У каждого свой опыт, у меня он другой.
Не могу сказать что работа РП простая: ты всегда между нескольких огней. Но ее вполне можно выстроить так, чтобы жизнь не казалась грустной. Тут для меня классическая история про психологию отношений. Смена работы, как и смена партнера - в первую очередь должна происходить не как результат бегства, а как результат изменения себя, многократных предложений по изменению процессов в компании и, только потом, можно сменить компанию.
И тогда, скорее всего, на новом месте получится запустить многое из того, что не получалось на старом. Потом будут новые проблемы, но это будет новый виток.
По моему опыту меньше всего получается сделать, если я просто сижу и грущу, что ничего сделать нельзя и ничего и не делаю.
Спасибо! :)
слушайте, конечно не надо перегибов на местах, когда от РП требуют вообще всего, а взамен не просто кукиш, а обвинение во всех грехах и лишение премий.
Из такой компании, по моему, надо просто уходить (я, кстати, отдельно напишу, истории, как подставляют РП). Обычно, все не настолько запущено, как вы написали. Ну , у меня , по крайней мере :)))
почитал, спасибо за ссылку. Для меня там рассказ про то, что успешный проект - тот, который ориентируется не только на классические бюджет-сроки (ресурсы - это тоже про бюджет), но и на метрики "приживаемости". История хорошая, конечно, но есть пара нюансов:
метрики надо еще выделить. кто готовил ФЭО под новые проекты знает, что иногда, при очевидной необходимости проекта, ФЭО делается тяжело.
далеко не всегда можно оценить бюджет правильно для достижения именно тех метрик, которые хочется увидеть. Вот тут как раз и тема моей статьи:
есть формально успешный проект - метрики выполнены, дом взорвали, все свободны.
есть формально неуспешный проект - метрики не выполнены, но есть mvp и выделяется допбюджет на допиливание. После чего появляется продукт. И пусть к качественным продуктам для меня - всегда в этом пункте.
мысль поддерживаю: внедрять и оценивать внедрение надо по четким метрикам. По правильному, эти метрики должны биться с OKR компании. То бишь, с ее стратегией.
На практике я вижу, что определение метрик очень затруднено и решение в 50% случаев принимается волевым решением руководства "потому что так надо", на основании внутренней убежденности, что работа должна быть сделана.
Кроме того, в инновационной деятельности, по определению, не очень ясны метрики. Или, скорее, метрики ясны, а вот посчитать ресурсы и бюджет для достижения сразу невозможно.
Хороший пример - Госуслуги. Сейчас - это отличный сервис, отлаженные процессы, отличное приложение. Но можно вспомнить Госуслуги после первого внедрения. Я помню, я тогда попытался оплатить штраф через них, это был конец нулевых, если не ошибаюсь. Это были слезы. Но MVP сделали. А потом многократно допиливали.
Так что я бы добавил фазирование. Классическая тема стартапа: сперва делаем mvp, затем дорабатываем - рулит и в заказной разработке и во внедрении новых продуктов, потому что предусмотреть все подводные камни сразу невозможно.
Вот именно эту тему я и буду раскрывать в бложике, по мере сил. Понимаю, что вопрос глубоко философский и опираться я могу только на личный опыт, но зато его много, да и обсудить будет что :)
я собеседовал , наверное, менеджеров 30 за последнее время. И опыт был не 1-2 года, а прямо 4 даже (заявленных). Очень мало кто отвечает про то что "успешный проект" - это такой сферический конь в вакууме и показатели если не только бюджет/скоуп/деньги. Потому и захотелось высказаться на тему
В данной выше ситуации РП облажался ровно один раз, когда вначале принял проект (вместо полностью уволенной команды) и попытался сходу сдать этап, не оценив масштаба бедствия и не предупредив о невыполнимости показателей. Но он тогда был еще молодой и зеленый, так что простительно.
В дальнейшем, решение о продолжении работ принималось и его руководителем, CTO и CEO компании. Там был хороший уровень эскалаций. Более того, решение продолжать или нет, принимались каждые 1-2 месяца, исходя из общения с заказчиком.
С учетом этого интересно, где РП облажался еще?
В статье есть две крайности, просто чтобы дать понять, как оно в жизни бывает. Оно бывает по-разному. Уверен, если бы мы тогда замерили то, что я научился замерять сейчас (удовлетворенность клиента и удовлетворенность команды), результаты были бы крайне интересные и подтверждающие мои тезисы.
А вот то, что вы написали про успешность в конце камента, и есть посыл моей статьи. Менеджеры проектов часто боятся показать неуспешными, я сам таким был. Линкед ин пестрит успешным успехом. Но так бывает не всегда. И не надо за этим гнаться. Надо честно делать свою работу. А уже рубиться или нет - каждый сам пусть выбирает.
Я иногда люблю и порубиться.
Вы знаете. Суть моей статьи как раз в том, что есть две крайности
Я работаю строго по должностной и отстаньте от меня со своими дополнительными задачами.
Я спасаю мир, я делаю вообще все: и то, что мне поручили, и то, что не поручали я делаю тоже
Первый подход превращает команду в формалистов. Я видел людей, которые так работают. Как Руководители проектов - они не эффективны, у них плохие отношения с заказчиками (без исключения, в моем опыте).
Второй подход очень нравится руководству, но ведет к выгоранию или к увольнению - это когда герой не справляется.
По моему опыту очень большого числа внедрений, нужно искать баланс. Где надо - уметь подстраховать и подумать чуть больше, чем это предусмотрено должностной инструкцией или ТЗ. Но уметь и сказать "нет" заказчику или руководителю.
Как найти этот баланс, опять таки, по моему опыту, не знает ни один РП, который приходит в профессию. Все набивают свои шишки.