Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения

Публикация № 1070575

Управление - Управление проектом

27
В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

Продолжаю тему вопросов и ответов по курсу “Управление ИТ-проектами”.


В управлении проектами часто случаются конфликтыВ своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. И эта картина нередко бывает устроена довольно причудливым образом - например, бухгалтер может искренне быть уверенной в том, что какие-то задачи решаются сами собой и не видеть трудоемкости задач для разработки. А разработчики, наоборот, могут считать, что бухгалтерии совсем не сложно протестировать какие-нибудь печатные формы, и когда они не сообщают разработчикам сразу о косяках - это исключительно из вредности.
В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

И здесь я хочу поговорить про инструмент, который может помочь договориться, кто за какие задачи в проекте отвечает. Этот инструмент - матрица ответственности. Сразу хочу оговориться - разумеется, любой инструмент, любой документ - это не панацея. Как известно, “Автоматизация хаоса приводит к автоматизированному хаосу” - если сотрудник разгильдяй, и если он не готов выполнять свои прямые обязанности, то документы помогают не очень сильно. Тем не менее, помогают. За счет чего - расскажем несколько ниже.

 

Матрица ответственности

 

Итак, матрица ответственности, она же RACI-матрица (от сокращений английских слов Responsible-Accountable-Consulted-Informed).

По вертикали выписываем результаты, которые встречаются на проекте. Детализация может быть самой разной - можно указывать в матрице только самые высокоуровневые задачи, можно - детализировать до конкретных задач (некоторые применяют матрицу ответственности прямо в диаграмме Ганта в MS Project - указывая в графе “назначенные ресурсы” тех, кто за ту или иную задачу отвечает). В общем, все зависит от ваших целей. 
А по горизонтали - разные роли на проекте (РП, архитектор, сисадмин, бизнес-аналитик и т. п.). А на их пересечении указывается, какое отношение к этой задаче какая роль имеет.  
В самом простом варианте матрица включает в себя 4 позиции.
Р - разрабатывает (в английском R - responsible). Это непосредственный исполнитель по тому или иному результату. Обратите внимание, что в предлагаемой градации речь идет не про “разрабатывает” в значении “разработка/программирование” - у вас может программирования по той или иной задаче вообще не быть, скажем, речь идет про подготовку документа или описание бизнес-процесса. 
У - утверждает (или О - отвечает, в английском - A - accountable).  Это, образно говоря, “крайний” за тот или иной результат, тот кто его утверждает, “подписывает”. По замыслу авторов матрицы “Утверждает” и “Ответственный” - это синонимы. Обе позиции предполагают включенность участников в процесс, и ответственность за результат. Причудливость организации работы в некоторых проектных командах такова, что “утверждает” - это часто роль только на бумаге, то есть человек просто ставит подпись, не участвуя в процессе и не вникая результат. Это, как не трудно догадаться, с позиции оптимального результата не очень целесообразно…  
К - консультирует (в английском C - consulting) - человек, не занимающийся непосредственно выполнением задачи (см. пункт “разрабатывает”), но привлекаемый в процессе выполнения задачи. 
И - информируется (вот это “тся” иногда вызывает определенные вопросы - но обычно под буквой И обозначается именно тот, кого нужно информировать, а вовсе не тот, кто должен информировать, в английском I - Informed). Это тот сотрудник, которого нужно уведомить, когда тот или иной результат исполнен. В этом и главное различие между ролями “Консультирует” и “Информируется” - “К” относится к работе в процессе, а “И” - к работе, когда она уже сделана.

Расширенный вариант матрицы.

На самом деле, этими буквами картинка на проекте, разумеется не ограничивается. Я не возьмусь сказать, что есть какой-то универсальный подход, который бы подошел “абсолютно всем”. Зависит от ваших целей, и от того, как планируется использование матрицы.


Какие буквы могут добавляться?

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

Может быть конкретное разделение по задачам внутри пункта “Р - Разрабатывает”: 
СТ - Собирает требования
Р - Разрабатывает
Т - Тестирует
О - Обучает
Д - пишет документацию
(кстати, очень ценный пункт!)

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


