Андрей Плетенев

Исходя из вашего описания я вижу 2 причины, которые мешают вашему знакомому доводить проекты до конца:
1) Он пытается все делать в одиночку, при этом не являясь специалистом. Это крайне неэффективный путь. К примеру, если там нужно программирование, а он не программист, то нужно найти единомышленника программиста и т.д. Тогда проект не будет заходить в тупик из-за некомпетентности.
2) Похоже на то, что ваш знакомый по складу характера - исследователь. Т.е. ему нравится начинать новые проекты, изучать что-то новое. Как только стадия "узнавать новое" сменяется стадией "пахать", такие люди сдуваются и быстро находят новую идею, которая их вдохновляет. Если мое предположение верно, то ему нужно либо найти деятельность, связанную с исследованиями, либо людей, которые будут реализовать его идеи (см. п.1).

"Циклы разработки" и пр. ему не помогут.

Посоветуйте тем, кто в вашей фирме "пытается внедрить скрам", чтобы они хорошо разобрались, как он внедряется, какие проекты и команды подходят для скрам, а какие - нет, как подготовить людей.
Скрам - это не просто ритуалы, это - состояние команды. А у вас, судя по вопросу, этого состояния нет.
По книжкам и статьям из интернет ничего не внедряется. Пусть обратятся к тем, у кого есть опыт внедрения.

Процент выполнения - не очень хорошая метрика. Вот почему:
1) Две задачи могут иметь одинаковый процент выполнения, к примеру 90%. При этом одна может быть закончена завтра, а по другой - еще на неделю работы.
2) Если вы добавите в проект задачу и даже если при этом добавите разработчика, процент выполнения все-равно снизится.
3) Самое главное - процент не дает ответ на вопрос - вы успеваете в срок или нет.
Для отслеживания прогресса из простых метрик можно использовать планируемую дату завершения или оставшийся объем работ.

Ну и не забывайте 2 закона, касающихся использования процентов :)
- 90% времени задачи находятся в состоянии "сделано на 90%"
- Не так трудны первые 90% проекта, как вторые 90%.

В оценке есть количественная сторона и есть качественная. Выпишите основные юзкейзы вашей работы. В количественной оценке можно смотреть на такие параметры, как количество кликов мышью для выполнения тех или иных юзкейзов, время, затрачиваемое на непосредственные действия с UI в каждом юзкейзе. В качественной оценке - обычный опрос удовлетворенности пользователей. Можно взять NPS. Он в данном случае будет показывать количество сторонников и противников данной системы в вашей организации.

Как вариант: любой сервис опросов с отправкой результатов на почту типа Limesurvey. Насколько я знаю, в slack можно настроить переадресацию почты. + любая напоминалка о том, что нужно пройти опрос. Напоминать регулярно может все что угодно: от будильника в телефоне до google календаря.

Redmine + плагины
Это не ERP, но то, что вам нужно сделать может.

Насколько можно судить по вашему вопросу, причина в том, что у вас нет целостного подхода к разработке. Если вы не хотите много переделывать, работайте по "водопаду": наймите адекватного архитектора и проектируйте всю систему перед кодированием. А если вы не хотите/не умеете/не можете проектировать заранее, тогда уж следуйте эджайлу. При этом у вас переделки останутся, но хотя бы релизы станут короткими.
А у вас, похоже, методологии нет, что приводит к неэффективной трате средств вашим заказчиком.

Если работа може быть сделана удаленно (ваш случай) - никаких офисов. Лишние расходы и геморрой.
Если работы для него нет на полный день - тогда фриланс. Иначе - найм на fulltime.

