dmshar

А зачем считать "баги на проект"?? Тем более, что любой мало-мальски опытный программист знает главную аксиому программирования: "Любой последний найденный баг в программе/проекте всегда является на самом деле предпоследним".
И это не шутка.
Вот из этого и исходите.

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

Не могу понять.
Есть возможности и желания - "занимайтесь" сайтом сами. Не хотите - да, ищете кто будет это делать за плату, т.е. с кем будете делиться прибылями. Не факт, кстати, что кто-то согласиться это делать за долю, наемные работники как правило хотят фиксированную и гарантированную зарплату. Хотите - доверяете ему, не хотите - не доверяете. Хотите - отдаете ему вести весь сайт. Не доверяете одному - найдите пятерых и распределите задания между ними в надежде, что они не сговорятся против вас. "Как доверять" - это зависит от уровня вашей мании недоверия окружающим и умения разбираться в людях.
Вопрос-то в чем? Особенно если "другими проектами не занимаюсь"?

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

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

Есть что-то, что можно почитать на эту тему? Может какие-то практические кейсы с примерами составленной документации и т.д.?
Тысячи книг и десятки тысяч сайтов с "чем-нибудь на эту тему". Включая практические кейсы, отработанные методики, лучшие практики и т.д. Гуглите по слову "Управление проектами" и читайте все подряд. Ну, можно еще уточнить "Управление проектами в области ИТ".

1. От того, что вы пройдете какие-то курсы - начиная с Гуру, который из тех, кто "сам не умею, но научить всех могу" до суперкрутого американского универа - вы разьве что наберетесь терминов и умения их (термины) применять где надо и где не надо. Правда, хоть будете знать, что они есть и что они значат. А вот когда в жизни столкнетесь с десятком реальных ситуаций, котрорых вроде бы и в книжке описаны, да вот только в жизни все немного "не так" - вот тогда можно считать, что вы чему-нибудь и научились.
2. Можно-ли не набивать шишек? Ну на курсах вам объяснят, что можно. Вот только почему-то 101% реальных фирм эти шишки все-таки в той или иной степени набивают (если не успевают схлопнуться до - или от - первой же шишки).
3. Суть, конечно же все не только уловили, но и описали-обсудили тысячи путей их решений и в курсах, и в книгах, и в интернет, и даже на этом форуме. Ну и? Вот-жеж нежданчик, серебрянной пули, позволяющей "не наступать на грабли и сосредоточится на процессах и их наладке" так и не отлили.

С правообладателями можно и не контактировать. Но тогда придется контактировать с правоохранителями. Выбирайте, что вам больше нравиться.

Очень интересный кейс. И не простой.
Но, во-первых, что-то у вас не так в организации проекта, если любой может лЁгко снести свой код за два дня до дедлайна. А где копии, а где контроль удаления?
Есть над чем поработать даже без относительно к ситуации, которую мы рассматриваем.

Во-вторых, проблема "выгорания" - это проблема психологии. Мне такие проблемы при удаленной работе попадались один раз. И честно говоря, даже при офисной работе с ними справиться не легко - но тут как-бы человек на виду, всегда можно поговорить на диванчике, за чашкой кофе. А на удаленке контакт значительно слабее, поэтому надо сказать , что и шансы на успех будут на порядок ниже.
Вы должны вообще-то говоря понять, что как только вы - как работодатель и как исполнитель - приняли решение об удаленной работе - все личные проблемы исполнителя остаются вне поля вашего внимания. Вы должны его об этом поставить в известность сразу-же. Это его плата, которую он несет в обмен на удобства его работы дома. Он должен понимать, что это не он, это вы согласились на то, что-бы он не тратил время-деньги на дорогу, на присутсвие в офисе, на завязывание галстука и шнурков на ботинках, на жесткий контроль часов и т.д. "Выгорел" - это не COVID-19 подхватил, не ногу сломал, упав с дивана и не кошка любимая заболела, срочно надо к ветеринару. "Выгорел? - ну пойди соберись и работай дальше. Не можешь - поезжай на Бали, расслабся, как вернешся - подавай резюме на свободную к тому моменту вакансию, тогда и будем решать". Тем более, что участник проекта из новых, а с новыми - всегда легче прощаться, чем с теми, с кем ты сделал десяток проектов. И после десятого совместного проекта я бы "выгорел" - еще потерпел-бы, дав человеку передышку. А если это начинается на втором-третьем месяце первого проекта?

Еще одно. "Выгорел" - это один кейс. "Сотрудник снес свой код, сорвав дедлайн" - это совершенно другой. Вообще-то говоря он нанес вам (вашей фирме) урон, материальный. Вы с ним об этом говорили? Вы ему объясняли, что срыв дедлайна - это удар не по абстрактной фирме или абстрактному заказчику - это в первую очередь удар по коллегам, работающим вместе с ним на проекте. Возможно - лишении их премии. Вы спросили его, как он собирается компенсировать этот урон? Что он вам ответил?

Пока писал - понял, что на самом деле тут таки таки два разных решения.

Первое, если бы просто "выгорел". Тут есть правило менеджмента "управляемость такая-же важная характеристика сотрудника, как его квалификация". И не важно, что "для своего уровня неплохой". Неплохой, но слабоуправляемый. Найдете другого, но впредь при приеме на работу смотрите не только на квалификацию, но и на его социально-психологические особенности. Поэтому алгоритм - "беседа - выяснение причин - и если не помогло - то прощание".

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

Ну вот как-то так.
Удачи вам в решении проблемы.

Не сравнивайте круглое со стеклянным.
Дисциплина распределения заявок - это ну никак не "методология (и не метод, и не методика) управления". Это просто дисциплина распределения заявок. Не больше.
А agile или scrum - это методологии, в которых распределение заявок играет 246 роль по важности.