Как быть дизайнером

Как помочь дизайнеру прокачать системное мышление, если вы лид Финальный пост из серии про системное мышление. Итак, допустим, вы помогаете развить системное мышление не себе, а человеку в вашей команде. Как это лучше делать? 1️⃣ Всегда подсвечивать пересечения. Если вы лид, то наверняка видите больше, чем линейные сотрудники, и на уровень выше: ходите на больше созвонов, общаетесь с продактами, знаете о планах компании. Заведите привычку регулярно рассказывать дизайнерам о том, что знаете, и расширять их картину мира, а если видите пересечения задач между разными продуктами и командами — говорите о них сразу, а не когда-нибудь потом. Точки пересечения — это именно те места, где дизайнеру требуется системное мышление: задачки на стыке разных зон ответственности, сквозные сценарии, общие справочники под капотом. Подсвечивая их, вы как бы говорите дизайнеру, куда ему приложить усилия, подсвечиваете фонариком тёмные углы. 2️⃣ Быть человеком для думания. Очень часто, чтобы увидеть слабое место в решении или важное ограничение в продукте, нужно пересказать всё другому. Отсюда рождается роль хорошего наставника: надо быть тем, кому хочется рассказывать — как умное зеркало, отражать чужой мыслительный процесс, обогащая его и подбадривая. Из этой позиции полезно задавать дизайнеру вопросы о том, как устроена его система. Не для того, чтобы проверить его знания — вы не учитель на уроке, — а чтобы человек мог поразмышлять вместе с вами и, формулируя ответ для вас, самому увидеть и понять систему. 3️⃣ Развивать активное слушание. Вытекает из предыдущего пункта: чтобы стать человеком, которому будут охотно рассказывать и отвечать, надо стать благодарным и внимательным слушателем — не отвлекаться во время разговора, не сидеть на созвонах с отключенной камерой, задавать вопросы, делиться чувствами и мыслями. Может показаться, что к системному мышлению это не имеет никакого отношения, но на самом деле, когда у дизайнера появляется такой собеседник (и тыл) в лице лида, ему становится гораздо проще разбираться в сложных системах, ковыряться в непонятном и выдерживать неопределённость. 4️⃣ В рамках критики подсвечивать сильные стороны. Прям словами говорить, где именно решение хромает, а где оно хорошее с точки зрения системности и почему. Часто есть соблазн не подсвечивать хорошее, а сосредоточиться только на том, что требует доработок: мол, Вась, тут у нас опять беда с панелью ошибок, давай на ней сосредоточимся, остальное неважно. Но говорить о сильных сторонах нужно для того, чтобы, прочесывая плохие решения, дизайнер заодно не избавился от удачных идей. Пусть дизайнер хотя бы кратко услышит от вас, что вот в этой задаче он удачно закрыл дыру в безопасности, а вот здесь лучше прежнего проработал корнер-кейсы. Это научит не терять ценные находки среди раундов исправлений. 5️⃣ И финальное: не развивать насильно. Бывает так, что некая работа требует сильного системного мышления, а дизайнер принципиально иного склада ума. Например, он силен в визуале или креативе и не хочет от этого уходить. Вы науськиваете человека на сложное проектирование, а ему это вообще не надо, у него весь кайф в другом. На мой взгляд, лучшее решение — не пытаться научить человека тому, что его не заводит (даже если это якобы принесет ему пользу), а прямо обсудить проблему с дизайнером, признать косяк найма (человек не на своём месте), и если желания явно расходятся, подобрать варианты рокировки внутри компании. И вам, и дизайнеру будет лучше, если все будут заниматься делом, к которому лежит душа.

