лср по лэу что это

Обучающий курс по работе с программой «ГРАНД-Смета»

Группы выходных форм

Теперь давайте пробежимся по группам выходных форм, которые входят в состав дистрибутива ПК «ГРАНД-Смета». Открываем на панели инструментов вкладку Файл и выбираем пункт Формы для печати. Далее выбираем раздел Образцы форм.

Каждая группа выходных форм предназначена для конкретного типа документов. Например, форма Объектная смета будет доступна только из расчёта объектной сметы. Если у вас в программе открыт какой-либо сводный сметный расчёт, то и для формирования выходного документа вы сможете выбрать только формы, предназначенные для сводного сметного расчёта. А формы локальных или объектных смет в списке выходных форм в этом случае будут неактивными.

Давайте заглянем в папку с выходными формами локальных смет.

Локальные сметы могут быть рассчитаны базисно-индексным методом или ресурсным методом. Для каждого метода предусмотрены свои выходные формы. Отдельно выделена папка с формами для смет на пусконаладочные работы.

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

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

Ещё несколько слов о многообразии выходных форм локальных смет.

Изначально общепринятая форма локальной сметы, так называемая Форма № 4, была введена в МДС 81-35.2004. В этой форме по каждой позиции выводится стоимость прямых затрат на единицу и их общая стоимость. Причём в одной колонке выводится по два значения. Это узкая форма.

Развернутый вариант этой формы – Полный локальный сметный расчёт. Набор данных по каждой позиции тот же самый, только больше колонок: в одной колонке – одно значение.

Это классические варианты формы локальной сметы. Но далеко не единственные.

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

Это формы для расчёта по ТСН города Москвы (папка ЛСР по ТСН) и формы, разработанные для ЛЭУ Московской области (папка ЛСР по ЛЭУ). Весь расчёт стоимости каждой позиции вплоть до накладных расходов и сметной прибыли показывается здесь под позицией сметы.

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

В папке с выходными формами локальных смет есть обширный раздел Прочие формы, где можно найти самые разные дополнительные формы.

Например, в нём есть папка ЛСР БИМ по СМР с формами, где также выводится полная структура расчёта каждой позиции, но не построчно, а колонками. Необходимый набор колонок подбирайте по названию формы. И аналогичный набор выходных форм содержится здесь в папке ЛСР БИМ по Статьям Затрат. Ясно, что в данном случае выбор выходной формы для вывода на печать локальной сметы зависит от того, какой в этой смете задан способ применения индексов.

Отдельно хотелось бы упомянуть выходную форму Сводка стоимости работ. В неё выводятся стоимости по разделам сметы. Эту форму удобно использовать при анализе затрат в смете.

Если вы работаете с крупными корпорациями, то обратите внимание на выходные формы в разделе Ведомственные.

Многообразие выходных форм локальных смет очень велико. Если вам прислали новую и необычную для вас выходную форму, то теперь вы знаете, где её искать в наборе, который входит в состав дистрибутива ПК «ГРАНД-Смета».

Теперь давайте заглянем в папку с выходными формами для учёта выполненных работ.

Формы актов выполненных работ (КС-2) сгруппированы аналогично формам локальных смет – по отдельности формы для базисно-индексного метода и для ресурсного метода, есть ведомственные и прочие формы. Дополнительно к этому выделены формы журнала учёта выполненных работ (КС-6а) и формы КС-3.

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

И очень интересен набор выходных форм в папке Ресурсы.

Эта папка актуальна как при работе со сметами (группа форм Ресурсы по смете), так и при работе с актами выполненных работ (группа форм Ресурсы по актам). И отдельный тип документа здесь – сводная ресурсная ведомость. Этот документ создаётся на группу смет по объекту или строительству в целом. О формировании такого документа рассказывается в отдельной части учебного курса, которая посвящена расчёту затрат по объекту и стройке.

Источник

Live site review. Разбираем инциденты

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

