Реальные оценки

Возвращаясь, в очередной раз, к теме оценки сроков проектов (project estimation), я хочу поговорить не о точности, техниках и методиках оценки, а совершенно о других вещах. Я хочу поговорить о честности и смелости.

Первоначальная оценка проекта практически всегда происходит на фоне конфликта интересов. Менеджер (и в его лице вся проектная команда) заинтересован в том, чтобы все было долго и дорого. Это понятно, ведь «вес» менеджера прямо пропорционален размеру бюджета, который он осваивает. Заказчик хочет, чтобы все было быстро и дешево. Ситуации, когда разработка проекта ведется в условиях практически неограниченного бюджета, чрезвычайно редки.
Как делается оценка проекта. Сначала менеджер собирает технические оценки, которые делают программисты. Затем, он учитывает некоторые показатели, вроде размера команды, времени на обучение и отпуска и т.д. и выдает окончательную оценку.
Когда заказчик внешний, то оценка проекта, это фактически предмет торговли, со всеми вытекающими. Проект надо продать подороже, но не перегнуть палку, чтобы заказчик не ушел. Либо заказчик очень важен для компании, и необходимо начать проект любой ценой.
Когда заказчик внутренний, то обычно все еще хуже, чем с внешним. Внутренний заказчик, это чаще всего начальник менеджера или начальник начальника. Какие уж тут торги.

Вот тут самое время поговорить о честности и смелости. Ведь что часто происходит? Начинается новый проект, менеджер приносит оценки - «это можно сделать командой в восемь человек за девять месяцев». На что получает немедленный и категоричный ответ начальника: «Любой аутсорсер сделает это в два раза быстрее и в два раза меньшим количеством людей». Чем не повод поговорить о смелости и честности?
Бывает, конечно, и не так плохо. Вместо категоричного ответа можно услышать что-то вроде: «Вы знаете, что у нас ограничения по бюджету. Вот если бы вы смогли сделать это за шесть месяцев командой из шести человек, было бы здорово». В любом случае менеджер проекта (или просто программист, если проект маленький) испытывает на этом этапе очень сильное давление со стороны начальства, заказчика, отдела продаж, и т.д.

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

Существует и другой путь, под девизом «Главное начать. А потом они никуда не денутся». Есть мнение, что следует соглашаться на сокращение предварительных оценок, чтобы склонить руководство или заказчика к тому, чтобы начать проект. После того как проект будет начат и в него будут вложены определенные средства, то им придется довести его до конца, несмотря на перенос сроков. А объективные причины, объясняющие причины сдвига сроков мы всегда найдем. Надо сказать, что это весьма и весьма распространенный подход. Это путь смелый, но не честный, и надо сказать весьма рискованный. Соглашаясь сделать проект на $250 000, отчетливо сознавая, что потребуется не менее $500 000, вы подставляете человека, принимающего решение о старте проекта (будь то ваш начальник или представитель заказчика) на серьезную сумму, и если по результатам проекта вам придется всего лишь расстаться с работой - это можно считать довольно легким исходом.

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

Ну, и наконец, можно поступить честно и смело. Не поддаваться давлению, сказать все, что вы думаете своему начальнику и уйти, хлопнув дверью. И честно, и смело, и…. непрофессионально.

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

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

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

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

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