Я обещала озвучить, за счет чего матрица ответственности помогает?


Обсуждение спорных вопросов из матрицы ответственности уже часто идет на пользуМы фиксируем обязанности и сообщаем их тем, к кому они относятся (разумеется, если РП просто нарисовал матрицу у себя в блокноте и никому не показал, она ничем не поможет)
Но если мы обсуждаем матрицу ответственности и с представителями ИТ, и с представителями бизнеса, мы можем, условно говоря, “сверить часы” - понять, где у нас точки зрения не сходятся. И либо договориться, либо эскалировать вопрос “наверх”, чтобы нам помогли договориться. 
Кстати сказать, и в том случае, когда сотрудники явно не выполняют свои обязанности просто по причине низкой заинтересованности, сам факт существования матрицы, в которых они указаны как ответственные, уже помогает. Во-первых, он все-таки самодисциплинирует. Во-вторых, если ситуацию таки приходится эскалировать наверх, то прописанные обязанности лучше работают как аргумент.    
В процессе подготовки самой матрицы всплывают сложности взаимодействия. Например, становятся наглядно видны проблемные места.

В моей практике часто встречаются, например, такие проблемы:

 

  • Спорная зона ответственности руководителя проекта со стороны исполнителя и со стороны заказчика. Кто отвечает за результат, кто принимает решения? 
    Хороший работающий вариант, как правило - это когда РП со стороны заказчика (ну, или ответственный представитель со стороны бизнеса, если речь идет о внутреннем проекте, когда ИТ-отдел внедряет что-то по запросу бизнес-подразделений/бухгалтерии и т. п.) берет на себя роль “Владельца продукта” - то есть описывает финальную картинку, и видит целевой результат - как то или иное прикладное решение должно работать с позиции пользователя. 
    А РП со стороны исполнителя (или ответственный айти-специалист, опять же, когда проект внутренний) - отвечает за архитектуру и техническую реализацию.
  • Практически за все задачи отвечает один и тот же человек (РП?). Он и швец, и жнец и на дуде игрец. И вообще с тоской думает, как ему разорваться на много маленьких “рпшничков”, чтобы успеть сделать если не всё… То хотя бы всё самое необходимое… 
    На этом месте иногда можно увидеть, что команды проекта-то на самом деле нет. Что всё делает полтора человека, остальные, максимум, готовы проконсультировать…
  • Проблема, что никто не хочет брать на себя ответственность. Люди не любят принимать решения, особенно в бюрократизированных организациях, где они понимают, что за неправильное решение им может влететь. Вообще, уговорить матерого руководителя что-то подписать - это отдельная история ))). Хотя чаще всего (если есть хоть какая атмосфера сотрудничества и взаимного доверия), уже даже подтверждение на словах/в электронной почте, что “да, я со всем принципиально согласен” - уже помогает дальнейшему взаимодействию. Я уже рассказывала, что в моей практике были ситуации, когда Устав по той или иной причине уполномоченные лица так и не подписывали, но сам факт наличия этого документа, принципиально согласованного, пусть даже и без подписи - уже помогал улучшить взаимодействие.  
  • Еще одна проблема, которая часто оказывается заметна - это  суровая незаменимость. Есть ровно один человек, у которого в голове есть картинка, как должен выглядеть проект. Если этот человек заболевает (или даже просто уходит в отпуск) - никто не представляет, какая ситуация на проекте.

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

Коль скоро мы увидели проблемные и спорные места - можно попытаться их обсуждать и разрешать.


А какие проблемы с распределением ответственности встречаются в ваших проектах?
Как получается их разрешать? Поделитесь!


 