Как прокачивать системное мышление В прошлой серии обсудили, как понять, что у дизайнера проблемы с системным мышлением. А сегодня расскажу, как его развивать и что помогло лично мне. 1️⃣ Начинать с моделирования. Вникая в новый проект или сложную задачу, полезно не просто протыкать экраны на проде, глянуть макеты и прочесть задачку — надо нарисовать схему, как все устроено as is и как должно быть to be. Вот вроде на курсах учат: перед макетами всегда рисуйте флоу. Но на практике многие джуны и миддлы пренебрегают схемами, пока их не вынудят к этому лиды. Почему? Во-первых, они цепляются за конкретную методологию: JTBD, CJM, service blueprint? Что выбрать? Как правильно? Что, если для чего-то нет данных? Сразу тормозим, а время поджимает. На самом деле пофиг, как правильно. Схемы можно рисовать любые, хоть просто статусы со стрелочками — лишь бы это помогало разобраться в системе дёшево и быстро. Во-вторых, редкий продакт добровольно поставит задачку «Нарисовать упрощенную схему». Ему это не надо, у него свои артефакты. Начинающие ребята боятся сказать: ребзя, перед макетами мне нужно уйти на несколько часов или дней рисовать схему, которая не пригодится никому, кроме меня. Тут нужна воля и вес в команде. Как исправить ситуацию? Достаточно один раз зажмуриться и сказать это наперекор неловкости. Вежливо, без наезда, извинений и расшаркиваний, потому что это обычный технологический процесс, как на заводе. Через пару-тройку таких задач неловкость исчезнет. Появится опыт и твёрдая уверенность, что моделирование правда предотвращает проблемы и прокачивает мышление, и без него в сложных задачах никуда. (Особый кайф — моделировать вдвоем с напарником: другим дизайнером или аналитиком. Требует сыгранности, но дает +100 к результату) 2️⃣ Разбираться в модели данных. Какие данные есть, какие типы, из каких справочников берутся, где хранятся и что бывает, когда хранилище отваливается. Тут тоже есть соблазн пропустить этап: пусть, мол, аналитик разбирается, это его работа, а я в макете рыбу нарисую. Что в целом понятно, но стреляет в ногу: в данных вся соль, они не просто влияют на дизайн — они и есть тот предмет, что требует дизайна. Нельзя придумать отображение для вещи, которую ты не понимаешь — такой дизайн рассыпется, как карточный домик. 3️⃣ Документировать находки. Непопулярный, но очень полезный ход: вести собственные заметки об устройстве продукта, этакую мини-вики. Пришла сложная задача, с которой нет уверенности, что ты её правильно понимаешь? Круто написать краткое понимание задачи своими словами, скинуть аналитику и попросить его окнуть или возразить в комментах — так сразу видны расхождения. 4️⃣ Завести чеклист состояний. Пустые стейты, скелетоны, корнер-кейсы, когда данные не пришли или пришли не те, ошибки — полезно сделать из этого чеклист, держать под рукой и адаптировать под каждую задачу. Несколько примеров из своей практики покажу в комментах. 5️⃣ Ходить на демо смежных продуктов. На мой взгляд, это самый бесячий совет, и ему трудно следовать, но он работает. Если продукт сложный и с высокой связанностью, полезно смотреть, как соседи решают те же проблемы, есть ли у вас похожие сущности и как они выводятся в интерфейсе, как ведь себя пересекающая аудитория. Иногда это экономит сотни часов и приводит к озарениям. Если демо чересчур много, можно раз в месяц забивать время на чтение дайджестов соседей и саммаризировать созвоны. 6️⃣ Сознательно выбирать сложное. Ничто так не прокачивает человека, как столкновение с задачей на пределе его возможностей, если он выбрал её сам и искренне захотел с ней разбираться. Прокачать системное мышление легко, когда горишь идеей повысить сложность, и очень сложно, когда тебя вынуждают. Это разница между страстью первопроходца, азартно прорывающегося через джунгли с мачете, и кошмаром новичка, которого толкают в болото с крокодилами. Универсальный совет: не надо развивать себя через силу и становиться жертвой обстоятельств — это очень мучает. Круто быть автором изменений и идти туда с горящими глазами, остальное приложится.

