Комментарии 13
Зачастую (по моей практике) разработчики мечтают создать красивого журавля в небе и приходится их заземлять, что бы начать с синицы в руках, то бишь MVP.
Причём этим страдает и непосредственный заказчик проекта, который боится, что после запуска MVP его хотелки идеи и фантазии отойдут на дальний план backlog-а.
Так что приходится заземлять оье стороны, что бы что-то практичное всё-таки вылупилось и зажило своей жизнью.
Очень просто это решается. Торговаться о сроках можно и нужно, особенно если это объективно требуется бизнесом. Но только за счёт урезания какого то функционала, что естественно должно быть озвучено и согласовано. Тогда у бизнеса будет понимание, что их интересы по срокам учитываются и не будет ощущения, что кого то дезинформировали на этапе первоначальной оценки.
Более того, отмечу, что торговаться - это нормальная часть рабочего процесса. Бизнес вполне разумно хочет быстрее и дешевле, а разработчики как эксперты могут помочь с оценкой сроков каждой подфичи внутри фичи и тем самым в процессе диалога с бизнесом помочь расставить приоритет. Если оценить, что одну фунцию можно сделать за три дня, а другую за две недели, то у бизнеса появляется понимание как выбирать меню.
Здесь, на мой взгляд, есть два принципиально разных подхода. Первый, условно, заказная разработка: там есть место и торговле, и уступкам и т. п., короче говоря, разработка и заказчик по разные стороны. Второй вариант — когда заказчик и разработка "в одной лодке" и в конечном счёте ищут оптимальное по времени и качеству решение общих задач.
Да ладно, человечество методики придумало еще задолго до появления первых компьютеров, да что компьютеров, до счетных палочек. Классический восточный базар - хочешь продать сделать фичу за месяц - заряжай полгода, клиент поторгуется и выторгует месяца три, уйдет со встречи довольный с ощущением своей победы, а у тебя будет в три раза больше времени на то что-бы спокойно без горящей жопы все написать и отладить.
Сейчас, мне тут, конечно, начнут топить за космические корабли, бороздящие просторы Большого Театра, минусов накидают полную панамку, но по чесноку - кто так не делал или не делает вот прямо сейчас?
всегда кидаю x2 от оценки. если что-то пойдет не так, то буфер поможет.
Добавив 2 недели к положенному по графику сроку на непредвиденные задержки, добавьте еще 2 недели на непредвиденность самих непредвиденных задержек... (Из свода законов Мэрфи)
Проблема этой методики в том, что риски — вещь вероятностная. Соответственно, если вы разобъёте задачу на этапы, а потом добьёте срок выполнения каждого этапа до вероятности в 2 девятки (99%), то срок будет избыточно длинный + какой-то этап попадёт в оставшийся 1%, и не уложится и в этот срок.
См. DeMarco "Waltzing with bears".
Риск может быть и вероятностная вещь, но оценить его точно можно очень редко, математика тут практически не работает. Это не с броском монетки, где можно математически точно рассчитать риск выпадения орла, тут все как ни крути упирается в экспертную оценку, т.е. в субъективное. А эксперт, как человек, всегда ошибается. Причем даже у очень профессионального и честного человека, ошибка может достигать огромных значений, просто по причине того, что в задачах разработки часто попадается очень большая неопределенность, которую сложно адекватно учесть.
Потому и говорю - точно закладываются обычно когда имеют дело с чем-то тривиальным, где неопределенность минимальна. Чаще всего делают хороший запас, и то даже с ним бывает ошибаются и сроки плывут в сторону увеличения.
Требовать от разработчиков урезать сроки – всё равно что торговаться с метеорологом о погоде