Веб-программист
  • Как оценить часы на разработку

    Все что вы перечислили — это прежде всего инструменты реализации задачи, т.е. внутрикомандные.

    Я же говорю о работе с заказчиком (т.е. постановке задачи). Составление документа, согласно которого заказчик будет принимать и оплачивать выполненные работы. ТЗ — это фактически детальный счет к оплате, как в ресторане.

    А внутри команды, для разработчиков вы уже разбиваете его на задачи, этапы, сроки, исполнителей и т.п. Еще лучше — предварительно делаете отдельное внутреннее ТЗ для разработчиков.

    Даже Google Docs для многих заказчиков это проблема. Для половины заказчиков наиболее удобный вариант общения — по телефону. Если вы им покажете Trello, они вас пошлют матюками.

    Поддержал: Елена Таранова
  • Как оценить часы на разработку

    Отличная аргументация!!! Сразу чувствуется профи.

  • Как оценить часы на разработку

    Я как раз говорю о том, что ТЗ — не «вордовский файлик с тысячью правками» — и чтобы этого не было, все пожелания клиента пишутся в новый документ.

    Работа производится циклами — предварительная сдача проекта/этапа — получение пожеланий клиента — составление дополнения к ТЗ из этих пожеланий, потом их внедрение. Следующий цикл — получение пожеланий клиента после внедрения новых правок, если еще есть пожелания — составление дополнительного ТЗ.

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

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

    P.S. И гонять вордовский файлик с клиентом не нужно — есть прекрасный Google Drive с совместной работой над документами и даже комментариями для любого абзаца или слова. Странно что вы до сих пор об этом не знаете :)

    P.P.S.Причем ТЗ пишете вы, а клиент может только читать и комментировать. И тогда везде порядок и все довольны.

  • Как оценить часы на разработку

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

  • Как оценить часы на разработку

    В утвержденном ТЗ ни одна строчка не меняется. Иначе потом не найдешь концов — кто прав, а кто виноват.

    Если нужны изменения в ТЗ — а такое происходит в любом проекте — составляется дополнение к ТЗ. Фактически ТЗ на дополнительные задачи. Оно же и оценивается дополнительно.

    Поддержал: Павел Г
  • Как оценить часы на разработку

    Все что вы описали — относится к правильному составлению и согласованию ТЗ. И не относится к оценке «часов на разработку».

  • Как оценить часы на разработку

    сайт на WP, где будет лежать несложный контент

    Несложный сайт на полном готовых решений Wordpress — за 2-3 месяца.
    Это кричит о том, что методика оценки категорически ошибочная. Либо неверно построены процессы.

    300-450 часов по $20 за час = $6000 — $9000 за сайт

    Поделитесь, где вы находите заказчиков, готовых платить такие деньги за такой простой сайт? :)
    Вы можете в методику впихивать сколько угодно параметров, но есть объективная реальность — рынок — заплатит ли кто-то за вашу работу со всем учитанным и просчитанным про запас.

    Поддержал: Елена Таранова
  • Портрет украинского IT-HR/рекрутера

    Типичный разговор разработчика с 80 процентами ИТ-рекрутеров:

    Вариант 1.
    Рекрутер: Здравствуйте, мы нашли ваше резюме, у нас открыта для вас вакансия, приезжайте к нам на собеседование.
    Разработчик: А что за вакансия, какие условия?
    Рекрутер: На эти вопросы ответит наш ИТ-директор, приезжайте на собеседование и мы все расскажем.

    Вариант 2.
    Рекрутер: Здравствуйте, мы нашли ваше резюме, мы ищем специалиста по XXX, NNN, SSS и ZZZ технологиям. Вам подходит наше предложение?
    Разработчик: Да, я специалист по XXX, NNN, SSS и ZZZ. А в чем ваше предложение?
    Рекрутер: Мы предлагаем вам работу по XXX, NNN, SSS и ZZZ.
    Разработчик: у меня есть работа по XXX, NNN, SSS и ZZZ. Что вы предлагаете по финансам?
    Рекрутер: А что вы хотите?
    Разработчик: Если у вас есть предложение, так предлагайте, вы же со мной связались.

    Чаще всего рекрутеры не могут вообще выразить предложение как таковое, а уж тем более выразить в чем интерес их предложения для разработчика.
    То есть подход чисто номинальный, для отчета — у меня есть план связаться с 20 разработчиками сегодня. И все.