На каком этапе разработки проекта могут возникнуть ошибки

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

Ошибки, допускаемые в начале проекта

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

• Например, цель «хорошо провести вечер» для одних означает сходить в ресторан. Для других это поход на хоккей с веселой компанией.

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

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

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

• Например, один менеджер предпочитает живые переговоры с контрагентами, а другой – официальную переписку. Оба метода хороши, но в разных случаях. Об этом нужно сразу договориться.
• Другой пример: администратор проекта привык работать с Microsoft Project. А руководитель проекта отдает предпочтение Primavera. В результате дополнительное время на обучение и адаптацию администратора к новой программе сдвинет сроки реализации проекта.

4. Занижение или завышение масштаба проекта также влияет на его бюджет и сроки реализации.

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

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

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

Как правильно начать проект?

Чтобы не допустить вышеперечисленных ошибок, нужно:

1. Определить конкретные цели, так чтобы они однозначно понимались и принимались всеми участниками проекта. Кроме того, они должны совпадать с общими целями компании. Оцифровать цели, для этого есть много методик, например SMART.
2. Определить критерии успеха проекта. То есть, в каком случае проект будет считаться удавшимся. Это числовая характеристика успеха проекта через определенное время после его реализации. Например, снятый фильм посмотрят не меньше 2000 человек за первый месяц проката.
3. Согласовать методы, способы, средства управления проектом, регламент обмена информацией между участниками и так далее. То есть определить четкие правила и прописать их в Уставе проекта и других базовых документах.
4. Разработать четкий план работ, матрицу ответственности и бюджет проекта, продумать все риски. Об этих и других инструментах управления проектом можно прочитать в соответствующей статье.
5. Заручиться поддержкой спонсора проекта или высшим руководством.

А пока давайте проверим на своих проектах, все ли вышеперечисленные ошибки мы учли.

А если в ваших проектах были другие ошибки, за которые Вы «дорого заплатили», пишите в комментариях. Давайте делиться опытом!

Опыт менеджеров Redmadrobot.

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

Ситуации, при которых появляется необходимость взять на себя обязанности PM (project manager), бывают разные: в маркетинге — при создании сайта, в HR — при организации мероприятий. Мы вспомнили десятки подобных случаев и подготовили список ошибок, которые допускают новоиспеченные руководители проектов.

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

На самом старте

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

Ошибка № 1: отсутствие фиксации договорённостей со стейкхолдерами

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

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

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

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

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

Вариант посложнее: железная команда аналитиков и дизайнеров Redmadrobot на этапе старта проекта всегда собирает паспорт продукта — документ с описанием характеристик и основных целей.

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

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

Ошибка № 2: бездумное формулирование целей и задач в команде

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

На выходе мы имеем старое доброе «ничего», а прикрываемся «внешними факторами», «незапланированными активностями» и «кто-то виноват, а мы не подозревали».

Простое решение: вариант для самостоятельного использования — воспользуйтесь одной из проверенных временем методологий постановки задач, например, SMART. Мы часто используем в работе подходы DoD и DoR .

Но проект — дело командное, поэтому, если есть возможность планировать и думать над реализацией всем вместе, её нужно обязательно использовать.

Вариант посложнее: изучите вместе с коллегами одну из методологий постановки задач и грамотно её внедрите. Для этого разделите планирование результатов на несколько итераций, после чего сделайте deep dive (погружение в проект) всей команды по методологии постановки задач.

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

Ошибка № 3: перекладывание ответственности

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

А в том случае, если в проекте что-то пойдёт не по плану, менеджер должен чётко понимать, в какой его части произошёл сбой. Иначе PM рискует поставить под угрозу результаты работы и деморализовать всю команду.

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

Простое решение, если не хотите заморачиваться и у вас небольшой проект:

Главное — договоритесь о том, как планируете взаимодействовать в команде и зафиксируйте это любым удобным способом: текстом, в Miro или, например, набросайте mind map — как вам удобно.

Вариант посложнее: для крупных проектов можно сделать ролевую модель проекта в виде карты и добавить описание функций каждой роли (это можно сделать, например, в Miro).

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

По ходу реализации: про реализацию

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

Ошибка № 4: отсутствие инструментов для командной работы

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

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

Простое решение: не гонитесь за модой — используйте доступные и универсальные инструменты, такие как Trello или Google-таблицы.

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

