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

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

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

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

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

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

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

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

• Со временем предложения и требования начинают сыпаться одно за другим: “Нужны обсуждения!”, “Форумы!”, “Блоги!”, “Сделайте чат!”, “Срочно нужны новости!”

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

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

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

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

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

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

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

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

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

• Проект – служит для объединения задач.

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

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

• Аналитика – любая дополнительная информация, которую вы хотите учитывать по ходу работы над задачей. Это фирменное изобретение ПланФикса. Простые примеры аналитик: доходы, расходы, затраченное время и т.п.

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

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

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

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

• Обсуждение – это задача без даты планируемого завершения, к которой в качестве участников задачи подключены нужные для обсуждения вопроса люди.

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

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

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