Почему "камбан", или краткое введение в японскую письменность

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

Слоговая азбука японского языка

Как многим известно, японское письмо - иероглифическое, оно имеет название "кандзи", и в нем один символ, как правило, соответствует целому слову (или, по крайней мере, лексической единице). Однако, помимо иероглифов в японском есть и азбука, которая называется "кана" и, в отличие от привычных нам кириллицы и латиницы, является слоговой. Это значит, что каждый знак (буква) в ней соответствует не отдельному звуку, а целому слогу. Примеры: ва - две буквы, два звука - [в] и [а], соединенные в слог [ва]; ワ - тот же самый слог [ва], те же два звука [в] и [а], но изображается одним знаком.

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

Системы транслитерации

Слово "камбан" имеет в японском два смысла. В первоначальном значении - это магазинная вывеска, шильда, и в этом случае оно записывается с помощью кандзи (как на картинке вверху). Привычный нам камбан из сферы управления проектами японцами всегда записывается катаканой: カンバン. Этим подчеркивается, что значение слова отличается от первоначального. Кстати говоря, работники Тойоты записывают слово исключительно хираганой: かんばん, и никогда такое написание не применяется за пределами компании. Ниже я буду обращаться к варианту с катаканой.

Давайте внимательно посмотрим на само слово. Буква ン в нем повторяется дважды. Лингвисты называют ее "мораическое н" (не спрашивайте у меня, что это значит), и это единственный слог каны, который состоит из одного согласного звука. В большинстве ситуаций он похож на наш звук [н]. Выходит, что "канбан" - правильный вариант, а я просто себе что-то придумал? Не совсем так. Да, в большинстве ситуаций ン действительно звучит как [н], но не во всех.  Дело в том, что перед согласными [б] и [п] эта буква произносится как [м]. Если вы занимались японскими боевыми единоборствами, вам должно быть знакомо слово "сэмпай", в котором присутствует та же самая буква ン. На Ютубе есть видео, в котором японец объясняет произношение слова "камбан", и слышно, что он произносит слово именно через [м].

Возникает логичный вопрос, откуда же взялся "канбан"? Во всем виноваты системы транслитерации. Существует несколько вариантов транслитерации японского латинским алфавитом, самый популярный из которых - система Хэпберна. Он встречается повсеместно, даже в Японии, хотя и не является стандартом. Именно по системе Хэпберна слово "камбан", записанное латиницей, будет выглядеть как "kanban".

Что же в русском?

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

К слову сказать, подавляющее распространение системы Хэпберна, вызвано, скорее, историческими причинами (оккупацией Японии Штатами после Второй Мировой), нежели лингвистическими. Поэтому я бы не рекомендовал на нее ориентироваться вообще.

Так как будет правильно?

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

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

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

Личное планирование с помощью камбана, Скрама и Trello

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

Основные принципы

Идея системы возникла благодаря Trello - сервису "организации всего". В основе сервиса лежит обыкновенная доска-камбан. На доске можно создавать сколько угодно списков (столбцов), а контроль процесса сводится к перетаскиванию карточек из одного списка в другой или вверх-вниз по списку (удобный drag-n-drop прилагается). Сервис похож на многие другие инструменты планирования, но с той лишь разницей, что он не перегружен излишней функциональностью. Предельно просто и крайне удобно. Вдобавок, он доступен на любой платформе, включая мобильные, и бесплатен (платные функции вам точно не понадобятся, они ориентированы на корпоративное использование).

Я сформулировал для себя несколько ключевых правил, которые позаимствовал из некоторых известных техник Agile:

1. Единый бэклог для всех задач. Размер, тип или важность не имеют значения.
2. В начале дня задачи на текущий день переносятся в список "Сегодня".
3. В конце дня все незавершенные задачи отправляются обратно в бэклог, все завершенные попадают в "Done".
4. Любые идеи, которые могут стать задачами, фиксируются тут же на доске. Для это существует специальный список "Котел".

И добавил несколько исключений:

1. Только задачи, которые растягиваются на несколько дней, могут оставаться в "Сегодня" в конце дня, тем самым напоминая мне, что я над ними активно работаю. Их, как правило, не больше одной одновременно.
2. Для долгосрочных проектов по мере необходимости создаются отдельные задачи наподобие "Работа над проектом, 3 часа".
3. Для выходных удобно иметь дополнительный список "Завтра". Он упрощает планирование сразу на оба дня, которые можно рассматривать как единый интервал времени. 

Пример доски для личного планирования

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

Замечания

Пожалуй, стоит вкратце пояснить, почему система оказалась для меня достаточно эффективной.

Удобный интерфейс побуждает к использованию

Удобство интерфейса и доступность Trello сыграли не последнюю роль в создании моего способа планирования. Раньше я пытался использовать для этих целей Evernote, OneNote, Outlook и Гуглокалендарь. У каждого из них были свои существенные недостатки. Бумажный блокнот я даже не рассматривал: я практически никогда не заглядываю в свои записи второй раз.

Бэклог продукта © www.informit.com

Бэклог

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

Сегодня

По сути, это бэклог спринта длинной в день. Вечером я перетаскиваю задачи из бэклога в To do, примерно прикидывая, что я успею сделать завтра.

Done

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

Долгосрочные задачи

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

Крупные проекты

Здесь тоже все максимально просто. Когда я считаю, что пора уделить проекту внимание, я просто создаю задачу в духе "Работа над проектом, 3 часа" и добавляю ее в бэклог на общих основаниях. Когда я берусь за эту задачу, я включаюсь в проект, и если для него ведется отдельное планирование, пользуюсь уже им.

Все в одном месте и под рукой

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

Все без исключения

Я добавляю в бэклог абсолютно все: бытовые дела, рабочие вопросы, личные проекты - все, что требует хоть малейшего усилия воли, чтобы начать это делать. Отчасти, я делаю так из-за предыдущего пункта. Отчасти, потому что я пришел к выводу, что гораздо проще и эффективнее приоретизировать общий список, не разбивая его на части. А отчасти, потому что на силу воли полагаться нельзя вообще ни в чем. Более того, когда я вижу в конце дня в Done список из 5-6 задач, пускай даже некоторые из них были не особенно важны, это помогает мне формировать привычку воспринимать себя как человека, способного к действию.

Скрам: "это не то, что ты думаешь!"

Поводом к написанию поста стал недавний спор с коллегой о том, отличаются ли доски в Скраме от камбана. Для коллеги оказалось сюрпризом, что в Скраме нет ничего про доски.

Цена простоты

Когда простота может быть сложной

Agile вошел в моду, можно сказать, стал мейнстримом. Сегодня даже статистика на стороне гибких подходов, и все хотят себе в проект волшебный Скрам. Это привело к тому, что вокруг него сложилась странная ситуация: простота и, как следствие, популярность играют с ним злую шутку. Скрам продемонстрировал, как простыми методами можно решать сложные задачи. В этом его очевидная заслуга. С другой стороны,  появились "специалисты", которые восприняли это как право заявлять "я все знаю", всего лишь прочитав пару статей в Интернетах (многие из которых написаны такими же "специалистами"). Очень часто я слышу, как люди обсуждают Agile, путая его со Скрамом, при этом и о том, и о другом имеют весьма туманное представление.

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

От философии к реальности

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

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

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

Myth Busted

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

Скрам - каркас, а не полновсеная методология.

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

Скрам содержит только самое важное.

Ничего лишнего

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

Цель Скрама - продуктивность и прозрачность

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

Самое известное о Скраме вообще не Скрам

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

В заключение

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

Напоследок, в поддержку моего мнения то же самое, но более кратко, словами Алистэра Коуберна.