Идеология ПланФикса – 2015

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

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

Самое модное слово сейчас – “простота”. “Простая система”, “простой интерфейс”, “простые функции” – вот девизы создателей большинства онлайн CRM, BPM или PM-сервисов. Изначально мы тоже пошли этим путем, и на главной странице нашего сайта слово “простота” присутствовало как минимум два раза. Но если посмотреть глубже, то даже такую простую вещь, как простота, люди понимают по-разному.
Как обычно развиваются системы, подобные ПланФиксу?

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

Что ж, логично, дела нужны – и в системе появляется новый раздел.

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

ОК, штука нужная, добавляем еще одну сущность и еще один раздел.

  • Со временем предложения и требования начинают сыпаться одно за другим: “Нужны обсуждения!”, “Форумы!”, “Блоги!”, “Сделайте чат!”, “Срочно нужны новости!”
  • Создатели либо отбиваются от этих предложений, либо продолжают наворачивать свою систему, добавляя в нее новый функционал и новые разделы. При этом каждый раз, создавая очередную сущность и втискивая ее в интерфейс, авторы добавляют очередную башенку к песочному замку под названием “интеграция”.
  • Дальше запросы начинают сыпаться с удвоенной силой: “Эй, дайте возможность добавлять файлы не только к задачам, но и к делам!”, “Хочу прикрепить сообщения из чата к задаче, чтоб потом не искать”, “Добавьте возможность переводить дела в задачи, очень надо!”, “Почему нет возможности назначить событие для сделки на календаре?!?!”.

В этой ситуации вариантов поведения для создателей сервиса особо нет:

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

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

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

Судите сами: задача, поставленная самому себе – чем не дело? Задача, поставленная на определенное время в течение дня – это вполне себе событие или встреча. А комментарий остается комментарием, вне зависимости от того, оставлен он в блоге, обсуждении, чате или отправлен по почте. Так зачем же множить эти сущности, увеличивая количество разномастных данных и неизбежно сталкиваясь в будущем с проблемой их интеграции?

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

На текущий момент таких сущностей в ПланФиксе четыре:

  • Проект – служит для объединения задач.
  • Задача – основная смысловая единица ПланФикса; все вертится вокруг задач, задачи могут иметь любое число подзадач неограниченной вложенности, к ним можно добавлять нужные вам реквизиты (поля) и отключать ненужные.
  • Действие – “информационный атом” ПланФикса, который отражает любые изменения в задачах: добавление нового файла или комментария, изменения даты выполнения или исполнителя, добавление напоминания или аналитики и т.п.
  • Аналитика – любая дополнительная информация, которую вы хотите учитывать по ходу работы над задачей. Это фирменное изобретение ПланФикса. Простые примеры аналитик: доходы, расходы, затраченное время и т.п.

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

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

Название “задача”, кстати, не совсем удачное – оно вводит пользователя в заблуждение, ограничивает его восприятие привычным пониманием этой сущности. Если бы мы начинали работать над ПланФиксом сегодня, скорее всего мы назвали бы эту сущность как-то более универсально – например, форма или объект. Может быть, в будущем нам еще придется это сделать.

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

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

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

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

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

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

  1. Аватар

    Хорошо. Легко читается. Внушает доверие. Написано отлично. Поймал себя на мысли, что не могу оторваться. И “воды” нет.
    И хочется читать дальше.
    Молодец Дмитрий!

  2. Аватар

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

  3. Аватар

    Говорят, что Сент-Экзюпери принадлежит отличный афоризм: “Идеальное – это когда нечего убрать”. Мой 30-летний опыт работы с различными интерфейсами это подтверждает на 100%. Поэтому, никогда не отказывайте себе в удовольствии что-нибудь урезать 🙂

    Успехов!

  4. Аватар

    А почему только два варианта: либо простота, либо слишком навороченная система? Почему бы не включать/выключать нужные фичи?
    Например, так делают в crm pipedrive. Нужна тебе сущность “товар”? Включи. В итоге каждый получает что хочет.

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

      >> А почему только два варианта: либо простота, либо слишком навороченная система?
      – это два крайних варианта, обычно все системы как раз помещаются между ними: что-то в них очень просто, а что-то – наворочено. Я писал в заметке выше про “градиент” – это как раз по этому поводу.

      >> Почему бы не включать/выключать нужные фичи?
      – Такая возможность в ПланФиксе есть, и эту ветку мы развиваем. У нас это называется конфигурации – можно установить конфигурацию и в системе появится новая сущность, а также заранее настроенные инструменты по работе с ней. Пример такой конфигурации – Управление сделками. После ее установки в системе появляется “Сделка”, а также специальный тип задач “Активность по сделке” и набор планировщиков и отчетов для работы с этими сущностями. Но все это – сущности второго порядка, если можно так сказать. В основе этих сущностей лежат базовые сущности ПланФикса – та же задача, в частности.

      Такой подход, на наш взгляд, имеет принципиальное преимущество в том, что он гораздо в меньшей степени ограничивает возможности пользователя фантазией разработчиков. Если вам нужен товар – сделайте товар (или установите настройку, в которой он уже есть, если таковая существует). А если нужен Каталог недвижимости – то сделайте его, даже если мы, создатели ПланФикса, о таком думать не думали и галочку для него не предусмотрели.

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

  5. Аватар

    Дмитрий добрый день,

    Зачем отдельная сущность Проект?
    Отличий между Задачей и Проектом не много, их можно унифицировать и свести к национальным настройкам.

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

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

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

  6. Аватар

    Никогда не понимал почему в описании подобных сервисов никто никогда не пишет “Что будет с моими данными в случае если вы закроетесь”? Ну правда. Сколько смотрю всякие подборки CRM годичной давности, так половина из них как правило даже доме уже не работает.
    При выборе подобных сервисов, я впервую очередь задумываюсь над этим. Ведь ты настраиваешь все под себе, хранишь серьезные данные, статистику, историю, где-то даже финансы и контакты, настраиваешь под себя структуру, какие-то мелочи, а потом что? Максимум выгрузку в exel?
    Расскажите, пожалуйста, что предусмотрено у вас на такой случай? Я бы хотел как минимум, возможность выкупа системы для установки на свой сервер.

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

      У нас чуть лучше, чем выгрузка в Excel – вы можете экспортировать все (или нужные) данные, включая все загруженные в систему файлы, при помощи специального механизма. Данные экспортируются в формате json, что дает хотя бы теоретическую возможность загрузки их в другую выбранную Вами систему (хотя для этого и понадобится написание специальной обработки).

      Штатной возможности выкупа системы и установки ее на своем сервере мы не планируем – но и закрываться не планируем тоже, причем уже лет 7-8 как, с момента начала работы над ПланФиксом. Если вдруг придется когда-то закрываться (хотя сложно представить в результате чего такое может случиться), то будем думать, как не подвести пользователей. Мы вообще этим сильно заморачиваемся – хотя, наверное, это и не редкость. Вот, например, когда мы решили вводить в ПланФиксе платные подписки, то поступили не так, как это обычно бывает. В этом году меняли систему тарификации – всех платящих клиентов это обошло стороной, платят по старым тарифам. В общем, хорошо зная ситуацию изнутри, на месте наших настоящих и будущих клиентов я бы не волновался.

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