Pull to refresh

Comments 8

Глупости всё это. У меня вот изначальная оценка — на покраску требуется 1-2 рабочие недели, и сейчас я объясню почему:
1 день — закупаем материалы. Идем в магазин и видим, как муж с женой ругаются из-за оттенка (1-1,5 часа), а также из-за того, должна ли быть краска водостойкой и нужно ли покрасить еще потолок. После этого муж сдается, и жена закупает еще кучу всякой мелочевки, нужной для ремонта. Все приходят домой, пьют чай.
2 день — отодвигаем мебель и нежно накрываем её газетами или чем-нибудь ещё. В процессе из шкафов достаются вещи и делается попытка их разобрать и выкинуть (не)нужное, сопровождающаяся руганью мужа и жены. Занимает весь день. Особо упорные/опытные в этот же день пытаются сделать прототип, т.е. смешать краску и попробовать что-то на небольшом клочке стены, но это как пойдет.
3 день — собственно, грунтовка+покраска. С перерывом на чай.
4 день — находятся шероховатости и желание что-то переделать. Мазок там некрасиво лег, и так далее. Сначала правки вносятся под чутким руководством жены, потом приходит муж и говорит, почему это неправильно. Чай и очередное обсуждение в духе «А я вижу так» и «А ты кто такой?».
5 день — задвигаем обратно мебель. Муж с женой пытаются внести очередные правки, но сил больше нет, и им указывают на увеличение бюджета («только за дополнительные деньги!»). После очередных разборок производится оплата, недовольные стороны наконец-то расходятся.

При недостаточной мотивации сторон вышеуказанные процессы могут растянуться еще на несколько рабочих дней.
Вы уложились в последнюю формулу.
Если же серьезно: у вас чувствуется опыт, которого обычно не хватает.
Тоже сразу подумал про неделю.
Я даже не пытался давать начальную оценку дочитав до места где её попросили выдать. Всегда, перед тем как дать срок хоть немного отличимый от «бесконечно долго», я стараюсь уточнить как можно больше деталей выполнения задачи. И вот на этом этапе и возникают проблемы. Мои исходные требования из реальной жизни выглядят так:
1. Комната большая?
— Самая обычная комната.
— А её размеры, хотя бы примерно?
— Вы что, не знаете какого размера бывают «обычные комнаты»?
2. У вас уже есть материалы для покраски?
— Нет.
3. В комнате много мебели? А дверей, окон и дрегих штук, которые надо исключить из процесса покраски?
— А в комнатах бывают двери и окна?
— Обычно да.
— Мы не знаем, но наверное как в обычных комнатах, вы же специалист по комнатам, должны сами знать!
4. Какого цвета комната сейчас, и в какой цвет её будут красить?
— Сейчас комната синяя, покрасить мы её хотим в круглый цвет!
И уже на этом этапе от меня требуют оценку. Хотя бы «примерную». Ни на какой сбор требований перед оценкой, времени не дают. Оценку хотят услышать здесь и сейчас. Требования будут уточняться в процессе работы. И даже если собрать все требования в кучу, и выставить действительно реалистичный срок, менеджеры в середине работы прибегут с криком: «Ой! Нам нужен не круглый, а квадратный цвет!», на все протесты и требования сдвинуть сроки я слышу только «Ну вы же Agile! Вы должны быть гибкими».
Много времени и сил было положено на то, чтобы переломить эту систему. Правда, потом начали пытаться вводить метрики, и примерное время выполнения покраски типовой комнаты, оценивать по времени замены типовой водопроводной трубы. Но это уже совсем другая история.
Наиболее опытные из моих коллег в таких случаях на вопрос ПМа «прошу оценить трудоёмкость и сроки» отвечают: «на оценку трудоёмкости потребуется 2ч.д, приступить смогу на следующей неделе.»
Судя по формуле, задачи со сроком выполнения меньше 1 надо отдавать неопытным командам.
Оценка времени выполнения плана, полученная методом суммирования продолжительности элементарных операций, всегда будет иметь очень большую погрешность из-за накопления ошибки и неправильного учёта факторов. Гораздо перспективнее вспоминать или хотя бы искать в чужой практике, приблизительный аналог проекта в целом, и от него отталкиваться.
Я оцениваю следующим образом (ну и не только я): [чистая работа в часах]*2 или на 3 (смотря на возможность увеличить время или нет по возможности). Если нельзя на 3 умножать, т к на такой срок не пойдет Заказчик, то к формуле прибавить еще небольшой статический коэффициент в рабочих днях. И это работает. Умножение на 2 служит на всякий-кто-то заболеет, что-то недоучли и прочее-прочее. В основном конечно буфер-это человеческий фактор, если опыт в данной или похожей работе уже был. А если не было опыта, то еще нужно заложить риск с переносом выполненых работ с демостенда на живую систему (новые технологии были неправильно поняты кем-то из разработчиков или внедренцев). Изучение новых технологий (как и настройка демостенда) обычно у нас протекает еще до подписания договора, т к это полезно коллективу для саморазвития. И даже если Заказчик откажется-можно продать потом-использовать как рекламу+есть знания. Но таких случаев было всего 2 у нас.
Sign up to leave a comment.

Articles