27

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Rustig 1172 03.06.19 09:01 Сейчас в теме
(0) спасибо! полезно к прочтению и осмыслению.
понял на примере, что значит "высокоуровневые" требования - до сих пор непонятный термин для меня был...
добавлю информацию из вашего курса, с вашего разрешения :) - можно рисовать матрицу в нескольких экземпляров - "точка А" (текущее положение, как мы видим) и "точка Б" (идеальная матрица, идеальное взаимодействие, как бы нам хотелось распределить ответственность - возможно, это будет предметом очередных переговоров).
И еще добавлю, что анализ матрицы можно проводить по вертикали и по горизонтали: условно говоря, по вертикали анализируем роли и про каждую задаем вопрос "не слишком ли перегружена роль задачами?", по горизонтали анализируем задачу и задаем вопрос "эффективно ли распределены роли для решения задачи?".
как итог, продолжаем прорабатывать самые слабые звенья этой матрицы, так как в них кроется наибольшая потеря времени, динамичности или бюджета проекта.
2. MariaTemchina 803 03.06.19 10:47 Сейчас в теме
(1) Рустем, спасибо за комментарии!
3. Yashazz 2500 03.06.19 11:11 Сейчас в теме
Точка "а", точка "бэ"...Никакая матрица на самом деле ничего не даёт. Даже если вы в этом компоте варились год и знаете, как вам кажется, всю подноготную. Потому что есть такое внезапное явление, как "концепция изменилась", и оно обычно происходит N раз за время проекта. Так что примерно оценить степень звездеца, конечно, можно, а вот избежать - ни разу, и всем умненьким зарубежным анализам тут грош цена. Реальны только 2 вещи - жёсткий руководитель со стороны заказчика, который сможет заставить своих сотрудников кушать кактус, и жёсткий РП со стороны автоматизаторов, который совершенно ненаучными, зато эффективными способами этого заказчика нагнёт и продержит нагнутым до конца проекта.

Наша задача - не автоматизация, коллеги. Автоматизация, перефразируя Пелевина, тут никому нахрен не нужна. Наша задача - деньги зарабатывать, и реально полезны только приёмы, позволяющие эту задачу решить наименее напряжно)
Alnair; Gluk_1C; +2 Ответить
4. MariaTemchina 803 03.06.19 11:40 Сейчас в теме
(3)
Точка "а", точка "бэ"...Никакая матрица на самом деле ничего не даёт.

Яков, я не люблю категоричных высказываний... Как в сторону "этот инструмент - это панацея и спасение для всех проектов!!!" так и в сторону "это ничего не дает!!!".
Матрица может помочь лучше договориться. При наличии у всех сторон желания получить результат. При наличии, да, управленческой воли. При определенном уровне адекватности. То есть матрица помогает, но не по отдельности, а в комплексе. На проектах из разряда "Ты сильный - ты справишься... Нет, я умный - я даже не возьмусь!" никакая матрица не поможет.
Наша задача - не автоматизация, коллеги. Автоматизация, перефразируя Пелевина, тут никому нахрен не нужна. Наша задача - деньги зарабатывать, и реально полезны только приёмы, позволяющие эту задачу решить наименее напряжно)

С одной стороны - соглашусь, что сама по себе автоматизация мало кого спасает. "Автоматизация хаоса приводит к автоматизированному хаосу" (С).
С другой - позиция, что "наша задача - деньги заработать, а у клиента хоть трава не расти" - приводит к кратковременным заработкам, но никак не приводит к длительному сотрудничеству (см. мою статью про Дилемму заключенного в управлении проектами) - все-таки правильно, когда исполнители тоже заинтересованы, чтобы у заказчика всё было хорошо...
5. Yashazz 2500 03.06.19 14:19 Сейчас в теме
(4) Насчёт помощи в переговорах и определении вектора движения матрица может чуток помочь.
А что касается "у заказчика всё хорошо" - это не значит, что софт работает, отдача повышается, люди там эффективно трудятся и 1С упрощает жизнь. Нет. Это значит, что все заинтересованные руководители довольны. К качеству автоматизации это имеет слабое отношение)
16. Rustig 1172 04.06.19 03:43 Сейчас в теме
(5) посмотрите мои публикации - разработки и наработки - все они используются моими клиентами на протяжении 5 и более лет, клиенты начинали свою деятельность с одного человека, сейчас у них штат (10-20 человек), несколько офисов, производство у некоторых...Клиенты растут во всех смыслах, и есть доля успеха в том, что в какой-то момент была хорошо продумана система учета 1с, которая позволила быстро масштабировать бизнес... Это в защиту "качества автоматизации"!
15. Rustig 1172 04.06.19 03:36 Сейчас в теме
(3) ну вроде и "да", а вроде и "нет"...двоякое чувство вызывает ваш ответ...
"да" - потому что не поспоришь, что концепция меняется...ну такова жизнь, и природа проектов и взаимодействий людей...
"нет"вызывает - потому что у вас одни эмоции, и о предмете разговора ничего кроме эмоций не высказано...
не понятно, как отвечать человеку, когда он не задает вопросов, считает что все уже знает на свете и высказывается категорично...
представляю, в какой картине мира вы живете: в проектах у вас со всех сторон жесткие РП, все друг друга держат в жестком напряжении...до инфаркта осталось немного...
20. Yashazz 2500 04.06.19 17:05 Сейчас в теме
(15) не берусь утверждать, что "всё знаю", но располагаю весьма богатой выборкой за 20 лет работы, и именно её экстраполяция сподвигает на категоричность. И это не проблема восприятия или пристрастной фильтрации, это грустная объективная реальность.
А картина мира у меня, как и у всех: кругом бардак, никому ничего не надо, деньги пилят, крайних ищут, начинают заново. Всё просто и привычно)
22. Rustig 1172 04.06.19 17:36 Сейчас в теме
(20)
Всё просто и привычно)