Основной комплекс мер по защите от увода клиентской базы нужно внедрять заранее.
То, что можно сделать сейчас в вашей ситуации:
1. Расставаться “по хорошему” и прямо оговорить непереманивание клиентов.
2. РОП передает своему преемнику или вам всю информацию по клиентам и сделкам, которые находятся сейчас в работе: в каком состоянии работа по каждому клиенту, какие есть договоренности, обязательства, документы и т.п. Можно сделать такую передачу письменной. В идеале вся эта информация должна вестись в CRM.
3. C адреса РОП всем клиентам рассылается письмо, или он звонит им в присутствии преемника. Сообщается что с такого-то числа все дела будет вести новый человек (его контакты). Преемник должен как можно быстрее связаться со всеми переданными клиентами.
4. В случае, если риск увода базы высок, после решении об увольнении в ходе 2-недельного срока, пока РОП еще работает, допускать его к корпоративному компьютеру только в присутствии преемника. Обычно именно в этот период и крадут данные.
5. Если все же уволившийся РОП попытается уводить клиентов и других сотрудников, можно письменно изложить все факты и разослать клиентам и конкурентам, в т.ч. в компанию, куда ушел сотрудник. Так же можно опубликовать эту историю в интернет в отраслевых блогах или форумах. Пример подобной статьи, написанной моим знакомым, директором IT компании. В результате, потери в клиентах будут минимальны, нечестный сотрудник узнает, что означает деловая репутация, оставшиеся сотрудники десять раз подумают, прежде чем последовать его примеру.

OneNote

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

С этой оговоркой вам подойдет любая система обработки задач, тикетов, заявок с разграничением доступа. Из бесплатных - тот же Redmine. Доступ настроить так, чтобы в состоянии до назначения задачи она была видна всем, а в состоянии "Назначена" ее видел только менеджер и назначенный исполнитель. При регистрации пользователей генерируете всем обезличенные абстрактные username и вперед. Максимум, что потребуется из контактных данных - это e-mail для получения уведомлений. Их лучше тоже генерировать и выдавать со своего домена.

Если речь идет об экономии времени на вливании новых людей в проект, то все, что вам нужно, это:
1) Выяснить, отсутствие какой инфрмации приводит к наибольшим трудозатратам нового саппортера
2) Описать нужную информацию при условии, что время, потраченное на описание, будет стоить меньше чем время, которое в противном случае будет потрачено на то, чтобы самостоятельно разобраться и выпытать это у коллег (с учетом времени коллег).

Две мысли для расширения понимания конкуренции:
1) В современном мире за одни и те же деньги потребителя конкурируют все, кто что-либо продает. Вне зависимости от отраслей и ниш.
2) Конкуренты в одной нише могут стать и партнерами при желании.

Совет:
Разруливать здесь нечего. Вне зависимости от отрасли, не распространяйте информацию, полученную от своих клиентов. Если вы построили с ними надежные доверительные отношения, то не будет иметь значения, узнают ли они друг о друге. А если доверия нет, то рано или поздно вы так или иначе потеряете клиента. Т.е. суть не в том, знают ли они друг о друге, а в том, доверяют ли они вам. Стройте отношения, укрепляйте доверие и не будете бояться подобных вопросов.

Если у вас нет плана, то причина не в том, что нет инструмента. Инструментов полно и дело не в их выборе. Дело в том, что у вас (и судя по всему у вашей команды) нет навыков проектной работы, включая планирования проектов.
У вас есть выбор: a) Учиться этому "методом тыка". Это больно, дорого, долго и не факт, что хорошо научитесь. b) Взять в команду опытных людей, которые вас научат. Это - лучший вариант. с) Если в команду вы привлечь таких людей не сможете, то хотя бы поучитесь у них. Есть множество курсов. Выбирайте практиков.

1) Оценка как правило основывается на прежнем опыте. Задачи с новой технологией и новой базой не имеют достаточной основы для оценки. Желательно сначала создать исследовательскую задачу. Результатом этой задачи должна стать оценка. Исследовательскую задачу тоже не просто оценить, но ее можно ограничить. Например: "Дать оценку с той точностью, которую можно получить, потратив 16 часов на исследование." В любом случае - это будет точнее, чем оценка "навскидку". Если задачу будет оценивать 1 человек, а не покером, то для уточнения используйте оценку по 3 точкам.
2) 50 часов - это немного больше человеко/недели. У вас спринт - меньше недели? Если все же задача выходит за границы спринта, ее нужно дробить на части (желательно не больше 3-4 человеко/дней) и распределять эти новые задачи по следующим спринтам в общем порядке. Еще один вариант - подумать можно ли получить ту же бизнес-ценность другим, менее затратным путем.
3) В скраме вместо гантта используют диаграмму сгорания. Ее двигать не надо, нужно просто дорисовывать каждый день. Кстати, при использовании гантта, его вручную двигать не нужно, если есть регулярное обновление статусов от разработчиков (например в MS Project).

