Комплект документации описывающий процесс строительства и эксплуатации объекта это проект

Проектная и рабочая документация

В 1980—1990-х гг. предусматривались два варианта разработки проекта: в одну стадию (рабочий проект) или в две стадии (проект и рабочая документация). Рабочий проект предназначался для строительства технически несложных объектов, а также объектов, сооружаемых по типовому или повторно применяемому проекту. При этом выделялась утверждаемая часть проекта. Окончательный выбор варианта проектирования осуществлял заказчик.

В соответствии с указаниями Минрегиона России заказчиком должна разрабатываться проектная и рабочая документация [1] . Таким образом, основным способом проектирования является двухстадийное проектирование. При этом по проектной документации практически строить невозможно: она нс включает многих важных для строителей данных: конструктивных решений, размеров на чертежах, спецификаций и др.

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

Технологическая документация в проекте

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

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

Объем проектной документации составляет в настоящее время до 40% общей стоимости проектирования, рабочей документации — соответственно свыше 60% [2] [3] .

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

На стадии «Concept Design» (концептуальный проект) прорабатываются основные технологические и строительные решения, при необходимости проводится выбор вариантов решений. Как правило, окончательно выбирается площадка строительства. Стоимость объекта оценивается примерно с точностью 3-го класса. Объем выполненных проектных работ должен быть достаточным для проведения согласований и получения всех разрешений от органов власти на строительство на данной территории.

Техническая и конструкторская документация в проекте

В большинстве случаев после технико-экономического обоснования разрабатывается основной проект «Basic Design». Этап может также иметь название FEED (Front-end Engineering Design) или FEE (Front-end Loading). Решения примерно соответствуют отечественному понятию «проектная документация». Стоимость объекта оценивается с точностью 2-го класса.

Детальная проработка ведется на этапе «Detailed Design» с оценкой стоимости 1-го класса, что соответствует термину «рабочая документация».

По общему правилу, установленному в ГрК РФ (ч. 16 ст. 48), проектная документация, кроме проведения экспертизы, не проходит дополнительных согласований. Однако в целом ряде случаев такое согласование

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

Для объектов, связанных с размещением и обезвреживанием отходов I—V классов опасности, необходима экологическая экспертиза. Классы опасности устанавливаются в соответствии с законодательством об отходах производства и потребления [4] [5] .

В ст. 48 ГрК РФ приведен обязательный состав проектной документации для строительства, реконструкции и капитального ремонта. Эта документация должна состоять из томов, которые сгруппированы в следующие разделы:

Подробный состав проектной документации изложен в Положении о составе разделов проектной документации и требованиях к их содержанию. По требованию заказчика в проект включается раздел «Конкурсная документация» и другие разделы. Для линейных объектов (дорог, трубопроводов, линий электропередач) выполняется десять разделов:

• 1) пояснительная записка;
• 2) проект полосы отвода;
• 3) технологические и конструктивные решения линейного объекта. Искусственные сооружения;
• 4) здания, строения и сооружения, входящие в инфраструктуру линейного объекта;
• 5) проект организации строительства;
• 6) проект организации работ по сносу (демонтажу) линейного объекта;
• 7) мероприятия по охране окружающей среды;
• 8) мероприятия по обеспечению пожарной безопасности;
• 9) смета на строительство;
• 10) иная документация в случаях, предусмотренных федеральными законами.

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

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

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

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

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

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

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

Состав рабочей документации не оговорен ГрК РФ, однако указывается в системах национальных стандартов (ГОСТ): Единой системе конструкторской документации (ГОСТ ЕСКД) и Системе проектной документации для строительства (ГОСТ СПДС). Правила оформления чертежей оговариваются в основном в стандартах ЕСКД, ориентированных в первую очередь на машиностроительные чертежи, а содержательная часть регламентируется обычно стандартами СПДС. В соответствии с ГОСТ 21-101 «Основные требования к проектной и рабочей документации» рабочая документация по каждому разделу состоит из основных комплектов, прилагаемой документации и ссылочной документации. Основные комплекты всех разделов по всем зданиям и сооружениям стройки составляют полный комплект документации.

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

Локальные и объектные сметы в рабочей документации составляются, если это предусмотрено заданием на проектирование. При этом в подрядном договоре должно быть оговорено их использование при составлении актов выполненных работ, в противном случае сметы просто не нужны. Для составления смет используются сборники региональных или федеральных единичных расценок на строительные работы (ТЕР-2001, ФЕР- 2001), на монтажные и пусконаладочные работы (соответственно ФЕРм- 2001 и ФЕРп-2001), данные поставщиков о стоимости оборудования и др.

Источник

Проектная документация на строительство.

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

Рис. 4.17. Жизненный цикл проекта

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

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

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

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

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

