Игорь

https://www.mindtheproduct.com/2011/10/what-exactl...
https://www.aha.io/roadmapping/guide/product-manag...

Как оценить время которое потребуется программисту в часах на создание приложения?

Задать вопрос этому программисту.

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

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

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

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

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

Это я не говорю о том, какого хера тестирование делается в нерабочее время и в ночь перед релизом))
Если так всё запущено, то можно предположить, что это всё вообще не важно и ничего страшного не случится, если утром релиз перенесут.
Там, где такие релизы *действительно* важны, в ночь перед релизом не тестируют.

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

Это зависит от задачи, от разработчика, от технологий.
Например джун по новой для него задаче с незнакомой технологией очевидно будет много гуглить и читать - значит активность будет ниже.
Если задача требует в основном кодирования и сотрудник может не гуглить, то активность будет выше.

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

Коротко - быстро и дёшево - никак.

Менее коротко - наймите профессионала/профессионалов, которые этим занимаются (мы, например, занимаемся). Я серьёзно. Это самый эффективный метод (и по деньгам, и по времени и по нервам), если только вы сами лично не планируете освоить профессию бизнес-аналитика.

Более подробно
Если вы попросите разных людей пробежать марафон - люди назовут разное время и разную стоимость. Никакой "правильной" оценки по срокам и бюджету в реальности не существует.
Или другой пример. Гораздо более простой по сравнению с (почти) любым ИТ проектом продукт - хлеб, который выпускается массово и опыт его создания у человечества - тысячелетний, если не больше. Так вот 1) один и тот же хлеб в разных магазинах стоит по разному 2) всяких хлебов в магазине десятки 3) разные люди его согласятся делать за разные деньги и сроки.

Что делать
Никаких волшебных методик нет. Ваша задача требует кучи работы так или иначе. Создать Техническое Задание и оценить его, тем более по каждой фиче - это куча работы для высококвалифицированного и опытного (а значит дорогого) специалиста.

1. Определитесь, с кем будете работать. Это должно не сильно зависеть от денег (в т.ч. потому что у вас ещё нет оценок), а больше от того, насколько вы доверяете друг другу, насколько вы сработались, и вам комфортно работать вместе. (Отсутствие доверия или несовместимость методов работы - слишком большой риск провала проекта, мы к примеру за такие проекты даже не берёмся).
2. Сядьте вместе с исполнителями или его представителем и разбейте проект на фичи, можно довольно грубо. Т.е. составьте нумерованый список всех фич. В экселе или гугл таблицах.
3. Исполнитель их оценит, проставит свои оценки в соседних колонках. Оценки тоже будут довольно грубые. По деньгам и срокам скажем. Т.е. этот список отдаёте команде исполнителя, команда оценивает. Это может занять часы или дни (для проекта в 2 месяца). Понятно, что фичи могут быть взаимосвязаны, оценки тоже и т.д. Это держим в уме (в очевидных случаях) или делаем пометки о зависимостях рядом в колонке (в неочевидных).
4. После этого вы смотрите на оценки и решаете что делать, а что нет.
5. С теми фичами, что вы решили оставить, работаете более подробно. Пишете более подробную спецификацию, делаются проверки, оценки корректируются, план работ ещё раз уточняется и т.д.

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

Дальше вы начнёте делать проект, и что-то пойдёт не по плану, поэтому нужно будет работать с Измненениями в Проекте и корректировать план работ уже по ходу. Но это несколько другая история.

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

1. Учиться на своих ошибках и успехах. Алгоритма по оценке не существует, есть методики, но они требуют опыта оценки. Без опыта оценки всё равно будет неверный результат.
2. Прочитать "Вальсируя с Медведями". Там есть методика рассчёта Riskology, из неё будет хотя бы понятно как это работает вообще.

Изменения за доп деньги

Зависит от продукта, сферы деятельности компании и её структуры. Везде по разному.

Это слишком сложный вопрос, по нему столько копий сломано. К тому же сформулирован слишком общё. По каким критериям оценивать? Их же много. В общем, в отличие от строительства, тут не так всё стандартизированно. Поэтому лучше всего обратиться к опытному специалисту.

Как договоритесь.

Поэтому и не знаю, какие адекватные рамки стоимости

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

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

И может вообще, не нужно делать самописный сайт, а достаточно работать на какой то cms для этих целей?

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

Основные требования - скорость загрузки, чистый код, чтобы ничего не мешало seo продвижению, масштабировалось на поддомены, удобная админка.

Плохой специалист плохо сделает и на CMS и без неё. Хороший - и с CMS и без сделает хорошо, вот и всё.

Никаких волшебных ответов в вашем случае нет.

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

Некоторые люди написали, что вырасти из девелопера в менеджера нельзя, потому что это разные вообще вещи. Забавно это читать, учитывая, что вот тут на вопрос "Как стать руководителем/менеджером проекта?" были даны совершенно противоположные ответы.
Почему же так? А там спрашивал не девелопер ))
Умора.

В Jira это можно настроить используя встроенные возможности. Кроме Гантта, он есть как плагин.

Github и в нём использовать Github issues. Чтобы ставить права доступа, нужна организация в Github.

UPD: размышления не в кассу, стоимость TeamWox - $150 за рабочее место + ещё $30 в год.

Как я понял, TeamWox стоит $900. При такой цене и ваших масштабах вас должны волновать совсем другие вопросы. Стоимость внедрения будет существенно выше $900.
Предположим в вашей организации размер зарплат средний по стране (30 т.р.). Тогда объём ФОТ у вас = 30 000 руб * 100 чел * 1.4 (коэф - налоги и социалка) ~= $65000. Если всего на внедрение/обучение/освоение в среднем у каждого сотрудника уйдёт 1 рабочий день (что очень мало), то это потери в $65000/22 ~= $3000. И это я ещё не считаю стоимость самого внедрения, последствия снижения эффективности работы в период освоения новой системы, время и усилия на доводку системы под свои бизнес-процессы и риски того, что она вообще вам не подойдет и у вас не заработает и т.д. Можно смело удвоить-утроить цифру.
Итого, стоимость внедрения будет порядка $5000 - $10000. Навскидку.
Поэтому при цене в $900 логичнее искать решения не дешевле, а более подходящие.
Стоимость TeamWox в вашей ситуации - копеечная.