Почему некоторые проекты никогда не появятся в портфолио, а об их разработке вы никогда не напишите кейс? Называем основные причины появления на рынке некачественных программных продуктов.

Каждая IT-компания сталкивается с проблемами и сложностями в разработке: вы работаете сверхурочно, укладываетесь в дедлайны, а на выходе получается проект, которым не то что гордиться трудно — его не хочется упоминать вслух. Наша команда не исключение.

Мы адаптировали статью тимлида команды Yelluw про основные грабли и проблемы, влияющие на появление плохого программного продукта на рынке.

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

weak-leaderСлабое в техническом плане руководство

Лишенные последовательности и неверные решения никогда не перерастают в качество. Хорошие проекты никогда не пишутся инстинктивно. Это результат организованных и основанных на фактах решениях. Сильный руководитель задает тон остальным сотрудникам. Все люди учатся на примерах.

Нечеткие обязанности

Работникам необходимо ясно понимать, что они должны делать. Четко поставленная задача — прямая обязанность руководства. В противном случае они будут перекладывать вину друг на друга, когда начнут ошибаться. Важно не только предоставить им возможность делать «крутые вещи», но и сформулировать условия достижения целей.

lack-of-testingОтсутствие тестирования

Сегодня большое количество проектов пишется без последующего выполнения тестов. Никаких юнит-тестов. Никаких тестов по интеграции. Даже никаких «как это будет работать на машине заказчика"-тестов. Код просто пишется (копируется с Гита), компилится и выдается клиентам.

Нежелание учиться

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

time-goalsСотрудники-мудаки

Бывает, что работник пишет крутой код, но ужасно обзается с коллегами. Но проекты делаются людьми для людей, поэтому следует позаботиться, чтобы такой человек не причинил вреда остальной команде. Иногда мудаками становятся, когда руководство не демонстрирует должного авторитета (см. п. 1).

Ориентированность на краткосрочные цели

Возможно, сдать проект, не выполнив всех надлежащих тестов, покажется хорошей идеей для решения «частного случая», но разработчики должны видеть общую картину. Получая на выходе хороший продукт, вы создаёте почву, на которой другие смогут выдавать годные вещи. Нам приходилось браться за проект, в котором предыдущие разработчики даже не удосужились проверить, как будет вести себя программа с большими объемами данных, что в итоге сильно замедляло её работу.

Нашли в своем проекте схожие черты? Без паники. Важно понимать, что плохой продукт является результатом, который находится в пределах вашего контроля. Знать и принимать такое положение вещей — первый шаг к изменениям в работе компании.

Перевод статьи: https://dev.to/yelluw/how-bad-software-gets-made

* Обязательные поля
Как получается плохой софт
Средняя оценка 5 Проголосовало 3