Планирование в агентстве / веб-студии

В этой статье разберем такую стандартную боль студий и аутсорс-продакшенов, как планирование. У очень многих эта боль есть, но все о ней почему-то молчат.

Рассмотрим два наиболее часто используемых инструмента планирования, почему мы от них отказались и к чему пришли.

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

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

Но в итоге по мере роста все приходят к какому-то более гибкому с точки зрения возможностей инструменту планирования и переходят к этапу 2.

Наиболее частый случай на начальном этапе развития - это когда для планирования используется Трелло (канбан доски).

Плюсы для нас на тот момент:

- Все онлайн;

- Бесплатно;

- Относительно безболезненное и быстрое внедрение для команды.

Мы на определенном этапе развития также использовали канбан в виде трелло. В начале использования все удобно и наглядно.

Но на определенном этапе у нас вылезла существенная проблема:

на разработчике есть задачи, есть поток; видим, в каких колонках работа застревает, но есть главный минус - это сроки, которых мы не видим.

При систематическом потоке старых задач - определенные задачи могут съезжать по срокам на фоне нового потока тасков. Добавляются новые разработчики, потом сверху падают PM’ы т.д. Горизонт планирования нельзя расширить за пределы 1-2 дней.

Ниже картинка из трелло. Почти все зарисовано, но общий смысл понятен.

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

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

Из начальных плюсов на тот момент:

- Дешево и работает "из коробки";

- Имелась интеграция, в том числе с Битрикс24 (в нем мы работаем).

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

По какому принципу это все работало: под каждого разработчика заводился свой календарь. Вернее директор (т.е. я) в своей гугловской учетке создавал дополнительный календарь, к которому давал доступ:

- Разработчику;

- Менеджерам;

- Тимлиду этого разработчика либо команде (если это тимлид).

Скрин ниже из архива наших регламентов:

- Слева: менеджеры, директор и тимлиды видели примерно такую картинку.

- Cправа: их персональная загрузка по дням (скрин ниже из архива наших регламентов)

Для планирования времени разработчика мы указывали номер задачи (брался из нашего Битрикс24), количество планируемых часов в день и опционально название проекта.

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

Менеджер это делает и в этом случае в календаре разработчик получает 8+ часов.

На определенном этапе система стала достаточно громоздкой и неудобной:

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

- При добавлении задач менеджерами, директору, который являлся изначальным создателем календарей, в 9 утра прилетали уведомления о списке задач на сегодня (что лично меня жутко бесило - я ведь уже не вел проекты, PM’ы полностью заменили меня).

В итоге с ростом количества людей, Гугл Календарь стал окончательно неудобен. Появились идеи и хотелки по интеграции, автоматизации, более глубокому планированию и прогнозированию. А также возможности по их реализации в полной мере.

Поэтому в нашем случае начался новый этап. На этом этапе все выбирают коробочные решения которые допиливают под себя или делают как мы.

Следующее решение было выбрано по принципу: хочешь, чтобы было как нужно тебе - пили свое решение ( :

В результате на базе Dhtmlx написали свой планировщик по аналогии с календарем Гугла по функционалу, а также взяв, по нашему мнению, лучшие фишки из календаря Битрикс24.

Фишки, которых нам не хватало в обеих системах и которые в итоге реализовали у себя:

- Быстрое переключение отображений день-месяц-год.

- Удобная навигация.

- Возможность отключить отображение тех или иных сотрудников.

- Возможность видеть чужие календари загрузки.

- Просмотр задачи сразу на странице просмотра календаря.

Небольшая визуальная, но очень важная фишка:

Менеджер видит, когда освобождается конкретный разработчик и ставит в ближайшее окно новую задачу в план. Это позволяет иметь горизонт планирования дедлайнов не 1-2 недели, а на несколько месяцев вперед.

На скриншоте ниже пример как визуально выглядит распланированный месяц:

Да, есть некоторые риски, что сотрудник не уложится в оценку и/или прилетят asap правки по другим проектам/задачам. Для этого, как я выше и писал, у нас есть специальные «окна» для таких задач. Потому график если когда и съезжает, то не сильно.

Вариант что сотрудник заболеет - это форс-мажорный, спланировать такое нереально. Потому в планировании это обычно не учитываем.

Отпуска, кстати, тоже отмечаются в календаре. Да, вот так вот банально :)

Сейчас бывает поглядываю на диаграмму Ганта, которую используют для планирования некоторые студии, однако вид Таймлайн в нашем календаре позволяет фактически так и видеть график:

Таким образом, от планирования в 1-2 дня канбана и гугл календаря, мы ушли в работу со своим решением . Это позволило нам максимально гибко строить долгосрочные планы, достаточно точно говорить клиентам, когда мы начнем делать и когда планируем сдать их проект. И, как правило, даже на достаточно больших проектах (для нас сейчас это 2-4 месяца) погрешность составляет максимум пару дней.

Мне будет очень интересно услышать, как вы у себя в компании наладили планирование, что используете и чем это лучше/хуже на ваш взгляд.