Задача эффективного инструмента — упростить жизнь команде. Trello и Google-таблицы хорошо с этим справляются. Но независимо от ваших предпочтений, есть типы инструментов, которые понадобятся вам в любом проекте: делегирование, встречи или «синки», риск-менеджмент, каналы коммуникации и взаимодействия.

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

Ошибка № 5: отсутствие чётких приоритетов

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

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

Простое решение: если у вас небольшой проект, то используйте методологию MоSCоW — она хорошо подходит для определения приоритезации. Также обратите внимание на методологии RICE и ICE.

Вариант посложнее: в крупном проекте поможет формирование собственной системы приоритезации входящих задач. Её можно построить на базе Google-таблиц или Trello.

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

Ошибка № 6: отсутствие контрольных точек и оценки результата

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

Решение:

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

По ходу реализации: про взаимодействие

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

Ошибка № 7: неинформирование команды

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

Решение:

Ошибка № 8: отсутствие реакции на изменения или критичные ситуации

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

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

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

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

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

И в конце

Проект всегда имеет конечные точки и финал. Соберитесь силами и не допустите в них последних двух ошибок.

Ошибки № 9 и № 10: отсутствие рефлексии и подведения итогов

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

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

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

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

Вариант посложнее: мы в Redmadrobot пользуемся двумя инструментами: ретроспектива проекта команды и индивидуальная рефлексия для руководителя. Ретроспектива помогает регулировать эмоциональный фон команды, снимать обратную связь по прошедшему периоду и, что важно, — благодарить друг друга.

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

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

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

Источники ошибок

Рассмотрим
источники ошибок на первых трех этапах
проектирования.

Этап
1. На этом этапе источниками ошибок могут
быть: логическая несогласованность
требований, упущения, неточности
алгоритма.

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

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

Каждый
из перечисленных источников ошибки
может породить большое число субъективных
или физических неисправностей, которые
необходимо локализовать и устранить.
Обнаружение ошибки и локализация
неисправности являются сложной задачей
по нескольким причинам: во-первых, из-за
большого числа неисправностей; во-вторых,
из-за того, что различные неисправности
могут проявляться одинаковым образом.
Так как отсутствуют модели субъективных
неисправностей, указанная задача не
формализована. Имеются определенные
успехи в области создания методов и
средств обнаружения ошибок и локализации
физических неисправностей. Эти методы
и средства широко используются для
проверки работоспособного состояния
и диагностики неисправностей дискретных
систем при проектировании, производстве
и эксплуатации последних.

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

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

Проверка правильности проекта

Основные
методы контроля правильности проектирования
следующие: верификация — формальные
методы доказательства корректности
проекта; моделирование; тестирование.

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

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

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

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

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

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

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

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

Один бизнес-план — три варианта

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

Экстенсивность не всегда успешна

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

10 ошибок в российской практике разработки бизнес-планов

1/10 НЕТ БИЗНЕС-ПЛАНА

Преднамеренный отказ от подготовки этого документа исключает возможности компании по получению средств.

2/10 ПЛОХОЕ ВИДЕНИЕ И СТРАТЕГИЯ

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

3/10 ДЕФИЦИТ В ОТНОШЕНИЯХ С КЛИЕНТАМИ

Не обращать внимание на контакты с клиентами.

4/10 НЕЗНАНИЕ РЫНКА И КОНКУРЕНТОВ

Недостаток рыночных знаний и знаний о конкуренции — базовая ошибка бизнес-планирования.

5/10 ПРОПУСК СИЛЬНЫХ И СЛАБЫХ СТОРОН

Не замечать возможности, угрозы и активы компании.

6/10 ПРОБЛЕМА С ФИНАНСОВЫМ АНАЛИЗОМ

Приравнивание прибыли к денежным средствам без учета поступлений и текущих расходов.

7/10 ИГНОРИРОВАНИЕ УПРАВЛЕНИЯ РИСКАМИ

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

8/10 ИЗОЛЯЦИЯ РАБОТНИКА

Отсутствие вовлеченности сотрудников в составление бизнес-плана.

9/10 ПРОБЛЕМА СО СМЕНОЙ РУКОВОДСТВА

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

10/10 НЕДОСТАТОК МОТИВАЦИИ СОТРУДНИКОВ

Отсутствие систематической и логичной концепции мотивации сотрудников.

Распространенные ошибки на этапе подготовки бизнес-плана

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

