Нашел у себя план архитектурного кикофа (совместное формирование первичного видения архитектуры), Last edit was about 8 years ago 🙂
Зачем мы здесь собрались?
Просто и четко опишите проблему, которую намереваетесь решить.
Каково видение?
Опишите, как предлагаемый продукт решает ранее описанную проблему.
В чем ценность?
Опишите бизнес-ценности продукта.
Каков скоуп?
Перечислите наиболее приоритетные из уже известных функциональные требования. Обычно — это must have фичи.
Перечислите то, что не входит в скоуп.
Какие фичи могут повлиять на архитектурное решение?
Кто ключевые заинтересованные лица?
Перечислите заинтересованных лиц и их основной интерес
Как выглядит наиболее просто решение?
Скетч номинальной архитектуры. Это может быть неформальная диаграмма.
Каковы ключевые риски?
Перечислить топ ключевых рисков.
Как много предстоит сделать? Какова стоимость?
Имея на руках предварительные данные по скоупу и номинальную архитектуру, оцените приблизительные затраты и стоимость реализации. Перечислите предположения, касающиеся размера команды и уровня компетений.
Каковы ожидания по компромиссам?
Обсудите ключевые компромиссы прежде чем переходить к принятию сложных решений. Обсудите большую четверку: стоимость, скоуп, сроки и качество. Обсудите важные атрибуты качества.
Когда будет готово?
Предоставьте стейкхолдерам идеи о том, сколько времени может занять разработка продукта. Оценка позволяет начать разговор об основных вехах разработки продукта. Создайте черновик таймлана для известных видов работ. Таймлайн не обязан быть точным и может изменяться по мере работы над продуктом.
Зачем мы здесь собрались?
Просто и четко опишите проблему, которую намереваетесь решить.
Каково видение?
Опишите, как предлагаемый продукт решает ранее описанную проблему.
В чем ценность?
Опишите бизнес-ценности продукта.
Каков скоуп?
Перечислите наиболее приоритетные из уже известных функциональные требования. Обычно — это must have фичи.
Перечислите то, что не входит в скоуп.
Какие фичи могут повлиять на архитектурное решение?
Кто ключевые заинтересованные лица?
Перечислите заинтересованных лиц и их основной интерес
Как выглядит наиболее просто решение?
Скетч номинальной архитектуры. Это может быть неформальная диаграмма.
Каковы ключевые риски?
Перечислить топ ключевых рисков.
Как много предстоит сделать? Какова стоимость?
Имея на руках предварительные данные по скоупу и номинальную архитектуру, оцените приблизительные затраты и стоимость реализации. Перечислите предположения, касающиеся размера команды и уровня компетений.
Каковы ожидания по компромиссам?
Обсудите ключевые компромиссы прежде чем переходить к принятию сложных решений. Обсудите большую четверку: стоимость, скоуп, сроки и качество. Обсудите важные атрибуты качества.
Когда будет готово?
Предоставьте стейкхолдерам идеи о том, сколько времени может занять разработка продукта. Оценка позволяет начать разговор об основных вехах разработки продукта. Создайте черновик таймлана для известных видов работ. Таймлайн не обязан быть точным и может изменяться по мере работы над продуктом.
Еще из старого:
«Bounded Context» как решение проблем с аморфными терминами через контекстные границы доменных моделей
Если нужна информация из ограниченного контекста или нужно сделать запросы на какие-либо действия внутри ограниченного контекста, происходит обмен данными с его четко обозначенной границей с помощью моделей.
Приступая к обдумыванию ограниченных контекстов, имеющихся в вашей организации, нужно размышлять не в понятиях совместно используемых данных, а в понятиях возможностей, предоставляемых такими контекстами всей остальной предметной области.
«Bounded Context» как решение проблем с аморфными терминами через контекстные границы доменных моделей
Если нужна информация из ограниченного контекста или нужно сделать запросы на какие-либо действия внутри ограниченного контекста, происходит обмен данными с его четко обозначенной границей с помощью моделей.
Приступая к обдумыванию ограниченных контекстов, имеющихся в вашей организации, нужно размышлять не в понятиях совместно используемых данных, а в понятиях возможностей, предоставляемых такими контекстами всей остальной предметной области.
Объемная статья про практики распределенной трассировки.
https://www.zerok.ai/post/distributed-tracing-best-practices
https://www.zerok.ai/post/distributed-tracing-best-practices
А админ-то прав 🙂
В сложных системах, состоящих из множества компонентов (+инфраструктурных) и инстансов этих компонентов, среднее время между сбоями (MTBF) стремится к нулю. В любой момент времени что-то может упасть, лежать или деплоится.
Во-первых, в такой ситуации важно не накопить критическую массу отказов, при которой вся система умрет.
Во-вторых, в таких системах точно известно, что отказы неизбежны, но неизвестно что конкретно и когда откажет.
Вот поэтому и нужно уметь поднимать быстро :)
В сложных системах, состоящих из множества компонентов (+инфраструктурных) и инстансов этих компонентов, среднее время между сбоями (MTBF) стремится к нулю. В любой момент времени что-то может упасть, лежать или деплоится.
Во-первых, в такой ситуации важно не накопить критическую массу отказов, при которой вся система умрет.
Во-вторых, в таких системах точно известно, что отказы неизбежны, но неизвестно что конкретно и когда откажет.
Вот поэтому и нужно уметь поднимать быстро :)
В 19:00 Иван Волынкин (OneCell) расскажет как предоставить команде возможность работать на разных dev окружениях с разными ветками и всегда знать, где что задеплоено.
Подключайтесь по ссылке на эфир и задавайте вопросы спикеру: https://www.youtube.com/live/sViiClT1t-M?feature=shared
Подключайтесь по ссылке на эфир и задавайте вопросы спикеру: https://www.youtube.com/live/sViiClT1t-M?feature=shared
YouTube
Continuous deployment — следующая ступенька после Continuous delivery
Как избавить команду разработки от необходимости нажимать на кнопку деплоя, предоставить возможность работать на разных dev окружениях с разными ветками и вс...
Микросервисы / распределенные системы
В 19:00 Иван Волынкин (OneCell) расскажет как предоставить команде возможность работать на разных dev окружениях с разными ветками и всегда знать, где что задеплоено. Подключайтесь по ссылке на эфир и задавайте вопросы спикеру: https://www.youtube.com/live/sViiClT1t…
Ваня пилит достаточно классный и удобный open source инструмент: https://github.com/jonasasx/envrouter 🙂
В видео Ваня показал envrouter в действии, демка пока даже доступна публично https://demo.envrouter.ru (как я понял 1-2 дня будет доступна)
Кому интересно попробовать или поконтрибьютить, чат проекта:
https://tttttt.me/envrouter_ru
В видео Ваня показал envrouter в действии, демка пока даже доступна публично https://demo.envrouter.ru (как я понял 1-2 дня будет доступна)
Кому интересно попробовать или поконтрибьютить, чат проекта:
https://tttttt.me/envrouter_ru
♻️ Виды потерь, через призму которых можно посмотреть и на процессы, относящиеся к работе с архитектурой
Неэффективная верификация
Неэффективное тестирование, прототипирование, подтверждение; например — поддержка тестов стоит дороже, чем тем риски, которые они митигируют
Плохая координация
Плохое планирование, некачественное расписание, приоритизация, не синхронизированный процесс; например: работа выполняется последовательно в то время как может выполняться параллельно
Переключение между задачами
Прерывания, требующие изменения направления движения /мышления; например: встречу могут прерывать выполнение других задач
Ограничение возможностей и выгорание
Прерывание выполнения работы из-за недоступности ресурсов или превышения возможностей; например: слишком большое количество одновременно выполняемых проектов может привести к выгоранию сотрудников
Недостаток в требуемых компетенциях
Недостаток навыков или знаний, требуемых для выполнения задачи; например: неэффективное использование IT-инструментов из-за недостаточных навыков
Нечеткие цели, видение
Разобщенные цели и видение в отношении друг с другом, например, в требованиях; например: сотрудники двигаются в разном направлении, что снижает эффективность
Перегрузка информацией
Большие размеры партий работы (batch size), распространение и хранение ненужной информации; например: слишком большое количество информации усложняет процесс поиска релевантной информации
Нечеткие ответственности
Нечеткие ожидания в отношении производительности и организационных ролей; например: наложение компетенций и ролей
Недостаточные коммуникации
Коммуникации требуют значительного времени и усилий, при этом не добавляя ценности; например: недостаточная коммуникация ведет к исправлению неверной выполненной работы (rework)
Множественная интерпретация информации
Форма представления информации ведет к возможности множественной интерпретации; пример: отсутствие стандарта документирования
Доступность информации
Невозможность получить доступ к информации в тот момент, когда она требуется;
Недоутилизация
Использование навыков и компетенций не самым эффективным способом
Оверинжинирнг
Добавление фич, которые не добавляют ценности клиенту; пример: возросшая стоимость разработки и поддержки как результат избыточных требований
Ненужное преобразование данных
Перевод данных из одного формата в другой из-за использования неподходящих инструментов и недостатка в стандартизации; пример: переформатирование или повторный ввод данных
Недостаток в распространении знаний
Отсутствие обмена информацией, экспертизой и навыками; пример: старт новых проект не использует опыт, полученный при старте прошлых проектов
Обработка ошибочной информации
Обработка информации, основанной на правильных потребностях, но потребности не полностью удовлетворены; пример: при обработке информации не выявлена ее дефектность, что влияет на другие процессы
Изменение требований
Внутреннее или внешнее изменение требований; пример: изменения могут привести к rework, особенно если они произошли в конце процесса
Барьеры в кооперации
Нежелания взаимодействия; пример: недостаточное владение ведет к снижению мотивации
Неэффективная верификация
Неэффективное тестирование, прототипирование, подтверждение; например — поддержка тестов стоит дороже, чем тем риски, которые они митигируют
Плохая координация
Плохое планирование, некачественное расписание, приоритизация, не синхронизированный процесс; например: работа выполняется последовательно в то время как может выполняться параллельно
Переключение между задачами
Прерывания, требующие изменения направления движения /мышления; например: встречу могут прерывать выполнение других задач
Ограничение возможностей и выгорание
Прерывание выполнения работы из-за недоступности ресурсов или превышения возможностей; например: слишком большое количество одновременно выполняемых проектов может привести к выгоранию сотрудников
Недостаток в требуемых компетенциях
Недостаток навыков или знаний, требуемых для выполнения задачи; например: неэффективное использование IT-инструментов из-за недостаточных навыков
Нечеткие цели, видение
Разобщенные цели и видение в отношении друг с другом, например, в требованиях; например: сотрудники двигаются в разном направлении, что снижает эффективность
Перегрузка информацией
Большие размеры партий работы (batch size), распространение и хранение ненужной информации; например: слишком большое количество информации усложняет процесс поиска релевантной информации
Нечеткие ответственности
Нечеткие ожидания в отношении производительности и организационных ролей; например: наложение компетенций и ролей
Недостаточные коммуникации
Коммуникации требуют значительного времени и усилий, при этом не добавляя ценности; например: недостаточная коммуникация ведет к исправлению неверной выполненной работы (rework)
Множественная интерпретация информации
Форма представления информации ведет к возможности множественной интерпретации; пример: отсутствие стандарта документирования
Доступность информации
Невозможность получить доступ к информации в тот момент, когда она требуется;
Недоутилизация
Использование навыков и компетенций не самым эффективным способом
Оверинжинирнг
Добавление фич, которые не добавляют ценности клиенту; пример: возросшая стоимость разработки и поддержки как результат избыточных требований
Ненужное преобразование данных
Перевод данных из одного формата в другой из-за использования неподходящих инструментов и недостатка в стандартизации; пример: переформатирование или повторный ввод данных
Недостаток в распространении знаний
Отсутствие обмена информацией, экспертизой и навыками; пример: старт новых проект не использует опыт, полученный при старте прошлых проектов
Обработка ошибочной информации
Обработка информации, основанной на правильных потребностях, но потребности не полностью удовлетворены; пример: при обработке информации не выявлена ее дефектность, что влияет на другие процессы
Изменение требований
Внутреннее или внешнее изменение требований; пример: изменения могут привести к rework, особенно если они произошли в конце процесса
Барьеры в кооперации
Нежелания взаимодействия; пример: недостаточное владение ведет к снижению мотивации
🧩 Виды прототипов в связке с архитектурой
Макет/демо
Цель – получить представление о том, как продукт должен выглядеть. Можно сделать на основе одной или нескольких историй, учитывая, что вы строите продукт основываясь на воображении, а не на действительной обратной свзязи. Люди не оценивают макет так же, как они оценивают продукт. Отсюда можно получить первые очертания NFR.
Spike
Цель – лучше понять проблемную область. Сохраняется только результат исследования, код уничтожается.
MVP
Цель – выпустить минимальное жизнеспособное решение относительно самого себя в будущем, но конкурентноспособное относительо рынка.
Ходячий скелет
Форма PoC для основной концепции архитектуры. Специализируется на реализации одной самой простой функциональности, минималистичной реализации end-to-end сценария. Это не точное отражение архитектуры, лишь «скелет», который тем не менее должен быть «ходячим», то есть потенциально мы имеем возможность отгрузить его заказчику. Он должен быть покрыт тестами.
Alistair Cockburn очень точно описал этот феномен (http://alistair.cockburn.us/Walking+skeleton):
A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in working, shippable and testable code. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.
Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A skeleton of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.
Макет/демо
Цель – получить представление о том, как продукт должен выглядеть. Можно сделать на основе одной или нескольких историй, учитывая, что вы строите продукт основываясь на воображении, а не на действительной обратной свзязи. Люди не оценивают макет так же, как они оценивают продукт. Отсюда можно получить первые очертания NFR.
Spike
Цель – лучше понять проблемную область. Сохраняется только результат исследования, код уничтожается.
MVP
Цель – выпустить минимальное жизнеспособное решение относительно самого себя в будущем, но конкурентноспособное относительо рынка.
Ходячий скелет
Форма PoC для основной концепции архитектуры. Специализируется на реализации одной самой простой функциональности, минималистичной реализации end-to-end сценария. Это не точное отражение архитектуры, лишь «скелет», который тем не менее должен быть «ходячим», то есть потенциально мы имеем возможность отгрузить его заказчику. Он должен быть покрыт тестами.
Alistair Cockburn очень точно описал этот феномен (http://alistair.cockburn.us/Walking+skeleton):
A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in working, shippable and testable code. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.
Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A skeleton of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.
Краткая выжимка из ответов на вопрос о распределении данных из чата по микросервисам, показалось важным, так как ситуация распространенная:
Вопрос
Есть два микросервиса: документы и авторизация. Документы реализует всю свою бизнес логику, авторизация свою. В документе есть ссылка на пользователя из авторизационного сервиса. Например я делаю грид с документами, где я должен показать не просто id пользователя а его имя фамилию. В каком месте правильнее переводить ID в имя фамилию? На стороне сервиса документов или на стороне UI?
Ответ
Если подойти к вопросу с позиции предметно-ориентированного проектирования.
Например, у меня есть договор найма. Я меняю фамилию (и паспорт). Это не приводит к автоматическому изменению моих имени и фамилии в договоре найма, это приводит к запуску еще одного (или многих) процесса, кульминацией которого будет изменение договора найма или допник или еще что-то. То есть сервис документов должен узнать, что произошли изменения и выполнить какие-то действия, зафиксировать сам факт изменений, а не просто отобразить при следующем обращении в документе новые имя и фамилию.
В такой ситуации стоит рассмотреть вариант хранения имени и фамилии в сервисе документов, так как в описанной ситуации они относятся к модели работы с документами. При необходимости можно обновлять данные об имени и фамилии на основе события-уведомления из сервиса авторизации.
С другой стороны, если это только чтение и никакой логики касательно имени и фамилии нет в предметной области (которая шире кода), то BFF здесь выглядит наиболее рациональным. Да в этом случае это дополнительные накладные расходы, – дополнительный сервис, кодинг, деплой и проч, но зато чистый сервис документов, который ничего не знает о сервисе авторизации и его API + масштабирование выглядит более простым в случае необходимости.
И, конечно, всегда есть простой вариант в виду вызова API сервиса авторизации, но это связывает сервисы документов и авторизации напрямую, что создает между ними достаточно сильную зависимость и, возможно, порождает потребность в координации.
Ссылка на оригинальное обсуждение: https://tttttt.me/microservices_ru/26794
Вопрос
Есть два микросервиса: документы и авторизация. Документы реализует всю свою бизнес логику, авторизация свою. В документе есть ссылка на пользователя из авторизационного сервиса. Например я делаю грид с документами, где я должен показать не просто id пользователя а его имя фамилию. В каком месте правильнее переводить ID в имя фамилию? На стороне сервиса документов или на стороне UI?
Ответ
Если подойти к вопросу с позиции предметно-ориентированного проектирования.
Например, у меня есть договор найма. Я меняю фамилию (и паспорт). Это не приводит к автоматическому изменению моих имени и фамилии в договоре найма, это приводит к запуску еще одного (или многих) процесса, кульминацией которого будет изменение договора найма или допник или еще что-то. То есть сервис документов должен узнать, что произошли изменения и выполнить какие-то действия, зафиксировать сам факт изменений, а не просто отобразить при следующем обращении в документе новые имя и фамилию.
В такой ситуации стоит рассмотреть вариант хранения имени и фамилии в сервисе документов, так как в описанной ситуации они относятся к модели работы с документами. При необходимости можно обновлять данные об имени и фамилии на основе события-уведомления из сервиса авторизации.
С другой стороны, если это только чтение и никакой логики касательно имени и фамилии нет в предметной области (которая шире кода), то BFF здесь выглядит наиболее рациональным. Да в этом случае это дополнительные накладные расходы, – дополнительный сервис, кодинг, деплой и проч, но зато чистый сервис документов, который ничего не знает о сервисе авторизации и его API + масштабирование выглядит более простым в случае необходимости.
И, конечно, всегда есть простой вариант в виду вызова API сервиса авторизации, но это связывает сервисы документов и авторизации напрямую, что создает между ними достаточно сильную зависимость и, возможно, порождает потребность в координации.
Ссылка на оригинальное обсуждение: https://tttttt.me/microservices_ru/26794
Требования безопасности.pdf
121.5 KB
Нашел в архиве требования безопасности, уж не помню к какому точно проекту формулировал, еще в 2012-м году, может кому-то будет полезно.
Делайте скидку на то, что это было почти 12 лет назад, появились новые угрозы, но что-то почерпнуть точно можно :)
Делайте скидку на то, что это было почти 12 лет назад, появились новые угрозы, но что-то почерпнуть точно можно :)
Почти совсем оффтопик.
Очень давно посмотрел этот ролик и все никак не мог потом найти, – название не запомнил. А запомнился он мне ровно тем, что, казалось бы, 1986-й год, а многие компании работают, продукты разрабатываются и архитектурные решения принимаются ровно так, как описал Михаих Жванецкий.
Кто не видел – не пожалейте времени, всего 6 минут. Это шедевр 🙂
Михаил Жванецкий - Паровоз для машиниста (1986)
https://www.youtube.com/watch?v=srfeL88Oov8
Очень давно посмотрел этот ролик и все никак не мог потом найти, – название не запомнил. А запомнился он мне ровно тем, что, казалось бы, 1986-й год, а многие компании работают, продукты разрабатываются и архитектурные решения принимаются ровно так, как описал Михаих Жванецкий.
Кто не видел – не пожалейте времени, всего 6 минут. Это шедевр 🙂
Михаил Жванецкий - Паровоз для машиниста (1986)
https://www.youtube.com/watch?v=srfeL88Oov8
YouTube
Михаил Жванецкий монолог Паровоз для машиниста
Михаил Жванецкий монолог Паровоз для машиниста. 1986 год, предача Вокруг смехаЗдесь хорошо там, где нас нет!
И вдогонку еще статья, McAfee перешел на микросервисы и в статье есть интересные моменты об их опыте.
Оставлю один тут, как опорный, чтобы потом можно было вспомнить и найти :)
If I'm a McAfee user, what are the five things that a user can do? It shouldn't overreach. It should be complete. And you should provide all of that functionality. It's almost like taking these little, itsy, bitsy pieces of things that you can stitch together. And then you think ‘that’s a noun, what does it provide in terms of verbs that can be done to it?
Or what can it do to other nouns in the system? So that's the domain decomposition, which is the first exercise.
https://diginomica.com/mcafee-adopts-microservices-using-confluent-cloud-scale-its-architecture-and-services?amp
Оставлю один тут, как опорный, чтобы потом можно было вспомнить и найти :)
If I'm a McAfee user, what are the five things that a user can do? It shouldn't overreach. It should be complete. And you should provide all of that functionality. It's almost like taking these little, itsy, bitsy pieces of things that you can stitch together. And then you think ‘that’s a noun, what does it provide in terms of verbs that can be done to it?
Or what can it do to other nouns in the system? So that's the domain decomposition, which is the first exercise.
https://diginomica.com/mcafee-adopts-microservices-using-confluent-cloud-scale-its-architecture-and-services?amp
Микросервисы / распределенные системы
Первый публичный заход. Сегодня на it-picnic.ru расскажу о быстром восстановлении архитектурных знаний. Выступление построил практико-ориентированным, то есть буквально, что делать по дням, чтобы быстро получить широкий спектр архитектурных знаний, когда…
ArchDays занял столько времени, что подготовить не оказалось времени, а на пикнике не велась запись.
Так что, – надо повторить :)
К концу месяца доработаю выступление, добавив в него деталей и сделаю онлайн выступление.
Скоро анонс, а пока можете написать в комментарии к этому сообщению свои вопросы или идеи (может кто из канала был на выступлении, какие темы были не раскрыты или раскрыты не полностью).
А кто хочет погрузиться глубже, – начинайте с гугления ATAM и CBAM, проверенные годами подходы, а позже я напишу какие с ними проблемы (точнее, – не с ними, с аудируемыми решениями, но сути это не изменит).
Так что, – надо повторить :)
К концу месяца доработаю выступление, добавив в него деталей и сделаю онлайн выступление.
Скоро анонс, а пока можете написать в комментарии к этому сообщению свои вопросы или идеи (может кто из канала был на выступлении, какие темы были не раскрыты или раскрыты не полностью).
А кто хочет погрузиться глубже, – начинайте с гугления ATAM и CBAM, проверенные годами подходы, а позже я напишу какие с ними проблемы (точнее, – не с ними, с аудируемыми решениями, но сути это не изменит).
Кто использует https://raml.org для API?
Поделитесь впечатлениями.
Поделитесь впечатлениями.
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Через 5 минут ArchDays MeetUp.
Тема: «Сага - решение технической проблемы или доменный процесс?».
🟢 Михаил Натаров, расскажет: если поискать доклады про саги, то они делятся на два типа. В первом говорят, что саги - это про распределенные транзакции. Во втором - что саги это описание процессов в домене. В докладе спикер поделится плюсами и минусами каждого из подходов, и вместе посмотрим на примерах когда "контекст и движок", а когда это скорее про DDD и "доменные саги".
🔜 Ссылка на трансляцию
Тема: «Сага - решение технической проблемы или доменный процесс?».
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Media is too big
VIEW IN TELEGRAM
На прошлой неделе я вошел в высший совет профсоюза ИТ-специалистов «ПРО-ИТ».
Профсоюз ПРО-ИТ - это сообщество, которое защищает интересы IT-специалистов.
То есть первоочередная роль профсоюза в том, чтобы оказывать юридическую помощь, но немаловажную роль играет и развитие индустрии через помощь в развитии людей.
Конкретно я займусь развитием ветки по архитектуре и всему, что с ней связано, хотя уже внес ряд предложений по решению проблем индустрии в целом.
Будут и совместные проекты ассоциации и профсоюза.
Официальный сайт профсоюза: https://proito.org
Если захотите вступить, укажите в форме вступления код приглашения ARCH
На видео Алексей Мариза на открытии ArchDays рассказывает о профсоюзе и том, что он может дать.
За дело :)
Профсоюз ПРО-ИТ - это сообщество, которое защищает интересы IT-специалистов.
То есть первоочередная роль профсоюза в том, чтобы оказывать юридическую помощь, но немаловажную роль играет и развитие индустрии через помощь в развитии людей.
Конкретно я займусь развитием ветки по архитектуре и всему, что с ней связано, хотя уже внес ряд предложений по решению проблем индустрии в целом.
Будут и совместные проекты ассоциации и профсоюза.
Официальный сайт профсоюза: https://proito.org
Если захотите вступить, укажите в форме вступления код приглашения ARCH
На видео Алексей Мариза на открытии ArchDays рассказывает о профсоюзе и том, что он может дать.
За дело :)