August 15, 2021

Понимание MVP на своём опыте

Чтобы сделать большой проект, необходимо двигаться от базового функционала. Насколько он должен быть большой?

На моём примере - сейчас идёт разработка платформы для взаимодействия разработчиков (поставщиков) и постановщиков задач (покупателей). Я долго вынашивал эту идею, думаю около 3х лет. Ранее работал в компании через jira, в других компаниях был лист учета рабочего времени в эксель.

Основная "боль", которая у меня возникала:

  • Задачи и технические требования к ним терялись в переписке, так как доступ к jira имел только я, а не клиенты
  • При использовании экселя я сам забывал вовремя вносить задачи в таблицу, а потом приходилось вспоминать, чтобы детально описать - на что же я потратил 2 дня разработки
  • Чтобы поставить задачу надо было потратить время: созвониться с клиентом, написать на почту, получить согласование цены и только потом заполнить её в jira / эксель
  • Не было понимание статуса задачи: она готова, надо ли доработать, тестирует ли её заказчик
  • При ведении таблицы в какой-то момент просто забивал на неё и начинал вести новую: либо она была неудобная, либо я не оперативно её вёл и она становилась неактуальной
  • Ну и частенько я просто забывал выставлять счета за некоторые задачи и просто терял деньги

Полтора года назад сделал самый простой пример сайта + сервера, где мои клиенты могут ставить мне задачи. Задачи перестали теряться, так как было поставлено условие - задачу не выполняю, пока её нет в задачнике. Стало заметно удобнее, появилось понимание - кто должен мне денег, а кому я, если работал с разработчиками и в каком статусе та или иная задача, её приоритет. Я понял, что надо выкатывать систему на рынок, т.к. не нашёл удобных примеров:

  • jira - пришлось бы обучать клиентов с ней работать, там много всего и клиентам было бы неудобно, а особенно - мне. Настройка могла занимать много времени, нет возможности выставлять счета
  • гугл таблицы - тут всё просто, неудобный функционал. Клиенты отказывались ставить задачи там, да и заморочки с правами на редактирование

Мой сайт был сделан на нативном js, нормально работал только на пк, на мобильном телефоне не работал. Коллега подсказал, что можно использовать админ лте для ускорения разработки, но на тот момент я его не послушал и оказался не прав. Он многое позволяет сделать из-за платформы конструктора.

2ая версия сайта была уже написана на нём. Клиенты ощутили удобство, потому что я решил одну из болей клиентов - в моей первой версии был только один список задач, листать было неудобно - я разделил их на актуальные / на согласовании / все.

В данные момент я учитываю, что клиенты этой crm (1cer) будут регистрироваться, добавлять постановщиков и исполнителей, вести учёт по взаморасчетам. Чтобы мои клиенты начали ставить задачи, мне пришлось сделать её максимально простой. Раньше было только текст задачи и пару полей: какая база, какой тип задачи. А со стороны разработчика - комментарий и оценка. Так же, была возможность в разрезе задачи вести переписку.

Текущая версия сайта подразумевает наличие расширенных ролей, блок по взаиморасчетам и статистику. А чтобы к системе было больше доверия я решил, что разработчик должен писать затраченное время (или согласованные часы) и их нельзя было бы поменять, чтобы не "накинуть" руководителю со стороны разработчика. Клиент должен понимать полную стоимость задачи, если в ней участвует несколько человек. Например, если это будет несколько задач в рамках одного проекта.

Мне хочется построить максимально удобную систему, которая всё учитывает - это хорошо, но на первом этапе надо двигаться итерационно. Суть системы - учёт задач, следовательно базовым функционалом - должно быть именно постановка и выполнение задачи. Ранее я хотел сделать расширенное редактировать организации и партнеров, но чтобы получить обратную связь быстрее - нужно обеспечить бизнес процесс:

  • Разработчик регистрируется
  • Добавляет партнера (покупателя)
    • Добавляет базы, с которыми взаимодействует партнер
    • Добавить пользователей, которые ставят задачу и выслать им приглашения
  • Поставить задачу и выполнить её, получить подтверждение от клиента

До этого я хотел вот такой бизнес процесс:

  • Разработчик регистрируется
  • Вводит данные о компании (вид юр. лица, реквизиты для выставления счета)
    • Вводит свои базы
    • Вводит подразделения
    • Добавляет сотрудников
      • устанавливает ставку
      • высылает приглашения
  • Добавляет контрагента
    • Заполняет его реквизиты для выставления счетов
    • Заполняет ставку
    • Заполняет базы
    • Заполняет подразделения
    • Добавляет пользователей
      • Устанавливает права
      • Какие видят базы
      • высылает приглашения
  • Возвращается к своим сотрудникам
    • Указывает, кто какие задачи видит по контрагентам / подразделениям / пользователям
    • Дополнительно указывает - должна ли оценка по задачам согласовываться внутри компании
  • Создаются задачи, выполняются
  • Выставляются счета

Разработка второго бизнес процесса кратно дольше, а протестировать его можно будет только при выполнении всей необходимой доработки. Но если сделать только базовую часть, то её уже можно отдавать на тестирование своим коллегам и получить обратную связь и вовлеченность. Эта система должна приносить прибыль, соответственно, нужность - это главный показатель. На следующем этапе я уже доработаю блок с взаиморасчетами и буду просить денег, так как система будет экономить время и деньги. Соответственно ценность будет больше чем цена.