Comments 13
Выдал базу в хорошем смысле. В ИТ вообще имхо только у программистов понятная роль, все остальные вспомогательные и взаимозаменяемые, идея - разгрузить интровертов гениев и по возможности снять с них общение с людьми. Если не-программист этого не понимает и вместо этого надувает щёки и "отстаивает границы", то с точки зрения компании он не приносит пользы
Это очень интересная статья, но возможно все эти вопросы можно решить грамотным делегированием. Да, понятно, что в матричной структуре это сложно (а тут, судя по описанию, именно матричная), но постараться можно.
Ну и что значит "на коленке написать ТЗ"? А как по нему риски смотреть? Как бюджет считать? Ну положим посчитали так, пришли с этим к лидам, они посмотрели и время в два раза увеличили, а вы уже цену озвучили. Приходить с этим к заказчику теперь и снова озвучивать цену - то такое.
Я не против идеи "быстро набросать", но нужно тогда предупредить заказчика что это драфт, а анализ займет условный месяц (по классике это время оплачивают обе стороны).
И да, неплохо если РП может в ту область, которой он сейчас занимается. Но, по факту, решая не свои задачи он сделает только хуже проекту, но не лучше. Думаю надо донести это до бизнеса и он сам отстанет. В теории )
Как вывод того, что я хотел сказать, в анализ можно и уметь, но для проекта это сделает только хуже. По факту у нас есть проблема, которую мы не решаем, а пытаемся "маскировать". Возможно стоит поработать именно с проблемой и тогда вопрос с анализом просто пропадет сам.
Я люблю отсчитывать от крайностей (конечно смотрим матрицу, РП почти всегда работает в матрице):
крайность 1 - это когда РП чистый администратор, который не лезет в технику, делегируя ее команде. Если команда недостаточно компетентна - это не проблема РП, а проблема тех, кто набрал такую команду (ресурсного менеджера). В этом случае знание предметки вообще не надо и на ИТ проект легко можно взять РП из стройки (и наоборот)
крайность 2 - это когда РП решает технические вопросы вместо команды, закапываясь и пропуская управление рисками, скажем.
И то и то - для меня перебор. РП со стройки не приживется в ИТ команде, даже если у него будут сертификаты PMP, PMI и прочее (а есть такие).
Тезис статьи как раз в том, что мой опыт 20+лет показывает, что умение РП в аналитику делает проект более устойчивым (РП заранее видит риски, больше доверия и понимания в команде) , а опыт собесов на РП (которых я прошел больше сотни или нескольких, я сбился) показывает , что и другие компании ищут тех, кто понимает, что делается на проекте.
20 лет, сотни собеседований - это конечно хорошо ) Но мой поинт был в другом. Если такая ситуация создалась, то проблема не в том есть ли что-то у РП или нет, а в том что такая ситуация вообще произошла. Не лучше ли найти причину и устранить ее?
Плюс, как бы мы не крутили, но "ТЗ на коленке" не даст точно посчитать бюджет. Чтобы просчитать риски которые может увидеть в первую очередь техлид, это даже не аналитиком нужно быть, а просто реально погруженным в тему ) И это возможно только если заниматься одноплановыми проектами, где все кейсы уже известны, в противном случае ни одна аналитика не поможет...
хы) отвечу
"Не лучше ли найти и устранить проблему?" - вы тезис свой скажите? Вы за формализацию процесса так, чтобы РП занимался администрированием, так?
Тут два ответа: первое - по моему опыту, если так происходит, проект управляется менее эффективно, чем если РП погружен в предметку. Эффективность в терминах маржи и сроков есессно. Готов обосновать и то, и то.
второе - Адзизес мой любимый говорит, что функция администрирования важна безусловно, но всегда должна балансироваться, чтобы не выродиться в бюрократию (что является тенденцией для стагнирующих компаний). Более того, в развивающейся быстро компании, функцией администрирования пренебречь ради захвата рынков - совершенно правильно и нормально
Отсюда итог - если компания хочет расти (ИТ компания) ей нужны РП, шарящие в предметке. Иначе просто будет неэффективно - значит медленно. А медленно рынки не захватываются.
Если же мы говорим о стабильном проектном офисе внутри компании, где каждый год приезжает бюджет 1-2 млрд или типа того, скорее, я с вами соглашусь: особого развития там нет - есть функция. И она должна быть нормирована.
о, и про оценку забыл важное. Лично у меня нет проблем с оценкой ТЗ, сделанного на коленке. И на миллионных проектах (в долларах), я попадаю с точностью до 1% с учетом рисков (не понт, это тупой факт и я считаю это подтверждением правильности моего подхода) без всех этим теоретических методов оценки по трем точкам, по функциональным точкам и какие там еще есть методы.
В моем случае решает несколько моментов
Умение понимать техническую сложность проекта (функции, интерфейсы, документация, отчетность и тп)
Понимание команды и заказчика
Кроме того, я научил также оценивать свою команду менеджеров, которые сейчас успешно работают. Так что да, возможно. Опытный менеджер должен уметь давать оценку в условиях тумана. Иначе для меня он нифига не Senior
Жиза... ) Вроде бы есть должностные инструкции, где все прописано, но выход за них уже не исключение, а скорее норма.
З.Ы. Кейс внешнего РП "ТЗ за три дня" как то опасно звучит) на мой взгляд возможно только с очень лояльным заказчиком
Да, это красная зона, тут надо работать аккуратно: понимать, куда заложить риски, какие самые рискованные моменты должны быть описаны, а где можно пренебречь, понимая там примерный максимальный объем.
Искусство оценки хаоса по критическим точкам. Это не поддается никакой методике оценки, чисто опыт.
Скажем так, я умею давать такие оценки и умею этому научить.
Мне значит с этой точки зрения "не везло" - РП, хоть в маленькой компании, хоть в большой, это именно администратор. Причём я не хочу сказать что это плохо - там огромное количество работы, необходимо следить за всеми сроками-ресурсами-согласованиями-... Но с точки зрения что ТЗ (т.е. понимания общей картины продукта, и даже больше - вообще архитектурных решений), что технических особенностей реализации, это не к РП. Для них проект это набор задачек в джире, у которых есть параметры приоритета, сложности, сроков, взаимосвязанности. Но собственной экспертизы за пределами этих цифр они не имеют. Вплоть до того что им на пальцах приходится рассказывать принцип работы создаваемого продукта. И я не вижу в этом ничего плохого - каждый должен заниматься своим делом.
Добавлю, что если РП настолько крут что реализует функции аналитиков, то ему понадобятся "младшие РП", которые занимаются администрированием :). И которых он будет находить на других должностях штатки, как бы они не назывались - от секретарей до техподдержки. В обязанности сотрудника на должности Руководитель Проекта в разных компаниях вкладывают очень разные вещи, и если РП занимается аналитикой - значит он выполняет роль аналитика на штатной должности РП :). Само собой, чем мельче компания тем больше ролей "висит" на одном человеке. Я когда техдиректором был, занимался примерно всем понемножку, закрывая срочные и/или сложные задачи, но это же не означает что это правильно.
в небольшой - еще как правильно. потому что а) нет денег на всех б) не факт что они будут вам нужны завтра (даже если сегодня оч нужны)
ну и про администраторов - зависит от проектов. В коммерции администрирования меньше - там просто контракт, ТЗ и все (ну или заказы на работы по рамочному договору).
в госухе бумажек больше, факт. Но это можно на аутсорс спихнуть. В целом, конечно надо следить за балансом. Выглядит так, что чем меньше компания и проекты, тем больше функций на одном человеке (любом, включая РП). Далее компания растет и в пике становится огромной, где РП - чистый администратор, под которым бегают техменеджеры, которые шарят
в небольшой - еще как правильно.
Но при этом мне как раз было удобно работать именно с РП-"администраторами", потому что следить за всей текучкой-сроками-задачами-встречами было уже перебор, когда как вы и пишете силы тратились на "временную замену" толпы специалистов, а с другой стороны там сильно и не развернуться "мощным РП". Поэтому не уверен что им место только в крупняке. А задачи - разработчик довольно навороченного ПАК, собственного колл-центра и прочих телекомовских услуг.
Надо ли Руководителю проектов быть аналитиком?