Как понять, что у дизайнера проблемы с системным мышлением Главный маркер: сложные задачи систематически возвращаются к дизайнеру с какой-то большой и существенной проблемой. Речь не о том, что забыли учесть пару состояний, а о том, что важная логика не сходится: — нет ветки сценария, — не дружат статусы, — есть критическая уязвимость, — функции дублируются, — два соседних продукта наступают друг другу на пятки. Тут надо оговориться: не всегда это вина дизайнера. Синхронизация больших продуктов друг с другом — огромная головная боль продактов и их хэдов. Индустрия в кризисе идей, смыслов и кооперации: даже компании с почти бесконечным ресурсом типа Эппла регулярно с этим продалбываются и вместо вменяемого единообразного UX внутри своих же платформ месяцами пилят несчастный Luquid Glass и выдают это за прорыв и удобство. (Вообще в последние годы очень уж часто любой сквозной сценарий любой корпорации, затрагивающий 2-3 платформы, — это UX-ад. Мы сейчас туда не пойдём, иначе рискуем словить ощущение полной тщеты бытия. Какое нафиг системное мышление, если ни одна компания на рынке не может сделать сквозной сценарий подписки одинаковым и внятным с любого устройства? Но я сторонник идеи, что когда кругом хаос, надо продолжать возделывать собственный сад и делать всё по уму хотя бы в нём, этим и спасёмся) Если продукт действительно сложен технически, то перед дизайном непременно должен быть этап системного анализа, где аналитик придумывает техническую архитектуру решения — откуда и как брать данные, где хранить, как защищать. Дизайнер (даже сеньор) не разбирается в этом на уровне профи, нужна база от опытного системного аналитика. Но если база есть, этапы системного анализа пройдены, а задачи разворачиваются на этапе дизайна с потерянными связями и недодуманными ветками, это повод подкачать системное мышление. Как вообще выглядит прокачанное системное мышление у дизайнера? Мои маркеры таковы: 💚Дизайнер не работает изолированно. Любую задачу видит как кусочек целого: вот эту новую фичу мы добавляем не потому, что нам важна фича в вакууме, а потому что она особенно классно работает в синэнергии с десятком других фич и систем, дружит с ними, позволяет достигать некой большой цели. 💚Меняет уровень детализации. Легко поднимается на bird view и видит систему целиком, легко заземляется и вникает в детали реализации. Перескок происходит без проблем, буквально по щелчку. Не зацикливается на маленьких вещах, если маленькие вещи не бьют в большие цели. 💚Помнит об ограничениях и взламывает их, когда надо. Получая задачу, прощупывает ограничения и интересуется, почему они именно такие, крутит их в уме, как кубик Рубика, учитывает нужное, отбрасывает ненужное, убеждает в этом команду. 💚Разбирается в модели данных. Знает, что откуда приходит, что где искать, какими данными мы оперируем, а какими нет. Не допускает ситуаций, когда в макете что-то придумано, а в бою эту инфу неоткуда взять. 💚Системные аналитики на него не жалуются. Спорный, конечно, фактор — жаловаться-то могут и на крутых ребят. Но если команда собралась хорошая и аналитики опытные, обратная связь от них важнее всего. Всем ли надо качать системное мышление? На мой взгляд, нет. Если дизайнер чаще работает с креативами, генерит идеи и создает визуал (в том числе и ИИшкой), развитое системное мышление может даже тормозить полёт мысли, вынуждать думать не о том. А вот если дизайнер работает над продуктами со сложной моделью данных, техничными инструментами, b2b-сервисами и продуктами с большим количеством связей — без этого, увы, никуда. Особенно в эпоху ИИ-агентов: сделать дизайн без системного видения они и сами могут, а вот формулировать видение, понимать контекст, связи и ограничения — это бесценная роль человека. В следующей серии расскажу про прокачку навыка и что помогло лично мне.

