Делегирование в информационных системах

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

Про информационные системы (ИС) даже говорить не буду. Это наше все.

Но часто ли вы встречаете сценарии делегирования в ИС? Ну кое с чем вы наверняка сталкивались:

1. Имеются задачки (task) или баги, записанные на меня. Система позволяет перекинуть их на кого-то другого. Но это не делегирование в чистом виде, а скорее некий принятый workflow - например, руководитель группы является входной точкой для задач и ответственен за распределение их по исполнителям - это все-таки не делегирование.
2. Имеется ИС, в которой у меня широкий круг полномочий. На время отпуска я хочу часть из них переложить на своего заместителя. Я иду к админу, и мы вместе настраиваем полномочия заместителю. Самостоятельный доступ к настройкам полномочий в системах, как правило, закрыт. Так что после возвращения из отпуска мне снова придется пойти к админу и убрать выданные полномочия. Да, и кстати, все действия, выполненные им в мое отсутствие, будут записаны на него. Так что если он опубликовал в системе отчет, который я ему делегировал, его авторство может ввести кого-то в заблуждение... 

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

Некоторое движение навстречу делегированию предлагает SharePoint. Если вы админ своего сайта, вы сам себе голова и можете раздавать привилегии (правда, на постоянной основе), настраивать workflow для контроля поручений, а также настраивать пользовательские атрибуты, различающие ответственного и исполнителя... С легкой непринужденностью менеджер делегирует все эти хлопоты своему подчиненному, назначив его "админом" сайта. Так что мы все равно имеем ситуацию, как в п.2., но теперь у нас уже свой подчиненный админ, а не неподконтрольный субъект из другого департамента, обслуживающий нас в порядке живой очереди.

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

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

О юридической точности

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

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

Аналогичная тонкость с синонимами и определениями. Бывает, что легкомысленно, даже поэтически мы к ним относимся. Отсюда непонимание и просьбы переформулировать или переопределить.

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

Но умение писать  - это полбеды. В наш век массового графоманства гораздо более редким качеством является умение читать и правильно интерпретировать прочитанное. Это попросту незаменимо когда нужно:

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

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

О пеленках, в которых часто теряют младенца

Статья также опубликована в блоге UML2

Очень часто в моей практике при работе с требованиями их форме уделяется гораздо больше внимания, чем содержанию:

• В этом документе собраны требования ко всему продукту, а мне нужны требования только для моего компонента

• Мне не нравится порядок изложения, он непоследовательный с моей точки зрения

• Слишком много/мало диаграмм

• Не хватает связей / слишком много перекрестных ссылок и я не понимаю ваших стрелочек
• 100 страниц вашего документа для меня слишком подробно… введение на 2 странички - слишком общо, а подготовьте мне документ страниц на 30?
• Мы работаем в своей системе (в отдельном репозитории). Подготовьте нам требования, чтобы мы могли их туда загрузить.

Все эти вопросы могут быть одновременно заданы разными людьми к одному и тому же документу. О чем это говорит?

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

Все становится гораздо проще, если взглянуть на проблему под другим углом. Нужно разделить содержание и способы его отображения. Изменение способа отображения не должно вынуждать создавать отдельную копию содержания. Содержание должно быть всегда в единственном экземпляре, чтобы вы были уверенны, что внесенные вами изменения отобразятся во всех настроенных способах отображения. Что это нам дает? Это дает возможность настраивать отображение, удобное специалисту, независимо от отображений многочисленных заинтересованных лиц. Каждое заинтересованное лицо может получать тот вид, который ему удобен…  Что это все напоминает? Правильно, шаблон проектирования MVC (Model-View-Controller).  Чего нам для полноты ассоциации не хватает в этой схеме - это логики работы с требованиями - т.е. процесса согласования, внесения изменений и прочих событий жизненного цикла требования - которые тоже должны существовать независимо от представления и содержания.

Что помогло бы решить проблему и снять вопросы по форме?

