1. Типичные ошибки в техническом задании
1.1. Ошибки в понимании целей и задач проекта
1.1.1. Подмена проблемы пожеланиям клиента
1.1.1.1. Например, клиент говорит "Нужен новый статус", а в реальности проблем в отсутствии понимания, как правильно работать и нормального обучения
1.1.2. Нет привязки к бизнес-целям клиента
1.1.2.1. ТЗ описывает "какие кнопки сделать", но не отвечает на вопрос "на что повлияет"
1.1.3. Отсутствие приоритизации
1.1.3.1. "Хотелки" смешаны с критичными задачами, из-за чего внедрение затягивается или идет хаотично
1.1.4. ТЗ составлено только по словам клиента
1.1.4.1. Без анализа реальных процессов, системы учета и фактических данных
1.2. Ошибки в структуре и содержании ТЗ
1.2.1. Слишком "техническое" ТЗ
1.2.1.1. Описаны поля, галочки, роботы, но нет логики процесса. Сотрудники потом не понимают, как работать из-за её отсутствия
1.2.2. Нет сценариев работы пользователя
1.2.2.1. Не расписано, что происходит с лидом, кто его обрабатывает, что должно произойти на каждой стадии
1.2.3. Отсутствие визуализаций
1.2.3.1. Схем, воронок, карт интеграций. Клиенту сложно понять текст, он соглашается "на доверии", а потом недоволен результатом
1.2.4. Нет связи между разделами
1.2.4.1. В одном месте описана одна логика, в другом - противоречащая ей
1.2.5. Размытые формулировки
1.2.5.1. "Сделать удобно", "Настроить аналитику", "Ускорить работу", без четких критериев результата
1.2.6. Нет информации о правах и ролях
1.2.6.1. Не прописано, кто и что может видеть, изменять или удалять
1.3. Ошибки в технической части
1.3.1. Прописаны функции, которых нет в Битрикс24 или они требуются дорогостоящих доработок
1.3.1.1. Например, кастомная интегация, которую клиент не готов оплачивать
1.3.2. Нет учета ограничений тарифа
1.3.2.1. Настроено то, что работать не будет, если клиент не купит более дорогой тариф
1.3.3. Отсутствие нормальной архитектуры
1.3.3.1. Поля и процессы продублированы, система становится перегруженной и неповоротливой
1.3.4. Слишком много ручных действий
1.3.4.1. Автоматизация не проработана, процессы остаются ручными, но с дополнительными кликами
1.3.5. Противоречивые условия автоматизаций
1.3.5.1. Роботы мешают друг другу, перепрыгиваюют стадии или создают дубли
1.4. Ошибки коммуникаций и согласования
1.4.1. Клиент подписал ТЗ, но не понял его
1.4.1.1. Написано сложным языком, без конкретики и примеров
1.4.2. Нет границ проекта
1.4.2.1. Не указано, что входит и не входит в текущую настройку (потом клиент требует "еще сделать")
1.4.3. Отсутствие финальных критериев приёмки
1.4.3.1. Не прописано, как понять, что задача выполнена и можно сдавать проект
1.4.4. Неполные данные от клиента
1.4.4.1. ТЗ составлено без всей необходимой информации (например, нет структуры компании, источников лидов), из-за чего приходится переписывать
2. Техническое задание - структура, логика, критерии
2.1. Делают в miro
2.1.1. Шаблон ТЗ
2.1.1.1. https://miro.com/app/board/uXjVJVu_K58=/
2.2. После того как сделали, еще раз пробежаться с клиентом и зафиксировать, всё ли правильно поняли
2.3. 24 шаблона ТЗ
2.3.1. https://miro.com/app/board/uXjVIt99bYg=/
3. Методы выявления "узких" мест
3.1. Где встречаются
3.1.1. Уже есть в бизнесе клиента
3.1.2. При составлении ТЗ
3.1.3. После запуска
3.2. Проблемные зоны
4. Как подойти к настройке CRM с головой "от бизнес-процесса - к системе"
4.1. Делаем обзор сверху вниз на бизнес компании
4.1.1. Какие есть отделы
4.1.2. Кого мы предположительно будем добавлять как сотрудников в Битрикс24
4.1.3. Какие у нас есть процессы образно общими словами (процесс продаж, прооцесс снабжения, HR)
4.1.4. Из этих блоков формирууем скелет того, что будет
4.1.4.1. Пример
4.1.5. Потом начинаем углубляться и выбираем, где и в каком блоке будет максимальная польза исходя из самого слабого места на текущий момент
4.1.6. Затем начинаем простраивать систему и углубляемся в процесс
4.1.7. Этап нужно называть законченным действием, потому что менеджеру интуитивно будет понятно в какой момент и куда передвинуть сделку
5. Что обязательно нужно описать в ТЗ: воронки, роли, типы клиентов, интеграции, документы
5.1. Обязательно перед описанием нужно выделить время на изучение данных
5.2. Когда начинаем описывать бизнес-процесс, выписывать показатели, какие нужно видеть, чтобы, например, выделить для этого сразу отдельную стадию
5.3. Битрикс - это сервис, где много "кирпичиков" и лучше двигаться по блокам
5.4. Работу над любым блоком начинаем с самого начала. Например, в продажах - источники. Отсюда понимаем, какие должны быть интеграции (сайт, телефония, WhatsApp)
5.5. Далее обсуждаем карточки сущностей (поля контакта, компании)
5.6. Далее сами воронки
5.6.1. Название - завершенное действие
5.6.2. Логическое завершение - успешный результат воронки, чтобы смотреть аналитику
5.6.3. Причины отказа
5.6.3.1. Плюс обязательное поле с комментарием
5.7. Далее наполняем воронки автоматизацией
5.7.1. Задача должна быть отражением этапа, где она находится
5.7.2. Обязательно реальные сроки
5.7.3. Результат задачи - это название следующего этапа
5.8. Визуализировать структуру компании и кто за что отвечает
5.9. Проговорить настройки ролей
5.10. На усмотрение дополнить внутренней работой. Например, создание проектов или генерация документов
6. Типичные ошибки при составлении ТЗ
6.1. Когда пишут ТЗ на всё и сразу, делают великий космический корабль
6.1.1. Сложнее будет разбираться
6.1.2. Больше потратят времени на обучение
6.1.3. На ТЗ не получится продумать прям всё
6.2. Делать этап для этапа и поле для поля не нужно
6.3. Если действие не несет цели, то не делаем
6.4. Слишком длинные воронки
6.5. Слишком много автоматизации, чтобы не засыпать задачами
6.6. Не игнорировать роли и права доступа
6.6.1. Не должно быть много администраторов!!!!
6.7. Нарушение целостности
6.7.1. Должно быть последовательное движение по воронкам и смысловое продолжение, а не кусочками
7. Как не уйти в избыточность и не забыть про ключевое
7.1. В простых вещах есть истина
7.2. Отдыхать после написания ТЗ
7.2.1. Иногда просто нужно время, чтобы в спокойной обстановке обдумать процесс
7.2.2. Не спешить
7.3. ТЗ не становилось ГОСТом
7.3.1. ТЗ может меняться и это не нужно отрицать
7.3.2. Оно живое и может дополняться
7.4. Не старайтесь захватить всё и сразу
7.4.1. Делаем только то, что приносит пользу сейчас
7.4.2. Если отдел появится потом когда-то, то его исключаем из ТЗ
7.5. Не боимся обращаться к коллегам
7.6. Добавляйте внутренние процессы и мелкие плюшки
7.7. Отталкиваться от цели и не терять фокус
7.7.1. Зачем мне сейчас нужна эта задача
7.8. Поставить фильтр на всю систему, что конкретно в этой воронке влияет на результат и сделать акцент на этом этапе
7.9. Убрать паранойю тотального контроля
7.9.1. Пример: Я хочу понимать, сколько слов сказал сотрудник в день
7.9.2. Вопрос: Какую цель мы тут преследуем?
7.10. Не стесняться переделывать
8. Подход "От цели к системе"
8.1. Разбор бизнес-процессов - Сборка CRM - Презентация
8.2. Этап 1 - Подготовка
8.2.1. Изучить компанию клиента и зафиксировать себе заметки - найти инфу в интернете
8.2.2. Фиксируем какие-то идеи, котоые появляются в процессе изучения
8.2.2.1. Это уже результат для собственника, хотя мы еще не погружались в его бизнес
8.2.3. Присылаем кейсы клиенту до первой встречи, чтобы клиент ознакомился
8.2.4. Тесты - оставить заявку на сайте и посмотреть на результат
8.3. Этап 2 - Первая встреча
8.3.1. Цель и задачи - почему решил настроить себе CRM, какой результат хочет получить
8.3.2. Боль - какую боль хочет закрыть, что ранее было не так
8.3.3. KPI - какие показатели отслеживают
8.3.3.1. Поможет при построении процесса и при выборе дальнейших отчетов
8.3.3.2. Поможет при выборе дальнейших отчетов
8.3.3.3. Поможет при замере результата (какой был и какой стал)
8.3.4. Бизнес-процессы - что за компания, что продают и т.д.
8.4. Этап 3 - Определить этапность работы и MVP
8.4.1. Какие подразделения делаем и в какой последовательности
8.5. Этап 4 - Рисуем ТЗ
8.5.1. Максимально прозрачное