Любопытно. Я такого не встречал. Я делал оценки проектов в 15 млн долларов, было дело, на 100 человек на пару лет (плюс-минус). Да, мы прикидывали риски из понимания заказчика, его процессов и слабых мест, оценка заняла тогда 4 недели.
И для меня заказчик, который может прийти и сказать про увеличение в 4 раза после такого выглядит, как факап первичного анализа на стадии оценки. Или заказчик и правда неадекват. Первое я встречал (ошибки оценки), второе - реже, честно. Может, везло.
Разумеется, если заказчик неадекват, то моя статья нерелевантна: если на вас полезли с кулаками, дипломатия не поможет.
Но вообще любопытно, какой у вас подход был.
Классический подход по созданию ФГИС, насколько я его понимаю это:
Разработка нормативки и концепция + ОТЗ: 1-2 года (нормативка разрабатывается годами, это я для простоты)
Затем НИОКР на создание ТЗ для разных частей системы: 1 год
Затем пара этапов на создание: 1-2 года
все вместе занимает 3-4 года. Дробление как раз призвано снизить объем неизвестности на каждый год. То, что говорите вы, отличается: одно ТЗ на несколько лет - рискованная история, конечно.
Хмм. А вы про IT, да? Десятки тысяч чд (только реальных, а не по оценке, оценивать на такие значения я и сам умею) - это реально немало, особенно если за год.
Тут у меня другой вопрос был бы: а кто работал с заказчиком и почему вот так резко, без причины, вырос объем? По моему опыту это просто так не бывает. Бывает: сходили к министру и чето брякнули. Или от них министр потребовал - чего-то такое.
Тут скажу, что у меня до судов не доходило, было рядом, мы договаривались (речь шла не за десятки тысяч чд, просто за тысячи, но весьма реальные)
Посыл в том, что "нет" говорить не надо вообще. Надо обрисовать проблему, показать, какие есть варианты решения и предложить заказчику выбрать самому любой вариант.
Пример из жизни: у заказчика есть 1 млн рублей и невнятное ТЗ на сайт + интеграцию с AD (к примеру, от балды). И надо сделать за 1 месяц. Заказчик говорит - админ есть, он все поможет. И чтобы дизайн был "ух"!
Для меня это как раз отличный пример всего и сразу. Что я делаю. Готовлю варианты
Для классного проработанного дизайна нужна хотябы карта сайта и согласованные блоки - но их нет. Понимая, что вам надо быстро, можем предложить базовые дизайны стандартного движка сайта (в Б24 их дофига, к примеру). Так будет и красиво и быстро и недорого
Опять таки, карты сайта нет, потому я сам предлагаю ограничиться разделами 1,2,3,4 и все - это можно сделать быстро и в красивом дизе
интеграцию в АД сделать вообще не проблема, правда ваш админ сказал, что она не работает, но если он починит - мы сделаем (надо через 2 недели)
Если вас такой подход устраивает - мы готовы сделать.
Смотрите, я не сказал "нет", но я сам очертил границы и задал скоуп, согласовав его. Это работает почти всегда. Исключение - когда заказчик уперся и хочет все таки все все и сразу. Там наступает момент когда можно сказать "коллеги, мы в указанный срок можем сделать Фазу1, а позже - Фазу 2"
Отлично вас понимаю. РП не любят сейлов - те чтото напродавали , а мне - выполняй. Я такое выижу очень часто, да и сам был таким.
Пока не прочитал одну из лучших книжек для РП (я считаю) "черная книга менеджера". Старая уже, но она мне мозги вправила. Сейлз - продает. Если вы не продадите, нам через полгода станет делать нечего и кушать тоже нечего. По крайней мере тут. Так что выгоднее помогать сейлзу, а не ныть. Так и получается командная игра.
За последние 5 лет почти все превратили. Да, иногда ругались с прямым заказчиком (ему надо было быстро), эскалировали на руководство, готовили презентации.
Делать хорошо непросто, но можно.
Я тут увольнялся, мне лид одного направления (душнила) припомнил один модуль, который так и не отрефакторили, хотя я обещал. Было. Но я честно 4 или 5 заходов делал. У бизнеса там строгое понимание, что они не хотят делать нормально, с понятным обоснованием. Ну так бывает.
А вообще, я скажу, что Госуслуги запустились в 2007 году, если мне не изменяет память. И поддержка тогда работала у них через ЖЖ. Оплата штрафов шла у меня 3 месяца )))) это сейчас, спустя >10 лет там идеально вылизанный сервис. Но все постепенно :)
А вот тут поможет замечательный проектный запас. Размер запаса обратно пропорционален проработанности ТЗ заказчика :)
и на вопрос заказчика: "а почему так дорого" я обычно по каждому требованию могу пройти и рассказть, какие там вопросы есть. Далее смотрю в глаза честно и спрашиваю: "коллеги, мы можем за пару недель с вами проработать все вопросы и уточнить оценку или заложить риски, на ваш выбор".
Собственно вариант по моей статье выше - не говорю нет некачественному ТЗ, я люблю некачественное ТЗ :) просто вот тут и вот тут заложим интеграцию , тут неясно что у вас с процессами, а тут вы не можете определить параметры доступности, потому считаем 99.6.
Хорошая тема, кстати, запишу в блокнотик и тоже напишу отдельно.
Если коротко, то отличие только одно, но принципиальное.
Это не ТЗ. ТЗ будет у вас плохое и там и там, если вы его сами не напишете (я в пресейле 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 млн долларов, было дело, на 100 человек на пару лет (плюс-минус). Да, мы прикидывали риски из понимания заказчика, его процессов и слабых мест, оценка заняла тогда 4 недели.
И для меня заказчик, который может прийти и сказать про увеличение в 4 раза после такого выглядит, как факап первичного анализа на стадии оценки. Или заказчик и правда неадекват. Первое я встречал (ошибки оценки), второе - реже, честно. Может, везло.
Разумеется, если заказчик неадекват, то моя статья нерелевантна: если на вас полезли с кулаками, дипломатия не поможет.
Но вообще любопытно, какой у вас подход был.
Классический подход по созданию ФГИС, насколько я его понимаю это:
Разработка нормативки и концепция + ОТЗ: 1-2 года (нормативка разрабатывается годами, это я для простоты)
Затем НИОКР на создание ТЗ для разных частей системы: 1 год
Затем пара этапов на создание: 1-2 года
все вместе занимает 3-4 года. Дробление как раз призвано снизить объем неизвестности на каждый год. То, что говорите вы, отличается: одно ТЗ на несколько лет - рискованная история, конечно.
Хмм. А вы про IT, да? Десятки тысяч чд (только реальных, а не по оценке, оценивать на такие значения я и сам умею) - это реально немало, особенно если за год.
Тут у меня другой вопрос был бы: а кто работал с заказчиком и почему вот так резко, без причины, вырос объем? По моему опыту это просто так не бывает. Бывает: сходили к министру и чето брякнули. Или от них министр потребовал - чего-то такое.
Тут скажу, что у меня до судов не доходило, было рядом, мы договаривались (речь шла не за десятки тысяч чд, просто за тысячи, но весьма реальные)
Посыл в том, что "нет" говорить не надо вообще. Надо обрисовать проблему, показать, какие есть варианты решения и предложить заказчику выбрать самому любой вариант.
Пример из жизни: у заказчика есть 1 млн рублей и невнятное ТЗ на сайт + интеграцию с AD (к примеру, от балды). И надо сделать за 1 месяц. Заказчик говорит - админ есть, он все поможет. И чтобы дизайн был "ух"!
Для меня это как раз отличный пример всего и сразу. Что я делаю. Готовлю варианты
Для классного проработанного дизайна нужна хотябы карта сайта и согласованные блоки - но их нет. Понимая, что вам надо быстро, можем предложить базовые дизайны стандартного движка сайта (в Б24 их дофига, к примеру). Так будет и красиво и быстро и недорого
Опять таки, карты сайта нет, потому я сам предлагаю ограничиться разделами 1,2,3,4 и все - это можно сделать быстро и в красивом дизе
интеграцию в АД сделать вообще не проблема, правда ваш админ сказал, что она не работает, но если он починит - мы сделаем (надо через 2 недели)
Если вас такой подход устраивает - мы готовы сделать.
Смотрите, я не сказал "нет", но я сам очертил границы и задал скоуп, согласовав его. Это работает почти всегда. Исключение - когда заказчик уперся и хочет все таки все все и сразу. Там наступает момент когда можно сказать "коллеги, мы в указанный срок можем сделать Фазу1, а позже - Фазу 2"
(опять нет не сказал, смотрите)
Отлично вас понимаю. РП не любят сейлов - те чтото напродавали , а мне - выполняй. Я такое выижу очень часто, да и сам был таким.
Пока не прочитал одну из лучших книжек для РП (я считаю) "черная книга менеджера". Старая уже, но она мне мозги вправила. Сейлз - продает. Если вы не продадите, нам через полгода станет делать нечего и кушать тоже нечего. По крайней мере тут. Так что выгоднее помогать сейлзу, а не ныть. Так и получается командная игра.
Да, все так и есть. Senior PM должен быть PO в моем понимании. Во внутреннем ИТ до продактов были вообще то Сервис менеджеры (по ИТИЛ) - это их роль.
А во внешнем - дальше можно расти в биздев смело.
про противоречия 223 и 44 реальности хочется сказать очень много, но нельзя :) работаем с тем, что есть :))))
За последние 5 лет почти все превратили. Да, иногда ругались с прямым заказчиком (ему надо было быстро), эскалировали на руководство, готовили презентации.
Делать хорошо непросто, но можно.
Я тут увольнялся, мне лид одного направления (душнила) припомнил один модуль, который так и не отрефакторили, хотя я обещал. Было. Но я честно 4 или 5 заходов делал. У бизнеса там строгое понимание, что они не хотят делать нормально, с понятным обоснованием. Ну так бывает.
А вообще, я скажу, что Госуслуги запустились в 2007 году, если мне не изменяет память. И поддержка тогда работала у них через ЖЖ. Оплата штрафов шла у меня 3 месяца )))) это сейчас, спустя >10 лет там идеально вылизанный сервис. Но все постепенно :)
А вот тут поможет замечательный проектный запас. Размер запаса обратно пропорционален проработанности ТЗ заказчика :)
и на вопрос заказчика: "а почему так дорого" я обычно по каждому требованию могу пройти и рассказть, какие там вопросы есть. Далее смотрю в глаза честно и спрашиваю: "коллеги, мы можем за пару недель с вами проработать все вопросы и уточнить оценку или заложить риски, на ваш выбор".
Собственно вариант по моей статье выше - не говорю нет некачественному ТЗ, я люблю некачественное ТЗ :) просто вот тут и вот тут заложим интеграцию , тут неясно что у вас с процессами, а тут вы не можете определить параметры доступности, потому считаем 99.6.
Оценка и допущения.
На выходе я получаю железобетонную позицию.
Хорошая тема, кстати, запишу в блокнотик и тоже напишу отдельно.
Если коротко, то отличие только одно, но принципиальное.
Это не ТЗ. ТЗ будет у вас плохое и там и там, если вы его сами не напишете (я в пресейле 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 месяца, исходя из общения с заказчиком.
С учетом этого интересно, где РП облажался еще?