Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Мы живём в реальном мире и, к сожалению или к радости, используют эти самые часы. Сложно продать заказчику контракт на Х стори пойтов, если ты аутсорс и работаешь по T&M контракту. Сложно доказать эйчару, что тебе в команду нужен дополнительный разработчик, потому что тебе нужно увеличить производительность на Х стори пойнтов.
Безусловно, стори пойнты рабочий инструмент. Про то, что 1 SP должен быть равен 1 часу вообще речи не идёт. И любая оценка, хоть в стори пойнтах, хоть в часах, хоть в попугаях, должна оценивать риски, сложность и т.д.
Мой вопрос вытекает из того, что по мере того, как разработка перестаёт быть "вещью в себе" и должна быть вписана в другие процессы компании, кому-то и как-то придётся делать эту "бухгалтерию".
Спасибо за развёрнутую, но не перегруженную статью. Пара вопросов от меня:
1) Правильно ли я понял, что в Тикетленде сейчас несколько команд и один коуч? Который поочерёдно работает с отдельными командами? Или же коуч делит своё время между всеми командами?
2) В начале статьи говорилось, что старая организация команд была ориентирована на приложения, а сейчас команды кросс-функциональные - а в чём разница?
3) Переводятся ли в итоге строи поинты в человекочасы? Со временем производительность команды выравнивается и по итогу X дней спринта равны Y сторипойнтам. Перейти в мир "реальных" величин кажется логичным шагом. Или же вы продолжаете использовать строи пойнты?
Надо определиться, за что отвечает тимлид? Максимизация продуктивности команды? Ресурсные вопросы комплектации команды входят в его зону ответственности? И так далее. Это поможет сфокусироваться тимлиду на тех областях, где "кто, если не он?". Вопросы по другим областям нужно подсветить ответственным и дальше решать сообща.
Кто вообще сказал, что разработчик отвечает только за свой код? Это прописано в каких-то корпоративных политиках, гайдах для разработчиков и т.д.? Это дезинтеграция. Если разработчик приходит в КОМАНДУ с мыслью "моя хата с краю", то он не приходит в КОМАНДУ. Плёвые вопросы вроде "немного неточных" тикетов разработчик мог бы прояснить сам, всё остальное он отгружает человеку, которые отвечает за "понятные тикеты". Да, возможно будут одна-две волны митинг, уточнение критериев ясности - но потом всё должно стать красиво. Если не становится - это беда и не проблема митингов, а проблема менеджмента.
Использовать ретро для разборок "кто виноват" - это ещё более дезинтегрирующая идея. Никто не любит быть виноватым и как правило люди не стремятся стать виноватыми. А для исправления непреднамеренных ошибок публичные бичевания не очень подходят. Попробуйте внедрить культуру "blameless" ретро. Оперируйте такими понятиями как "улучшения", а не "исправление ошибок". Жизнь - это то, как мы к ней относимся. Если тимлид программирует команду на разборки на ретро, ждите срачей.
Если говорить про сами созвоны, то не стоит выносить их в какую-то супер-отдельную категорию. Вот есть созвоны. А групповые чаты? А разговоры у стола коллеги? А письма? Всё это инструменты и все они должны служить благим целям. Вопрос не в самих созвонах, а в их эффективности. Приносят ли они пользу? Эта польза получается максимальной именно в такой форме? Иногда тебе не нужен созвон, вопрос можно решить в чате. А иногда переписка заходит в тупик и проще созвониться и проговорить всё голосом. Начните с манагеров, обучите их пользоваться каждым инструментом коммуникации, выбирать подходящий в зависимости от ситуации.
Наверное, вкратце ситуацию можно было бы описать таким образом. Есть симптомы, а есть заболевания. Есть баг, а есть корневая причина. Бесполезные митинги - это симптом. Будет тимлид лечить симтом или само заболевание - вот, в чём вопрос.
Я бы сказал, что проблема несколько глубже: а каким образом удовлетворённость или состояние потока относятся к инженерным метрикам? В статье немного смешались метрики, подходы и сферические кони в вакууме. Читатель может потеряться.
Строго говоря, состояние потока - это вообще не метрика. Это "перспектива", с которой нужно смотреть на компанию и её процессы. Одна из осей координат, если угодно. Потому что DevEx сам по себе не методология (когда тебе дают чёткие инструменты), а фреймворк (когда акцент делается на практиках и образе мысли). В статье, кстати, DevEx как раз фреймворком и именуется.
Как это работает? Сначала вы выравниваетесь по тому, что для вашей компании или команды является состоянием потока и каким вы его хотите видеть. Потом выделяете факторы, которые влияют на него в лучшую и в худшую сторону. Затем уже эти факторы некоторым образор оцениваете. И это не обязательно числовые значения, это может быть и "хорошо"-"нормально"-"плохо" и т.п.
Далее, оценив своё текущее положение, вы стараетесь внедрить улучшения в тех областях, которые тянут состояние потока вниз.
Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы
Вот тут ещё попрошу пруфы. В каком из изданий Scrum Guide упоминается Velocity как часть фреймворка? В скрам входит только то, что написано в гайде. Всё остальное, даже то, что создатели могу рассказывать на публичных выступлениях или писать в блогах, не является частями скрама.
Потом окажется, что презентацию по обратной связи делал условный Вася, который получит за этот скилл низкую оценку. И как после этого оценивать влияние его презентации на общий уровень в команде?
Как будто можно было сначала провести оценку, а потом поделить темы в зависимости от уровня навыка и критичности скилла.
Проблема этого подхода заключается в том, что собственно менторинга и оценки качества знаний (компетенции) нет. Один коллега что-то самостоятельно изучил, рассказал другим и... И получил галочку, заполнил ещё одну ячейку матрицы?
Трёх скоростей для путешествия априори мало, я про это говорил. Диапазон узкий, разница между передачами скорее всего значительная. С такой трансмиссией силы будут уходить быстрее.
Мягкое седло - синоним онемевшей промежности. На мягком седле приятно проехать 10км в городе по асфальту. Но даже вот так 100+ км проехать - сначала будет жопка побаливать. А потом по докторам ходить придётся.
Натирание происходит либо от неудобного седла, либо от неправильно подобраной одежды. Широкое седло "диван" и труханы+джинсы - залог натирания, например.
Я рад, что герои статьи успешно финишировали. При этом, скажем так, я бы не рекомендовал повторять их эксперимент один в один. Всё же лучше уделить больше времени изучению теоретической базы. Тогда глядишь и поездка дастся легче.
Очередная статья "делайте хорошо, а плохо не делайте")
Я нанимаю профессионалов (хард скиллы)... Я смотрю на софт скиллы...
Поздравляю, вы проводите обычное собеседование и набираете людей как любой рекрутер с годом работы.
Ещё внимание привлёк пассаж про недоверие к скрам мастеру. А к автору статьи у кандидатов или коллег из других команд врождённое доверие? Доверие можно заслужить и любой опытный специалист, особенно отвечающий на налаживание коммуникации, должен уметь это делать. Да, можно говорить, что со старта к скрам мастеру относятся с недоверием - это будет правдой для большинства случаев. Но дайте человеку хотя бы 2-3 недели, а потом считайте цыплят.
Красивый замок из песка, который нужно успеть показать всем, пока он не рассыпался)
Вопрос, который уже накинули здесь и он остался без ответа, это замена выделенного слота на "ещё одно уведомление, на которое нужно ответить". Раньше у трёх амиго был один одинаковый слот. Сейчас амиго всё равно должны находить время, но теперь уже "кто когда сможет".
Далее, а есть ли смысл в "непрерывной" оценке багов через бота? Что с ними дальше происходит? Разработка может сразу брать их в работу? Или всё же есть некий буфер, он же бэклог, который наполняется и оттуда забираются задачи в замисимости от срочности? Если второе, то в чём выигрыш?
Ещё я не заметил упоминания классического фоксу оценивания: если есть хотя бы две сильно отличающиеся оценки, эта задача/баг оценивается отдельно. Потому что это признак некого понятийного разрыва в команде. А тут просто считается среднее.
И это подводит нас к последней мысли. Шакала от 1 до 100? Серьёзно? Кто-то понимает "в граммах" разницу между 60 и 61? Какие у вас в принципе значения приоритетов в тасктрекере?
Во-первых, пюсую опасениям, что размещение "кипятильников" в мировом океане не способствует здоровью планеты. Да, человеки уже заметно повлияли на экосистемы суши. Значит ли это, что теперь пришло время "выжигать" океан? Уверен, что нет.
Во-вторых, при всей технической эффективности подводных ЦОДов, мне не даёт покоя вот какая мысль: неужто подводные ЦОДы не бэкапятся на сушу? Если руководствоваться правилось территориального разнесения резервных копий, то бэкапы должны храниться на удалённой площадке. Либо такой же подводной, либо наземной. Решитесь ли вы иметь и основную и резервную площадку под водой? Если нет, то поздравляю, вам всё равно нужен традиционный ЦОД. Да, в меньших объёмах, но всё же.
Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Тезисами и по делу:
Скрам не методология.
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Обнял.
По третьему пункту.
Мы живём в реальном мире и, к сожалению или к радости, используют эти самые часы. Сложно продать заказчику контракт на Х стори пойтов, если ты аутсорс и работаешь по T&M контракту. Сложно доказать эйчару, что тебе в команду нужен дополнительный разработчик, потому что тебе нужно увеличить производительность на Х стори пойнтов.
Безусловно, стори пойнты рабочий инструмент. Про то, что 1 SP должен быть равен 1 часу вообще речи не идёт. И любая оценка, хоть в стори пойнтах, хоть в часах, хоть в попугаях, должна оценивать риски, сложность и т.д.
Мой вопрос вытекает из того, что по мере того, как разработка перестаёт быть "вещью в себе" и должна быть вписана в другие процессы компании, кому-то и как-то придётся делать эту "бухгалтерию".
Спасибо за развёрнутую, но не перегруженную статью. Пара вопросов от меня:
1) Правильно ли я понял, что в Тикетленде сейчас несколько команд и один коуч? Который поочерёдно работает с отдельными командами? Или же коуч делит своё время между всеми командами?
2) В начале статьи говорилось, что старая организация команд была ориентирована на приложения, а сейчас команды кросс-функциональные - а в чём разница?
3) Переводятся ли в итоге строи поинты в человекочасы? Со временем производительность команды выравнивается и по итогу X дней спринта равны Y сторипойнтам. Перейти в мир "реальных" величин кажется логичным шагом. Или же вы продолжаете использовать строи пойнты?
Давайте по порядку.
Надо определиться, за что отвечает тимлид? Максимизация продуктивности команды? Ресурсные вопросы комплектации команды входят в его зону ответственности? И так далее. Это поможет сфокусироваться тимлиду на тех областях, где "кто, если не он?". Вопросы по другим областям нужно подсветить ответственным и дальше решать сообща.
Кто вообще сказал, что разработчик отвечает только за свой код? Это прописано в каких-то корпоративных политиках, гайдах для разработчиков и т.д.? Это дезинтеграция. Если разработчик приходит в КОМАНДУ с мыслью "моя хата с краю", то он не приходит в КОМАНДУ. Плёвые вопросы вроде "немного неточных" тикетов разработчик мог бы прояснить сам, всё остальное он отгружает человеку, которые отвечает за "понятные тикеты". Да, возможно будут одна-две волны митинг, уточнение критериев ясности - но потом всё должно стать красиво. Если не становится - это беда и не проблема митингов, а проблема менеджмента.
Использовать ретро для разборок "кто виноват" - это ещё более дезинтегрирующая идея. Никто не любит быть виноватым и как правило люди не стремятся стать виноватыми. А для исправления непреднамеренных ошибок публичные бичевания не очень подходят. Попробуйте внедрить культуру "blameless" ретро. Оперируйте такими понятиями как "улучшения", а не "исправление ошибок". Жизнь - это то, как мы к ней относимся. Если тимлид программирует команду на разборки на ретро, ждите срачей.
Если говорить про сами созвоны, то не стоит выносить их в какую-то супер-отдельную категорию. Вот есть созвоны. А групповые чаты? А разговоры у стола коллеги? А письма? Всё это инструменты и все они должны служить благим целям. Вопрос не в самих созвонах, а в их эффективности. Приносят ли они пользу? Эта польза получается максимальной именно в такой форме? Иногда тебе не нужен созвон, вопрос можно решить в чате. А иногда переписка заходит в тупик и проще созвониться и проговорить всё голосом. Начните с манагеров, обучите их пользоваться каждым инструментом коммуникации, выбирать подходящий в зависимости от ситуации.
Наверное, вкратце ситуацию можно было бы описать таким образом. Есть симптомы, а есть заболевания. Есть баг, а есть корневая причина. Бесполезные митинги - это симптом. Будет тимлид лечить симтом или само заболевание - вот, в чём вопрос.
Тезис о прогрессивной экономике поверх фотографии Минска - это та ещё ирония)
Ещё раз. Скрам эту метрику не включал. Велосити - не часть скрама. Тчк.
Я бы сказал, что проблема несколько глубже: а каким образом удовлетворённость или состояние потока относятся к инженерным метрикам? В статье немного смешались метрики, подходы и сферические кони в вакууме. Читатель может потеряться.
Строго говоря, состояние потока - это вообще не метрика. Это "перспектива", с которой нужно смотреть на компанию и её процессы. Одна из осей координат, если угодно. Потому что DevEx сам по себе не методология (когда тебе дают чёткие инструменты), а фреймворк (когда акцент делается на практиках и образе мысли). В статье, кстати, DevEx как раз фреймворком и именуется.
Как это работает? Сначала вы выравниваетесь по тому, что для вашей компании или команды является состоянием потока и каким вы его хотите видеть. Потом выделяете факторы, которые влияют на него в лучшую и в худшую сторону. Затем уже эти факторы некоторым образор оцениваете. И это не обязательно числовые значения, это может быть и "хорошо"-"нормально"-"плохо" и т.п.
Далее, оценив своё текущее положение, вы стараетесь внедрить улучшения в тех областях, которые тянут состояние потока вниз.
Такие дела.
Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы
Вот тут ещё попрошу пруфы. В каком из изданий Scrum Guide упоминается Velocity как часть фреймворка? В скрам входит только то, что написано в гайде. Всё остальное, даже то, что создатели могу рассказывать на публичных выступлениях или писать в блогах, не является частями скрама.
Цель инженерных метрик
Цели использования инженерных метрик могут быть разнообразными.
Directed by Robert B. Weide
Потом окажется, что презентацию по обратной связи делал условный Вася, который получит за этот скилл низкую оценку. И как после этого оценивать влияние его презентации на общий уровень в команде?
Как будто можно было сначала провести оценку, а потом поделить темы в зависимости от уровня навыка и критичности скилла.
Проблема этого подхода заключается в том, что собственно менторинга и оценки качества знаний (компетенции) нет. Один коллега что-то самостоятельно изучил, рассказал другим и... И получил галочку, заполнил ещё одну ячейку матрицы?
Трёх скоростей для путешествия априори мало, я про это говорил. Диапазон узкий, разница между передачами скорее всего значительная. С такой трансмиссией силы будут уходить быстрее.
Мягкое седло - синоним онемевшей промежности. На мягком седле приятно проехать 10км в городе по асфальту. Но даже вот так 100+ км проехать - сначала будет жопка побаливать. А потом по докторам ходить придётся.
Натирание происходит либо от неудобного седла, либо от неправильно подобраной одежды. Широкое седло "диван" и труханы+джинсы - залог натирания, например.
Я рад, что герои статьи успешно финишировали. При этом, скажем так, я бы не рекомендовал повторять их эксперимент один в один. Всё же лучше уделить больше времени изучению теоретической базы. Тогда глядишь и поездка дастся легче.
Дя, с т.з. велосипедизма странноватая история. Планетарочка на три скорости для путешествия, "южноафриканская Мерида", мягкое седло на дальняк.
Но за само путешествие - однозначно лайк.
Кайфанул от статьи, большое спасибо!
Спасибо, большинству пунктов одобрительно киваю.
Очередная статья "делайте хорошо, а плохо не делайте")
Я нанимаю профессионалов (хард скиллы)... Я смотрю на софт скиллы...
Поздравляю, вы проводите обычное собеседование и набираете людей как любой рекрутер с годом работы.
Ещё внимание привлёк пассаж про недоверие к скрам мастеру. А к автору статьи у кандидатов или коллег из других команд врождённое доверие? Доверие можно заслужить и любой опытный специалист, особенно отвечающий на налаживание коммуникации, должен уметь это делать. Да, можно говорить, что со старта к скрам мастеру относятся с недоверием - это будет правдой для большинства случаев. Но дайте человеку хотя бы 2-3 недели, а потом считайте цыплят.
Красивый замок из песка, который нужно успеть показать всем, пока он не рассыпался)
Вопрос, который уже накинули здесь и он остался без ответа, это замена выделенного слота на "ещё одно уведомление, на которое нужно ответить". Раньше у трёх амиго был один одинаковый слот. Сейчас амиго всё равно должны находить время, но теперь уже "кто когда сможет".
Далее, а есть ли смысл в "непрерывной" оценке багов через бота? Что с ними дальше происходит? Разработка может сразу брать их в работу? Или всё же есть некий буфер, он же бэклог, который наполняется и оттуда забираются задачи в замисимости от срочности? Если второе, то в чём выигрыш?
Ещё я не заметил упоминания классического фоксу оценивания: если есть хотя бы две сильно отличающиеся оценки, эта задача/баг оценивается отдельно. Потому что это признак некого понятийного разрыва в команде. А тут просто считается среднее.
И это подводит нас к последней мысли. Шакала от 1 до 100? Серьёзно? Кто-то понимает "в граммах" разницу между 60 и 61? Какие у вас в принципе значения приоритетов в тасктрекере?
Во-первых, пюсую опасениям, что размещение "кипятильников" в мировом океане не способствует здоровью планеты. Да, человеки уже заметно повлияли на экосистемы суши. Значит ли это, что теперь пришло время "выжигать" океан? Уверен, что нет.
Во-вторых, при всей технической эффективности подводных ЦОДов, мне не даёт покоя вот какая мысль: неужто подводные ЦОДы не бэкапятся на сушу? Если руководствоваться правилось территориального разнесения резервных копий, то бэкапы должны храниться на удалённой площадке. Либо такой же подводной, либо наземной. Решитесь ли вы иметь и основную и резервную площадку под водой? Если нет, то поздравляю, вам всё равно нужен традиционный ЦОД. Да, в меньших объёмах, но всё же.
Истина