От первого лица: Выбор и использование системы управления проектами

Владислав Иващенко, Технический директор агентства поискового маркетинга ivaschenko * nizamov

Здравствуйте, коллеги!

Меня зовут Владислав. Пост мы писали с Октавианом. В данный момент мы работаем вместе над построением агентства поискового маркетинга ivaschenko * nizamov, поэтому тема таск-менеджмена актуальна для нас как никогда, и свои шишки мы успели набить.

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

Лично моё знакомство с ПланФиксом началось, если не ошибаюсь, ещё в 2011 году.

Дальше – много букв про то, как мы не отказались от ПланФикса за 4 года.

Тогда ещё я работал на фрилансе и искал систему управления задачами, которая бы мне подошла. Перепробовал много всего, но в итоге остановился на ПланФиксе: функционала на то время хватало, дизайн устраивал, а, главное, ПланФикс был бесплатным.

Прошло время и в 2013 году мы с партнёром открывали наше агентство. Естественно, что практики управления проектами плавно перетекли и в нашу совместную компанию. И вот с этого момента мы начали действительно активно пользоваться системой, а ПланФикс прошёл настоящую проверку на прочность: стал использоваться не как записная книжка фрилансера, а как полноценная система управления проектами и задачами.

Несмотря на то, что ПланФикс мы использовали, что называется, по-умолчанию, время от времени мы открывали для себя аналоги и тестировали то, что появлялось в нашем поле зрения. (Надо понимать, что тогда перечисленные ниже решения обладали немного иным функционалом, чем, вероятно, сейчас. Поэтому некоторые моменты могут оказаться не на 100% актуальными.)

  • Во-первых, мы рассматривали только SaaS решения. Желание разбираться с установкой/настройкой Редмайна или MS Project совершенно не было. Хотя тыкали мы, конечно, и Редмайн, и решения от Майкрософта, но это уже немного другая история.
  • Во-вторых, мы тестировали продукты в разное время при наличии на то ресурсов, т.е. это не было системным сравнением. Все выводы сугубо субъективные

Что мы пробовали и по каким причинам оно нам не подошло:

Asana

Плюсы:

  1. Довольно быстрый старт благодаря простоте и более или менее интуитивному интерфейсу.
  2. Неплохое мобильное приложение под iOS. Ввиду простоты сервиса, мобильная версия почти не уступает десктопу в функционале и удобстве.
  3. Есть бесплатная версия, которой может хватить на небольшую организацию. Нам на первых порах вполне хватило бы.
  4. Продуманная система горячих клавиш на клавиатуре. Не считая того, что не всегда они типичны и привычны, почти все действия можно делать без участия мыши — что вполне себе доставляло.

Минусы:

  1. Полная свобода действий юзера. Исполнитель, например, может свободно двигать сроки по своим задачам, редактировать суть задач, удалять их. Без какого-либо участия постановщика.
  2. Самое ужасное – всё происходит почти бесследно. То есть, в большинстве случаев всем заинтересованным будет выслан мэйл (убивая ящик каждым таким движением), но, бывает, что почта не доходит, или ты ее пропустишь: в задаче история хранится очень неполная. Кстати, 26 января Asana анонсировали нечто вроде хроники в ПФ.
  3. Отсутствие сводных аналитических отчётов: сколько у кого просрочек, сколько времени принимается задача. Нам банально не удалось разобраться как узнать сколько вообще в системе активных задач. Полностью “обезоруживает” в некоторых случаях.

Нюансы:

  1. Очень хитрая сортировка проектов в ленте слева. Так и не разобрались с ней. Таких непонятных “переоптимизированных” решений в Асане целый ряд, хотя и ко всем им, полагаю, можно привыкнуть, если пользоваться постоянно.
  2. В момент тестирования не было приложения под Андроид. Сейчас уже вроде сделали.
  3. За время тестирования/использования создалось ощущение, что проект не развивается: очень редко появляются новые фичи.