• Поверхностный анализ рыночной среды;
• Чрезмерная спешка и получение остаточной информации;
• Слишком общее определение целей;
• Непрозрачный план;
• Несколько подробных маркетинговых мероприятий;
• Несоответствие между финансовым планом и материальным планом;
• Чрезмерный оптимизм.

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

1. Формальные ошибки и расстроенная структура бизнес-плана

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

2. Слишком жесткий характер плана отпугивает инвесторов

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

3. Неправильная формулировка допущений является одной из самых распространенных ошибок

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

4. Отсутствие аргументов и ссылок на источники информации

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

5. Создание бизнес-плана, ориентированного исключительно на внешнего получателя

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

6. Несоблюдение рамок соглашения бизнес-плана

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

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

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

Постановка задачи

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

Составление технического задания.

Техническое задание это документ в котором описаны все возможности программного обеспечения, утрированный пример:

Создание интернет магазина

Написать интернет магазин с возможностью добавлять категории, добавлять товар по категории с картинкой и описанием.

Участники системы:
1) Администратор
2) Покупатель

Возможности пользователей

Возможности администратора:
1) Добавлять удалять и редактировать категории
2) Добавлять удалять и редактировать товары
3) Добавлять удалять и редактировать заявки на покупку товара

Возможности пользователя/покупателя
1) Добавлять товар в корзину
2) Оформлять покупку

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

Давайте рассмотрим подробнее и разобьем на этапы:
1) Рисование и верстка дизайна.
2) Проектирование базы данных.
3) Проектировние архитектуры.
4) Написание программного кода.
5) Написание базы данных.а
6) Покупка хостинга и домена.
7) Продвижение сайта.

А если мы захотим, добавить еще 2 возможности:
1) Регистрация пользователя
2) Пользователь может добавлять товары

Вроде бы отличие в двух строчках, но это уже не интернет магазин, а задача может перерости в сервис на подобии avito, alibaba, а сроки и сложность возрасти в разы (таблиц станет не 5-10, а 100).

Ошибки в проектировании примеры:
Часто сроки сложность и стоимость разработки может увеличиваться из за ошибок в архитектуре и постановке задачи, примеры:

1) Был сервис который показывал геолокацию товара или услуги на карте при помощи API яндекс или гугл карт, а потом понадобились специфические вычисления которые сторонние сервисы не предоставляют в результате: нужно установить движок карты, сменить базу данных, сконвертировать данные, написать нужные формулы, адаптировать старый код под возможности модуля карт. Это повлечет за собой временные и денежные затраты.

2) Была неправильно смоделирована база данных, необходимо добавить несколько полей и изменить программный код.

3) Неправильно составлено техническое задание: необходимо полное переписывание.

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

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

Правильный выбор инструментов для разработки
1) IDE — во многих современных средах разработки предусмотрен: автокоплит (автоматическое дополнение кода), интеграция с системой контроля версий, сестемами сборки версий, подсказки об ошибках, интерграция с системами тестирования, интеграция с системами дебага.
2) Система контроля версий: снижает риски потерять программный код, дает возможность командной разработки, дает возможность разделять код на ветки, дате возможность восстанавливать старые версии кода.
3) Система управления проектами: дает возможность ставить задачи для команды, разделять задачи, контролировать процесс разработки.
4) Фреймворк: позволяет ускорить разработку, позволяет разделить логику, может иметь специфический набор возможностей для ваших задач.
5) Выбор языка и базы данных тут рассматриваться не будет — лично мое мнени их нужно выбирать от задачи.

Итеративная и командная разработка и ошибки
В команде есть три разработчика их обязанности разделены по частям кода, в понедельник они собрались и решили какие задачи будут выполнять в течении следующих двух недель:
1) Первый решил поменять модель, так что бы появилась возможность выводить и отслеживать дату создания.
2) Второй решил исправить регистрацию.
3) Третий менял дизайн.
В течении недели все трое писали код и вносили изменения в репозиторий, в результате первый разработчик изменил код так, что «отвалилась» часть за которую был ответственен второй программист. Части в которых были внесены изменения работают хорошо, а в других местах где он незаметил начали сыпаться ошибки.

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

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

Правильная постановка сроков

За сколько вы создадите типовой интернет магазин? У вас все настроенное, вы давно работаете, в совершенстве владеете языками и системами управления контента и работаете командой. 5 дней может быть неделя (качественного отказоустойччивого приложения вы за этот срок неполучите)? Смело умножайте на 2, для того что бы учесть форсмажоры и избежать конфликтов.

