Кажется, что независимо от моего проекта, я получаю 80% работы довольно быстро. Пользователи и менеджеры ожидают, что вещи идут впереди графика, но назойливые 20% оставшейся работы, по-видимому, занимают в 4 раза больше, чем предыдущие 80%. Когда у нас есть регулярные проверки или встряски в проекте, я чувствую себя сломанной записью, говорящей: "Да, до сих пор все прошло хорошо, но еще многое осталось сделать..."
По большей части мои оценки довольно точны, но я человек. Каков наилучший подход для убеждения пользователей в том, что последние 20% работы действительно занимают 80% времени? Кажется, все больше и больше пользователей и руководство считают, что это легко, и магия происходит при щелчке пальцами...
В целом, мы отслеживаем задачи по тому, что, по моему мнению, достаточно низкое. Не обязательно на создании ярлыка или текстового поля, но мы довольно подробно... Мы также отслеживаем нашу оценку до завершения по всем задачам, которые, по моему мнению, являются более важным числом, чем исходная оценка, когда вы находитесь в середине проекта.
Я думаю, что это сводится к восприятию пользователей и управления. Несмотря на то, что они могут знать, что оценка завершена, они все еще обернуты эмоциями и представлениями о том, что они видят, а оценочные числа занимают заднее сиденье. Это то, что я пытаюсь понять, как сдерживать или управлять ожиданиями.
Это всегда занимает больше времени, чем вы ожидаете, даже если принять во внимание закон Хофстадтера
Но я отвлекся.
Лучшей практикой является печальный опыт. Методы SCRUM были очень полезны для некоторых типов разработки программного обеспечения, так как они постоянно обновляют дату выпуска до более точной даты. (быстрое видео о схватке)
Не показывайте им первые 80%, как только они будут завершены. Капайте их.
Возможно, вам нужно разбить задачи/функции, над которыми вы работаете, на более мелкие единицы, как для планирования работы, так и для проверок/отчетов. Например, у меня почти нет отдельного элемента в моем графике, который длится дольше двух дней.
Затем вместо того, чтобы говорить "Я работаю над нашим новым создателем muppet" каждый день в Scrum в течение двух недель, вы можете сказать "Я сейчас работаю над селектором глаз для создателя muppet".
Если вы работаете с расписаниями, и ваши графики точны (что означает, что они составляют как 80%, так и 20%), тогда у руководства действительно не должно быть проблем. Если они подразумевают, что они могут сократить выделенное время, потому что вы "почти закончили", тогда покажите им те части спецификации, которые не были реализованы.
Я предполагаю, что вы работаете в какой-то форме функциональной спецификации, которая детализирует то, что что-то должно делать, как оно должно себя вести, и крайности, с которыми он должен иметь дело. Если это так, то беспокоиться о эмоциях и восприятиях управления представляется мне очень странным, они должны быть способны либо сравнить спецификацию с вашей работой, либо прочитать ваше расписание, чтобы увидеть, что осталось.
Как вы оцениваете объем работы? Вы говорите, что "надоедливые 20% оставшейся работы, по-видимому, занимают в 4 раза больше, чем предыдущие 80%", но как вы дошли до оценки, что "20%" работы осталось и что "80%" сделанный? Очевидно, что оценки ошибочны - на самом деле только 20% работы сделано и 80% осталось.
В разработке программного обеспечения очень сложно дать точные оценки заблаговременно. Единственный способ - разделить работу на небольшие управляемые части (возможно, менее 10 часов каждый). Вы можете точно оценить только следующие следующие шаги.
Некоторые методы, которые помогают в оценке прогресса, можно найти в Scrum. Объем работ, которые будут выполняться в течение следующего спринта (один месяц или меньше), фиксируется в начале спринта, и для каждой работы даются приблизительные оценки. Затем после спринта команда может задуматься о том, сколько было сделано, сколько еще не хватает, насколько точны оценки и что замедляет работу команды. В Scrum и других гибких методах важным моментом является получение быстрой обратной связи с тем, что сделано и насколько далеко мы находимся в проекте. Я рекомендую прочитать о них больше. Видео о Scrum, которое Ólafur Waage, связанное в его сообщении, дает хороший и быстрый введение.
Прочитайте отличную книгу Стив Макконнелл Rapid Development, которая может многое сказать о проблеме 80/20 и других кавычках оценки программного обеспечения.
Когда дело доходит до оценки времени, это мой опыт:
Если вы не можете положительно сказать, что задача займет менее 4 часов, вы не сможете ее точно оценить. Разбейте его небольшими кусками и повторите рекурсивно.
Создание такой оценки времени - это не пикник, это займет время, вам в основном придется сгладить весь проект в управляемых кусках, что означает, что любые изменения в требовании приведут к изменению плана времени (удивительно, не так ли?)
Самая большая проблема заключается в том, что мы не можем предвидеть все детали (возможно, допустим, может быть, на 20%? Оставив вас остальных на 80% недооцененных...) - см. SCRUM, как уже указывали другие.
Менеджмент редко "принимает" такую подробную оценку времени, как "слишком долго", чтобы реализовать.
Однако, поскольку руководство заинтересовано в получении прибыли, они также заинтересованы в резке углов. Таким образом, вы должны определить углы, которые можно сократить и сделать сложные компромиссы, основанные на реальных сценариях жизни. Опираясь на менеджмент, вы можете выполнить многие из этих последних 20%, ничего не делая (грустно, как я предполагаю, но все же верно).
Поскольку последние 80% работы, которая представляет последние 20% конечного продукта, действительно полируют и устраняют ошибки и адаптируются к измененным требованиям и т.д. Возможно, возможно, что у вас будет ограниченная первая версия и т.д. и т.д., быть творческим.
Было сказано, что первые 90% времени проекта используются для 90% работы, а оставшиеся 90% времени проекта используются для оставшихся 10% или работы.;)
Естественно добиться больших успехов в начале проекта, поскольку сначала вы просто делаете самые простые части. Кроме того, если в первых 80% кода есть какие-либо проблемы, они часто не будут очевидны до тех пор, пока все не соберутся вместе, и вы можете проверить весь код.
Возможно, в качестве эксперимента вы должны позволить людям попробовать приложение, которое сделано на 90%, чтобы они увидели, в чем разница последних 10%...
Я обнаружил несколько вещей, которые очень помогают с оценками времени
Я использовал это довольно успешно в приближении скорости коллегирования. Он просто принимает некоторые эмпирические замечания о том, как быстро они могут разработать функцию и насколько хорошо это будет до фактического тестирования.
Я не думаю, что могу сказать это лучше, чем Joel с Безболезненно Расписания программного обеспечения.
Если ваш менеджер заставляет вас оцените, здесь что делать. Создать новый столбец в списке Рик Эстимейт (при условии, что ваше имя Рик, конечно.) Положите свою оценку в там. Пусть ваш менеджер все сделает она хочет с колонкой Curr Est. Игнорируйте оценки своего менеджера. когда проект выполнен, посмотрите, кто был ближе к реальности. Я обнаружил, что просто угрожая сделать это чудеса, особенно когда ваш менеджер понимает, что они только что вошли в конкурс, чтобы увидеть, как медленно вы можете работа!
Одна из основных причин феномена 80/20 заключается в том, что неожиданное всегда происходит для любых сложных, а иногда и тривиальных задач. Например: документация о том, что ваш процесс разработки программного обеспечения автоматически устанавливает новый формат шаблона, благодаря некоторым чрезмерным менеджерам процессов. Внезапно, это не просто вопрос обновления документов для вашей новой версии - теперь вам нужно реструктурировать каждый из них, и все они занимают значительно больше времени.
Одна из лучших рекомендаций, которые я слышал для работы с этим типом явлений, - это всегда создавать буферные подзадачи в расписание проекта - рекомендуется Ричард Уайтхед. Каждая главная задача получает 20-процентное увеличение времени (или где-то там), отмеченное как подзадача для этой задачи. Цель каждого состоит в том, чтобы обеспечить некоторые измерения того, что происходит, когда "что-то не так" по этой задаче. Автор признает (и я также признал, что это правда), что зачастую руководство будет пытаться удалить эти задачи буферизации - ваш единственный выход - либо встать на свои места, либо вытащить маневр, как защитники Джоэла (как уже упоминал @Casey). На практике я обнаружил, что большое количество буферных подзадач обычно прилипает и несколько раз помогало в сжатых графиках.
Я обнаружил, что лучший способ - сохранить расписание в актуальном состоянии с полным процентом для каждой задачи. Таким образом, прогресс достаточно ясен. Сообщите об этом руководству, и они должны понимать, где вы находитесь всегда.
Я думаю, что если вы делаете оценки для задачи, которая объединяет 80% и 20%, вы уходите на слабый старт. Разделите свои оценки. Сделать 80% и 20% двух явных задач; легкий бит и жесткий бит, если нужно.
Затем вы можете предоставить более реалистичные оценки времени для работы в целом и упростить производство для отслеживания специфики.
При планировании учтите это. Оценивая время, которое потребуется для выполнения подзадачи, дайте оценку "Готово", а не "В основном сделано" (Оцените опыт, насколько длиннее "Готово" ). Сопротивляйтесь соблазну отклонить интеграцию, документацию, убрать, тестирование, исправление ошибок после тестирования, развертывание и т.д., как небольшие задачи, которые будут поглощены другими задачами.
В итоге вы получите ужасающую крупную оценку. Но спросите себя, не соответствует ли это фактическому времени, затраченному на предыдущие проекты.
Попробуйте и предоставите наиболее точные оценки, которые вы можете, и обеспечите как можно большую прозрачность в проекте. Если вы постоянно приближаетесь к своим оценкам, этого должно быть достаточно, чтобы удовлетворить ваших менеджеров. Помните, что очень сложно измерить производительность.
Я думаю, что это сводится к восприятию пользователей и управления. Несмотря на то, что они могут знать, что оценка завершена, они все еще обернуты эмоциями и представлениями о том, что они видят, а оценочные числа занимают заднее сиденье. Это то, что я пытаюсь понять, как сдерживать или управлять ожиданиями.
Сначала напишите алгоритмы... затем пользовательский интерфейс.
Следите за тем, чтобы ваши временные горизонты были короткими. Легче оценить, что вы будете делать в ближайшие несколько недель, чем в ближайшие несколько месяцев. Подумайте о том, чтобы разбить свой проект на короткие сроки. Месяц или, возможно, пару месяцев зависит от того, что вы пытаетесь сделать. Это в основном то, что делает Scrum. Затем наиболее точно оцените только ту работу, которую вы собираетесь делать в текущем вехе. Переоцените следующую веху, когда вы доберетесь туда, и получите гораздо больше данных для оценки. Одной из причин, по которой последние 20% занимают так много времени, является то, что вы, вероятно, делаете оценку заранее, когда вы не знаете достаточно.
Кроме того, попробуйте методы широкополосной Delphi. Это приведет к гораздо более скрытым расходам, которые вы, вероятно, не рассматриваете.
Говоря "да, все дошло до сих пор, но еще многое осталось сделать...", возможно, не лучший способ понять вашу точку зрения. Услышав, что менеджер или клиент может подумать "да, осталось совсем немного, но он сделал эту часть так быстро, конечно, остальное минимально".
Вместо этого убедитесь, что вы идентифицируете оставшуюся работу и планируете ее. Таким образом, вы можете показать, где вы должны находиться в течение оставшихся 20% проекта. Если это займет слишком много времени, ваше расписание покажет проект за графиком, и это должно вызвать некоторое чувство срочности.
Периодически обновляйте свои задания (или регулярно публикуйте отчеты о состоянии). Определите районы, которым грозит опасность отстать, особенно если от них зависят другие районы.
Я думаю, что лучше всего, если вы можете обещать и перегружать.
Если ваши оценки правильные, то вы учитываете эти досадные 20%. Вы, очевидно, этого не сделали, и именно поэтому это проблема.
Может быть, вы пытаетесь дать им все, что они хотят, что нереально. Возможно, вы не полностью учитывали закон Мерфи или не дали достаточно времени для тестирования, поиска ошибок, затем тестирования снова и т.д.
Похоже, вы должны делать немного больше управления рисками...
Если вы последовательно находите, что последние 20% работы занимают 4 раза в течение первых 80%, то может быть время для честного обсуждения с вами (или с доверенными сверстниками) о том, разрешаете ли вы технический долг нарастает в течение первых 80%, и он кусает вас в конце.
Это может говорить о методах работы, которые вы могли бы рассмотреть.
Две из лучших практик, которые я знаю для поддержания технического долга, пишу хорошие тесты (желательно, прежде чем писать код, но также работают послесловия) и рефакторинг после каждой задачи. Подумайте о рефакторинге, как уборка кухни после каждого приема пищи, а не в конце месяца.