Подводя итог:
Asana – продвинутая записная книжка онлайн, заточенная на ведение списка дел.

Мегаплан

Изначально мы рассматривали Мегаплан как CRM-систему. К сожалению, знакомство быстро не задалось ввиду глючности и “дубовости”: система полностью заточена под определённую модель продаж, а понять как это исправить быстро не вышло; тестирование было заброшено.

Сейчас уже понимаем, что “дубовость” сохраняется и в управлении проектами.

Ворксекшн

Ворксекшн уже ближе к универсальному решению по управлению проектами, но всё же есть вещи, которые смущают сразу:

  1. Визивиг-редактор из прошлого. Попробуйте добавить в комментарий к задаче таблицу: у вас это не выйдет. А картинка прилепится только файлом, т.е. не будет отображаться в рамках самого комментария.
  2. Нет логики в работе подзадач. Например, в задаче с дедлайном сегодня можно спокойно создать подзадачу с дедлайном завтра.
  3. Нет детализации потраченного по задаче времени. (Сейчас, к слову, детализация всё же появилась: время группируется на одного сотрудника за день.)

Из плюсов хотелось бы удостоить внимания действительно удобный “таймер”.

Подводя итог: Хорошая развивающаяся система, но пока явно слабее.

Чем ещё мы пользовались:

  • Битрикс-24
  • Basecamp
  • qTrack

В итоге, на дворе 2015-ый и мы до сих пор плотно сидим на ПланФиксе.

 

Плюсы, которые мы видим в ПланФиксе

  •  Невозможно сделать вид, что ты не в курсе сроков задачи. Ведь не забыть про задачу помогут:
    • Сводка
    • Хроника
    • Уведомления на e-mail (если они не отключены).
  • Действительно ничего нельзя сделать бесследно. Это касается не только сроков, но и описания задач, комментариев, чек-листов и т.д. и т.п. Даже администратор аккаунта не может “химичить” без следов. При должном подходе становится возможным получить состояние постоянного оперативного понимания сроков по всем задачам всех сотрудников компании.
  • Нам очень нравится система вложенностей и зависимостей задач. Достаточно один раз структурировать и зафиксировать бизнес-процесс (разложить на подзадачи, расставить ответственных), а затем его можно “запускать” одним кликом. Руководитель же вспоминает о запущенном процессе лишь когда задачи выполняются, либо когда кто-то из исполнитель запрашивает участие постановщика.

Микро-кейс 1: Типовой проект

При запуске нового проекта в работу менеджер проекта заводит его в ПланФиксе и ставит шаблонную задачу “Составить план проекта” техническому руководителю.

Поставленная задача выглядит как шпаргалка-инструкция:

Задача в ПланФиксе
Затем уже технический руководитель проекта создаёт по шаблону план ближайших работ (на старте он типичен для любого из проектов). И за 5-10 минут мы получаем список всех работ на месяц:

Список задач проекта в ПланФиксе
При этом все задачи связаны между собой. Если вдруг в какой-то момент затянется согласование с клиентом – то подвинутся и сроки работ у технического отдела. При этом, установлен и общий дедлайн (он с запасом в несколько дней на “подвижки”), о смещении которого будет обязательно уведомлен руководитель проекта. В этом помогает соответствующая галочка:

Подписка на уведомления по задаче ПланФикса

  • Разумный компромисс гибкости и сложности.
    ПланФикс действительно кастомизируется под множество разных задач, но при этом не требует участие программиста.
Микро-кейс 2: Получение лидов в ПланФикс с сайта
Обычно первый контакт с клиентом у нас возникает в момент заполнения им заявки на поисковый аудит на нашем сайте. В данной ситуации важно проявить реакцию как можно быстрее.Мы создали специальный проект в ПланФиксе, куда складываем все лиды.
После заполнения клиентом заявки на сайте скрипт отправляет письмо со всеми данными заявки на электронный ящик проекта:Email-адрес проекта в ПланФиксеДалее работает шаблон по-умолчанию для этого проекта:
а) Исполнитель: группа “Отдел продаж”.
б) Первый принявший – исполнитель, остальные отключаются.
в) Для задач указаны кастомные статусы: “Заведена в CRM”, “Дубликат” и “Спам”.В небольшом коллективе отдела продаж, особенно с условиями разнородной нагрузки, ребята сами оперативно решают кто какую заявку возьмёт.

