Данная заметка написана по мотивам мышления письмом над книгой Роберта Мартина "Идеальный программист" (и на основе личного опыта). В основу легли записи из моего ZettelKasten. Данный подход отлично себя показал при переработке книги и некоторых курсов ШСМ. Это моя первая попытка оформить кусочки заметок и мыслей в осмысленный пост в рамках обучения в ШСМ.
Чем сложна оценка?
Оценка задач - частая основа противоречий между бизнесом и техническими специалистами. Проблема заключается в том, что бизнес стремится рассматривать оценку как обязательство, однако оценка является распределением вероятностей. Практический опыт технических специалистов делает распределение точнее, но уверенно попасть в цифры может быть проблематично.
Точная оценка вызывает проблемы по двум причинам:
- владение полной информацией не гарантирует попадание в сроки. Зачастую задача оказывается сложнее чем кажется, что вносит свои коррективы;
- чем точнее формируются требования, тем быстрее теряется их актуальность. Маловероятно, что за время разработки в задачу не будут внесены изменения, что сделает первоначальную оценку неверной.
Учитывая эти факторы, задача профессионала - сделать так, чтобы бизнес четко понимал риски, а для этого эти риски нужно до него донести. На базе этого часто возникают конфликты, так как разработчики и менеджеры готовы отстаивать свои интересы через конфронтацию. Не нужно этого бояться, так как через подобную коммуникацию достигается взаимоприемлемый результат.
Коммуникация практична и направлена на достижение определенных результатов, предусмотренных проектными ролями. У каждой роли есть свои интересы, а успешность выполнения задачи определяется тем, насколько роли умеют договариваться между собой. Однако не стоит забывать, что разные роли формируют разные картины мира в голове. Понимание этого поможет избежать неоднозначности в требованиях (т.н. "состояние поздней неоднозначности", когда предъявители требований уверены, что читатели требований однозначно понимают, что имеется ввиду) и сделать оценку более реальной.
Принципы профессионала при оценке задач
- профессионал обязан следить за тем, чтобы из требований к задаче исключалась неоднозначность. На примере разработки ПО этого можно достичь путем приемочного тестирования;
- чем выше ставки, тем важнее уметь говорить "нет", и тем точнее должна быть предоставляемая информация;
- нет понятия "я попытаюсь успеть". Если нет плана и не запланированы сверх усилия, то это ложь ради избежания конфронтации и сохранения лица;
- профессионал не возьмет на себя обязательства, только если нет уверенности в возможности их выполнения. На основании этих обязательств строятся планы других участников процесса
- поскольку оценка - распределение вероятностей, то имеет смысл давать три оценки - оптимистичный сценарий, оптимальный и пессимистичный;
- умение работать в команде не всегда означает, что стоит со всем соглашаться. Командная работа включает в себя способность думать о командных интересах и сообщать точную информацию о возможностях команды. Сильный лидер будет до конца защищать команду и не будет игнорировать потенциальную проблему, которая в будущем может привести к негативным последствиям для участников команды;
- худший вид непрофессионализма - попытка выдать неготовый продукт за готовый. Еще хуже, когда сама команда обманывает себя и верит в то, что в будущем недоделки будут исправлены. Это ведет к искажению существующего положения дел и в итоге готовый продукт станет сложнее поддерживать под гнетом технического долга;
- излишний оптимизм и надежда губительны для сроков. Ключевые участники должны понимать ситуацию и иметь план Б;
- для минимизации последствий сорванных сроков следует придерживаться следующих правил:
- раннее обнаружение, т.е. регулярная проверка того как движется выполнение задачи и не срываются ли сроки;
- прозрачность, т.е. участники процесса должны владеть максимально актуальной информацией.
- исходные оценки точнее оценок, вносимых под давлением. Выполнение поставленной задачи ускоряется не за счет сверхурочной работы, а путем усечения функциональности. Спешка не решает проблемы, а откладывает принятие сложных, но необходимых решений.
