| Оценивать задачу всегда сложно. Постараюсь описать именно свой субъективный опыт в этом вопросе, чтобы помочь своим коллегам решить подобный вопрос. Сразу оговорюсь, у меня до сих пор не всегда получается оценивать задачи адекватно (во всяком случае не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, и только о технической оценке. Иногда по "политическим" мотивам техническую оценку необходимо уменьшить или увеличить, но данный вопрос не будем рассматривать. Также в статье не рассматривается вопрос торгов по оценке и переоценка в процессе выполнения задачи. | ||
|
В нашей работе приходиться оценивать задачи с некоторыми неизвестными факторами. Чем их больше, тем больше мозг "бунтует" и сопротивляется решению вопроса. Обычно сопротивление мозга проявляется в беспокойстве, страхах:
|
||
|
Соответственно, чтобы оценить задачу хорошо, надо исключить два вышеуказанных страха. Но сначала надо определиться, что же означает оценить задачу "хорошо". В моем понимании хорошая оценка – это ясная оценка, которую всегда можно аргументировать и которая позволяет комфортно приступить к работе (для каждого конкретного исполнителя это субъективное понятие). То есть, если заказчик или менеджер считают, что Вы оценили задачу слишком дорого, это совершенно не означает того, что задача оценена плохо. При этом, как правило, чем меньше опыта у сотрудника, тем меньшую оценку он будет давать, переоценивая свои возможности, попадаясь в ловушку первого страха – показаться некомпетентным. С точки зрения заказчика эта оценка будет хорошей. |
||
|
Хорошей оценкой в этой статье будет считаться ясная и комфортная оценка для исполнителя. |
|
Оценка задач программистом 1С предполагает следующие ключевые этапы 1) Боремся со страхами (подробнее можно прочитать ЗДЕСЬ) |
||
|
Итак, выдержка по оценки задач:
1. Прикиньте максимум и минимум затрат. Не важно, что оценки могут отличаться в разы 2. Задавайте вопросы, фиксируйте ответы 3. Прописывайте ограничения 4. Прописывайте конкретные требования 5. Разделите задачу на подзадачи 6. Скорректируйте первоначальную вилку, не стремитесь, чтобы она обязательно была узкой. Стремитесь к тому, чтобы любой пункт оценки вы смогли аргументировать 7. Не бойтесь ошибаться в оценке, если задачу целесообразно решить по отличным от "меркантильных" мотивам |
||
|
Тем, кому интересно изучить данный вопрос подробнее, советую почитать книгу Стива Макконнелла "Сколько стоит программный проект". |
||
|
Константин Вальков, руководитель отдела внедрения ООО “Кодерлайн” |