Серия про системное мышление В этом году решила писать сюда пореже, но на темы, которые не отпускают. Сейчас назрела серия про системное мышление. Иногда в карьере дизайнера наступает момент, когда он хочет усложниться: видеть шире, копать глубже, проектировать более сложные заковыристые штуки. Для всего этого кровь из носу надо качать системное мышление, а как — хз. Редко где рассказывают. У меня такой момент наступал трижды: — в 2019 году, когда уходила из агентства в продукт, — в 2020 году, когда стала работать с Почтой России над системами международного обмена почтой, — в конце 2022, когда перешла в Т-Банк (тогда ещё Тинькофф) и там взялась делать low-code платформу с нодовым интерфейсом. Каждый раз копалась с этим сама, и почти негде было получить толковый совет. Короче, накопился кое-какой опыт и не отпускает. Серия (пока что) состоит из 3 постов: 1. Как дизайнеру понять, что у него есть проблемы с системным мышлением и что его нужно качать 2. Как именно прокачивать системное мышление в повседневных задачах 3. Как помочь дизайнеру прокачать системное мышление, если вы — лид Погнали.

Как показывать визуал в портфолио? Бывает, смотришь портфолио с продуктовыми кейсами, там внутри гипотезы, тесты, анализ — гора полезной инфы, но вот визуально изменения не радикальные. Будем честны, редко какая задача в продукте (особенно внутреннем, сервисном или b2b) обладает зрелищным дизайном. Чаще наоборот — постороннему наблюдателю нужно еще наловчиться, чтобы понять, а что здесь визуально изменилось. А кроме того, непонятно, где заслуги и косяки дизайнера, а где дизайн-система. Может, из неё тянется легаси пятилетней давности — стрёмные тени, лишние дивайдеры, грязноватые цвета, которые дизайнер не убирает, потому что весь продукт надо перевозить на другую версию. Ну, бывает, все там были. Для дизайнера загвоздка в том, что собеседующий лид точно будет оценивать визуал. Даже если он нулевой или практически отсутствующий. Даже если речь о продукте, где не требуется классный UI, а надо просто уметь чисто сверстать таблицу или модуль. Лиду надо понять, что умеет кандидат с ограничениями и без них, к чему у него лежит душа и подойдет ли навык работы с UI в конкретном продукте. 🤩 На такой случай есть универсальный совет: соберите скрины с наиболее удачным и показательным UI на отдельной странице и назовите её «Визуал». Пусть там не будет юзкейсов и полезного действия — просто скрины. Удачные варианты вёрстки модулей, примеры иконок, которые вы рисовали, концепты, не дошедшие до прода, но демонстрирующие ваши навыки без привязки к легаси-решениям, да и просто красивые маленькие детали. У каждого продуктового дизайнера найдется хотя бы три-четыре приятных скрина, которыми он гордится (а если пока не находится ни одного, это повод что-то изменить в своей работе). Иногда для единообразия достаточно посадить скрины на однотонные светлые плашки, а иногда можно и без этого — будет уже красиво. Это ход win-win: и дизайнеру хорошо, и нанимающему лиду понятно, и занимает минимум времени.

