Про видимую демократию

Про видимую демократию

Я недавно вскользь упомянул такой способ принятия решений, но он достоин большего внимания.

Вы наверняка такое видели или даже делали сами (я точно грешен): руководитель организует встречу для обсуждения какой-то проблемы. Но приходит туда с готовым решением или идеей. Или даже презентацией. Ну потому что ты же руководитель/снователь `— ты всегда должен знать, что делать дальше 🙂

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

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

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

Что с этим можно сделать руководителю? Во-первых, расслабиться и понять, что готовые решения никому не нужны. Не нужно пытаться быть самым сильным, смелым и умелым в работе с командой своих коллег. Командная работа не про это.

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

Три важных слова

ОБСУЖДЕНИЕ ПРОЕКТА ТОЛЬКО НАЧАЛОСЬ, И У РЕБЯТ ЗА СТОЛОМ ЕЩЁ МНОГО ОТЛИЧНЫХ ИДЕЙ. Но мне нравится та версия, с которой на встречу пришел я сам. Она мне кажется просто безупречной, и лучше придумать им явно не удастся. Так иногда бывает, что ты вроде участвуешь в разговоре, слушаешь доводы и аргументы, но внутри уже все решено. И ты камень. Скала. Какие бы ни возникали идеи, они для скалы как капли дождя. Как ветер или тонкий слой пыли. Снаружи могут покрыть, но внутрь проникнуть – нет. Благодарю всех, заканчиваю встречу и предлагаю перейти к реализации моего плана, предвкушая большой успех.

Чем старше мы становимся, тем больше разного нам удается делать хорошо. Быть разумными, надевать шапку, принимать спокойные решения и выбирать важное вместо срочного. А когда ты знаешь, что многое делаешь хорошо, легко стать заложником своего авторитетного мнения. И чем ты кажешься себе сильнее, тем сложнее сказать тебе три простых слова, цена которых может быть очень высока. Можно потратить уйму времени, ресурсов, поставить под угрозу людей, углубиться в самые дебри и запутать все окончательно. Лишь бы не расставаться с ней. Со своей точкой зрения, защищая ее любой ценой. И если ты только кажешься сильным, то, скорее всего, будет именно так. А вот действительно, есть ли сила внутри, узнать очень просто. Только сильный может сказать всем вокруг три важных слова: «Простите, я ошибся».


Это был фрагмент из письма Splat №152

Итеративный процесс в дизайне и инженерном творчестве

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

Итеративный процесс работы в проекте может быть сложным если не учитывать нескольких факторов:
— Желаемый результат, финальная функциональность и потребности людей должны изначально описываться в четырех группах. Обязательные, измеряемые показатели, устанавливаются заказчиком.
— Возможные, измеряемые показатели, параметры успешности и критерии заказчика ограниченные максимальными возможностями разработчиков.
— Конкурентные, зависимые от возникающих обстоятельств в процессе разработки и прогнозируемые как потенциальные, измеряемые.
— Коллаборативные результаты, факторы синергического влияния на результат возможных в процессе разработки объединений компетенций, реакция на контекст изменений в потребностях людей и возникновений новых условий и инструментов разработки.
— Необходимо оберегать и сохранять промежуточные проектные разработки. Итеративный процесс не исключает возврат к прошлым шагам, решениям и условиям и пересмотру «проектной истории»
— Важно сохранять единый список критериев и стандартов требований ко всем этапам итераций в разработке, не меняя критерии, или при изменениях стараться заново проверить прошлые версии решений на соответствие новым стандартам и критериям.
— Надо понимать, что итеративный этап разработки может при перспективной идее показать неудовлетворительный результат, но по возможной причине качества реализации замысла. Стоит уметь оценивать идею отдельно от этапа реализации и видеть как измерять и сравнивать разные характеристики. Два прототипа, один ориентирован на проверку самой идеи и ее барьеров и ограничений. Второй прототип проверяет качество реализации выводов после активного тестирования первого прототипа, но используя технологии близкие реальному производству.
— Команда разработчиков привычно проверяет и выносит независимые суждения по эффективности решения, если есть желание пойти на компромисс, пожертвовать функциональностью в целях материальной экономии, то для этого нужны веские аргументы целесообразности и компенсации недостатков опорными действиями. Ограничиваем функциональность, значит увеличиваем режим обучения, возможно объединяем отдельные действия в функциональные блоки.
Итеративный процесс разработки чувствителен к данным и наблюдениям. Сама разработка может повлиять на сам внутренний процесс работ и на методы, как и на трансформацию первичных требований и технических заданий, основываясь на возникающем постепенно понимании потребностей и инструментов реализации этих потребностей, как и возникающих рисках и вызовах.

Например, «ОКБ Сухого» Информационно-управляющее поле кабины самолета СУ-35 / Т-50 было разработано в нескольких вариантах в виде тренажера, прототипа геометрии кабины и интерфейса управления с обратной связью в среде купола виртуальной реальности, через который пропустили несколько сотен курсантов с летных училищ с типичными заданиями.

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

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

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

Как спрашивать «зачем»?

Как вы помните из заметки про фичреквесты, которые не стоит выполнять (https://t.me/pmdaily/98), вопрос «зачем?» — самый важный вопрос, который нужно задавать любому представителю бизнеса, который пришел к вам с задачей.

Однако задавать постоянно этот вопрос не так уж и просто: если в лоб спрашивать у каждого постановщика, зачем ему эта задача, он может и обидеться — к вам же пришли, оторвались от важных дел, подумали головой, а вы тут сидите с умным видом и объясняете, что делать ничего не нужно.

Вот пара трюков, чтобы процесс задавания вопросов пошел легче:

  • Объясните, чем вы можете помочь, имея это знание. К примеру, только вы знаете все уголки системы настолько, чтобы не пилить новую фичу, а предложить уже существующую похожую.
  • Поговорите про цифры: «Подскажи, какие показатели мы прогнозируем в результате?». Когда вы говорите про цифры и гипотезы, то вы находитесь максимально далеко от личности постановщика задачи, а значит ему будет спокойнее отвечать на ваши вопросы.
  • Расскажите, что понимая конечный результат, вы забираете на себя больше ответственности — если в конце спринта будет говно, то виноваты будете вы сами, а не тот, кто плохо поставил вам задачу. Для постановщика это выглядит как делегирование, а делегирование любят все менеджеры

Заметки на полях. Из психологии.

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

Общая формула: событие → [автоматическая мысль] → эмоция

П Р И М Е Р

Событие:
прилетает внезапная срочная задача

Автоматическая мысль, которую не замечаем:
«Я не справлюсь» (или «Я могу не справиться»)

Эмоция:
тревога

Примечание: этот пример максимально базовый, чтобы все могли попробовать его примерить на себя. Уровень тревоги в подобном примере обратно пропорционален опытности специалиста, так что, если вы занимаете middle+ позицию, то вспомните себя пару лет назад.

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

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

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

И понятно, что будет полезно уметь замечать и работать с автоматическими мыслями в обычной жизни. Если вам интересно чуть подробнее покопать для себя эту тему, то можете просто начать хотя бы со статьи на Википедии (https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D0%BC%D1%8B%D1%81%D0%BB%D0%B8), чтобы как-то сориентироваться. Понимаю, что источник не самый глубокий, но для старта может подойти.

И здесь хочется привести только опросник об автоматических мыслях Джудит Бек, который хоть немного может помочь поработать с автоматическими мыслями:

1. Каковы доказательства, поддерживающие эту идею? Каковы доказательства, противоречащие этой идее?
2. Существует ли альтернативное объяснение?
3. Что самое плохое может произойти? Смогу ли я пережить это? Что самое лучшее может произойти? Каков самый реалистичный исход?
4. Каковы последствия моей веры в автоматическую мысль? Каковы могут быть последствия изменения моего мышления?
5. Что я должен делать в связи с этим?
6. Что я мог бы посоветовать ___ (другу), который находится в такой же ситуации?

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

Иван Емелюшкин написал, что может предпринять дизайнер (не фрилансер), если у него кончились задачи.

1. Прошерстите продукт и найдите, что не так: кривая вёрстка, старые элементы интерфейса, плохой текст, иконки не подходят друг к другу, забыли про технические разделы или пустые экраны.

2. Залезьте в соседнюю область. Если работаете над приложением, обратите внимание на сайт, рассылку, печатку, рекламу или интерьер магазинов.

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

3. Сядьте с аналитиком или хотя бы Вебвизором, найдите проблемы и предложите решения.

4. Проведите пользовательское тестирование с опытными пользователями и новичками. Пройдитесь по основным и второстепенным сценариям.

5. Облегчите работу команде: создайте UI-кит или шаблоны для рекламных материалов, напишите словарь терминов или полноценные гайдлайны. Поговорите с командой, чтобы не сделать что-то ненужное.

6. Сделайте лучше жизнь в офисе: организуйте место для отдыха, запустите корпоративный мерч.

7. Заявите о себе: напишите статью, распишите кейс, опубликуйте работу в портфолио.

https://designpub.ru/67ac0a28a732