На каком этапе разработки проекта могут возникнуть ошибки - Ремонт и установка крупной бытовой техники

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

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

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

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

Ресторан

Хоккей

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

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

Фильм

Кинопремия

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

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

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

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

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

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

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

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

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

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

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

Опыт менеджеров 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 пользуемся двумя инструментами: ретроспектива проекта команды и индивидуальная рефлексия для руководителя. Ретроспектива помогает регулировать эмоциональный фон команды, снимать обратную связь по прошедшему периоду и, что важно, — благодарить друг друга.

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

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

Куда я попал?
Что я планировал сделать?
Что получил в итоге?
Что получилось и не получилось?
Что я буду делать дальше?

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

Кристина Борисова

менеджер проектов в Redmadrobot

Какую из перечисленных ошибок вы совершали чаще всего?

Игнорировал мнения стейкхолдеров.

Не уделял должного внимания планированию.

Перекладывал ответственность на других.

Не использовал необходимые инструменты в работе.

Не ставил чётких приоритетов.

Не прописывал контрольных точек.

Не реагировал на изменения или критичные ситуации.

Не проводил рефлексию.

Редко подводил итоги.

Показать результаты

Переголосовать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опыт предпринимателя

«Самостоятельно готовили бизнес-план и презентовали его в рамках Startup Show с Алексеем Алёхиным в январе 2020. Речь шла о спортивной яхте Believer. Каждый этап подготовки оказался полон инсайтов: и подсчёт ёмкости рынка, и анализ конкурентной среды, и бизнес-модель. И маркетинговая стратегия. И самое интересное, что по итогам написания бизнес-плана появилась уверенность в том, что инвестор не так уж и нужен. Что бизнес-план просто показал чётче и ярче. Инвесторов очень впечатлила концепция и финансовая модель проекта. И нас пригласили на Финал Startup Show в Дубай на 22 февраля. Но мы отказались из-за пандемии коронавируса»

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, для того что бы учесть форсмажоры и избежать конфликтов.

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

Основные риски разработки бизнес-планов

Типичные ошибки при составлении бизнес-планов

Решения, позволяющие повысить качество бизнес-планов

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

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

Основные риски разработки бизнес-планов

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

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

И хотя раздел о рисках последний в бизнес-плане, он, безусловно, является очень важной его частью:

• во-первых, он содержит критический обобщенный анализ, подтверждающий корректность предыдущих разделов;

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

• в-третьих, позволяет потенциальным заказчикам и инвесторам оценить качество проработки всех показателей бизнес-плана компании.

Риски, которые могут помешать компании достичь целей бизнес-плана, делятся на неконтролируемые (внешние) и контролируемые (внутренние).

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

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

Например, вероятность реализации производственных рисков можно снизить, если:

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

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

• контролировать качество продукции на всех этапах производства.

А чтобы минимизировать операционные риски:

• назначаем ответственных за функционирование бизнес-процессов на всех стадиях реализации бизнес-плана;

• по максимуму автоматизируем бизнес-процессы;

• контролируем выполнение сотрудниками внутренних инструкций и регламентов;

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

