Страница 1 из 4 1 2 3 4 ПоследняяПоследняя
Показано с 1 по 20, из 78.

Тема: Как считать творческих программистов?

Hybrid View

  1. #1
    Регистрация
    10-10-2005
    Сообщения
    23,030
    Благодарность
    18,840
    Поблагодарили 16,524 раз в 6,186 сообщениях

    Question Как считать творческих программистов?

    Вдруг есть новый свежий взгляд.

    Без оценки трудоёмкости сложно адекватно планировать. Точнее говоря - не сложно,... "но такой бред получается" ©

    А как оценить гипотетическую трудоёмкость разработки?... Экспертный метод? Метод предыдущих аналогов?

    Читать "Как пасти котов" не предлагать.
    Побеждает тот, кто первым скажет ложь

  2. зависит от. Если у тебя веб студия по клепанию лендингов - то да, метод предыдущих аналогов. Если сложный продукт/система, в которой надо делать новые фичи и внедрять новые технологии - то никак вообще. Единственное, что можно сделать - это прорабатывать задачу, декомпозировать как можно детальнее, каждую подзадачу ранжировать по принципу от сложного/непонятного через сложное/понятное к простому/понятному. Так хотя бы будет возможность по мере продвижения работ всё точнее прогнозировать сроки окончания.

  3. Одобрили:
    Major Keis  (26-01-2024)  

  4. #3
    Регистрация
    10-10-2005
    Сообщения
    23,030
    Благодарность
    18,840
    Поблагодарили 16,524 раз в 6,186 сообщениях
    Спасибо!

    Декомпозиция = трудоёмкость подготовки, "неповоротливость" ТЗ, но предсказуемость.

    Думал на тему классификатора, для простоты "взвешивания" запросов, но... даже так получается не достаточно точно.
    Побеждает тот, кто первым скажет ложь

  5. делай по аджайл
    берешь проект
    выбиваешь примерный бюджет
    берете задачу, делаете, закрываете по t&m , и так пока все задачи не сделаете или не кончится бюджет
    тогда возвращаешься в точку или нового проекта или нового бюджета

  6. #5
    Регистрация
    10-10-2005
    Сообщения
    23,030
    Благодарность
    18,840
    Поблагодарили 16,524 раз в 6,186 сообщениях
    Потеря доверия заказчика - т.к. задачи могут растягиваться во времени. Нет конечной стоимости.
    Потеря доверия исполнителя - т.к. объем доработок и изменений будет бесконечным. Нет конечного срока.
    Побеждает тот, кто первым скажет ложь

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

  8. Бляяя

  9. #8
    Регистрация
    10-10-2005
    Сообщения
    23,030
    Благодарность
    18,840
    Поблагодарили 16,524 раз в 6,186 сообщениях
    Почитаю. Хм... "тарификационный справочник"...
    Побеждает тот, кто первым скажет ложь

  10. если даже пимиай признали аджайл ( а куда им было деваться то.. ) то нам сам бог велел

  11. угу, давай, жги по аджайлу с каким-нибудь корпортатом/ентерпрайзом или не дай бог с госами, да ещё в проекте с кучей легаси..
    все эти модные баззворды оставьте для молодёжных стартапов...

  12. Одобрили:
    Deg  (29-01-2024)  

  13. Чай когда есть куча лигаси, есть и историческая база для оценки, и можно делать фиксед прайс.
    Вот когда никто толком не может ни требования расписать, ни тем более декомпозировать на задачки, тогда т&м может спасти. Но вопрос доверия заказчика нельзя недооценивать - волшебное слово аджайл это хорошо, но если вы в начале обсудите «примерную стоимость», то за неё потом и спросят

  14. вот очень распространённое заблуждение, что в легаси всё понятно... там по факту такое вскрывается иногда при попытке прикрутить что-то простое... А уж если речь пойдёт про ту же смену БД в этом легаси, например, можно такого огрести...

    Про требования - я всегда стараюсь получить от заказчика требования в виде решаемой проблемы, на уровне бизесс-кейса. Зачастую на этом этапе задача снимается Но если заказчик смог сформулировать, какую задачу ему нужно решать, я уже могу предложить ему как эту задачу решить. Тем самым требования застолблены и мы переходим к декомпозиции, если это что-то реально сложное. После этого есть примерная оценка стоимости. Накручиваем на неё 50-100% рисков плюс маржу ну и...

  15. Если заказчик может точно описать требования… то заводить и чатгпт сможет

  16. #14
    Регистрация
    10-10-2005
    Сообщения
    23,030
    Благодарность
    18,840
    Поблагодарили 16,524 раз в 6,186 сообщениях
    Часто встречаю от Заказчика - чтобы было, ну, "зашибись". А что, под этим тектоническая плита и функции "соседей" по процессам, которые своими действиями или бездействием "закопают" всё обратно... это не интересно.
    Побеждает тот, кто первым скажет ложь

  17. как говорится, если нет ТЗ - то результат ХЗ

    тут всё просто же: сделайте что-нибудь! Вот, сделали! Что сделали? Что-нибудь, пройдите в кассу!

    если серьёзно почти, то если заказчик не готов внятно сказать, какую свою задачу он хочет решить - это значит что у него нет задачи, которую надо решить. И зачем тратить его и ваше время?

  18. Чтобы потратить его деньги

  19. Одобрили:
    axel  (27-01-2024)  

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

  21. Потому что я всю жисть то заказчик, то прдрядчик, то внедренец, а то просто консультант)))
    И госы мне родные шописец)

  22. если нужно просто попилить бюджет - не трахайте мозг разработчикам про оценки

  23. Разрабы вроде не рабы
    Не хотят денег - идут курить чистую энергию

Страница 1 из 4 1 2 3 4 ПоследняяПоследняя

Информация о теме

Users Browsing this Thread

Пользователей, читающих тему - 1. (зарегистрированных - 0, гостей - 1)

Ваши права в разделе

  • Вы не можете создавать новые темы
  • Вы не можете отвечать на сообщения
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •