saveug

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

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

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

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

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

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

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

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

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

Способы коммуникации по степени убывания эффективности:

• личное общение
  
• видеосвязь (скайп и пр.)
  
• телефон
  
• переписка
  

В вашем случае, в тикетах рекомендую фиксировать только итоги устных договоренностей.

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

Унифицировать действия заказчиков намного труднее, чем унифицировать обработку информации внутри компании. Советую выработать правила и внутри приводить все к одному виду, формату и структуре хранения.

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

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

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

Обычно заказчик соглашается на участие в тестировании в следующих случаях:
a) заказчик внутренний, b) низкое доверие к вашему тестированию или c) заказчик хочет съэкономить и согласился тестирование взять на себя. В остальных случаях - тестирование - это ваша задача. Заказчик хочет получить демонстрацию и увидеть, что все прекрасно, а не ваши баги. Ну а если смотреть шире, то любое обнаружение бага в ходе эксплуатации, является тестированием силами заказчика. :)