kn0ckn0ck

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

Определите наиболее весомые для проекта риски. Из того что перечислено, на мой вкус, это все яйца в одной корзине (один разработчик) и отсутствие тестирования. Важно понимать, что наличие костылей само по себе не так уж и критично, как поют некоторые спецы. Куда критичнее отсутствие регрессионного тестирования.

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

С задачей по настройке CI я бы тоже не спешил. Если время выполнения одной задачи занимает неделю, то ускорение выпуска сборки через CI на 1 день ничего не решает. CI хорош, когда несколько разработчиков делают изменения в своих ветках, когда есть автотесты и т.п.

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

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

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

Если уверены, что проблема именно в этом запросе, то анализировать нужно не запрос, а план его выполнения (explain ...). Без плана ничего дельного сказать нельзя. Можно только предложить абстрактные идеи для оптимизации:

1. продуманные индексы
2. денормализация
3. материализованные представления
4. партиционирование
5. типы движков

Лучше всего учиться на примерах. С другой стороны, если у вас есть макеты, дизайн и структура БД, то это фактически и есть ТЗ. Вам осталось минимум - записать это в форме удобной для исполнения и контроля. Разбейте систему на небольшие участки (формы, страницы и т.п.), это будут разделы вашего ТЗ. Наполните эти разделы тем, что у вас есть. Вот и готовое ТЗ.

Учтите, что если разработчик требует ТЗ, то у него есть какое-то представление об этом и если вы ему не угодите, то он скажет, что ТЗ плохое. С этим ничего не поделаешь. Хорошее ТЗ писать могут не многие, этому учатся годами. Если у вас нет столько времени, измените стратегию. Замените качественную формализацию общением. Так и скажите разработчику: "у нас есть вся нужная постановка, а детали, конкретика и вопросы при личном общении".

Опытный разработчик с хорошей точностью может оценить стоимость реализации макета (тем более с дизайном). Ему разжовывать все детали через ТЗ не требуется. Обычно все в ТЗ прописать не удается, не тешьте себя надеждами, что вот теперь-то все будет копейка в копейку. Всегда бывают разночтения, непродуманные моменты и изменения в ТЗ. Коммуникация между заказчиком и исполнителем обязательна.

1. выгружаете его из трекера, в котором ведете задачи и списывается трудозатраты
2. ведете Excel-ку самостоятельно, в столбцах: название задачи, исполнитель, затрачено часов

или вопрос был про то, что написать в отчете, чтобы было понятно, что потраченные деньги были на что-то потрачены?

Google Docs?

Raspberry Pi 3

А документацию читать пробовали? + сортировка по сроку

Битрикс24

Ну, начнем по традиции: Система_отслеживания_ошибок

Да, такой инструмент называется темпоральные СУБД. Кстати, многие современные РСУБД имеют необходимые для этого расширения или механизмы.

Если словосочетание "правила обеспечения ссылочной целостности" не вызывает отторжения, то это они :)
D:R - delete restricted
U:R - update restricted
ну и т.д.