Несмотря на большое количество рисков, которые могут влиять на выполнение бизнес-плана, они имеют характерные особенности и группируются по видам (рис. 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 % от проектной нагрузки.

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

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

Узнайте стоимость ремонта в течении 5 минут и забронируйте скидку 10% на все виды работы

1. Тип недвижимости:

Квартира/Дом

Офис/Бизнес-центр

3. Тип ремонта:

Бюджетный

Премиум

Элитный

Срочный

4. Вид ремонта:

Косметический

Капитальный

Евроремонт

Под ключ

Делаем расчет ремонта

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

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

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

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

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

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

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

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

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

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

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

Ошибки проектировщиков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Старт разработки без сформированных требований к проекту

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

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

Это хороший выход из ситуации — такое ТЗ можно предложить оценить другим разработчикам, получите срез рынка и сможете выбрать подходящую цену. Исследование занимает одну-две недели, в некоторых случаях дольше. Цена зависит от студии: кто-то предлагает делать за 50 000 рублей, кто-то может сделать за 300 000 рублей.

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

Велик риск, что в какой-то момент появится фича, с внедрением которой неопытный подрядчик вообще не сможет справиться.

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

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

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

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

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

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

Если увлечетесь процессом, посоветую книгу Карла Вигерса и Джоя Битти «Разработка требований к программному обеспечению». Или закажите формализацию и оценивайте сроки и бюджет по ней.

Недооценка сложности задачи из-за недостатка опыта и компетенций

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

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

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

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

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

Неготовность выбирать между качеством или скоростью

В разработке стартапов обычно есть две крайности:

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

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

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

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

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

Ориентируйтесь на бизнес-задачу. Не идите на поводу у подрядчика. Если вам нужно быстро проверить идею — не слушайте советов делать медленно и основательно. Просто предусмотрите риски и расставьте приоритеты.

Ошибка в планировании — игнорирование времени на исправление ошибок и доработки

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

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

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

Или есть понятие «историчность данных» — когда разработчики закладывают в базу данных возможность сохранять старые версии каких-либо данных.

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

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

Технический долг накапливается, и если не выделять время на его исправление, проект пострадает:

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

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

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

Расчет на быстрое формирование команды

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

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

Решение интересного проекта, который влияет на жизнь. В определенный момент разработчику становится неинтересно работать просто за деньги, особенно когда базовые потребности закрыты. Хочется приносить пользу, чувствовать энтузиазм. Если стартап может предложить такой интересный проект, отлично.
Сформированный HR-бренд. Нужно не просто предлагать хорошие условия разработчикам, а еще и активно рассказывать про это. Придется качать PR-направление, вести контент-маркетинг, не только для клиентов, но и для потенциальных сотрудников. Я рекомендую делегировать это отдельным людям на фултайм.
Делегирование срочных задач. Стартап необязательно должен развиваться за счет собственного технического штата. На начальном этапе многим достаточно ресурса внешнего подрядчика, аутсорсинговой компании. Когда проект вырастет, подрядчиков можно использовать для решения срочных задач, пока вы формируете собственный штат.
Потенциальные доли в компании. Это стандарт для зарубежных компаний, но у нас формат еще не распространен. Поэтому опционы могут стать конкурентным преимуществом.
Разработка на непопулярном языке. Это очень спорная тема, но у нас сработала. Мы используем Haskell, а этот язык привлекает разработчиков, которые уже много где покодили и понимают, что хотят работать именно с этой технологией. Haskell сложный и мощный, плюс мы не конкурируем с крупными банками и богатыми стартапами, потому что они обычно используют популярные языки.

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

Кратко. Как не допустить ошибок, начиная разработку стартапа

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

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

Фото на обложке: Shutterstock / Who is Danny

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

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

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

Коллективная ответственность — это не всегда эффективно. Если сотрудники не понимают, кто поможет решить проблему и к кому можно обратиться с вопросом — проект рискует превратиться в хаос.

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

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

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

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

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

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

Почему срываются проекты и как этого избежать: базовые принципы проектного менеджмента

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

Профессия с нуля: курс даёт всю необходимую базу для работы в роли руководителя проекта
Упор на практику: каждый студент работает минимум с 4 различными проектами
Сопровождение: оперативная поддержка опытных кураторов и преподавателей

Согласно исследованию Института управления проектами (PMI), 21% проектов срываются из-за недостающих или ограниченных ресурсов.

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

Как решить. Увеличивать или сокращать количество ресурсов в зависимости от потребностей. Не начинать проект при недостатке ресурсов.

Почему срываются проекты и как этого избежать: базовые принципы проектного менеджмента

Так можно контролировать загруженность сотрудников

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

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

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

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

Почему срываются проекты и как этого избежать: базовые принципы проектного менеджмента

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

Также не забывайте проводить ретроспективы с командой по результатам работы.

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

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

Итак, менеджер проекта должен:

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

Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.

Источник

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

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

Ресторан

Хоккей

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

Фильм

Кинопремия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соберитесь вместе с коллегами и обозначьте, какие могут быть роли в команде. Например, менеджер — делает заметки во время встреч, а дизайнер — потом согласовывает их со стейкхолдерами — роли могут быть какими угодно, придумайте их сами.
Прикиньте какие роли на себя может взять каждый участник команды.
Проговорите основные обязанности каждой роли и за какой результат отвечает. Например, договоритесь, что именно менеджер назначает встречи, ведёт заметки по ходу встреч, и фиксирует их результаты; аналитик (так уж получилось, что он у нас очень чёткий парень) заводит задачи в таск-трекере и описывает их для команды; разработчики самостоятельно собирают прототипы на «Тильде», чтобы показать их стейкхолдерам или пользователям).

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

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

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

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

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

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

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

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