Думаю не трудно себе представить экономию: сил, времени, денег и нервов. Учтя все вышеописанные нюансы, приемы и ошибки.

Материал публикуется частично. Полностью его можно прочитать в журнале «Справочник экономиста» № 10, 2020.

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

Есть ли возможность избежать ошибок? Конечно! Быть внимательнее, не экономить «на спичках» (экономия в несколько сотен тысяч рублей может вылиться в многомилионные потери), выезжать на объект. О том, каковы причины и последствия ошибок в проектировании, какие неточности допускаются чаще всего и почему проекты заворачивает экспертиза, вы узнаете из нашего материала.

Основные причины и последствия ошибок проектирования

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

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

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

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

Чем могут быть вызваны ошибки в проектировании? Обычно они происходят из-за таких факторов:

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

Названные факторы могут спровоцировать:

• Неправильный выбор оснований и конструктивной схемы фундамента. Нужно понимать, что речь идет о базе здания, поэтому ошибка в проектировании чревата недопустимой осадкой, креном. Это приведет к появлению трещин большого раскрытия, даже разрушению объекта.
• Использование неподходящей конструктивной схемы здания, что приводит к перегрузке и разрушению несущих конструкций.
• Появление сырости, плесневого грибка, провоцирующего физический износ объекта в короткие сроки. Подобный эффект вызывает сочетание расчетов воздухообмена по устаревшим нормами с установкой современных «евроокон». Такие окна имеют эффективные уплотнители, которые перекрывают доступ в здание наружного воздуха почти на 90 %.
• Учет материалов, которые уже не производятся и были взяты при подготовке документации из старых сортаментов.

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

• правильная организация работ с учетом норм ГОСТ ISO 9000-2011;
• проведение свободных дискуссий специалистов по проектированию в сфере строительства;
• подготовка запасов материалов на случай непредвиденных ситуаций;
• личная ответственность участников работ;
• сбор всей доступной информации и статистики, связанной с определенной сферой деятельности;
• разработка запасного варианта на случай негативного развития ситуации;
• опора на информацию о современных строительных материалах, конструкциях.

Наиболее распространенные ошибки проектирования ПЗУ

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

Проблемы могут быть связаны и с тем, что проектирование ведется для территории, выходящей за пределы предоставленного земельного участка, в соответствии с выпиской из правил землепользования и застройки (ГПЗУ).

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

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

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

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

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

Данные нормы содержатся в СанПиН 2.2.1/2.1.1.1076-01 и озаглавлены «Гигиенические требования к инсоляции и солнцезащите помещений жилых общественных зданий и территорий». Необходимо спроектировать площадки нормируемого благоустройства в таких объемах, чтобы обеспечить необходимыми условиями всех жителей.

Описанные ошибки при проектировании свидетельствуют о нарушении:

• ч. 1 ст. 48 ГрК РФ;
• п. 11.19, п. 7.5 СП 42.13330.2011 «Градостроительство. Планировка и застройка городских и сельских поселений»;
• п. 2.3 гл. 2 СанПиН 2.1.2.2645-10 «Санитарно-эпидемиологические требования к условиям проживания в жилых зданиях и помещениях».

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

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

Допускают ошибки и на этапах проектирования детских дошкольных образовательных учреждений (ДДОУ). Нередко в составе раздела ПЗУ отсутствует схема планировочных ограничений для участка проектирования, требуемая в пп. «п» п. 12, раздела 2 «Схема планировочной организации земельного участка», «Положение о составе разделов проектной документации и требованиях к их содержанию», утвержденных ПП РФ.

Обычно для возведения детских садов выделяют участки вне сложившихся жилых кварталов, за границей частного сектора. То есть для них отводят территории для перспективной застройки без учета радиусов доступности и радиусов обслуживания ДДОУ в соответствии с требованиями п. 5.4* СНиП 2.07.01-89*.

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

Ошибки проектирования в архитектурных и объемно-планировочных решениях

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

Этажность общественных зданий определяется в соответствии с приложением Г (Г.8) СП 118.13330.2012 «Общественные здания и сооружения. Актуализированная редакция СНиП», приложением Б СП 56.13330.2011 «Производственные здания. Актуализированная редакция СНиП». Для жилых домов действует приложение В.1.6 СП 54.13330.2011 «Здания жилые многоквартирные. Актуализированная редакция СНиП».

Согласно информации из этих документов:

