Comments 59
отличный пост, спасибо!
Суперский пост!! Спасибо :)
В каких браузерах должен корректно отображаться сайт?
Надо делать так, чтобы во всех основных браузерах сайт выглядел нормально, без крайностей конечно :)
А не предлагать это опционально.
Для разных регионов - разные "основные браузеры", к примеру, заказчики из США хотят видеть свой сайт адекватным в IE6, IE7, FF и Safari, отечественный выбор немного иной : IE6,IE7,FF и Opera.
От набора основных браузеров зависит время потраченное на тестирование системы, и этот "суповой набор" необходимо утвердить заранее...
От набора основных браузеров зависит время потраченное на тестирование системы, и этот "суповой набор" необходимо утвердить заранее...
с клиентом необходимо в обязательном порядке обсудить, что такое "основные браузеры" для его веб20. Или будет, что и не редко: "а у моей ... на сайт работает не так" - а там IE5 или даже IE4 оказывается. Четкость составления ТЗ - залог успеха
При разработке сайта стоит учитывать, что есть распространенные и есть малораспространенные браузеры, а также не стоит забывать о том, что надо заниматься поддержкой прочих агентов.
Стандарт поддержки пользовательских агентов можно посмотреть здесь
Стандарт поддержки пользовательских агентов можно посмотреть здесь
сделаю за 30К Евро :D
хорошая статья, и сколько в итоге будет стоить такой проект? хотя бы примерно
Очень хорошая и полезная статья. Спасибо!
Всё хорошо, правда я ещё ожидал увидеть хоть приблизительные цифры (актуальные на данный момент) по стоимости каждого пункта. Или может кто какой-то ссылочкой поделится, а то часто бывает просят что-то сделать, а какраз с оценкой стоимости возникает больше всего проблем :(
Начало воодушевляющее, но: Очень много про конкретные работы по конкретному проекту (разработка сферического сайта в вакууме) и очень мало про собственно методики проведения оценки: про экспертную оценку, оценку группой экспертов (Дельфийский метод) и другие способы. Не раскрыты способы переведения оценки трудоемкости в стоимость проекта для заказчика.
Резюме: статья НЕ про оценку проектов.
Резюме: статья НЕ про оценку проектов.
действительно, ничего не сказано ни об оценке времени, ни о сумме :) только план
создалось впечатление что расчитано на "вменяемых" заказчиков, которые уже точно знают что хотят, провели оценку нагрузки, и могут назвать более двух браузеров. такое обычно бывает когда работаешь субподрядчиком. в общем же случае все гораздо сложнее.
Здорово! Пойду оценю свой проект)
Очень много вопросов задано о стоимости проекта, она же легко вычисляется из количества человеко-часов простым умножением на стоимость (часы указаны в фичелисте), стоимость же человеко-часа варьируется в достаточно больших пределах - от $4 у студентов до бесконечной наглости у некоторых IT фирм. (встречали и по 25 евро в оутсорсе и это не предел)...
4$ в час, т.е. 8*4 = 32$ в день, т.е. 32 * 22 ~= 700$ за месяц работы студента на условиях полного рабочего дня. Причем, я так понял, что это для заказчика уже цена, т.е. до студента меньше дойдет. Можно ли расчитывать на качество за такие деньги?
а что вас удивляет? студентам так и платят. а хотят получить такое, что целая фирма будет месяц делать.
в бытность работы фрилансером, пришлось взять проект с следующими функциями:
интернет-магазин
каталог компаний
доска объявлений
форум
а теперь самое интересное - за проект мне было уплачено... 8000 рублей.
даже с учетом того, что для скорости все сделано на Джумле, я считаю, что это не деньги
в бытность работы фрилансером, пришлось взять проект с следующими функциями:
интернет-магазин
каталог компаний
доска объявлений
форум
а теперь самое интересное - за проект мне было уплачено... 8000 рублей.
даже с учетом того, что для скорости все сделано на Джумле, я считаю, что это не деньги
Я просто усомнился в реальности цифры 4$ в час на сегодняшний день. Очень много вакансий с большими цифрами. Если Вы говорите, что вполне реально найти такого студента, то окей.
вы забыли добавить налоги и накладные расходы.
и до студента дойдёт максимум 400 ;)
и до студента дойдёт максимум 400 ;)
очень доходчиво (для меня, как Заказчика) и понятно.
При обсуждении стоимости (чего бы то ни было) драфт всегда наглядней, чем просто пассы руками в воздухе и сыпание терминами.
К тому же наглядное представление того, сколько времени разработка той или иной фичи потребует, убеждает Заказчика в том, что он действительно имеет дело с профи (здесь есть кусочек лукавства, конечно).
Спасибо!
При обсуждении стоимости (чего бы то ни было) драфт всегда наглядней, чем просто пассы руками в воздухе и сыпание терминами.
К тому же наглядное представление того, сколько времени разработка той или иной фичи потребует, убеждает Заказчика в том, что он действительно имеет дело с профи (здесь есть кусочек лукавства, конечно).
Спасибо!
Спасибо за статью.
Только все же цель оценки какая была? Оценить время/деньги/количество разработчиков?
Или просто собрать максимально полный перечень пожеланий?
Если первое - как правильно переводить, до какой глубины это узнавать - потому что изначально далеко не все ясно, и в ходе реализации проекта сдвиги все равно будут (иными словами - какой процент оставлять на погрешность? например: признавая, что в ходе этих манипуляций разумно в течение такого то времени оценить проект на 60-70-80%, а остальное уже звять приблизительно, т.к. углубляясь в реализации (пока еще нет технического задания и макета, а может быть и бизнес плана как такового) оценка займет слишком много времени? Или же идти до конца?
Только все же цель оценки какая была? Оценить время/деньги/количество разработчиков?
Или просто собрать максимально полный перечень пожеланий?
Если первое - как правильно переводить, до какой глубины это узнавать - потому что изначально далеко не все ясно, и в ходе реализации проекта сдвиги все равно будут (иными словами - какой процент оставлять на погрешность? например: признавая, что в ходе этих манипуляций разумно в течение такого то времени оценить проект на 60-70-80%, а остальное уже звять приблизительно, т.к. углубляясь в реализации (пока еще нет технического задания и макета, а может быть и бизнес плана как такового) оценка займет слишком много времени? Или же идти до конца?
Результатом оценки для заказчика должны быть - деньги и время (не человеко-часы, а календарное время).
У меня есть понятие приблизительной оценки - т.е. заказчик не знает чего хочет - задача угадать желания заказчика и порядок чисел, и точной оценки, когда перед глазами есть ТЗ, тогда погрешность не должна выйти за 20%. Соответственно приблизительная оценка не должна занимать более часа рабочего времени, а точная может затянуться на день(дни) - она необходима если Вы хотите исключить часть рисков дабы не промахнуться и не испугать заказчика.
У меня есть понятие приблизительной оценки - т.е. заказчик не знает чего хочет - задача угадать желания заказчика и порядок чисел, и точной оценки, когда перед глазами есть ТЗ, тогда погрешность не должна выйти за 20%. Соответственно приблизительная оценка не должна занимать более часа рабочего времени, а точная может затянуться на день(дни) - она необходима если Вы хотите исключить часть рисков дабы не промахнуться и не испугать заказчика.
Статья о там как дать понять заказчику, что бабла надо готовить на порядок больше, чем он расчитывал.
Точно. Особенно порадовало "Upload to server all php files and DB" - 8 man/hours. Это по модему что ли? :)
Это тот случай когда для того что-бы залить сайт нуна пинать админов заказчика в личном порядке, потом просить выставить права на папки, дать доступ к БД, и т.д. и т.п., в итоге - поднятие проекта на сервере заказчика может оказаться более трудоемким процессом. цем простое копирования файлов...
Это еще что.. а вот у нас...
Однажды мне стоимость загрузки ресурса считали 8 часов! Эта цифра прошла по документам и никог не смутила.
Однажды мне стоимость загрузки ресурса считали 8 часов! Эта цифра прошла по документам и никог не смутила.
Очень советую всем кто счел статью правильной (в том числе автору, если он не в курсе) много читать про agile.
"Фичи" про которые написано в статье - основная особенность FDD (Feature Driven Development - методология agile).
Оценку трудоемкости (estimates) в соответствии с agile лучше проводить в PD (Perfect Programming Days - идеальные программистские дни), добавляя время утренних и вечерних митингов потом. Оценка проводится группой разработки в соответствии с их опытом.
"Фичи" про которые написано в статье - основная особенность FDD (Feature Driven Development - методология agile).
Оценку трудоемкости (estimates) в соответствии с agile лучше проводить в PD (Perfect Programming Days - идеальные программистские дни), добавляя время утренних и вечерних митингов потом. Оценка проводится группой разработки в соответствии с их опытом.
"Perfect Programming Days" термина не знаю, но кажется интуитивно понял о чем речь... =)
Согласен.
Могу добавить, что указанным методом, как мне кажется, имеет смысл оценивать отностиельно несложные и предсказуемые проекты (создание среднестатистического сайта, веб-витрины и т.п.).
Когда же требуются хоть сколько-нибудь уникальные разработки, ориентированные на результат (а не девелопмент ради девелопмента), agile рулит.
Могу добавить, что указанным методом, как мне кажется, имеет смысл оценивать отностиельно несложные и предсказуемые проекты (создание среднестатистического сайта, веб-витрины и т.п.).
Когда же требуются хоть сколько-нибудь уникальные разработки, ориентированные на результат (а не девелопмент ради девелопмента), agile рулит.
Часы конечно не хилые получились :) Если бы я при своих 7$ в час, сказал, что на разработку мне понадобится >300 часов, то надо мной бы посмеялись :) Хотя в принципе полезный пост, особенно пример фич-листа ) Возьму в качестве примера, только кол-во часов наверно раза в 2 уменьшу на каждый пункт =)
Заглавие "Оцениваем проекты", в посте знак американских денег... А где стоимость проекта?
Далась вам всем стоимость :)
Количество часов * стоимость часа работы вашей компании или вас ( с учетом счетов за электричество, интернет и пр. расходы).
Вот и будет стоимость.
Кстати, при указанной стоимости студенческого часа, равной 4 доллерам, стоимость разработки уменьшается, но стоимость тестирования и поддержки, потенциально, наоборот увеличивается :)
Так что имеет смысл несколько раз подумать, покупая девелопера за небольшие деньги.
Количество часов * стоимость часа работы вашей компании или вас ( с учетом счетов за электричество, интернет и пр. расходы).
Вот и будет стоимость.
Кстати, при указанной стоимости студенческого часа, равной 4 доллерам, стоимость разработки уменьшается, но стоимость тестирования и поддержки, потенциально, наоборот увеличивается :)
Так что имеет смысл несколько раз подумать, покупая девелопера за небольшие деньги.
Вы же проект не только часами оцениваете? Вот мне и интересно на сколько вы оцениваете этот проект в деньгах, к тому же для заказчика и исполнителя это тоже немаловажный фактор :)
> стоимость разработки уменьшается, но стоимость тестирования и поддержки, потенциально, наоборот увеличивается :)
Логично, что не доплатишь сейчас, переплатишь потом =) Про индийцев тут недавно поднимали тему..
> стоимость разработки уменьшается, но стоимость тестирования и поддержки, потенциально, наоборот увеличивается :)
Логично, что не доплатишь сейчас, переплатишь потом =) Про индийцев тут недавно поднимали тему..
Спасыбо за статью!
Очень интересно было бы услишать опыт оценки дизайна сайтов.
Очень интересно было бы услишать опыт оценки дизайна сайтов.
буду знать теперь несколько нових деталей... сам просто задавал вопроси и до того, но не настолько детально, как описано здесь...
>самые популярные нынче это IE6.0+, FF 2.0+ и Safari 3.0+
А уменя (1500+ уников), почему-то Safari занимает 0,31%. Зато Opera - 22,8%.
А уменя (1500+ уников), почему-то Safari занимает 0,31%. Зато Opera - 22,8%.
А, так вы оценивали трудоёмкость разработки?? Первый раз читал, думал, про стоимость проекта речь )
Как в фичер-листе (списке характеристик продукта) оказались дисциплины (возможно - деятельность?) типа Architecture, Testing, Management?
Задайте следующие вопросы заказчику:
Вообще идея совместить целеполагание, выявление требований, проектирование архитектуры (разбиение на технические подсистемы), определение состава работ и трудоёмкости под общим названием "оценка проектов" мне кажется безумной идеей, близкой к халтуре.
Странно, что оценка не зависит от множества переменных, типа квалификации команды, их сработанности, количества используемых новых (а следовательно, рисковых) технологий.
Оценка трудозатрат всегда предполагает определённую точность, диапазон достоверности.
В любом случае, спасибо за интересную тему. Попытка оценки всегда лучше, чем ничего )
Как в фичер-листе (списке характеристик продукта) оказались дисциплины (возможно - деятельность?) типа Architecture, Testing, Management?
Задайте следующие вопросы заказчику:
Антон Шевчук: Какие требования к безопасности сайта?
Заказчик: Э... ну типа это, сайт должен быть безопасным, вроде...
Вообще идея совместить целеполагание, выявление требований, проектирование архитектуры (разбиение на технические подсистемы), определение состава работ и трудоёмкости под общим названием "оценка проектов" мне кажется безумной идеей, близкой к халтуре.
Странно, что оценка не зависит от множества переменных, типа квалификации команды, их сработанности, количества используемых новых (а следовательно, рисковых) технологий.
Оценка трудозатрат всегда предполагает определённую точность, диапазон достоверности.
В любом случае, спасибо за интересную тему. Попытка оценки всегда лучше, чем ничего )
Все очень очень верно по посту.
Вообще, это очень здорово уметь все четко рассчитывать и понимать, как это делается - в этом случае появляется возможность аргументировать перед заказчиком каждую копейку стоимости, а также аргументированно давать понять, к чему приводят чрезмерные "скидки" и "давления на бюджет". Заказчик должен понимать, чем он жертвует, если согласится на "тот же самый" сайт за $4000 вместо заявленных $5000. И очень хорошо, когда компания-исполнитель действительно умеет все объяснить и посчитать. У заказчика тогда даже не остается ощущения "цифр с потолка". Да и риск просчитаться с бюджетом ниже.
К слову о расчетах и о целесообразности включения всех этих пунктов. Считаю, что это обязательно. Мы в своих коммерческих предложениях учитываем, к примеру, даже такую роль как "системный администратор". Какого черта он делает в проекте? Напрямую в процессе разработки - никакого. Ровно, как и менеджер и многие другие необходимые товарищи. Но, как показывает опыт, в ЛЮБОМ проекте "надо что-нибудь где-нибудь донастроить поднастроить и перенастроить". А кто этим будет заниматься? Поэтому, в бюджет включается абсолютно все, что имеет отношения к затратам в проекте.
P.S. К слову о квалификации - от нее зависит стоимость специалиста на час работы.
Вообще, это очень здорово уметь все четко рассчитывать и понимать, как это делается - в этом случае появляется возможность аргументировать перед заказчиком каждую копейку стоимости, а также аргументированно давать понять, к чему приводят чрезмерные "скидки" и "давления на бюджет". Заказчик должен понимать, чем он жертвует, если согласится на "тот же самый" сайт за $4000 вместо заявленных $5000. И очень хорошо, когда компания-исполнитель действительно умеет все объяснить и посчитать. У заказчика тогда даже не остается ощущения "цифр с потолка". Да и риск просчитаться с бюджетом ниже.
К слову о расчетах и о целесообразности включения всех этих пунктов. Считаю, что это обязательно. Мы в своих коммерческих предложениях учитываем, к примеру, даже такую роль как "системный администратор". Какого черта он делает в проекте? Напрямую в процессе разработки - никакого. Ровно, как и менеджер и многие другие необходимые товарищи. Но, как показывает опыт, в ЛЮБОМ проекте "надо что-нибудь где-нибудь донастроить поднастроить и перенастроить". А кто этим будет заниматься? Поэтому, в бюджет включается абсолютно все, что имеет отношения к затратам в проекте.
P.S. К слову о квалификации - от нее зависит стоимость специалиста на час работы.
То, что Вы называете фиче-лист, фактически представляет собой список функционала + высокоуровневый WBS. Поэтому, на мой взгляд такое название не совсем корректно.
Я думаю, что одновременно их делать не очень удобно, лучше сначала фичи, потом WBS. :)
Я думаю, что одновременно их делать не очень удобно, лучше сначала фичи, потом WBS. :)
Sign up to leave a comment.
Оцениваем проекты