• ? составление ходатайства (декларации) о намерениях и направление его в орган исполнительной власти муниципального образования, на территории которого намечается строительство, и предварительное согласование места размещения объекта строительства;
• ? составление задания на разработку обоснований инвестиций в строительство;
• ? разработку ТЭО и получение заключения государственной экспертизы;
• ? утверждение ТЭО в органе исполнительной власти муниципального образования, на территории которого намечается строительство, и получение акта выбора земельного участка для строительства.

Перечень вопросов, рассматриваемых при разработке Обоснований инвестиций в строительство, приведен на рис. 4.18.

Рис. 4.18. Перечень вопросов, рассматриваемых в Обоснованиях инвестиций в строительство

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

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

Для объектов производственного назначения проект строительства состоит из следующих разделов:

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

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

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

Осуществление названных мероприятий обеспечит развитие процессов проектирования и строительства на территории муниципальных образований на новой правовой, экономической и финансовой основе, что в конечном счете повысит эффективность программ социально-экономического развития муниципальных образований.

Для регулирования процессов строительства на всех его этапах при местной администрации обычно создается муниципальный орган управления капитальным строительством — отдел капитального строительства или управление капитального строительства (ОКС, УКС). Он может иметь форму структурного подразделения администрации или муниципального учреждения. В администрациях крупных муниципальных образований существует должность заместителя главы администрации по строительству. Основные функции муниципального органа управления капитальным строительством показаны на рис. 4.19.

Рис. 4.19. Функции муниципального органа управления строительством

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

Источник

Момент, когда проектная документация нужна

Время идет, планета крутится, системы растут и развиваются, а я продолжаю слышать в кругах аналитиков сожаление: «Эх, пришел на проект, а тут никакой документации, смотрим в код».

Но это ерунда. Хуже, когда заказчик говорит: «Создали два разработчика. Уволить не могу, хотя почти ничего не делают, только по мелочи донастраивают. А с этой системой у нас уже и бухгалтерия интегрирована, и … Документация? Нет ее.

А надо. Спасите-помогите»!

Проблемы с документацией в процессе разработки ПО были, есть и будут. Эта статья посвящена поиску момента, в который появляется необходимость ведения проектной документации и поможет принять решение, если у вас только начали появляться мысли об этом. Повествование сопровождается примерами из жизни МоегоСклада.

Что это за зверь — «документация»?

С чего начинается задача на разработку? С идеи. Чтобы что-то создать, нужно это представить в своей голове. Чтобы не потерять мысль, её лучше зафиксировать.

По сути, документирование — это процесс описания идеи от момента ее возникновения в сознании до выпуска результатов в релиз. А значит документировать мы начинаем в момент написания ТЗ, при описании задачи, без строгого формата, в картинках или на листе бумаги. Когда мы формализуем, как это должно работать.

Для кого документировать?

Если нет понимания, кому нужна проектная документация, то она не нужна. Возможно, прочитав эту статью чуть дальше, мнение может резко поменяться, но это не точно.

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

Разработчик быстрее осознает, над чем он вообще трудится, спокойнее принимает «чужое наследство».

Тестировщик каждый раз не находит одни и те же ошибки, которые на самом деле уже стали особенностями реализации.

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

Иногда проектная документация нужна просто потому, что так сказали.

На мой взгляд, это самый омерзительный случай — страдают все: и те, кто пишет документацию – нудно, скучно, бессмысленно потраченные силы на соблюдение каких-нибудь ГОСТов, и те, кто потребляет ее – обязанность заказать и оплатить документацию по ГОСТу, потому что так надо.

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

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

Причины, по которым компании приходят к внедрению документирования

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

Есть сервис МойСклад и 2007 год. Прекрасный пример стартапа от двух разработчиков. Фундамент сервиса был целиком заложен Аскаром (генеральный директор) и Олегом (технический директор). Если почитать историю создания МоегоСклада, то можно узнать интересный факт – уже тогда было неосознанное документирование продукта в рабочей тетрадке в клеточку!

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

На момент, когда у продукта было 0 пользователей, лэндинг и рабочая альфа-версия, документировать было бессмысленно. Да и сейчас любой самостоятельной команде разработчиков, запускающих стартап, уверена, документировать не надо – вы сами творите свое «сокровище» и знаете его. Лучше докрутить еще парочку фич, чем заниматься печатью лишних символов с описанием системы для себя. Время бесценно. А вот тем, кто заказывает разработку стартапа, я советую задуматься, в какой момент они могут пожелать заменить подрядчика и начинать строить свою команду.

Пример с автомастерской

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

В зависимости от опыта он успешно будет чинить обычные автомобили: не глядя в инструкции, не советуясь со старшим мастером. Интуиция спасет его.

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