Помимо того, чтобы быстро восстановить работу сервиса, важно избежать повторения проблем там, где это возможно. А там, где предотвратить аварии совсем нельзя, — минимизировать ущерб как для пользователей, так и для сотрудников.

Поэтому кроме круглосуточного мониторинга у нас есть процесс разбора инцидентов. И сами пожары на проде, и работы по анализу проблем мы называем live site review или LSR. Я отвечаю за часть работ с LSR после пожаротушения и хочу поделиться нашими наработками.

Минутка контекста

Авито — большая компания. На ноябрь 2020 года у нас:

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

Как устроен LSR-процесс

Работу с LSR в Авито начали в 2017 году. Процесс несколько раз менялся, и сейчас выглядит так:

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

Как реагируем на инциденты

За работоспособностью всего Авито следит команда с названием «Мониторинг 24/7». Она всегда доступна и смотрит за всеми сервисами. Если случается «взрыв на проде», эта команда первой отправляется тушить пожар и привлекает дежурных разработчиков при необходимости.

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

Что описываем в постмортем тикете

После того, как постмортем тикет заведен, его дополняют данными все желающие. В описание мы вносим любую информацию, которая кажется полезной. Есть единственное правило — описание должно быть таким, чтобы через полгода можно было прочитать и понять написанное. Например, если мы пишем о конкретном дне, то нужна точная дата — «22 сентября», а не «вчера». Если прикладываем ссылку на график, то следим, чтобы не потерялся таймстемп.

В постмортем тикете есть фиксированный набор полей.

Summary (обязательное) — это заголовок. Заголовок мы стараемся заполнять так, чтобы увидев его в календаре или в квартальном отчёте, можно было вспомнить, о чём идёт речь.

Description (обязательное) — здесь описываем суть проблемы, ключевую причину инцидента и любую другую информацию, которая может быть полезна при разборе. Также сюда команды пишут пожелания по разбору, например «обсудим сами внутри кластера» или «обязательно позовите на встречу Васю».

Priority (обязательное) — приоритет тикета. У нас их четыре:

Slack link — ссылка на обсуждение инцидента в слаке. Если обсуждений было несколько в разных каналах, то в поле мы вносим наиболее ценное. Остальные в этом случае добавляем в Description.

Команда (обязательное) — проставляем сюда только одну команду, которая стала виновником торжества.

Пострадавшие сервисы — в этом поле перечисляем все сервисы, которые сломались, кроме того, где была ошибка. Поле нужно для того, чтобы видеть неявные зависимости сервисов и отмечать места, где нужно поработать над graceful degradation.

Участники — здесь указываем всех, кого стоит позвать на встречу с разбором инцидента. В их календари потом придёт приглашение.

Были ли раньше такие проблемы — когда заводится новый постмортем, в поле ставим «нет». Если происходит второй подобный инцидент, линкуем его тикет с постмортемом и меняем описание на «да».

Вероятность повторного возникновения ближайшие полгода — экспертная оценка того, кто заполняет тикет.

Action items — до проведения встречи пишем сюда идеи, предложения и пожелания по инциденту. Так при обсуждении LSR будет меньше шансов про них забыть. Во время обсуждения это поле редактируется.

Link from Helpdesk — добавляет саппорт, если были обращения пользователей.

HD count — количество пользователей, которые обратились с проблемами по инциденту в HelpDesk. Это поле заполняется и обновляется автоматически, если заполнено поле выше.

Продолжительность — абсолютное значение продолжительности инцидента в минутах.

Как разбираем инциденты на встречах

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

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

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

Вот список типовых вопросов, которые стоит обсудить при разборе LSR:

Основная ценность, которую мы получаем от встреч — это action items, то есть действия, направленные на то, чтобы проблема не возникала в дальнейшем или чтобы мы раньше её замечали и быстрее чинили. Это могут быть как правки в коде, так и проекты по улучшения инструментов или процессов, предложения новых best practices и информационные рассылки на всю инженерную команду.

Хорошие action items:

Плохие action items:

