Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про ToDoList и таск-трекеры и нарисовала им на холодильнике импровизированную асану. Маша наклеила стикеры с задачами и сроками, Саша терпеливо кивнул. Настолки состоялись.
Недавно я снова заглянула в гости. Стикеры на холодильнике висят, а Маша и Саша опять ссорятся. Точнее, громко выясняют, кто хотел починить стол / вывести холодильник / искупать кота, кто по-факту должен был это делать, и почему до сих пор ничего не сделано. Я промолчала, т.к. в чужие семейные разборки со своим PMBOK-ом не лезут.
Но потом решила, что всё нормально, лезут, т.к. вспомнила, что видела RACI-матрицу для распределения ответственности с шуточным объяснением через поездку семьи на дачу. Полезла искать эту картинку для Саши с Машей, нашла, а в ней куча ошибок:
Простите. Не могу промолчать. Не надо так.
Общая суть
Есть в проектном менеджменте такой инструмент — RACI матрица PMBOK Guide (9.1.2.1 Organization Charts and Position Descriptions, Matrix-based charts)
RACI — это аббревиатура:
R — Responsible
A — Accountable
C — Consulted
I — Informed
И вокруг этой матрицы есть путаница. Responsible и Accountable можно перевести на русский язык одинаково — ответственный, иногда это можно использовать как синонимы, но не в RACI matrix. В матрице ответственности между Responsible и Accountable семантическая пропасть, вот вам мостик через неё.
Матрица обычно создается с вертикальной осью (левый столбец) задач (из структуры разбивки работ) или результатов (из структуры разбивки продукта), и горизонтальной осью (верхний ряд) ролей (из организационной схемы).
Responsible — тот, кто будет выполнять этап, прям физически, к примеру, Вася делает кликабельный прототип приложения. Он Responsible за этап проекта «прототипирование».
Accountable — тот кто апрувит результат и отвечает за него. В некоторых вариациях звучит как Authorize. В зависимости от команды, это может быть менеджер Васи, может быть старший дизайнер Васи, а если в команде 2,5 человека, то это может быть и сам Вася. Но такая практика сгодится только для супер-маленьких команд, не надо к ней прилипать.
Informed и Consulted тоже кажутся близки по смыслу. Основное отличие в том, что у C двусторонняя коммуникация в проекте, а у I — односторонняя. C может влиять на проект, а I — нет.
Я нашла в сети еще объяснения RACI матрицы, на бытовых примерах из жизни:
И в обоих шуточных примерах допущены ошибки при составлении, которые в реальном проекте могут мешать. Ниже всего два раздела, рекомендации — «как стоит делать», и чек-лист для проверки — «как не стоит делать».
Рекомендации по составлению матрицы
Я порылась в Википедии, почитала, что пишут иностранные коллеги и собрала все рекомендации по составлению матрицы.
- В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
- Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта.
- Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
- В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
- Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней.
- Лучше устанавливать A и R на минимальный соответствующий уровень.
- Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
- Сведите к минимум позиции I и С.
- Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
- RACI матрицу иногда приходится обновлять по ходу проекта, т.к. она может устареть.
Проверка матрицы
Проверяют матрицу по двум направлениям: по вертикали и по горизонтали. Вот чек-лист, как проверить свою RACI матрицу на вшивость.
Вертикальная (по ролям)
Т.е. оценивается насколько сбалансированы роли в проекте
Слишком много R
Проверочный вопрос: «Вывезет человек на этой роли так много задач?»
Нет пустых мест
Проверочный вопрос: «Человеку в этой роли действительно необходимо участвовать во всех этапах проекта?»
Слишком много A
Проверочный вопрос: «Можно ли снизить количество процессов, в которых человек в этой роли принимает решение и отчитывается за них?»
Нет R или A
Проверочный вопрос: «Это нужная роль? Можно ли перераспределить часть ответственности на другие роли или передать часть ответственности с других ролей на эту?»
Двойные позиции A/R, или A/I
A/R, A/C, R/C — возможная картина для очень маленькой компании, но лучше избегать.
A/I, R/I, C/I- свидетельствует о непонимании RACI матрицы как инструмента.
Общая картина
Проверочный вопрос: «Соответствует ли количество ответственности на проверяемой роли уровню подготовки человека / его вовлеченности в проект?
Горизонтальная (по этапам)
По сути просматриваем, есть на каждом этапе чувак, который будет принимать решение, который будет это выполнять, и т.д.
Нет R
Нет исполнителя данного этапа. Проверочный вопрос: «Кто будет это делать?»
Слишком много R
Работа может замедлиться. Проверочный вопрос: «Можно ли разбить этап на более конкретные задачи, чтобы снизить количество исполнителей в этапе?»
Нет A
Нет ответственных, нет выполненной работы. Проверочный вопрос: «У кого есть полномочия из участников проекта, чтобы принять окончательное решение и иметь дело с последствиями данного этапа?» Т.е. кто отдает команду в каком направлении атаковать, и кому снесут голову с плеч, если направление оказалось неверным.
Больше, чем одна A
Первое правило RACI матрицы — только одна А для каждого этапа проекта.
Все ячейки заполнены на каждом этапе
Проверочный вопрос: «Действительно ли нужны все участники проекта на каждом этапе? Есть при преимущества от их участия?»
Нет C/I
Возможно вы кого-то забыли. Проверочный вопрос: «Вы учли всех участников проекта? Коммуникация между «отделами» налажена? Могут ли отделы начать выполнять какой-то этап параллельно или без учета последних изменений? »
Слишком много C
Замедляет проект. Проверочные вопросы: «Действительно нужно консультироваться со всеми C? Затраты часов на эти консультации окупаются? Можно просто проинформировать эти роли?»
Слишком много I
Проверочные вопросы: «Приносит ли это информирование пользу проекту? Или просто создает лишние созвоны и совещания? Можно информировать людей на этих ролях только в исключительных обстоятельствах? Можно ли отказаться от информирования людей на этих ролях?»
Много двойных позиций
Да, в маленькой команде могут возникать «двойные позиции», к примеру, когда на одном и том этапе один человек и выполняет задачу R и принимает по ней конечное решение A. Но такая формулировка может показывать непонимание матрицы, задач, команды, ответственности.
Непоняточки
Т.к. матрица разделяет Responsible и Accountable, то складывается впечатление, что R не несет ответственность за свои действия. Дело в том, что на каждом этапе может быть много R, и нужен человек, который может решать, соответствует ли результат поставленной задаче. R отвечает только за свою работу, а A чаще отвечает за работу других. Если полетят головы, то начинать будут с A.
RACI матрица не регулирует, кто будет планировать этап. С другой стороны, это гибкость, можно менять условия под свою команду/проект.
RACI матрица не регулирует, будет ли C (консультант) давать консультацию только по запросу, или он будет сам вмешиваться в проект, когда сочтет, что его консультация необходима, и позже сможет убедиться, что его рекомендации реализовали.
Еще есть неоднозначность с тем, кто будет отправлять информацию I или получать информацию от C, и отчитываться ему о результатах. Тоже, на ваше усмотрение.
Ошибки из примера
А теперь, с чек-листом, я проведу проверку шуточной матрицы из интернетов, из-за которой я начала писать:
Горизонтальная проверка (по этапам)
− Подготовить машину.
Нет R (исполнителя), того, кто будет это делать: пойдет выгонять машину из гаража, проверять масло и т.д.
+ Купить еду.
Тут все ок, мама отправила папу и сына в магазин, они не знали, какой горошек брать для оливье, и позвонили бабушке. Всё сходится.
± Взять игрушки.
Если речь идет о детских игрушках (в такой маленькой команде, как семья), скорее всего сыну пришлось бы взять на себя и A и R. Вряд ли папа смог бы его проконсультировать о том, какие игрушки сын любит. И вряд ли семья вызвала бы маму на ковёр, если бы сын поехал без игрушек.
Если речь идет о настолках для всей семьи, тогда распределение ролей выглядит логично, что мама дала задание взять с собой развлекухи, сын пошел искать «Монополию» в шкафу, а папа попросил взять не «Монополию», а «Манчкин».
+ Взять одежду.
Все окей: мама скомандовала всем взять теплые кофты, все взяли теплые кофты. Все в порядке.
− Взять алкоголь
Та же ошибка, что и с подготовкой машины, нет R. Непонятно, кто побежит в магазин за пивом. Да и польза этапа для всего проекта сомнительная. Убираем этот этап.
+ Замариновать шашлык
Все окей, папа решил, что настоящий шашлык может сделать только настоящий мужчина, и отправил сына становиться настоящим мужчиной. Ошибок нет.
+ Взять рассаду
Тоже все в порядке. Бабушке на даче нужна рассада, она отправила папу с сыном таскать ящики с рассадой. Мама дает ценные советы, как эти ящики поставить в багажник так, чтобы рассада доехала до дачи. Всё сходится.
− Взять инструмент
Опять нет R, кто этим будет заниматься — непонятно.
− Оценить погоду
Сын решил, что важно посмотреть, будет ли на выходных дождь. И опять, кто этим будет заниматься — неизвестно, т.к. R не назначили.
Итого, 4 или 5 из 9 этапов требуют корректировки.
Вертикальная проверка (по ролям)
Папа
Участвует абсолютно в каждом этапе проекта. При горизонтальной проверке, на этапе «Подготовить машину» нет R. Папа — единственный компетентный член семьи, так что ему придется совмещать A и R. Вероятно, эта роль перегружена, и надо перераспределить часть задач на других членов команды.
Мама
В целом роль выглядит сбалансированной, но т.к. в ходе горизонтальной проверки, мы нашли этапы, на которых нет R (исполнителей), Мама может стать R на этапе «Оценить погоду». Если мама маленькая и хрупкая (некомпетентная), то она не сможет стать R на этапе «Взять инструмент», но обычно мама знает, где что лежит, так что может выступить C (консультантом).
Сын
В целом роль выглядит сбалансированной. Если сын большой и сильный мальчик, то на этапе «Взять инструмент», может стать R (исполнителем).
Бабушка
В целом роль выглядит сбалансированной, я бы даже сказала ненапряжной. На этапе «Подготовить машину», Бабушку решили не информировать. Она может сорвать сроки по проекту «Поездка на дачу», т.к. не будет знать, что пора искать очки и начинать спуск по лестнице. Добавим Бабушке I на этапе «Подготовить машину», чтобы она успела подготовиться.
Кот
Ошибка, которая сразу бросается в глаза. Это ненужная роль. Этот ленивый шерстяной нахлебник не приносит велью и, вероятно, попал в проект через мур-мур. Эту роль нужно упразднить.
В итоге, получаем матрицу без очевидных ошибок:
Надеюсь после моего шуточного разбора полетов, стало чуточку понятнее, как пользоваться RACI-матрицей.
Меня вдохновила вот эта штука: Как объяснить бабушке, что такое Agile за 15 минут с картинками
Комментарии (41)
akomiagin
20.01.2022 17:54Интересно, а как решить вопрос с тем как собрать представительную выборку для группы в реальном проекте (в вашем случае папа, мама, сын, бабушка, кот)? Или это всегда лотерея и кто во что горазд в зависимости от культуры и процессов в компании?
AllexIn
20.01.2022 18:05+2Насколько я понимаю всё идет от А.
У А появляется требование. В процессе обсуждения с командой выясняется кто будет R, кто может C и кого надо I.
В статье говорится, что надо использовать Роли, а не Имена. Это выглядит плохой идеей. Потому что задачи идут не от Роли А, а от конкретного человека, у которого по какой-то причине есть требование это А получить. И если завтра *bus factor* и придет новый человек на туже должность - далеко не факт что А останется актуальным.
В случае бас фактора никакого "передали ответственность по умолчанию на нового человека с той же ролью" очевидно не работает и в любом случае придется пересматривать столбец связанный с этим человеком.
Asya_Dyu Автор
20.01.2022 18:35+3По идее, роли а не имена, потому что рисовать роль под одного конкретного человека — самоубийство. И для проекта и для человека.
У меня так новоиспеченный техдир чуть не отъехал по здоровью, т.к. многие проекты мы завязали на него, а не на роль. Техдир сначала был тимлидом, компания начала расти и тимлид стал техдиром. В роли тимлидов оказались другие ребята, но они не смогли забрать задачи, техдир зашивался, мы срывали сроки.
Но вы правы, что «роль» должна коррелировать с «именем». Это и про вовлеченность, и про компетентность. Но все же, рисовать роль под одного человека — очень рискованно.
=======
Еще дополню.
Я писала выше, что в матрице «задача/таск», это вроде значимого этапа проекта. Иллюстрация с семьей может немного путать.
Если совсем докапываться, то команда под названием «семья», делает проект под названием «выезд на дачу», где есть этап «сбор и подготовка провизии», «транспортировка», «интерактивно-развлекательный модуль» и т.п.
К примеру, роль «Папа» — глава семьи, с пулом скиллов и обязанностей. Тогда Папа был бы «A» в задаче(этапе) «транспортировка»; при чем Папа вполне мог бы делегировать конкретную фичи в проекте «прогреть машину» или «выкопать машину из сугроба» Сыну, т.к. Сыну хватило бы на это компетенций.
A-Z-0-9
21.01.2022 17:10Для абстракных процессов надо использовать Роли, а для реального проекта Имена.
Asya_Dyu Автор
20.01.2022 20:40Поправьте, пожалуйста, если я неверно поняла.
Если вы под «представительной выборкой» имеете в виду, какие должны быть роли в проекте вместо Мамы и Папы, то это по команде смотрится, как я понимаю.
Типа собрались делать проект. Поняли из чего проект состоит (этапы раз, два, три); поняли, что за скилы нужны, чтобы эти этапы реализовать; поняли у кого эти скилы есть (инженер, разработчик, дизайнер, артдир, манагер, аналитик); прописали роли и проверяем, а действительно ли все эти люди в проекте нужны; или наоборот, точно ли мы никого не забыли.
aborouhin
20.01.2022 18:28+1Инструмент интересный. Понятно, что упрощений много, но лучше, чем просто список "ответственных" через запятую без уточнения ролей.
Но вот единственное, что хочется прямо обязательно уточнить - это разделить "C" на собственно консультантов ("спросим у бабушки совета, какой горошек взять") и согласующих лиц ("обязательно согласуем марку горошка с бабушкой, т.к. она очень придирчива к выбору данного продукта, и пока бабушка не согласовала - не купим"). А лучше ещё и собственно консультантов - на обязательных ("даже если сами можем выбрать горошек - всё равно послушаем по этому поводу мнение бабушки") и факультативных ("спросим бабушку, только если сами запутались в 20 сортах горошка"). Иначе порядок взаимодействия со всеми этими "C", мягко говоря, неочевиден и может привести к конфликтам.
AllexIn
20.01.2022 18:33+1Требования к горшочку это уже не С, а А. Может быть больше одного А(хоть это сразу не очевидно).
MagisterLudi
20.01.2022 18:39+3Первое правило RACI матрицы — только одна А для каждого этапа проекта.
AllexIn
20.01.2022 19:31+3Хм. Ок. Значит будет декомпозиция и появится еще одна таска: утвердить горшочек
ggo
21.01.2022 10:50A - все таки, отвечающий за результат, при этом в горшочках он может не шарить.
C - следует понимать широко, не просто возможность опциональной консультации, но и ответственность за рекомендации, которые должны привести к нужному результату.
Так что бабушка - С.
Asya_Dyu Автор
20.01.2022 18:40Т.к. в матрице не прописано как взаимодействовать с С (консультантом), то это остается на усмотрение команды. Плюс еще же разный состав стейкхолдеров, так что точно адаптировать под себя придется.
AllexIn
20.01.2022 19:31Если С начинает что-то апрувить это уже А, даже если мы его так не называем.
petrol8s
20.01.2022 20:22Так С может совмещаться с А.
AllexIn
20.01.2022 20:32Что такое С? С это:
я не знаю где купить горшок
посмотри в магазине на углу
С не апрувит магазин. И не апрувит горшок. С рассказывает варианты решения и отвечает на вопросы в рамках своей компетенции.
Горшок апрувит А. Потому что А решает что задача выполнена правильно. Если А пофиг на горшок и есть еще кто-то, кому не пофиг у нас получается два А. Никак не может быть С тот кто что-то апрувит.
Asya_Dyu Автор
20.01.2022 20:33В проекте могут быть стейкхолдеры, которые вообще не войдут в матрицу; это будет часть процесса, а не роль.
К примеру, за этап «согласование с заказчиком макетов» отвечает А. Но на самих стейкхолдерах не будет никакой ответственности. Именно А несет ответственность за согласование макетов и должен знать, что для этого надо сделать.AllexIn
20.01.2022 20:36+1Это не имеет значения. Нам в рамках матрицы не важны критерии по которым А принимает задачу. Личное желание, требование закона, кто-то выше рангом.
Здесь же обсуждается ситуация, когда у нас бабушка горшок хочет другой. То есть в матрице есть еще кто-то принимающий результат.Мы можем взаимодействовать с ним через А, но это выглядит как костыль, когда у нас уже есть конкретный апрувер в рамках матрицы. Впихивать костыль просто чтобы не было двух А у задачи?
Asya_Dyu Автор
21.01.2022 14:39Впихнуть двух А как раз будет костылём.
Нет такого этапа «купить горшки», т.к. «купить горшки» — способ достижения. Допустим, мы покупаем горшки, чтобы посадить рассаду, т.е. это будет мелкий таск для этапа «Подготовка К Агрофитнесу», в большом проекте «Летнее Рабство В Усадьбе Для Заготовки Провианта На Голодную Зиму».
Бабушка шарит за горшки, она авторитетный источник. Мама тоже авторитетный источник и тоже шарит за горшки, только у нее чуть меньше опыта.
Кто будет А зависит от того, к кому потом всё семейство подойдет и скажет: «Где рассада? Че сажать? Как нет рассады? Мы же с голода теперь помрем.»
Т.е. по итогу, это тот, к кому зимой пойдет Папа, Сын и Кот за едой, на кого будут смотреть голодными глазами и кому будут мяукать голодным ртом.
Помните рекомендацию?Лучше устанавливать A и R на минимальный соответствующий уровень.
Так что тут вероятно Мама будет A, а Бабушка будет C.
Разгоняемся. При назначении ролей, мы должны учитывать вовлеченность в проект и способности / возможности.
У Бабушки чисто статистически вероятность дотянуть до зимы меньше, с кого тогда спрашивать?
iggr63
21.01.2022 14:22Да с С неразбериха. Даже в больших компаниях с PLM роль С зачастую считают вспомогательной хотя именно они определяют что и как R должен делать, а А - проверить. Потому что R - исполнитель, А - менеджер и только С носитель знаний.
MockBeard
20.01.2022 18:52+3Ну вот, Microsoft избавляется от Котика и вы тоже избавляетесь от котика.
Asya_Dyu Автор
20.01.2022 20:25Кстати, про котика. Вообще, котики — это хорошо, но в другом проекте. Тут Кота явно не в тему прилепили.
Вот если бы рассматривали «создание уюта» как проект, то Кот вполне мог бы быть R с его скилами мурчания, лежания на коленках и тыканья мордочкой в ухо. Но в проекте «поездка на дачу» он оказался не нужен как ответственное лицо.MockBeard
20.01.2022 20:51Согласен, но в контексте проекта нужно не забыть про управление рисками, так как котики не только мурчат и создают уют, но и шипят и мочатся на пол.
Asya_Dyu Автор
20.01.2022 20:55Видимо, теперь придётся писать про управление рисками? :)
(Мое слабое место, видимо, пришла пора закрывать пробелы)MockBeard
21.01.2022 12:38С котиками вы слабо можете контролировать выполнение их непосредственных служебных обязанностей (мурчать), т.к. они практически не поддаются дрессировке и заменить исполнителя обычно невозможно (рука не поднимется). Поэтому нужно особенно тщательно подходить к выбору исполнителя этой роли (котенка) :)
tvr
20.01.2022 22:53"Но в проекте «поездка на дачу» он оказался не нужен как ответственное лицо."
А мышей на даче кто гонять будет?
Бабушка, которой не забыли взять рассаду для проекта "Поездка на дачу"?
Ему надо было назначить таск - "отточить охотничьи навыки и когти" - R.
В качестве A - сын, пусть оценивает готовность на своей шкуре.
olehorg
20.01.2022 19:46+2вспомнилось незабвенное "я не коммунист, я - член партии. чай, не маленький, уже должен понимать разницу."
Revertis
21.01.2022 00:14+1«Я не ответственный, я — Responsible»
У моего отца когда-то была футболка с надписью "I'm very responsible. Everytime something goes wrong - I'm responsible!".
olehorg
21.01.2022 01:22знаменитый "гарри поттер и методы рационального мышления" начинается с:
"Of course it was my fault. There's no one else here who could be responsible for anything."
v1000
21.01.2022 00:48Я правильно понимаю, что "кот" был в девичестве "Питомец Шарик", поэтому его спрайт на картинке, и фраза "попал в проект через мур-мур" вызывают когнитивный диссонанс?
Asya_Dyu Автор
21.01.2022 14:21Там две неверных матрицы.
Одна с Шариком, вторая с Котом.
Я разбирала только ту, что с Котом. Но в матрице с Шариком смысл не сильно изменится.
Winnie13
21.01.2022 16:15Я, может, какой-то негативный человек, но в коллективах, где без RACI-матрицы не могут разобраться кто что должен делать и что ему за это будет либо не будет, по факту есть только одна действенная роль. Она у владельца денег и рисков, т.е. у A. И нормально делегировать получается только если делиться этим самым природными аспектами A, а не выдумывать всякие RCI. Потому что когда выдумывают, то в итоге всё приходит к равновесному состоянию "хочешь сделать хорошо - сделай это сам".
А где произошло какое-то чудо, и люди сами как-то интуитивно сработались и всё хорошо - там эта матрица не нужна тем более.
RealGringo
21.01.2022 19:09+2Инструмент в теории звучит красиво и интересно. Однако из моей практике он ни разу нам не пригодился... (про RACI марицу знали и понимали, как она работает). У нас реализовано много проектов небольших с очень коротким циклом Time2Market (от 2 недель до 2-х месяцев) Для каждого из них прописывать RACI - себе дороже (время - самый ценный ресурс), лучше это время посвятить развитию проекту(ам).
На проекте с сроком вывода в ОПЭ в 9 месяцев он тоже не зашел... Своего заказачика мы знали очень хорошо, как и он нас - наверное, это и помогло - на старте проекта договорились о "правилах игры" и никакого RACI нам делать не пришлось - все "неожиданные" вопросы решалось оперативно и в режиме онлайн.
Возможно, в RACI есть смысл на очень больших, длительных проектах и с высоким фактором неопределености (хотя бы в начальных его фазах).
Так что ограничения для применения инструмента есть, но за статью спасибо - подано интересно!
Asya_Dyu Автор
22.01.2022 13:38Окей, спасибо, что поделились.
У меня просто пригорело с того, что в интернетах пытаются объяснить как пользоваться инструментом на пальцах, а в итоге чепуха получается.
NekittpppetroV
22.01.2022 13:34вероятно, попал в проект через мур-мур
Бывает хрен выгонишь тех, кто попал через мур-мур, спасибо за статью, повеселили и инфу полезную дали
souls_arch
23.01.2022 02:03То есть, кота вы за человека не считаете? И за коньячком он у вас не гоняет и мышей не ловит? Стыдно, ей-богу, девушка. Лоток, кстати, финально контролирует тоже он. Только кот, и никто иной, может утверждать, достаточно ли он для него чист. Иной ведь при неправильной чистке могёт и промазать туалет то! А кто определяет вкусноту купленного мяса и правильность приготовленного шашлыка? Кто контролирует любой процесс в доме?
Сразу видно, - нет у вас кота, и - не было!
korjavin
Стало непонятно зачем