Роман Химов

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

Читайте далее »

Посмотрев на стандартную библиотеку C++, у меня появилась мысль попробовать решить ту же задачу средствами языка Го. У меня было время немного посмотреть на него, что-то понравилось, что-то так себе (это будет отдельной темой), было время прочитать ключевую работу тов. Хоара. Ну а чтобы лучше понять, как оно работает, неплохо бы попробовать что-нибудь сделать.
Читайте далее »

Выбранный в марте офис оказался в весьма оживлённом уголке города, на пересечении Лиговского проспекта и Обводного канала. В бизнес-центре, конечно, есть своё едальное заведение, но так как район перенасыщен разного рода кафе и ресторанами, я решил провести совершенно противоестественный для себя опыт — рискуя жизнью, попробовать обойти все заведения вокруг (где-то в радиусе 500 метров), где дают бизнес-ланчи.

Исключения получились только для одного японского заведения (там в стандартном наборе роллы, а я к ним с немотивированным подозрением (как и ко всему японскому, да)) и всяких американцев типа МакДональдса, КФЦ и Сабвэя, где я ничего съедобного для себя не вижу. Эксперимент закончился только ближе к концу мая, причём, на первом этапе повторялся я только с внутренним кафе самого БЦ, как правило, из-за погоды или других обстоятельств.

В итоге выяснилось следующее:

• стандартный обед может стоить любых денег от 180 до 380 рублей, но чаще около 200–250
• высокий ценник почти всегда способствует качеству еды, но количественно может работать и в обратную сторону
• количественное наполнение разнится сильно, остаться голодным после обеда вполне реально
• в заведениях с большими надписями «Шаверма» тоже бывает вполне съедобная пища
• некоторое количество заведений принцпиально не связывается с бизнес-ланчами
• не все китайские заведения одинаково полезны, раньше (совершенно немотивированно) мне казалось, что у китайцев плохо не бывает
• жизнь кипит, в мае мне довелось обедать в заведении, которое открылось десять дней назад, причём, показалось, что этот фактор даже способствует качеству еды
• все хорошие заведения, кроме одного, принимают оплату картами
• ПэйПасс систематически встречается только на фуд-корте ТРК «Лиговъ»
• тот же самый фуд-корт «Лигова» систематически (там заведений много) дороже окружающих где-то на 50 рублей, хотя рекордные чеки в 350 и 380 рублей остались совсем в других местах
• суп мисо — не моя еда
• блины с тяжёлой мясной начинкой — тоже (это я и раньше подозревал, но)
• в общем зачёте по совокупности показателей восточная кухня явно лидирует

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

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

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

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

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

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

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

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

С огромным для самого себя удивлением обнаружил, что бежится вполне себе ничего, нормально. Отмахал три километра без особого напряга. Через день повторил, и тоже хорошо. Через ещё несколько подходов даже несколько нарастил темп, и тоже вполне успешно, бегается хорошо.

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

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

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

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

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

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

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

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

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

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

Интереснее ситуация становится чуть позже, когда, например, нужно освоить велосипед. Объяснить что нужно делать для того, чтобы ехать, тоже практически невозможно, необходимо некоторое тонкое чувство баланса сопряжённое с работой телом и руками (ну ещё педали иногда покручивать полезно). Но практическая ценность всех слов приблизительно равна нулю, поскольку пока обучаемый не почувствует баланс, все слова бесполезны.

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

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

Конечно, барьеры могут быть не только физическими.

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

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

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

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

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

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

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