Решение:

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

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

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

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

Решение:

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

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

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

И в конце

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

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

Куда я попал?
Что я планировал сделать?
Что получил в итоге?
Что получилось и не получилось?
Что я буду делать дальше?

Кристина Борисова

менеджер проектов в Redmadrobot

Какую из перечисленных ошибок вы совершали чаще всего?

Игнорировал мнения стейкхолдеров.

Не уделял должного внимания планированию.

Перекладывал ответственность на других.

Не использовал необходимые инструменты в работе.

Не ставил чётких приоритетов.

Не прописывал контрольных точек.

Не реагировал на изменения или критичные ситуации.

Не проводил рефлексию.

Редко подводил итоги.

Показать результаты

Переголосовать

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

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

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

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

Время прочтения
5 мин

Просмотры 2K

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

Это плавающие ошибки

Если ты владелец IT-продукта и болеешь за свое дело, то без качественных технических заданий не обойтись. В больших нетиповых проектах постановка и формирование ТЗ становится нетривиальной. Нужно описать много условий, ветвлений и прочих сложных логических конструкций, которые «с наскоку» не реализовать, ведь на бумаге это выглядит лишь как набор абстракций. А так уж устроен наш мозг, что ему нужна конкретика и образы, а не полотна с текстом!

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

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

Есть всего два возможных базовых варианта. Остальное — их комбинации.

Вариант 1. Подумать и сформулировать набор правил для каждой сущности. Например, берем сущность «Переписка» и формулируем правила по ее доступности. Это может выглядеть следующим образом:

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

a. Проект получает статус «Заблокирован»

b. Проект получает признак «Снят с публикации»

c. Проект получает статус «Закрыт» (полное закрытие)

d. Специалист отказался от выполнения проекта на этапе поиска исполнителя

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

Кстати, как вы думаете, какой сюрприз (явно ненужный нам) можно получить по этому правилу? Напишите в комментариях, если заметите!

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

Лайфхак: это лучше зафиксировать в проектной документации в качестве принципа работы!

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

Но что, если вы не смогли чего-то учесть?

Тут на помощь приходит второй вариант постановки задачи…

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

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

3 состояния проекта S = (S1, S2, S3)
3 роли R = (R1, R2, R3)
и три атрибута А = (А1, А2, А3), которые зависят от того, как пересекаются S и R.

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

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

S1 + R1 = А1

S1 + R2 = А2

S1 + R3 = А3

S2 + R1 = А1

S2 + R2 = А2

S2 + R3 = А3

S3 + R1 = А1

S3 + R2 = А2

S3 + R3 = А3

Таким образом, пересечение двух небольших множеств, состоящих всего из трех объектов дало нам выборку из 9 вариантов!

А если множество статусов S получит еще статус S4? Сколько будет вариантов? Уже 12!

А если размеры обоих множеств станут равны 4-м? Тогда вариантов будет 16!

Это я еще не привел пример, когда нам нужно пересечь 3 множества или больше!

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

Неполная карта частных случаев из одного фриланс-проекта

Применимость на практике и «плавающие» ошибки?

