Право на «да», «нет», и «я так хочу»

Менеджерская херня.
Очень полезно в процессах и структуре принятия решений явно очерчивать, кто какими правами и возможностями наделён.
По этим трем пунктам особенно.

Какую проблему решаем:
— да как обычно, в толпе умных людей, кто принимает решение (какое) и несет за него ответственность (какую).

Потому что случаются ситуации, когда это ни фига не очевидно.

Когда случаются ситуации «не очевидно», а решение принимать надо, возможны следующие коллизии неприятные:

все потрындели, но решение не принято. Потому что итог и план работы — это ответственность и отдельное право в администрировании процесса. Никто не сделал = ничего никуда не поехало, крайних нет.
все потрындели и нашли возможные решения, но кто-то что-то в работу взял, а кто-то и не взял. Хорошо если хоть что-то полезное произошло (но не факт, что именно то, что нужно, и что важнее). Дальше потребуется отдельный чекап вида «а что там вообще происходит и до чего мы договорились», это затратно.
взяли в работу разные решения и модели. Вася и его команда решили, что будет так, Петя и команда ждут совсем другого (и нихрена не делают, т.к не поняли).
обсуждали хреновое решение, но никто не сказал «нет». Это хреновее, т.к люди дальше пойдут по (возможно) совсем неудачному пути, во что это выльется — как минимум в переделки, откаты и «думаем заново».
равновесные варианты, у всех свои плюсы и минусы, как обычно (и даже все с виду неплохие). Но решение принимать надо. Если его никто не примет, «ничего не делать» вариант проигрышный.

Поэтому очень неплохой идеей будет прямо прописать механики (например, в ключевых процессных документах), кто какими правами «на какие слова» наделён.

Понятно, что базовые права сказать «да, делаем», «нет, не делаем» и им подобные — имеют собственники бизнеса, например. Но вы к ним бегать точно не будете. Этот подход работает на мелкоте, но совершенно не скейлится. К совету директоров вы не набегаетесь.

Право на «да»

С ним достаточно просто: это аппрув, базовое подтверждение «делаем так» (и не делаем иначе).

Механизм получения аппрува («да») должен быть как минимум а) понятным б) оправданным — когда спрашивать надо, а когда можно и не спрашивать.

В чем могут быть непонятки:

а что, если человек который должен говорить «да», сейчас недоступен? Как поведет себя цепочка управления — эскалируется (вверх) или уедет на тактический уровень «решите сами» (вниз)?
что, если таких людей (или отделов, систем) несколько, как собирается консенсус? Достаточно ли одного «да», или вам нужно простое большинство, или вам нужно убедиться что нет тех, кто против — см про право на «нет»? Нужна ли эскалация?
кто должен узнать о принятом решении? В какие сроки?
как разруливаются пограничные случаи? Что важнее, скорость принятия решения, или уверенность?
есть ли уведомительный порядок «мы будем делать так, но можете успеть нас отговорить» — ?

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

Право на «нет»

Тут интереснее. Чтобы сказать «нет», нужно хотя бы понимать, в чем заключается «да». Какое решение принимали, чего приняли, какая модель последующей жизни для всех остальных.

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

В чем непонятки и подводные камни здесь:

как, и какие люди узнаЮт, что необходим их ревью, внешний поверхностный анализ? Кто им сообщит? Как они вовлечены в оценку решений?
ситуация «нет, и дальше что?» Если решение получает негативный отзыв, что должно происходить: требуется ли аргументация, обязательно ли предлагать альтернативы, кто их ищет, кто их рассматривает?
нужен ли кросс-ревью? достаточно ли одного «нет», или лучше собрать рабочую группу?
связаны ли «право на да» и «право на нет», это одни и те же люди? Если нет/разные (а так часто бывает), то как выстроена между ними коммуникация?
как разруливаются конфликты между «да» и «нет»? Обычно «нет» имеет приоритет, но: есть ли ситуация «делаем под свою ответственность, не получится расстреляем» — ?
всегда ли надо слушать «нет», или бывают кейсы экспериментов, которые могут этот подход игнорировать? Если бывают, то как это прописано?
есть ли у принятого решения «кнопка отмены» в будущем? См. право на undo. Если такой нет — возможно, ее стоит предусмотреть?

Право «я так хочу»

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

я хочу, чтобы в продукте появилась такая фича
я хочу, чтобы вот здесь работало вот так
я хочу, чтобы были достигнуты вот такие показатели за вот такие сроки
я хочу, чтобы вот такой херни больше не было
я хочу, чтобы люди вот сюда копали, а вот сюда не копали
я хочу, чтобы делали как нужно, а как не нужно — не нужно (ц)

Может, на этом этапе есть один человек с такими правами. Может — несколько. Может быть есть своя структура управления, когда (например) аналитики формируют фронт возможных задач, менеджеры и овнеры оценивают их со своих позиций, а решение по рабочему плану принимает (кто?) допустим, директор.

Какие подводные камни неплохо бы тут подумать и разобрать:

пересекающиеся и конфликтующие хотелки; кто отвечает за приоритеты, чье слово важнее и в какой ситуации. Например, owner может принимать решения с аргументацией от аналитиков, а директор может обойтись только мнением.
есть ли ревью, работает ли право на «нет» до хотелок, или после? (обычно, и там и там)
кто на каком уровне (и с каким ресурсным риском) может ставить хотелки в работу? Например, руководство отделом может ставить себе в работу штуки стоимостью в человеко-ресурсе до двух недель затрат, всё что больше — иди согласовывай (к кому и как?). Или, например, техническая группа может сама на тактическом уровне принимать решения стоимостью до $1000 затрат, остальное потребует эскалации — ?
где посмотреть, кто чего хотел: что стоит в работе на повестке дня, и кто это, собственно, «хотел» и когда?
где зафиксированы ожидания? Кто имеет возможность их править, корректировать, двигать по времени, дробить по составу, проверять итп — ?

Обычно к пониманию необходимости описанных «прав» компания/команда приходит с ростом и опытом.

Людей много, бардака много, коллизии (описаны в начале) наступают всё чаще.
Если задумаетесь заранее, то и граблей обойдете заранее. Ну, наверное.

Hope that helps.