Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

Оценка трудозатрат выполнения проекта по разработке ПО: практика в условиях украинской реальности

Блог компании Инфопульс Украина

Вступление



К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (fixed price projects).
В статье мы займемся только оценкой трудозатрат по работе над проектом, оценка длительности выполнения и стоимости – это совсем другая история.
В статье я описываю свой личный опыт оценки проектов, и,
конечно же, у вас могли быть другие ситуации и свои методы и
рекомендации оценивания.
Для большего понимания сути, смысла и «духа» статьи рекомендую сначала просмотреть:
  • выступление Сергея Мартыненко «Написание тестов, как вид тестирования требований»[1], на которое я буду часто ссылаться в ходе данной статьи. Важно понимать, что правильно сформулированные цели и требования – это большой и важнейший шаг к успеху проекта
  • и презентацию Сергея Бережного
    «My Story: «Путь овертаймов» [2]. По большому счету данная презентация к теме статьи не имеет, но имеет отношение к неправильно оцененным трудозатратам.

Статья содержит такие разделы:


  • Украинские реалии при выполнении проекта
  • Проблемы и их решения
  • Подготовка к оценке
  • Перечень работ для оценивания
  • Оценка работ по написанию кода
  • Цифры и коэффициенты из практики
  • Пример расчета

Читать дальше →
Всего голосов 42: ↑40 и ↓2 +38
Просмотры 111K
Комментарии 15

Программирование, быстрое и медленное: разработчики и психология самоуверенности

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

Но сначала история…

Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).

Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.

Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?

Мм, вообще-то: три месяца.

У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.

В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.

К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.
Читать дальше →
Всего голосов 62: ↑51 и ↓11 +40
Просмотры 49K
Комментарии 36

Разработка ПО: факты против мифов

Программирование *
Мифы – это попытки осмысления картины окружающего мира, присущие первобытной культуре.

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

То, что производят программисты, нематериально – это brainware, результат коллективного мыслительного процесса проектной команды, материализованный на одном из языков программирования. Программной инженерии чуть больше полувека. Если сравнивать с материальным производством, то необходимо констатировать, что разработка ПО пребывает еще в первобытном состоянии.

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

Вот наиболее распространенные мифы и факты, которые их опровергают.
Читать дальше →
Всего голосов 150: ↑135 и ↓15 +120
Просмотры 68K
Комментарии 124

Человеческий фактор в разработке программного обеспечения: психологические и математические аспекты

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

Разработка ПО – нелинейный процесс

Разработка программного обеспечения — нелинейный процесс. Если на проект выделено 5 разработчиков, которые за 5 месяцев должны разработать продукт (25 чел./мес.), то 25 разработчиков не смогут сделать эту же работу за 1 месяц (те же 25 чел./мес.).


image
Читать дальше →
Всего голосов 51: ↑39 и ↓12 +27
Просмотры 25K
Комментарии 14

Оценка трудозатрат на проект и подготовка коммерческих предложений

ERP-системы *CRM-системы *
Из песочницы
Ни для кого не секрет, что большинство команд разработчиков регулярно или периодически встречаются с ситуациями проваленных сроков выполнения и превышения планируемого бюджета проектов. В англоязычном интернете можно найти очень много информации по этому поводу. Более того, каждый более или менее опытный разработчик, как правило, имеет собственное мнение на этот счет.
Читать дальше →
Всего голосов 14: ↑12 и ↓2 +10
Просмотры 25K
Комментарии 20

Подготовительный этап разработки программного обеспечения

Разработка веб-сайтов *
Если вы не знаете, в каком направлении развивать проект, то он вряд ли выберет нужный путь самостоятельно.
Стив Макконнелл

Введение


В предыдущей статье «Обзор процесса разработки программного обеспечения» [1] я рассказал о самом «верхнем уровне» процесса разработки, сложившегося в моей практике на текущий момент. Во введении к «Обзору» я постарался сформулировать используемые термины и привёл примеры некоторых проектов, в которых использовался рассматриваемый процесс.

Сегодня я расскажу, как мы проводим подготовительный этап разработки ПО. У подготовительного этапа есть два коллективных действующих лица: заказчик и исполнитель. У каждой стороны есть свои интересы и свои цели в рамках этапа. Описывая подготовительный этап, я постараюсь представить обе точки зрения, их взаимосвязи и возможные конфликты интересов.

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

