Ми писали CRM
Цей тиждень присвятив проектуванню невеликої CRM системи, яка має вирішити локальні завдання клієнта з обробки близько 120 000 контактів силами відділу із 30 співробітників.
Щиро кажучи, спочатку я спробував знайти вже готове рішення. Готове рішення завжди простіше: його не треба програмувати, його не треба тестувати і т.д. Завжди можна послатись на те, що це робив не ти. Але головний аргумент це все-таки те, що можна заощадити свої нерви та сили на розробці. Адже я чудово розумів, що після проектування доведеться ще й проконтролювати, щоби все зробили як треба, а потім ще й запустити систему в експлуатацію. А це може виявитися дуже непросто.
Подивився кілька безкоштовних CRM і жалем повинен був зізнатися, що доналаштування готової системи виявиться не менш трудомістким процесом, ніж розробка з нуля.
Потрібна "лопата", але всі пропонують "екскаватор"
У результаті я почав переглядати інтерфейси добре документованих систем, щоб знайти в них ідеї або підглянути рішення. Ось підсумковий список, на якому я сконцентрувався:
Найкориснішою виявилася Zurmo, але навіть ідеї, які я підглянув там, у результаті довелося відсіяти. І я підійшов до рішення робити все (точніше проектувати) з нуля, тобто. зі своїх сценаріїв взаємодії системи та користувачів.
«За» та «проти» розробки CRM з нуля
Найсуттєвіший аргумент «проти» — це низька підготовка мене як проектувальника та продукт-менеджера (у цьому проекті) з погляду теорії розробки CRM систем.
Розумом я розумію, що за всіма добрими інтерфейсами лежить методологія, яка дозволяє не тільки зробити зручний інтерфейс, а й ефективно організувати роботу людей. Час на вивчення теорій управління, методик менеджменту, моделейвзаємодії у мене немає, тому при проектуванні залишається спиратися лише на логіку та здоровий глузд.
В принципі, я високої думки про свою логіку і проект невеликий, з локальними функціями (не буде інтеграції до зовнішніх систем) і дуже простою ієрархією ролей, тому я і зміг за нього взятися. Iceland
Істотне «За» в тому, що в результаті ми розумітимемо, як усе працює і зможемо налаштувати роботу системи у «гарячому режимі».
Початок та продовження: коротко
Почав я з карти. Розбив на бек, фрон (буде невелика видима з інтернету частина) та технічні функції, про які потрібно пам'ятати, але які можуть не мати прямої візуалізації в інтерфейсі.
Продовжив візуалізацією сценаріїв. Окремо зробив ключовий сценарій розмови із можливим розгалуженням. Я виходив з того, що інтерфейс повинен підтримувати сценарій розмови (якщо основною справою у співробітників будуть дзвінки) і допомагати їм у роботі, тому було важливо зрозуміти з чого складатиметься розмова і до чого він може привести.
У результаті розроблена карта та сценарії вили покладені в основу вайрфреймів для інтерфейсу співробітника та інтерфейсу адміністратора.
Сьогодні віддав на прототипування і потім спробуємо зібрати та змусити це все працювати.