я бы сказал "все печально" в вашей картине мира... печаль вызывает и ваше состояние на текущий момент: одни говорят, что стакан наполовину пуст, другие - что он наполовину заполнен...
23. acanta 60 04.06.19 22:48 Сейчас в теме
(22) И мы каждый раз не знаем кому из них можно верить?
6. Diversus 1958 03.06.19 14:34 Сейчас в теме
Всю статью можно охарактеризовать всего одним вашим предложением:
В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.

Абсолютно не важны эти матрицы, если этот вопрос будет решен.
7. MariaTemchina 803 03.06.19 14:40 Сейчас в теме
(6)
Абсолютно не важны эти матрицы, если этот вопрос будет решен.

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

Разумеется, матрица - не цель, а средство. Ну и любой успешный проект можно запороть, если написать достаточное количество документации...
8. Diversus 1958 03.06.19 15:08 Сейчас в теме
(7) Мария, коль ответили, то можно пару вопросов вам, возможно не совсем по теме.
Вы пишите красивые статьи про проекты, проектную деятельность, управление и т.д.
Все это красиво и забавно, но вот червячок, который живет у каждого из нас мне говорит: "Виталий, а ты уверен, что Мария реально, через все это прошла, чтобы давать советы другим?"
Читая ваши статьи не могу избавиться от этой мысли, когда вижу эту "академичность", которая часто не сочетается с реальной практикой. В связи с этим вопросы:

1) На каких проектах вы были и в роли кого?
2) Сколько из них было выполнено успешно и/или, так или иначе, не были выполнены, или доведены до конца лишь частично?
3) Scrum/Agile/уставы проектов и т.д. Что из этого вы реально применяли в своей работе на проектах, а что из разряда "я это просто знаю, когда будет такая необходимость применю"? Не просто попытаться дать определения в статье и знать, что это такое, а реально использовать в своих проектах?
4) Каковы масштабы и ваша роль в этих проектах? Одно дело, когда проект автоматизации на 5 человек, другое, когда на 500.
5) Какой ваш самый крупный "косяк" на проекте, когда "клочки по закоулочкам летели"? Все, кто реально хоть что-то автоматизировал, ВСЕГДА с этим сталкивались. Я не знаю таких специалистов, которые все проекты доводили идеально до конца, не думаю, что вы исключение.

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

Спасибо.

PS: Прошу не воспринимать мои вопросы как критику или какие-то придирки. Это логичные вопросы. Если говорите о каких-то методиках, то хотелось бы знать, вы их сами использовали
или нет.
10. MariaTemchina 803 03.06.19 15:33 Сейчас в теме
(8)
Все это красиво и забавно, но вот червячок, который живет у каждого из нас мне говорит: "Виталий, а ты уверен, что Мария реально, через все это прошла, чтобы давать советы другим?"

Виталий, хороший вопрос! Понимаю вас, я тоже не люблю "теоретиков", которые начитались умных книжек, а их на практике применять не пробовали.

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