Мы рассмотрели два способа подачи информации для ТЗ в сложных проектах. Я считаю, что у обоих способов есть свои преимущества и недостатки.

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

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

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

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

Другими словами это, когда:

после проверки было: S1 + R1 = А2 (неправильно), а S1 + R2 = А2 (правильно)
после исправления стало: S1 + R1 = А1 (правильно), а S1 + R2 = А1 (неправильно)

Таким образом, наша ошибка уплыла из случая S1 + R1, но приплыла в случай S1 + R2.

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

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

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

При таком подходе снять с себя ответственность уже не получится, а это уже прямое указание на чью-то возможную некомпетентность или лень!

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

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

Буду рад, если вы поделитесь в комментариях своим опытом борьбы с плавающими ошибками! Как решали подобные ситуации? Были ли конфликты на этой почве?

Автор и ведущий персонального блога «ПРО-продукт» https://t.me/productmaster

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

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

Опыт предпринимателя

«Самостоятельно готовили бизнес-план и презентовали его в рамках Startup Show с Алексеем Алёхиным в январе 2020. Речь шла о спортивной яхте Believer. Каждый этап подготовки оказался полон инсайтов: и подсчёт ёмкости рынка, и анализ конкурентной среды, и бизнес-модель. И маркетинговая стратегия. И самое интересное, что по итогам написания бизнес-плана появилась уверенность в том, что инвестор не так уж и нужен. Что бизнес-план просто показал чётче и ярче. Инвесторов очень впечатлила концепция и финансовая модель проекта. И нас пригласили на Финал Startup Show в Дубай на 22 февраля. Но мы отказались из-за пандемии коронавируса»

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. Несоблюдение рамок соглашения бизнес-плана

В статье рассказывается:

Основные причины и последствия ошибок проектирования
Наиболее распространенные ошибки проектирования ПЗУ
Ошибки проектирования в архитектурных и объемно-планировочных решениях
Ошибки проектирования в конструктивных решениях
Примеры ошибок проектирования из практики
Из-за каких ошибок проекты чаще всего не проходят экспертизу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не предоставляется информация об уровне ответственности объекта, предусмотренном «Техническим регламентом о безопасности зданий и сооружений». Нередко коэффициент надежности по ответственности зданий и сооружений принимается по указаниям ГОСТа. Это влечет за собой нарушение приоритетных на данный момент требований п. 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.

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

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

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

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

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

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

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

Узнайте стоимость ремонта в течении 5 минут и забронируйте скидку 10% на все виды работы

1. Тип недвижимости:

Квартира/Дом

Офис/Бизнес-центр

3. Тип ремонта:

Бюджетный

Премиум

Элитный

Срочный

4. Вид ремонта:

Косметический

Капитальный

Евроремонт

Под ключ

Делаем расчет ремонта

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

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

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

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

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

Ошибки проектировщиков

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

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

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

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

Почему срываются проекты и как этого избежать: базовые принципы проектного менеджмента

Профессия с нуля: курс даёт всю необходимую базу для работы в роли руководителя проекта
Упор на практику: каждый студент работает минимум с 4 различными проектами
Сопровождение: оперативная поддержка опытных кураторов и преподавателей

Почему срываются проекты и как этого избежать: базовые принципы проектного менеджмента

Так можно контролировать загруженность сотрудников

Почему срываются проекты и как этого избежать: базовые принципы проектного менеджмента

Также не забывайте проводить ретроспективы с командой по результатам работы.

Итак, менеджер проекта должен:

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

Основные риски разработки бизнес-планов

Типичные ошибки при составлении бизнес-планов

Решения, позволяющие повысить качество бизнес-планов

Основные риски разработки бизнес-планов

И хотя раздел о рисках последний в бизнес-плане, он, безусловно, является очень важной его частью:

• во-первых, он содержит критический обобщенный анализ, подтверждающий корректность предыдущих разделов;

Например, вероятность реализации производственных рисков можно снизить, если:

