[Программирование, Управление разработкой, Управление проектами, Управление продуктом] Оценка трудозатрат в разработке ПО для начинающих (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Оценка временных затрат при разработке ПО может быть сложной задачей, но есть несколько хитростей, которые помогут получить точные цифры.
Помню, как меня впервые попросили дать оценку…Тогда это застало врасплох.Меня завели в кабинет, где были мой начальник, его босс и кто-то из вышестоящего руководства, и мы сели за круглый стол, уставившись друг на друга.Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.И тут мой начальник повернулся ко мне и спросил: «Сколько времени это займет?»Я не знал, что сказать, — меня к этому не готовили. Мне не сказали, что на этой встрече нужно будет давать оценку — я думал, меня позвали поприсутствовать, чтобы я чему-то научился.И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.Передо мной лежала бумага для заметок. Я взял один листок и начал писать какие-то числа — без понятия, для чего, но точно не для этой оценки.Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: «Не знаю… часов 600?»Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200 часов.Не очень люблю вспоминать тот день.Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?Цель проведения оценкиПрежде чем приступать к оценке, нужно понять, для чего она будет использоваться. Вы сообщите цифры начальнику или вышестоящему руководству — и что будет дальше?Оценка объема работы используется в основном в двух целях:
- Планирование.
- Выставление счета клиенту.
ПланированиеСтаршие менеджеры, директора и вице-президенты компании заинтересованы в том, чтобы работа шла и выполнялась в срок. Им нужно знать, что и к какому времени будет сделано — а для этого нужна оценка того, сколько времени уйдет на проект.Они знают, какой объем работы какая группа разработчиков может на себя взять в месяц, квартал и год. И чтобы обеспечить занятость сотрудников, руководству нужно составить график работы над проектами. Данная вами оценка и поможет в таком планировании загрузки.Допустим, в вашей команде разработчиков три человека. Каждый работает по 40 часов в неделю — это примерно 160 часов в месяц, или 480 часов в квартал (на троих — примерно 1500 часов).Представьте, что ваша команда должна выполнить пять проектов — с оценками объемов работ 800, 400, 300, 200 и 50 часов. Планируя загрузку, вы будете видеть, что не сможете к концу квартала выполнить все проекты. Менеджеры составят график, использующий определенный процент максимальной загрузки — на случай, если разработка займет больше времени, чем предполагалось.С оценками из нашего примера можно было бы взяться за проекты на 800, 400 и 50 часов, и при этом осталась бы некоторая свобода для маневра.Выставление счета клиентуРазработка программного обеспечения — это бизнес, цель которого — зарабатывать. Если клиент хочет, чтобы для него был выполнен индивидуальный проект, и он готов за это платить, ваша оценка поможет определить соответствующую стоимость.Вам передают требования, вы говорите, сколько времени потребуется на разработку, отдел продаж переводит время в денежную сумму и сообщает ее клиенту, который после этого решает, стоит ли желаемое таких затрат.Примечание. Это применимо не ко всем компаниям — разработчикам ПО: не все занимаются разработкой на заказ. Если вы не разрабатываете ПО на заказ, то оценки объема работ будут использоваться в основном для планирования.Ключевые факторы при оценкеТеперь, когда вы знаете, для чего вообще нужна оценка, пришло время выяснить, как ее проводить. Когда в следующий раз кто-нибудь спросит, сколько времени потребуется на разработку чего-либо, помните о следующих пяти ключевых факторах.
Фото — AbsolutVision, площадка Unsplash1. Не оценивайте, сколько времени понадобится ВАМПервые два года своей карьеры в качестве «оценщика» я постоянно пытался определить, сколько времени на разработку ушло бы у меня — но спрашивают-то не об этом.Помните, что вы даете оценку с учетом продуктивности команды разработчиков. Не нужно думать, что те, кто будет этим заниматься, знают предметную область так же, как вы. Добавьте небольшой запас, чтобы они могли изучить кодовую базу и новую область знаний.Часто полезным будет предположить, что работу будет выполнять самый неопытный в команде.2. Не занижайте — завышайтеПомните, что в первую очередь оценка делается для планирования. Поэтому не нужно давать цифры, которые, по вашему мнению, могут быть превышены.Если разработчики выйдут за отведенный вами срок, это нарушит график работ.Находиться в границах 20% — это нормально, но только если оценка оказалась завышена — а не занижена.К какой бы цифре вы ни пришли, добавьте к ней 20%: задачи обычно оказываются сложнее в реализации, чем кажется.3. Повышение квалификацииПотребуется ли команде для выполнения проекта изучать что-то новое? Например, если вы обычно разрабатываете приложения для «толстых» клиентов, а новый проект — это создание веб-страницы.Если есть компоненты, требующие приобретения новых навыков (повышение квалификации), учтите это и в оценке. Дайте команде время изучить все тонкости новых шаблонов, языков, фреймворков и т. д. — это всё равно придется делать, поэтому время на обучение нужно заложить в оценку.
Фото — Matheus Frade, площадка Unsplash4. Примеры аналогичных проектовПроще всего давать оценку проектам, основанным на уже привычных для команды шаблонах.Если у команды имеется некий опорный материал в виде ранее разработанного ПО, то объем работы может значительно снизиться. Разработчикам проще действовать по принципу «копировать, вставить, заменить», и это отражается на скорости выполнения задач.Обязательно подумайте, делали ли что-то подобное в этой компании раньше. Если у вас есть специалисты, которые занимались такого рода проектами, проконсультируйтесь с ними при оценке и обязательно используйте их код в качестве вспомогательного при разработке.5. Не забывайте об аналитикахЧасто вас будут просить дать полную оценку, а она включает в себя время разработчиков, бизнес-аналитиков и специалистов по обеспечению качества.В этом случае дать оценку только по разработчиками будет мало — нужно учесть, что бизнес-аналитикам придется писать документацию, делать пользовательские истории и руководить обзорами спринтов.Также потребуется учесть время, необходимое отделу контроля качества для тестирования. Возможно, у вас есть какая-то система автоматизации, которую нужно настроить и для этого проекта тоже? На всё это нужно время, которое также включается в оценку.ЗаключениеЧтобы научиться давать оценку объему работу, нужно время. Этот навык, как и любой другой, требует практики.Со временем оценки будут даваться вам всё легче. Запомните перечисленные моменты, научитесь понимать, сколько времени занимает разработка определенных элементов, и полагайтесь на свой опыт.Если резюмировать самое главное, запомните вот что:
задача всегда сложнее, чем кажется, и лучше переоценить объем работ, чем недооценить.
Никто не будет злиться, если у вас всё пойдет по плану, — начальство даже порадуется! И при этом у вас останется больше времени на другие проекты.Так что не стесняйтесь выделять побольше времени и помните, что оценка — это всего лишь оценка.О переводчикеПеревод статьи выполнен в Alconost.Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Allen Helton
===========Похожие новости:
- [Python, Программирование, Научно-популярное, Космонавтика, Астрономия] Кодируем и декодируем сообщение для внеземных цивилизаций
- [JavaScript, Программирование, Angular] RxJS и Angular: искусство отписки от уведомлений (перевод)
- [Программирование, Разработка под Android] Рисование собственных представлений (View) в Android (перевод)
- [Программирование, Разработка под Android, Kotlin] Меняем стандартный диалог сбоя приложения в Android на собственный экран (перевод)
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом] Корпоративные опросы всех бесят, но я знаю, как это исправить
- [Программирование, Функциональное программирование] Векторные языки — параллельный мир
- [Управление разработкой, Управление персоналом] Почему мы не берём на работу новичков или 5 мифов обучающих платформ
- [Разработка веб-сайтов, JavaScript, Программирование] Роутинг и рендеринг страниц на стороне клиента с помощью History API и динамического импорта
- [Управление разработкой, Управление персоналом] Как проводить собеседования разработчиков
- [Программирование, Java, Анализ и проектирование систем] Микросервисная авторизация для чайников для чайников
Теги для поиска: #_programmirovanie (Программирование), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_proektami (Управление проектами), #_upravlenie_produktom (Управление продуктом), #_alconost, #_otsenka_trudozatrat (оценка трудозатрат), #_otsenka_stoimosti_proekta (оценка стоимости проекта), #_otsenka_vremeni (оценка времени), #_otsenka_proekta (оценка проекта), #_rekomendatsii (рекомендации), #_estimation, #_estimatsija (эстимация), #_blog_kompanii_alconost (
Блог компании Alconost
), #_programmirovanie (
Программирование
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 05:46
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Оценка временных затрат при разработке ПО может быть сложной задачей, но есть несколько хитростей, которые помогут получить точные цифры.  Помню, как меня впервые попросили дать оценку…Тогда это застало врасплох.Меня завели в кабинет, где были мой начальник, его босс и кто-то из вышестоящего руководства, и мы сели за круглый стол, уставившись друг на друга.Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.И тут мой начальник повернулся ко мне и спросил: «Сколько времени это займет?»Я не знал, что сказать, — меня к этому не готовили. Мне не сказали, что на этой встрече нужно будет давать оценку — я думал, меня позвали поприсутствовать, чтобы я чему-то научился.И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.Передо мной лежала бумага для заметок. Я взял один листок и начал писать какие-то числа — без понятия, для чего, но точно не для этой оценки.Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: «Не знаю… часов 600?»Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200 часов.Не очень люблю вспоминать тот день.Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?Цель проведения оценкиПрежде чем приступать к оценке, нужно понять, для чего она будет использоваться. Вы сообщите цифры начальнику или вышестоящему руководству — и что будет дальше?Оценка объема работы используется в основном в двух целях:
 Фото — AbsolutVision, площадка Unsplash1. Не оценивайте, сколько времени понадобится ВАМПервые два года своей карьеры в качестве «оценщика» я постоянно пытался определить, сколько времени на разработку ушло бы у меня — но спрашивают-то не об этом.Помните, что вы даете оценку с учетом продуктивности команды разработчиков. Не нужно думать, что те, кто будет этим заниматься, знают предметную область так же, как вы. Добавьте небольшой запас, чтобы они могли изучить кодовую базу и новую область знаний.Часто полезным будет предположить, что работу будет выполнять самый неопытный в команде.2. Не занижайте — завышайтеПомните, что в первую очередь оценка делается для планирования. Поэтому не нужно давать цифры, которые, по вашему мнению, могут быть превышены.Если разработчики выйдут за отведенный вами срок, это нарушит график работ.Находиться в границах 20% — это нормально, но только если оценка оказалась завышена — а не занижена.К какой бы цифре вы ни пришли, добавьте к ней 20%: задачи обычно оказываются сложнее в реализации, чем кажется.3. Повышение квалификацииПотребуется ли команде для выполнения проекта изучать что-то новое? Например, если вы обычно разрабатываете приложения для «толстых» клиентов, а новый проект — это создание веб-страницы.Если есть компоненты, требующие приобретения новых навыков (повышение квалификации), учтите это и в оценке. Дайте команде время изучить все тонкости новых шаблонов, языков, фреймворков и т. д. — это всё равно придется делать, поэтому время на обучение нужно заложить в оценку.  Фото — Matheus Frade, площадка Unsplash4. Примеры аналогичных проектовПроще всего давать оценку проектам, основанным на уже привычных для команды шаблонах.Если у команды имеется некий опорный материал в виде ранее разработанного ПО, то объем работы может значительно снизиться. Разработчикам проще действовать по принципу «копировать, вставить, заменить», и это отражается на скорости выполнения задач.Обязательно подумайте, делали ли что-то подобное в этой компании раньше. Если у вас есть специалисты, которые занимались такого рода проектами, проконсультируйтесь с ними при оценке и обязательно используйте их код в качестве вспомогательного при разработке.5. Не забывайте об аналитикахЧасто вас будут просить дать полную оценку, а она включает в себя время разработчиков, бизнес-аналитиков и специалистов по обеспечению качества.В этом случае дать оценку только по разработчиками будет мало — нужно учесть, что бизнес-аналитикам придется писать документацию, делать пользовательские истории и руководить обзорами спринтов.Также потребуется учесть время, необходимое отделу контроля качества для тестирования. Возможно, у вас есть какая-то система автоматизации, которую нужно настроить и для этого проекта тоже? На всё это нужно время, которое также включается в оценку.ЗаключениеЧтобы научиться давать оценку объему работу, нужно время. Этот навык, как и любой другой, требует практики.Со временем оценки будут даваться вам всё легче. Запомните перечисленные моменты, научитесь понимать, сколько времени занимает разработка определенных элементов, и полагайтесь на свой опыт.Если резюмировать самое главное, запомните вот что: задача всегда сложнее, чем кажется, и лучше переоценить объем работ, чем недооценить.
=========== Источник: habr.com =========== =========== Автор оригинала: Allen Helton ===========Похожие новости:
Блог компании Alconost ), #_programmirovanie ( Программирование ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 05:46
Часовой пояс: UTC + 5