Оценка по времени, тестирование, ошибки, отношение и ожидания, принятие решений и ответственности

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

Сама дата крайнего срока без указания времени может трактоваться по-разному: может подразумеваться, что задача должна быть выполнена в любое время в течение указанного дня, или не позже следующего дня (пусть и поздно вечером); или днем, чтобы результат можно было показать клиенту в течение его рабочего дня.

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

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

Ни одна задача не принимается в работу без ее оценки по времени и его согласования

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

Эксель отлично подходит для составления списка задач и оценки по времени. Копите и корректируйте историю своих оценок.

Резерв времени согласно истории прошлых оценок или на форс-мажор

При оценке задачи разработчик вправе добавит ко времени немного, чтобы увеличить шанс выполнения задачи в срок. Добавление 20% сейчас кажется приемлемой величиной. Если есть желание добавить больше, то это может означать, что первоначальная оценка неверная.

Если для выполнения задачи требуется помощь другого специалиста, объявите об этом сразу

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

Планирование занимает время

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

Тестирование своего кода — неотъемлемая часть разработки

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

Менеджер — не бета-тестер. Просьб типа «проверяй» быть не должно. Менеджер должен быть уверен в результате не смотря. Решение о закрытии задачи изначально принимает разработчик, менеджер с ним соглашается или не, уточняя требования.

Несферический конь

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

Это относится и серверной и к клиентской разработке.

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

Анализ

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

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

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

Тестирование законченного решения перед сдачей клиенту

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