Комментарии 5
А у меня для быстрой оценки времени калькулятор есть :P
Вот что получается для 3-х задач, каждая из которых оценивается в 1 час наименьшего времени, 2 часа обычно и 5 часов наихудшего случая.
Правда, это не спасает от случая "прилетело обновление, в результате работа встала".
Пора бы уже давно всем отвечать на слова "сколько займет работа?" или "оцени задачу" - задача займет столько сколько займет, т.е по факту с промежуточными результатами.
Если бы все из IT сферы ит.п придерживались этого правила, то не было бы этих ненормальных дедлайнов и горе руководителей/клиентов, которые начинают охать и ахать если говоришь им что задача займет например 10 часов, а у них видите ли "опыт" и вообще их сосед по лестничной клетке Вася эту задачу в течение часа за бутылку водки сделает и еще туалет прочистит параллельно, а не вы который 10 часов делаете и 300$ хотите...
Спасибо вам за интересное мнение! Хотелось бы немного порассуждать на эту тему.
Прежде всего, я считаю, что отсутствие сроков может негативно сказаться на проекте, приводя к постоянным доработкам, желанию добавить новый функционал или дополировать уже готовый и, в результате, к бесконечному растягиванию времени выполнения проекта. Как мне кажется, сроки устанавливают определенные рамки, в которые необходимо вписываться, и помогают избежать бесконечных доработок.
Из этого вытекает следующий важный момент. Чем дольше проект находится в работе, тем выше вероятность, что он утратит свою актуальность, станет ненужным и не будет соответствовать быстро развивающимся технологиям.
Также мне кажется, что отсутствие предварительных сроков сильно ограничивает возможность планирования. Как для заказчика, который хочет знать, когда получит готовый продукт, и спланировать дальнейшие действия. Так и для исполнителя, который может работать над несколькими проектами, каждый из которых требует грамотного планирования и внимания. Еще оценка помогает определить приблизительные затраты на проект (если это не фикс прайс, конечно). На мой взгляд, для заказчика важно иметь представление о приблизительной стоимости проекта. Без возможности спланировать сразу и время, и приблизительный бюджет проекта заказчику будет трудновато.
Как вы верно отметили, у некоторых клиентов могут быть слишком оптимистичные и завышенные ожидания, поскольку они не всегда осознают объем работы. По моему мнению, если мы не будем занижать эти ожидания в процессе обсуждения проекта, существует бóльшая вероятность столкнуться с тем, что заказчика не устроит скорость работы. В таком случае, часть работы будет проделана, а оставшаяся часть будет доделываться с большим напряжением из-за обманутых ожиданий. Объясняя оценку и занижая ожидания, мы заранее готовим заказчика к реальному времени выполнения проекта, он ментально настраивается на это и это помогает избежать неправильных представлений о сроках и разочарований.
Ну и наконец, как мне кажется, важно помнить, что это заказчик обращается за услугой, а не наоборот. Если бы я, как клиент, обратилась за услугой в другой сфере и по срокам мне бы ответили: "Будет готово, когда мы закончим", я вряд ли бы стала обращаться снова к этому исполнителю. Всё-таки в наших интересах установить хорошие отношения с клиентом, оправдать его ожидания и принести пользу.
“Если бы все из IT сферы ит.п придерживались этого правила, то не было бы этих ненормальных дедлайнов и горе руководителей/клиентов”. На мой взгляд, горе руководители всегда найдут, над чем охать и ахать. Опять же это ответственность исполнителя установить контакт с клиентом, создать комфортный процесс работы и сделать все возможное, чтобы не допустить для себя “ненормальных дедлайнов” и жуткого стресса. В конце концов, если уже на первоначальном этапе не удается установить нормальный диалог с клиентом, можно отказаться от совместной работы.
Было бы крайне интересно узнать ваше мнение относительно этих рассуждений:)
Когда оплата работы? - Когда продадим продукт, тогда и заплатим.
И ещё закон Паркинсона в помощь всем "когда готово, тогда готово".
У автора хорошее замечание, что вряд-ли мы сами готовы обращаться за услугой к таким исполнителям.
Как оценивать задачи и подружиться с дедлайнами