«Книга помогает определить лучший способ инвестировать в улучшение производительности программного обеспечения.»
— Берри Боэм, автор спиральной модели и COCOMO

Модель оценки объема работ

1. необходимости наверстать разницу между уровнями текущего и нового приложений,
2. объеме непредусмотренных изменений,
3. улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.

Сокращение разницы

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

Помню, как меня впервые попросили дать оценку…

Тогда это застало врасплох.

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

Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.

И тут мой начальник повернулся ко мне и спросил: «Сколько времени это займет?»

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

И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.

Передо мной лежала бумага для заметок. Я взял один листок и начал писать какие-то числа — без понятия, для чего, но точно не для этой оценки.

Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: «Не знаю… часов 600?»

Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200 часов.

Не очень люблю вспоминать тот день.

Понятно, что мне еще многое предстояло узнать, но меня мучил один вопрос: как оценивать объем предстоящей работы?

Ситуация и проблема

Что такое человеко-час, человеко-месяц и человеко-год? Как правильно ими пользоваться при планировании и выполнении программных проектов? Какие типичные ошибки допускают проектные менеджеры и руководители групп программистов?

Эта статья поможет развеять мифы и подскажет как правильно планировать работы в проектах. От правильной оценки проекта зависит очень многое. И то, согласится ли с ней ваш клиент и даст ли проекту старт. И то, насколько сложно вам будет делать коррекцию этой оценки в процессе, что неизбежно, и сможете ли вы эту коррекцию обосновать, и то, как вы будете выстраивать бизнес-процессы в управлении проектом. Поэтому в оценке IT-проекта задействована масса факторов, шкал и расчетов. Тем не менее, основная масса клиентов ориентируется на очень понятную и четкую единицу измерения – человеко-час.

Привет. Меня зовут Инга, и я работаю в digital-агентстве Alente.

Мы занимаемся разработкой и продвижением сайтов. Фронт-офис компании состоит из менеджеров, которые заправляют коммуникацией в проектных командах, с клиентами и между ними. Но, помимо этого, в перечень работ любого нашего менеджера, будь то продаван, аккаунт или производственник, входит объяснение всяких непонятных для клиента терминов и в целом добавление прозрачности всем процессам, которые мы как специалисты осуществляем в своей работе.

Одной из самых тёмных и непонятных тем для наших клиентов (текущих и потенциальных) была оценка временных затрат на разработку сайтов.

Стоит сказать о том, что мы в Alente всегда делали относительно небольшие коммерческие проекты: корпоративные сайты, интернет-магазины и несложные веб-сервисы. За 12 лет привыкли работать по фиксированной оценке, так как задачи стали более-менее типовыми. Мы сделали калькулятор с вилками по оценкам этапов и считали всё по нему — и, как правило, попадали в эти оценки. В калькуляторе были типовые блоки, например «отзывы», «страница с каталогом товаров», «авторизация по электронной почте» и прочие.

Как обычно происходит оценка проекта в IT?

ТЗ от клиента дают на осмотр специалисту / старшему специалисту / руководителю проектов. Он прикидывает объем трудозатрат "за всех" и сообщает менеджеру грубую оценку. Менеджер накидывает на эту стоимость некий фирменный коэффициент и получает сумму, которую озвучивает клиенту.

Подобная оценка смотрится настолько же неуместно как лейбл адидас на китайской болванке резинового тапка из 90-х и часто ведёт к тому, что проект будет сделан в убыток для компании или недостаточно хорошо для клиента, т.е. с возможными репутационными потерями для вас.

Правильный подход к оценке должен состоять из следующих этапов.

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

Всем привет, меня зовут Максим Гусев!

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

Я руководитель международных проектов (PMP) и портфелей (PfMP) с реализованными проектами в Турции, Арабских Эмиратах, Германии, Франции, России и Беларуси. С более чем 10-летним опытом управления проектами и 4-летним опытом разработки автономных транспортных средств/робототехники и сегодня я хочу Вам рассказать об определении стоимости технически сложных продуктов и проектов.

Привет! Хочу поделиться своим опытом применения Jira easyBI. Расскажу на примере точечной диаграммы, но также просто можно построить любой отчет в виде произвольной таблицы, Ганта и пр., а после собрать свой дашборд под решение конкретной задачи.

Совсем недавно в SM Lab я занималась подготовкой рекомендаций к верхнеуровневой оценке объема работ. Очень быстро стало понятно, что сформулировать рекомендации легко, а вот их выполнение может быть достаточно геморройным затратным.

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

Привет всем, сегодня от лица Артема, нашего ведущего разработчика, делимся некоторыми советами с теми из вас, кто пытаются оценить проект программного обеспечения и определить четкий MVP.

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

Итак, процесс интервьюирования может быть достаточно сложным, особенно в случаях, когда у клиента:

• несколько заинтересованных сторон;

• интеграционные решения внутри своей системы;

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

Перед менеджером продукта часто возникает потребность в оценке задачи до передачи ее в работу, то есть до проектирования с командой и декомпозиции. Например, от стоимости будущей разработки зависит решение о приоритизации таски (RISE, Value vs. Effort и прочее).

Я занималась разработкой и внедрением рекомендаций к оценке эпиков для product lead-ов (далее — PL) в Спортмастер Лаб и хочу поделиться выводами:

• Нет универсального метода оценки эпиков для всех команд и продуктов.
• Ни один метод не гарантирует 100% точность и надежность.
• Унификация применяемых способов оценки — нужная и полезная работа.
• Если вы хотите масштабировать применение рекомендаций, дайте удобные инструменты.

Поясню :)