Планирование работы. Часть 1. Критерии качественного плана и оценка времени программистом

Программистов нужно заставлять планировать, по мнению многих заказчиков, и возможно, они правы, особенно если это планирование отпуска. Обобщаю, так как количество непредсказуемых вещей в проекте всегда держит в тонусе как разработчиков, так и девопсов, интеграторов, тестировщиков etc. "Oк, ставьте жесткие сроки, - отвечают технари, - но за качество мы тогда не ручаемся." В отличие от теоретических практик проектирования ПО, в реальности - полностью предсказуемый проект - мёртвый проект. Эта статья в продолжение поста какую IT-компанию выбрать и касается рабочего планирования.

Основные шаги успешного планирования:

• Чётко обозначен конечный результат
• Определены этапы работы
• Понятен предполагаемый результат каждого этапа
• Рассчитано время, необходимое для реализации каждого этапа
• Проанализированы другие рабочие процессы, которые пересекаются с обозначенными
• Проанализирован список ресурсов и наличие возможностей для выполнения этапов
• Проанализированы потенциальные риски и возможные способы их решения

Признаки качественного плана

• Развернутый (достаточно детальный и захватывающий все нужные области)
• У него есть сроки. Есть такая менеджерская аббревиатура SMART (Конкретный, измеримый, достижимый, значимый, ограниченный по времени) для планов, последнее сокращение - это как раз срок выполнения.
• Понятный. Не только исполнителю, но и постановщику задачи.
• Учитывает ресурсы.
• Учитывает риски.

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

Самое интересное для меня, когда приходишь на новое место работы - узнать как там решили проблему с тем, что программисту нужно обозначить лимитированное время, за которое он решит задачу. Если не уложится, скорее всего, начнут сдвигаться сроки у других для связанных задач и тд

Часто, зная об этом или нет, на планировании кто-то из менеджеров может озвучить желаемый для клиента срок, а ведь эта цифра очень важна психологически. Всё! Остальное будет сравниваться с первоначальной оценкой. Переработка вам обеспечена. Мне приходилось наблюдать в разных вариациях, как планировалось время и идеального решения никто не нашёл.

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

Есть ещё вариант, и он у меня вызывает смех, когда дружно садятся играть в "покер" (специальное приложение), анонимно оценивая задачу всем отделом. Потом ищется среднее арифметическое. При этом, при разном опыте работы, кого-то эта цифра приведёт в восторг, а кто-то будет серьёзно опечален. Снова переработка.

Средний уровень - это когда оценивают задачу все, а потом озвучивают, почему так. Лучше, если первым задачу оценит самый опытный разработчик, а затем остальные "вроде бы оценивая", добавят свой коэффициент, потому что со временем его можно вычислить. Потом совместно решают, кто эту задачу возьмет - с его оценкой, конечно.

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

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