Ошибки разработчика

Человеческий фактор есть в любой области. Все люди ошибаются, и есть много факторов, которые на это влияют. Мы попробуем разобрать причины ошибок именно в IT.

Ошибка расчета

Мы уже говорили ранее, что планирование в IT - сложный процесс, потому что невозможно заранее предугадать все тонкости проекта. В связи с этим рекомендуем использовать подход, который регламентирует отклонение во времени от -40 % до +60 %.

Ошибка опыта

Есть цитата для преподавателей:

«Если вы 10 лет рассказывали один и тот же урок, значит, ваш опыт - 1 год».

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

Отрывок из статьи «Четыре ошибки программистов, которые я осознал, только когда стал CTO»

💡

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

Ошибка бизнес логики

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

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

Ошибка одноминутного решения

Эта проблема встречается во многих профессиях, но в IT она особенно заметна. Очень часто важные решения принимаются быстро, прямо во время встречи.

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

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

Поэтому для важных технических решений полезно:

• иксировать их письменно;
• давать команде время на обдумывание;
• при необходимости возвращаться к обсуждению после дополнительного анализа.