Почему мои идеи не принимают? 2/2 (начало в предыдущем посте) Причин тьма, но я чаще всего видела такие. Причина 1, самая банальная: идеи не в кассу. Дизайнер либо предлагает мелкие улучшайзинги, которые по отдельности никому не важны, кроме него, либо гигантские редизайны, на которые нет ресурса, либо что-то мутное, в чём команда не видит ценности: в OKR не бьёт, метрики не ясны, сегмент узкий. Это не значит, что идеи плохие — скорее всего, дизайнер просто работает в продукте первые месяцы и ещё не въехал. Что делать: 🤩не увольняться сразу — сначала дойти до точки, где идеи станут релевантными, 🤩не приносить команде первые идеи, а дать им настояться, 🤩заранее подумать, как обосновывать ценность, 🤩мелкие улучшайзинги группировать в задачки побольше и тащить периодически — например, раз в квартал. Причина 2: идеи норм, но время неподходящее. Сейчас у компании время оптимизации, а дизайнер принёс идею, как захватить новый сегмент. Либо, наоборот, компания все силы вкладывает в освоение нового рынка, а дизайнер такой: друзья, вот 15 фич по автоматизации рутины с помощью AI. Прикольно, спасибо, дружище, но шансов ноль — это как вести парусник против ветра. Что делать: почитать статью Людвига «Оценка идеи. Компании роста и компании прибыли» Причина 3: нет нормального формата. Команда генерит много прикольного, но это куда-то утекает. Обсудили на дейлике или в личке, покивали, забыли. Пришло время планироваться — из головы вылетело. Нет встреч, бэклогов идей, форм для сбора обратной связи, процесса оценки фич, куда вовлечён дизайнер — с идеями можно попрощаться. Что делать: — внедрить формат, — убедиться, что ты общаешься с людьми, которые как-то влияют на принятие решений в продукте, — уже потом нести им идеи. Причина 4: нет авторитета и навыка дотаскивания идеи до прода. Чем серьёзнее изменение, тем больше ощущается сопротивление среды. Не потому, что люди плохие, а потому что подключается масса обстоятельств, связанных фактов, мелких дел. Велик риск потерять на полпути нюансы, проиграть в глухом телефоне, что-то не учесть. Чтобы дотащить изменение, нужно иметь некий ранговый потенциал и союзников, которые горят этой идеей так же, как вы, и готовы разделить с вами бремя организационных проблем. Что делать: 🤩искать союзников, 🤩превращать коллег в соавторов, не вцепляясь в единоличное авторство — не так важно, чья идея, если она хорошая, главное, чтоб она доехала до прода, 🤩почитать статью: «Как продуктовому дизайнеру качать стратегическое мышление» (в России открывается под vpn) Причина 5: есть контекст, который дизайнер не знает. Например, он не в курсе, что компания на грани разорения и лиды все силы бросают, чтоб не сокращать людей — им сейчас вообще не до идей, сорян. Или есть один бизнес-заказчик, который заказывает музыку, и он все подобные идеи втихую блокирует. Или чьи-то интересы и ценности внутри команды противоречат вашей идее, но вслух об этом говорить неприлично. Или в соседнем подразделении такую идею уже реализовали, и она не взлетела. Отличить подобную ситуацию можно по внутреннему ощущению: происходит неведомая фигня, рациональных причин отказа нет, но всё по-тихому сливается. Что делать: 🤩постараться аккуратно выяснить, кто вовлечен в процесс принятия решений и как (лучше всего на 1-2-1 с лидом или продактом — то есть с кем-то, у кого есть выход на уровень выше) 🤩если атмосфера в команде доверительная и безопасная, постараться сделать проблему видимой — обсудить на ретро, в командных чатах, с продактом (не давить и не наезжать, просто спросить с искренним желанием узнать чужое мнение) 🤩если атмосфера небезопасная, слив идей продолжается месяцами, союзников нет и не предвидится — уходить с чистой совестью (но не сдаваться, пока не испытаны способы выше)

Почему мои идеи не принимают? 1/2 Бывает, встречаешься с дизайнером на консультации, конфе или в баре, а он тебе: слушай, я разбился в лепёшку, принёс тысячу идей по развитию продукта, а продакты и аналитики их не берут. Это лыжи не едут или я? И не пора ли увольняться? Вопрос не праздный: почти каждый деятельный дизайнер на определённом этапе карьеры сталкивается с ощущением, что его прекрасные идеи либо складываются в долгий ящик, либо явно или неявно отвергаются. Некоторые выгорают, смиряются и перестают приносить идеи вообще. Другие отращивают навык аргументации, мучают команду месяцами и превращаются в евангелистов продукта. Третьи говорят: «Вы все дураки, а я непонятый гений» и уходят на поиски более сговорчивой команды. (продолжение в следующем посте ↓)

