Простой путь

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

Почему так происходит? Тут есть множество объяснений (включая «мир несправедлив и мы все умрем»). Я расскажу об одном из них. Оно не то чтобы полностью объясняет проблему, скорее, является одним из факторов. Этот фактор я для себя называю «простой путь».

Простой путь означает, что программист (менеджер и так далее) рассчитывает на то, что все будет просто. Он (или она; иногда даже оно) будет работать целенаправленно, ни на что не отвлекаясь, никаких проблем вида «тронул в одном месте — завалилось в другом» не будет, будет все хорошо и красиво. На самом деле, так не будет, конечно. И еще (как будто этого мало) простой путь означает, что реализован будет самый прямой сценарий. Не будет ни обработки неожиданных ситуаций (что-нибудь вроде «у пользователя внезапно не оказалось кредитной карты»), ни обработки ошибок от внешних систем, ни просто обработки ошибок (например, в середине визарда отвалилась соединение с БД; что делать, с какого шага восстанавливать работу?). А о том, что вот это все сделать тоже нужно, при оценке люди задумываются мало.

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

Что же с этим поделать? Ну, вариантов получить более адекватную оценку — масса. На эту тему книги написаны, большие такие. Например, некоторые умножают в два (три, четыре) раза оценку программиста и записывают в план эти страшные цифры. А потом следующий менеджер снова умножит на два, ага. Некоторые детально прорабатывают задачу до начала работы над ней, строят все сценарии и когда все варианты ясны — дают оценку (некоторые потом ее умножают на, скажем, полтора — на всякий случай). Есть и другие способы, они приходят с опытом и посещенными тренингами. Лично мне на данный момент милее всего оценка в попугаях.

Этот способ обычно оценки используется в Agile, в частности в Scrum. Но можно и вне Agile, кто же вам помешает-то. Задачи при таком подходе оцениваются в так называемых идеальных часах или в feature point’ах. И новые задачи мы оцениваем по сути по отношению к старым — старая задача заняла три попугая, эта чуть сложнее, ага, пусть будет пять. И так как старую задачу мы оценивали тоже по «простому пути», то и новую так же оценим. Но посмотрим, что старая заняла 3 дня, значит, эта займет 5 дней, скорее всего. Естественно, чем дольше команда работает вместе, тем оценка становится точнее. Я плоховато объясняю, хорошие объяснения с примерами есть много где, в любой методичке по Scrum как минимум.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU