June 23rd, 2004

vanity

Информационная архитектура, как проектирование опыта // М об ИА-в-контексте

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

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

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

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


  • Current Music
    Reverence — Faithless
vanity

Выбор музыки под запись // подчищенные контексты

Интересный вопрос возник у меня года полтора назад, когда я впервые осознала этот странный тренд в „автоматическом поведении“:

Часто ли вы подгоняете играющий в плеере трек под то, что вам бы хотелось видеть у себя в Current Music? Для уточнения, или напротив — затуманивания своей записи?

Например, играет у вас на фоне какой-нибудь там Мистер Малой или, не дай Аллах, микс диджея Грува на трек Легального Бизне$$а. А вы пишете тут такой полупанковский текст о МакДональдсе, который ну никак не вяжется с Грувом (у вас в голове не вяжется, на практике-то, может, ещё как вяжется). И вот вы залезаете в свою фонотеку, устраиваете „тыкание пальцем“, и выбираете уже куда более панковско-макдональдсовскую тему в виде Pink товарищей Аэросмитов. Врубаете её, жмёте в семаджике на Detect Music Now, и наслаждаетесь завершённостью образа своей записи, вплоть до мелких деталей — юзерпика, музыки, и, иногда, настроения.

У меня вот регулярно случается.


  • Current Music
    Reverence — Faithless
vanity

[ Q ] На речке, на речке, на том бережочке

На речке, на речке, на том бережочке,
Ой, мыла Марусенька белое платье.

Мыла Марусенька белое платье,
Она мылась, белилась, ой, говорила,
Ой, мыла, белила, с собой говорила.

Ой, приплыли к Марусеньке белые гуси:
«Ой вы, гуси, гуси – лазоревые очи,
Сколько хотите, то пейте, воды не мутите.
Сколько хотите, плывите, воды не мутите».

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

Первая строчка — один из самых сильных мемов советского времени (благодаря Евгению Леонову). Есть ещё один страшный мем „Светит месяц, светит ясный“, который достаточно услышать или прочесть, и потом не отделаешься, пока не перебьёшь чем-то другим, более мощным.

И ещё один, очень нудный мем — песня „Я готов целовать песок, по которому ты ходила“. Владимира Маркина пристрелить за неё надо (особенно за этот акцент на „-вать“, который и цепляет песню в память — все, кого спросишь, сразу же вспоминают текст, едва им про это „целовАть песок“ сказать).

Из подобных мемов, сидящих-в-голове-всегда, у меня вот только „Марусенька“ (которую, пожалуй, слышали все, кто знает меня больше недели в офлайне) и „Walking upside-down“ Жарра.


souloveme?

CEA об организации времени и жизни // непроэтосамленная сигара

Тезисы, извлечённые из двух больших комментариев centralasian об организации информации и времени.

  • [1] Требуемый большой временной фрейм можно заменить несколькими малыми. Это ускорит выполнение задачи. Разбивай на подзадачи.
  • [2] Наличие свободного фрейма не гарантирует творческого возбуждения, воодушевления или вдохновения. Не рассчитывай на стопроцентную эффективность „когда до этого дойдут руки“. Планируй с учётом этого, а значит — закладывай избыточное время на творческие муки.
  • [3] Обязательна информационная гигиена — чёткое осознание ограниченности ресурсов внимания, и дозируемое, осознанное их расходование. Концентрируй усилия.
  • [5] Короткие задачи выполнять быстро, не откладывая. Короткие тексты читать сразу, автоматически вытаскивая идеи и сразу решая, сохранить или выбросить контент-блок.
  • [4] Ментальные чек-листы для структурирования мышления помогают разложить нечётко оформленные данные „по коробкам“
  • [6] Зависшие проекты лучше завершать. Если есть хороший инструментарий архивирования-консервации, проекты можно замораживать.

Источник: 1 | 2. Здесь перепечатано в подчищенной и подправленной версии.


Сначала про "откладывание по потом". Это зверь известный, ловится он на разные мормышки. Сегодня я постараюсь половить его на "когнитивный подход". (Надо заметить, кстати, что я, несмотря на все мои юзерпики, ужасный когнитивист. Конечно, в связи с появлением подрастающего поколения, у меня происходит неизбежное "поправение" в сторону биологического детерминизма, но это, во-первых, у кого не бывает; а во-вторых — меня избыток мифов всегда беспокоит меньше, чем недостаток).

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

[1]

Например, одна из наиболее частых "ошибок мышления" при "откладывании" — убеждение в том, что сейчас на это у меня нет требуемого времени (скажем, Х), а есть только немножко (х); а значит, нечего этим заниматься сейчас, даже начинать не надо. А вот потом я ка-а-ак соберусь, как выкрою это искомое время Х и всё-всё сделаю (поиск времени обычно следует логике одной нашей знакомой — "я или сама заработаю как-нибудь, а если нет, то уж Бог поможет.")

Ошибка здесь в постулировании необходимости Х времени. "Мне, чтобы статью эту написать, нужна неделя, как минимум". Недели нет (никогда), поэтому и начинается бесконечное "откладывание." В ожидании недели.

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

Можно ли обойтись х? можно ли обойтись по х, но несколько раз? Можно ли это всунуть где-то между Y и Z? Да и много других решений можно найти, если поискать.

[2]

Следующая частая ошибка — мы думаем, что как только мы получим кусок времени Х, мы сразу сделаем замечательное (сложное, дивное) действие Q. И всё сразу будет супер-ништяк. (Например, сев-таки за статью, мы сразу и напишем нетленку; распланируем весь проект; выучим голландский, тоже "сразу").

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

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

[3]

Например, если выбирается решение "немедленной обработки информации" (на неспособность справиться с потоком информации кто тут только не пожаловался), то нужно сделать себе инструмент "мгновенного реагирования".

Для случая обработки информации "информационный объект" при попадании в поле зрения в идеале мгновенно оценивается и обрабатывается (рубрикуется, впитывается в собственную систему знаний) — и всё это за доли секунды.

[4]

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

Более сложный способ, который я часто использую для маркирования текстов (для записей юзеров в жж, например) — знаменитые журналистские 5 w (или 5+1) - who? what? when? where? why? + and so what? Сначала прогон "единицы анализа" через такой фильтр-чеклист происходит ужасно медленно. Но мозг — удивительная штука, очень скоро он научается делать всё "на автомате", быстро и незаметно. "Автоматизация высших психических функций".

Мне помогло, конечно, что нас в своё время на эти 6W ужасно насобачили, в Праге, в OMRI. Но многие другие инструменты я ставил себе и без внешней "школы". Чеклисты можно, разумеется, затачивать и под проекты, под "темы", которые интересны сейчас, или были (будут) интересны потом.

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

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

[5]

Дальше можно работать с ещё одной очень частой ошибкой — неким представлением о безразмерности, неограниченности, времени (и сил). Что, если вы можете отложить только пять статей/закладок на завтра? Строго? Зато сразу же начинается всё — и приоритизация, и "мгновенная отработка" того, что интересно, но "не очень", не настолько, чтобы расходовать целый "информационный патрон".

[6]

И последнее, про "закрывание". Везде пишут, что нужно научиться "закрывать" проекты, темы и тп, а то они так и остаются "висеть". Не знаю... Мне кажется, что такая вот "обязательность" закрывания — она тоже из области когнитивных сшибок. Да, в рамках некой темы (включая проект, например) иногда нужно "выдавать на гора результат" (отчёт, к примеру, или статью, или whatever). Но будучи "сделанным", проект не обязательно должен закрываться и выбрасываться. Можно ведь и "заморозить", и пустить в дрейф. То есть, дело в качественном архивировании (которое тогда качественное, когда хороши те самые инструменты — чеклисты, или что-то другое).

Как бы — пусть собирается пыль в углу, "сама по себе". А когда мне надо будет, я возьму и сделаю анализ комнаты по "самой собой накопившейся за дверью пыли."




  • Current Music
    Asian Dub Foundation - [Community Music #03] Officer XX
souloveme?

Консалтерский подход к штату исполнителей проектов против менеджерско-девелоперского

Любопытная деталь в проектной практике МакКинси:

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

Мне показалось сначала, что это ощутимо противоречит менеджерским техникам, описываемым Бруксом в „Мифическом человеко-месяце“. Это было бы логично — в разработке проектов речь идёт в первую очередь о проектировании, архитектуре и генерации конечного кода, с фазами проверок, отладки и ввода в строй, включая знакомство пользователей и некоторый entry-delay, с этим связанный.

„Перед консалтерами стоят задачи — как глобально, так и тактически — немного иного плана“, — казалось мне. — „Поэтому и подсчёт затрат, и командная работа там совершенно другие“ „Щас. Разбежалась.“, — стало мне ответом.

В McKinsey вы никогда не работаете в одиночку. Всё, что происходит в Фирме, связано с командной работой, начиная с работы на проекте и кончая разработкой и принятием решений о внутренней политике компании. Самая маленькая команда, в которой я когда-либо работал, занималась pro bono проектом для театральной компании из Нью-Йорка. С другой стороны, на проектах для некоторых крупнейших клиентов могут работать несколько команд, состоящих из пяти или шести консультантов, одновременно. Это своего рода „метакоманда“. В начале девяностых члены метакоманды, работавшей по проекту AT&T, решили собраться вместе. В штаб-квартире комании не нашлось достаточно вместительного помещения для всех, поэтому пришлось заказать зал в гостинице.

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

Объяснить можно только одним: доступные руководителю проекта люди изначально являются высокоэффективной интеллектуальной рабочей силой. Как это сказано в процитированных словах одного из менеджеров — „иначе бы они не были в McKinsey“.

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

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

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

 
 

  • Current Music
    Asian Dub Foundation - [Community Music #06] Collective Mode