Как говорить о проекте, который не удался? Бывает так: дизайнер работает над проектом полгода, и тут выясняется, что задачи не взлетают, фичи не приносят прибыли, пора сливать воду и тушить фонарь. Проект закрывается, а дизайнер остаётся с двумя задачами: пережить горечь от напрасно вложенных усилий и найти новую работу. Но там точно спросят о старой, а как говорить о провале? 🤩 О пользе провала В моменте здесь и сейчас провал всегда болезненен. Это тяжело психологически — когда вбухала сотни часов труда, а продукт не взлетел; когда пользователи не оценили фичу; когда стейкхолдеры или команда друг с другом не договорились; когда искренне верила в решение, а оно оказалось ошибочным; а хуже всего — когда вроде всё сделала по уму, но обстоятельства на рынке таковы, что бизнесу надо повернуть в иную сторону. Меня один из карьерных провалов довёл до психолога. А из-за другого я буквально потеряла голос от нервов: приходила на созвоны, открывала рот и не могла вымолвить ни слова. Если вы переживаете провал прямо сейчас, это кажется катастрофой. Но в перспективе долгих десятилетий карьеры провалы полезнее успехов — именно за опыт преодоления разнообразного пиздеца опытному дизайнеру и платят. Успех даёт сиюминутные пузыри радости, а вот провал учит чему-то полезному раз и навсегда: — обращать внимание на юнит-экономику, — не бегать от стейкхолдеров, — концептировать много идей, а не цепляться за первую, — думать о корнер-кейсах на берегу, — тестировать перед внедрением, — не выбирать продукты и команды, с которыми не совпадаешь по ценностям, — всегда, всегда читать договор. Если человек называет себя сеньором и при этом у него не было ни одного проекта, который не удался, значит, он либо врёт, либо не сеньор. 🤩 Как рассказывать о провале Нет никаких правильных слов, которыми можно рассказать, что вы сели в лужу, спроектировали какую-то шляпу или выбрали не тот продукт, чтоб это звучало красиво и выигрышно. Нанимающий лид слышал тысячу историй. Если он достаточно опытен, то любая обтекаемая формулировка заставит его насторожиться. Вопрос не в конкретных словах, а в позиции: признаете ли вы личную ответственность, если косяк правда был ваш? Удалось ли извлечь полезный опыт? Понимаете ли вы, что пошло не так и как этого избежать? Если да — рассказывайте на собесе об этом. Если нет — остановитесь и подумайте, как не повторять косяк (подробнее в посте об ошибках). Ещё один важный момент: есть ли в вашем опыте что-то ещё, кроме провалов. Если у человека в портфолио пять проектов, ни один из которых не доехал до прода — это тревожный звоночек, внутри явно закопана какая-то системная нерешаемая проблема. Например, неумение дожидаться результатов, перебежки с места на место. Лучше сначала решить её, а уже потом искать работу (например, начать ходить к психологу). Но если один продукт не доехал, другой провалился, но ещё три норм — всё в порядке, это обычный рабочий опыт, и говорить о нём можно и нужно безо всякого стеснения.

