ІДЕОЛОГІЯ

Вперше замітку з такою назвою ми розмістили у блозі Planfix у березні 2011 року. З того часу мало що змінилося, і тут вона публікується практично в тому ж вигляді — хіба прикладів стало більше і реалізація ідеології в інтерфейсі системи стала більш очевидною. Ми недаремно часто посилаємось на цей текст — він дуже важливий для розуміння нашого підходу до побудови системи. Якщо ви плануєте використовувати Planfix у роботі своєї компанії і хочете зрозуміти його принципову відмінність від систем, з якими ви стикалися раніше, рекомендуємо почати саме з цієї замітки.
Наймоднішим словом зараз є «простота». "Проста система", "простий інтерфейс", "прості функції" - ось девізи творців більшості онлайн CRM, BPM або PM-сервісів. Спочатку ми теж пішли цим шляхом, і на головній сторінці нашого сайту слово «простота» було принаймні двічі. Але якщо глибше подивитися, то навіть таку просту річ, як простота, люди розуміють по-різному.
Як зазвичай розвиваються системи, подібні до Planfix?
Створюється проста структура даних, наприклад «проєкт-завдання-коментар або «лід-контакт-угода», робиться простий дизайн з великою кількістю приємної порожнечі, після чого автори починають користуватися системою самі та пропонувати це робити іншим.
Все починається дуже красиво
І їм починають надходити пропозиції від користувачів: «А давайте, крім завдань, зробимо «справи», тому що мені незручно вести колективну роботу із завданнями у вашій системі, а особисті справи окремо. Зробіть список справ, і я користуватимуся тільки вашою системою, і ще наведу всіх своїх друзів.»
Проходить якийсь час
Що ж, логічно, справи потрібні — і в системі з'являється новий розділ.
Новий запит від іншого користувача: Вам не вистачає «подій»! Треба зробити їх у вигляді календаря, щоб можна було поставити там події, наприклад, зустріч із клієнтом або нараду».
Потім ще...
З часом пропозиції та вимоги починають сипатися одне за одним: «Потрібні обговорення!», «Форуми!», « Блоги!», «Зробіть чат!», «Терміново потрібні новини!».

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

Далі запити починають сипатися з подвоєною силою: "Гей, дайте можливість додавати файли не тільки до завдань, але і до справ!" дуже треба!», "Чому немає можливості призначити подію для угоди на календарі?!?!".
Потім ще...
ОК, штука потрібна, додаємо ще одну сутність та ще один розділ.
У цій ситуації у авторів сервісу не так багато варіантів поведінки:
або городити мегасистему типу ZOHO, у якій різні функціональні блоки пов'язані між собою дуже слабко (а часто практично ніяк).
або залишатися, подібно до Basecamp, на позиціях святої простоти, не додаючи нового функціоналу,
В результаті, всі системи, які нам довелося спостерігати, розподілилися на цій шкалі "Basecamp - ZOHO" таким собі градієнтом, з явним тяжінням у бік ZOHO. Саме по собі це не добре і не погано, а просто відображає стандартний шлях еволюції систем: від «одноклітинних» простих систем з дуже обмеженим набором функцій, до загальмованих «динозаврів», мозок яких надто пізно розуміє, що їхній хвіст вже жує інший динозавр.

Творцям системи дуже складно прийняти вольове рішення і залишити її на «одноклітинній» стадії, коли навколо всі прагнуть рости. Тому більшість систем зазвичай отримує довільний набір функціоналу для організації спільної роботи (блоги, обговорення, чат, пошта), управління продажами (контакти, ліди, угоди, воронка продажів), постановки завдань (проєкти, віхи, завдання, коментарі, події) та особистого планування (справи, зустрічі, туду-листи і т.п.) При цьому, якщо подивитися уважніше, дуже багато перерахованих сутностей мають між собою набагато більше спільних рис, ніж відмінностей.

