Ещё горячо мной любимый Alistair Cockbern в начале 2000х подметил, что наибольшую эффективность даёт команда, физически запертая в одной комнате. Этот факт был неоднократно подтверждён и использован мной во время проблемных проектов, когда за короткий срок нужно было мобилизоваться и сделать большой объём работы или решить серьёзную проблему. 

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

А если собрать команду в одном месте нельзя или это очень дорого? А если речь идёт не о неделе/двух, а о проекте длиной в полгода-год? А если твоя команда мало того, что распределена географически, так ещё и работает в двух таймзонах, а заказчик — в третьей? Сегодняшняя заметка про управление географически-распределённой командой в разных таймзонах.

Крупные организации часто сталкиваются с проблемой функциональных колодцев (на западе -  silos) - это когда каждое подразделение или продуктовая команда работает изолированно, фокусируясь только на своих целях, бюджетах и приоритетах. На первый взгляд, это кажется эффективным: каждый знает свои задачи и отвечает за свой результат... до тех пор, пока не потребуется реализовать кросс-функциональный / кросс-продуктовый проект. Рассмотрим это с позиции вендора, которые делает такой проект у крупного заказчика.

Ты что-то ждёшь от коллег из другого подразделение / продукта. Попросил раз. Попросил два. Написал в чат — тишина. Напомнил ещё раз — снова молчание. Знакомо? Что делать дальше? Самый очевидный путь - эскалация. Но точно ли он лучший?

Дисклэймер: заметка написана со стороны вендора, который работает с большим корпоративным заказчиком. В организациях поменьше есть свои нюансы.

Ресурсное планирование отдельно взятого проекта — большая тема, и мы её поделим на несколько частей. В первой части мы рассмотрим задачи, которые надо решить, информацию, которую надо собрать и решения, которые надо принять при подготовке к ресурсному планированию. А во второй части поговорим о том, как делать ресурсный план.

В предыдущей статье мы уже анализировали, от чего зависит ресурсный план. Давайте немного подробнее рассмотрим самые принципиальные моменты и дополним их полезными напоминаниями.

Ценность ресурсного планирования для IT-компании сложно подвергнуть сомнению. Ресурсные планы есть у многих. А действительно работающей системой ресурсного планирования похвалиться могут совсем немногие. Почему же? Давайте разберёмся.

Что такое действительно работающая система ресурсного планирования?

Давайте рассмотрим одну из самых распространённых моделей работы компании среднего размера по разработке программного обеспечения и не только. Не продуктовую. Обычно, в таковой мы имеем:

В 2001 году, когда ещё не было Хабра и существенной доли его современных читателей, когда вотерфолл был всемогущим, а об эджайле ещё только-только начинали говорить, я немного поисследовал тему методологий разработки и их отличий друг от друга. В результате появилась статья, которая была опубликована на дружественных мне веб-сайтах. На статью даже ссылались некоторые уважаемые учебные заведения при подготовке курсов по основам менеджмента программных проектов. Поскольку дружественные веб-сайты были не про IT, то и статья со временем с них исчезла. Дабы не допустить её полного исчезновения с просторов рунета, позволю себе опубликовать её на Хабре и предлагаю всем желающим совершить небольшой экскурс в прошлое. Да, многие вещи сейчас кажутся наивными, но ряд выводов всё ещё более чем актуален.

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

Что самое ценное для IT-компании? Что является главным активом и ресурсом почти для каждой IT-компании? На что компания тратит больше всего денег? Какая статья затрат является самой большой? На обслуживание какого ресурса у вас уходит больше всего денег? Не сильно ошибусь, если скажу, что ответом на все эти вопросы является “Команда компании”. Именно ваша команда делает проекты, двигает вашу компанию вперед и зарабатывает деньги, и именно на зарплаты, бонусы, налоги, оборудование рабочих мест и прочие прямые и косвенные выплаты вашей команде приходится основная масса затрат компании.

Если в нужный момент у вас будет недостаточное количество вашего ключевого ресурса, то вы не сможете сделать важный проект и упустите выгоду. А если у вас будет избыток ресурсов, то вы будете нести убытки, оплачивая простаивающую часть вашей команды. Поговорим о ресурсном планировании.