Микро-кейс 3: Автонапоминание для всех задач
В системе присутствуют шаблоны задач. И есть стандартный шаблон, который используется при добавлении любой новой задачи, если для неё не задан иной шаблон. Поскольку задачи часто ставятся наперёд, мы добавили в стандартный шаблон напоминание за 10 минут до старта задачи. Таким образом, исполнитель всегда увидит задачу, которую он должен сегодня начать, у себя в хронике с напоминанием. 
  • Планировщик

Фундаментальный раздел, сильно помогающий во многих нюансах. Мы не используем его как календарь, но используем в качестве:

  • Кастомной сводки по своим и чужим задачам: какие сегодня должны быть завершены, какие начаты и т.д.
  • Scrum-доски для отдела разработки. И это работает не хуже аналогов, при этом с учётом всего остального обильного функционала ПланФикса.
  • Работа с почтой и, особенно, раздел “Хроника”.

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

Сейчас мы осознали насколько крут раздел “Хроника” для оперативной работы и почти у всех сотрудников уведомления на почту отключены.
События в Хронике ПланФикса

  • Кастомные отчёты и аналитики.

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

Микро-кейс 4: Учет времени работы по задачам и проектам

Кейс не нов, это стандартный функционал, о котором говорят сами разработчики: фиксирование времени работы над задачами. Каждый сотрудник техотдела обязательно фиксирует потраченное над решением конкретной задачи время. В итоге:
а) Можно понять какой сотрудник чем занимался в течение дня/недели/месяца:Работы за неделю в Планировщике ПланФиксаб) Каждую неделю на совещании технического отдела по проектам мы имеем сводку о потраченном на каждый проект за неделю времени:Отчет по временным затратам на проекты в ПланФиксев) Можно строить аналитики вида:
– проект
– выручка
– потраченное время
– потраченное время в денежном эквиваленте
– прямые расходы
– прибыль
– рентабельность
– и т.д.
  • Постоянное развитие, саппорт, идеология. Пункт лично от меня.

Во-первых, поддержка не в пример большинству российских компаний. Крайне удобно ставить задачу саппорту прямо у себя в аккаунте. У нас отдельный проект под это дело выделен.
Во-вторых, ПланФикс не стоит на месте. Никогда. За последние несколько лет развивается и развивается.
В-третьих, у разработчиков есть идеология, которой они следуют. И главный идеолог – разработчик, а не продажник или маркетолог. Это круто, на самом деле.

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

 

  • Стабильность.

На моей памяти ПланФикс ни разу не падал.

Были профилактические работы, апдейты и т.д., но это бывает редко (да и обычно в нерабочее время) и об этом заранее предупреждается.

 

  •  Права доступа

Права доступа к задачам просты и понятны. 4 основные роли, которые нужно понять: аудитор, постановщик, исполнитель и участник.
Хотите дать доступ к задаче клиенту? Подключить его e-mail в качестве участника.

Хотите дать доступ клиенту ко всему проекту? Установите его участником по-умолчанию.
Если к какой-то задаче вы всё же не хотите давать доступ – уберите из участников и клиент её не увидит. А можете скрыть какой-то конкретный комментарий, например.

Продуманно, просто, удобно.

 

  •  Конструктор отчётов.

Вот эту штуку, на наш взгляд, нужно выносить в УТП.
Можно анализировать и строить отчёты буквально по всем данным из вашего аккаунта. Используете статусы, кастомные поля, аналитики? Не проблема.

Из самого простого: за 5 секунд строится отчёт о принятых в работу лидах отдела продаж (см. микро-кейс 2) с разбивкой по менеджерам.