Комментарий к постскриптуму. Напоминает анекдот "Что тут думать? Прыгать надо!"
Каждый час, выделенный тобой на обучение, высвободит тебе и команде на порядок больше времени, теряемого впустую, в каждом проекте. Добавь к этому стоимость ошибок и еще раз подумай. Желая съэкономить время, ты на самом деле, выбрал самый времязатратный, дорогой и долгий режим развития.

1) На практике это означает a) Людей в команду желательно подбирать более универсальных, владеющих разными технологиями и без амбиций типа "яжпрограммист, я не буду тестить". b) Если выбирать не приходится и вам достались узкие специалисты и при этом команда постоянная, то занимайтесь ее развитием, расширяя их компетенции. Это долго, но стоит того. с) Если специалисты узкие и даны на короткое время, тогда обходитесь без кроссфункциональности. Это не догма, как и все остальное в скраме.
2) В planing poker не могут участвовать 2 человека. Участвует вся команда. Кроме того на практике джуниор обычно не спорит с сеньором, а прислушивается к нему. По времени планирование спринта - ограничено. (мах 8 часов для больших и сложных спринтов) Скрам-мастер должен следить за тем, чтобы обсуждение шло конструктивно и не буксовало. Если кто-то уперся рогом в землю, не может убедить других и не слушает их аргументы - это не командное поведение. А команда - это основа agile. С ним нужно проводить воспитательную работу. Если это регулярно - возникает вопрос, действительно ли его место в этой команде.
3) Все необходимые виды тестирования должны проходить в рамках спринта. Желательно использовать Continuous Integration и тесты, включая нагрузочные гонять регулярно. Разработчики, реализуя user stories должны думать о производительности, как и о многом другом. Разумеется, требования к производительности должны быть им озвучены.
4) Это не скрам, а одна из практик экстремального программирования. Применял в компании SiberLogic. В случаях, когда было критически важно, несмотря на затраты, быстро и качественно запилить задачу за часы.
5) Коммуникацию с заказчиком в скраме обычно осуществляет продакт. Он же и отвечает перед ним. Команда отвечает перед продактом. На практике в некоторых компаниях перед заказчиком отвечает ПМ, который находится снаружи скрам-команды.
6) За найм и увольнение отвечают те же люди, что и без скрама. Это может быть директор или HR. Иногда этим занимаются ПМы. Однако, скрам-команда может "вытолкнуть" человека, если он в нее не вписывается. Если разговоры по душам не помогают, то человека перемещают в другую команду или в другую компанию :)

По книжкам скрам не внедряется. Если будут еще вопросы, пишите в личку.

Поговорите с каждым ПМ'ом один на один. Без гонора и амбиций, а по человечески. Можете даже пивка попить или чаю. Нормальный ПМ сам должен был бы это сделать, видя, что вы раздражены. Но, возможно, вы скрываете свои чувства или Пм'ы еще неопытные. Исходите из того, что вы с ними делаете одно дело и должны помогать друг другу. Расскажите ему, что по-вашему, мешает вашей совместной продуктивной работе и предложите свои варианты взаимодействия. Оперируйте фактами, а не эмоциями, обсуждайте действия, а не личности. Нормальный ПМ нормально к этому отнесется и объяснит почему действует именно так или изменит свое поведение. Если не удастся прийти к общему решению, идите к вышестоящему руководству. После этого на вас снизойдет просветление, либо вы перестанете работать вместе.