Philipp

1. Нанимаете команду в штат на зарплату.
2. Знакомите его со старым исполнителем.
3. Обеспечиваете задачами, чтобы приработались вместе, месяца 3-4.
4. Делаете нормальный официальный хостинг на юр.лицо.
5. Переводите сайт с хостинга старого исполнителя на свой.
6. Разрываете контракт со старым исполнителем по поводу очередной отсрочки или отмазки.

Съэкономить на программисте больше не получится. Делайте выводы.

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

А зачем вообще высокое качество кода, если его кроме своих больше никто не видит?
Это ваш первый фактор, который сильно влияет на мотивацию разработчиков. Их работа по большому счету никому не нужна.

Тестов нет, я сам вручную тестирую закрытые таски на предмет ошибок.

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

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

Очевидно для вас, неочевидно для разработчика. Реализация напрямую зависит от постановки задачи. Если вы предоставили плохое/нечеткое ТЗ, то будут косяки. Опять же ваша вина.

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

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

Что посоветуете?

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

Итак, что же нужно сделать в такой ситуации.

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

1. Пересмотреть подход к постановке задач. Недаром в Agile имеется такой пункт, как сценарий использования. Это и есть ваш тест. Если разработчик выполняет сценарий и баг возникает, значит его косяк. Решается возвратом тикета на доработку. Если тестовый сценарий хоть на йоту отличается - ваш.

2. Внедрить юнит и интеграционное тестирование, как часть процесса разработки. Разработка будет в 2-3 раза дольше. Это нормально. Зато качество кода существенно улучшится и количество ошибок уменьшиться. Внедрение тестирования достаточно болезненный этап и занимает около года на перестройку мышления.

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

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

Напоследок. Ошибки бывают даже при самых лучших практиках и замечательной мотивации. Это природа человеческой натуры. Не будьте чересчур строги к подчиненным.

Разработчики черпают информацию из нескольких основных принципов

• декомпозиция - разбиение больших частей на составные части. Например: нужно сделать гостевую книгу. В гостевой книге есть страница, которая отображает записи и есть та, через которую они добавляются. Т.е. первый уровень декомпозиции - страница отобразить записи и страница добавить запись. Далее каждая страница бьется дальше. Например отображение - где-то надо записи хранить, значит у нас будет база данных, как-то отображать, значит будет какой-то шаблон для страницы. Раз записи повторяются, то у всех записей будет одинаковый шаблон отображения. Данный принцип применятся до тех пор, пока не достигается конечная глубина, после которой становится очевидна тривиальность реализации. Если представить все эти шаги разбиений в виде дерева - мы получим дерево декомпозиции.
  
• системный подход - когда будущее приложение разбивается на подсистемы (это как декомпозиция, но с другой стороны), например подстема отображения записей, подсистема хранения записей и т.д.
  

Приведенные выше принципы результат последовательного изучения информатики, программирования и проектирования систем. Каждый разработчик проходит через стадии, на которых он не знает, как реализовать или решить ту или иную проблему, поэтому он всегда находится в непрерывном изучении, как технологий, языков программирования, так и подходов к разработке, и, помимо этого, он изучает предметную область.
Имея разносторонний набор знаний человек прибегает к синтезу, в результате которого появляется некоторое обобщенное представление решения той или иной задачи. Как правило этот синтез является неопосредованным актом интеллектуальной деятельности (тупо человек не думает особо, а решение всплывает как бы само собой). Хотя на самом деле это результат высшей интеллектуальной деятельности.
Чтобы перейти от "я не могу это сделать" к "я справился" необходимо изучить опыт других людей, решавших подобные проблемы в прошлом и ознакомиться с тем, что они изучали - какие книги читали, какие науки постигали, курсы или обучение в университете (колледже). Не следует пренебрегать формальным обучением, оно закладывает базу, с котором можно развиваться впоследствии.
Обучение помогает приобрести некоторый опыт в решении задач и сформировать подходы к их решению.
После обучения следуют начинать работать по специальности, не перебирать места, а идти в любое место и набираться опыта. Опыт поможет сформировать представление о реальном положении вещей и том, как правильно применять полученные знания на практике. В общем, чем больше вы работаете, тем больше решений прийдется создать и тем более сложные задачи вы сможете решать.
Не стремитесь сразу браться за сложные задачи, начните с простых, тех, которые как вам кажется, вы сможете решить. И работайте.
Все приходит постепенно. Просто нужно движение. Учитесь, пробуйте применять изученное. И так по кругу. А потом сами не заметите, как спрогрессируете.

Существует понятие цикла релизов. Каждый цикл подразумевает детерменированное количество изменений внесенных в продукт.
Для каждого релиза объявляется набор интерфейсов между компонентами. В разных проектах это реализуется по-разному, например в веб используются инструменты вроде Swagger.
Есть архитектор, который отвечает за общий интерфейс. Он объявляет версию, например 1.0.5. Бэкенд и фронт-энд пилятся под соответствующую версию интерфейса. Если одна команда не успевает, происходит релиз 1.0.4, т.е. то, что готово или релиз откладывается.
Обычно может быть объявлено несколько версий интерфейса.
В больших и сложных проектах используется модульный подход. Каждая команда отвечает за свой компонент проекта и имеется координатор проекта. Он отвечает за релиз. В любом случае подготовленный релиз проходит через команду тестировщиков и т.д. Просто так сырой код в продакшен не попадает.

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

Есть проект, называется Fogbugz
www.fogcreek.com/fogbugz
В нем можно ставить задачи и указывать время их исполнения. Он собирает информацию и потом может выдавать предсказание о времени выполнения задачи.
По опыту могу вам посоветовать, если вам кажется, что задача займет пару часов, а заказчику скажите 4 или 6. В систему вводите свое собственное время. Через пару месяцев у вас появится некоторая картина вашей скорости.
На мой взгляд лучше срок немного увеличить, чем сделать не вовремя. Вообще это приходит с опытом, но все равно очень сложно оценивать время выполнения. Лично я стараюсь узнать о задаче максимум до начала ее выполнения или представления оценки заказчику.
Что еще можно сказать - не переживайте сильно по поводу оценки времени. Все ошибаются, даже специалисты с 10-20 летним стажем.
Есть еще немного другой подход - непрерывная разработка, в которой нужно ставить оценки времени, но необязательно их соблюдать. Т.е. оценку разработчик делает сам для себя. Что-то вроде личного мотиватора, не более того.