• Инструмент, который позволит с содержанием в том виде, в котором это удобно его создателю. Я хочу создавать требования, не заботясь о том, удобно ли их читать. Пока я создаю требования, это не важно. Важно содержание.
• Когда я довольна содержимым, я начинаю задумываться, а как их будут читать. В этот момент мне нужно скомпоновать мое содержимое в тех видах, в которых его от меня ждут: упорядочить, сгруппировать, отфильтровать, сверстать в документ в конце концов. И это никак не должно затронуть мое содержание и не должно порождать независимых копий моего содержания.
• Далее предстоит задуматься о жизненном цикле требования. Этот жизненный цикл начинается с того момента, когда я впервые выпускаю в люди готовое и приведенное к нужному виду требование.  При этом жизненный цикл должен использовать настроенные на предыдущем шаге представления, а те в свою очередь  - то же содержимое, которое я создала на первом шаге. И жизненный цикл, также как и представления не должен порождать независимые копии содержимого (ну разве что некие baseline-ы, моментальные снимки требований, не претендующие на поддержку и развитие). Но это уже совсем другая история, и здесь я ее развивать не буду.

Вроде все просто и почти очевидно. Да? Удалось ли мне испытать полное соответствие всем описанным тезисам на собственном опыте? Пока нет. Зато удалось понаблюдать, как это часто выглядит в жизни.

 MS Word

 Как известно MS Word - текстовый редактор. Здесь идет речь о документе, а не о работе с информацией.  Ни один из описанных тезисов не выполняется: содержание неотделимо от представления. Тем не менее, как инструмент он работает во множестве практических случаев. Он есть у всех и все владеют им хотя бы на уровне Notepad.

• Когда это работает?
  
  • Вы работаете по жестко установленному формату представления (например, по ГОСТ);
  • документ имеет два состояния: в работе и согласован.
  • Все изменения после согласования оформляются в отдельном документе.

• Когда начинаются проблемы?
  
  • Когда форматов несколько (для заказчика и для проектной команды, к примеру);
  • когда изменения надо вносить постоянно. При этом  не спасает даже track changes - разные версии документа расходятся по членам команды и последняя версия может просто потеряться в них.
  • Когда документ превращается в набор связных документов с перекрёстными ссылками или в талмуд из нескольких сотен страниц - полноту, связность (трассировки) и непротиворечивость отследить становится нереалистично.

MS Excel

1й шаг к работе с информацией: атрибутируйте каждое требование по потребности, сортируйте, фильтруйте,  группируйте. Так же как Word, MS Excel есть у всех. Но уже не все владеют фильтрами и  сортировками, да и представление нельзя сохранить. Так что настройку удобного отображения придется переложить на читателя.

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

• Когда начинаются проблемы?
  
  • Когда жесткий формат все-таки требуют;
  • Когда важен автоматический track changes - в Excel он весьма странный.
  • И опять-таки мы не решили проблему размножения версий на компьютерах ваших коллег, даже при условии единого для всех хранилища для документа.
  • Excel не особо приспособлен для графики - так что если вы много работаете с графическими моделями - забудьте.

MS SharePoint

Вершина преданности решениям от MS; 1й шаг к работе с многопользовательской системой, а главное все 3 тезиса здесь наконец-то могут быть удовлетворены. О наличии готового решения для работы с требованиями мне не известно. Скорей всего придется заказывать решение или изобретать самостоятельно. В зависимости от потребности и изобретательности оно сможет покрыть многие и многие проблемы - от простых решений, использующих списки, до работы c MS Access, InfoPath формами и т.п.

• Когда это работает?
  
  • Все участники имеют доступ к системе и умеют с ней работать хотя бы на уровне чтения, поиска и фильтрации.
  • Специалист, способный "подтюнить" систему (администратор) находится поблизости и всегда может поправить или улучшить систему по потребности.
  • Вам привычно табличное представление данных, вы хотите сохранить достоинства Excel, и получить одновременно полную свободу работы со способами отображения - средствами самого Sharepoint, а также интеграции с MS Access, Excel, InfoPath.
  • Вы реализуете жизненный цикл требований с помощью workflow, что позволяет реализовать логику жизненного цикла требования.