Для достижения поставленных целей заказчику и исполнителю совместно нужно решить ряд вполне определённых задач:

  1. На основе исходной идеи сформулировать цели и задачи будущего проекта.
  2. Разработать некоторое исходное видение – концепцию проекта.
  3. Провести анализ востребованности будущего продукта.
  4. Провести предварительную оценку рисков будущего проекта.
  5. На основе концепции и списка предварительных рисков подготовить предварительное техническое решение.
  6. Выбрать методологию разработки и подготовить предварительный план работ.
  7. Провести предварительную оценку трудозатрат и необходимых ресурсов.
  8. Провести анализ реализуемости продукта.
  9. Провести независимое рецензирование технического решения.
  10. Принять решение о том, стоит ли продолжать работы.

Читать дальше →
Всего голосов 12: ↑9 и ↓3 +6
Просмотры 42K
Комментарии 0

10 тезисов инди-разработки, которые привели к успеху

Разработка веб-сайтов *Разработка игр *
Лет 10 назад, когда я только начинал свой путь в игровой индустрии, слово инди ещё никто не произносил, а игровые корпорации на постсоветском пространстве казались всем мифической сказкой. В те прекрасные времена, когда на игровом рынке только расцветали первые российские браузерки, мы с другом начали делать свой проект. Мы не считали себя предпринимателями или стартаперами. Нет. Вчерашние студенты, обычные игроки, фанатеющие по Варкрафту, Героям и другим классическим играм. Сегодня я хочу поделиться с вами личным опытом, полученным за время инди-разработки браузерной игры с нуля. Начинающие разработчики, это статья для вас.



Читать дальше →
Всего голосов 22: ↑16 и ↓6 +10
Просмотры 35K
Комментарии 11

Как научиться оценивать задачи, если не умеешь: 4 фактора сложности

Программирование *
Когда я был начинающим программистом, – а впрочем, и позднее, когда я был начинающим ведущим разработчиком, – я думал, что спрогнозировать сроки, в которые ты что-то сделаешь, абсолютно невозможно. Или же, что хороший прогноз требует очень детальных проектирования и подготовки, примерно таких же по длительности, как и сама задача.

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

В одной из команд, где я работал, мы придумали оригинальный метод для предварительной оценки задач. Метод синтезирует некоторые известные из литературы приёмы, но в приведённой форме, пожалуй, никем не описан. Концепция была следующей: объективность (связь с измеримыми показателями); интегрируемость с Agile; повторяемость; быстрота оценки (меньше 0.5% от объема задачи); доступность для начинающих разработчиков. Я буду рад обсудить нашу идею и не исключаю, что кому-то из Хабрааудитории она придётся по душе.
Читать дальше →
Всего голосов 25: ↑23 и ↓2 +21
Просмотры 49K
Комментарии 5

Оценка стоимости ПО: Дэн Гэлорат и SEER-SEM

Управление разработкой *Управление проектами *Agile *


Дэниэль Д. Гэлорат — президент и исполнительный директор Galorath Incorporated и главный разработчик SEER-SEM, программного продукта по алгоритмическому управлению проектами.

Он считается экспертом в области оценки программного обеспечения и автор книги «Программное обеспечение, оценка и риск-менеджмент» («Software Sizing, Estimation, and Risk Management»).

«Книга помогает определить лучший способ инвестировать в улучшение производительности программного обеспечения.»
— Берри Боэм, автор спиральной модели и COCOMO
Читать дальше →
Всего голосов 7: ↑5 и ↓2 +3
Просмотры 5.1K
Комментарии 0

Как оценивать большие задачи

Блог компании Mindbox Agile *
Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.

image
Читать дальше →
Всего голосов 21: ↑21 и ↓0 +21
Просмотры 22K
Комментарии 19

Почему приоритизация по трудозатратам и ценности не работает

Блог компании Kolesa Group Управление разработкой *Управление проектами *Развитие стартапа Управление продуктом *
Перевод

И почему всё же стоит использовать её


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


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



Читать дальше →
Всего голосов 15: ↑14 и ↓1 +13
Просмотры 6.6K
Комментарии 18

Оценка новых проектов

