в чем состоит цель enterprise фреймворков safe less
SAFe для проектных менеджеров #1
Мы запускаем серию ознакомительных статей про SAFe для менеджеров проектов. В них мы расскажем о преимуществах, структуре и ролях Scaled Agile Framework, а также о том, где проектные менеджеры могут найти себе применение в данном подходе. Первая часть посвящена обзору подхода с точки зрения классического проектного управления.
Часть 1: Место проектов в SAFe
SAFe – один из наиболее популярных в мире подходов для организации работы гибкой компании. Его преимущество перед другими методами состоит в следующем:
В минимальном виде SAFe выглядит как уровни Team + Program. Уровни Portfolio и Large Solution опциональны в зависимости от потребностей организации. В этой статье мы не будем рассматривать уровень Large Solution и сконцентрируемся на трёх основных.
Командный уровень
На уровне команд SAFe придерживается базовых принципов гибкой разработки, описанных в Agile-манифесте и поддерживает итеративно-инкрементальную разработку по фреймворку Scrum или методу Kanban. Команды итеративно разрабатывают элементы продукта двухнедельными итерациями (спринтами) и проводят демонстрации результатов своей работы и ретроспективу.
Единица управления на данном уровне – команда, реализующая пользовательские истории из бэклога. Роли на данном уровне такие же, как и в классическом Scrum: Владелец продукта, Scrum-мастер, член команды разработки.
Программный уровень
Уровень программы является ключевым как со стороны бизнеса, так и с точки зрения координации. На этом уровне все ресурсы, команды, заинтересованные лица кооперируются вокруг одной важной цели, чаще всего представляющую собой поток создания ценности (Value Stream) или продукт. Синхронизируют свою работу команды при помощи совместных сессий планирования (Program Increment Planning) в начале каждого квартала и демонстрации интегрированного инкремента продукта (System Demos) каждые 2 недели и ретроспективы (Inspect & Adapt) в конце каждого квартала.
Соответственно, все роли и процессы ориентированы на поставку ценных элементов функциональности. Метафорой этого процесса является “Поезд” (Agile Release Train).
ART – это долгоживущая группа команд, заинтересованных лиц и других участников, объединённых общей целью, создающая в едином ритме общее решение или его часть. Длина итераций и частота общего планирования внутри поезда фиксирована.
Управляет «Поездом», соответственно, «Машинист» (Release Train Engineer). Он коучит весь «экипаж» поезда для повышения эффективности работы, взаимодействует с заинтересованными сторонами, фасилитирует общие собрания поезда поставки. Он не начальник, он лидер этого поезда. Release Train Engineer больше всего похож на Scrum-мастера, но отвечающего не за одну, а за много команд и их взаимодействие между собой. В терминах PMI «Машинист» соответствует Менеджеру программы по уровню ответственности и исполняемым функциям (The PM role in a lean and agile world).
У поезда также есть главные «пассажиры» – Представители бизнеса (Business Owners). Это основные заинтересованные лица, которые отвечают за финансовые показатели Поезда. Business Owners – это руководители, которые будут получать выгоду от создаваемого решения, пользоваться им или продавать его.
Управляет продуктом и владеет бэклогом поезда команда Продуктового менеджмента (Product Management). В неё входят Владельцы продуктов отдельных команд, а также Продуктовые менеджеры. Они выявляют потребности клиентов, формируют дорожную карту и приоритезируют элементы функциональности. Говоря простыми словами, Представители бизнеса ставят цели, а команда Продуктового менеджмента стараются их достичь силами команд.
Также на программном уровне есть роль Системного архитектора (System Architect). Архитектор определяет архитектуру будущего решения, направляет работу команды с технической стороны системы, взаимодействия подсистем и нефункциональных требований к системе.
Уровень Портфеля
Цель портфельного уровня – согласование стратегии компании с реализацией портфеля за счёт организации процессов вокруг потоков создания ценности. Этот уровень появляется, если у организации несколько потоков создания ценности.
Портфель в SAFe состоит из Потоков создания ценности. Это могут быть продукты или направления деятельности организации. На этом уровне определяется стратегия инвестирования, бюджеты и показатели эффективности. Также на этом уровне реализуется функция принятия решения самого высокого уровня – портфельное управление (Lean Portfolio Management). И хотя глядя на схему может показаться, что Менеджер портфеля это некая отдельная роль, но это не так. На самом деле это группа функций, исполняемая людьми, которые могут также исполнять другие высокоуровневые роли в организации.
Корпоративный архитектор (Enterprise Architect) принимает решения относительно архитектуры всех систем в компании и их взаимодействия, для их гармоничного взаимодействия внутри организации.
«Проекты» в SAFe
Как можно заметить из схемы, роли проектного менеджера в SAFe нет, как и отдельного уровня проектов. Все бизнес инициативы связанные с созданием ценности реализуются в рамках «Поездов», уже существующих или созданных под инициативу.
Как же тогда в организациях, практикующих SAFe, реализуются инициативы по автоматизации, внедрению новых систем, затрагивающих всю организацию и многие «Поезда»? Для таких случаев в SAFe существует понятие Эпика (Epic). И он больше всего похож на классический проект.
Если возникает такая необходимость, Владелец эпика (Epic Owner) определяет описание Эпика и его Минимальный Жизнеспособный Продукт (Minimum Viable Product). Затем он взаимодействует напрямую с заинтересованными сторонами и «Машинистами» соответствующих «Поездов» для реализации Эпика.
Главное отличие от классического проекта в том, что разработка Эпика ведётся итеративно-инкрементально, а фокус функций Владельца Эпика смещается с управления командой на координацию взаимодействия с командами разных «Поездов». Реализация Эпика, как и у классического проекта, ограничена во времени. В отличие от потока создания ценности, развитие которого, как правило не останавливается.
Особенность эпика, вероятно повлиявшая на название (от англ. — «эпически, грандиозный»), в его масштабе. Это по-настоящему колоссальная инициатива, «прошивающая» большую часть организации. А потому Владельцем эпика чаще всего выступает кто-то близкий к C-уровню менеджмента в организации. Простому менеджеру проекта Эпик доверят вряд ли.
Что делать менеджерам проектов дальше?
Цифровизация, ускорение запуска инноваций, продолжающийся рост роли Интернета привели к тому, что уровень неопределённости бизнеса в целом и проектов в частности вырос. И предпосылок для замедления этого роста не наблюдается. Технологии, потребности, конкурентное окружение и прочие факторы меняются не только постоянно, но и с высокой скоростью. Со временем всё меньше организаций будут предпочитать классическое проектное управление гибким подходам в качестве инструмента развития своего бизнеса. А в большинстве Agile-методологий нет роли менеджера проекта. Увы, но это так.
Если организация хочет сохранить ценных, опытных и компетентных менеджеров проектов и использовать их потенциал в своём бизнесе, ей придётся приспособить их для исполнения новых функций. А менеджерам проектов, чтобы остаться в игре, придётся освоить новые роли и навыки. Какие, мы расскажем во второй части нашей статьи.
Как мы “примеряли” SAFe
Привет, меня зовут Василий Юзов, и я Chief Product Owner в небольшой, но очень гордой IT-компании. У нас 12 продуктовых команд, которые разрабатывают различные решения для автоматизации и цифровой трансформации бизнеса и государства.
Вообще, мы обычная команда полного цикла разработки. Работали в командах, использовали Agile, Scrum, где-то взлетало, где-то не очень… В какой-то момент все начало разваливаться. Вроде все делаем как всегда: много работаем, делаем дофига и чуть больше, команда растет… Но техдолг тоже растет, и недовольство клиентов растет. И все чаще ребята стали приходить в состоянии “я так больше не могу, пристрелите меня”.
Мы честно пытались что-то “починить”, взять новых крутых senior’ов, мотивировать и стращать ребят деньгами и всякими материальными и не очень плюшками и фишками. Но в какой-то момент поняли, что менять нужно все и кардинально. Надо все сломать и просто заново выстроить процесс разработки. И решили попробовать фреймворк SAFe®.
Если вы знаете, что такое SAFe®, то просто проскрольте эту часть. Если же нет, то перед тем, как продолжить рассказ, сделаю небольшой экскурс в предмет.
Что такое SAFe® и как оно работает
Подробно про фреймворк можно почитать на официальном сайте.
Чтобы что?
А вторая: возможно, это покажется кому-то смешным, но ключевой внутренний заказчик (так сказать, “Бизнес”, который отвечает за доходы) не совсем понимал, что происходит в производстве. Были случаи, когда “продавали” одно, а когда Клиент уже согласился и подписал контракт, выяснялось, что это невозможно. Поэтому потребовалось сделать цикл и процесс разработки понятным и прозрачным для всех.
Третья причина. Заглядывая немного вперед, хочется прийти к кросс-функциональным командам, которые будут гибко переключаться между разными направлениями, в зависимости от приоритетов.
Очевидно, что мы не первые, кто столкнулся с такими сложностями, мы решили не изобретать велосипед, а посмотреть мировую практику. В результате все свелось к выбору между LeSS (Large Scaled Scrum) и SAFe®. Выбрали мы SAFe®, потому что он более:
распространен, а значит, у него большое комьюнити, можно задавать вопросы единомышленникам, перенимать чужой опыт.
Запрягаем коней
Все, мы решились. Давайте внедрять. Открываем “инструкцию”, читаем пункт первый:
“Возьмите ваши Agile-команды…”
Так, стоп, а у нас есть Agile-команды. До этого момента каждая команда “жила” так, как ей нравилось. Да, большая часть использовала так или иначе фреймворк Scrum, но явно требовалась определенная синхронизация и выравнивание даже на уровне понятийного аппарата, чтобы все разговаривали на одном языке.
Поэтому перед тем, как внедрять, мы слегка подготовились. Для начала прошли обучение на Scrum Master в SAFe® (6 человек), SAFe® Product Owner & Product Manager (3 человека) и SAFe® Scaled Agile Engineer. После мы организовали и провели ряд обучающих мероприятий внутри компании, чтобы подготовить плацдарм для изменений.
Примерка
SAFe® мы тоже «примеряли». Правда здесь двумя неделями было не обойтись. По классике стандартный цикл во фреймворке длится 3 месяца, мы решили попробовать спланировать PI на месяц: 2 производственных спринта + IP-итерация на неделю. Конечно, так никто не делает. Просто потому, что само по себе “PI-планирование”, как мероприятие, довольно-таки сложное и дорогое удовольствие. Нужно “вырвать” на 2 дня из производстводственного процесса и собрать в одном месте все команды и заинтересованных представителей “бизнеса” внутри компании. Но мы решили, что это невысокая цена для проверки нашей гипотезы.
Наше первое PI-планирование
Состав
В начале августа 2021 года мы вывезли 80 человек за город, чтобы понять, во что мы ввязываемся. Мы решили, что нам нужны:
представители бизнес-подразделений, которые непосредственно общаются с заказчиками,
продуктовые команды со своими PO и Scrum-мастерами,
UI/UX дизайнер для экспертной оценки возможных интерфейсов, т.к. это может повлиять на бэкенд,
представители сопровождения, которые отвечают за внедрение, тиражирование и поддержку пользователей,
Такой состав нужен, чтобы, с одной стороны, иметь всю необходимую для принятия технических решений экспертизу под рукой, а с другой — ребята, которые будут деплоить и сопровождать разрабатываемые решения, могут сформулировать дополнительные нефункциональные требования, которые нельзя не учитывать.
Регламент и повестка
План
Планирование мы начали с короткого бизнес-контекста, после чего все вместе повторили теорию, и понеслось.
Для соблюдения тайминга каждые 20 минут мы собирали всех Scrum-мастеров и проходили по общему чек-листу. Это был своего рода синхрон, чтобы не допускать отставания команд.
Все хорошо, но надо переделать
Не то, чтобы мы думали, что все пройдет легко и гладко. Скорее наоборот, мы знали и очень ждали каких-то интересных ситуаций. И вот во время ревью целей в одной из команд мы поняли, почему авторы методологии настаивают на проведении PI-планирования в 2 дня. Ребята из “бизнеса” увидели, что критичная для клиента фича не попадает в «поезд» и быстро переиграли приоритеты. Команде пришлось перестроить свой план работ на планируемый период. И все бы ничего, если бы не те самые пресловутые зависимости между командами. Смена приоритетов в работе одной команды нарушила зависимость от другой команды, которой тоже пришлось оперативно перестраивать свои спринты. Нам “повезло”, что мы планировали всего лишь 2 спринта (а не 6), поэтому удалось быстро все переиграть и исправить.
По классике, ревью черновика плана проводится в конце первого дня. Продуктовые команды расходятся по домам, а продуктовый менеджмент и представители бизнеса могут остаться для пересмотра приоритетов, чтобы оставить в «поезде» действительно необходимые фичи. Это носит неформальное название «Ночь торгов». На следующий день команды получают уточненные приоритеты, и у них есть еще один день, чтобы скорректировать свои планы и зависимости друг от друга.
Первый Program Board
В результате PI-планирования мы получили Program Board со всеми запланированными историями и выявленными зависимостями. Существует мнение, что на доску есть смысл выносить только зависимости, но команда решила зафиксировать на доске все истории, которые попали в «поезд». Таким образом мы визуализировали свой план на август:
Наш первый Program Board
Естественно, позже все переехало в Miro:
Program Board в первом PI
Небольшие пояснения по доске. Зеленые стикеры в конце спринта — это цели команды. Грустный смайлик означает, что цель не достигнута. Кстати, многие команды включают в цель спринта несколько пунктов, и мы договорились, что цель считается достигнутой, только если сделаны абсолютно все пункты. Это помогает нам учиться ставить понятные и адекватные цели.
Красные линии и карточки показывают зависимости между задачами. Видно, что красная линия идет от красных стикеров к синим. Это означает, что от команды, в чьем бэклоге есть красный стикер, зависит команда с соответствующим синим стикером.
Выводы и итоги
Важно иметь проработанный до уровня User Story бэклог. При этом у команд не должно быть не решенных до PI-планирования вопросов по самим историям и критериям их приемки.
PI-планирование должно проходить 2 дня.
В каждой команде обязательно должен быть подготовленный Scrum-мастер. При таком количестве обсуждений и споров без грамотной фасилитации не обойтись.
Program Board лучше сразу делать в Miro и выводить ее через проектор на экран.
LeSS — Scrum на больших масштабах
LeSS — это Scrum, применяемый к множеству команд, работающих совместно над одним продуктом.
Тема работоспособности и, вообще, возможности применения Agile в больших масштабах не дает покоя отрасли разработки программного обеспечения последний десяток лет. Появилось большое количество подходов таких как Scaled Agile Framework, Disciplined Agile Delivery, Nexus, примитивный Scrum-of-Scrums и т.п. Все они либо сложны, поэтому применение их очень затруднительно и часто не дает ожидаемых результатов, либо настолько просты, что решают лишь частные проблемы в ограниченном количестве кейсов.
Хочется найти какую-то золотую середину, что-то «элегантное», такое же «элегантное», простое и провоцирующее к развитию продукта, процессов и команд, как Scrum.
И вот оно свершилось. Встречайте Large-Scale Scrum, сокращённо LeSS, или по-русски Скрам на больших масштабах. LeSS — это Скрам, применяемый к множеству команд, работающих совместно над одним продуктом.
С этого момента мы начинаем серию статей о подходе Large-Scale Scrum и о том, как он применяется в реальных компаниях. Начнем мы с простого — рассмотрим, из чего состоит LeSS в целом и его особенности.
Коротко о LeSS
LeSS — это Скрам. Скрам на больших масштабах (LeSS, Large-Scale Scrum) — это не новый или улучшенный Скрам. И это не разделение на «Скрам на уровне каждой команды» и «что-то другое на уровне выше». Скорее это о том, как применить принципы, назначение, элементы и элегантность Скрама в контексте большого масштаба настолько просто, насколько это возможно. Так же, как Scrum или любой другой настоящий Agile-фреймворк, LeSS является «минимально достаточным подходом» для максимальной отдачи.
Скрам на больших масштабах — это не специальный фреймворк расширения, работающий только на уровне команд. По-настоящему масштабированный Скрам — это тот же Скрам, но работающий на большем масштабе.
В LeSS основная часть команд — это кросс-функциональные, обладающие всеми необходимыми компетенциями продуктовые команды (feature-team), состоящие из 3-9 нацеленных на обучение участников, выполняющих всю работу (от пользовательских интерфейсов и разработки до снятия продуктовых метрик) для создания полноценного рабочего продукта.
Эти команды работают вместе над одним Бэклогом Продукта, потому что у них есть общая цель: по итогам общего Спринта разработать единый, цельный, готовый к поставке продукт, и каждая команда вовлечена в это, потому что она является не компонентной, а продуктовой командой (feature-team), и отвечает за end-to-end продукт, а не только за его отдельную часть.
Что представляет собой продукт в LeSS? Это полноценное (end-to-end), клиенториентированное решение, которое будет использоваться реальными людьми. Понятие продукта в LeSS гораздо шире, чем просто компонент, платформа, слой или библиотека.
LeSS — это не просто процессный фреймворк. LeSS включает в себя:
Скрам на больших масштабах состоит из двух фреймворков:
Обычный LeSS-фреймворк предполагает наличие одного (и только одного) Владельца Продукта, который владеет продуктом, оптимизируя продукт в целом, и управляет одним Бэклогом Продукта, над которым работают команды в рамках общего для всех Спринта. Элементы LeSS-фреймворка практически идентичны элементам Скрам для одной команды, только применяются уже не к одной команде, а к «команде команд».
LeSS Huge
В какой-то момент, когда один Владелец Продукта более не может держать в голове полный контекст, у него не получается соблюдать баланс между внутренними и внешними коммуникациями, а Бэклог Продукта разрастается настолько, что один человек более не способен с ним справляться. Это сигнал для перехода от обычного LeSS к LeSS Huge.
В LeSS Huge по-прежнему есть один владелец Продукта, но у него есть команда помощников (Area Product Owners). В LeSS Huge работа над продуктом разделяется по Областям Требований (Requirement Areas). Область требований — это не компонент продукта, а определённая группа end-to-end функционала продукта с точки зрения клиента, то есть каждый элемент Бэклога Области Требований (Area Backlog) несет конечную ценность для клиента. Работа над Requirement Area осуществляется Area Product Owner и от 3-х до 8-ми команд.
Вот в целом как выглядит LeSS, но, конечно же, под капотом много нюансов: как плавно запустить LeSS, какие изменения необходимы в организации, как происходит распределение команд, как плавно перейти к feature-team, как определить, что является продуктом в вашей компании? Об этом всем читайте в наших следующих статьях.
Приходите на наш тренинг
SAFe или Scaled Agile Framework
Что такое SAFe?
Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.
Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?
Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.
Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.
SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. Т.е. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек
Выгода?
В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead
Во-вторую очередь отделы управления программами. Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. То же самое относится к разного рода архитекторам. В SCRUM для них нет функции в SAFe — есть карьерный путь.
Далее — это может быть выгодно тем владельцам бизнеса, где управляющие работают над большими, пожирающими огромное количество человеко-часов проектами и не могут (иногда по объективным причинам) сделать эти проекты независимыми.
Множеству разработчиков с квалификацией ниже среднего, т.к. часто для того, чтобы что-то сделать их нужно экспоненциально больше чем тех самых опытных и замотивированных профессионалов.
В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.
SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).
На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.
Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)
Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.
Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.
Плюсы
Недостатки
Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.