Автор: Павел Басманов
Loenne Maciel — моя хорошая знакомая, талантливый архитектор, работавшая в крупнейших архитектурных фирмах Европы. Её путь — очень вдохновляющий. Loenne из Бразилии, училась в Академии изящных искусств Сан-Паулу, а затем в The Bartlett School of Architecture, специализируясь на программе «Professional Practice and Management in Architecture».
В Декабре она успешно сдала сертификацию Project Management Professional (PMP) — самый престижный мировой сертификат в сфере проектного управления. Сдать такой экзамен крайне сложно и немногие с этим справляются. Loenne — талантливый лидер и явно знает многое, о чем могла бы рассказать.
Loenne также развивается в медийной сфере и с радостью делится своим опытом об архитектурном управлении в Инстаграме (@loenne_maciel).
Вдохновившись ее историей, я решил поговорить с ней, узнать о ее пути и о взгляде на современную культуру управления в Архитектуре.
В Декабре она успешно сдала сертификацию Project Management Professional (PMP) — самый престижный мировой сертификат в сфере проектного управления. Сдать такой экзамен крайне сложно и немногие с этим справляются. Loenne — талантливый лидер и явно знает многое, о чем могла бы рассказать.
Loenne также развивается в медийной сфере и с радостью делится своим опытом об архитектурном управлении в Инстаграме (@loenne_maciel).
Вдохновившись ее историей, я решил поговорить с ней, узнать о ее пути и о взгляде на современную культуру управления в Архитектуре.
Что побудило тебя сдавать экзамен PMP? Это было предложением вашей компании? Является ли сертификация PMP распространённой практикой для архитекторов в ЕС, стремящихся к роли руководителя проектов?
Меня всегда интересовала управленческая часть Архитектуры. Я верю, что творчество усиливается благодаря процессам, целям и ограничениям, а не через общепринятое мнение о полной свободе. С помощью PMP я стремилась глубже понять управленческие практики, которые могли бы повысить эффективность и развитие как на этапе создания, так и на этапе реализации проекта.
PMP был моим личным решением, и моя компания мне не предлагала его прохождение, хотя некоторые компании действительно делают сертификацию PMP обязательной для кандидатов претендующих на должности в проектном управлении.
PMP был моим личным решением, и моя компания мне не предлагала его прохождение, хотя некоторые компании действительно делают сертификацию PMP обязательной для кандидатов претендующих на должности в проектном управлении.
При подготовке к PMP многие мои друзья-менеджеры обычно читают бесчисленное количество книг и смотрят множество лекций. Они говорят, что подготовка к PMP значительно расширяет кругозор. Можешь ли ты поделиться своим опытом? Было ли у тебя так же?
Перед сдачей экзамена я уже знала о его сложности из-за огромного объёма материала и детализированных процедур. Мои ожидания оправдались — сложность заключалась не столько в запутанности информации, сколько в её объёме и разнообразии применения в зависимости от культуры компании и типа проекта.
Я посетила более 400 занятий, потратила несколько часов на изучение и повторение, а также прошла множество пробных тестов и тренировочных викторин. Рекомендуемое время подготовки варьируется: 3 месяца для медленного темпа, 2 месяца для среднего и 6 недель для быстрого. Мой подход заключался в том, чтобы в первые 4 недели получить общее представление о материале, а затем в последние 2 недели сосредоточиться на углублённом понимании, викторинах и повторении.
Я посетила более 400 занятий, потратила несколько часов на изучение и повторение, а также прошла множество пробных тестов и тренировочных викторин. Рекомендуемое время подготовки варьируется: 3 месяца для медленного темпа, 2 месяца для среднего и 6 недель для быстрого. Мой подход заключался в том, чтобы в первые 4 недели получить общее представление о материале, а затем в последние 2 недели сосредоточиться на углублённом понимании, викторинах и повторении.
Насколько применимы эти новые навыки в архитектуре? Мне кажется, что культура управления в архитектуре всё ещё отстаёт от многих отраслей, ей не хватает структуры и даже базового интереса к обучению у некоторых профессионалов. Каково ваше мнение?
Существует заблуждение, что творчество и управленческие практики не могут сосуществовать. В прошлом многие менеджеры выражали нежелание внедрять эти практики, когда я их предлагала, опасаясь, что это помешает творческому процессу. Однако реальность такова, что ограничения на самом деле усиливают творчество.
На мой взгляд, становление более «корпоративным» не подавляет творчество; напротив, это вводит практики, которые облегчают рабочий процесс, коммуникацию и документирование, позволяя архитекторам сосредоточиться на проектировании, не отвлекаясь на внутренние процессы, которые должны управляться через эти установленные практики. Это как научиться водить машину: когда процесс становится автоматическим, внимание переключается на путешествие и дорогу, а процедурные аспекты выполняются автоматически.
PMP предоставляет базовый набор инструментов, которые помогают структурировать проекты так, чтобы учитывать дополнительную работу и/или время без ущерба для бюджета, качества или благополучия команды. Он также даёт рекомендации по мониторингу и контролю выполнения проекта, обеспечивая анализ рисков и соответствующие меры реагирования.
Кроме того, сертификация знакомит с гибридными методологиями (agile (1) и waterfall (2)), которые могли бы значительно улучшить архитектурную отрасль, особенно при частых изменениях дизайна. Концепция «завершенности» (3) — это тоже то, что могло бы принести пользу архитекторам, поскольку дизайн часто очень субъективен.
На мой взгляд, становление более «корпоративным» не подавляет творчество; напротив, это вводит практики, которые облегчают рабочий процесс, коммуникацию и документирование, позволяя архитекторам сосредоточиться на проектировании, не отвлекаясь на внутренние процессы, которые должны управляться через эти установленные практики. Это как научиться водить машину: когда процесс становится автоматическим, внимание переключается на путешествие и дорогу, а процедурные аспекты выполняются автоматически.
PMP предоставляет базовый набор инструментов, которые помогают структурировать проекты так, чтобы учитывать дополнительную работу и/или время без ущерба для бюджета, качества или благополучия команды. Он также даёт рекомендации по мониторингу и контролю выполнения проекта, обеспечивая анализ рисков и соответствующие меры реагирования.
Кроме того, сертификация знакомит с гибридными методологиями (agile (1) и waterfall (2)), которые могли бы значительно улучшить архитектурную отрасль, особенно при частых изменениях дизайна. Концепция «завершенности» (3) — это тоже то, что могло бы принести пользу архитекторам, поскольку дизайн часто очень субъективен.
Представь, что ты присоединились к команде, где между коллегами нет коммуникации. Предыдущий руководитель проекта раздавал задания в стиле: «Открой модель в Revit и просто сделай что-нибудь». Передача концептуальных материалов заказчику запланирована через шесть месяцев, и в целом заказчик очень недоволен проектом. Что бы вы сделали первым делом? Какой процесс вы бы выбрали? Каковы были бы ваши главные приоритеты?
Я бы опиралась на методологии agile и waterfall. Мои ключевые действия были бы следующими:
Сначала я бы разобралась с внутренними проблемами, проведя собрание команды, чтобы оценить сильные стороны каждого участника и определить, соответствует ли команда их навыкам. Я бы также узнала их мнение о недовольстве клиента и собрала предложения по улучшениям. Важно вовлечь команду, чтобы они понимали цель своей работы и чувствовали, что их вклад имеет значение.
Затем я бы встретилась с заказчиком, чтобы понять его ожидания, разочарования и предпочтительный стиль общения. Отсутствие должной коммуникации часто является ключевым фактором недовольства заказчика. Я бы обсудила сроки проекта, выяснила, остаются ли они прежними, и определила, какие аспекты дизайна их больше всего интересуют. Я бы предложила небольшие итеративные поставки (в стиле agile), чтобы убедиться, что продукт соответствует их ожиданиям.
После того как заказчик определит свои приоритеты, я бы вместе с командой спланировала краткосрочные поставки, сосредоточившись на принципах, а не на финальных продуктах, чтобы получить раннюю обратную связь. Я бы внедрила ежедневные стендапы (используя методологию agile), где команда делится обновлениями и обсуждает необходимую помощь. Как только удовлетворённость заказчика будет восстановлена, а команда начнёт работать эффективно (используя стадии развития команды Такмана), я бы перешла к подходу waterfall, установив окончательную дату поставки и подготовившись к передаче проекта.
Важно понимать, что вступление в проект на середине пути — это как начало с нуля. Необходимы тщательное планирование, оценка и управление рисками.
Сначала я бы разобралась с внутренними проблемами, проведя собрание команды, чтобы оценить сильные стороны каждого участника и определить, соответствует ли команда их навыкам. Я бы также узнала их мнение о недовольстве клиента и собрала предложения по улучшениям. Важно вовлечь команду, чтобы они понимали цель своей работы и чувствовали, что их вклад имеет значение.
Затем я бы встретилась с заказчиком, чтобы понять его ожидания, разочарования и предпочтительный стиль общения. Отсутствие должной коммуникации часто является ключевым фактором недовольства заказчика. Я бы обсудила сроки проекта, выяснила, остаются ли они прежними, и определила, какие аспекты дизайна их больше всего интересуют. Я бы предложила небольшие итеративные поставки (в стиле agile), чтобы убедиться, что продукт соответствует их ожиданиям.
После того как заказчик определит свои приоритеты, я бы вместе с командой спланировала краткосрочные поставки, сосредоточившись на принципах, а не на финальных продуктах, чтобы получить раннюю обратную связь. Я бы внедрила ежедневные стендапы (используя методологию agile), где команда делится обновлениями и обсуждает необходимую помощь. Как только удовлетворённость заказчика будет восстановлена, а команда начнёт работать эффективно (используя стадии развития команды Такмана), я бы перешла к подходу waterfall, установив окончательную дату поставки и подготовившись к передаче проекта.
Важно понимать, что вступление в проект на середине пути — это как начало с нуля. Необходимы тщательное планирование, оценка и управление рисками.
Сейчас, работая в IT, я вижу культ гибких методологий — мы стремимся к этой парадигме. В то же время молодые архитектурные студии заимствуют многие термины из IT и пытаются их адаптировать, хотя, на мой взгляд, не очень успешно. Как думаешь, применимы ли методологии Agile в архитектурной практике? Какие аспекты на твой взгляд, работают?
Методологии Agile определённо могут работать в архитектуре, особенно для таких частей проекта, как разработка концепции, параллельные исследования или изменения дизайна. Любой проект с высокой степенью неопределённости относительно конечного продукта — хороший кандидат для agile.
Например, представьте ситуацию, когда фаза разработки дизайна (DD) завершена на 70%, а заказчик хочет изменить концепцию фасада. В этом случае часть команды могла бы продолжить разработку DD (используя waterfall), а другая команда работала бы над исследованиями фасада (используя agile). Важно, чтобы эти команды оставались на связи, а команда DD выступала консультантом для исследовательской команды во время стендапов.
Главное преимущество как agile, так и waterfall — их адаптивность к разным сценариям. Однако команда должна понимать правила обеих методологий. Им не обязательно быть экспертами, но они должны быть хорошо осведомлены, чтобы различать их при планировании и выполнении проектов. Также важно оценить сложность проекта, навыки команды и вовлечённость стейкхолдеров перед выбором методологии.
Например, представьте ситуацию, когда фаза разработки дизайна (DD) завершена на 70%, а заказчик хочет изменить концепцию фасада. В этом случае часть команды могла бы продолжить разработку DD (используя waterfall), а другая команда работала бы над исследованиями фасада (используя agile). Важно, чтобы эти команды оставались на связи, а команда DD выступала консультантом для исследовательской команды во время стендапов.
Главное преимущество как agile, так и waterfall — их адаптивность к разным сценариям. Однако команда должна понимать правила обеих методологий. Им не обязательно быть экспертами, но они должны быть хорошо осведомлены, чтобы различать их при планировании и выполнении проектов. Также важно оценить сложность проекта, навыки команды и вовлечённость стейкхолдеров перед выбором методологии.
Что не работает на практике или терпит неудачу, несмотря на теоретические обещания?
Изменения в заказах часто создают проблемы. В предсказательной методологии любые изменения в объёме проекта требуют формального процесса изменения заказа, включая счёт за дополнительную работу и корректировку сроков. Однако в архитектуре крупные изменения дизайна иногда рассматриваются заказчиками как часть разработки дизайна, а не как дополнительная работа.
Я однажды работала в фирме, где около 300 тысяч евро дополнительной работы остались неоплаченными. Заказчик утверждал, что это часть обычного процесса разработки дизайна и, поскольку это не было официально утверждено как дополнительная работа, они считали, что не обязаны платить. Эта ситуация подчёркивает важность определения концепции «готовности» с заказчиком до начала проекта и согласования количества обновлений и изменений.
Если компания ценит долгосрочные отношения с заказчиком, она может принять некоторые убытки ради возможности будущих проектов, но это должно быть внутренне обсуждено и чётко определено с самого начала.
Я однажды работала в фирме, где около 300 тысяч евро дополнительной работы остались неоплаченными. Заказчик утверждал, что это часть обычного процесса разработки дизайна и, поскольку это не было официально утверждено как дополнительная работа, они считали, что не обязаны платить. Эта ситуация подчёркивает важность определения концепции «готовности» с заказчиком до начала проекта и согласования количества обновлений и изменений.
Если компания ценит долгосрочные отношения с заказчиком, она может принять некоторые убытки ради возможности будущих проектов, но это должно быть внутренне обсуждено и чётко определено с самого начала.
Забавно, как заказчики по всему миру так похожи. Многие говорят, что в России они самые непредсказуемые, но я думаю, что видел и похуже. В IT бизнес тоже часто навязывает нереальные сроки, давит на инженеров и заставляет работать сверхурочно, если компания не отстаивает себя. На ваш взгляд, есть ли вина Архитекторов в этой истории? Есть ли у тебя советы по управлению, чтобы отношения с заказчиками стали проще?
Одним из ключей к управлению проектами является вовлечение стейкхолдеров. Управление проектами — это в основном управление ожиданиями людей и в некоторой степени управление самим проектом, и это относится ко всем заинтересованным сторонам, как внутренним, так и внешним.
Как бы жёстко это ни звучало, непредсказуемые заказчики часто являются результатом нашей неспособности вовлечь их, понять и предвидеть, что и когда они хотят. Это непростая задача, и она постоянная. Если заказчик новый, очень вероятно, что недоразумения будут возникать по ходу дела. В конечном итоге это процесс построения отношений. Ключ в том, чтобы ещё до начала проекта начать выстраивать эти отношения со стейкхолдерами, учитывая такие факторы, как: личность, бизнес-модель, толерантность к рискам, предпочтительный стиль общения, культурный фон и уровень влияния и интереса каждого участника — и затем планировать соответственно.
Например, допустим, это новый заказчик с репутацией очень требовательного и желающего множества изменений. В таком случае подготовьтесь к изменениям в последнюю минуту, создав среду, в которой вас не застанут врасплох. Эти решения могут даже сопровождаться дополнительной платой или коммерческим решением принять небольшой убыток ради обеспечения другого проекта с этим заказчиком. Вот почему так важно перед началом проекта обсудить внутри компании видение относительно этого заказчика.
Стройте отношения с клиентом, разговаривайте с ним, понимайте его разочарования и получайте удовольствие от процесса. Вам не нужно становиться друзьями, но определённо стоит выстроить дружелюбные отношения. Будьте открыты и прозрачны, ничего не скрывайте, будьте честны и выполняйте обещания. В конце концов, это люди, которые хотят завершить проект, заработать деньги и укрепить свою репутацию.
Как бы жёстко это ни звучало, непредсказуемые заказчики часто являются результатом нашей неспособности вовлечь их, понять и предвидеть, что и когда они хотят. Это непростая задача, и она постоянная. Если заказчик новый, очень вероятно, что недоразумения будут возникать по ходу дела. В конечном итоге это процесс построения отношений. Ключ в том, чтобы ещё до начала проекта начать выстраивать эти отношения со стейкхолдерами, учитывая такие факторы, как: личность, бизнес-модель, толерантность к рискам, предпочтительный стиль общения, культурный фон и уровень влияния и интереса каждого участника — и затем планировать соответственно.
Например, допустим, это новый заказчик с репутацией очень требовательного и желающего множества изменений. В таком случае подготовьтесь к изменениям в последнюю минуту, создав среду, в которой вас не застанут врасплох. Эти решения могут даже сопровождаться дополнительной платой или коммерческим решением принять небольшой убыток ради обеспечения другого проекта с этим заказчиком. Вот почему так важно перед началом проекта обсудить внутри компании видение относительно этого заказчика.
Стройте отношения с клиентом, разговаривайте с ним, понимайте его разочарования и получайте удовольствие от процесса. Вам не нужно становиться друзьями, но определённо стоит выстроить дружелюбные отношения. Будьте открыты и прозрачны, ничего не скрывайте, будьте честны и выполняйте обещания. В конце концов, это люди, которые хотят завершить проект, заработать деньги и укрепить свою репутацию.
В фирме, где я работал, было что-то похожее на Agile: ежедневные стендапы, много живого общения, итеративный процесс с еженедельной подачей альбома и чёткие короткие задачи. Но никто явно не использовал термины вроде Agile/Scrum/Kanban и т.д. Многие мои друзья, работающие в крупных европейских фирмах, подтверждают этот опыт. Кажется, что многие пытаются улучшить процессы схожим образом.
Я считаю, что рост технологических компаний заставил бизнес изменить подход, чтобы привлечь молодое поколение и ускорить переход от идей к конечному продукту. Это отражается не только в дизайне офисов компаний (например, у Google), но и в скорости разработки проектов.
С появлением ИИ я думаю, что даже методологии Agile устареют. Их основные принципы должны будут эволюционировать, и компаниям придётся принять совершенно иной образ мышления.
Вот как я вижу будущее управления проектами: традиционный перевёрнутый треугольник между Agile и Waterfall превратится во что-то вроде орбиты. Ключевые изменения, на мой взгляд, будут такими:
1. Время как центральное ограничение
С ускорением рабочих процессов благодаря ИИ, заказчики и стейкхолдеры будут всё больше ожидать быстрой доставки. «Скорость выхода на рынок» станет главным. Поскольку ИИ автоматизирует тяжёлую работу — планирование, отчётность и даже принятие решений, — давление на ускорение доставки только усилится. Время может стать настоящим неоспоримым фактором.
2. Качество как гибкий параметр
Мы уже видим сдвиг в определении качества. Во многих случаях, особенно с прототипами или ранними поставками, «достаточно хорошо» — это достаточно. С генеративными инструментами быстрые итерации и тестирование станут нормой. Качество всё ещё будет иметь значение, особенно в регулируемых отраслях, но, скорее всего, сместится к «пригодности для цели», а не к «безупречности».
3. Стоимость становится менее критичной
Поскольку инструменты становятся дешевле — или даже бесплатными. например, рендеры, текст и код, созданные ИИ, а также ИИ помогает в составлении бюджета и переговорах с поставщиками, предельные затраты на интеллектуальную работу сокращаются. Хотя труд людей, энергия и материалы всё ещё будут стоить денег, соотношение между технологиями и человеческими усилиями изменится. Я считаю, что затраты проявятся в других формах, таких как:
4. Объём становится текучим
Будущее будет склоняться к адаптивному объёму. Проекты будут начинаться с направления, а не с фиксированного объёма. Благодаря ИИ, обратной связи в реальном времени и быстрому прототипированию, команды будут совместно создавать объём по ходу дела. Это соответствует Agile, но на новом уровне, где «непрерывная эволюция» становится стандартом, а не просто мышлением.
Кроме того, с расширением ИИ и индустрии данных, обусловленным прогрессом в квантовых вычислениях, растёт спрос на всё более мощные вычислительные системы. Это потребует значительных модернизаций дата-центров, которые должны будут поддерживать эти высокопроизводительные системы. Следовательно, углерод может перестать быть единственным показателем устойчивости. Появятся новые метрики устойчивости, сосредоточенные не только на энергоэффективности, но и на управлении такими факторами, как рассеивание тепла, электромагнитные помехи и более широкое экологическое воздействие инфраструктуры вычислений следующего поколения.
С появлением ИИ я думаю, что даже методологии Agile устареют. Их основные принципы должны будут эволюционировать, и компаниям придётся принять совершенно иной образ мышления.
Вот как я вижу будущее управления проектами: традиционный перевёрнутый треугольник между Agile и Waterfall превратится во что-то вроде орбиты. Ключевые изменения, на мой взгляд, будут такими:
1. Время как центральное ограничение
С ускорением рабочих процессов благодаря ИИ, заказчики и стейкхолдеры будут всё больше ожидать быстрой доставки. «Скорость выхода на рынок» станет главным. Поскольку ИИ автоматизирует тяжёлую работу — планирование, отчётность и даже принятие решений, — давление на ускорение доставки только усилится. Время может стать настоящим неоспоримым фактором.
2. Качество как гибкий параметр
Мы уже видим сдвиг в определении качества. Во многих случаях, особенно с прототипами или ранними поставками, «достаточно хорошо» — это достаточно. С генеративными инструментами быстрые итерации и тестирование станут нормой. Качество всё ещё будет иметь значение, особенно в регулируемых отраслях, но, скорее всего, сместится к «пригодности для цели», а не к «безупречности».
3. Стоимость становится менее критичной
Поскольку инструменты становятся дешевле — или даже бесплатными. например, рендеры, текст и код, созданные ИИ, а также ИИ помогает в составлении бюджета и переговорах с поставщиками, предельные затраты на интеллектуальную работу сокращаются. Хотя труд людей, энергия и материалы всё ещё будут стоить денег, соотношение между технологиями и человеческими усилиями изменится. Я считаю, что затраты проявятся в других формах, таких как:
- Вычислительные единицы (мощность обработки ИИ)
- Данные как валюта (качество, редкость/эксклюзивность данных)
- Качество данных (насколько чисты, непредвзяты и проверяемы данные)
4. Объём становится текучим
Будущее будет склоняться к адаптивному объёму. Проекты будут начинаться с направления, а не с фиксированного объёма. Благодаря ИИ, обратной связи в реальном времени и быстрому прототипированию, команды будут совместно создавать объём по ходу дела. Это соответствует Agile, но на новом уровне, где «непрерывная эволюция» становится стандартом, а не просто мышлением.
Кроме того, с расширением ИИ и индустрии данных, обусловленным прогрессом в квантовых вычислениях, растёт спрос на всё более мощные вычислительные системы. Это потребует значительных модернизаций дата-центров, которые должны будут поддерживать эти высокопроизводительные системы. Следовательно, углерод может перестать быть единственным показателем устойчивости. Появятся новые метрики устойчивости, сосредоточенные не только на энергоэффективности, но и на управлении такими факторами, как рассеивание тепла, электромагнитные помехи и более широкое экологическое воздействие инфраструктуры вычислений следующего поколения.
В последнее время много говорят о выгорании. Почему, по вашему мнению, инженеры и архитекторы испытывают выгорание и неудовлетворённость на работе? Что могут сделать компании, чтобы это исправить?
Упростить. Компаниям нужно упростить четыре вещи и продолжать их упрощать; это непрерывный цикл улучшений, от 1 к 4 и обратно к 1:
И наконец, есть ли что-то, что вы хотели бы сказать архитекторам, которые пренебрегают управлением, коммуникацией, ежедневными стендапами и в итоге пропускают дедлайны?
Если вам сложно справляться со всем остальным, сосредоточьтесь на одном ключевом аспекте: планировании. Никогда не недооценивайте силу хорошо продуманного плана. Тщательно устанавливайте внутренние и внешние дедлайны, оставляя время на проверку работы перед отправкой клиенту. Учитывайте 10-20% дополнительного времени на непредвиденные проблемы. Разбейте проект на управляемые части, разделите их на задачи и распределите среди команды. Планируйте на месяцы вперёд, детализируя каждую задачу, и регулярно проверяйте прогресс команды на еженедельных собраниях: «Что ты сделал вчера? Что делаешь сегодня? Нужно ли тебе что-то от кого-то?»
Если вы замечаете, что пренебрегаете управлением, остановитесь и подумайте, почему. Это нехватка времени? Тогда спланируйте свою неделю и обсудите с руководителем выделение времени на правильное планирование. Это отсутствие интереса? Возьмите инициативу в свои руки и узнайте, как управление может напрямую принести вам пользу и улучшить вашу рабочую жизнь. Или это недостаток знаний? Попросите у компании средства или время на ваше развитие. Например, я настоятельно рекомендую сертификацию PMP — она расширит ваши навыки и лучше подготовит вас к предстоящим вызовам. Разберитесь с причиной вашего пренебрежения, потому что игнорирование управления никогда не приводит к положительным результатам.
И наконец, самое важное — находите радость в своей работе, независимо от ситуации. Будь вы перегружены, если недостаточно получаете денег или сталкиваетесь с проблемами в проекте, команде или компании, найдите момент, чтобы остановиться и вспомнить цель вашей работы. Помните, работа — это не только трудности; она должна быть вознаграждающей и приносящей удовлетворение. Вы должны гордиться тем, что делаете, результатами, которые создаёте, и наследием, которое строите. С правильными инструментами управления вы можете снизить стресс, повысить эффективность и сделать процесс более плавным для себя и своей команды.
- Планирование — например, создать инновационный фонд для участия в конкурсах с убытком, не затрагивая время сотрудников через сверхурочные.
- Коммуникация — например, быть более прозрачными в общении. Проводить общие собрания вместо отправки писем, сообщать о целях компании и давать сотрудникам возможность высказываться и предлагать идеи. Принимать негативную обратную связь и действовать на ее основе. Сделать карьерный путь ясным, простым и не субъективным.
- Время — например, постоянные сверхурочные — признак плохого управления. Дать команде достаточно времени на отдых и занятия другими делами позволяет творчеству расцветать.
- Награда — например, архитектурным компаниям нужны более конкурентоспособные зарплаты. Лучшие умы будут стремиться к ним. Но для этого компании нужно лучшее планирование.
И наконец, есть ли что-то, что вы хотели бы сказать архитекторам, которые пренебрегают управлением, коммуникацией, ежедневными стендапами и в итоге пропускают дедлайны?
Если вам сложно справляться со всем остальным, сосредоточьтесь на одном ключевом аспекте: планировании. Никогда не недооценивайте силу хорошо продуманного плана. Тщательно устанавливайте внутренние и внешние дедлайны, оставляя время на проверку работы перед отправкой клиенту. Учитывайте 10-20% дополнительного времени на непредвиденные проблемы. Разбейте проект на управляемые части, разделите их на задачи и распределите среди команды. Планируйте на месяцы вперёд, детализируя каждую задачу, и регулярно проверяйте прогресс команды на еженедельных собраниях: «Что ты сделал вчера? Что делаешь сегодня? Нужно ли тебе что-то от кого-то?»
Если вы замечаете, что пренебрегаете управлением, остановитесь и подумайте, почему. Это нехватка времени? Тогда спланируйте свою неделю и обсудите с руководителем выделение времени на правильное планирование. Это отсутствие интереса? Возьмите инициативу в свои руки и узнайте, как управление может напрямую принести вам пользу и улучшить вашу рабочую жизнь. Или это недостаток знаний? Попросите у компании средства или время на ваше развитие. Например, я настоятельно рекомендую сертификацию PMP — она расширит ваши навыки и лучше подготовит вас к предстоящим вызовам. Разберитесь с причиной вашего пренебрежения, потому что игнорирование управления никогда не приводит к положительным результатам.
И наконец, самое важное — находите радость в своей работе, независимо от ситуации. Будь вы перегружены, если недостаточно получаете денег или сталкиваетесь с проблемами в проекте, команде или компании, найдите момент, чтобы остановиться и вспомнить цель вашей работы. Помните, работа — это не только трудности; она должна быть вознаграждающей и приносящей удовлетворение. Вы должны гордиться тем, что делаете, результатами, которые создаёте, и наследием, которое строите. С правильными инструментами управления вы можете снизить стресс, повысить эффективность и сделать процесс более плавным для себя и своей команды.
- Agile — методология управления проектами. Она возникла в сфере IT и сначала использовалась для разработки ПО. Сейчас Agile используют и в других отраслях. Agile строится на принципе итеративных поставок продукта и его улучшений с каждой итерацией (классический вариант, поставка продукта раз в 2 недели)
- Waterfall — это каскадная модель для разработки продуктов, которая позволяет решать задачи по принципу последовательного плана без возврата на предыдущие этапы.
- Концепция “Завершенности” / Definition Of Done (DoD) - Набор критериев, которые определяют “Готовность” Задачи/Проекта. По достижению критериев DoD элемент работы является безоговорочно завершенным для всех заинтересованных сторон.