Я писала об этом немного в статье "Быть или казаться". Крайность номер один: когда берут "красивые слова" и пытаются их с умным видом применить на практике не заботясь о том, уместны они или нет. Иногда наблюдаю как таким образом применяют разные технологии внедрения от 1С. Получается так себе.
Крайность номер два: когда говорят, что "красивые слова только мешают", и вообще "я уже это всё делал, и сам знаю как", и делают по наитию. Иногда получается (чаще всего получается лучше, чем в первом варианте, иногда даже лучше чем в третьем, но без гарантии), но есть определенный потолок в развитии и трудно обеспечить уверенность в результате.
И третий подход, между крайностями - когда то, что вы называете "красивыми словами" уместно накладывается на реальный опыт. Встречается куда реже, чем первая крайность, а там где встречается - люди чаще всего не очень громко кричат о том, что у них получается, так как заняты. Вот к этому разумному подходу я всех и призываю. Но, повторюсь, поскольку "крайность номер один" гораздо проще реализуема, чем "третий подход", то действительно разнообразных "эффективных менеджеров" пруд пруди.
1) На каких проектах вы были и в роли кого?

Проекты были в разных сферах. Кроме проектов автоматизации (внедрение УПП, КА, ЭДО и т. п.), занималась проектами в других сферах: производство промышленных компьютеров, навигационных систем, организация массовых мероприятий до 1000 человек, запуск российского представительства международной компании, реорганизация производственного предприятия и т. п. Роли были разные - руководитель проекта, РП со стороны заказчика, консультант, Scrum-мастер, координатор, Agile-коуч, руководитель проектного офиса.
2) Сколько из них было выполнено успешно и/или, так или иначе, не были выполнены, или доведены до конца лишь частично?

Часть была выполнена успешно, часть не выполнена, часть доведена до конца лишь частично. Статистику не считала, в том числе из-за разнородности проектов ))). Честно говоря, я бы с некоторой настороженностью относилась к руководителю, который говорит о том, что все его проекты 100% успешны - тут можно совершить "систематическую ошибку выжившего"...
3) Scrum/Agile/уставы проектов и т.д. Что из этого вы реально применяли в своей работе на проектах, а что из разряда "я это просто знаю, когда будет такая необходимость применю"? Не просто попытаться дать определения в статье и знать, что это такое, а реально использовать в своих проектах?

Scrum в чистом виде - нет. Я в него не верю. Возможно, кто-то верит, у кого-то он работает.
Agile - да, несомненно! В том числе до того, как узнала это слово.
Устав проекта - да, несомненно! В разных формах.
План управления проектом - да, несомненно! Тоже в разных вариантах.
Матрица ответственности - да, несомненно!.. Продолжать, с вашего позволения, не буду.
4) Каковы масштабы и ваша роль в этих проектах? Одно дело, когда проект автоматизации на 5 человек, другое, когда на 500.

Пожалуй, совсем крупными проектами автоматизации руководить не приходилось. Скорее помогала и поддерживала старших товарищей. ))). А вообще - руководила, наверное, проектами с командой порядка 100 человек.
5) Какой ваш самый крупный "косяк" на проекте, когда "клочки по закоулочкам летели"? Все, кто реально хоть что-то автоматизировал, ВСЕГДА с этим сталкивались. Я не знаю таких специалистов, которые все проекты доводили идеально до конца, не думаю, что вы исключение.

Знаете, на собеседованиях любят такие вопросы задавать. Конечно, косяки были, без них не интересно! Вопрос непростой и интересный - вот, недавно Дмитрий Коткин даже проводил онлайн-конференцию "Ошибки руководителей". Кажется, вы мне подкинули идею для новой статьи! ))))
12. Diversus 1958 03.06.19 15:42 Сейчас в теме
(10) Спасибо, это и хотел услышать. Судя по комментарию, оказывается вы умеете писать и "не академично" и знаете, мне так больше нравится :)
За этими умными фразами проглядывается живой человек :D