Анализ и проектирование систем *Управление разработкой *
Из песочницы

«Почему Я?!»


Сложно начать писать и структурировать мысли, когда за много лет работы скопилось миллион идей и наработок, как сделать оценку проекта быстро и как можно точнее.

Начнем по порядку. За время работы в ИТ ко мне, как в принципе, и к любому ИТ специалисту, приходят с просьбами оценить ту или иную задачу, функциональность или проект. Первая реакция у всех одна и та же: «Почему я?!». На такой вопрос идут типизированные ответы: «Ты же хотел чего-то нового?!», «Ты классный специалист!», «Это твое развитие!» и т. д. и т.п. Можете сами продолжить смысловой ряд, почему жребий судьбы пал именно на вас.

Все это конечно хорошо, но что делать, если тема для вас новая и оценивать не приходилось часто, а тут задача поражающая воображение: «Оцени нам, как отвезти человека на Марс!».
Читать дальше →
Всего голосов 17: ↑14 и ↓3 +11
Просмотры 6.2K
Комментарии 19

Цена изменений: во сколько на самом деле обойдется переработка кода

Блог компании Wirex Программирование *Управление разработкой *Статистика в IT
Перевод
Автор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.


По мере разрастания кода работать с ним становится все труднее. Годы разработки и отлавливания багов приводят к желанию перечеркнуть все и начать с чистого листа. Действительно, очень заманчива мысль о том, чтобы оставить ошибки в прошлом, вооружиться новыми технологиями и на этот раз все сделать правильно. Однако перед прыжком в бездну я все же предлагаю внимательнее присмотреться к реальной стоимости этого шага.

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


Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?

Читайте также
Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»


Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о:

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



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


Первый фактор — новому приложению необходимо догнать текущее.
Читать дальше →
Всего голосов 17: ↑16 и ↓1 +15
Просмотры 6.5K
Комментарии 3

Оценка и планирование в программных проектах — без купюр

Блог компании 1С-Битрикс Разработка веб-сайтов *Управление проектами *
Друзья, добрый день!

Мы продолжаем серию публикаций «без купюр» о проектах, связанных с разработкой, часто с приставкой «веб». Сегодня поговорим о том, как наиболее правильно и быстро проводить оценки работ и планировать релизы программной системы. Скорее всего, начинающие менеджеры и энергичные и ищущие себя разработчики будут шокированы рекомендациями, но, поверьте — цель стоит одна и только одна: помочь и сделать из вас настоящего джедая, который и пользу компании приносит, и проекты двигает, да и людей развивает одновременно. Такого джедая, который искренне не заслуживает быть обнаруженным в виде мумии в темной серверной между стойками с веб-серверами и базами данных веб-проекта, летящего в будущее без душевно документированного кода, ТЗ — лишь на энергии чистого «ХЗ». Итак, поехали!
Читать дальше →
Всего голосов 21: ↑18 и ↓3 +15
Просмотры 6K
Комментарии 1

Об оценке и управлении разработкой программных продуктов

Программирование *Управление разработкой *Управление проектами *
image

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

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

Справедливости ради следует заметить, что в разработке гораздо более распространены заниженные оценки. Почему? Кто-то считает, что программисты слишком оптимистичны по своей натуре. Я добавлю к этому еще одну причину: быть хорошим программистом и быть хорошим оценщиком — не одно и тоже. Чтобы стать хорошим программистом одного желания не достаточно. Нужны знания и практика. С чего вдруг с оценкой будет по другому?

В статье я расскажу о том, как менялось мое отношение к оценке задач и как сейчас оцениваются проекты в нашей компании. А начну я с того, как оценивать не надо. Если про то как «не надо» вы уже знаете, переходите сразу ко второй части статьи.
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Просмотры 8.3K
Комментарии 3

Грани честности и Джон Доу

Управление разработкой *Управление персоналом *Карьера в IT-индустрии
Я, где-то с 2005 года, с перерывами, работаю в компаниях, которые решают задачи за деньги. Ну это когда клиент приходит, просит чего-то ему запрограммировать, мы делаем, и он нам платит. Там есть и проекты, но в тексте – только про разовые задачи. Да, это про 1С. Не про какую-то конкретную компанию – проблема одна для всех, нигде ее не решили нормально.