• При определении количества этажей в здании учитываются все надземные этажи, в том числе технический, мансардный, цокольный, при условии, что верх его перекрытия расположен выше средней планировочной отметки земли минимум на 2 м.
• Согласно прил. Б п.2.7, этаж, выделенный под размещение инженерного оборудования, прокладку коммуникаций, может находиться между надземными этажами либо в нижней, верхней части здания. Последние варианты обозначаются как техническое подполье и технический чердак соответственно. Пространство, имеющее высоту до 1,8 м, которое задействуется исключительно для прокладки коммуникаций, не считается этажом.

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

Нередко в проекте не предусмотрена безопасная эвакуация людей при пожаре посредством объемно-планировочных решений, конструктивного исполнения эвакуационных путей. Может быть подготовлено мало путей эвакуации либо проемы и проходы оказываются перекрыты смежно расположенными дверными полотнами, о чем говорится в ст. 53 (1, 2) ФЗ от 01.01.2001 «Технический регламент о требованиях пожарной безопасности».

Распространенной ошибкой проектирования жилых зданий является отсутствие принудительной вентиляции для кухонь-ниш. При определении количества комнат в квартирах кухни-столовые расценивают как жилое помещение – на данную ошибку указывает СП 54.13330.2011 «Здания жилые многоквартирные. Актуализированная редакция СНиП».

При выполнении мероприятий по повышению теплозащиты зданий, указанных в разделе 5 СНиП «Тепловая защита здания», СП «Проектирование тепловой защиты зданий», могут быть допущены следующие ошибки:

• Отсутствуют сведения об общей и послойной толщине наружных стен и технических особенностях использованных материалов.
• Не представлен теплотехнический паспорт здания.
• Не учтен коэффициент теплотехнической однородности при проведении теплотехнических расчетов. Не указаны нормативные и расчетные значения сопротивлений теплопередачи окон и витражей (R0, м2 оС/Вт) с учетом коэффициента остекленности фасада, о чем говорится в п. 5.11 СНиП. Данная ошибка распространяется на производственные, административно-бытовые и иные помещения здания.
• Не предусмотрено утепление полов на грунте в области их примыкания к наружным стенам – требования зафиксированы в п. 9.13 СП 29.13330.2011 «Полы. Актуализированная редакция СНиП 2.03.13-88».

При проектировании уклонов въездных рамп автостоянок не соблюдаются требования СП 113.13330.2012, озаглавленного «Стоянки автомобилей. Актуализированная редакция СНиП». Документ утвержден Приказом Минрегиона РФ от 01.01.2001 N 635/99 и действует с 1.01.2013. Некоторые застройщики используют несертифицированные фасадные системы утепления и витражные системы либо не предоставляют информацию о выбранных системах.

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

Ошибки проектирования в конструктивных решениях

В более чем 90 % проектной документации, подаваемой на экспертизу, присутствуют нарушения ГОСТ P 21. «СПДС. Основные требования к проектной и рабочей документации»:

• Не предоставляется информация об уровне ответственности объекта, предусмотренном «Техническим регламентом о безопасности зданий и сооружений». Нередко коэффициент надежности по ответственности зданий и сооружений принимается по указаниям ГОСТа. Это влечет за собой нарушение приоритетных на данный момент требований п. 7 ст. 16 «Технического регламента о безопасности зданий и сооружений». ГОСТ входит в «Перечень национальных стандартов и сводов правил», обязательное применение которых позволяет выполнять требования ФЗ «Технический регламент о безопасности зданий и сооружений». Правда, по данному вопросу ГОСТ противоречит обозначенному основному закону.

• Нет или слишком мало информации о конструктивной схеме сооружения, конструктивных мероприятиях, призванных обеспечить его общую устойчивость и сохранение геометрии в нормальных условиях и в случае пожара – табл. 21 «Технического регламента о требованиях пожарной безопасности», ФЗ от 01.01.2001. Нередко предложенные в проекте решения неспособны сообщить объекту указанные свойства. Допустим, в здании с металлическим каркасом не предусмотрены жесткие узлы, связи.
• Нет данных, касающихся проектной степени огнестойкости и класса конструктивной пожарной опасности зданий, что должно быть указано согласно нормам «Технического регламента о требованиях пожарной безопасности». Из-за этой ошибки проектирования зданий и сооружений невозможно предусмотреть и проверить соответствующие конструктивные мероприятия.
• Расчеты строительных конструкций выполнялись на основании нагрузок, которые не соответствуют проектным решениям или являются необоснованными по нормам СНиП 2.01.07-85, СНиП 2.09.03-85, пр.
• Допущены ошибки при выборе расстояния между температурно-усадочными швами либо здание в принципе не разделено на блоки, что чаще всего встречается при проектировании парковок. Требования зафиксированы п. 1.22 СНиП 2.03.01-84 «Бетонные и железобетонные конструкции».