• контролировать качество продукции на всех этапах производства.

А чтобы минимизировать операционные риски:

• назначаем ответственных за функционирование бизнес-процессов на всех стадиях реализации бизнес-плана;

• по максимуму автоматизируем бизнес-процессы;

• контролируем выполнение сотрудниками внутренних инструкций и регламентов;

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

ТИПИЧНЫЕ ОШИБКИ ПРИ СОСТАВЛЕНИИ БИЗНЕС-ПЛАНОВ

Цели проекта несоразмерны потенциалу компании.

Занижается требуемый объем инвестиций.

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

#статьи

19 май 2022
0

Управление рисками в проекте: как найти и оценить, как составить план защиты от них

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

Кадр: фильм «Исходный код»

Анна Игнатьева

Обозреватель Skillbox Media по маркетингу и IT. С 2015 года работает с SEO, таргетированной и контекстной рекламой. Писала для Skypro, Yagla и Admitad.

Риски — неотъемлемая часть любого проекта, от семейного праздника до строительства гидроэлектростанции. Ни один проект не следует плану на 100%, даже если им руководит опытный менеджер. Управление рисками — отрасль проектного управления со своими техниками и методиками.

Мы перевели и пересказали главное из лекции об основах управления рисками «Risk Management Basics», которую подготовили в Google для курса по управлению проектами.

Что такое риски в проекте
Самые распространённые виды рисков
Как найти риски в проекте и оценить их
Вы нашли риски: что с ними делать
Как составить план по управлению рисками

Есть много определений риска, но мы дадим очень простое. Риск — это негативное событие, которое может произойти, а может и не произойти. Риски нужно отличать от проблем: риск станет проблемой, только если негативное событие произойдёт.

Проблемы мешают выполнению задач проекта. Если вы руководите проектом, вы должны помнить, что несёте ответственность за риски.

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

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

Фото: VILTVART / Shutterstock

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

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

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

Есть разные классификации рисков. Мы назовём виды рисков, которые упоминают чаще остальных.

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

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

Риски изменения объёмов работы. Они могут появиться, если исполнители не поняли требований заказчика или он сам внёс в проект изменения. Это может привести к пересмотру бюджета, сроков и списка задач.

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

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

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

Зависимости. Это связи между двумя задачами в проекте: когда начало одной задачи зависит от завершения другой. Зависимости часто становятся риском для проекта.

Например, один из членов команды должен подписать контракт с заводом-поставщиком. Пока контракта нет — остальная команда не может выполнить ни один заказ. Если вовремя не подписать документ, то проект не закончат в срок.

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

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

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

Фото: chinahbzyg / Shutterstock

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

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

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

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

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

Вот диаграмма Исикавы, составленная для анализа проблемы — у компании низкие продажи.

Так выглядит диаграмма Исикавы с тремя уровнями факторов. Пока она не заполнена до конца
Инфографика: Майя Мальгина для Skillbox Media

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

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

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

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

Инфографика: Майя Мальгина для Skillbox Media

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

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

Потом оцените вероятность того, что риск возникнет:

Высокий — высокая вероятность риска.
Средний — риск есть.
Низкий — скорее всего, риска нет.

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

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

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

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

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

Рассмотрим каждый способ.

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

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

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

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

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

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

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

План можно создать в «Google Документах». Так все члены команды будут иметь к нему доступ. Укажите название компании, название проекта и кто создал этот документ — чтобы было понятно, к кому обращаться, если возникнут вопросы. Также можно написать, когда документ был создан и когда обновлялся в последний раз. Так команда будет понимать, насколько он актуален.

Так может выглядеть шапка плана по управлению рисками
Скриншот: Google Career Certificates / YouTube

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

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

Например, один из рисков — поставщик не успевает уложиться в сроки. У этого риска средний уровень. Для снижения риска есть решение: ежедневно созваниваться с поставщиком.

Инфографика: Майя Мальгина для Skillbox Media

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

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

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

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

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

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

Другие материалы Skillbox Media по управлению проектами

