Александр Павлють

Микросервисы - многие не в курсе что это не "опимизация технического решения" а оптимизация "управления техническим решением".

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

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

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

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

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

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

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

Поэтому техническое решение которое работает это:
- для разработки это заказ "библиотек" и "компонентов" (любые платформы и языки имеют возможности поставки и дистрибуции таких "пакетов").
- если вам надо "майнтанить (обслуживать) "распределенно и секурно" - это микросервисы и облачка.

Чтобы все это "придумать" и "собирать вместе" вам нужен очень головастый и рукастый "архитектор" (на самом деле он называется "системный инженер" по версии INCOSE).

Решения есть - важно понимать что вы "потяните" сами.

Если у вас как и говорят "мега идея но вы ничего не можете сами" - вы и не сможете без зависимости от внешних талантов.

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

Готов ответить детально на каждый вопрос всем желающим в комментариях.

https://www.youtube.com/watch?v=4912HpeC0xg&featur...

Да надо.

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

Тестировать надо вместе и по заранее согласованным сценариям - это путь к договоренностям.

Если клиент не хочет подписываться под конкретные сценарии - вы должны работать по-недельно. То есть - оплата за неделю, в течении недели находится баг, вы его чините, и так далее.

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

То есть вы не имеете возможностей (ровно как и любой человек в этом мире) предвидеть все возможные варианты.

Итого это регулируется тестовым сценарием под который ставится подпись, на нем написано что все что в оговоренный сценарий не входит - в него не входит. Если надо будет проработать новый кейс - он будет для вас обоих новым кейсом, потому что не представлен в бумаге.

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

Разумеется каждый набор тестов с оговоркой на каких девайсах проверяете.

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

Телепаты же в отпуске.

Успехов.

У меня есть ценообразование которое работает так как вы описали, и клиенты за это платят.

Так как я даю ссылку и это на моем сайте - модераторы постоянно выпиливают эти ответы, я честно говоря немного этим возмущен, но вы знаете что делать.

UPD: Подробно об этом я рассказал на спарке https://spark.ru/startup/mjolnir/blog/32675/pravil...

Существует и много. На соседнем сайте работаю больше 5 лет. freelansim.ru

Ценник зависит только от тебя, понятно что ты не совсем четко понимаешь что именно это значит и как этим управлять - но все же зависит только от тебя и от того как ты научишься работать с ценами и клиентами.

Для начала нужно не боятся и просто начинать работать - все остальное появится без сильного напряга если ты работаешь. Успехов и не бойся - все получается, начни!

Снова похожий вопрос, я тут уже как-то отвечал, но вот еще раз ссылка на пост полутора-годовалый может поймаешь уверенность - www.pavlyut.com/posts/freelance-is-good

Не боись

[хотел просто написать но не дает все вставить, так что сходите по ссылке там все я разложил на эту тему почти два года назад]

www.pavlyut.com/posts/freelance-is-good