• Когда начинаются проблемы?
  
  • Когда не все заинтересованные лица имеют доступ к системе (например, внешние заказчики).
  • Когда люди не готовы отказаться от документооборота и работать с отдельным требованием.
  • Когда нет специалиста, способного поддерживать и развивать систему.
  • Остается проблема неприспособленности работы с графикой. В лучшем случае вы сможете версионировать с помощью Sharepoint файлы, разработанные другими приложениями, но не более того.

Специализированные инструменты (Doors, EA, QC, ReqisitePro, Raven и прочие)

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

• Когда это работает?
  
  • Когда компания готова купить дорогостоящую систему и провести полномасштабное внедрение.
  • Все участники работают в единой системе (или хотя бы несколько систем автоматически синхронизируются).
  • Все участники обучены системе.
  • Процесс работы с требованиями стабилен и нет потребности к изобретению нового на лету.
  • Есть администратор системы.

• Когда начинаются проблемы?
  
  • Когда вы хотите купить коробочную программу, но не готовы менять свой привычный процесс работы;
  • Когда система куплена для одного отдела (например, для аналитиков и архитекторов), а остальные участники проекта работают по-своему;
  • когда инновационный проект требует исключения из правил.
  • Когда вы не готовы выделить специалиста для поддержки системы.

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

Есть ли требования за пределами IT?

Это размышления по следам RE10, конференции посвященной требованиям вне вопросов предметной области, где меня поразило то, насколько широко за рубежом применяются методики работы с требованиями.
Где в настоящее время в России работают с требованиями кроме IT? По крайней мере, если не считать стандартов, сертификатов соответствия и прочих внешних предписывающих документов? Запрос по словам "управление требованиями" возвращает только статьи, так или иначе связанные с программным обеспечением. И все.
И это похоже на правду, потому что некоторые повседневные примеры из жизни наводят на ту же мысль.
Как-то у меня на даче завелись кроты. Десятки неопрятных кучек на любимой клумбе. Рынок средств борьбы с кротами предлагает капканы, отпугивающие химикаты и электронные устройства. Капканы отпадали сразу, т.к. на полноценную охоту, ни сил ни времени. Каково же было мое изумление, когда я прочитала инструкцию к химикату:
Между имеющимися на участке соседними кротовинами (выбросами земли) сделать вертикальные вырезы до глубины хода. В вырез заложить по 5-7 г (1-2 столовые ложки) в каждую сторону хода слегка смоченные водой гранулы препарата. Сверху вырез закрыть дощечкой (или картонкой) и засыпать землей, пометить место внесения препарата. Через 2-3 дня проверить наличие его в норе. Если гранулы засыпаны землей или выброшены кротом из норы, следует расчистить ее и внести новую порцию. Обработку производить по мере необходимости.
Естественно, я купила электронные отпугиватели. Но кто изобрел этот сценарий и как он себе представлял реализацию?! Собирают ли производители обратную связь о своем препарате и как они с ней работают?
Однажды в одной компании завелись методологи (процесс-менеджеры). Десяток высокооплачиваемых сотрудников, которые должны использовать свой опыт для оптимизации работы остальных. Не скажу за всех специалистов, но с чем столкнулась я, было предписанием, в котором не было ни четких целей деятельности, ни условий, при которых эта деятельность осмысленна, ни альтернативных сценариев для необычных ситуаций. Создавалось впечатление, что создатели попросту не владеют ни одним из инструментов или техник анализа. Кого рассматривали авторы в качестве источника требований к выпускаемому продукту - себя, начальство, которому они сдавали документы, или сотрудников, которым по этим документам работать? И каковы последствия следования такому предписанию (хотя это уже совсем другая история)?
Ну и конечно же все стояли в пробках. Вопрос дорожного строительства - задача непростая. В ней задействованы тысячи инженеров по всей стране, существуют нормы, предписания, стандарты - в общем требования есть. Но как эти требования развиваются и как учитывают потребности потребителей? Ведь пробки - это ничто иное, как потребность, превосходящая предложение. Кто-то изучает, анализирует эту потребность? Управляет ею? Актуализирует на ее основе требования?
У меня нет пока ответов. Есть только вопросы и их становится все больше. По каким же правилам строится работа с требованиями и потребностями потребителей в отраслях помимо IT? Есть ли там вообще такая работа и как там принято называть ее и специалистов, в ней задействованных?  На конференции работу с требованиями называли инженерией требований. В IT эта работа часто прячется под должностью аналитика. По каким же ключевым словам искать родственные специальности в других отраслях? Ведь мы могли бы многому научить друг друга.
На конференции я слышала, что мировая инженерия требований насчитывает около 30 лет.  30 лет осознанной работы с требованиями в различных отраслях, 30 лет постоянного усовершенствования выпускаемой продукции в соответствии с потребностями и учетом удачно принятых ранее решений и совершенных ошибок. Даже видя этот опыт, этот путь быстро не пройти. Просто потому что это должно войти в привычку и стать частью работы не только специалистов по работе с требованиями, но и всей производственной линии. Но надо когда-нибудь начинать. 
Пост также доступен в блоге uml2

