Pull to refresh

Comments 6

Мне кажется, Вы недоговариваете, или недооцениваете риски, которые несёт в себе привлечение ресурсов со стороны. Время на обучение вполне предсказуемо. А вот качество изменений привнесённых «не родными» участниками гораздо сложнее прогнозировать. И дело не просто в возможно меньших компетенциях, которые бы отразились только на времени-стоимости их участия. А в том что вероятность получить результат низкого качества гораздо выше, а исправление этого результата будет существенно выше и сложнее, чем в случае с использованием только постоянной команды.

Я как-то был свидетелем подобного жонглирования ресурсами в крупной трансконтинентальной компании. Менеджмент в преддверии дедлайна не сумел его отодвинуть и решил привлёч всех кого можно: в итоге на короткий срок были привлечены разработчики со всех доступных проектов, в количестве превосходящим собственную команду. При этом компетенции у них были порой и выше чем в команде. В результате добежать в дедлайн на костылях почти успели, но качество кодовой базы серьёзно пострадало. Количество возвращающихся багов и время на фиксы и вытаскивание костылей (чем занималась естественно уже своя команда) существенно превзошло по стоимости «впрыснутые» ресурсы.

Конечно приведённая ситуация субъективная, и в теории можно предусмотреть разные методологии снижающие эти риски. К тому же, жираф большой, ему видней: если тот дедлайн отвечает за жизнь проекта в принципе, то в этом и может быть смысл с точки зрения продакт-менеджера. Но для объективности картины, и принятия решений не забывайте: старый конь борозды не портит, а старый друг лучше новых двух.
Ну, недоговаривать мне смысла нет, а насчет подсвеченных рисков — конечно, они есть. Но я весь комплекс этот рисков упаковал в формулировку «негарантированное качество ресурсов», которое, как правило, нужно компенсировать более изощренным управлением, что и отражено в «дорогое управление» и «накладные расходы на администрирование».
Еще одно очень важное отличие людских ресурсов от денег — это востребованность. Деньги востребованы всегда :) Если у вас образовались лишние деньги, вы тут же можете ими воспользоваться — что-то купить, инвестировать, одолжить и т.д. А вот освободившиеся с проекта ресурсы по своей технической специализации, уровню компетенции или стоимости могут оказаться невостребованными в других проектах и зависнут в ресурсном пуле, возможно на долгое время, заметно увеличивая ваши накладные расходы.
Все верно говорите. Это если ограничиваться жизнью внутри компании. А за ее пределами? Я понимаю, что не все компании, особенно большие и очень большие, готовы продавать свои ресурсы на открытом рынке или даже партнерам. В этом случае, обычно, спасают внутренние проекты компании, на которые просто так никто ресурсы не выделит, а вот если ресурс простаивает — пожалуйста. В таком случае это уже сложно назвать неоправданными затратами на содержание простаивающих/недозагруженных ресурсов, это уже инвестиции в свой продукт/проект.
Внутренние/собственные проекты лучше продажи ресурсов. У продажи голов есть только один плюс — регулярный денежный поток. Все остальное — сплошные минусы.
Самое интересное в ресурсном планировании — это оценка потребности в ресурсах различной специализации и уровня в условиях, когда старты и завершения проектов носят весьма вероятностный характер. Проекты в разработке софта постоянно опаздывают, соотвественно и высвобождение ресурсов задерживается на неопределенный срок. Цикл продаж также очень длинный и реальный старт проекта может откладываться по нескольку раз.
С нетерпением жду продолжения статьи :)
Sign up to leave a comment.

Articles