malbaron

1) К кому мне обратиться для разработки MVP? Частные программисты на фрилансе или компания по разработке интернет-порталов? (Сразу хочу кое-что прояснить, мы отмели идею привлечения программиста за процент от долевого капитала, планируем платить живые деньги за разработку. Нам нужен заинтересованный специалист, который понимает за что он работает)

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

Частник - дешевле.
Компания - дороже.

Без разницы кто будет делать. MVP - вполне по силам одному.

2) Если мы рассматриваем поиск программиста-фрилансера, нужен ли аналитик для написания ТЗ для этого фрилансера или выключить его из цепочки?

Нет. Для MVP вся аналитика - это вы + программист. Лишние люди тут не нужны.

3) Сейчас, как я понял, мало программистов, которые занимаются backend и frontend разработкой. С чего начать сначала, front или back? Или имеет смысл искать двух специалистов, которые будут работать синхронно?

Найдете одного. Спланируете с ним как будет. Определитесь с ним нужен ли второй.

4) Что потребуется программисту для написания MVP, помимо ТЗ?

Деньги.
И ответы на много вопросов по ходу написания.

5) И, главный вопрос, как написать ТЗ программисту, провести отбор, если мы не разбираемся в технической стороне вопроса и не можем корректно оценить квалификацию специалиста? Нужен ли нам для этого технический директор?

Написать простым русским языком. Вкратце основные принципы.
ТЗ лучше оформлять уже в паре с выбранным программистом.

А чем технический директор будет отличаться от программиста в плане оценки квалификации технического директора?

Это на самом деле большая проблема.

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

Ничем не отличается о поиска хорошего автослесаря, хорошего мастера по ремонту помещений и любого другого хорошего специалиста - рекомендации. Нет рекомендаций - по объявлению наудачу.

Обратиться в фирму - существенно дороже.
Но есть слабая надежда, что фирма дорожит репутацией. Фриленсеры кидают частенько.

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

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

Читаем как пример как нужно комментировать:
https://github.com/golang/go/blob/master/src/time/...

Для начала делается БРИФ.
Всеми способами выбиваешь из заказчика БРИФ.
Это формальное описание - чего он хочет.

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

Другой вариант - договориться с заказчиком на оплату дальнейших вариантов/экспериментов.
Многие - соглашаются доплачивать.

Заказчик может быть в больнице или т.п.
Вполне уважительная причина.

Но с другой стороны - тебе же кушать нужно каждый день, а не через день.
Я бы взял уже другой.

Предупреди письменно - что в связи с отсутствие ответов ты взялся за другой проект и что когда заказчик решит продолжить ему придется ждать долго пока ты закончишь.
Как заказчик вернется, - предъяви ему письма свои. Что мол писал.

Декомпозиция
И
https://habrahabr.ru/post/269589/

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

Github и пр. - всего лишь хранилища.
Как подключить к вашему проекту - решаете вы в каждом проекте отдельно.
У нас просто при очередном коммите срабатывает хук в Gitlab, который дергает утилиту, которая засасывает файлы в Docker-образ. Этот образ запускается на тестовом сервере. Если проходят тесты успешно то образ запускается на боевом сервере, запросы роутятся на новый сервер, старый образ на боевом сервере отключается.

Как сделать - также читать тут:
https://flynn.io/docs/basics
или тут:
https://deis.com/workflow/how-it-works/

Git, Github, Gitlab, Bitbucket и т.п здесь не более чем хранилище исходных файлов.
Возможно, умное хранилище, но не более того.

Само по себе оно ваш сайт не запустит.
Исключение - статические сайты или сайты где вся логика во фронтенде.
См. github pages и т.п.

Исходя из обычного здравого смысла.
Там нет ничего такого особенно волшебного.

P.S.:
Есть специальные инструменты, есть специальные языки описания проектов - но это уже для серьезных задач.
Сомневаюсь, что серьезная задача вдруг оказалась на плечах человека, который не знает как к ней подойти.