Так вот, самая скользкая тема в нашей работе – оценка трудоемкости задач. И гадость в том, что, какую бы оценку мы не давали, она будет казаться нечестной.
Читать дальше →
Всего голосов 37: ↑32 и ↓5 +27
Просмотры 9.3K
Комментарии 45

Как сервис Estimate помогает автоматизировать процесс оценки и узнать стоимость IT-проекта

Блог компании SimbirSoft Разработка веб-сайтов *Анализ и проектирование систем *Управление проектами *Облачные сервисы
Как для бизнеса, так и для IT-компании оценка – один из самых важных этапов в начале работы над проектом. Бизнес готов сотрудничать с тем подрядчиком, который назовет стоимость объективно и быстро, кроме того, заказчикам нужна максимальная прозрачность оценки.

При этом на рынке существует значительный разброс цен: например, одна IT-компания оценивает работу в 300 тысяч рублей, а другая – в 900 тысяч. Стоимость зависит от множества факторов: способа реализации, опыта экспертов, глубины оценки и т.д.

Мы в SimbirSoft уже пять лет используем собственный сервис для автоматизации процесса оценки – Estimate. Мы создали его для того, чтобы упростить работу специалистов, которые занимались оценкой вручную – потому что количество запросов на разработку постоянно росло, а опытные эксперты одновременно были нужны и в оценке, и в проектной работе. Мы постепенно улучшали Estimate и в результате получили инструмент, который учитывает особенности разработки IT-систем любой сложности. В статье расскажем, как вы можете с его помощью ускорить оценку и учесть возможные риски.

Читать дальше →
Всего голосов 13: ↑12 и ↓1 +11
Просмотры 7K
Комментарии 6

Оценка. Рассчитать и уложиться

Программирование *Управление разработкой *
🔥 Технотекст 2020
Предсказуемость сроков выполнения играет важную роль в разработке IT-проектов. И в связи с высокой сложностью процессов оценка задач является непростой проблемой, у которой нет явного алгоритма или простого плана. Усугубляется это тем, что в процессе общения об оценках бизнес, управление проектами и разработка могут говорить на разных языках, не понимать и не хотеть понимать проблемы и ценности друг друга. В результате получаются «отписки», на которые тратятся усилия, а необходимого эффекта они не приносят. 

Статья будет полезна разработчикам, которые хотят улучшить и сделать более комфортным для себя процесс оценки. В ней поделюсь наработанным подходом, который позволяет повысить взаимопонимание с другими подразделениями, а также снизить уровень собственных усилий для оценки. Разберем зачем нужны оценки, как оценивать большие задачи и декомпозированные подзадачи. И, самое главное, что делать, чтобы в эти оценки попасть.
Читать дальше →
Всего голосов 6: ↑6 и ↓0 +6
Просмотры 2.6K
Комментарии 7

Об оценках сроков в разработке ПО

Управление разработкой *Управление проектами *Agile *
Перевод
В течение всей истории разработки ПО мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?

К примеру, возьмите методологию Scrum, по которой сегодня работают многие компании. Центральная идея Scrum — брать в спринт не больше задач, чем ваша команда способна за это время выполнить. На первый взгляд, звучит разумно. К сожалению, слишком часто на практике этот подход приводит к замедлению работы команды в обмен на иллюзию планирования. Позвольте объяснить, почему.
Читать дальше →
Всего голосов 89: ↑87 и ↓2 +85
Просмотры 31K
Комментарии 77

Обдумывая стори поинты

Управление проектами *Управление продуктом *
Перевод
image

Мне нравится говорить, что я, возможно, изобрел стори поинты (story points) и если действительно изобрел, то сегодня мне жаль. Давайте рассмотрим подробнее, что я думаю о стори поинтах сейчас. По крайней мере один из нас точно заинтересован в моих мыслях.

Идея историй (stories) конечно же пришла из XP, а не из Scrum. Неким образом скрам-практики адаптировали эту идею в свою работу. Хотя официальный скрам-гайд говорит лишь об элементах бэклога (backlog items), использовать пользовательские истории в качестве элементов бэклога – очень распространенная в скраме практика.
Читать дальше →
Всего голосов 11: ↑11 и ↓0 +11
Просмотры 4K
Комментарии 0
1