Самодельный отчет по лидам в ПланФиксе

Но и про минусы хотелось бы сказать

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

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

Костыли мы таки придумали:
Мы завели отдельного сотрудника: Аудитор просрочек.
Он подписан аудитором на все проекты. И в каждом включены уведомления обо всех событиях по задачам проекта.Также для этого сотрудника включены уведомления на почту, а на почте настроен фильтр, который находит уведомления о просрочках и пересылает их на нужный ящик.
Затем уже раз в месяц руководитель проходит по всем таким уведомлениям и руками проставляет аналитики штрафов.
  • Начальная стадия развития интерфейсов для мобильных устройств.
    С айпада более или менее удобно пользоваться полной версией ПланФикса, но есть нюансы: глючит клавиатура при добавлении действия, маленькие ссылки в интерфейсе и т.д.
    С телефоном лучше: всё-таки есть и активно развивается мобильная версия. Но пока её функционал достаточно скуден, хотя уже и охватывает большинство необходимых обычно с телефона действий: сводка, комментарии, сроки, напоминашки.
  • Довольно медленный интерфейс.Вероятно это оборотная сторона удобства. Но на 3G с iPad’а это, бывает, напрягает.
  • Не до конца продуманна система зависимостей.
    Сами по себе зависимости сильно упрощают жизнь, о чём упоминалось в плюсах системы.
    Однако:
    – Было бы отлично устанавливать зависимость при создании задачи. Сейчас приходится создать задачу, открыть её, нажать на вкладку связей и только потом связь можно установить.
    – Не видны обратные зависимости. Видно от каких задач зависит открытая задача, но не видно какие задачи зависят от неё. Иногда это приводит к неожиданным эффектам при редактирования сроков задачи, меняя за собой сроки целой кучи задач, про которые заранее узнать довольно непросто.
  • Плохая логика работы с рабочими/нерабочими днями. Сейчас в системе любой будний день – рабочий, любая суббота и воскресенье – нерабочий день. Будь до 1 января, 8 марта или 9 мая. И нет никакой возможности настроить в аккаунте индивидуальные выходные.

Плюс достаточно нечёткое разделение этих понятий, и, как следствие, частая путаница. Например, в длительности задачи имеются в виду рабочие дни, в зависимостях тоже, а при создании шаблона “раз в месяц” – календарные (хотя прямо об этом нигде не говорится).

Я уже где-то читал, что работа над логикой разделения рабочих/календарных дней уже запланирована. И мы очень ждём и ратуем за эту задачу.

 

Подводя итог

Имея значительный опыт работы с ПланФиксом, я могу крайне рекомендовать его всем командам с проектной деятельностью команды.

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

Мастер Йода рекомендует ПланФикс


 

Владислав Иващенко

Октавиан Низамов

 

 

 

 

 

 

 

 Агентство поискового маркетинга ivaschenko * nizamov

Санкт-Петербург


Дмитрий Гончаренко, Команда ПланФикса

Дмитрий Гончаренко Команда ПланФикса

В заключение – традиционно пару слов от меня.

Во-первых, большое спасибо ребятам за такой качественный и интересный рассказ с обилием примеров – команде ПланФикса он очень понравился, думаю что и вам будет полезен.

Во-вторых, хочу напомнить: если вы готовы рассказать о своем опыте выбора и использования ПланФикса – ставьте задачу на Службу поддержки с темой “Рассказ от первого лица”, я подхвачу ее с нашей стороны и свяжусь с вами для согласования деталей.

Нам интересны рассказы о том, какие системы вы использовали или пробовали использовать раньше, как нашли ПланФикс, какими его функциями пользуетесь и как это помогает вам в ежедневной работе. Жду ваших рассказов!

