ТОП-5 проблем программистов: как решать?

Проблема № 1:

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

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

Решение

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

Проблема № 2:

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

Решение

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

Проблема № 3:

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

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

Решение

Профессионалы должны принимать такие ситуации и вызовы, чтобы оправдывать звание настоящего программиста!

Проблема № 4:

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

Решение

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

Проблема № 5:

программист просит выделить время на переработку своего кода и устранение дефектов, которые не видны пользователям системы
Основная цель переработки или перепроектирования (рефакторинга) кода — сделать его более эффективным и удобным в обслуживании. Это помогает снизить затраты на будущее обслуживание и поможет предотвратить новые ошибки.

Решение

Делать переработку кода медленно, но неуклонно. И при планомерной работе вы увидите, что постепенно код становится более компактным и читаемым. Люди увидят изменения, но на это требуется время.

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

Автор: Андрей Крехов - директор по специальным программам компании ICL Services.

Статья размещена на Tproger.