Блог компании Инфопульс Украина → Оценка трудозатрат выполнения проекта по разработке ПО: практика в условиях украинской реальности
Вступление
К написанию данной статьи меня подтолкнул не очень давно завершившийся проект. Как и в любом другом проекте, в нем были и ошибки (в том числе и при оценке), и проблемы и интересные их решения, и, несмотря ни на что, боевой дух команды, и желание сдать проект во время, и переработки и таки сдача проекта в срок, и долгожданный отпуск. Все это стоит отдельной статьи. Но главное — был бесценный опыт, на основании которого создана эта статья.
Очень часто, мы оцениваем проект и сильно ошибаемся. И вроде как из-за мелочей, которые появляются по ходу проекта, но которые, в действительности, можно было бы и обнаружить и учесть заранее.
Статья содержит простые и в тоже время полезные рекомендации и метод расчета оценок трудозатрат проектов и будет интересна руководителям проектов, архитекторам, системным аналитикам, продавцам ИТ решений и всем остальным, кто занимается оценкой работ по проектам с фиксированной ценой (fixed price projects).
В статье мы займемся только оценкой трудозатрат по работе над проектом, оценка длительности выполнения и стоимости – это совсем другая история.
В статье я описываю свой личный опыт оценки проектов, и,
конечно же, у вас могли быть другие ситуации и свои методы и
рекомендации оценивания.
Для большего понимания сути, смысла и «духа» статьи рекомендую сначала просмотреть:
- выступление Сергея Мартыненко «Написание тестов, как вид тестирования требований»[1], на которое я буду часто ссылаться в ходе данной статьи. Важно понимать, что правильно сформулированные цели и требования – это большой и важнейший шаг к успеху проекта
- и презентацию Сергея Бережного
«My Story: «Путь овертаймов» [2]. По большому счету данная презентация к теме статьи не имеет, но имеет отношение к неправильно оцененным трудозатратам.
Статья содержит такие разделы:
- Украинские реалии при выполнении проекта
- Проблемы и их решения
- Подготовка к оценке
- Перечень работ для оценивания
- Оценка работ по написанию кода
- Цифры и коэффициенты из практики
- Пример расчета
Персональные блоги → Прагматический Процесс Разработки в «не-книжных» условиях
Доброго времени суток.
Хочу поделиться некоторыми идеями которые помогают мне в Святой Войне с Хаосом в процессе разработки ПО. Для определенности картины добавлю несколько деталей: я — менеджер проектов, фирма средних размеров (~40 мозгов) занимается оффшорным программированием, команда смешанная (15% сеньоры, 35% девелоперы, 35 джуниоры, 15% стажеры, причем есть еще деление по специализации — разработка, качество, инфраструктура).
Источников создания хаоса более чем достаточно — длинная цепь связи с заказчиком, неоднородная и в общем, молодая команда, «славянский менталитет» ( эксцентричное творчество и частые медитации ;) ), проблемы коммуникаций, политические игры сейлс-людей (Sales — те кто нас «продают») и т.д.
Хочу поделиться некоторыми идеями которые помогают мне в Святой Войне с Хаосом в процессе разработки ПО. Для определенности картины добавлю несколько деталей: я — менеджер проектов, фирма средних размеров (~40 мозгов) занимается оффшорным программированием, команда смешанная (15% сеньоры, 35% девелоперы, 35 джуниоры, 15% стажеры, причем есть еще деление по специализации — разработка, качество, инфраструктура).
Процесс
Источников создания хаоса более чем достаточно — длинная цепь связи с заказчиком, неоднородная и в общем, молодая команда, «славянский менталитет» ( эксцентричное творчество и частые медитации ;) ), проблемы коммуникаций, политические игры сейлс-людей (Sales — те кто нас «продают») и т.д.
Персональные блоги → Сумеет ли ваша команда разработчиков создать отличный продукт?
Читая книгу «The Silicon Valley Way» by Elton Sherwin. Наткнулся на интересный тест, который уверен поможет стартапщикам искать слабые места и белые пятна в своих будущих продуктах.
За каждый вопрос ставьте следующие балы:
За каждый вопрос ставьте следующие балы:
- Нет и не планирую — 0
- Нет, но планирую — 4
- Верно на пятьдесят процентов — 5
- Верно на восемьдесят процентов — 8
- Да, совершенно верно — 10
Управление проектами → Учёт рисков при оценке трудоёмкости ПО и планировании проекта
Поговорим о рисках

Что такое риски? Что является риском, а что нет? Как учитывать риски при оценке трудоёмкости ПО и планировании проекта? Об этом я предлагаю поговорить в этом топике. В то же время, чтобы не раздувать топик и не повторяться, здесь не будут обсуждаться вопросы идентификации и митигации рисков — действий по выявлению, уменьшению вероятности возникновения рисков и минимизации их последствий.
После публикации статьи о смертных грехах в оценке трудоёмкости программного обеспечения мне указали, что ни автор, ни я ничего не сказали о рисках. Хочу исправить это досадное недоразумение и поведать вам немного о рисках и моём опыте работы с ними.
Управление проектами → Как растянуть создание проекта на пару лет или искусство эффективного планирования
Данный топик не претендует на то, чтобы прямо утверждать о том, что тот или иной подход планирования реализации проектов лучше другого. Хотелось бы в обсуждении выяснить, какой подход ближе хабролюдям, и какой из них, по их мнению, является оптимальным.
В связи с тем, что в жизни день ото дня появляются всё новые и новые задачи, проекты, дела – зачастую стало появляться ощущение полнейшего внутреннего беспокойства, возможно, даже стресса. Ощущение того, что не успеваешь ничего сделать, что делаешь то, что надо было реализовать ещё вчера. В общем… ощущение полнейшего завала.
В связи с этим решил заняться своим собственным Time Management-ом. Так как знаний у меня в этой области явно было мало, решил почитать некоторые книги. Первой книгой, которая попала ко мне в руки, точнее, попала в мой наладонник – была “Getting Things Done” David Allen. Буквально первые же главы этой книги, заставили задуматься меня над темой этого поста.
В связи с тем, что в жизни день ото дня появляются всё новые и новые задачи, проекты, дела – зачастую стало появляться ощущение полнейшего внутреннего беспокойства, возможно, даже стресса. Ощущение того, что не успеваешь ничего сделать, что делаешь то, что надо было реализовать ещё вчера. В общем… ощущение полнейшего завала.
В связи с этим решил заняться своим собственным Time Management-ом. Так как знаний у меня в этой области явно было мало, решил почитать некоторые книги. Первой книгой, которая попала ко мне в руки, точнее, попала в мой наладонник – была “Getting Things Done” David Allen. Буквально первые же главы этой книги, заставили задуматься меня над темой этого поста.