Мы договариваемся о кусочках, которые надо сделать обязательно, и таких, которые сделать желательно. Когда action items сформулированы, мы заносим их в Jira — это тикеты в разных проектах, слинкованные с постмортемом. В начале описания необязательных задач ставим вопросительный знак, чтобы их можно было сразу отличить. По остальным считаем, что их желательно сделать в течение месяца. Чтобы это работало, я отдельно слежу за выполнением всех action items и периодически прохожусь с напоминаниями по людям, которым они назначены.

Как ведём базу знаний

Самые интересные или общественно полезные постмортемы и список рекомендаций по ним я вношу в базу знаний. Я их отбираю вручную и раз в две недели публикую в общем канале разработки под заголовком «стенгазета LSR». Все выпуски стенгазеты также собраны в Сonfluence, чтобы можно было быстро найти, как решались те или иные инциденты.

Благодаря стенгазете многие делают исправления в своих сервисах до того, как они сломались. В итоге LSR с одними и теми же причинами в разных командах становится заметно меньше.

А ещё по LSR можно строить любопытную аналитику

Кроме того у нас есть много графиков по LSR: по причинам, виновникам, пострадавшим сервисам, продолжительности, времени возникновения, времени суток. В них я ищу тренды и совпадения. Например, если какой-то сервис падает при любой неисправности любого стороннего сервиса, стоит поработать над его стабильностью: переделать, где возможно, обращения на асинхронные, добавить graceful degradation, может быть, увеличить пул ресурсов.

Лирическое заключение

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

Протестировать абсолютно всё нереально, поэтому в какой-то момент надо сказать, что мы протестировали достаточно хорошо, и остановиться. А что такое «достаточно хорошо»? Если в релизе нашли 100 багов — это достаточно? А если из багов 20 критичных, 50 средних, а остальные некритичные — это достаточно хорошо или недостаточно? Проблема в том, что ответ на самом деле зависит не от того, сколько багов нашли, а от того, сколько не нашли тестировщики, но заметят пользователи.

С помощью LSR я считаю те баги, которые помешали пользователям. Мы получаем некую финальную точку в контроле качества, с которой видно весь цикл разработки как он есть. И сразу становится понятно, куда прийти с отверткой и подкрутить.

Источник

Локальные сметные расчеты (сметы)

Локальные сметы (ЛС) – первичные сметные документы, составляются на отдельные виды работ и затрат по зданиям и сооружениям или по общеплощадочным работам на основе объемов, определившихся при разработке рабочей документации (РД).

Локальные сметные расчеты (ЛСР) составляются в тех случаях, когда объемы работ и размеры затрат окончательно не определены и подлежат уточнению на основании РД, или когда объемы работ, характер и методы их выполнения не могут быть достаточно точно определены при проектировании и уточняются в процессе строительства.

Стоимость работ в локальных сметах производиться в 2-х уровнях цен:

Структура ЛСР (ЛС)

ИСПОЛЬЗОВАНИЕ РАЗЛИЧНЫХ МЕТОДОВ ДЛЯ ОПРЕДЕЛЕНИЯ СМЕТНОЙ СТОИМОСТИ КОНКРЕТНЫХ ВИДОВ РАБОТ

Базисно-индексный метод

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

где V_i – объем работ, выраженный в физ. единицах;

R_i – единичная расценка в базисном уровне цен, руб.

ТРЕНИНГ

ОПРЕДЕЛЕНИЕ СМЕТНОЙ СТОИМОСТИ СТРОИТЕЛЬНЫХ РАБОТ БАЗИСНО-ИНДЕКСНЫМ МЕТОДОМ.

Последовательной определения сметной стоимости строительных работ базисно-индексным методом

Шаги с 1-ого по 7-й повторяются для всех пунктов локальной сметы.

Источники исходных данных

Форма локальной сметы

Таблица 1 (окончание)

Ресурсный метод

Расчет в текущем уровне цен ресурсов, необходимых для реализации проектного решения.

Источник

Разъяснение Минстроя о применении рекомендуемых образцов форм сметных расчетов