А если серьезно, то теория без практики - это штука, которая не приносит пользы. Если есть возможность используете свой личный опыт с примерами в статьях. Это сильно разбавит статьи, придаст им человеческое лицо и сделает их ближе к людям. Просто совет.

Ну а на счет статьи с косяками, то было бы здорово это почитать. Ждем.
MariaTemchina; +1 Ответить
13. MariaTemchina 803 03.06.19 15:49 Сейчас в теме
(12)
А если серьезно, то теория без практики - это штука, которая не приносит пользы.

Плюс стопятьсот! )))

Если есть возможность используете свой личный опыт с примерами в статьях. Это сильно разбавит статьи, придаст им человеческое лицо и сделает их ближе к людям. Просто совет.

Да, вы правы. Нюанс в том, что очень часто натыкаешься на NDI - то есть надо как-то маскировать информацию...

Ну а на счет статьи с косяками, то было бы здорово это почитать. Ждем.

Чёрт, и кто меня за язык тянул? )))) Сама же предложила, теперь грех жаловаться )))).
Diversus; +1 Ответить
18. Rustig 1172 04.06.19 04:03 Сейчас в теме
(8) Виталий, я вообще до поры до времени не обращал внимания на околоуправленческие статьи, поскольку в терминах не силен, и не понимал о чем начинается дискуссия.
Данная статья призвана в первую очередь, проинформировать сообщество ИС, что такие инструменты в управлении проектами есть и давно используются, и есть большие сообщества управленцев, которые изучают кейсы провальных проектов и инструменты, с помощью которых можно было избежать провала.
Сама матрица ничего не гарантирует. Должна быть использована для анализа. Вот пример анализа https://kogio.ru/knowledge/matrica-otvetstvennosti/
Здесь нет волшебной таблетки. Что касается практик и, что самое интересное, практик в 1С, то их в открытых источниках почти нет. Поэтому такой скепсис вызывает теория про управление.
17. Rustig 1172 04.06.19 03:52 Сейчас в теме
(6) Виталий, привет!
речь идет о больших проектах, о разработке на 1млн рублей, срок проекта год, когда горизонта и перспектив еще не видно. Матрица и другие инструменты вкупе позволяют прогнозировать и планировать успех проекта - Заказчик будет доволен результатами точно-в-срок, работа будет оплачена вовремя.
На малых проектах порой и документация не нужна,
а также на проектах текущего сопровождения - когда отношения Заказчик-Исполнитель уже годами и прошлыми проектами отработаны - всякая дополнительная документация может привести к бюрократизации проекта...
В общем, по ситуации надо использовать инструменты... Я к примеру матрицу использую при входе к новому клиенту, когда Заказчика не знаю совсем - прописываю ожидания в любом виде - в матричном, линейном, в иерархичном... Чем больше, тем лучше...
9. Yashazz 2500 03.06.19 15:18 Сейчас в теме
Присоединяюсь. Вообще когда я задаю подобные вопросы всяким проповедникам Agile, адептам ISO и прочим теоретикам да "бизнес-аналитикам", они тихо сливаются или с разной степенью изящества пытаются выкрутиться, но никогда не сообщают конкретики. Мария?)
11. MariaTemchina 803 03.06.19 15:37 Сейчас в теме
(9) Яков - это более чем логично!
Угадайте, людей с каким опытом по предлагаемой шкале больше всего встречается среди "проповедников" красивых идей? (См. приложенную схему про эффект Данинга-Крюгера)
Прикрепленные файлы:
14. Азат_ 4 04.06.19 00:57 Сейчас в теме
Здравая и полезная статья. Спасибо Мария
MariaTemchina; +1 Ответить
19. Yashazz 2500 04.06.19 14:22 Сейчас в теме
Короче всю статью можно ужать до фразы "Расставлять точки над Ё надо до, а не в процессе и не после".
...а сколько внимания, сколько сразу плюсов...
21. Rustig 1172 04.06.19 17:33 Сейчас в теме
(19)
...а сколько внимания, сколько сразу плюсов...

я не психолог, просто человек со стороны - мне кажется у вас профессиональное выгорание - раз так реагируете на коллег.
вот статья в тему https://infostart.ru/public/988665/
Оставьте свое сообщение