Что такое проект: разбираем главное понятие проектного управления
Kanban: рассказываем, как работает эта методика
Как планировать проекты и следовать графику работ с диаграммами Ганта
Что такое Agile: методология, команда, оценка эффективности
Как работает Scrum и как управлять проектом с помощью этой методики

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

Участвовать

Научитесь: Профессия Менеджер проектов
Узнать больше

Старт разработки без сформированных требований к проекту

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

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

Недооценка сложности задачи из-за недостатка опыта и компетенций

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

Неготовность выбирать между качеством или скоростью

В разработке стартапов обычно есть две крайности:

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

Ошибка в планировании — игнорирование времени на исправление ошибок и доработки

Технический долг накапливается, и если не выделять время на его исправление, проект пострадает:

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

Расчет на быстрое формирование команды

Решение интересного проекта, который влияет на жизнь. В определенный момент разработчику становится неинтересно работать просто за деньги, особенно когда базовые потребности закрыты. Хочется приносить пользу, чувствовать энтузиазм. Если стартап может предложить такой интересный проект, отлично.
Сформированный HR-бренд. Нужно не просто предлагать хорошие условия разработчикам, а еще и активно рассказывать про это. Придется качать PR-направление, вести контент-маркетинг, не только для клиентов, но и для потенциальных сотрудников. Я рекомендую делегировать это отдельным людям на фултайм.
Делегирование срочных задач. Стартап необязательно должен развиваться за счет собственного технического штата. На начальном этапе многим достаточно ресурса внешнего подрядчика, аутсорсинговой компании. Когда проект вырастет, подрядчиков можно использовать для решения срочных задач, пока вы формируете собственный штат.
Потенциальные доли в компании. Это стандарт для зарубежных компаний, но у нас формат еще не распространен. Поэтому опционы могут стать конкурентным преимуществом.
Разработка на непопулярном языке. Это очень спорная тема, но у нас сработала. Мы используем Haskell, а этот язык привлекает разработчиков, которые уже много где покодили и понимают, что хотят работать именно с этой технологией. Haskell сложный и мощный, плюс мы не конкурируем с крупными банками и богатыми стартапами, потому что они обычно используют популярные языки.

Кратко. Как не допустить ошибок, начиная разработку стартапа

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

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

Фото на обложке: Shutterstock / Who is Danny

Источник

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

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

Ресторан

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

Фильм

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

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

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

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

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

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

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

Источник

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

Соберитесь вместе с коллегами и обозначьте, какие могут быть роли в команде. Например, менеджер — делает заметки во время встреч, а дизайнер — потом согласовывает их со стейкхолдерами — роли могут быть какими угодно, придумайте их сами.
Прикиньте какие роли на себя может взять каждый участник команды.
Проговорите основные обязанности каждой роли и за какой результат отвечает. Например, договоритесь, что именно менеджер назначает встречи, ведёт заметки по ходу встреч, и фиксирует их результаты; аналитик (так уж получилось, что он у нас очень чёткий парень) заводит задачи в таск-трекере и описывает их для команды; разработчики самостоятельно собирают прототипы на «Тильде», чтобы показать их стейкхолдерам или пользователям).

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

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

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

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

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

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

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

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

Решение:

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

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

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

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

Решение:

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

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

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

И в конце

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

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

Куда я попал?
Что я планировал сделать?
Что получил в итоге?
Что получилось и не получилось?
Что я буду делать дальше?

Кристина Борисова

менеджер проектов в Redmadrobot

Какую из перечисленных ошибок вы совершали чаще всего?

Игнорировал мнения стейкхолдеров.

Не уделял должного внимания планированию.

Перекладывал ответственность на других.

Не использовал необходимые инструменты в работе.

Не ставил чётких приоритетов.

Не прописывал контрольных точек.

Не информировал команду.

Не реагировал на изменения или критичные ситуации.

Не проводил рефлексию.

Редко подводил итоги.

Показать результаты

Переголосовать

Проголосовать

Источник