Кратко: Выходные формы по новому МДС 421 носят рекомендательный характер. Переход к формату предоставления сметных расчетов на государственную экспертизу может осуществляться по мере готовности как заказчика, так и экспертизы к подаче и принятию документов в электронном формате, который предусмотрен новой методикой.

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

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

Читаем так: пока разработчики не разработают в сметных программах новые «рекомендованные формы» из образцов в Методике — ждём (кто бы ещё им объяснил на реальных примерах что к чему).

Речь идёт об образцах:

О чем думали, когда выпускали и утверждали методику? С кем согласовывали/обсуждали? Вопросов и сложностей не предполагалось?

Собирали ли всех разработчиков сметных программ на площадке Главгосэкспертизы (или хотя бы удаленно) перед выпуском нового, столь значимого для сообщества документа? Получали ли от них предложения, замечания? Они как-то учитывались? Как так получилось, что ни один из разработчиков оказался не готов к выпуску новой версии сметного программного продукта согласно нового документа? И сейчас в авральном режиме вносят изменения в сметные программы, попутно «засыпав» запросами сотрудников Главгосэкспертизы, которые и так перегружены? Можно же было всего этого избежать?

Ирина Тютьмина, Директор департамента ценообразования и градостроительного зонирования Минстроя России в выступлении на круглом столе 21 октября 2020 года: «Нужно, чтобы не только подрядчики, но и государственные заказчики могли грамотно пользоваться этой методикой (видимо все сами должны разобраться что к чему, научиться… с помощью разработчиков сметных программ и авторского материала по новой Методике от Павла Горячкина).

16 октября 2020 г Минстрой России направил в субъекты РФ разъяснение о вступлении в силу этой Методики (с 5 октября, а не 1 октября, как сказано в видео с еле слышным звуком!), обновлении формы сметных расчетов, где предполагается также XML-формат… Регионы это сейчас очень волнует.

Переход к новому формату (не к самим положениям Методики, которые касаются включения в себестоимость тех или иных затрат!), а именно к формату предоставления сметных расчетов на государственную экспертизу может осуществляться по мере готовности как заказчика, так и экспертизы к подаче и принятию документов в электронном формате, который предусмотрен данной методикой. Это очень важно, что такое разъяснение мы направили».

Даже и не знаем как прокомментировать всё происходящее со столь долгожданной новой Методикой. Оконфузились. Никто не готов: ни рассказывать, ни объяснять, ни отвечать на вопросы, ни даже запустить работу по ней.

Хотели дать расшифровку выступления Минстроя о новой «Методике определения стоимости строительства» с круглого стола. Но, ничего путного, кроме вышеприведённой цитаты, одного-единственного слайда и, собственно, разъяснения там нет.

«Боль» (помимо новой Методики) — экономия подрядчика и конъюнктурный анализ. Самые упоминаемые практически каждым выступающим на круглом столе. И с этим нужно что-то делать…

Мнение сметного сообщества. И это тоже нужно решать:

«К нашему ужасу нам придется выполнить уже с сегодняшнего дня большой объект по новой МДС. Если честно мы от нее в шоке! Приложение 2 смета локальная на 12 граф, что за коэффициенты нам предлагают применять для объемов и стоимости, если на данный момент расценки базы ФЕР не редактируются и таких форм в сметных программах РИК и ГРАНД нет. Нет ни одной формы кроме сводного и ОСР приложения № 5.6, получается все перековеркали, а сводник оставили прежний. Непонятно как будет работать обменный блок АРПС и сметы, скинутые через XML для других программ. Как я составлю сметы по новой методике, если в программном комплексе не изменены алгоритмы и не введены новые формы? Посчитать сметы вручную? Абсурд. Тем более, что там одна из смет на полторы тысячи позиций, я ее до Нового года вручную буду пересчитывать. А сроки экспертизы никто не отменял!»

Источник

Лср по лэу что это

Автор: Журнал №3 (47), 2007 г. «Консультации и разъяснения по вопросам ценообразования и сметного нормирования в строительстве»[Просмотреть ответ]