Привезут в автомастерскую сломанную «буханку». Опытный механик постучит молотком по нужным частям, и она поедет. А постучит, возможно, даже наугад! Это сопоставимо с тем, что опытный разработчик придет в разработку простой системы и будет решать задачи как получится, наугад. И все будет получаться, потому что никаких сложных связей и соединений внутри нет — например, какой-нибудь интернет-магазин с информационным сайтом или что угодно другое.

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

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

И все успешно получится, потому что система обычная, никаких «наворотов» нет.

Но вот привезли Aston Martin или Ferrari. А я обычный механик в среднестатистической автомастерской. Конечно, сначала я обрадуюсь такому. Но потом, когда дело дойдет до ремонта, я буду вдумчиво смотреть на это «чудо света» и искать все возможные инструкции, чтобы устранить неисправность.

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

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

В отсутствии проектной документации основная стоимость разработки будет потрачена на изучение того, «как оно работает», «что это» и «почему так».

За 13 лет МойСклад смог очень круто подрасти: веб-приложение для RU- и US-площадок, кассовое ПО для трех платформ, мобильные приложения, шесть протоколов API и много-много всего.

Продукт простой снаружи, для пользователя, но сложный внутри — для разработки и развития. Я, как ведущий системный аналитик, шла в компанию с желанием описать все быстро и продолжать развивать документированный продукт.

Когда я открыла «капот» дорогого и любимого Aston Martin, я поняла, что взяла очень интересную и сложную машину. Сначала было длительное изучение «начинки», а теперь нужно время, чтобы успевать и развивать новое, и описывать ранее созданные детали.

Одна из основных причин начала накопления знаний в МоемСкладе – продукт стал большим и сложным.

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

Причиной запуска такой деятельности стало то, что ведущий QA тратила много времени на обучение продукту новых сотрудников и рассказы про одно и то же. Да и некоторые знания забываются и теряются, потому что есть золотое правило «не трогай то, что работает».
Собранные командой тестирования документы и сегодня помогают ориентироваться в том, как работают части МоегоСклада: что считать нормой, а что нет.

Программный код и есть документация

Так говорят разработчики. И нет, это не так.

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

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

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

Как нас много

Как масштаб проекта по части количества людей влияет на необходимость появления документации.

Сервис МойСклад начинался с Аскара и Олега 13 лет назад. Целиком знают продукт всего три человека: Аскар, Олег и Максим — присоединившийся к ним немногим позже продакт и бизнес-аналитик.

Сегодня компания насчитывает более 150 человек. Три хранителя знаний на тридцать сотрудников? Возможно. А на команду от ста человек? Да и помнить все детали, особенно когда реализовывал их не ты, просто невозможно.

Поэтому нормой стал ответ «смотри как на проде».

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

Может ответить только зафиксированное знание, которое либо есть, либо нет, либо оно в человеке (а значит его нет).

В МоемСкладе стали важными такие умения, как «археология по коду» у разработчиков, «археология по возможностям системы» у тестировщиков и аналитика.

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

Не храните знания в людях – это опасно

Рынок IT-специалистов очень бодр и динамичен. Отсутствие документации на продукт может быть опасным. Человек, уходя из компании, уносит с собой знания о тех частях, которые он делал. Это плохо тем, что развитие и сопровождение неизведанных частей становится очень дорогим удовольствием – нужно исследовать, как работает сейчас и достраивать над текущим поведением нечто новое.

У бизнес-заказчика при смене подрядчика возникнет очень много вопросов с передачей кода новой компании: «наследство» не любят, особенно, недокументированное. Бизнес-заказчику без документации может быть сложно стать независимым.

Сегодня все более актуальна тема с удаленной работой, да и ранее команды разработки всегда обсуждали задачи в чатах (Slack, Telegram, Skype и т.д.).

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

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

Моя позиция такова: стараюсь минимизировать развернутые ответы на вопросы в чатах и максимально ссылаться на существующую документацию:

Разработчик: [Вопрос]
Я: [ссылка на Confluence] п. [название]

Это куда быстрее, чем каждый раз отвечать всем на одни и те же вопросы. Если вопрос возник, значит ответ на него надо документировать. Такая вот простая логика.

И про контекст

Итого: где же тот самый момент?

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

Некоторые компании начинают с первых дней, а некоторые тянут до последнего. Но начинать никогда не поздно. Через 5 лет, через 10 или 13 — главное не пытаться прятать голову в песок, когда становится заметно, что сотрудникам сложно работать и есть проблемы с пониманием системы.

Что может дать наличие документации на программный продукт?

• Меньше обсуждений в чатах и поисков причин «почему так».
• Быстрее погружение в контекст.
• Команде проще понимать и оценивать объем изменений для новых задач.

Ссылки

analystdays.ru/ru/talk/83497 Analyst Days. Как мы процесс документирования внедряли
habr.com/ru/company/moysklad/blog/452016 Сервис МойСклад 12 лет в облаке (уже 13!)

Источник