Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Время подумать

Taking Time to Think

Оригинал статьи находится тут.
www.randsinrepose.com

Ланч в «Доне Джованни» с Филиппом. Он перевозбуждён. Мы ещё даже не видели официанта, а он уже расчистил стол и яростно чертит какие-то каракули на белой бумажной скатерти.

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

Я киваю, наблюдая, как каракули становятся всё более неразборчивыми. Я бы купил Филиппу бокал Кьянти, чтобы охладить его, но он мормон, поэтому я попробую правду.

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

Фил, для того чтобы создавать, надо думать».

РЕАГИРОВАТЬ или ДУМАТЬ

Почему вы не можете думать, когда вы заняты?

Глупый вопрос, не правда ли? Ответ: «Я не могу думать потому, что я занят.»

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

Пример. Вы входите в мой офис и начинаете вопить: «Рандс, до поставки осталось два дня, а мы только что нашли ужасный критический баг. Что нам делать? Мы в заднице?»

Я отвечу, и мой ответ будет выглядеть как результат размышления, но я не делаю ничего оригинального, потому что я имел дело с этим сценарием «критический баг за два дня до поставки» В КАЖДОМ ПРОДУКТЕ, КОТОРЫЙ Я КОГДА-ЛИБО ДЕЛАЛ. И каждый раз выживал. Была парочка отличных историй. Именно этот опыт я использую, когда вы входите в мой офис и сообщаете, что небо падает на землю. На самом деле я не делаю ничего нового, я всего лишь говорю вам, как я починил небо в прошлый раз.

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

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

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

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

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

НАЧИНАЕМ

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

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

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

УЧАСТНИКИ

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

Кого пригласить? Сложный вопрос. Если вы пригласите всех и каждого человека в команде, вы ничего не добьётесь... даже с лучшим в мире ведущим. Вам следует начать малым составом для придания начального импульса. Тут вы можете поначалу расстроить людей, потому что каждый хочет участвовать в этом собрании, потому что у каждого есть своё мнение. Если у вас есть представление, какими могут быть первоначальные темы для обсуждения, пригласите тех, кто, по вашему мнению, разбирается в вопросе. Если вы понятия не имеете, с каких тем начинать, бросьте монетку... выберите случайным образом. Никогда не знаешь, что может оказаться в головах у инженеров. Хорошая новость в том, что смена участников является одним из лучших признаков продуктивного процесса дизайна. Больше об этом чуть позднее.

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

СОДЕРЖАНИЕ

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

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

Когда вы таки дойдёте до моделей и прототипов, делайте их лёгкими и лишёнными деталей. Если идёт третья неделя, а команда спорит, какую иконку куда лучше поместить, вы слишком далеко зашли. Я сторонник использования каркасов, если дело идёт о визуальном проектировании приложения. Каркасы описывают геометрию идеи, но не навязывают «look and feel».

ЭТО РАБОТАЕТ?

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

Хорошая работа. Действительно.

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

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

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

КОГДА ОСТАНОВИТЬСЯ

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

БОРИТЕСЬ С ЗАСТОЕМ

Компания Google знает, что время для раздумий необходимо. Ходят слухи, что они просят своих работников проводить один день в неделю, работая над своими собственными проектами. Подсчитайте. Google инвестирует 20% инженерного бюджета в обдумывание. Я уверен, что из большинства этих проектов не выходит ничего, но Google выигрывает дважды от этой программы. Во-первых, некоторые проекты приносят пользу компании. Вероятно, это один из пяти, но это не главная польза. Google создаёт культуру обдумывания, позволяя своим работникам беспорядочно бродить и влезать в дерьмо.

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

Удачи.

30 августа 2005 г.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



3 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Перевел неплохо, только фраза «Первое — это мозговой штурм, а второе — посвящено прототипам» — явно зевгма (типа «Шли два студента и дождь. Один в пальто, другой в университет, третий в осенний вечер»).Не согласен с мнением о бесполезности статьи, есть на что обратить внимание — парочка моментов навскидку: — «наиболее подходящее время для инициации процесса глубокого обдумывания — сразу после большого релиза» — вы это делаете? — «по мере того, как проходят недели, вот несколько вещей, на которые можно обратить внимание» — приводится готовый чек-лист, а у вас он есть? Короче, по мимо общих рассуждений чувак делится практическим (!) опытом. Без обид — если вам нечего взять из материала, не значит, что там ничего и не было;)

О чем эта статья? О том, что разработка — это не только кодирование? Ну так достаточно посмотреть требования на ЛЮБУЮ вакансию разработчика, и прочесть название скила «аналитический склад ума»...Зачем писать целую статью про очевидные вещи?

Підписатись на коментарі