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

Данные можно соотнести самыми разными инструментами, от обычных Excel/G.Docs с использованием макросов и скриптов и до MS Project. Выбор инструмента зависит от количества проектов и участников процесса, а также кошелька. И еще дополнительных пожеланий, как то, графики оплат по этапам, акты и поступления по ним. Но это в прочем уже другая история...

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

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

Мы ведем статистику по производительности каждого сотрудника в отдельности и производительность компании в целом, что дает понимание того, какой проект мы сможем переварить и сколько еще ресурсов нам необходимо будет привлечь. Планирование идет на 1-2 месяца вперед, столько времени проходит в среднем от заявки до старта работ.
С волнообразностью спроса может помочь перенос некоторых проектов именно на редкие месяцы, т.е. надо объяснить клиенту, что «именно в это время мы будем полностью ваши»

Главное — быть честным с клиентом.

Мы стараемся выстроить работу таким образом, чтобы один специалист работал над 3-4 проектами одновременно и не более, причем чтобы данные проекты заканчивались последовательно, таким образом высвобождается определенный интервал рабочего времени в день. Такой принцип позволяет нам разгрузить сотрудника от монотонности одного проекта. А как уже сам сотрудник выстраивает свой рабочий день — это его проблемы, но к часу Ч он у нас должен сдать определенный кусок кода, шаблон компонента, макет дизайна или чего-то еще. Т.е. я как руководитель знаю, что во вторник Иван у меня освободит пол рабочего дня и я могу ему поставить в задачи новый проект. Отлично в этом плане нам помогает SCRUM доска от Сибирикс в нашем Корпоративном портале. Но тут стоит учитывать тот нюанс, что никто не застрахован от волны, есть только шанс ее немного сгладить вовремя высвобождая ресурсы и не загружая студию на 100%, что только подталкивает провалу сроков или чрезмерной нагрузке на специалистов.

«Простые ответы» — зеркало рынка. В который раз мы сталкиваемся с не самой активной реакцией экспертов на вопрос, актуальный почти для всех. Мы благодарим экспертов, приславших свои комментарии. Из лучших практик, которые я видел в цифровых компаниях, озвученную проблему решают два подхода. Первый, к сожалению, доступный только крупным компаниям, состоит в переводе клиентов на годовые бюджеты и «time & material». Только в таком смысле я могу согласиться с экспертом о «длительных клиентских проектах». Потому что второй, менее действенный, но доступный средним и малым компаниям, заключается в переходе на итеративную разработку, когда горизонт загрузки по одному проекту ограничивается 1-3 месяцами одной итерации. Такие блоки работ проще перестраивать между собой и проще договариваться с клиентами об отсрочке старта следующей итерации на одну-две недели, чем разрывать длинные проекты.