О таланте

designsniper О таланте

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

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

Талант стремится делать иначе, искать с легкостью и упорством неожиданное и это ставит результаты его работы на одну плоскость восприятия с безумством и бездарностью. Видеть в необычном, странном, разноголосом талантливую суть, самостоятельный стержень — это умение. Надо воспитывать в себе это чувство «понимания непонимания».
Редкий талант успешен, он не умеет голосить о себе, не умеет объяснять, не умеет дергать за рукав. Не нужно хвалить, нужно верить. Доверять сложному. Помогайте талантливым умением слышать. Не отрывайте их пальцы от труда, не наносите ран осуждением — таланту не нужно много труда в физическом мире, но труд душевный, мыслительный, самоокапывание не самых плодородных тем и заданий — удел способных, одаренных и талантливых. Не отвлекайте талантливых от мысли — но становитесь их голосом, их личным чудом, вдохновителем. Становитесь стаей, коллективным пространством понимания, что все мы разные и роли наши только в взаимной поддержке, в взаимном импульсе.

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

Монокультура

Что думал в начале 2019:
- Все мы — люди. Мы живём в разных странах и говорим на разных языках, но во многом мы очень похожи.
- Дизайн во всём мире делается людьми для людей.
- Ещё Стив Джобс рассказывал после своей поездки в Турцию: «Весь день я смотрел на молодых людей в Стамбуле. Они все пили то же самое, что и все остальные дети в мире, и на них была одежда, которая выглядела так, как будто её купили в Gap, и все они пользовались мобильными телефонами. Они были как дети где угодно. Меня поразило, что для молодых людей весь мир теперь один и тот же. Когда мы делаем продукты, нет такой вещи, как турецкий телефон или плеер, который хотела бы молодёжь в Турции, и который отличался бы от того, что хотела бы молодёжь в других местах. Мы теперь просто один мир.»

Что думаю в начале 2020:
- Действительно, границы культур стираются всё сильнее.
- Например, хипстерские кофейни выглядят абсолютно неотличимо во всех городах мира: что в Нью-Йорке, что в Гонконге, что в Нижнем Новгороде. Поищите в Пинтересте "coffee shop interior" — всё одинаковое, нельзя даже предположить, где сделаны фотки.
- То же самое происходит с Airbnb (https://www.theverge.com/2016/8/3/12325104/airbnb-aesthetic-global-minimalism-startup-gentrification). Владельцы квартир всё чаще стремятся сделать стандартный «стильный» интерьер, который придётся по душе усреднённому современному путешественнику. Но это начисто уничтожает уникальные культурные особенности стран и городов.
- Впрочем, чему тут удивляться. Миссия Airbnb: Create a world where anyone can belong anywhere (в моём вольном переводе: «создать мир, в котором каждый может чувствовать себя как дома где угодно»). Но что если я хочу чувствовать себя как дома у себя дома, а в путешествии хочу чувствовать себя как в путешествии?
- Эта равномерная одинаковость вызывает у меня всё меньше оптимизма.
- Что уж говорить про дизайн массовых цифровых продуктов, у которых за редкими исключениями никогда и не было признаков культурной идентичности. Большинство в лучшем случае стремятся соответствовать трендам.
- Думаю, что маятник всё же качнётся в другую сторону. Нам бы только перестать бояться быть собой (http://t.me/desprod/463).
- Если бы сегодня снова записывал ролик для «33 слова о дизайне (https://bangbangeducation.ru/movie/33)», он получился бы уже немного другим.

Чинить баги по TDD

Один из кейсов, которые я рассмотрю на своём мастер-классе 26 октября (https://tdd.timepad.ru/event/1074439/?utm_source=telegram&utm_medium=messenger&utm_campaign=mypost-bugs) — это исправление багов по TDD.

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

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

Правильный процесс выглядит так: открываем контроллер в API, куда ходит кнопка, а дальше ставим под сомнение каждый нижележащий метод, проговаривая про себя гипотезы, к примеру: «я сомневаюсь, что метод get_users() не возвращает неактивных пользователей». Если сразу не находим теста, который доказывает обратное — пишем свой. Если тест падает — отлично, у вас уже есть тест, и остаётся только написать код. Если написанный тест не падает — git checkout --, и ставим под сомнение следующий метод.

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

После получения брифа и первичного общения с заказчиком мы отправились пробовать сервис на зуб.

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

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

Второе, что мы попробовали сделать — зарегистрироваться в качестве специалиста.

И у нас не получилось.

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

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

Но и это еще не все!

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

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

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

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

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

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

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

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

Парадигма навигации

Для навигации по приложению мы выбрали таббар. В 2018 году это выглядит очевидным, не было даже вариантов, что может быть по другому. Вопрос был скорее в том, какие пункты меню выбрать.

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

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

Окей, с навигацией разобрались. Теперь как понять, какие функции у приложения основные и что из них вынести в таббар? Можно пользоваться простой логикой — ради этой функции в таббаре я буду запускать приложение.

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

Почему я предпочитаю удалённую работу

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

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

За процесс, наоборот, спрашивать легко: опоздал программист на работу на 5 минут — значит сам виноват. Тупил во вконтосик в рабочее время — значит плохо работает.

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