Как я должен знать, сколько дней что-то займет? [закрыто]

Прошлый опыт и исторические данные часто лучше всего подходят для получения оценок. Если вы имели дело с аналогичным кодом / проблемами до того, как использовать исторические данные для прогнозирования будущих задач. Конечно, если вы имеете дело с чем-то новым или совершенно неизвестным, дать точные оценки сложнее. Конечно, это «оценки», которые представляют собой обоснованное предположение о том, когда что-то будет сделано.

Оценить время сложно.

Но времена, когда я делал это хорошо, у всех есть пара вещей:

1.) Я получил очень хорошо и полные требования к проекту. Это важно, и вы должны задавать сложные вопросы, чтобы убедиться, что требования действительно максимально полны.

2.) Я разбил проект на разделы, записал каждый раздел на белой доске, а затем оценил время для доработки по каждому разделу индивидуально. Я попросил остальную часть моей команды внести свой вклад, так что я ничего не забываю. Это кажется таким простым, но работает так хорошо. Я думаю, это позволяет вам быть более реалистичным, уменьшая возможность пропустить часть проекта, может отнять много времени. Если вы сможете записать и спланировать проект на таком детальном уровне, как этот, это очень поможет.

В течение всего этого процесса оценки вы даже можете лучше понять проект и то, что необходимо сделать. Это может предотвратить ошибки, написание и переписывание кода и т. Д. И это хорошо для всех.

Я обычно говорю, что это займет в 3-4 раза больше времени, чем я думаю. Например, если я знаю, что могу построить что-то за два дня, я скажу неделю или около того.

Таким образом, если вы закончите намного быстрее предполагаемого времени, вы будете выглядеть как герой! : P

Если можете, найдите другую работу. Ваш босс, похоже, не имеет никакого представления об управлении проектами, управлении ресурсами и разработке программного обеспечения.

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

Некоторые мысли об оценке:

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

Лучший совет Я могу разбить задачу на более мелкие части, а затем оценить их. Возможно, приложите процент «уверенности» к каждой подзадаче, чтобы рассчитать оптимистичный и пессимистический диапазон. Таким образом, когда ваш начальник говорит: «5-8 дней? Это мне совсем не помогает, откуда вы такие цифры!?!?» вы просто показываете ему свою неудачу, и у вас есть оправдание. Компетентный менеджер должен поставить на карту вашу задницу за то, что вы делаете, а не за то, что вы отклоняете, чтобы заставить вас сделать это.

Существует также разница между

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

Об оценке времени, необходимого для выполнения чего-либо:

• когда вы делаете что-то в первый раз, трудно представить себе, сколько времени потребуется, чтобы это сделать
• но со временем вы будете делать все больше и больше разных вещей; и каждый раз вы будете вспоминать, сколько времени вам потребовалось.

Через некоторое время, когда вас спросят: «Сколько времени вам понадобится на это?», вы сможете подумать:

• «что "очень похоже на то, что я сделал в проекте X, и на то, что еще я сделал в проекте Y
• , я потратил 8 дней, делая это в проекте X, и 6 дней на проекте Y; но с Y это было намного проще, потому что я уже имел некоторое представление о том, как это сделать (уже сделал это на X)
• , поэтому в этом новом проекте это не займет больше времени, чем в проекте Y
• на самом деле, сейчас я даже лучше, более опытен ... Так что это должно занять около 5 дней
• , и чтобы не слишком сильно давить на себя, и сохранить некоторую погрешность, вы скажете 6 дней или 6 дней и половину вашему боссу.
• и в его голове он добавит еще один день ^^ (или, если он из тех, кто считает 4, когда слышит 6, просто скажите ему 8, и он поймешь 6 ^^)

Со временем ты будешь становиться все лучше и лучше в этом; и, в конце концов, вы, вероятно, сможете:

• и это, как для опытного разработчика,
• , так и для новичка
• или только для одного конкретного человека

Хо, и я забыл: я обычно добавляю около 15% «времени разработки» для тесты и исправления ошибок, кстати - это стандартная ставка для проектов, над которыми я работал, и в целом довольно точная (конечно, для новичка, который, вероятно, создаст больше ошибок, вы добавите еще немного; для опытного разработчика немного меньше) .

Да, конечно, иногда вы совершенно ошибаетесь; Бывает, вот и все: все время от времени делают ошибки: -)

О задержке: ну, я обычно говорю своему боссу, что «у меня должно пройти X дней, если мне не придется делать что-то еще»; тогда, если мой босс говорит мне сделать что-то еще в течение 2 дней в середине моей задачи, это «его вина»
В проекте, над которым я работал некоторое время назад, я говорил клиенту: «Мне нужно 5 дней, чтобы сделать это, но, учитывая, что я обычно трачу половину своего времени на то, что не запланировано, давайте предположим, что это займет у меня 10 дней. всего дней "- через некоторое время привыкаешь так считать ^^

