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

отличный пост, спасибо!

Суперский пост!! Спасибо :)

В каких браузерах должен корректно отображаться сайт?

Надо делать так, чтобы во всех основных браузерах сайт выглядел нормально, без крайностей конечно :)

сделаю за 30К Евро :D

хорошая статья, и сколько в итоге будет стоить такой проект? хотя бы примерно

Очень хорошая и полезная статья. Спасибо!

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

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

Резюме: статья НЕ про оценку проектов.

действительно, ничего не сказано ни об оценке времени, ни о сумме :) только план

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

Здорово! Пойду оценю свой проект)

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

4$ в час, т.е. 8*4 = 32$ в день, т.е. 32 * 22 ~= 700$ за месяц работы студента на условиях полного рабочего дня. Причем, я так понял, что это для заказчика уже цена, т.е. до студента меньше дойдет. Можно ли расчитывать на качество за такие деньги?

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

К тому же наглядное представление того, сколько времени разработка той или иной фичи потребует, убеждает Заказчика в том, что он действительно имеет дело с профи (здесь есть кусочек лукавства, конечно).

Спасибо!

Спасибо за статью.
Только все же цель оценки какая была? Оценить время/деньги/количество разработчиков?
Или просто собрать максимально полный перечень пожеланий?
Если первое - как правильно переводить, до какой глубины это узнавать - потому что изначально далеко не все ясно, и в ходе реализации проекта сдвиги все равно будут (иными словами - какой процент оставлять на погрешность? например: признавая, что в ходе этих манипуляций разумно в течение такого то времени оценить проект на 60-70-80%, а остальное уже звять приблизительно, т.к. углубляясь в реализации (пока еще нет технического задания и макета, а может быть и бизнес плана как такового) оценка займет слишком много времени? Или же идти до конца?

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

Очень советую всем кто счел статью правильной (в том числе автору, если он не в курсе) много читать про agile.

"Фичи" про которые написано в статье - основная особенность FDD (Feature Driven Development - методология agile).

Оценку трудоемкости (estimates) в соответствии с agile лучше проводить в PD (Perfect Programming Days - идеальные программистские дни), добавляя время утренних и вечерних митингов потом. Оценка проводится группой разработки в соответствии с их опытом.

Часы конечно не хилые получились :) Если бы я при своих 7$ в час, сказал, что на разработку мне понадобится >300 часов, то надо мной бы посмеялись :) Хотя в принципе полезный пост, особенно пример фич-листа ) Возьму в качестве примера, только кол-во часов наверно раза в 2 уменьшу на каждый пункт =)

Заглавие "Оцениваем проекты", в посте знак американских денег... А где стоимость проекта?

Спасыбо за статью!
Очень интересно было бы услишать опыт оценки дизайна сайтов.

буду знать теперь несколько нових деталей... сам просто задавал вопроси и до того, но не настолько детально, как описано здесь...

>самые популярные нынче это IE6.0+, FF 2.0+ и Safari 3.0+
А уменя (1500+ уников), почему-то Safari занимает 0,31%. Зато Opera - 22,8%.

А, так вы оценивали трудоёмкость разработки?? Первый раз читал, думал, про стоимость проекта речь )

Как в фичер-листе (списке характеристик продукта) оказались дисциплины (возможно - деятельность?) типа Architecture, Testing, Management?

Задайте следующие вопросы заказчику:

Антон Шевчук: Какие требования к безопасности сайта?
Заказчик: Э... ну типа это, сайт должен быть безопасным, вроде...

Вообще идея совместить целеполагание, выявление требований, проектирование архитектуры (разбиение на технические подсистемы), определение состава работ и трудоёмкости под общим названием "оценка проектов" мне кажется безумной идеей, близкой к халтуре.

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

Оценка трудозатрат всегда предполагает определённую точность, диапазон достоверности.

В любом случае, спасибо за интересную тему. Попытка оценки всегда лучше, чем ничего )

Все очень очень верно по посту.

Вообще, это очень здорово уметь все четко рассчитывать и понимать, как это делается - в этом случае появляется возможность аргументировать перед заказчиком каждую копейку стоимости, а также аргументированно давать понять, к чему приводят чрезмерные "скидки" и "давления на бюджет". Заказчик должен понимать, чем он жертвует, если согласится на "тот же самый" сайт за $4000 вместо заявленных $5000. И очень хорошо, когда компания-исполнитель действительно умеет все объяснить и посчитать. У заказчика тогда даже не остается ощущения "цифр с потолка". Да и риск просчитаться с бюджетом ниже.

К слову о расчетах и о целесообразности включения всех этих пунктов. Считаю, что это обязательно. Мы в своих коммерческих предложениях учитываем, к примеру, даже такую роль как "системный администратор". Какого черта он делает в проекте? Напрямую в процессе разработки - никакого. Ровно, как и менеджер и многие другие необходимые товарищи. Но, как показывает опыт, в ЛЮБОМ проекте "надо что-нибудь где-нибудь донастроить поднастроить и перенастроить". А кто этим будет заниматься? Поэтому, в бюджет включается абсолютно все, что имеет отношения к затратам в проекте.


P.S. К слову о квалификации - от нее зависит стоимость специалиста на час работы.

То, что Вы называете фиче-лист, фактически представляет собой список функционала + высокоуровневый WBS. Поэтому, на мой взгляд такое название не совсем корректно.

Я думаю, что одновременно их делать не очень удобно, лучше сначала фичи, потом WBS. :)