У нас небольшая компания, пилим свой сайт, црм и подобные штуки для внутреннего использования.
А зачем вообще высокое качество кода, если его кроме своих больше никто не видит?
Это ваш первый фактор, который сильно влияет на мотивацию разработчиков. Их работа по большому счету никому не нужна.
Тестов нет, я сам вручную тестирую закрытые таски на предмет ошибок.
Дальше можно не продолжать. Отсутствие тестов - индикатор низкого уровня разработки, как результат - плохой код на выходе. Это ваша вина, как лидера группы.
Практические все закрытые разработчиками задачи содержат ошибки, причем очевидные, которые сразу бросаются в глаза при минимальном тестировании.
Очевидно для вас, неочевидно для разработчика. Реализация напрямую зависит от постановки задачи. Если вы предоставили плохое/нечеткое ТЗ, то будут косяки. Опять же ваша вина.
Разработчик должен пушить код, в котором он уверен с высокой степенью вероятности или это так и принято, что пушишь и нифига не тестируешь, типа как-то там сами тестеры разберутся?
Налицо отсутствие понимания самих принципов разработки. Ваш косяк в первую очередь, он же проецируется на подчиненных.
Что посоветуете?
По-хорошему, надо вас уволить, ибо вы некомпетентны в области разработки. Я не думаю, что вам прийдется по душе такой сценарий.
Итак, что же нужно сделать в такой ситуации.
0. Поговорить с людьми, чисто по-человечески. Объяснить, что от их работы зависит работа компании и их зарплата, премии и т.д. Внедрить понимание культуры ответственности и гордости за сделанную работу. Поощрять хорошо сделанную работу. Еще нужно уметь разбираться в психологии людей, вникать в их проблемы (дети, болезни, долгая дорога), помогать быть успешными в своей работе. Человеческое отношение творит чудеса - люди сами станут стараться делать свою работу хорошо.
1. Пересмотреть подход к постановке задач. Недаром в Agile имеется такой пункт, как сценарий использования. Это и есть ваш тест. Если разработчик выполняет сценарий и баг возникает, значит его косяк. Решается возвратом тикета на доработку. Если тестовый сценарий хоть на йоту отличается - ваш.
2. Внедрить юнит и интеграционное тестирование, как часть процесса разработки. Разработка будет в 2-3 раза дольше. Это нормально. Зато качество кода существенно улучшится и количество ошибок уменьшиться. Внедрение тестирования достаточно болезненный этап и занимает около года на перестройку мышления.
3. Следует научиться разбираться в людях. Это сложно. Есть люди, которые делают больше ошибок, чем другие. Как правило они имеют творческую натуру. Они чаще нарушают правила, делают что-то не так, как все и т.д. Вобщем чудаки по жизни. В работе такие люди создают много ошибок и сами это знают, но они не в состоянии с этим ничего сделать. Тяжелее всего таким людям дается рутинная работа. Для них это боль, для руководителя одно расстройство. Однако у этих людей есть одно качество, которое перевешивает остальные - они способны решать задачи нестандартными способами. Эти люди могут придумать нечто новое, такое, чего еще никто не делал. Такие люди, сами того не понимая, могут сделать какую-то фичу, которая будет выгодно отличать ваш продукт от конкурентов. Нельзя собирать команду сплошь из таких людей, она будет нефункциональна.
Следует проработать эти 4 пункта в описанной последовательности. Если после этого количество ошибок не уменьшится, то у вас работают лентяи. Просто нанимайте новых и увольняйте старых. Порой замена одного члена команды может привести к драматическим изменениям в настроении и отношении к работе. Поэтому будьте благоразумны в своих действиях.
Напоследок. Ошибки бывают даже при самых лучших практиках и замечательной мотивации. Это природа человеческой натуры. Не будьте чересчур строги к подчиненным.
Средний
Простой