• Просят процитировать в дней - это смешно, лучшее, что вы можете сделать, - это оценить.
• Старайтесь любой ценой избежать принуждения к прямым предположениям, вы почти наверняка ошибетесь. Всегда лучше потратить некоторое время, чтобы сделать более точную оценку.
• Если вы имеете дело с изменением или взаимодействием с каким-то кодом, с которым у вас нет предыдущего опыта, то попробуйте дать оценку того, сколько времени потребуется, чтобы отработать как делать то, что вам нужно, а затем вернуться к ним, когда вы будете более точно знать, что вам нужно делать, с оценкой того, сколько времени.
• То же самое касается того, что вы никогда не делали раньше. , вы, вероятно, добьетесь успеха раньше, если проведете небольшое исследование того, как подобные проблемы были решены другими.
• Разбейте свои задачи на более мелкие части (как можно меньшие) для более точной оценки. Таким образом, вы можете сказать что-то вроде: «Я думаю, что A, B и C займут в общей сложности около 6 дней, но D - это то, что мне нужно будет посмотреть». Это звучит намного лучше, чем «Понятия не имею» или «столько времени, сколько потребуется».
• Вы не можете оценить время, которое потребуется, чтобы найти ошибку. Вы можете оценить, сколько времени потребуется, чтобы исправить это. На обнаружение и исправление серьезной ошибки может уйти 2-3 дня. Ошибки в уже доставленном коде отнимут у вас время на последующие разработки.
• Всегда сообщайте им, когда вы сталкиваетесь с проблемой, из-за которой ваш крайний срок сдвигается намного раньше вашего крайнего срока. Таким образом, ваш босс будет предупрежден, когда будет разговаривать со своим боссом / клиентом.
• Если вы переоцениваете и достаточно удачливы, чтобы иметь дополнительное время, либо протестируйте его еще раз, либо используйте время, чтобы разработать что-то еще, что будет полезно для вас.
• Если вас постоянно заставляют соглашаться с произвольными сроками, постоянно преследуют или вы чувствуете, что ваши объяснения получаются так, как будто они являются чистой ложью, тогда спокойно начните искать другую работу в фирме, которая разбирается в управлении проектами программного обеспечения, прежде чем вы здоровье неизбежно страдает.

Более точные оценки основываются на опыте.

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

Следуйте своей догадке и добавьте 50% времени. Вы уложитесь в сроки, не будете нервничать, ваш босс увидит качественный код вместо быстрого, и вы, вероятно, будете время от времени быстрее, чем ожидалось. Выигрывают все :)

Эта статья - хорошее описание практически единственного способа узнать, сколько времени что-то займет: http: // www. joelonsoftware.com/items/2007/10/26.html

Один из способов помочь вам стать лучше - это отслеживать вашу первоначальную оценку (сначала снимайте в темноте, если вам нужно), а затем отслеживайте, сколько времени на это у вас ушло. Возможно, вы даже захотите оценить, насколько «сложно» это было сделать и насколько сложно, как вы думали, это будет изначально сказать по шкале от 1 до 10.

Сделайте это некоторое время, и вы можете увидеть закономерность и даже начинаете понимать, насколько ваши оценки хороши / плохи (относительный термин).

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

Итак, я собираюсь оценить 10 дней на этот день и посмотреть, что произойдет. : )

Постоянно повторяйте это упражнение, и вы начнете лучше справляться с этим.

Ах да, как уже упоминалось, оценка сложна, и есть много ресурсов, но ничего лучше практики или действительно хорошего наставника. :)

Вот ссылка на замечательную книгу Стива Макконнелла (также известного как Mr Code Complete): который может составлять от 30% до 500%)

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

представить его своему руководителю и обсудить

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

От 1 дня до 5 дней) и любые примечания, которые могут включать вопросы и предположения.

представить его своему руководителю и обсудить

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

От 1 дня до 5 дней) и любые примечания, которые могут включать вопросы и предположения.

представьте его своему руководителю и обсудите

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

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

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

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

Когда менеджер спрашивает оценку, он / она часто заботится не столько о самой оценке, сколько о том, что сотрудник проводит анализ и выясняет подзадачи, основные пробелы, зависимости и т. д. Другими словами, запрос оценки часто является уловкой, которую использует руководство, чтобы заставить сотрудника приступить к работе. В этом случае оценочное значение - это просто механизм внедрения зависимости, чтобы заставить сотрудника провести анализ.

Конечно, хитрые менеджеры также имеют тенденцию запоминать оценочное значение,

Закон Мерфи о тайм-менеджменте:

Чтобы узнать, сколько времени что-то займет, начните с того, сколько это должно занять.

Затем умножьте это на 2.

Затем перейдите к следующей более высокой единице времени.

Так, если проект должен занять один день, то, вероятно, займет две недели.

Я бы сделал две вещи:

1. Оценка, основанная на том, сколько времени вам потребовалось, чтобы выполнить последнее задание аналогичной сложности - технику «вчерашней погоды».
2. При необходимости дайте оценку диапазона: «Если дела пойдут хорошо, два дня. Если дела действительно плохи, это может быть два месяца». Хотя это крайний диапазон для оценки, есть задачи, в которых она настолько точна, насколько это возможно. Если вы указываете диапазон, не забудьте также указать причины, по которым этот диапазон существует.