Agile строительство дома пример
Обновлено: 18.05.2024
Применим ли Agile в строительстве?
Первый ответ, который приходит на ум – нет, Agile не подходит для использования в строительстве. Но при более пристальном рассмотрении оказывается, что некоторые принципы Agile и Lean вполне могут быть применены в строительстве и инжиниринге. В конце концов, разработку Программного обеспечения часто сравнивают со строительством здания.
В целом, Agile сложно использовать в строительных проектах, из-за более широкого горизонта планирования, а также в связи с тем фактом, что производить изменения на поздних этапах уже слишком сложно и дорого. Кроме того, ключевой принцип гибкой разработки, состоящий в получении заказчиком выгоды от инкрементов продукта, также не очень хорошо работает в строительстве. Редко когда можно начать получать выгоду от ещё не достроенного объекта. Тем не менее, некоторые концепции Agile, такие как близкое взаимодействие с заказчиком или несение заказчиком ответственности за внесённые изменения, могут и должны быть применены в строительстве. (Мнение Проектных Сервисов состоит в том, что данные элементы не являются исключительно отличительной чертой Agile – прим. пер.) Методы Lean менеджмента могут найти применение в строительных проектах в форме создания потоков материалов и информации и максимизирования ценности путём избавления от потерь.
После того, как созданы план строительства и расписание, при помощи метода расписание разбивается на небольшие отрезки для итеративной реализации. Такой подход позволяет улучшить контроль, повысить точность оценки. Инструмент проиллюстрирован на Рисунке 1. Подробнее о нём можно прочесть здесь.
Рисунок 1. Процесс разбиения работы на итерации в строительстве Last Planner System
На Рисунке 2 приведены инструменты из строительства, которые максимально близко соответствуют инструментам Agile. Русскоязычные термины в строительстве слишком отличаются от англоязычных, и в их переводе много разночтений, однако специалисты поймут, что к чему. Оставим локализацию названий инструментов профессиональному сообществу. Тем не менее, такие параллели существуют. Перейдём к рассмотрению ролей и функций, которые могут быть использованы при адаптации Agile в строительстве.
Рисунок 2. Функциональные соответствия инструментов и терминов в Agile и Строительстве
Начальник участка способен взять на себя роль Скрам-Мастера, ведь он руководит командой напрямую и отвечает за результаты, находится в прямом контакте с командой, непосредственно руководит ей и способен быстро собрать всех членов команды на короткое совещание. Инженер проекта или Менеджер проекта обладают достаточной информации о продукте, чтобы выступать в роли владельца продукта. Кроме того, они принимают решения о том, как интерпретировать требования и спецификации, а также взаимодействуют с группами заинтересованных сторон.
По мнению автора статьи, применение Agile в строительстве имеет смысл в проектах большого масштаба и повышенной сложности. Таких проектов, в которых классический набор инструментов управления проектами не даёт нужных результатов. В основном речь идёт об инфраструктурных проектах – расширении сети Интернет в неподключенные регионы или строительство Умных сетей электроснабжения Smart Grid.
Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.
Поточное производство, Lean и Agile в строительстве
Динамичная среда, неопределённость условий, сложность строительных проектов и невозможность проведения полноценной инженерной подготовки служат причиной поиска методологий управления строительными проектами для повышения эффективности их реализации.
Одна из основных причин этих проблем — отсутствие отраслевых методологий управления. За годы рыночной экономики не сформировались фреймворки, отвечающие вызовам и требованиям рынка.
Большинство строительных компаний продолжает применять обломки моделей управления административно-командной экономики, используя устаревшие управленческие структуры «янтарных» организаций, сочетая их с «оранжевыми» методами управления.
Уровень внешних вызовов, внутренние противоречия, консервативность отрасли заставляют действовать участников ситуативно, что служит первичным показателем гибкости и может быть толчком для изменения майндсета большинства руководителей, а также расцениваться как готовность к поиску новых методов управления.
В качестве лучших практик управления производством и проектами к строительной отрасли можно принять две методологии:
- Lean, она хорошо работает для сформированных и предсказуемых производственных процессов проекта.
- Agile — гибкое управление проектом, которое прекрасно подходит для неопределённых и динамичных этапов проекта.
Методология управления строительным проектом, которая сможет объединить Lean и Agile в единое целое, для отрасли служит неизбежным ответом на существующие вызовы и новые требования четвёртой промышленной революции.
Традиционные методы управления строительством, или методы Lean-constructionПроектное управление (PM BoK) как методология управления строительным проектом ориентирована исключительно на менеджмент задач, реализацию проекта в соответствии с ключевыми показателями проекта, минимизацию рисков и рассматривает строительно-монтажные работы как преобразование входа в выход.
Это существенный недостаток проектного управления, так как эта методология не обеспечивает прогресс в строительстве, не ведёт к повышению производительности труда, не учитывает интересы всех участников проекта.
Требуется методология, обеспечивающая комплексный подход к жизненному циклу строительного проекта, базирующийся на понимании проектирования и производства работ как процесса создания ценности и потока.
В качестве основного сейчас применяется последовательный подход к выполнению проектно-изыскательских и строительно-монтажных работ, который основан на одном из трёх методов выполнения работ. Он предполагает, что достигнуть хорошего результата можно, тщательно спланировав и организовав процесс проектирования и строительства.
Традиционно строительно-монтажные работы выполняют по одному из трёх методов:
- Последовательному (простой).
- Параллельному (сложный).
- Поточному (высший пилотаж).
Поточный метод основан на последовательном выполнении простейших операций и максимальном совмещении строительных процессов для создания производственного ритма потока. Надо сказать, что массовое применение поточного метода в строительстве закончилось с распадом СССР как часть плановой экономики.
Тогда научно было обосновано, что коренное улучшение организации труда даст внедрение поточных методов в строительство.
Применение поточного метода строительства домов по Большой Калужской улице в Москве еще в 1938 году позволило снизить трудоёмкость строительства до полутора человеко-дней на 1 м³ готового здания против двух с половиной человеко-дней на других стройках.
Бережливое производствоLean ориентирован на эффективное использование ресурсов, сокращение операций, которые не добавляют продукту ценности. Это позволяет уменьшить жизненный цикл производства и понизить конечную стоимость продукта. Lean как система включает методики, инструменты и подходы к управлению.
Lean предусматривает тщательное планирование, но исходит из того, что неопределённость (внешний и внутренний хаос) — это естественное состояние строительного проекта. Даже выполнение тщательно спланированных планов может быть поставлено под угрозу.
Центральная идея бережливого производства, сформулированная Тайити Оно, — поиск и применение системных методов снижения всех видов потерь, таких как:
- Перепроизводство — увеличение объёмов незавершенного производства, а также выполнение работ больше, чем предусмотрено графиком финансирования, возникает из-за огрех в планировании и низком контакте с заказчиком.
- Брак и переделки — когда отсутствует встроенная система защиты от брака, мы фактически делаем два раза одну и туже работу, а платят нам один раз.
- Передвижение — персонал, материалы, оборудование, механизмы перемещаются, но не создают ценности. Это один из крупнейших источников потерь, он возникает незаметно и трудно учитывается при применении традиционных методов строительства.
- Транспортировка — перемещение материалов дальше, чем нужно, создаёт дополнительные затраты на технику и трудозатраты (погрузка, разгрузка, транспортировка). Это не добавляет ценности.
- Излишние запасы — материалы и сырьё с оборотом менее десяти раз в год, порча, воровство, дорого содержать склады.
- Излишняя обработка — дополнительные работы и качества продукта, за который заказчик не готов платить.
- Ожидание — люди, операции, продукция вынуждены дожидаться действий, информации, материалов, съедает время и деньги.
Обе теории: и теория поточного производства, и бережливое производство, — произошли путём развития принципов организации работы конвейерного производства применительно к строительной отрасли. Их основная цель — минимизация стоимости и сроков строительства за счёт сокращения потерь при обеспечении надлежащего качества.
Цель одна, а способы и методы реализации разные.
С учётом того, что методы поточного производства строительно-монтажных работ уже не во всех вузах преподают, а строительный конвейер можно увидеть разве что на объектах с участием иностранных компаний, строителям пора задуматься, каким образом создавать ценность заказчику, какие методы выбрать для изменений своих производственных процессов и повышения производительности труда.
60 дней фильмов и сериалов по промокоду Показать ещё 8 комментариев Популярные По порядку Написать комментарий.Спасибо, круто.
Но как справитесь с такой задачей.
Как применять Lean в случае изготовления индивидуальных заказов. Заказы индивидуальны, переработка сырья не возможна вообще. Да и с 1 единицы сырья можно порой изготовить от 1 до 4 единиц продукции.
Затраты на изготовление продукции где в одном индивидуальном заказе 1 единица составляет допустим 100 р, а где в одном заказе 4 единицы и так же использована 1 единица сырья расходы составляют 200 р.
Минимизировать сроки изготовления можно, но если привлечь новые технологии, тогда стоимость сырья будет на 1 единицу 100 р. а на 4 400 р. Здесь уже нет экономии. Но экономия при производстве больше.
В первом случае при 1 единице время на промежуточный этап занимало от 4 до 16 часов , 4 единицы от 6 до 16 ч.
Во втором случае при одной единице 60 мин, при 4 единицах 120 минут.
Меньше времени но расходов больше.
Так понимаю получилась путаница)) или смогли понять?)
теория поточного производства и бережливого производства пришли из конвейерного производства, поэтому для индивидуальных лучше применить фреймворки Agile, например Scrum :)
Не-а, не получится. Дешево. Продукция может стоить 2000-6000 реальных рублей. Хотя да иногда и 200 000, но это редко бывают такие заказы.
Николай Злобин и метод бригадного подрядаДа, были люди! Таких уже не делают..
Поточное производство и lean согласен, они и применимы и эффективны. Но как вы видите реальное применение agile? И чем это в данном контексте будет отличаться от lean?
Спасибо! Завтра внесу преложения )
Написать комментарий. Читать все 8 комментариев GoTech Innovation Подписаться Отписаться Осталось всего 3 дня, чтобы подать заявку в Finlanding Alex Petrov Подписаться Отписаться Согласно постановлению Правительства группам МИД и МВД поручили вернуть на родину 500 тысяч россиян-эмигрантов11 сентября 2021 года вышло Постановление Правительства Российской Федерации от № 1541 "О внесении изменений в государственную программу Российской Федерации "Обеспечение общественного порядка и противодействие преступности" согласно ему, до 2030 года в страну планируется вернуть не менее 500 тысяч граждан, уехавших из России, следует из…
Agile строительство дома пример
Как известно, в скраме о роли менеджера проекта (Agile PM) не сказано ни слова. Хотя в других гибких методологиях, таких как, например, Feature Driven Development (FDD), роль менеджера проекта (PM) предусматривается, однако его обязанности сводятся к выполнению административных задач по проекту, ресурсному управлению и возможной помощи в координации команды разработчиков. Это, разумеется, является малой часть того перечня обязанностей, которые описаны в руководстве по управлению проектами PMBOK. Например, в соответствии с FDD, эти обязанности отводятся роли менеджера по разработке (Development Manager), а не менеджеру проекта. Менеджер Agile-проекта (далее Agile PM), действуя за рамками тактической роли PM, занимается общей стратегией и координацией проектов. Agile PM дополняет свои кросс-дисциплинарные навыки традиционного PM уникальным умением принимать решения и действовать в контексте стремительных, изменчивых проектах в условиях разработки по гибким методологиям.
Так кто же такой Agile PM и каковы его функции? Можно рассматривать Agile PM как уникального специалиста с весьма специфическим набором навыков, которые позволяют ему/ей владеть, по мере необходимости, частью обязанностей двух или нескольких ролей одновременно. В скраме эти роли могут включать в себя роль владельца продукта (PO) и скрам-мастера, то есть в рамках одного проекта Agile PM может действовать больше как скрам-мастер, а в другом — как PO, в зависимости от потребностей каждого проекта, не в полной мере заменяя, но дополняя работу скрам-мастера или PО. Agile PM использует опыт управления проектами, чтобы помочь обеим сторонам (PO и скрам-мастер плюс команда разработчиков), заполняя пробелы и при этом всегда стремясь к лучшему результату для проекта и выполняя больше работы.
В Agile-проектах скрам-мастер, как правило, рассматривается как «владелец процесса». В его обязанность входит контроль соблюдения командой скрам- и agile-практик. Однако если рассматривать распределенные проекты разделение ролей дает нам определенные преимущества, т.к. большую часть времени команда разработчиков и PO находятся в разных странах, работа с конкретными лидерами на местах, позволяет обеспечить достижение целей проекта. Так, например, скрам-мастер и Agile PM могут работать совместно, чтобы вести проект и руководить географически удаленными командами. Agile PM берет на себя те задачи, которые, как правило, принадлежат бизнес-партнеру для обеспечения плавного продвижения проекта, когда заказчик не присутствует физически, чтобы встретиться с командой разработчиков. С принятием на себя этих обязанностей от имени клиента, работа Agile PM становится критически важной в обеспечении прогресса и успеха распределенных проектов. Наличие Agile PM также благотворно сказывается и на не распределенных командах. Поскольку распределенные команды находятся в разных помещениях, то осмотические коммуникации не работают, тогда именно наличие Agile PM помогает восполнить пробел в коммуникациях, что имеет решающее значение для успеха проекта.
Agile PM отвечает за следующие задачи (но не ограничивается этим):
- решение вопросов размещения проектной команды;
- обучение и наставничество проектной команды;
- наполнение баклога продукта вместе с PO;
- создание баклога спринта с проектной командой;
- оценка стоимости, бюджетирование и контроль расходования средств, выделенных на проект;
- планирование коммуникаций;
- управление рисками;
- управление закупками.
В частности, на стороне PO, Agile PM может быть ответственным за проведение вводной встречи, а также за планирование и организацию других совещаний по проекту по мере необходимости. В этой ситуации Agile PM будет отвечать за подготовку и передачу письменных и устных отчетов для членов команды и заинтересованных лиц, а также за обновление и архивирование проектной документации по мере необходимости (например, если проектный офис (PMO) компании требует ведения проектной документации в определенном формате, то для создания таких документов в баклоге должны быть заведены соответствующие истории).
Agile PM может оказывать помощь PO в правильной передаче своего видения команде разработчиков (например, путем создания/поддержания вбаклога продукта с использованием методов оптимизации стоимости (Value Engineering)). Также Agile PM помогает скрам-мастеру быть уверенным, что у проекта есть некто, играющий роль владельца проекта, и что за процессом следят на стороне заказчика, а не только внутри команды разработчиков.
Менеджер проекта Agile в действии
Чтобы полностью понять работу Agile PM, рассмотрим в качестве примера один из недавних проектов одной фармацевтической компании, входящей в список Fortune 50. Компания выполнила разработку программного обеспечения и начальную миграцию данных с помощью распределенной команды разработчиков, состоящей из скрам-мастера и команды, ответственной за выполнения работ из баклога продукта в соответствии с целями спринта. В состав команды входили три программиста с разными специализациями (кодер, веб-дизайнер, специалист по работе с СУБД), один тестер и один архитектор программного обеспечения. В дополнение к удаленной команде разработчиков, владелец продукта и Agile PM, также были частью проектной команды. Проект длился 66 дней и состоял из пяти этапов.
Проект начался с четырехдневной подготовки, которую команда назвала нулевым спринтом. На этом этапе группа рассмотрела требования клиента и установила предполагаемые сроки, в это же время была обсуждена и намечена инфраструктура приложения. Одной из целей нулевого спринта было вовлечение клиента в обсуждение для разъяснения вопросов, связанных с бизнес-правилами, чтобы клиент, Agile PM и команда разработчиков выработали единый взгляд на проект.
На протяжении всех спринтов (продолжительность спринта составила 16 дней) Agile PM играл важную роль в организации проектных коммуникаций, включая организацию ежедневных совещаний с командой, совещаний с клиентом и проверку баклога для обеспечения своевременного завершения частей проекта, которые характеризовались определенным темами (theme), коучинг скрам-мастера с точки зрения способностей предвидеть возможные препятствия. Команды разработчиков, практикующие скрам, верят, что они способны обеспечить контроль над баклогом и доведением задач до завершения. Однако данная команда сделала вывод, что с учетом особенностей географического расположения команды и заказчика, процесс лучше выстраивается выделенным менеджером, отслеживающим выполнение задач.
Важно отметить, что Agile PM не брал на себя распределение конкретных задач в проекте, поскольку команда разработчиков была самоорганизована и справлялась с этим самостоятельно. Например, некоторые из незавершенных задач были достаточно сложны для разработчиков, поэтому они обратились за помощью к архитектору программного обеспечения. Кроме того, хотя разработчики выполняли дополнительные задачи помимо кодирования, такие как тестирование модулей и системы, а также регрессионное тестирование, им всегда помогал тестер.
Первый день каждого спринта включал сессию планирования, во время которой команда разработчиков занималась наполнением баклога спринта — осуществляла разбивку пользовательских историй из баклога на задачи, проводила оценку временных затрат на выполнение этих задач и назначала исполнителей для каждой задачи. Заказчик совместно с командой и Agile PM определял цель каждого этапа, которая фиксировалась на доске в комнате, где работала команда разработчиков.
В течение следующих 14 дней, команда разработчиков занималась реализацией и участвовала в утренних ежедневных совещаниях (daily scrum meeting). В ходе этих совещаний, Agile PM, с помощью веб-камеры, обсуждал с командой, что было сделано накануне, что будет сделано сегодня и выяснял, какие препятствия возникают по ходу спринта. Agile PM также принимал участие в отдельном ежедневном, совещании с PO, посвященному обсуждению всех препятствий и поискам решений. Последний день каждого спринта был посвящен одночасовой демонстрации. Команда разработчиков представляла клиенту и всем заинтересованным сторонам результаты спринта.
Преодоление географических границ и улучшение коммуникаций
Из-за того, что команда разработчиков и клиент находились в разных регионах (команда разработчиков находилась в Бразилии, в то время как PO находился в Нью-Джерси), Agile PM был ответственным за каждый из спринтов. Стоит отметить, что поскольку команда разработчиков и клиент находились в одном часовом поясе, от Agile PM требовалось меньше усилий по организации коммуникаций.
Постоянные коммуникации, управляемые Agile PM, дополняли рабочий ритм команды разработки. Команда отдала приоритет регулярному общению с заказчиком, что позволило обеим сторонам сосредоточиться на самых актуальных бизнес-целях на протяжении всего проекта. Объединяя приоритеты коммуникаций высокоэффективной команды и явное присутствие Agile PM в качестве посредника между двумя сторонами, распределенная команда сохранила курс через спринты, воплощая проекты в срок и с учетом желаемых характеристик.
Опыт прошедших этапов и создание репутации
С учётом того, что в скраме обучение в проекте так же важно, как поставка конечного продукта на протяжении всего проекта, команда проводила ретроспективы в конце каждого этапа, во главе с Agile PM, который находился в постоянном контакте со скрам-мастером и командой разработчиков. Целью этих сессий было определение путей улучшения совместной работы, с учетом того, что было, по мнению команды, сделано правильно или неправильно по ходу спринта.
В результате этих сессий, команда разработчиков укрепила свою репутацию среди клиентов, создавая основу для образцовых рабочих процессов и являясь ориентиром для других команд, которые работают с клиентами по другим направлениям в области разработки программного обеспечения. Кроме того, из-за постоянных ретроспективных обзоров в каждом спринте, команде разработчиков необходимо меньше времени, чтобы доказать свою правоту клиенту до принятия решения, что приводит к сокращению накладных расходов, а сокращение накладных расходов имеет решающее значение в условиях жесткой конкуренции на рынке разработки ПО.
Поскольку команда разработчиков выстраивала свою репутацию в глазах клиента, она также укрепляла командный дух, важность которого для команды, которая стремиться стать высокоэффективной довольно команды трудно переоценить. Команда стала чувствовать себя более уверенно в своей работе и получила возможность попробовать новые способы решения поставленных задач, в том числе предлагая улучшения бизнес-процессов, связанных с созданием программного обеспечения.
Понимание успеха
Помимо успешного решения задач заказчика, команда разработчиков также достигла и внутрикомандных успехов. Привлечение Agile PM позволило потратить меньше времени на внутреннее развитие, оперативно получать обратную связь и сосредоточиться на наиболее важных элементах проекта, отдав приоритет поставке наиболее ценной с точки зрения бизнеса функциональности. Благодаря ежедневному взаимодействию, заказчик знал, что войдет в поставку и когда она будет осуществлена, какой ценный для него результат будет получен в итоге. Agile PM также оказывал помощь PO в подготовке отчетов для топ менеджмента.
Оглядываясь на этот проект, команда разработчиков сделала вывод, что ее успех, скорее всего, не был бы возможен без Agile PM. Без постоянных коммуникаций и оперативного обнаружения возможных препятствий, которые могли бы привести к проблемам, переработке существующей реализации и задержкам в поставке проекта, затраты на проект могли бы быть существенными. Без Agile PM, обеспечившим, чтобы команда разработчиков и клиент были направлены на одни и те же бизнес-цели, обе стороны могли бы пойти разными путями, что привело бы к созданию командой менее эффективного продукта, не отвечающего потребностям клиента.
Кроме того, важно, что наличие Agile PM в скрам-проекте обеспечило прозрачность проекта в целом. Заинтересованные лица могли ежедневно отслеживать ход выполнения проекта и оценивать способность команды оперативно реагировать на необходимые изменения, чтобы обойти препятствия. Прозрачность повысила доверие клиента к команде разработчиков. Благодаря подобному сочетанию высокоэффективной команды и Agile PM, был выпущен по-настоящему ценный для клиента продукт.
Об авторе
Леонардо Абдала является менеджером проектов, ответственным за agile-проекты с участием Amazon Cloud (AWS), Microsoft, Drupal, а также за мобильные приложения и веб-сайты, совместимые с мобильными устройствами, разрабатываемые компанией Ci&T для своих международных клиентов, в том числе фармацевтической компании, входящей в список Fortune 50, корпорации маркетинга и рекламы, входящей в список Fortune 200 и организации в сфере здравоохранения LOB, входящей в список Fortune 500. Он отвечает за руководство географически распределенными командами разработчиков Ci&T, базирующихся в Бразилии, Аргентине и Китае, и работает с Agile более 5 лет и в рамках PMI более 9 лет. Леонардо имеет несколько сертификатов компании Microsoft (MCP, MCTS, MCPD, MCITP), а также «Certified Scrum Master (CSM)» и «Certified Scrum Professional (CSP)» от Scrum Alliance, а также сертификат «Project Management Professional (PMP)» от PMI. Лео также является профессором колледжа, в настоящее время он находится в отпуске, в Белу-Оризонти, Бразилия. Он имеет степень бакалавра наук (бакалавр) и степень аспиранта в изучении управленческих информационных систем.
Перевод
Савицкий Андрей участвовал в различных проектах в качестве разработчика, архитектора и руководителя проектов. Занимался разработкой автоматизированной банковской системы и интернет-банка для ОАО «Промсвязьбанк». Руководил проектами для Министерства Здравоохранения и Социального Развития. Окончил Московский Государственный Университет Приборостроения и Информатики и аспирантуру по специальности «Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных систем».
Генеральный директор в Сибирикс
Российские реалии: Разумно считать, что Product Owner-ов на стороне заказчиков сейчас не бывает. Особенно в корпоративном сегменте.
Там же надо брать ответственность, быстро принимать решения, обладать достаточным временем, компетентностью, видением. И самое главное — не на кого свалить, если fuckup. Перебирал в уме, вспоминал — ну может быть человека за последний год. И то — скорее исключение.
С этим нужно что-то делать, и поэтому из кустов появляется PM. В нашем случае его основной задаче является проксирование заказчика (или его команды). Proxy Product Owner.
Делает он все то же, что и должен делать Product Owner в классическом Agile. Но агрегируя требования от клиента. Иногда — самостоятельно их интерпретируя (или помогая интерпретировать клиенту). PM так же существенно влияет на приоритеты — по сути, он предлагает изначальный ход проекта. Однако PM не вмешивается в сферу деятельности команды, например — распределение задач.
Управляющий партнер в Бизнес-школа РИК
В статье описан здравый подход к роли менеджера в Agile. Поскольку команда вполне самостоятельна, менеджеру остаются роли администратора (закупки, офис, ведение бэклога, бюджетирование и учет, управление рисками) и наставника/лидера.
Я считаю, что в Agile менеджеру проекта опасно быть скрам-мастером, потому что у менеджера в силу его роли есть свои интересы в проекте. Мало того, эти интересы подвержены постоянным колебаниям из-за потока изменений, свойственного Agile-проектам. Это ведет к тому, что менеджер будет отклоняться от процесса вплоть до полного отказа от него, не говоря уже о том, чтобы выделять свое время на совершенствование процесса, на то, чтобы посмотреть на него со стороны. Именно поэтому скрам-мастером должен быть отдельный человек, который находится над конкретным проектом.
Agile строительство дома пример
В середине апреля пришел к нам в гости арендодатель и мило сообщил, что наш офис он продал неделю назад. Договор аренды был заключен, слава богу, с головой — так что мы могли оставаться по старому адресу аж до июля.
Ладно, не привыкать, пошли искать новую аренду под наши эксклюзивные требования (500 м2 оупенспейса с плюшками). Не нашли. В нашем городе помещений достойного качества просто нет. Зато нашли стройку, которая потенциально нам идеально походила. Один нюанс — она была на стадии котлована.
Ок. Договорились с новым владельцем продлить нашу аренду до конца августа. Застройщик пообещал пустить нас делать ремонт с середины июля. Решили: «За полтора месяца с отделкой по-минимуму — успеем!». И заключили договор инвестирования.
Да, в новый офис мы таки переехали 31 августа. А теперь — про нюансы :)
Делайте визуальные проекты на все, что только можно. Везде, где нет визуализации или чертежей — будут проблемы. Писать текстом и объяснять словами — бесполезно.
Аналогии на сайтах: делайте прототипы. Тех. задания никто не читает, пока не оказывается поздно. Проверяйте прототипы на понятность. Убедитесь, что они вас устраивают в каждой точке.
К началу ремонта у нас были проекты на:
Проекты на планировку. Стены поставили практически без проблем и без нашего участия. По ходу пришлось принимать решение: из чего и как их делать. В проекте этого не было. Послушали совет застройщика и сложили перегородки из кирпича (самый дорогой и долгий вариант). Это в итоге сэкономило нам кучу денег и времени, когда случился неожиданный, но предсказуемый форс-мажор (но об этом — ниже).
Проект на отделку и освещение (за исключением дизайнерской, переговорки, бухгалтерии и кухни с туалетами). Во всех помещениях, где не было проекта, пришлось по десять раз объяснять исполнителям устно, что и как сделать. Рисовать крестики на стенах. Спецификации никто не читает. Если читают — не понимают.
Проект на розетки. НО! Кроме плана розеток, оказывается, нужен был план проводки. У нас его не было (тут сыграла наша неопытность в стройке). В результате некоторые трассы силового кабеля перекладывали по два раза. Сам план по розеткам мы проверили не дотошно. Как результат — в бухгалтерии двадцать розеток на два компьютера, а у программистов — по 2 розетки на 4 рабочих места. Однако у нас — agile-стройка! Поэтому делаем дополнительную итерацию, рисуем на стенах крестики и добавляем розетки в соответствии со здравым смыслом.
Проект на вентиляцию и слаботочку (всякая сигнализация). Однако мы не согласовали проект с электриками. Эх. Короче, кто первый встал — того и тапки, а провода у нас местами теперь висят так:
Примерно такой же код будет в вашем проекте, если, например, 1С-ники не договорятся с разработчиками.
Проводите ежедневные стендапы. Выясняйте, что было сделано вчера, какие планы на сегодня и какие есть проблемы.
Очевидные вещи, которые не описаны в ТЗ, никому, кроме вас, не очевидны. Как только видите, что что-то в разработке выходит не так, как надо вам, — не ждите, задавайте вопросы. Чем раньше это сделаете, тем проще будет что-то изменить.
Прихожу я на стройку (еще до переезда). Сантехники сверлят отверстиЕ (ОДНО) под трубы с водой. Начинаю выяснять — почему так. Говорят: «Только под холодную сказали делать». Звоню застройщику — уточнить, когда ж под горячую будут сверлить. Выясняю, что по проекту горячая вода в здании не предусмотрена. В смысле совсем. Все коммуникации в договоре (считай, в ТЗ) значились одной строкой. Ведь _МНЕ ЖЕ БЫЛО ОЧЕВИДНО_ что они включают также и горячую воду. Пришлось вежливо удивиться. Застройщику — респект и спасибо, выводы воды в итоге сделали. Сама горячая вода будет (надеюсь) в следующей итерации.
Делайте по процессу!
Если для чего-то есть отлаженный и эффективный процесс, его не надо лишний раз менять и даже параллелить. Без великой нужды.
У нас такая нужда была, поэтому начали отделку до того, как закрыли крышу. Параллельно запустили на объект всех: отделочников, электриков, сантехников, вентиляционщиков, слаботочников, дверников, оконщиков (кого забыла?). Параллелить — да, быстрее. Но возможны внезапные факапы и дополнительные расходы. Все шло своим чередом, когда застройщик ВНЕЗАПНО решил, что не плохо бы пристроить 5-й этаж. Кстати, 2ГИС до сих пор считает, что у нас 3 этажа. Ну-ну.
Катастрофа
У нас неожиданно пошел дождь, о котором прогноз погоды предупреждал за неделю. Помещение было готово под покраску. Вечером 26 августа.
Утром 27 августа я пришла на стройку и застала такую картину:
Дождь пошел ночью. На крыше — «временная мембрана» (если по-русски, ее просто полиэтиленовой пленкой застелили). «Временная мембрана» даже держалась сколько-то, пока на крыше не получился бассейн. А потом все это полилось к нам. На полу — сантиметров 5 воды, стены мокрые, в гипсокартонных конструкциях — аквариумы. С потолка льет сильнее, чем на улице.
Сроки отделки резко подвинулись на пару недель.
Надо было срочно предпринимать что-то. В полу просверлили дыры. «Не буду сверлить, провода мокрые!» — отпирался парень с фотографии. «Надо, Федя. Надо!». Сушили дизельными пушками, газовыми горелками и вентиляторами.
Не бойтесь запускаться поэтапно.
Мы перевезли вещи 31 августа в недосохший офис, где не было большей части напольных покрытий, отделки, воды, канализации, надежной крыши, электричество — по времянке удлинителем со стройки. Первую неделю ребята работали из дома, кого совсем прижало — приезжали на планерки. В офисе была я, наш директор, Владимир Завертайлов, и все ремонтники одновременно и по очереди. Туалет — деревянный во дворе или в кафе через дорогу. Вода — в бутылках в магазине. Дизельные пушки греют, коптят и дышать не дают.
Руководитель студии Sibirix
Пожалуй, это был самый трудный период для нас во всей стройке. Перевезенные вещи мешают строителям. Постоянные вопросы, координация параллельных потоков работ. Холодно. Мокро. Выходные на стройке для меня становятся нормой.
За неделю нам сделали временные коммуникации: вместо центральной канализации — местную выгребную яму. Воду провели шлангом от соседней церкви + поставили насос, чтобы она доходила до четвертого этажа. Электричество — раскидали удлинителями. К понедельнику у нас были работающие туалеты (со святой водой в промышленных масштабах) и часть помещения без полов и нормального света, но с достаточным количеством розеток.
Расставили столы — вывели работать почти всех.
Потом переехали в соседнюю комнату, пустили отделочников. Итого — за месяц привели офис в пригодное для относительно комфортной жизни состояние. Сейчас доводим до идеала и ждем, когда нам сделают территорию около здания.
Для себя я после такого экстремального опыта сделала вывод, что поэтапный запуск иногда можно заменить SAAS. Если бы сейчас у меня был выбор, то я бы, наверное, выбрала промежуточную временную аренду перед переездом и ремонт «по процессу». Нервы будут целее.
Product Owner на стороне клиента — это серьезная работа!
Да, на вашей стороне нужен менеджер, который будет заниматься проектом не меньше, чем менеджер проекта со стороны подрядчика. По 10 минут в день — не получится.
В активной фазе разработки всегда возникает масса вопросов по проекту, не учтенных в ТЗ. Если нет — надо насторожиться. Пока не пришлось переделывать слишком многое. Примите как данность: подрядчики не знают, что у вас в голове. А написанное в ТЗ можно всегда понять не так. Контролировать придется вам. Если хотите гибко рулить процессом — будьте готовы «жить на стройке».
Бонусы: множество оперативных микро-решений, которые улучшают конечный результат.
Руководитель студии Sibirix
На стендапах с разработчиками мы просим, чтобы они наглядно показали, что именно было сделано ими за вчера. Прям пальцем на мониторе. Фразы «я писал абстрактный класс для генерации универсальной библиотеки работы с примитивами» — повод выхватить неиллюзорных люлей. На стройке — та же фигня. Не верьте на слово, а проверяйте. Идите и смотрите. Что из себя представляет «временная мембрана на крыше», мы додумались посмотреть, только когда нас уже залило.
Отклонения от проекта — это нормально!
Если в ходе разработки вы видите, что какие-то решения на прототипе или в техзадании не совсем оптимальные — смело отказывайтесь от них. Вы можете добавить в проект свои крутые идеи.
Дизайнеры по помещениям (как и по сайтам) самореализуются за счет вашего проекта, придумывая прикольную, но непрактичную фигню. Почему наш офис никогда не будет соответствовать картинке дизайнера? Потому что полки из ящиков физически не могут нормально держаться на гипсокартонных стенах, например.
В любом проекте бывают «нежданчики». У нас такими оказались канализационные стояки в неожиданных местах, трубы ливневой канализации и пожарный щит. Их придется либо обходить, либо смириться и оставить как есть. В любом случае будут отклонения от проекта. И это — НОРМАЛЬНО!
Time+Material — хорош только с проверенными разработчиками
Понятно, что всего не учтешь, но оценка должна быть. Нормально (и правильно) если это будет вилка. Но оценка должна быть. Общая, на весь проект, можно с большими вилками. Но четкая и конкретная, с конкретными сроками — на каждый небольшой этап (хотя и там возможны отклонения 0-20%). Трясите реальные и четкие сроки этапов. Фиксируйте их в договоре. Оговаривайте штрафы за просрочки.
У нас были сметы и сроки с погрешностью 0-20% по всем работам, кроме электрики (тут работали «по факту»). В итоге все сделали быстро и по вполне ожидаемой цене.
Электрику вместо двух недель делали два месяца, постоянно меняя бригады, переделывали по несколько раз. Итоговый счет соответствовал. Больше на таких условиях не подпишусь ни с кем и никогда.
Держитесь за хороших подрядчиков. Выбирайте тех, кто не пользуется субподрядом.
Не знаю как в web-разработке (сама не заказывала), но в строительстве хороший подрядчик — ценность, которую надо беречь. Причем важно, чтобы подрядчик не использовал субподрядчиков на вашем проекте.
У нас субподрядом делали электрику. Остальные — работали напрямую (искали по рекомендации). Все было круто, особенно бригада отделочников:
Так вот, про электриков. Мы поменяли несколько бригад-слоупоков на проекте. Хорошо работала только одна, которая от застройщика. Субподрядные — тормозили, тупили, выходили пьяными на объект, долго и вдумчиво пили чай. Пинать их было бесполезно. Банально нет никакого рычага влияния. Хотя один профессионал, с высокой самомотивацией, работавший быстро и на совесть (Михаил) был и в субподрядной организации. Один из пятнадцати.
Не покупайте хрен пойми у кого
Были у нас в проекте дизайнерские лампы. Из Китая. И чтобы у них фиксировались шарниры, нам пришлось покупать шайбы в магазине «Все для УАЗ». Опытные люди говорят, это почти нормальная практика для многих товаров такого рода из этой страны.
Примерно то же самое вас ждет с большинством модулей в маркетплейсах от непонятных производителей. Капитан говорит: по возможности выбирайте вменяемого производителя.
Минимизируйте количество подрядчиков
На проекте всегда нужен главный, особенно — когда много подрядчиков. Иначе многие проблемы станут неразрешимыми.
У нас была анекдотичная ситуация, когда вентиляционщики и электрики отказывались общаться между собой, чтобы решить вопрос по подключению кондиционеров. Поругались на каком-то проекте пару лет назад. Взрослые мужики с сединой в волосах наотрез отказывались коммуницировать друг с другом.
На сайтах, где есть сложная интеграция, разные подрядчики на смежных работах есть зло. Например — настройка 1С и интеграция 1С с сайтом.
Ну и напоследок:
Фиксируйте все договоренности, пишите резюме встреч и звонков. Устные договоренности не запоминаются.
Платите подрядчикам вовремя.
Закладывайте резервы. Слушать слишком оптимистичные прогнозы можно, но надо учитывать пессимистичные.
Если сайт — ваш основной проект, планируйте после его запуска отпуск. Релиз — это жестко.
Руководитель студии Sibirix
Я хочу сказать огромное спасибо всем ребятам из команды, кто преодолел со мной эти трудности переезда (кто не преодолел — ну что делать, извиняйте бывает. Делали что могли). Да, еще много чего осталось доделать по мелочи. Пофиксить баги. Тепло. Повторную покраску. Убрать мигающий свет. Но структура уже построена. Релиз выпущен. Следите за апдейтами!
Читайте также: