Я работал на многих разнообразных проектах. Некоторые были успешны, а некоторые – нет. Как оказалось, у плохих проектов были одни и те же проблемы. Ниже приведены некоторые из них:
1. Слабое техническое руководство
Хаос и неправильные решения не способствуют улучшению качества. Хороший софт не делается по велению интуиции, хороший софт – это результат организации и принятия решений на основе фактов. Технические лидеры задают направление для остальных членов команды. Люди учатся на примерах, и технические лидеры должны выстраивать эти примеры для других.
2. Неопределенные обязанности
Люди должны знать, что им нужно делать, каковы их обязанности и что от них ждут. В противном случае, они начнут переводить стрелки и обвинять других, если что-то пошло не так.
Очень важно давать работникам задания, для которых есть определенные ожидания.
3. Отсутствие тестирования
Удивительно, но сейчас создается очень много программного обеспечения без проведения какого бы то ни было тестирования. Ни unit-тестов. Ни integration-тестов. Ни даже “Это работает у тебя на компьютере?” тестов. Код пишется (или копируется из интернета), компилируется, и отдается. Я видел, как некоторые компании проваливались из-за плачевного качества продукта, как результат отсутствия тестирования.
4. Нежелание обучаться
Никто не ждет, что каждый человек знает абсолютно всё и отлично разбирается в каждой существующей технологии, поэтому очень важно обучаться. Навыки команды разработчиков, которая не обучается, растут со скоростью наименее обученного человека в команде. Если вы готовы платить тысячи долларов в месяц за разработчика, то стоит хотя бы час или два в месяц их времени отдать на обучение по какой-либо технической теме. Это может быть тестирование, кодирование, новый язык, новая модель, в общем, всё что угодно.
Мне кажется, что такой подход с отсутствием обучения берет основу из корпоративного отношения по нежеланию инвестировать в своих людей. Кажется, что они боятся, что люди уйдут на лучшую работу, как только приобретут новые знания. Что иногда случается, но, как показывает опыт, это не такая большая проблема, как может показаться. Нежелание обучать из страха ухода сотрудников равносильно нежеланию влюбляться из страха быть обиженным. Проекты с открытым кодом также должны обучать разработчиков, будь то в форме документации, видео, либо как-либо еще. Если обучать разработчиков на open source проектах, они также будут расти и писать код лучше. Этот сценарий – беспроигрышная ситуация для обеих сторон. В реальности же я видел только пару open source проектов, которые обучали людей. И далеко не случайность, что такие проекты также стали успешными.
5. Неприятные члены команды
Некоторые люди отлично справляются с написанием кода, но при этом не могут нормально общаться с людьми. Но ПО создается людьми и для людей, поэтому важно убедиться, что команда хорошо ладит с такими неприятными членами команды. Есть две основных причины такого поведения: слабое техническое руководство (см. №1) либо выгорание на работе. Общаться с такими людьми очень сложно, но если их вычислить, то можно существенно улучшить условия тех, кто тесно с ними работает.
6. Фокусирование на краткосрочных целях
Продавливание кода без тестов для решения “частной проблемы” звучит отличной идеей в данный момент времени. Но разработчики должны видеть картину в целом: может быть, вам уже когда-либо разрешили поступить так же и на других, более масштабных задачах? Вы когда-либо работали на проектах, где раньше были тесты, а сейчас – нет? Угадайте, как так получилось?
И что же делать, если у вашего проекта одна или более таких проблем? Не паникуйте. Все можно исправить. Надо понимать, что плохой софт – это результат отсутствия контроля. Понимание и принятие того, что есть возможность что-то улучшить – это уже первый шаг к изменению проекта к лучшему.