Предоставлять заказчику предварительные оценки трудозатрат по проекту – штука крайне опасная. С одной стороны эти оценки могут измениться раза в полтора, а то и в два (на то они и предварительные), с другой – эти оценки могут накрепко отложиться в голове у заказчика и он будет потом ими же вас и “шантажировать”. Вечная дилемма, о которой написано достаточно много, но “серебряной пули” до сих пор никто не изобрел, ибо заказчики каждый раз разные.
Вот и сегодня заказчик попросил предоставить список функциональности на основании описания содержания проекта с предварительной оценкой трудозатрат по каждому пункту. Предварительные оценки мы с командой сделали. Я, исходя из опыта предыдущих проектов (метрики собираю уже давно) добавил процент на тестирование, стабилизацию, риски, управленческий резерв и т.д. Но всё рано, это предварительные оценки. Сейчас сижу и думаю, в каком виде для данного конкретного заказчика лучше представить предварительную оценку по трудозатратам, что бы этот конкретный заказчик осознал во всей полноте, что:
- Оценки предварительные и могут сильно измениться.
- Оценены трудозатраты в человеко-часах, а т.к. разработчики по факту не тратят все 8 часов в день на задачи проекта, то считать duration простым суммированием всех трудозатрат с последующим делением на кол-во разработчиков и на кол-во рабочих часов в месяце нельзя.
Эх, одна голова хорошо, а три лучше – пойду, всё же, посоветуюсь с коллегами =)
А вы в каком виде доставляете предварительные оценки до своих заказчиков, что бы в последующем эти оценки не сыграли против вас?
P.S. Кстати, полезная, на мой взгляд, книга о том, как можно оценивать малые и средние проекты: “Сколько стоит программный проект”, С. Макконнелл.
Вот и сегодня заказчик попросил предоставить список функциональности на основании описания содержания проекта с предварительной оценкой трудозатрат по каждому пункту. Предварительные оценки мы с командой сделали. Я, исходя из опыта предыдущих проектов (метрики собираю уже давно) добавил процент на тестирование, стабилизацию, риски, управленческий резерв и т.д. Но всё рано, это предварительные оценки. Сейчас сижу и думаю, в каком виде для данного конкретного заказчика лучше представить предварительную оценку по трудозатратам, что бы этот конкретный заказчик осознал во всей полноте, что:
- Оценки предварительные и могут сильно измениться.
- Оценены трудозатраты в человеко-часах, а т.к. разработчики по факту не тратят все 8 часов в день на задачи проекта, то считать duration простым суммированием всех трудозатрат с последующим делением на кол-во разработчиков и на кол-во рабочих часов в месяце нельзя.
Эх, одна голова хорошо, а три лучше – пойду, всё же, посоветуюсь с коллегами =)
А вы в каком виде доставляете предварительные оценки до своих заказчиков, что бы в последующем эти оценки не сыграли против вас?
P.S. Кстати, полезная, на мой взгляд, книга о том, как можно оценивать малые и средние проекты: “Сколько стоит программный проект”, С. Макконнелл.
1 комментарий:
Я научился на дурацкие вопросы давать дурацкие ответы. Если человек хочет знать, сколько будет примерно стоить труднопросчитываемая услуга, не говоря мне особой конкретики, я ему говорю очень разбросанную цифру, в минимальную назвав решение, которое ему заведомо мало, чтобы цифры он получил, а понять из них ничего не смог.
Если человек серьезный и я вижу, что речь идет не о том, что "а давайте поторгуемся" и человек действительно хочет понять уровень расходов, я ему говорю стоимость человекамесяца. Сам понимаешь, что тут ты не говоришь про разброс в тысячи, ты говоришь про разборс в единицы человек ))
Отправить комментарий