Я сделал схему троллейбусов Петрозаводска:

У неё есть несколько плюсов, по сравнению с существующими схемами:

• надписи достаточно большие, чтобы было видно на карманной формате A5, и на форматах A4 и A3 в троллейбусах;
• впервые решена проблема с пониманием того, как идут троллейбусы в районе вокзала;
• отмечены автобусы в районы, в которые троллейбусы не ходят.

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

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

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

Остановки, которые находятся в зоне видимости помечены одним пеньком, а те, которые чуть дальше — разными, с указанием направления движения.

Процесс создания.

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

Образование и среда.

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

Меня, бывает, спрашивают о том, как что-то реализовать, когда элементов очень много.

Например:

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

или

На странице отображаются 5 000 товаров с партиями, остатками, необходимо изменять эти данные. Что бы вы стали делать, если бы страница стала тормозить? Как бы вы искали источник проблемы?

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

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

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

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

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

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

• Опросить мнение у всех участников
• Придумать лучшее решение, учитывающее это мнение
• Рассказать о нём, услышать возражения, но только один раз
• Претворить решение в жизнь
• Нести ответсвенность за последствия решения и менять его при необходимости

Здесь не нужна какая-то формальность в пунктах и последовательности, нужно просто примерно понимать процесс.

А у всех других ребят остаётся право сменить этого человека на другого, если что-то раз за разом не нравится.

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

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

P.S. На всякий случай отмечу, что я много раз был как и тем, кто принимает решения, так и тем, к мнению которого просто прислушиваются.

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

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

Обычно до разработчика доходит какая-то такая задача:

«Необходимо создать страницу с отображением всего списка свидетельств, с возможностью изменения набора столбцов и фильтров. Изначальные наборы столбцов такие-то, наборы фильтров такие-то. Обеспечить разный уровень доступа для разных пользователей, возможность создания и подписания новых документов, выгрузки в EXCEL, XML, CSV, PDF, Word сохранения истории изменений. Ктопку такую-то разместить здесь, такую-то здесь, вот эту сделать зелёной. Набор полей документа формируется с учётом ФЗ № такой-то такой-то, ...»

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

Разработчику говорят, что делать, но не говорят, почему. Нет ответов на следующие вопросы:

• Почему мы вообще это делаем? Какую проблему заказчика мы решаем?
• Зачем нужна возможность изменения набора столбцов и фильтров?
• Что значит разный уровень доступа? Кто вообще будет этим пользоваться и в каком случае?
• Каким образом должна быть реализована подпись? Физическим ключом в USB? Паролем? Электронной подписью?
• Что значит «отображение всего списка свидетельств»? Сколько их всего? А если несколько миллионов? Вы уверены, что кому-то нужно сразу видеть миллион свидетельств за несколько лет?
• Выгрузка миллионов записей из БД с внешними ключами и данными из других таблиц и форматированием в каком-то формате займёт очень много времени и сильно нагрузит базу. Существует ли реальный сценарий использования этой функции?

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

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

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

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

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

Короче, Варламов топит за мангал в каждый двор, а я буду топить за турник и ровную площадку в каждый двор.

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

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

А ещё в подъезде нужно между 4 и 5 этажом турник на стене повесить на зимнее время.

P.S. За картинку спасибо Рите.

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

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

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

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

Но есть и следующий этап.

Даже если ты выработал навык, но стал снова на новом уровне задумываться о том, как именно это делать, ты можешь снова потерять возможность играть или говорить.

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

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

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

У него есть мои контакты, но он ни разу мне не писал. Конечно, он может спросить что-то у коллег, но и они говорят, что он не так часто это делает.

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

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

Я задумался. К тому времени у нас была очень простая система прав. У нас было что-то вроде 7 разделов и если кто-то имел доступ к разделу, то мог делать в нём всё. Теперь требовалось сделать так, чтобы для разных пользователей были доступны или нет конкретные действия и кнопки: просмотра, редактирования, удаления.

Но были и плюсы:

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

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

И пошёл в отпуск.

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

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

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