Продажа проектов домов, проектов коттеджей
На этой странице Вы можете получить информацию о наших услугах, их составе, объеме, получаемом Вами на каждом этапе сотрудничества. Все ниже перечисленные услуги могут быть предоставлены, как единым пакетом, так и поэтапно или в объеме индивидуально сформулированном в соответствии с вашими пожеланиями и потребностями.
Услуги
Проектирование загородных домов, коттеджных поселков, жилых домов, административных зданий, перепланировка квартир, интерьеры.
Наше бюро оказывает весь спектр проектных услуг необходимых для решения комплекса задач, возникших при строительстве, реконструкции и отделке. Нами выполняются все архитектурные, конструктивные, инженерные и технологические разделы проекта. После завершения проектных работ по желанию Заказчика нами осуществляется авторский надзор, сопровождение проекта.
Авторский надзор.
Авторский надзор производится с момента начала строительства и до момента полного окончания работ, предусмотренных проектом, заключается в контроле за соответствием выполняемых работ проектным решениям, а также выявлении необходимости их корректировки, информировании об этом Заказчика. Количество и режим посещений авторского надзора определяется договором и согласовывается с лицами, ведущими технический надзор (контроль качества строительно-монтажных работ).
Архитектурное сопровождение строительства.
Является комплексом консалтинговых услуг и включает в себя: авторский надзор, корректировку проектных решений по заданию Заказчика, консультационные и информационно-маркетинговые услуги.
Проекты повторного применения.
Для разработки индивидуального проекта требуется значительное время В некоторых случаях целесообразно использовать ранее разработанные проекты, что позволяет значительно уменьшить сроки и стоимость проектирования. Мы поможем Вам подобрать проект, максимально отвечающий вашим требованиям, выполним необходимую корректировку и привязку проекта.
Предпроектные исследования.
Являются обязательным этапом. Необходимы для оценки реальности поставленных задач, их соответствие полученной исходно-разрешительной документации существующим градостроительным ограничениям, геодезическим и конструктивным условиям, существующим нормам и правилам.
На основании исследований совместно с Заказчиком разрабатывается Техническое задание (ТЗ) будущего проекта, в котором описывается технико-экономические показатели, инженерное оснащение, определяется объем проектных услуг.
Фор проект (концепция).
Проработка этой стадии может происходить параллельно с предпроектными исследованиями и основывается на его результатах и требованиях ТЗ.
В процессе работы на основе вариантного проектирования и рассмотрения аналогов определяется стилевое направление, архитектурно-планировочное решение, ориентировочные технико-экономические показатели.
На основании проделанной работы и согласованных Заказчиком решений, выпускается отчет в виде альбома, в который входят: схема функционального зонирования, предварительные архитектурно-планировочные решения, технико-экономические показатели. Отчет принимается Заказчиком и служит основанием для проработки утвержденных решений на следующих стадиях проектирования.
Эскизный проект.
На этой стадии происходит проработка и конкретизация ранее принятых решений. Окончательно утверждаются архитектурно-планировочные решения, применяемые строительные материалы и технологии, отделка, инженерное оборудование, интерьерные решения (если разрабатывается проект интерьера). По окончании стадии Заказчик получает отчет, содержащий: архитектурные чертежи, схемы расположения инженерного оборудования, служащие заданием для последующей разработки инженерных разделов, пояснительную записку по используемым строительным материалам и технологиям, конструктивным и инженерным решениям, принятым в проекте, уточненные технико-экономические показатели.
Рабочий проект.
На этой стадии происходит разработка проектной документации в объеме, необходимом для производства строительно-монтажных работ, окончательная корректировка и увязка архитектурных, конструктивных и технологических решений, разработка инженерных разделов проекта: электрика, слабые токи, отопление и вентиляция, водоснабжение и канализация. Разработка конструктивных узлов и деталей, спецификации на объемы работ, оборудование. Отчет этой стадии передается Заказчику для передачи Подрядчику и Поставщикам. Отчет служит основанием для оказания нами и третьей стороной последующих услуг: авторского надзора, архитектурного сопровождения, строительства, консалтинговых и управленческих услуг, комплектацию объекта.
Архитектурное сопровождение
Наша мастерская выполняет услуги по сопровождению проекта начиная от стадии тендера до окончательной реализации.
Архитектурное сопровождение, технический надзор, управление и ведение проектов по ландшафтному дизайну.
В этом случае наша задача следить за проектными работами и ходом всех работ вплоть до строительства, озеленения и завершения проекта.
Мы предлагаем услуги по управлению проектом. Это означает, что мы можем участвовать в проекте на этапе строительства. Это участие является гарантией сохранения целостности дизайна от начала до конца.
Преимущества нашего участия во время строительства заключаются в следующем:
Сопровождать процесс строительства и озеленения, чтобы он соответствовал утвержденному проекту. Гарантия, что работы выполняются по плану – уменьшает риск задержек или проблем
Обеспечение обмена информацией и прозрачность между подрядчиками и клиентом.
ArchOps и как мы до него дошли
Всем привет! Недавно у нас в MTS DIgital прошла десятая научно-техническая конференция Hello, conference!, докладами с которой хотелось бы поделиться с сообществом. В этой статье руководитель центра RnD MTS Digital Дмитрий Дзюба и руководитель направления системной архитектуры MTS Digital Александр Петрухина расскажут про ArchOps.
Для любителей видео доклады с конференции доступны в записи.
ПРИМЕР 1: Когда хотели как лучше
Наш рассказ называется «Что такое ArchOps» и чтобы это было лучше понятно на примере, мы покажем, как вообще устроен архитектурный процесс в больших организациях.
Начнем с небольшой истории, которая произошла какое-то время назад у нас в компании. Задались мы, как архитекторы, целью навести порядок в интеграции, имеющейся в наших корпоративных приложениях.
Вы знаете, что в больших компаниях их может быть достаточно много, и это реально сотни типов информационных систем.
Архитекторам всегда хочется построить красивую и гармоничную архитектуру. И прежде чем начать глубокий рефакторинг IT-ландшафта, нам нужно определить принцип и порядок, как это должно происходить. Самый простой способ — начать с интеграционной архитектуры и декомпозировать ландшафт на набор bounded contexts, взаимодействующих через Open Host Service.
За основу мы взяли, наверное, многим из вас известный манифест Джеффа Безоса, который в какой-то момент времени задал общий принцип, как должны строиться приложения внутри Amazon.
Этот принцип заключается в том, что все должно иметь интерфейсы, приложения должны создаваться с учетом того, что их функциональность будет предоставлена через интерфейсы. Эти интерфейсы – единственный способ взаимодействия.
Очень важная составляющая этого мандата — его «мотивационная» часть. Что все, кто не будет так делать, будут уволены, и всем хорошего дня. Мы, конечно, так не могли сделать, поэтому решили пойти вглубь и немного его специализировать. Помочь нашим разработчикам понять, что такое интерфейсы, как они должны строиться.
Здесь нам на помощь пришла сервис-ориентированная архитектура – достаточно старый принцип, который содержит в себе части, описанные на картинке.
При этом сама корпоративная архитектура здесь больше как консультант-советчик и, конечно, автор различных стандартов, которые в компании внедряются.
Мы создали набор правил и политик с помощью которых описали все, вышеописанные принципы. И провели набор мероприятий по доведению новых принципов до команд.
Затем мы хотели получить классическую картину интеграции приложений на основе API Gateway. В ней у нас есть некоторая система, она взаимодействует с API Gateway по REST-протоколу, на API gateway происходят стандартные функции, такие как трансформация данных, изменение роутинга и так далее, а дальше происходят вызовы уже непосредственно самих систем. То есть такое контролируемое управление API.
В некоторых случаях мы действительно получили такую картину:
Но если приглядеться, она могла быть уже и не такая, то есть протоколы были уже не везде REST, где-то появился более старомодный SOAP (Xml WebServices), где мы обращаемся не к ресурсам, а вызываем какие-то функции. Просто потому что в данном случае команде было удобно вызвать какую-то функцию.
У нас неожиданно появилось несколько API gateways, потому что они оказались разными, какой-то удобнее, какой-то нет.
И самое неожиданное, у нас появилось еще то, что внутри некоторых API gateways стали зарождаться свои системы, реализующие custom-бизнес логику.
То есть, часть логики ушла из конкретных систем и продуктов в API gateway и там появилась уже полноценная enterprise service bus, которая непонятно, к чему относится и непонятно, как поддерживается. То есть результат мы получили не совсем такой, как хотели.
Итог такой, что вроде бы у нас стандартный процесс: мы как архитекторы придумали решение, мы его описали, мы его дали командам, но при этом единого решения у нас не получилось. И каждое отклонение от идеального решения, про которое я говорил, всегда имело какой-то смысл, всегда команда могла это обосновать. Как результат, у нас архитектура оказалась оторвана от реальности. Появляется логичный вопрос…
Почему так вышло?
Я думаю, эта картина более-менее всем знакома, это типичная ситуация башни из слоновой кости, когда архитектор диктует некие правила, policy и стандарты и так далее, и высокоуровневый landscape кидает в команду.
Команда, естественно, слабо понимает, что из этого должно получиться. Какое-то представление конечно имеется, но непонятно как именно должно быть реализовано.
Минусы такого подхода в том, что диалог, по сути, односторонний, это монолог архитектора в сторону команды, обратная связь обычно слабая или отсутствует, и на выходе получается не то, что планировали изначально.
В команду сыплется целый поток артефактов: это и высокоуровневая архитектура, и какая-то solution-архитектура, которая, вполне возможно, им не понятна, это и разные policy и стандарты.
Какие из них применимы в текущей ситуации, а какие нет – команда почему-то должна решать сама, из-за этого сроки затягиваются, потому что у команды, возможно, не хватает экспертизы, бизнес еще дает задачи с дедлайнами, и поэтому команда принимает решение то, как она его видит, то, как она его может реализовать, а не то, как оно было запланировано изначально.
ArchOps
Чтобы разрушить эту башню из слоновой кости, у нас существует подход, который называется ArchOps, (да, почти как DevOps, но он про архитектурный процесс).
Начинается все с того, что нас есть какой-то продукт, есть типичный процесс команды по разработке этого продукта, и есть какие-то высокоуровневые требования на уровне компании.
Что делает ArchOps: у нас добавляется архитектурное планирование, на котором эта стрелочка показывает не одностороннее взаимодействие, это некий тачпойнт с командой, это диалоги – где в команду вбрасывается целевая архитектура именно их продукта, а не какая-то общая.
На втором этапе у нас есть архитектурное сопровождение, где команды и архитекторы общаются через артефакт, называемый Architecture decision records (ADR), дальше на нем остановимся подробнее. Они обмениваются артефактами и выстраивают то решение, которое должно получиться, так, чтобы оно угодило и команде, которая бы понимала его, и угодило архитектуре, потому что, по сути, enterprise архитектура – это требования бизнеса.
На последнем этапе у нас идет надзор и стандартизация. Если были выявлены какие-то отклонения в реализации – это, по сути, наполнение бэклога технического долга команды, то есть это то, что было реализовано в угоду скорости или еще чему-то, например, выводу фичи скорее в продакшн, не так, как планировалось изначально. И это тоже добивается этими же ADR.
Как итог, мы имеем диалог между командой и архитекторами, команда и архитекторы выступают почти на равных, то есть они могут принимать решения по изменению архитектуры или принимать другие решения и обосновать их. И на выходе всем проще, потому что изначально что планировалось, то и получилось, бизнес тоже доволен.
Теперь посмотрим, какие же артефакты у нас ходят. Это, собственно, сам ADR, Architecture decision records и solution-архитектура как набор подкрепляющих артефактов. ADR-log позволяет не только посмотреть эволюцию архитектуры на всех уровнях (от enterprise до продуктовой) но и понять мотивацию принимаемых решений.
Все остальные стандарты, policy и все высокоуровневое – укладываются в этот ADR, описывающий именно то инкрементное изменение, которое должна сделать команда. Соответственно, команде проще, потому что у нее теперь есть понятный артефакт, по которому она двигается.
Что же такое ADR? Здесь на иллюстрации показана реализация m ADR – стандартного шаблона ADR в формате MarkDown.
ADR состоит из двух файлов, это MarkDown-файл, который описывает шаблонизированный подход к описанию проблемы, какие решения были приняты, какие у них плюсы и какие минусы, и некий puml (PlantUML), который обычно описывает либо sequence диаграмму, либо С4 в зависимости от контекста и потребностей этого ADR.
В данном, упрощенном, примере ADR видно, что есть какая-то проблема, есть какие-то пути ее решения, есть плюсы и минусы, и итог, что же должно произойти. И, обычно это еще подкреплено некой диаграммой.
Диаграммы и сам ADR складываются в некий архитектурный лог, обычно он контролируется в version control в Git. Команда может обращаться к этому логу как к базе знаний. Еще, это облегчает онбординг новых сотрудников, которые из ADR (в котором все описано) смогут понять, почему были приняты те или иные решения.
Стоит добавить, что появляется еще и роль solution архитектора. Есть, конечно, простые продукты, где в принципе архитектура и команда могут общаться через ADR, но в больших корпорациях обычно есть еще продукты, которые реализуются несколькими командами, то есть это какой-то суперпродукт.
В экосистеме есть хороший пример, что есть несколько компаний участвующих в создании сквозного решения, и вам нужен кто-то, кто может курировать всю архитектуру сложного проекта. Обычно на эту роль выделяется solution архитектор, который общается с командами посредством ADR, и команды через архитектурный лог могут видеть, что происходит в соседних командах, и как-то принимать решения, которые позволят сделать его лучше.
Пример 2: Платформизация
Давайте постараемся понять — а всегда ли нужен такой сложный процесс, если мы хотим внедрять общие архитектурные паттерны в сложном ИТ-ландшафте. Для этого наш второй пример.
Как вы уже догадались из контекста первого примера в начале статьи, IT-ландшафт в крупных компаниях достаточно сложный, и часто возникает задача вообще понять, как реальные системы взаимодействуют друг с другом. Это называется решением задачи наблюдаемости на IT-ландшафте.
Как мы подошли к этой задаче? Во-первых, наблюдаемость, а это естественное свойство любой архитектурной системы, решается так или иначе в каждом конкретном IT-продукте.
Обычно это делается с помощью одного или нескольких аспектов:
Трассировка — когда мы все запросы, которые проходят через систему, как-то отслеживаем и понимаем логику прохождения общих сценариев и вариантов использования через наши компоненты внутри системы.
Логирование всех событий, которые вообще происходят в системе.
Подсчет различных ключевых метрик (например производительности), которые позволяют нам понять насколько наше приложение здорово. Обычно это делается внутри самой системы. Но теперь нам нужно было исследовать весь ландшафт.
У нас есть на ландшафте большой набор систем, которые взаимодействуют друг с другом (на картинке они показаны как A, B, C, D, E). Они могут решать какую-то непростую задачу, которая задействует десятки сложных систем – класса Business Support System или Operation Support System. И нам важно понимать, в каком состоянии находится процесс, где он тормозит, как он проходит через системы, какие системы работают эффективно, а какие не очень.
Здесь очень важно отслеживать сквозной процесс прохождения между всеми системами и для этого у нас в компании есть замечательная платформа наблюдаемости. Возможно, многие про нее слышали, мой коллега Филипп Бочаров, автор этой платформы, много выступает с ней на конференциях, поэтому я здесь сильно не буду сильно пускаться в детали и устройства.
Суть платформы наблюдаемости в том, что она построена на наборе опенсорсных компонентов, которые любая продуктовая команда может встроить в свой продукт и подключиться к единому полю наблюдаемости, которое формируется на IT-ландшафте. После чего мы начинаем получать информацию о том, как идут конкретные вызовы.
Что здесь было важно в этом процессе: мы точно так же определили принцип и конкретный способ решения задачи. Но вместо создания сложных артефактов мы создали платформу, и у нас появилась платформенная команда, которая помогала конкретным разработчикам внедрять внутрь себя вот эти инструменты, фактически реализовывать наш принцип.
В итоге большинство команд внедрило эту платформу, у нас появилась возможность автоматически строить карту вызовов на IT-ландшафте, стало проще им управлять и оптимизировать.
Можно сказать, ну вот же, задача похожая и все получилось без всяких ArchOps. В чем же здесь разница?
Отличия ArchOps от решения с платформой
Разница действительно достаточно минимальна, основное отличие решения с платформой от ArchOps в том, что теперь мы дали разработчикам не только какое-то задание команде, но и предложили вариант решения, через который они могут зайти, с понятным порогом входа, с понятной документацией и с командой этой платформы, которая облегчала онбординг.
То есть теперь появился коридор, по которому команда может зайти на платформу и реализовать то или иное запланированное решение.
Что же такое ArchOps?
Это не конкретное решение, не конкретный инструмент, это набор базовых принципов, которые стоит применять, когда у вас действительно очень большая компания, очень сложный IT-ландшафт и вы хотите получить централизованное управление.
И здесь нужно фокусироваться на трех принципах:
Архитектурный проект: что это
Архитектурные проект представляет собой строительную документацию, точнее, ту ее часть, которая должна содержать архитектурные планы и решения, объем которых должен быть достаточным для того, чтобы разработать остальную строительную документацию для зданий, в проектировании которых должен принимать участие архитектор.
В процессе разработки архитектурного проекта на каждой его стадии все принятые решения должны строго соответствовать всем необходимым требованиям и нормам. Все архитектурные проекты и решения должны учитывать следующие требования:
Какова цель разработки архитектурного проекта?
Главная цель любого архитектурного проекта – как можно более подробно описать и объяснить все инженерные или декоративные решения, основываясь на общепринятые нормативы и стандарты, при этом не нарушая их.
Кому нужен архитектурный проект? В первую очередь, наличие проекта требуют власти, которым он необходим для проверки соответствия объекта СНиПам и государтсвенным стандартам. Кроме того, архитектурный проект нужен самим строителям, чтобы правильно реализовать все идеи заказчика.
Место и значение архитектурного проекта в строительной документации
Создание архитектурно – строительного проектирования осуществляется в соответствии со статьей 48 ГСК РФ. Проект разрабатывается путем создания и подготовки проектной документации для объектов капитального строительства, а также к частям объектов, которые возводятся или находятся в процессе реконструкции на территории земельного участка, который принадлежит застройщику. Архитектурный проект разрабатывается также в случае проведения капитальных ремонтных работ объектов капитального строительства. В этом случае проект необходим, если в процессе ремонта будут затронуты конструктивные характеристики здания, от которых зависит их надежность и безопасность.
Архитектурно-проектная документация является предметом государственной экспертизы, и, одновременно, основанием для выдачи разрешения на строительство. Пункт 4 «Положения о составе разделов проектных документов и требованиям к их содержанию» включает в себя следующие указания на разработку документации.
Для того чтобы эффективно реализовать в процессе строительства все необходимые архитектурные, технические и прочие решения, которые указаны в проектных документах на объект капитального строительства, должна быть разработана рабочая документация, в состав которой входят текстовые документы, чертежи, все спецификации оборудования, изделий, и т.д.
Что включает в себя архитектурный проект
Примерный список необходимых документов для архитектурного проекта, который указан в законодательстве РФ:
Этот список не является полным и может корректироваться в зависимости от места расположения объекта строительства.
Типы архитектурных проектов
Архитектурные проекты, существующие сегодня, делятся на следующие типы:
Типовые архитектурные проекты чаще всего разрабатывают компании, которые задействованы в индивидуальном строительстве. Такой проект включает в себя документацию, которая нужна для получения разрешения на проведение строительных работ.
Эскизный проект включает в себя только внешнее изображение объекта строительства – его эскиз. После разработки эскизного проекта все последующие расчеты, включая работу архитектора фирма-застройщик должна обеспечивать отдельно. Спроектировать здание таким способом очень дорого и сложно.
Наибольшей популярностью пользуются готовые архитектурные проекты. Здания, которые были построены по готовому проекту, очень любят инвесторы. Кроме того, они обладают высокой ликвидностью на рынке недвижимости, и надежны для самих владельцев. Кроме того, дом, построенный по готовому проекту, один из самых экономных, так как на его строительство уходит намного меньше времени и денег, чем на строительство зданий по эскизу или типовому проекту.
Видео о подаче архитектурного проекта:
Состав проекта. Конструктивные и архитектурные решения в проекте
Архитектурный проект состоит из двух разделов: раздел Архитектурных решений, и Раздел конструктивных решений. Раздел архитектурных решений, в свою очередь включает в себя два подраздела: графический и текстовый. В текстовую часть проекта входят:
Графическая часть архитектурного проекта включает в себя:
В разделе конструктивных решений находится описание таких характеристик будущего здания и земельного участка:
В графическую часть входят планы и чертежи кровли, межэтажных перекрытий, фундамента здания, и план каждого этажа.
Этапы разработки архитектурного плана
В данном разделе представлен пошаговый алгоритм разработки архитектурного плана. Этапы разработки архитектурной документации следующие:
Для чего необходим архитектурный проект здания?
В случае отсутствия архитектурного проекта возможны следующие негативные последствия:
Хороший архитектурный план, разработанный профессионалом, полностью оправдывает себя в финансовом плане – как входе строительства, так и по его завершению.
Видео о составе архитектурного проекта: