«Я не ответственный, я — Responsible» — как объяснить бабушке, что такое RACI-матрица +58




Приехала я год назад к друзьям играть в настолки. А они ссорятся. Из-за того, что Маша сказала Саше вынести мусор / убрать носки / погулять с хомяком, а он не сделал, потому что тупо забыл. Рассказала я Саше и Маше про 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 матрицы, на бытовых примерах из жизни:



И в обоих шуточных примерах допущены ошибки при составлении, которые в реальном проекте могут мешать. Ниже всего два раздела, рекомендации — «как стоит делать», и чек-лист для проверки — «как не стоит делать».

Рекомендации по составлению матрицы


Я порылась в Википедии, почитала, что пишут иностранные коллеги и собрала все рекомендации по составлению матрицы.

  1. В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
  2. Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта
  3. Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
  4. В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
  5. Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней. 
  6. Лучше устанавливать A и R на минимальный соответствующий уровень.
  7. Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
  8. Сведите к минимум позиции I и С.
  9. Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
  10. 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):

  1. korjavin
    /#23967429 / +38

    Стало непонятно зачем

  2. akomiagin
    /#23967473

    Интересно, а как решить вопрос с тем как собрать представительную выборку для группы в реальном проекте (в вашем случае папа, мама, сын, бабушка, кот)? Или это всегда лотерея и кто во что горазд в зависимости от культуры и процессов в компании?

    • vesper-bot
      /#23967495

      А это вы узнаете в следующей серии. ;)

    • AllexIn
      /#23967573 / +2

      Насколько я понимаю всё идет от А.

      У А появляется требование. В процессе обсуждения с командой выясняется кто будет R, кто может C и кого надо I.

      В статье говорится, что надо использовать Роли, а не Имена. Это выглядит плохой идеей. Потому что задачи идут не от Роли А, а от конкретного человека, у которого по какой-то причине есть требование это А получить. И если завтра *bus factor* и придет новый человек на туже должность - далеко не факт что А останется актуальным.

      В случае бас фактора никакого "передали ответственность по умолчанию на нового человека с той же ролью" очевидно не работает и в любом случае придется пересматривать столбец связанный с этим человеком.

      • Asya_Dyu
        /#23967733 / +3

        По идее, роли а не имена, потому что рисовать роль под одного конкретного человека — самоубийство. И для проекта и для человека.

        У меня так новоиспеченный техдир чуть не отъехал по здоровью, т.к. многие проекты мы завязали на него, а не на роль. Техдир сначала был тимлидом, компания начала расти и тимлид стал техдиром. В роли тимлидов оказались другие ребята, но они не смогли забрать задачи, техдир зашивался, мы срывали сроки.

        Но вы правы, что «роль» должна коррелировать с «именем». Это и про вовлеченность, и про компетентность. Но все же, рисовать роль под одного человека — очень рискованно.

        =======
        Еще дополню.

        Я писала выше, что в матрице «задача/таск», это вроде значимого этапа проекта. Иллюстрация с семьей может немного путать.

        Если совсем докапываться, то команда под названием «семья», делает проект под названием «выезд на дачу», где есть этап «сбор и подготовка провизии», «транспортировка», «интерактивно-развлекательный модуль» и т.п.

        К примеру, роль «Папа» — глава семьи, с пулом скиллов и обязанностей. Тогда Папа был бы «A» в задаче(этапе) «транспортировка»; при чем Папа вполне мог бы делегировать конкретную фичи в проекте «прогреть машину» или «выкопать машину из сугроба» Сыну, т.к. Сыну хватило бы на это компетенций.

      • A-Z-0-9
        /#23972707

        Для абстракных процессов надо использовать Роли, а для реального проекта Имена.

    • Asya_Dyu
      /#23968279

      Поправьте, пожалуйста, если я неверно поняла.

      Если вы под «представительной выборкой» имеете в виду, какие должны быть роли в проекте вместо Мамы и Папы, то это по команде смотрится, как я понимаю.

      Типа собрались делать проект. Поняли из чего проект состоит (этапы раз, два, три); поняли, что за скилы нужны, чтобы эти этапы реализовать; поняли у кого эти скилы есть (инженер, разработчик, дизайнер, артдир, манагер, аналитик); прописали роли и проверяем, а действительно ли все эти люди в проекте нужны; или наоборот, точно ли мы никого не забыли.

  3. AllexIn
    /#23967567

    Выглядит очень интересным инструментом. Спасибо.

  4. aborouhin
    /#23967695 / +1

    Инструмент интересный. Понятно, что упрощений много, но лучше, чем просто список "ответственных" через запятую без уточнения ролей.

    Но вот единственное, что хочется прямо обязательно уточнить - это разделить "C" на собственно консультантов ("спросим у бабушки совета, какой горошек взять") и согласующих лиц ("обязательно согласуем марку горошка с бабушкой, т.к. она очень придирчива к выбору данного продукта, и пока бабушка не согласовала - не купим"). А лучше ещё и собственно консультантов - на обязательных ("даже если сами можем выбрать горошек - всё равно послушаем по этому поводу мнение бабушки") и факультативных ("спросим бабушку, только если сами запутались в 20 сортах горошка"). Иначе порядок взаимодействия со всеми этими "C", мягко говоря, неочевиден и может привести к конфликтам.

    • AllexIn
      /#23967719 / +1

      Требования к горшочку это уже не С, а А. Может быть больше одного А(хоть это сразу не очевидно).

      • MagisterLudi
        /#23967769 / +3

        Первое правило RACI матрицы — только одна А для каждого этапа проекта.

        • AllexIn
          /#23968011 / +3

          Хм. Ок. Значит будет декомпозиция и появится еще одна таска: утвердить горшочек

      • ggo
        /#23970263

        A - все таки, отвечающий за результат, при этом в горшочках он может не шарить.

        C - следует понимать широко, не просто возможность опциональной консультации, но и ответственность за рекомендации, которые должны привести к нужному результату.

        Так что бабушка - С.

    • Asya_Dyu
      /#23967777

      Т.к. в матрице не прописано как взаимодействовать с С (консультантом), то это остается на усмотрение команды. Плюс еще же разный состав стейкхолдеров, так что точно адаптировать под себя придется.

      • AllexIn
        /#23968013

        Если С начинает что-то апрувить это уже А, даже если мы его так не называем.

        • petrol8s
          /#23968201

          Так С может совмещаться с А.

          • AllexIn
            /#23968245

            Что такое С? С это:

            • я не знаю где купить горшок

            • посмотри в магазине на углу

            С не апрувит магазин. И не апрувит горшок. С рассказывает варианты решения и отвечает на вопросы в рамках своей компетенции.

            Горшок апрувит А. Потому что А решает что задача выполнена правильно. Если А пофиг на горшок и есть еще кто-то, кому не пофиг у нас получается два А. Никак не может быть С тот кто что-то апрувит.

        • Asya_Dyu
          /#23968247

          В проекте могут быть стейкхолдеры, которые вообще не войдут в матрицу; это будет часть процесса, а не роль.

          К примеру, за этап «согласование с заказчиком макетов» отвечает А. Но на самих стейкхолдерах не будет никакой ответственности. Именно А несет ответственность за согласование макетов и должен знать, что для этого надо сделать.

          • AllexIn
            /#23968261 / +1

            Это не имеет значения. Нам в рамках матрицы не важны критерии по которым А принимает задачу. Личное желание, требование закона, кто-то выше рангом.
            Здесь же обсуждается ситуация, когда у нас бабушка горшок хочет другой. То есть в матрице есть еще кто-то принимающий результат.

            Мы можем взаимодействовать с ним через А, но это выглядит как костыль, когда у нас уже есть конкретный апрувер в рамках матрицы. Впихивать костыль просто чтобы не было двух А у задачи?

            • Asya_Dyu
              /#23971603

              Впихнуть двух А как раз будет костылём.

              Нет такого этапа «купить горшки», т.к. «купить горшки» — способ достижения. Допустим, мы покупаем горшки, чтобы посадить рассаду, т.е. это будет мелкий таск для этапа «Подготовка К Агрофитнесу», в большом проекте «Летнее Рабство В Усадьбе Для Заготовки Провианта На Голодную Зиму».

              Бабушка шарит за горшки, она авторитетный источник. Мама тоже авторитетный источник и тоже шарит за горшки, только у нее чуть меньше опыта.

              Кто будет А зависит от того, к кому потом всё семейство подойдет и скажет: «Где рассада? Че сажать? Как нет рассады? Мы же с голода теперь помрем.»

              Т.е. по итогу, это тот, к кому зимой пойдет Папа, Сын и Кот за едой, на кого будут смотреть голодными глазами и кому будут мяукать голодным ртом.

              Помните рекомендацию?

              Лучше устанавливать A и R на минимальный соответствующий уровень.


              Так что тут вероятно Мама будет A, а Бабушка будет C.

              Разгоняемся. При назначении ролей, мы должны учитывать вовлеченность в проект и способности / возможности.

              У Бабушки чисто статистически вероятность дотянуть до зимы меньше, с кого тогда спрашивать?

    • iggr63
      /#23971467

      Да с С неразбериха. Даже в больших компаниях с PLM роль С зачастую считают вспомогательной хотя именно они определяют что и как R должен делать, а А - проверить. Потому что R - исполнитель, А - менеджер и только С носитель знаний.

  5. MockBeard
    /#23967841 / +3

    Ну вот, Microsoft избавляется от Котика и вы тоже избавляетесь от котика.

    • Asya_Dyu
      /#23968215

      Кстати, про котика. Вообще, котики — это хорошо, но в другом проекте. Тут Кота явно не в тему прилепили.

      Вот если бы рассматривали «создание уюта» как проект, то Кот вполне мог бы быть R с его скилами мурчания, лежания на коленках и тыканья мордочкой в ухо. Но в проекте «поездка на дачу» он оказался не нужен как ответственное лицо.

      • MockBeard
        /#23968327

        Согласен, но в контексте проекта нужно не забыть про управление рисками, так как котики не только мурчат и создают уют, но и шипят и мочатся на пол.

        • Asya_Dyu
          /#23968345

          Видимо, теперь придётся писать про управление рисками? :)
          (Мое слабое место, видимо, пришла пора закрывать пробелы)

          • MockBeard
            /#23970811

            С котиками вы слабо можете контролировать выполнение их непосредственных служебных обязанностей (мурчать), т.к. они практически не поддаются дрессировке и заменить исполнителя обычно невозможно (рука не поднимется). Поэтому нужно особенно тщательно подходить к выбору исполнителя этой роли (котенка) :)

      • tvr
        /#23968775

        "Но в проекте «поездка на дачу» он оказался не нужен как ответственное лицо."

        А мышей на даче кто гонять будет?

        Бабушка, которой не забыли взять рассаду для проекта "Поездка на дачу"?

        Ему надо было назначить таск - "отточить охотничьи навыки и когти" - R.

        В качестве A - сын, пусть оценивает готовность на своей шкуре.

    • shushu
      /#23969665

      оффтоп: Так вроде как остается Котик

  6. olehorg
    /#23968081 / +2

    вспомнилось незабвенное "я не коммунист, я - член партии. чай, не маленький, уже должен понимать разницу."

  7. Revertis
    /#23969041 / +1

    «Я не ответственный, я — Responsible»

    У моего отца когда-то была футболка с надписью "I'm very responsible. Everytime something goes wrong - I'm responsible!".

    • olehorg
      /#23969209

      знаменитый "гарри поттер и методы рационального мышления" начинается с:

      "Of course it was my fault. There's no one else here who could be responsible for anything."

  8. v1000
    /#23969139

    Я правильно понимаю, что "кот" был в девичестве "Питомец Шарик", поэтому его спрайт на картинке, и фраза "попал в проект через мур-мур" вызывают когнитивный диссонанс?

    • Zenitchik
      /#23969277

      Если кот хорошо кушает - он может соответствовать имени Шарик.

    • Asya_Dyu
      /#23971459

      Там две неверных матрицы.

      Одна с Шариком, вторая с Котом.

      image

      Я разбирала только ту, что с Котом. Но в матрице с Шариком смысл не сильно изменится.

      image

  9. Winnie13
    /#23972319

    Я, может, какой-то негативный человек, но в коллективах, где без RACI-матрицы не могут разобраться кто что должен делать и что ему за это будет либо не будет, по факту есть только одна действенная роль. Она у владельца денег и рисков, т.е. у A. И нормально делегировать получается только если делиться этим самым природными аспектами A, а не выдумывать всякие RCI. Потому что когда выдумывают, то в итоге всё приходит к равновесному состоянию "хочешь сделать хорошо - сделай это сам".

    А где произошло какое-то чудо, и люди сами как-то интуитивно сработались и всё хорошо - там эта матрица не нужна тем более.

  10. RealGringo
    /#23973335 / +2

    Инструмент в теории звучит красиво и интересно. Однако из моей практике он ни разу нам не пригодился... (про RACI марицу знали и понимали, как она работает). У нас реализовано много проектов небольших с очень коротким циклом Time2Market (от 2 недель до 2-х месяцев) Для каждого из них прописывать RACI - себе дороже (время - самый ценный ресурс), лучше это время посвятить развитию проекту(ам).

    На проекте с сроком вывода в ОПЭ в 9 месяцев он тоже не зашел... Своего заказачика мы знали очень хорошо, как и он нас - наверное, это и помогло - на старте проекта договорились о "правилах игры" и никакого RACI нам делать не пришлось - все "неожиданные" вопросы решалось оперативно и в режиме онлайн.

    Возможно, в RACI есть смысл на очень больших, длительных проектах и с высоким фактором неопределености (хотя бы в начальных его фазах).

    Так что ограничения для применения инструмента есть, но за статью спасибо - подано интересно!

    • Asya_Dyu
      /#23975523

      Окей, спасибо, что поделились.

      У меня просто пригорело с того, что в интернетах пытаются объяснить как пользоваться инструментом на пальцах, а в итоге чепуха получается.

  11. NekittpppetroV
    /#23975495

    вероятно, попал в проект через мур-мур

    Бывает хрен выгонишь тех, кто попал через мур-мур, спасибо за статью, повеселили и инфу полезную дали

  12. souls_arch
    /#23977495

    То есть, кота вы за человека не считаете? И за коньячком он у вас не гоняет и мышей не ловит? Стыдно, ей-богу, девушка. Лоток, кстати, финально контролирует тоже он. Только кот, и никто иной, может утверждать, достаточно ли он для него чист. Иной ведь при неправильной чистке могёт и промазать туалет то! А кто определяет вкусноту купленного мяса и правильность приготовленного шашлыка? Кто контролирует любой процесс в доме?

    Сразу видно, - нет у вас кота, и - не было!

    • MagisterLudi
      /#23978779

      Кроме дураков и дорог, есть и еще «любители котов» в проектах.