crokus

Любой KPI проистекает из процесса. Если у вас Scrum, то в нем единственной метрикой является Velocity (скорость команды) и определяется она не для программиста, а для команды разработки (для всех программистов, участвовавших в спринте).

Очевидно, что при одинаковых расходах от спринта к спринту, вы хотели бы, чтобы Velocity не падала, а наоборот, со временем росла. Тренд Velocity и может быть тем самым KPI. Если тренд нисходящий, без наличия объективных причин (изменение состава команды и т.п.), это признак снижения продуктивности/эффективности команды разработки.

В разработке любого продута есть еще стадия эксплуатации, на которой в команду возвращаются баги, недоделки, недодумки и т.п. Число дефектов, вернувшихся из эксплуатации, также часто используемая метрика качества разработки.

Это если из простых.

В вашем случае хорошо будет объединить поддержку и Kanban. Процесс при этом может выглядеть следующим образом:
1. Через поддержку клиенты оставляют заявки, где описывают что им нужно.
2. Менеджер разгребает эти заявки, уточняет их (добавляет нужную информацию) и может как-то классифицировать, например, Сайт или Инфраструктура или еще как-то. Менеджер может оценивать сложность заявок по шкале X, L, M, S.
3. Члены команды берут по мере возможности себе те задачи, которые подходят им по классу и по оценке сложности. Выполняют работу и перетаскивают карточку в состояние "Выполнено".
4. Менеджер принимает выполненную работу и отмечает заявку как завершенную, либо отклоняет ее на доделку/переделку. Заказчику уходит письмо о том, что его заявка выполнена, ну и дальше он смотрит, отклоняет или принимает ее решение.

В этом процессе минимум взаимодействия, все видно на Kanban-доске. Видно где затык, кто сидит ковыряет в носу и т.д. В качестве инструмента, в котором такой процесс можно организовать, могу посоветовать devopsboard.ru

Самое простое и быстрое: форумы, slack, телеграмм, сообщества любые по тематике продукта. Это позволит собрать начальные контакты и мнения.

Для обстоятельного разговора лучше всего подходит личное общение: телефон, переписка, встреча. Здесь могут появиться первые неравнодушные потенциальные пользователи. Чтобы добыть эти контакты можно использовать знакомых, друзей или потратиться на недорогой телемаркетинг (fl.ru или еще что-то) - девочки по Skype звонят потенц. клиентам, предлагают познакомиться с товаром, с производителем и т.п. Клиенту нужно что-то дать: сайт, письмо с презентацией продукта, вебинар и т.п. Все это несложно и дешево сделать дома на обычном ПК.

Вообще места обитания клиентов сильно зависят от продукта. Вам нужно было указать хотя бы категорию продукта, тогда пипл набросал бы конкретных идей (мест).

Если нет никаких идей по клиентам или где их найти - это верный признак того, что бизнес лучше не начинать.

Андрей, у вас получается пул разных задач и под них целесообразно использовать разные системы:

Внезапно стало неудобно и непродуктивно общаться с заказчиками, которых набралось под 50 и с ними нужно взаимодействовать и отслеживать состояние процесса разработки в актуальном состоянии одновременно.

Для управления коммуникациями с заказчиком - CRM-система (их множество, я работаю в bpm'online), в ней фиксировать все контактные данные, связи между клиентами и контактами, планировать встречи и звонки, желательно туда же завернуть электронную почту.

Процесс разработки - система управления проектами, можно в самой CRM-системе вести список объектов их статус, сроки и % выполнения.

Почта перестаёт работать, как инструмент коммуникации, после вложенных друг в друга 15 сообщений. Разбивка сообщений по темам и сообщениям объём переписки только увеличивает и запутывает.

Обсуждение отдельных организационных тем всё равно придётся вести в почте - это самый эффективный на данный момент инструмент, позволяющий фиксировать историю и договорённости. Разбивать переписку по темам - хороший вариант, в конце договорённостей - резюме.
Обсуждение проектных задач вынести в систему описания задач (можно пользоваться любой wiki-системой, начиная от платной Confluence, до MediaWiki и т.п. или использоваться связку NextCloud+LibreOffice Collaborate для командного онлайн-редактирования документов - я пользуюсь вторым набором).

Как унифицировать отдельное хранение файлов и документов - кто то одним файлом ТЗ шлёт, кто то порознь и в разных форматах?

Определить свой формат ТЗ и приводить все документы к единому виду и единой структуре. И своё хранилище с разграничением доступа (я, опять же, пользуюсь NextCloud)

Как организовать демонстрацию результатов и сбор фидбэков по ним?

Перед передачей результата работ в тестирование составить тест-кейсы, в которых с одной стороны должно быть описаны действия пользователя и плановый результат, а с другой стороны пользователь укажет что у него реально получилось и какие замечания. Для этого тоже есть свои системы, мне пока обычных текстово-табличных документов хватает - если делать ТЗ в виде пользовательских историй, то их же потом можно в качестве тест-кейсов использовать.

Как организовать совместное с заказчиком участие в процессе тестирования?

Этот процесс лучше разделять на три: внутреннее тестирование + обучение + тестирование заказчиком с заполнением тест-кейсов.

Можно ещё почитать книгу М.Кон Пользовательские истории - неплохо описан процесс и порядок организации Agile-разработки.