Давайте сравним "Рога и Копыта" с MS.
Какой средний оборот???
Кто такой - "средняя компания"???

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

У одной компании оборот 900К $ в год был при штате в 40 человек. Другая совсем маленькая, штат 7 человек, оборот около 50К $. Компании из СНГ, работают в вебе и мабайле на рынок СНГ.

А Trello, где всего около 100 человек недавно была куплена за 0,5 миллиарда долларов.
;)

Это все несравнимо.

Читать Брукс "Мифический человеко-месяц"
Примерно полвека назад уже знали, что оценки в ИТ являются очень оптимистичными.

Способ 1:
Умножать свои оценки на 3. Я так и делаю.

Способ 2:
Делить работу на мелкие кусочки. Оценивать (и оплачивать кусочно).

Любой, что лучше знаешь.
PHP, Go, Ruby, NodeJS, Python, Net, C/C++,Perl - да что угодно.
Все варианты реализация имеют право на жизнь.

В качестве базы берем postgresql

Если проект очень перспективен, то:
Я бы выбрал Mongo+Postgres+Tarantool.
Разные описанные вами виды данных удобнее хранить и быстрее обрабатывать в разных СУБД.
Будет и быстрее и ресурсов будет меньше жрать.

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

Во первых - не обязательно это должен быть git.
Есть треккеры с issue.

Git - следит за исходным кодом. Но возможно вам будет удобнее прописывать подробности именно в отдельном issue, а не в комментариях к коммиту в git.

Можно и совмещать.

Во вторых, полное руководство по git читать не обязательно.
По минимуму, достаточно даже двух команд:

git commit -a -m "Описание изменений"
git push

В третьих
Gitlab (и прочее свое ПО на свой сервер) ставить не обязательно. Они предоставляют услугу (даже бесплатную вроде) - по размещеню кода у них.
Так же подобную услугу предоставляет BitBucket (бесплатно), но функционал меньше чем у Гитлаба.
Также за небольшие денежки подобная услуга есть у GitHub.

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

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

В шестых
Тестовая для показа и итоговая для выгрузки на боевой сервер можно решать ветками.
Традиционно ветка называемая "master" - это основная (боевая).

В седьмых
GitLab довольно тяжеловесен и требователен к серверу
Если уж хочется нечто похожее на свой личный GitLab то имеет смысл посмотреть
на https://habrahabr.ru/company/selectel/blog/305422/

В восьмых
Графические клиенты для git (SourceTree) вам вряд ли понадобятся - они полезны разве что если у вас будет очень много веток и их объединений. Да и то - возможностей у Gitlab для визуального наблюдения изменений довольно много.

Любой инструмент, что лучше знаешь.
Что лучше знаешь ты лично.
Нет никаких принципиальных ограничений.

Но сие (писать самому) целесообразно только если у заказчика навалом бабла.

Дешевле и быстрее - будет использовать готовое решение.
Есть куча специализированных CMS для интернет-магазинов.

1. Для сколько-нибудь корректной оценки - нужно детальное описание требований. Нет, не так. ДЕТАЛЬНЕЙШЕЕ.

2. См. пункт 1.

Однако: оценка может отличаться и в 10 раз.

В ИТ это совершенно нормально - так как есть очень и очень разные технологии, дающие разные перспективы развития.
И есть очень и очень разные специалисты.

Приведу пример:

У меня есть заказчик - развиваю ему интернет-магазин уже 10 лет.

1. Сначала подходили максимально экономично - сделали первую версию на стандартном движке.
2. Потому ему захотелось сильно много нестандартных фич - переделали на самописном движке с нуля, это оказалось дешевле, чем пилить стандартный движок под эти фичи.
3. Потом ему захотелось продавать свой движок другим - и, оказалось, что в продаже его заказной слишком дорог, так как затачивался под конкретные задачи. И не затачивался под продажу на сторону.

А формально все эти 3 принципиально различающихся сайта называются "интернет-магазин".