Как сохранять баланс новизны и рутины? Два частых разнонаправленных запроса у дизайнеров: 🤩Чрезмерный движ: кругом изменения, задачи сводят с ума, вызовы дикие, всё горит. Ничего не знаю, не умею, не вывожу. 🤩Полный застой: кругом скука, полный штиль, задачи изучены вдоль и поперёк, работа не зажигает. Как в бородатом анекдоте про патологоанатома: всё знаю, всё умею, а помочь никому не могу. Проблемы вроде разные, а на самом деле про одно и то же: сломался баланс новизны и рутины. Это работает в любой профессии, связанной с интеллектуальным трудом: человеку нужно чередовать ритм, чтобы сохранять свежесть взгляда и интерес к делу. Слишком много нового — формируется постоянный стресс и ужас перед новыми задачами. Слишком много рутины — появляется скука и ощущение унылого существования. Как добавить рутины 🤩Придумать ритуал на утро и начинать с него день (небеса пусть упадут на землю, но перед дейликом — кофе и чтение статей) 🤩Забить слоты в календаре регулярными делами: дейлики, чтение дайджестов, разбор переписок перед окончанием рабочего дня 🤩Выработать и зафиксировать регламент, через какие этапы должна пройти каждая задача 🤩Провести ревью процессов и четко понять, где болит сильней всего 🤩Настроить доску и все задачи заносить в неё, а не хвататься за то, что попросили в личке 🤩Внедрить регулярные ретро с командой и обсуждать проблемы и идеи в строго отведенное время 🤩Организовать себе крошечные быстрые победы: хотя бы раз в неделю брать маленькие понятные задачки, которые не могут не получиться Как добавить новизны 🤩Взять задачу, которую не знаешь, как решать. Если очень страшно облажаться на глазах у всех — взять втихую и первое время никому не рассказывать 🤩Забить в календаре слот на изучение новой штуки, до которой не доходят руки 🤩Устроить дизайн-игру с коллегами: в пятничный вечер собраться на часок и вместе задизайнить плакаты, шрифты, любую дичь на произвольную тему, далёкую от основной работы 🤩Поставить себя в экстремальные условия: решить задачу за 15 минут — пусть херово, но нагенерить все мыслимые и немыслимые решения в очень сжатое время по таймеру 🤩Провести ревизию рутины, понять, что в ней бесит сильнее всего, и найти способ отдать другим людям ненавистную часть (часто то, что для одного рутина, для других — вполне себе новизна)

Как косячить? Неочевидный, но суперважный навык в айтишечке: научиться косячить. Косячат все, от джунов до СЕО — потому что мир постоянно меняется, решения надо принимать быстро, сфера интеллектуально затратная и высококонтекстуальная. Не косячат только те, кто на автоматизме делает что-то несложное десятилетиями, да и там от случайной ошибки никто не застрахован. Алгоритм, как косячить 🤩Признавать проблему. Не прятать голову в песок, когда что-то пошло не так, не избегать, не отпираться, а смотреть на косяк прямо. Часто это самое сложное. 🤩Признавать личную ответственность. Размытая фраза «нести ответственность» уже стала клише, и люди не всегда понимают, что это значит. Есть заблуждение, что ответственность предполагает раскаяние и публичное побиение себя в грудь. Но это не так. Нести ответственность — значит признавать, что возникшая ситуация — это результат твоей деятельности, а не чьей-то ещё, что ты хозяин как побед, так и поражений, и когда поражения случаются, ты не остаёшься в стороне и не оставляешь других людей бороться с последствиями без тебя. 🤩Не уходить в самобичевание и не циклиться на вине. Ну да, косяк случился. Да, плохо. Но жизнь не закончена, карьера не закончена и даже задача не исчерпана — работаем дальше. Будем честны: каким бы ни был косяк, вряд ли от него кто-то умер, это одно из преимуществ нашей профессии. А даже если умер, жить дальше другим всё равно как-то надо. 🤩Предлагать решение или компенсацию. Компенсация не обязательно предполагает материальную ответственность — такой пункт должен быть обязательно оговорён на старте работы и предполагать весомое обратное вознаграждение. Очевидно, что инвесторы и владельцы компании несут материальную ответственность, а вот наемные сотрудники среднего левела — явно нет. Но есть базовая рабочая этика — обнаружив косяк, предложить усилия по его исправлению, компенсировать потери новым решением, а не просто сложить ручки и вздохнуть. Это трудно и не всегда получается, но хотя бы честная попытка — уже плюс в карму. 🤩Извиниться и дать людям время, чтобы остыть. Если косяк принёс кому-то из коллег головную боль, не ждать, что тебя простят сразу и всё мгновенно наладится. Люди эмоциональны, а эмоции имеют свою температуру. Прежде чем общаться дальше, нужно принести искренние извинения и дать слегка остыть. 🤩Не повторять косяк. Самое важное. Сделать всё, чтобы не наступить второй раз (ну ладно, хотя бы в третий) на те же грабли: провести ретро, поправить регламенты, изменить что-то в стиле работы, завести чеклист. Крут тот человек, который косячит по-разному — это и есть развитие.