Более развернутый отзыв о RE10

Более развернутое изложение получилось в весьма неожиданном формате :)
Читайте в "интервью" на сайте uml2.

Информационная архитектура в Интернете

Примерно год назад читала книжку Розенфельда и Морвиля. Надо сказать произвела приятное впечатление. Довольно много интересной информации, примеров, хорошо структурировано. В общем, книга не противоречила тем тезисам, которые проповедовала.
После прочтения я даже набросала в качестве конспекта mind map диаграмму. Надо сказать, я убила не нее тогда полдня... Не уверена, что это эффективно. В то время я болела, и рисовать было приятно и отвлекало от простуды. Вряд ли что-то столь же аккуратное и кропотливое я способна повторить в здравом уме. Но тем не менее, наткнуться на эти труды через год было приятно, а главное довольно ясно напоминает о содержании книги, детали которой в моей девичьей памяти уже давно затянулись паутиной. (Чтобы прочитать содержимое, нажмите на картинку. Блоггер хорош всем, кроме ширины колонки для статьи)

 Схема, поясняющая содержание всей книги

Схема поясняющая определение тезауруса

Саморазвитие

Осилила еще один курс на интуите как дань моей любви к Шарепоиинту: Разработка приложений Web 2.0 на Microsoft Sharepoint :) Не сказать, что узнала что-то новое, все уже видела и щупала раньше. Но начинающим - вполне.

Полночные басенки

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


"Побелка черных обезьян"
Как известно, "Большая черная обезьяна – это самая лизучая и смышленая черная обезьяна", а еще ей разрешают спать под деревом. Самые смышленые и самые лизучие из больших черных обезьян стремятся залезть на дерево. Для этого они увеличивают штат своей плантации и выбирают самых крупных, смышленых и лизучих обезьян. - Теперь вы - большие черные обезьяны и и можете спать под деревом, а за то, что я поручила вам эту честь, вы подставите мне спину, чтобы я смогла дотянуться до ближайшей ветки дерева. Когда-нибудь вы сможете последовать за мной. - говорит большая черная обезьяна и лезет на дерево. Когда после многочисленных прыжков и приседаний ей удается добраться до ветки, она уже чуть-чуть белее, т.к. ствол и ветки дерева усыпаны мукой, осыпавшейся с тел белых обезьян. Забравшись на ветку, она старается сидеть строго под выше сидящими белыми обезьянами, чтобы мука с них осыпалась на нее. Если ей удается это достаточно долго, то она приобретает достаточно белый цвет, и белые обезьяны к ней привыкают. Но такая обезьяна еще долго не становится настоящей белой обезьяной. Если под такой обезьяной ломается ветка, то при падении с нее может слететь вся мука, и ей придется снова идти на плантацию черной обезьяной.

"Язык Настоящих Белых Обезьян"
Настоящие Белые Обезьяны разговаривают на собственном языке. Понять язык Настоящих Белых Обезьян могут только другие Настоящие Белые Обезьяны. Прочие белые обезьяны делают вид, что понимают язык Настоящих Белых Обезьян, т.к. иначе все заподозрят, что они никакие не белые, а совсем даже черные. Черные обезьяны не понимают язык Настоящих Белых Обезьян, простые черные обезьяны не скрывают этого, самые смышленые и лизучие черные обезьяны, мечтающие спать под, деревом стараются делать вид, что понимают Настоящих Белых Обезьян, и даже стараются говорить на их языке. И то и другое вызывает у белых обезьян раздражение, и они говорят - эти тупые черные обезьяны ничего не понимают и двух слов связать не могут, все, на что они способны - собирать бананы.