17 комментариев

  1. Аватар

    Владислав, спасибо Вам большое за подробный рассказ.
    Удивительно, многие вещи у нас реализованы точно также.
    Например, создание проекта или перенос дерева задач из проекта “Продажи” в отдельный проект 🙂
    Видимо, из-за того, что бизнес у нас похож.
    Надо бы тоже написать такой пост, у нас есть много интересных кейсов!

    1. Аватар

      Ирина, было бы интересно услышать ваши кейсы использования ПланФикса. Ваша компания очень продвинута в этом вопросе и мы думаем, что другим пользователям будет очень интересно.

      1. Аватар

        Давайте голосовать.
        Какой кейс описать?
        1. Про управление дебиторской задолженностью?
        2. Про двойные сроки: по договору и фактические (управление просрочками по проекту)
        3. Про работу с фрилансерами (в т.ч. оплата им)
        4. Ведомости по выплате ЗП
        5. Деревья задач по сопровождению заказов

        Эти наиболее интересные, остальные либо слишком сложные (долго описывать), либо специфичные для нас.

  2. Аватар

    Начали хорошо, а закончили, извините, как попало. Вот в Asana, например, описаны и плюсы, и минусы (хотя, опять же, с ними я не согласен). Asana мне и самому не нравится.
    Мегаплан вроде и неплохой, но о нем два слова сказали и сразу же перешли к Worksection, где никаких плюсов, одни только минусы. Хотя насчет Worksection за год работы в системе могу поспорить, оценили не справедливо. Плюсов там действительно намного больше, чем минусов.
    Битрикс-24 и Basecamp упомянули вообще не понятно зачем. Причем забыли сказать, что Basecamp подходит для более мелких проектов, в то время, как Битрикс-24 – совсем наоборот.
    Субъективизм в оценке систем зашкаливает.

    1. Аватар

      Мы описывали наш субъективный опыт работы в разных системах, потому логично, что субъективизм зашкаливает. Таки в этом и была задача.

      А какой у вас опыт работы с перечисленными системами? Если соберём много субъективных мнений, возможно, появится что-то более объективное.

  3. Аватар

    На самом деле в планфиксе для нас самым большим минусом сейчас является отсутствие нормального мобильного приложения. Браузерная мобильная версия – это лучше, чем ничего, но для нормальной и тем более оперативной работы плохо подходит. А в офисе мы как-то не сидим, поэтому очень-очень хочется адекватно в нем работать хотя бы на айпаде. Может быть не абсолютно весь функционал, но работа с внесением и разрешением задач.

    1. Дмитрий Гончаренко

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

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

  4. Аватар

    Отличная статья. По нескольким позициям могу не согласиться. Мы пробовали несколько систем, остановились на АСВ (это название компании asv.ru). Все устраивает, минусы даже не могу выделить. Если что-то не так, исправляют и адаптируют под наши задачи

  5. Аватар

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

    Но то, что Планфикс активно реагирует на просьбы – даёт системе возможность быстро вырваться в лидеры. Пока – хорошо бы проанализировать в сравнении с текущим лидером – Битрикс24. Лаконичность – не везде сестра таланта 😉

    Чисто ОС: особенно отпугнул пункт про бомбёжку мэйлами и необходимость заходить куда-то (в сводку, хронику), чтобы увидеть висящие на мне задачи. Ярлыки, которые не слетают – решение намного удобнее.

    Спасибо за обзор! Рекламный, но всё же 😉

    1. Аватар

      Разбирающимся в разработке управленцем, я хотел сказать. А сейчас как раз все системы создаются разработчиками, которые по ходу дела разбираются с управлением. Так систему изначально не спланировать корректно – ведь если нет понимания проблем управления, архитектура закладывается на уровне “как понимаю”, а потом, с ростом самой компании разработчика и получением обратной связи от клиентов, система начинает расти в нужном направлении, но архитектура и именно ИДЕОЛОГИЯ уже заложены на уровне программиста-разработчика.

      А у разработчика должна быть одна идеология – воплотить ИДЕОЛОГИЮ эксперта в коде так, чтобы был задел на развитие и интеграции. Не наоборот 😉

Добавить комментарий