Судіть самі: завдання, поставлене самому собі, чим не діло? Завдання, поставлене на певний час протягом дня, - це цілком собі подія або зустріч. А коментар залишається коментарем, незалежно від того, залишений він у блозі, обговоренні, чаті або відправлений поштою. То навіщо ж множити ці сутності, збільшуючи кількість різномастих даних і неминуче стикаючись у майбутньому із проблемою їхньої інтеграції?

Ми давно побачили цю суперечність і з того часу враховуємо її при плануванні функціоналу Planfix. Коротко нашу ідеологію можна описати так:
Ми даємо змогу побудувати систему управління, що охоплює всю компанію, використовуючи обмежений набір сутностей.
"
На даний момент таких сутностей у Planfix чотири:
Служить для обʼєднання завдань.
Основна смислова одиниця Planfix. Все крутиться навколо завдань, завдання можуть мати будь-яке число підзавдань необмеженої вкладеності, до них можна додавати потрібні реквізити (поля) і відключати непотрібні.
«Інформаційний атом», який відображає будь-які зміни у завданнях: додавання нового файлу або коментаря, зміни дати виконання або виконавця, додавання нагадування чи аналітики тощо.
Будь-яка додаткова інформація, яку ви хочете враховувати під час роботи над завданням. Це фірмовий винахід Planfix. Прості приклади аналітик: доходи, витрати, витрачений час тощо.
Проєкт
Завдання
Дія
Аналітика

У Planfix ви не знайдете «справ», «подій» та інших похідних від завдання, які незначно відрізняються між собою. Таким чином ми повністю вирішуємо описані вище проблеми типу «щоб у справах були повідомлення як у подіях, а до подій щоб можна було підвантажувати файли». У нас все це можна робити за замовчанням, тому що весь цей функціонал передбачено завданням.

Якщо користувач просить нас ввести в Planfix нову сутність, ми пропонуємо йому описати відмінності цієї сутності від задачі. У процесі розмови стає ясно, що відмінності в основному в назві та комплекті параметрів задачі, що використовуються, — і користувач може самостійно змінити це у своєму акаунті, налаштувавши завдання у вигляді, зручному саме йому та його колегам: хоч «справи», хоч «події», хоч «заявки у виробництво».

Назва «завдання», до речі, не зовсім вдала — вона вводить в оману користувача, обмежує його сприйняття звичним розумінням цієї сутності. Якби ми починали працювати над Planfix сьогодні, швидше за все ми назвали б цю сутність якось більш універсально - наприклад, форма або об'єкт. Можливо, у майбутньому нам доведеться це зробити.

Ми розуміємо, що до ідеології Planfix треба звикнути - в інших системах подібний підхід не зустрічається, тому спочатку думка про те, що завдання замінює всі звичні за іншими системами сутності, сприймається непросто.
Це завдання без дати планованого завершення, до якого учасниками підключені потрібні для обговорення питання люди.
Обговорення
Давайте пройдемо для тренування ще кілька прикладів:
Це таке ж завдання без дати планованого завершення. В якості учасників до нього можна підключити групу «Всі співробітники компанії», звичайно, якщо з новиною потрібно ознайомити всіх. Якщо це локальна новина для відділу продажів, просто підключаєте до завдання потрібну групу, і її бачать лише учасники цієї групи.
Новина
Це те саме завдання, хіба що можна додати до нього пару додаткових реквізитів, наприклад «Сума угоди». А так робота з ним нічим не відрізняється від роботи з іншими завданнями — тримаємо контакт із клієнтом, підключаємо потрібних колег, проводимо угоду за статусами воронки продажів (які ми самі собі налаштовуємо як нам зручно), аж до переможного завершення.
Угода

Звичайно, проста внутрішня структура не обов'язково забезпечує простоту використання продукту в кінцевому результаті. Зокрема, ми маємо ще багато зробити в області можливостей налаштування інтерфейсу системи. Впевнені, що згодом ми доведемо його до кришталевої чистоти, зробимо його більш гнучким, виправимо всі дрібниці і приберемо зайві кліки — і допоможе нам у цьому саме ясна і проста внутрішня структура Planfix, що не роздмухується з часом.

Створіть аккаунт для своєї компанії зараз та

користуйтесь усіма можливостями впродовж 14 днів безкоштовно