Продолжая развивать нашу CRM-систему id:CRM, я решил добавить в нее функционал менеджера проектов. У нас уже есть функционал для работы внешних пользователей, но чат-бот в Телеге с подключенной нейронкой поудобней будет.
Основные задачи, которые должен выполнять цифровой проджект:
1. Авторизация/приветствие клиента.
2. Получение ТЗ на доработки сайтов (тут возможно понадобится ИИ).
3. Оценка ТЗ (а тут точно должна работать нейронка).
4. Создание задачи в CRM.
5. Уточнение вопросов по задаче от технических специалистов (хотя если такая необходимость возникла, значит пункт 2 отработан плохо).
6. Выдача статуса по задачам клиента.
Ну и в качестве доп задач работа с командой:
7. Выдача списка задач сотрудника с дедлайнами. 8. Напоминание о предстоящих дедлайнах.
Таким образом все, что делают ПМы в компаниях, где ПМ и Аккаунт-менеджер разные позиции, закрывается полностью. __Если совсем просто, то АМ это про общение с клиентом, а ПМ про разработку__. Вот разработку и оцифруем.
Самые сложные пункты в этой задаче это 2 и 3.
Получение ТЗ является проблемной зоной, потому что все заказчики и проджекты присылают свои ТЗ с правками в совершенно разных форматах. А ведь как бы чудесно было, если бы все пользовались системой SMART для этого. Уверен, про нее все знают, просто не пользуются, поэтому далее опишу ее для себя, чтобы подглядывать при задании логики боту, который будет по ней проводить валидацию ТЗ, не принимая в работу кривые и неточные формулировки. Возможно, что здесь стоит подключить ИИ, чтобы он переписывал ТЗ по-нормальному, но пока не ясно, что проще – валидация с подсказками или ИИ с переписыванием. Возможно, придется попробовать и так и так.
Итак, ТЗ по SMART:
Specific – конкретный. Каждая правка должна быть максимально чёткой и однозначной. Не «улучшить дизайн шапки», а «заменить фон шапки на белый, убрать кнопку «О нас», изменить логотип на новый из вложения». Стоит так же прикладывать скриншоты там, где может возникнуть неоднозначность. Это снижает риск недопонимания и лишних вопросов.
Measurable – измеримый. Все правки должны быть измеримыми. Например: «Исправить баг, из-за которого форма не отправляется». Это позволяет проверить, выполнена ли задача.
Achievable – достижимый. Правки должны быть выполнимыми с учётом текущих технических ограничений сайта, бюджета и времени. Например, нельзя требовать «перевести сайт на новую CMS за один день» или «сделать уникальный анимационный эффект без увеличения бюджета».
Relevant – актуальный. Этот пункт в валидации ТЗ не нужен.
Time-bound – ограниченный по времени. Важно указывать дедлайны (и помнить про достижимость): «Обновить текст на странице «О компании» — до конца недели». Это помогает планировать задачи, избегать затягиваний и держать работу под контролем. При этом нет смысла писать “нужно еще вчера”, потому что если вам надо что-то на столько срочно, значит это вы где-то не доработали, а разрабы все равно не вернутся в прошлое и поставят вас с график работ по своему усмотрению.
Таким образом, ставя задачу с использованием каждой буквы, можно добиться того, что задачи будут делаться с первого раза и максимально быстро. Но кто об этом думает, когда шлет в мессенджер 20 сообщений, которые можно связать в 1 предложение…
Проблема оценки ТЗ уже посерьезнее. Потому что есть типовые задачи, которые подходят всем, а есть уникальные задачи. Для оценки типовых достаточно вести учет времени и задач, а вот с уникальными мы попадаем в ситуацию неопределенности. Часто для такой оценки надо сразу придумать решение, а ошибка в расчетах времени может привести, как к отказу от работ (при завышении), так и к убыткам (при занижении).
Идея решения этой проблемы в подключении ИИ. Используя нашу многолетнюю базу задач и затрат времени на них, ИИ сможет дать верную оценку. __В теории.__
Позже напишу, что в итоге получилось, а при положительном результате, перенесем проджекта из n8n в плагин для WordPress.
