Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 14 267 веб-студий, 977 CMS, 250 567 сайтов.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Как делать быстрые и точные оценки сроков разработки проектов

Всем привет. Меня зовут Владимир Завертайлов, я — руководитель студии интернет-решений «Сибирикс».

Часто ли вам приходится отвечать на вопрос «Сколько стоит сайт?»? Как много наводящих вопросов вы задаете, чтобы прийти к какой-то сумме и озвучить ее? Нужно ли ее озвучивать, если не ясны детали ТЗ? Что делать с потоком заявок — оценивать каждое ТЗ индивидуально или использовать шаблонные оценки? Довольны ли разработчики заложенными сроками, а клиенты — суммой бюджета?

Практика подсказывает, что не все так просто при оценке. Чтобы сделать четкую и адекватную оценку любого проекта, требуется довольно много времени квалифицированного специалиста, которое не факт, что будет оплачено. Приведу пример: около года назад у нас уходило около четырех рабочих часов в день у двух квалифицированных разработчиков, чтобы выполнить оценки по всем приходящим заявкам. Это нагоняло тоску, и мы решили исправить ситуацию.

Сегодня, при возросшем объеме заявок, трудозатраты на оценки составляют около 20 минут в день, причем большую часть из них делают менеджеры проектов (не технические специалисты), при этом точность значительно выросла. И сегодня я бы хотел рассказать о простых и эффективных методах, которые мы применяем каждый день:

1. Самый простой и правильный способ сделать оценку — это не делать ее. Звучит странно? — Но работает. Нужно напрямую выяснить бюджет проекта у клиента.

Почему это может сработать?

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

Во-вторых, при этом может оказаться, что бюджет у клиента значительно ниже того, что вы обычно берете за такого рода проекты. Тут нам на помощь приходит всем известный принцип Парето — 80/20. Суть в том, что основные полезные, нужные и приносящие прибыль функции проекта составляют, как правило, около 20% (правда, есть лидер по невостребованным функциям - программа MS Excel, где постоянно используется около 4%). Зная этот принцип, вы должны обсудить бизнес клиента, помочь ему определить, какие функции для него будут ключевым и принесут максимальную отдачу, и при этом вам, скорее всего, удастся вписаться в бюджет.

Почему это может не сработать? По разным причинам. Довольно распространенная — клиент просто мониторит рынок и ищет самую низкую цену (у вас когда-нибудь просили сделать скидку от цены, которую вы назвали как “ОТ”, и причем с потолка?).

2. Второй способ подойдет для быстрой, но неточной оценки толстых фолиантов ТЗ или какой-то рутинной работы. В качестве метрики будет использоваться... ScrollBar. В чем смысл? — Допустим, вам прислали материалы для набивки каталога товаров, несколько сотен листов в Word и пачку неотсортированных фотографий. С ходу понять, сколько займет времени вбить этот каталог, довольно сложно. Берем, начинаем вносить товары, и замеряем время. Вбили несколько штук - по тому, как сместился scroll-бар в документе, примерно видим наш прогресс (в процентах). Дальше - дело техники, перемножить два числа.

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

3. Третий способ подойдет для быстрой оценки коротких ТЗ, в которых просто перечислены основные функции. Все просто: надо представить каждую функцию проекта, как она будет работать, и одеть на нее «майку» размера S, M, ну или L.

Таким образом сразу наглядно виден ее приблизительный «вес». Тут нет нужды в точности (не нужно одевать полмайки или четверть майки). Сколько каждая маечка будет занимать часов - это уже дело опыта оценщика. Оценки будут заведомо не очень точные. Зато очень быстро можно сделать предварительную оценку для очень большого списка функций.

4. Очень хороший способ сделать оценку - “Planning Poker”. Команда, которая будет работать непосредственно над проектом, собирается вместе и начинает обсуждать каждую фичу проекта. Каждому члену команды выдается набор из 13 карт разного номинала. После того как ведущий объяснил, как должна работать конкретная фича, все члены команды должны положить карты со своими оценками рубашкой вверх. После этого карты вскрываются.

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

Цифры на картах , в зависимости от обстоятельств, могут означать часы, дни или «Story point». При оценке в «Story point» мы выбираем самую маленькую фичу в проекте и считаем ее эталоном. Все остальные фичи оцениваются относительно выбранной.

В колоде кроме цифр есть специальные карты - “перерыв на кофе/пиво“, “???” (используется новыми разработчиками, которые затрудняются дать оценку), “0” (если фича готова или делается за минуту).

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

Я рекомендую всегда делать оценки сроков по всем проектам, неважно, по внутренним проектам студии или проектам для заказчика - какими бы маленькими они не казались. (Зачем? про это можно почитать и посмотреть в нашем блоге или погуглить по запросу “Закон Паркинсона”).

Мы применяем все четыре способа (не оцениваем, скролл-бар, майки и покер - в зависимости от ситуации), и они дают прекрасные результаты. С опытом команды скорость и точность выполнения оценок возрастают. Надеюсь, эти способы помогут и вам.

Я желаю успехов Вам и вашему бизнесу, с удовольствием отвечу на любые каверзные вопросы здесь или по e-mail: vladimir.zavertaylov@sibirix.ru

Автор: Владимир Завертайлов, Сибирикс (Генеральный директор)

Комментарии (Facebook)

Комментарии (13)


CMS Magazine CMS Magazine
Реклама
RSS-подписка
CMS Magazine CMS Magazine
CMS Magazine