18th Requirement Engineering Conference

Волею вышних сил и благодаря феноменальному везению я попала сюда: http://www.re10.org/
Если получится, опишу подробнее, но пока впечатления таковы:

• довольно интересно, народец съехался действительно со всего мира. Правда, как показалось народец тот же съезжается на эти конференции регулярно. Пятеро представителей РФ из всего одной компании произвели фурор. Потому что русских на этой конфе не было никогда
• бОльшая часть докладов представлена в секции research и представляют их различные институты - т.е. это чистая теория или аспирантско-студенческие работы. Однако попытка придать некое наукообразие статьям вызывает уважение. Да, выборки у них пока не репрезентаивны и замеры произведены всего несколько раз в полулабораторных условиях, но мне кажется, что это правильное направление мысли. Это лучше, чем просто не делать ничего.
• Ряд докладчиков усыплял, но были и очень интересные и динамичные доклады. Возможно, одно из самых ярких впечатлений (и один из немногих докладов, содержащих картинки некоего результата помимо простого текста) оставил первый посещенный доклад о сборе требований через специальное приложение iRequre, разработанное для мобильника. Идея пока сыра, но подкупает интересными путями развития и возможностью потребителю самостоятельно сформулировать потребность в тот самый момент, когда она у него возникла - пока не забыл.
• В целом ощущения собственной ущербности не возникло - мега откровений не открылось,  обсуждаемые проблемы коррелируют с тем, что я видела на своем опыте. Все те же идут бои между теоретиками и практиками, между адептами agile и любителями формального подхода. Тем не менее, мировая инженерия требований развивается уже 30 лет и здесь встречаются люди, вращающиеся в ней около 20 лет, а это опыт и широта кругозора.
• Особый момент - конфа посвящена требованиям вообще. Не важно - софт, железо или строительство - принципы работы с требованиями одинаковы. НО!!! Снова и снова звучит тезис о необходимости скилов в предметке и о проблемах, вызываемых их отсутствием. Другими словами, узнав методологию работы с требованиями, ты узнал, что надо сделать, чтобы защитить диссертацию - очевидно, для защиты этого не достаточно :) 
• Организована конфа толково - большие перерывы для отдыха и общения, хорошие ланчи и кофе-брейки, два фуршета на 3 дня конференции :)  

Наблюдение о заменимости незаменимых

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

Шутки в сторону

— Говорят ведь юмор — он полезный, шутка, мол, жизнь продлевает.

— Не всем. Тем, кто смеется, — продлевает. Тому, кто острит, — укорачивает. Вот так вот.
х\ф "Тот самый Мюнхгаузен"

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

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

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

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

Юмор на работе полезен и это распространенное мнение. Чувство юмора как компетенцию измеряют, оценивают и делают частью профиля компетенций, как это сделал Микрософт. Но как относятся к шутнику в рабочем коллективе? Проявим воображение.

Хорошо ли иметь шутника в коллегах? С ним (ней) легко наладить общение и общаться, его (ее) речь скорей всего легкая для восприятия и живая. Он (она) может из-за шуток поначалу показаться поверхностным или несерьезным, и лишь время и дела покажут, чего он (она) стоит как специалист. И очень трудно примириться, что шутки и ирония порой проходятся и по тебе... но ведь можно отшучиваться.

Хорошо ли иметь шутника в начальниках? Почти как в коллегах. Вот только вопрос - можно ли иронизировать в ответ?! Но даже если нельзя, критика (т.е. обратная связь) в форме иронии наверное мягче, человечнее и больше заставляет задуматься, чем формальный отчет о плюсах и минусах в работе. 

Хорошо ли иметь шутника в подчиненных? Вот тут позиция может резко разниться. 

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

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

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

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

х\ф "Тот самый Мюнхгаузен

Инструменты

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