• Нет данных о залегающих в основании фундаментов грунтах, их прочности, деформационных показателях, что также актуально для искусственных оснований. Обязательное наличие такой информации установлено пп. 2.10–2.16 СНиП 2.02.01-83 «Основания зданий и сооружений».
• Обоснование проектирования оснований зданий и сооружений не представлено либо признано недостаточным, что является ошибкой по п.1.4 СНиП 2.02.01-83.
• Нет или не предусмотрена информация, касающаяся защиты подземной части объекта от подтопления. Также необходимо принимать во внимание расчетный уровень подземных вод при сезонном и техногенном подъеме, о чем говорится в пп. 2.17–2.24 СНиП 2.02.01-83. При выборе глубины заложения фундаментов, в том числе в зонах спусков в подвал, приямков и вентиляционных шахт, не выполнены нормы пп. 2.25–2.31 СНиП 2.02.01-83.
• Не продумана защита основания фундаментов от промерзания через строительные конструкции, а также предохранение строительных конструкций от коррозии. Данные требования установлены СНиП 2.03.11-85.

Достаточно часто при проектировании допускают ошибку, не предусмотрев горизонтальную гидроизоляцию в каменных стенах, которая должна быть выполнена по п. 6.4 СНиП II-22-81. Грубые нарушения ГОСТ 21 и СНиП II-23-81 допускаются в разделе «Металлические конструкции».

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

Примеры ошибок проектирования из практики

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

• стремление заказчика сократить затраты на проект;
• желание проектировщиков сохранить клиента, поэтому они готовы выполнить любые его прихоти.

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

Остановимся более подробно на каждом факторе, влекущем за собой различные проблемы:

Попытки сэкономить на исследованиях

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

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

Допустим, вы собираетесь возвести объект размером 70х30 м. Для этого нужно подготовить свайный фундамент с заглублением свай на 15 м. К строительству уже приступили, но оказывается, что сваи уходят максимум на 10 м, так как дальше начинается скальная порода. И такая картина складывается на 80 % вашего участка.

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

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

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

Будьте готовы заплатить еще примерно 2-3 миллиона – это сумма без учета последствий срыва сроков. Кто из сторон будет оплачивать издержки, тоже сложно сказать. Решение данного вопроса в судебном порядке может растянуться на несколько лет. К подобной ситуации нужно быть готовым как на частных, так и на государственных объектах.

Проектирование без выезда на участок

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

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

Стоит пояснить, что «кабанчиком» называют облегченный пустотелый лицевой кирпич с тонкими стенками снаружи и парой во внутренней части. Толщина стенок составляет 10–15 мм.

Проектировщики упустили этот нюанс. Кроме того, протокол испытаний анкеров на вырыв, приложенный к проекту, показал: химический анкер 100 мм идеально держится. Заказчик понимает ситуацию, но требует, чтобы все пункты проекта были выполнены. К работе нельзя приступать, пока не будут проведены повторные испытания анкеров – именно они показали, что такой кирпич разрушается уже при подаче 20 % от проектной нагрузки.

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

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

Отсутствие внимательности

Рассмотрим еще один пример: на объекте нужно установить новые окна. Выполнены замеры, заказчику предоставлены размеры изделий и стоимость работ. Далее был подготовлен договор, после чего клиент внес предоплату.

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

Помните, что любые цифры и размеры в проектах нужно проверять и перемерять.

Безосновательное распределение работ между несколькими проектировщиками

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

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

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

Из-за каких ошибок проекты чаще всего не проходят экспертизу

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

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

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

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

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

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

Большую опасность несут в себе ошибки, совершенные в процессе проектирования наиболее объемного блока, архитектурных и конструктивных решений.

Некоторые недочеты не несут угрозы, например:

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

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

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

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

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

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

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

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

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

После получения заключения проектировщики должны внести изменения в установленные сроки. Обычно они делают это достаточно быстро и больше не повторяют свои ошибки в проектировании.

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

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

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

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

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

Для стартапов, которым нужно постоянно вводить новые фичи и показывать результаты инвесторам, это подобно смерти.