Решил не переводить, а образовать составное слово, которое очень напоминает названия культовых игр Warcraft и StarCraft — тёплые воспоминания о детстве. TaskCraft — сокращённо от task crafting: изменение задачи, ремесло задачи или придумывание задачи. Однозначно перевести сложно.
Забавно, что craft — это дословно ремесло, то есть что-то связанное с ручным трудом. При этом «ремесленничество» в искусстве — это часто работа по шаблону, отсутствие творчества, что в корне конфликтует с тем, что я собираюсь написать ниже. Но давайте обо всём по порядку.
Знаете это чувство, когда ты занимаешься одним и тем же долгое время и оно тебе приедается: хочется чего-то нового, новых вызовов, новых изменений, новых декораций. Кажется, что живёшь в дне сурка. Это чувство испытывает подавляющее большинство людей. В подобных поисках люди иногда доходят до радикальной смены деятельности и профессии в целом. Они меняют локации, города, страны, семьи, хобби. Это называется поиском себя.
В этом году у меня 16-й год опыта в коммерческом программировании — прошлый год был юбилейный по человеческим меркам, этот по битовым. При этом непрофессионально я начал гораздо раньше. Сейчас я решил написать гораздо больше текста, чем год назад.
Я всё ещё пишу ручками код, а не спускаю задачи на подчинённых (уже, конечно, меньше — «благодаря» ИИ-агентам; говорят, скоро они и вовсе отберут у меня это прекрасное занятие, но всё же). Я так и не стал фуллтайм-менеджером, не стал CTO, не ушёл из найма, не сменил профессию. Нет, я всё так же на проектах «крашу кнопки» и «собираю формы» программным кодом. И хотя уровень вовлечённости, влияния на продукт и «большой картинки» сверху менялся, в своей сути я продолжаю заниматься тем же, чем начал заниматься много лет назад.
Изменение работы
Я рефлексировал на тему того, что позволяет мне так долго заниматься одним и тем же без потери интереса к делу, и пришёл к выводу, что я очень давно уже использую технику — или даже правильнее подход, — который учёные в области психологии называют task crafting. Я всё время использовал это бессознательно, долгое время не знал, как это называется, и в целом не видел этой формы, пока не попал на один из семинаров в одной из своих бывших компаний. Тогда-то пазл у меня и сложился.
Крафтинг задач — один из терминов более широкого понятия job crafting, что примерно переводится как «изменение работы»: процесс проектирования своей деятельности, как правило инициированный самим работником снизу вверх, эдакая проактивная стратегия изменения характеристик работы для лучшего соответствия личным потребностям, целям, ценностям и предпочтениям.
Термин уходит истоками в работу двух учёных, профессоров Эми Вржесневски и Джейн Даттон, в начале 2000-х. Они изучали, почему одни сотрудники воспринимают свою работу как «каторгу», а другие находят в ней смысл и вдохновение, даже выполняя похожие задачи изо дня в день.
И тут умные люди выделяют три основных подхода к тому, чтобы работа приносила удовольствие и счастье:
- Task crafting (изменение задач) — изменение типа, объёма, последовательности и количества задач, составляющих работу. Работники могут проявлять инициативу, изменяя выполняемые ими задачи, способ работы или даже сроки выполнения. При этом работники осуществляют определённый уровень контроля над своей работой, чтобы минимизировать негативные чувства (например, отчуждение от непосредственной прямой работы) или общее время, чтобы успеть к дедлайну.
- Relational crafting (изменение отношений) — изменение характера взаимодействия на рабочем месте с другими людьми. Например, сотрудники могут выбирать, в какой степени и как они взаимодействуют с коллегами или насколько участвуют в групповых социальных мероприятиях (митапы, тимбилдинги, корпоративы, small talks и coffee talks и т.д.).
- Cognitive crafting (когнитивное изменение) — изменение восприятия своей работы с целью придания ей большего смысла. Например, работник может постоянно переоценивать, как работа влияет на него и насколько он с ней связан. Это может включать в себя рассмотрение наблюдений на работе и оценку того, насколько эти наблюдения соответствуют личным целям, идеалам и увлечениям.
Я бы хотел поговорить именно про изменение задач. Подходы изменения отношений и когниций — интересная тема, они тоже имеют место быть, но пока мне тяжело их отрефлексировать и добавить сюда, в продукт моего графоманства. Я обязательно сделаю это позже, а пока…
Вообще, я не очень силён в матчасти всей этой концепции — дальше одного семинара и Википедии я не ходил, — но, как оказалось, я хороший практик. Поэтому мне проще пойти и рассказать про очень конкретные примеры моего личного крафтинга задач, которые, на мой взгляд, помогли мне не «остыть» к ремеслу и профессии в целом, не быть «кузнечиком», который прыгает по работодателям за прибавку в несколько сотен долларов, а кое-где и повлияли напрямую или косвенно на всю мою карьеру.
Я прошу прощения, что текст ниже будет достаточно плотным из-за ностальгических и исторических вставок и очень конкретных и личных деталей моей карьерной и профессиональной кривой, но для полноты картины и передачи настроения мне важно всё это зафиксировать.
Примеры моего крафтинга задач
Тестирование и тесты
В 2010 году в поисках прохождения практики во время учёбы в колледже на специальности «программное обеспечение информационных технологий» (ПОИТ) я попал в местную ИТ-компанию, и, к моему везению, помимо обычного подписания практики мне предложили полноценно трудоустроиться — у компании как раз была открыта вакансия. Восторгу не было предела: я буду работать в настоящей ИТ-компании, не сисадмином в поликлинике или школе (при всём уважении к сисадминам), а там, где занимаются настоящей разработкой ПО, — это была прям мечта. Вот правда, вакансия была не про разработку, а про тестирование. Мне предложили стать тестировщиком, и я, не думая, согласился.
И буду честен: на тот момент я вообще ни черта не знал о том, что такое тестирование ПО и что должны делать тестировщики. Нет, на верхнем концептуальном уровне я вроде понимал — из той же индустрии компьютерных игр, бета-тестеры и всё такое, — но конкретики и деталей в голове совершенно не было.
Когда ты молод, тебе всё интересно: сама среда интересна, и то, что ты в ней. Я достаточно быстро преисполнился. Как и многие в то время, я быстро прочитал книгу Романа Савина «Тестирование Дот Ком» и даже написал на Borland C++ себе какую-то десктопную утилиту, которая помогала мне оформлять красивые багрепорты в отвратную систему трекинга большого интегратора КРОК — на тот момент одного из главных клиентов той ИТ-компании.
Как вы уже поняли, 99% моего рабочего времени занимало ручное тестирование. Это были системы электронного документооборота с витиеватыми жизненными циклами различных типов документов, написанные тогда на Java 6 и малоизвестной платформе EMC Documentum с DQL — диалектом SQL.
Всё было отлично, кроме того, что я всегда видел себя разработчиком, а не тестировщиком, — но сложилось как сложилось. У меня была лёгкая белая зависть к отделам, где ребята писали код. Я чувствовал себя во втором эшелоне, не в первом — опять же, при всём уважении к тестировщикам. Но при этом всегда честно и ответственно выполнял свою работу.
И всё же, если бы всё так дальше продолжалось, я определённо заскучал бы. Сменил бы компанию или ушёл бы куда-то в другое место — сложно сказать. Но вещь, которая меня удержала, — это автоматические тесты. Это и было моим изменением работы, моим крафтингом задачи.
Как завсегдатай software-testing.ru в то время, я быстро схватил тренд: все смотрели в сторону автоматизации. А там была Java, Selenium RC (первая реализация этого инструмента) и настоящее программирование со своими шаблонами вроде Page Object.
Я начал потихоньку изучать тему и программировать тесты на работе, параллельно занимаясь ручным тестированием на своих непосредственных рабочих проектах. Так профессия тестировщика заиграла новыми красками и уже не казалась скучной или «вторым эшелоном». При этом надо уточнить, что в самой компании автотесты были чем-то очень далёким: их не было на тот момент ни на одном проекте, и вообще это было что-то новое и неосвоенное, из модных статей на форумах, но не из реальной жизни на периферии.
В какой-то момент я решил провести небольшой митап для руководителей и команды на своём проекте — на тот момент это уже была система по работе с корпоративной документацией на основе стандарта DITA для корпорации SAP. Я показал end-to-end тесты, которые написал на Selenium RC (тогда все они строились на XPath из бесконечных цепочек div-контейнеров), и продал идею, что ручной регресс можно сжечь автоматизацией. Руководитель дал добро на то, чтобы я официально занялся покрытием основных сценариев, — и так программирование и автоматизация стали уже моей официальной работой, а не невидимым крафтингом задачи.
Мне даже выделили место в SVN рядом с кодом проекта. Ну и фактически я был первопроходцем и инноватором в части автотестов в той компании.
Позже автоматизация стала неотъемлемым атрибутом всех крупных проектов, а у тестировщиков появилась отдельная карьерная ветка с названием SDET.
В какой-то момент мой отдел объединённых сисадминов (тогда не было DevOps-инженеров даже как термина: людей, которые занимались настройкой Oracle и написанием Ant-конфигов, называли сисадминами наравне с теми, кто переустанавливал ОС и приносил тебе мышь с клавиатурой при приёме на работу) и тестировщиков созрел к тому, чтобы разделиться на два — QA и SA.
Это был примерно тот самый момент, когда умер Стив Джобс. Хорошо помню тот день: мы все ходили с коллегами чаёвничать и обсуждали, что будет с яблочной корпорацией и нашим отделом.
Перед нами стоял выбор: пойти либо в один — QA, либо во второй — SA, а я захотел в третий. Я подал заявку перейти в отдел разработки на Java. Да-да, этот первый эшелон всё не давал мне спокойно спать. К этому времени благодаря программированию Selenium-тестов я был уже достаточно уверенным в Java и защитил диплом, где кастомизировал Eclipse RCP под систему учёта и трекинга ошибок.
Но, надо сказать, начальник отдела разработки так просто брать меня не спешил: меня заставили пройти полноценное интервью с тестовым заданием. Вот так вот, никаких поблажек.
В качестве разработчика я оказался на проекте, который раньше тестировал, а моей первой задачей было прикрутить BIRT-отчётность.
Но очень быстро меня перевели на проект концерна Daimler — систему менеджмента пользователей. Я плохо помню доменную область: тогда это было не то, что у меня в фокусе, но это были таблицы в таблицах и редактирование их же. Как оказалось, я был идеальным кандидатом на этот проект. И вот почему.
Там был настоящий фулстек (тогда такого слова не было, по крайней мере в наших широтах). И я не про бэкенд + фронтенд, хотя отличительной чертой клиентской части был популярный на тот момент стек jQuery: jQuery UI, jQuery Mobile и QUnit.
Погружаясь в автоматизацию в браузере, мимо JavaScript было невозможно пройти: многие вещи надо было поддерживать именно JS-кодом, прямо вставляя его в код на Java, чтобы тот выполнил его в среде браузера в рамках теста. То есть я был в теме.
А среди прочего на проекте были наборы e2e-тестов на Selenium и нагрузочных на JMeter. Ну то есть нужен был Java-разработчик с навыками в автотестах и JavaScript-коде на клиенте. И благодаря своему крафтингу задач я оказался идеальным кандидатом на эту позицию.
Хотя автотесты изначально не были моей работой — они были только моим изменением задач, а JavaScript вообще был side effect'ом, чтобы не заскучать и наполнить рутину смыслом, — в дальнейшем они трансформировались в мои непосредственные прямые задачи, которые я получал от клиента или руководителя на работе.
Гештальт художника
До 2015 года, пока не произошёл релиз HTML5 и не началась эпоха SPA-приложений с полноценными фреймворками фронтенда, клиент-серверные приложения писались на инструментах вроде Eclipse RAP, GWT или библиотеках на основе JSF, которые инкапсулировали всю логику работы с браузерными технологиями JS, CSS и HTML. Ты пишешь на Java бизнес-логику и работу с данными, а UI — дело умных библиотек.
Такая ситуация порождала очень второсортное отношение инженеров к вёрстке и GUI: в основном все интерфейсы корпоративных приложений были одинаковыми, сухими и безвкусными, а лейаут собирали тегами HTML-таблиц.
В чём-то это подход, перекочевавший из десктоп-разработки на том же Borland VCL, Eclipse SWT и Java AWT.
Я уже пару лет как Java-разработчик на очередном крупном проекте для известного нефтяного холдинга, и это опять электронный документооборот. Фреймворк, на котором мы пишем UI, — JSF-библиотека, которая завернула внутрь себя ExtJS 3. Так как это был достаточно сырой велосипед, да ещё и без внятной документации, именно в этом слое постоянно появлялись различные баги и проблемы, а UI полз в разных браузерах.
Вспоминается цитата Алана Купера из его книги «Психбольница в руках пациентов»:
Инженерам трудно осознать, чем код на языке С, реализующий взаимодействие с базой данных, разительно отличается от кода на языке С, реализующего взаимодействие с человеком.
— Алан Купер, «Психбольница в руках пациентов»
Вот мне кажется, что именно тогда я оказался тем самым инженером, который осознал, что фронтенд и бэкенд — это про разное.
Возможно, это был гештальт несостоявшегося художника: до компьютеров мне пророчили стать иллюстратором, однако художку я бросил, да и в целом забил на это направление. Волшебный ящик с резисторами полностью забрал моё внимание. Но любовь к арту, визуалу и графике навсегда сохранилась в моём сердце.
Я стал тем человеком, которого всегда вызывали что-то поправить на UI, разобраться с этой непослушной JSF-библиотекой, продебажить код ExtJS и понять, как там всё работает. Моим крафтингом задач на тот момент стал CSS и желание разобраться в вёрстке — как правильно позиционировать элементы через float и clear — и перестать всё оборачивать в бесконечные table/tr/td в JSP-коде.
У нас тогда была концепция премий в процентах, и вот 100% можно было получить только за что-то выдающееся — очень редко. Помню, как тимлид бросил мне вызов: если я разберусь, как в этом JSF-велосипеде нормально и предсказуемо строить лейаут форм и панелей, то он выпишет мне эти 100%. Я сделал это. Даже под Internet Explorer 8 и 9. Это вам не шутки: сколько фронтенд-инженеров может похвастаться тем, что верстали под IE и писали на jQuery?
С тех пор ко мне прилипла репутация JavaScript- и UI-разработчика. Я был первым, кто вызывался на проекты с первыми JS-фреймворками, когда уже начала прослеживаться черта между фронтендом и бэкендом. Сначала первые SPA на ExtJS 4 — это была система для немецкой нотариальной палаты, и уже тогда я понял, что фронтенд — это непросто. Только сложность тут в другом. К примеру, локализация — это в лоб перевести текст с английского на немецкий. Немецкий язык необычный, со своей спецификой слияния слов в огромные токены, которые, конечно же, криво выпрыгивали из контейнеров и кнопок или делали неожиданные переносы контента. Локализация — это адаптирование всего UI под конкретную локаль.
Потом был Backbone.js, Ember.js, а дальше индустрия требовала AngularJS-специалистов с Bootstrap CSS в одной обойме. Мой крафтинг задач в full-stack-Java-разработке — когда я бесконечно плевался от падающих зависимостей в Maven и плохо понимал, почему так сложно вечно собрать этот war-файл для Tomcat, — привёл меня к программированию пользовательских интерфейсов в браузерах.
Я помню, как кто-то из Java-разработчиков уходил в большие данные и начинал писать на Scala, кто-то шёл в мобильную разработку (на Android была та же Java), а кто-то оставался в энтерпрайзе и эволюционировал вместе с языком и фреймворками вроде Spring. Благодаря крафтингу с вёрсткой, CSS, HTML и JS мой путь развития был очевиден.
Это было органично, словно по течению, и мне нравился такой исход: я чувствовал себя на своём месте. Слой взаимодействия человека и компьютера всегда интересовал меня больше, чем слой выкачивания данных из БД.
Художником я не стал, но начал «рисовать кодом», и это в какой-то степени частично закрыло гештальт.
Программирование и тесты
Я был мануальным тестировщиком, который программировал e2e-тесты. Я был серверным Java-программистом, который разбирался в CSS и JS. Надо было найти, чем отличаться среди JavaScript/Frontend-программистов. Надо было найти новый крафтинг задач.
Я всё так же сохранял свою роль full-stack-инженера с уже большим перекосом во фронтенд: Node.js заменил Java в моём стеке, а где-то сбоку выросла собственная команда и роль тимлида, который менторил и учил других.
В то время меня окружали проекты и инженеры, которые не писали модульные тесты. Их просто нигде не было. Хотя сама индустрия много про это писала и говорила, в реальности я сталкивался совершенно с другим. В попытке войны за тендеры клиентов, при постоянно горящих сроках и гонке скорости разработки тесты всегда воспринимались как нечто, что будет тормозить, не давать ценности в сравнении с QA и отнимать ресурс. Возможно, это был вопрос зрелости тех проектов и клиентов или вопрос качества инженерии в отдельно взятой компании. Но так было.
Голод к этой теме и попытка конвертировать свой прошлый опыт вылились в новый крафтинг задачи — модульные тесты. Популярная концепция Майка Коэна — пирамида тестирования — очень наглядно объясняла, почему упор нужно сделать именно на модульных тестовых наборах, а их пишут как раз программисты, не тестировщики.
Я стал проповедником тестов. Приходя на каждый свой проект, я прикручивал Jasmine, Mocha, Chai, Supertest и Protractor. А чтобы было интереснее, я начал агрессивно продвигать подход, сформулированный Кентом Беком: TDD (Test Driven Development) — разработка через тестирование.
Я писал про тесты, говорил про тесты, устраивал внутренние воркшопы и сессии парного программирования в команде, где пытался показать, как строить код, начиная с тестов. Ты пишешь тест — там твои ожидания, — а потом решение и реализация.
TDD и модульные тесты, да и практики «экстремального программирования» в целом, стали моим крафтингом задач на то время. У многих я тогда ассоциировался именно с этим. Некоторые коллеги говорили: «Вот, смотри, это тот разработчик, который работает по TDD».
Делали ли тесты наши решения более качественными? Уменьшилось ли количество багов? Было ли регрессионное тестирование автоматизировано и экономило деньги на ручном тестировании? Это всё вопросы бизнеса и корпораций. Мне ответы были не нужны, потому что тесты были моим крафтингом: я не говорил клиенту, что их пишу, не продавал их как обязательные задачи, но при этом мы всегда старались уложиться в сроки. Одно могу сказать точно: в других отделах так никто не делал. Только если клиент уже приходил с кодовой базой, где были тесты. Но они точно не были частью инженерной культуры той компании.
Время идёт, ты растёшь, вместе с этим меняются и твои мысли, и то, чем ты разбавляешь рутину работы.
Былое очарование старшим поколением, сформировавшим постулаты Agile, улетучилось. TDD был хайпом, но, на мой взгляд, был переоценён — про него больше говорили, чем внедряли и использовали. Я тогда уже прочитал много книг, все культовые: TDD by Example, Refactoring, Clean Code, Clean Coder, Clean Architecture и т.д. Часто я говорил цитатами и фразами других людей в попытке казаться умнее как инженер. Но это было не моё собственное мнение. Наверное, взросление — это когда кумиры пропадают: ты начинаешь видеть в них обычных людей, которые не идеальны, могут быть неправы, могут ошибаться.
Мартин Фаулер стал для меня пиарщиком собственной компании — при этом я пересекался с инженерами из ThoughtWorks на проекте крупной бизнес-консалтинговой компании, и качество их работы и сервиса оставляло желать лучшего. Дядя Боб стал для меня инфоцыганом от мира ИТ, который умело зарабатывал на своих тренингах и выступлениях, при этом не занимаясь настоящим корпоративным программированием, а Кен Швабер и Джефф Сазерленд — хорошими продавцами, товар которых — это сертификаты и бейджики по Scrum. Возможно, всё это ad hominem, но огонь к теме тестов, про которую так красноречиво все авторы выше много лет писали и говорили, у меня подостыл — реальность расходилась с книжной картинкой.
И нет, это не разочарование, а взросление. Существует множество крутых и талантливых инженеров, у них свои подходы — просто не все обладают возможностями и средой, где могут выпускать книги и влиять на умы людей. Хороший код — это не тот, в котором все шаблоны «банды четырёх» и принципы SOLID, а тот, который работает для людей и приносит пользу.
TDD — просто ещё один подход, ничего больше. Он не хуже и не лучше чего-то другого. Тесты — норма для любого большого настоящего проекта с пользовательской базой, если мы не хотим регрессии и хотим поставлять должное качество. Это часть quality gates наравне с другими проверками качества.
Роберт Мартин раньше апеллировал к истории мытья рук врачами: мол, да, тесты сейчас не пишут, но и врачи раньше руки не мыли. Хорошая метафора. И да, когда вокруг меня тесты не писали, это был крутой крафтинг. Теперь все врачи моют руки перед операцией и все инженеры пишут тесты, поэтому это тоже рутина и уже не так интересно. Уже не то, что отличает тебя от других.
Крафтинг задач в виде погружения в тесты принёс мне вампитер, вокруг которого я строил свои проекты и команды, инженерную культуру и — не побоюсь этого слова — репутацию внутри своей ИТ-компании.
Доступность
Новое увлечение, которое могло бы менять мою работу и влиять на неё, не заставило себя долго ждать. Если ты фронтенд-инженер, то чем ты хочешь отличаться от остальных фронтенд-инженеров? Я буду тем, кто делает экраны и компоненты не только в соответствии с дизайном в Zeplin, но и тем, кто делает их доступными для людей с ограничениями: слабовидящих, слепых, с нарушением моторики или когнитивными особенностями.
В своё время это была невероятно нишевая тема. В 2018 году я преподавал курс по веб-технологиям в ИТ-Академии и рассказывал студентам про стандарт W3C ARIA, при этом чётко понимал, что никто не делает этого на своих реальных коммерческих проектах.
Это невозможно продать клиенту: большинству стартапов собрать бы хотя бы зрячую аудиторию, привлечь хоть какие-то инвестиции или как-то монетизировать свой продукт. Отчёты ВОЗ о 15% людей с нарушениями выглядят хорошей фактурой, но реальный качественный сервис по разработке и тестированию доступного продукта — это колоссальные траты. Только огромные штрафы после юридических исков могут сподвигнуть компании думать о доступности, что и случилось в 2025 году после принятия акта EAA.
Но тогда, в 2018, я решил, что это и будет моим крафтингом. Я буду фронтендщиком, который говорит о доступности и внедряет её. Я начал разбираться в теме, работать со скринридерами, погружаться в гайды WAI и внедрять в код и вёрстку ARIA-шаблоны.
Это не было требованием на проектах: клиент это не заказывал и не просил — он даже не хотел бы делать это на 100% и сказал бы сфокусироваться на чём-то более прибыльном и важном. Но именно поэтому ему это никак не презентовалось и не подсвечивалось. Доступность не должна быть отдельным пунктом разработки, она должна стать частью натурального пути, чем-то само собой разумеющимся. Нет опции «пишем проект с тестами или без», как нет опции «пишем доступный продукт или нет». Это часть ремесла. Часть качественного сервиса.
У Алана Купера есть фундаментальный труд, толстенная книга «Интерфейс: основы проектирования взаимодействия». Знаете, сколько глав посвящено доступности? Всего одна, и в ней 2–3 предложения о том, что оно есть, важно и, если надо, нужно поддерживать ассистивные технологии. Я могу ошибаться, но, по-моему, это самая маленькая глава этой книги. Вот он точно первоклассный UX из Кремниевой долины.
Первым проектом, который мне удалось сделать более-менее читаемым для скринридера, была немецкая платформа Lition — где продавцы зелёной энергии могли находить своего покупателя и заключать с ним умный контракт в блокчейне.
Дальше доступность шла со мной рука об руку. И только сейчас, наверное, она превращается в рутину. Инструменты отлично развились: Lighthouse CI и Deque axe закрывают до 30% проблем; простое следование гигиене вёрстки — семантика, текст вместо картинки, немного ARIA — закрывает ещё 40–50% по ощущениям. Оставшиеся 20% — это экстра-усилие по принципу Парето, которое нужно закрывать с командой тестировщиков, имеющих настоящие ограничения, а не искусственные.
Ничего о нас без нас. Нужно привлекать слабовидящих или полностью слепых, людей с ситуативными и постоянными ограничениями — только так можно довести продукт до реального удобства. WCAG Level AA — это очень реальная и достижимая вещь, но важнее просто работающий продукт для всех категорий людей, а не цифры в отчётах и закрытые критерии в гайдах.
Доступность — это не только крафтинг задачи, но и мощный крафтинг смысла и когниций. Поддержка доступности приносит пользу и обычным пользователям: это называют принципом «курб-кат» (curb cut effect) — по аналогии с бордюрными съездами, которые изначально делали для инвалидных колясок, а теперь ими пользуются все. Даже ИИ-агенты получают пользу от доступной разметки.
Когда ты исправляешь div с onclick на button, добавляешь кнопке-иконке aria-label или дописываешь осмысленный alt у img, то чувствуешь себя настоящим героем, который спасает мир и восстанавливает справедливость. Ну вот, я соврал в начале эссе, что не буду рефлексировать про когнитивные изменения в работе.
В общем-то, это и не так сложно с инженерной точки зрения, как фундаментальные алгоритмы с поворотами бинарных деревьев, но эффект на сознание они оказывают большой.
Через какое-то время, сменив несколько компаний и проектов, я оказался на государственном проекте одной страны Ближнего Востока. Задача стояла разработать дизайн-систему для продуктов различных министерств и департаментов. Все они писали на разных стеках и использовали разные UI-библиотеки; важно было привести их всех к единому визуальному виду и стандарту.
Как вы можете догадаться, если где-то и есть строгие требования к доступности, то это в государственных цифровых продуктах. И вот опять мой крафтинг задач оказался полезен.
Мы разрабатывали дизайн-систему на Lit и Web Components, адаптируя порты к современным Angular- и React-экосистемам. Изначально я должен был отвечать за реализацию и техническую часть, а команда со стороны Ernst & Young — формировать требования к компонентам дизайн-системы. Но они ещё на старте успешно слились, и мне пришлось взять спецификации под свою ответственность.
У меня были постоянные встречи с командой Deloitte, которая отвечала за дизайн компонентов в Figma, — и тут-то я и блеснул своими знаниями доступности, много комментируя дизайн и давая советы и рекомендации по правкам. Казалось, что все знания про accessibility, накопленные за последние годы, нужны были именно для этого.
Жаль, правда, что дизайн-система как проект так и не была внедрена: проект заморозили из-за прекращения финансирования, бюджет перенаправили в другое место.
Анимация
Последним своим крафтингом задач я мог бы назвать анимации в вебе. Как-то один мой коллега сказал, что в 2024 году уже не комильфо делать статичные интерфейсы и компоненты в дизайн-системах. Микроанимации должны быть чем-то, что само собой разумеется. Я согласен.
Простые CSS-переходы на 200–300 миллисекунд делают интерфейс намного живее. Мне нравится приводить в качестве доводов весомые аргументы больших продуктов и немного цифр:
- Google Material Design: рекомендует анимации 200–500 мс для текста
- Apple HIG: предпочитает ease-out-кривые для появления контента, а ease-in-кривые приберегает для выхода и исчезновения контента
- Nielsen Norman Group: микроанимации могут улучшить пользовательский опыт продукта
- Shopify: деликатные анимации повышают engagement до 15–20%
Этих пунктов достаточно, чтобы убедить кого угодно начать внедрять анимации. Чаще всего сами дизайнеры поставляют статичные дизайны. Некоторые описывают текстом метки, какая анимация и где должна быть, но это крайне редко. Остаётся большое поле для творчества и крафтинга.
Я начинал с маленьких, почти незаметных transition-переходов и keyframes от 0% к 100% — что-то вроде fade in/out или анимированного появления контента со slide from bottom. Коллеги начинали говорить, что продукт становится живым, и я начинал чувствовать себя увереннее.
Так я дошёл до GSAP, Motion и Lottie. Многие наработки были тепло встречены моей продуктовой командой и дизайнерами и попали в продукт. Я одним из первых в подразделении адаптировал View Transition API, пытаясь мимикрировать под нативные платформы. Как-то я показал приложение своему бывшему коллеге, и он сказал: «Выглядит так, как будто это не веб, а натив». Это была высшая похвала.
Анимации не были моей прямой задачей и были исключительно крафтингом, но трансформировались в какой-то дефолт, где UI продукта теперь сложно представить статичным.
Недавно я сидел и обновлял в продукте визуал. Сзади подходит сын и смотрит, как лихо «шляпы» и «короны» напрыгивают на человечков (аватары пользователей), сгенерированных при помощи диффузионных моделей ИИ.
Сын постоял, посмотрел и говорит: «О, вот это я понимаю — программирование! А это ИИ-шка нарисовала?» 😁 И тут ты понимаешь, что всё не зря.
С этим главное — не переборщить, чтобы интерфейс не начал выглядеть как американские горки или цыганская свадьба и вызывать когнитивную нагрузку.
И обязательно учитывать опцию доступности Reduce Motion — внезапно два крафтинга переплетаются между собой!
Минусы
С другой стороны, будет лукавством не сказать про минусы постоянного изменения своей работы и задач.
Правда в том, что вы не будете получать больше денег за то, что начнёте рядом с ручными тест-кейсами класть e2e-код, что будете красиво всё верстать CSS flexbox или grid, а не таблицами, что будете писать модульные тесты, поддерживая покрытие кода на уровне 80%, и сделаете продукт доступным для людей с ограничениями.
Вы можете дождаться респекта от коллег и хорошей репутации, но реже — повышения или прибавки к зарплате. Получать улучшенную версию чего-либо за те же деньги — мечта любого работодателя. Просить больше денег или повышения можно, только если вы помогли оптимизировать бизнес, сэкономили, заработали — ну или, на худой конец (что вообще слабовато), хотите выровняться относительно зарплатного рынка, который ушёл вперёд.
Чтобы изменять задачи, вам надо быть готовым к сдвигам времени и сроков, к ускорению или к сознательному отступлению от приоритетов. Иногда это риски и издержки, которые нести вам. Срыв сроков или переработки вгоняют в стресс быстрее, чем кажется. Выгорание — это не миф, а реальность и современной ИТ-индустрии, и общества в целом.
Люди, которые вкладывают гораздо меньше усилий в свои задачи, могут рядом с вами расти по карьере гораздо быстрее — просто потому, что они не занимаются перфекционизмом, не топчутся на месте, меняя свои задачи для разнообразия, а движутся вперёд, понимая нужды бизнеса и запросы клиентов.
Я хочу сказать, что крафтинг задач — это не про успех в профессии. На собеседованиях в Google и Amazon никто не спрашивал меня про тесты, доступность и анимации: там нужно было провести мышку по лабиринту к сыру, подальше от злого кота, и сделать это максимально оптимально на абсолютно любом языке программирования. И я, судя по всему, сделал это не оптимально. То есть свободное время логичнее было бы потратить на профиль в LeetCode и очередное перечитывание «Алгоритмов» Роберта Седжвика — хотя через месяц у меня всё равно всё вылетело бы из головы, потому что это не рутина каждого дня.
Но это уже не крафтинг: такая деятельность, как курсы, книги, пет-проекты и т.д., — конкурирующая деятельность. Изменение задач — это про текущую конкретную работу, рутину, не что-то в стороне. Причём рутину внутри всё той же роли и часто компании.
Люди, которые меняют свои роли, переходят в менеджмент, становятся архитекторами и тимлидами, растут в деньгах быстрее. Правда в том, что заработная плата растёт ещё быстрее, если менять компании: рост внутри одной организации — всегда очень долгий и тяжёлый путь. Продать себя незнакомому человеку гораздо проще, чем тому, кто знает тебя уже много лет: первое впечатление нельзя произвести дважды, а провалы с тобой остаются навсегда.
Если успех в профессии — это деньги и карьерная иерархия, то крафтинг задач не об этом.
Главная мысль в том, что долголетие в профессии (плюс-минус одной роли) обеспечивается не сменой работодателей, а переизобретением собственных задач внутри одной и той же профессии. Это как раз тот путь, которым шёл я. Это путь, который, на мой взгляд, делает вас счастливее.
Что дальше?
Нужно какое-то завершение для этого лонгрида — вообще невероятно, что вы дочитали это до конца!
Быть футуристом сложно, поэтому крайне тяжело предположить, что будет актуально в будущем, какой крафтинг будет следующим и куда он заведёт.
Определённо, сейчас самый главный крафтинг у всех — это мастерство писать промпты на естественном языке, формировать планы в MD-файлах для ИИ-агентов и всячески автоматизировать работу, которую раньше инженеры делали руками.
Кто-то уходит «во все тяжкие» и начинает смело запускать ralph loop с review и непрерывным улучшением через одновременное редактирование и требований, и кода. Кто-то пока дозирует вовлечённость ИИ в работу и выступает в качестве ревьюера, человека в середине этого цикла, который пока ещё всё контролирует, понимает, что написано, и читает логику в коде. Кто-то смело заявляет, что больше не читает код.
Это, кстати, интересный вектор развития. Если код и языки программирования в создании ПО станут вторичными, то нам не нужны будут человеко-читаемые языки программирования. Нужно будет создать что-то вроде очень низкоуровневых оптимизированных языков, компактных и понятных машинам, но малопонятных человеку, — что-то вроде ассемблеров для ИИ, но ещё хуже по синтаксису. Генерировать код и разбираться в нём будет прерогативой машин, человек же будет контролировать процесс на самом высоком уровне инженерной абстракции. Возможно, даже без печати на клавиатуре — просто голосом, как уже сейчас многие практикуют.
Это вроде и крафтинг, и нет: этим сейчас занимаются все массово. Так что загадывать, что дальше, сложно. Но мне кажется, даже в этом новом дивном мире ИИ концепция и подход крафтинга задач и работы будут всё ещё актуальны!