Вова і свідома компетентність

#128. Що команда чекає від менеджера Згадав шось про опитувальник Gallup по залученості команди, і зрозумів шо це по суті список того що команда потребує від менеджера. І мабуть тому воно й тримається вже 30 років — людські потреби на роботі змінюються повільніше, ніж менеджерські тренди. Дванадцять питань — дванадцять речей, яких людина чекає від свого менеджера. Там зазвичай відповідають типу від "Повністю не згоден", до "Повністю згоден". Я знаю, чого від мене очікують на роботі. Пастка в тому, шо це здається питанням про роль. Типу "робити дизайни, туди сюди". Насправді воно про передбачуваність в більш ширшому сенсі. Людина не хоче щодня гадати шо зараз важливо і за шо її оцінюватимуть. Тому менеджер регулярно синхронізує пріоритети і дає чіткий критерій "зроблено": 1:1, sprint planning, definition of done, плани на пів року, фідбеки. У мене є матеріали й обладнання, потрібні для якісної роботи. Тут про те що менеджер спитає чи треба щось додаткове, чи всього вистачає, або хоча б не проігнорить запит від людини. На роботі я маю можливість щодня робити те, шо вмію найкраще. Задіяна сильна сторона, а не латання дірок там, куди тебе посадили. Інколи складно звісно, але треба наближатись до цього. За останні сім днів я отримав визнання чи похвалу за хорошу роботу. На перший погляд здається, шо йдеться про похвалу. Суть в іншому — у конкретному, вчасному сигналі: я бачу твій вклад, саме зараз, а не на річному рев'ю. Тому працюють shout-outs, demo, peer recognition — швидкі і адресні. Мій керівник, чи хтось інший на роботі, піклується про мене як про людину. Чи відчуває людина себе ресурсом, чи живою людиною. Закривається не жестом, а регулярністю: 1:1, check-ins, особистим контекстом. Це про те щоб особисто переживати за конкретну людину. Без цього в менеджменті людей взагалі складно. На роботі є хтось, хто підтримує мій розвиток. Хтось свідомо інвестує в твій ріст, пропонує і шукає можливості, а не "розвивайся сам, ти дорослий" або "придумай собі шо ти хочеш розвивать".. На роботі до моєї думки прислухаються. Тут майже гарантована помилка: люди думають шо це означає "робимо як я сказав". Ні. Це означає, шо думку чесно розглянули перед рішенням, навіть якщо ухвалили інше. Саме тому є дизайн-критики, brainstorming, decision review — не заради процесу, а заради місця для впливу. Місія чи мета компанії дає мені відчуття важливості моєї роботи. Люди мотивуються розумінням, навіщо саме їхня сьогоднішня задача комусь потрібна, тому це не стільки про місію чи мету, а нафіга це комусь потрібно, і чи є відчуття що "так". Мої колеги віддані якісній роботі. Довіра до професіоналізму навколо. Коли всім поруч байдуже, важко самому тримати високу планку. У мене є друг на роботі. Мабуть найсуперечливіше питання з усіх дванадцяти. Але буквальна дружба тут ні до чого, йдеться про приналежність і довіру: тебе оточують люди, з якими безпечно. Є з ким поговорити і поділитись. За останні шість місяців зі мною хтось говорив про мій прогрес. Регулярний погляд на прогрес, а не оцінка раз на рік, якої всі бояться. За останній рік у мене були можливості навчатись і рости. Не плутати з попереднім пунктом — там про те, що хтось підтримує. Тут про реальну можливість: нова задача, нова зона відповідальності, а не тільки добрі наміри. Коротше, найцікавіше в цьому списку зовсім не Gallup. Типове мислення менеджера: "у нас немає one-on-one, треба запровадити". Правильне мислення: "у людей немає відчуття шо ними цікавляться, чим це закрити?" І one-on-one — не єдина відповідь. Може бути шо менеджер став частіше підходити сам. Змінив формат стендапів. Зробив walk&talk. Почав регулярно давати контекст. І мабуть саме тому хороший менеджмент починається не з питання "який процес нам ще впровадити?". А з питання: "чого зараз не вистачає людям, шоб вони могли краще робити свою роботу?" Бо one-on-one, feedback, planning чи recognition це просто різні способи закрити якусь з людських потреб.

#127. Компанії купують не навички Продовжую шукати закономірності поза трендами, і на цей раз про АІ-шку і цінність людей у компанії. Ми постійно обговорюємо навички — хто вміє в Figma, хто пише код, хто збирає дослідження, хто вміє класно презентувати. Ставимо ці навички в рядок компетенцій і думаємо шо саме за них платимо. Але компаніям ніколи не були потрібні навички самі по собі. Компанія не купує Figma, чи SQL, чи дослідження, чи презентації. Вона купує те, шо завдяки цим навичкам перестає бути проблемою. Хтось збільшує швидкість. Хтось зменшує хаос. Хтось будує довіру. Хтось зменшує ризик. Питання не в професії і не в навичках а в тому, яке саме вузьке місце людина прибирає для організації. Дизайнер, менеджер і юрист можуть на перший погляд не мати нічого спільного, але всі троє продають компанії зняття проблеми, просто кожен своєї. Можна мати однаковий тайтл і зовсім різну цінність просто тому шо один прибирає головне вузьке місце компанії, а інший ні. Довго найдорожчим обмеженням була швидкість виробництва. Треба було більше екранів, більше коду, більше досліджень, більше презентацій, просто фізично більше рук, які встигають це зробити. Тому технічні навички коштували так дорого і швидко зростали в ціні далі. Не тому, шо самі навички були магічними, а тому, шо саме швидкість виробництва була головним дефіцитом. Ще пару років тому дизайнер малював екран два дні, зараз — двадцять хвилин і одразу з прототипом, кодом і блекджеком. AI не зробив відповідальність дорожчою, він зробив виробництво дешевшим. Різниця невелика на вигляд, але вона все міняє. Відповідальність не змінилась. Довіра не змінилась. Хаос нікуди не подівся. Змінилась ціна виробництва — а разом з нею автоматично змінилась відносна цінність усього іншого. Це не раптова мода на аішку чи soft skills — просто змінилося головне вузьке місце системи, а з ним і ціна всього іншого. Дорожчають ті, хто бере на себе відповідальність: може сказати "не випускаємо", коли всі навколо хочуть релізити швидше, і готовий відповідати за наслідки цього рішення. Дорожчають ті, хто вміє домовитись між командами і людьми, коли кожна сторона тягне у свій бік і всі формально праві — і саме тому їм довіряють навіть коли шось йде не так. Дорожчають ті, хто бачить наслідки рішення на три кроки вперед, а не тільки сам результат, який видно прямо зараз. Якщо подивитися на це через теорію обмежень, то нічого магічного не сталося. Просто обмеження перемістилося. Колись головним вузьким місцем була швидкість виробництва. Тепер — здатність приймати рішення, домовлятися, брати відповідальність і бачити наслідки. Ми думаємо шо AI замінює людей, але мені здається, він поки шо зробив дещо інше. Він просто перемістив головне обмеження системи. Раніше головне питання звучало так: "хто зможе це зробити?", а тепер все частіше звучить інше: "хто готовий за це відповідати?". Коротше, здається це трохи пояснює шо насправді відбувається і що робити.

#126. Чому менеджер витрачає так багато часу на пояснення Чим довше я працюю менеджером, тим більше мені здається, що головна частина цієї роботи — пояснення, і я мало чув про цю частину. Не хайринг, не вантувани — інше. Переклад і інтерпретація. Менеджер постійно щось перекладає — причому одразу в трьох напрямках. Зверху вниз Менеджер має більше доступу до всяких стратегічних мітингів і сі-левелу, і збирає там купу стратегічної інфи. І задача не переказати слова керівництва, а інтерпретувати їх для конкретного контексту команди. "Хочемо покращити retention" — команда чує "нам треба ще три фічі". "Стаємо AI-first" — команда чує "додай кнопку". Шо ця стратегія означає для нас? Шо треба робити інакше? Шо взагалі перестаємо робити? Це ніфіга не просто. Знизу вгору Команда десь буксує. Є причини — технічний борг, залежності від суміжної команди, нереалістичні дедлайни. Всі в команді про це знають, і намагаються покращити ситуацію. Але керівник бачить тільки шо дедлайн зірвано. Вже другий раз поспіль. Задача тут — перекласти реальність команди в сигнал який керівник зможе почути. Не скаржитись і не виправдовуватись, а давати контекст і пропозиції. Щоб рішення ухвалювались з розумінням ситуації — а не з фрустрації. Можливо вчасно запросити додаткові ресурси. Горизонтально Дизайн хоче ще два тижні на ресьорч. Продакт хоче релізитись до кінця кварталу. Обидві сторони мають рацію — вони просто живуть у різних контекстах і оптимізують різне. Менеджер повинен спочатку зрозуміти шо насправді важливо кожній стороні, а потім допомогти знайти рішення яке враховує обох. Без цього такі розмови перетворюються в перетягування канату де перемагає не той хто правий, а той хто голосніший. Штука в тому, шо інформація не протікає сама по собі. Кожна людина живе у своєму локальному контексті і оптимізує його. Це не погано і не добре — так влаштовано. CEO не бачить оперативних деталей. Дизайнер не знає шо відбувається в суміжних командах. Продакт інтерпретує стратегію через призму свого беклогу. І кожен при цьому діє цілком логічно — у межах свого контексту. Саме тому люди так часто рухаються в різні сторони, щиро думаючи шо рухаються в одну. І якщо в команді немає людини яка цей переклад робить — кожен починає інтерпретувати самостійно. Не зі злого умислу. Просто заповнює порожнечу тим що має. Коротше, переклад і інтерпретація — це не активність між "справжньою" роботою. Це і є велика частина роботи. Причому та від якої часто залежить чи рухається команда в правильному напрямку. Просто вона погано видима, не дуже вимірюється і ніколи не потрапляє в опис вакансії.

#125. Шо насправді написано в твоєму звіті або фідбеку Скоро в нас в Скайлум feedback week (коли всі пишуть фідбеки), то я став думати в цьому напрямі, а ще підтягнулися спостереження за щотижневими звітами, і виступами на дейліках. Коротше я спробував систематизувати то як, навіщо, і з якою мотивацією люди пишуть чи доповідають про свою роботу. Будь-яку інфу можна подати різними способами і здається, що який саме спосіб ти вибереш, залежить не від факту, а від твого стану. Мені здається тут є дві головні штуки, які це визначають. Перше — на чому фокус: на собі, чи на роботі/команді/продукті. Друге — режим: я зараз захищаюсь або атакую, чи просто передаю інформацію. Фокус на собі + інформаційний Чесна рефлексія. "Ось шо вийшло, ось де я помилився, ось шо зробив би інакше". Без перебільшень, без оборони — просто розбір. Більшості здається, що вони саме так все подають. Фокус на собі + політичний Це класичний "доказ цінності" — перелік всього шо ти зробив, шоб показати свою важливість. Цікаво, шо це можна робити з двома різними інтентами: - як атака: "дивись скільки я роблю, тому любіть мене, додайте грошей, промоутьте". - як захист: "дивись скільки я роблю, тому не звинувачуйте мене якшо шось пішло не так". Фокус на системі + інформаційний Ризики і рекомендації. "Основний ризик зараз — інтеграція X. Якшо не вирішимо до кінця місяця — втратимо два тижні". Тут немає питання "як я виглядаю" — є питання "шо важливо знати, шоб прийняти рішення". Фокус на системі + політичний Пошук винних. "Це не я, це вони / маркетинг затримав / процес поламаний". Теж може бути захистом ("я не винен") або атакою ("систему треба зносити, бо вона мені заважає бути крутим"). Є ще один напрям, котрий я бачив, це такий собі скромно-невпевнений "та шо я, я нічого то і не робив, херню всяку". Якщо це невпевненість — треба шось з цим робити і допомагати людині. Якщо це "ти повинен відповісти шо я класний", то може ви даєте мало позитивного фідбеку. Контраст в дії: може бути один і той самий тиждень, і той самий набір фактів. З одного режиму вийде "я зробив дофіга всього, дивіться який я молодець (або як мене скривдили)". З іншого — "ось де проблема, ось де я застряг, ось шо потрібно". Другий варіант коротший, менш вигідний для автора особисто — і набагато ціннішим для того хто читає. А можуть бути довготривалі патерни, з котрих треба тимпаче робити висновки. Ми часто думаєм шо передає тільки інформацію, а насправді передаєм і свій емоційний стан. І перш ніж писати наступний звіт чи фідбек — варто на секунду запитати себе: я зараз пишу шоб показати себе, захиститись, атакувати, чи шоб людина по інший бік могла прийняти краще рішення?

Різниця достатньо проста. По-перше, CDO - це людина, яка працює на рівні C-level, і це значить, що компанія бачить дизайн як елемент стратегії. Зазвичай люди потрапляють на C-level тоді, коли компанія бачить функцію як стратегічний інструмент. Наприклад, туди потрапляє маркетинг або технології - тому що вони можуть давати якусь конкретну перевагу на маркеті. Тобто, це історія про роботу зі стратегією і вплив на неї. Дизайн потрапляє туди, наприклад, в моєму випадку (попередній експіріенс), бо фаундерам було чітко зрозуміло, що компанія хоче конкурувати за рахунок комунікацій, креативу, експіріенсу в цифрових продуктах. І в принципі це відбулося - дизайн став елементом стратегії. Плюс, з точки зору керування функцією. У монопродуктовій компанії наявність CDO, коли всього 30 людей, і з них 6 запихувати на C-level - це типу ту-мач. Але якщо ми говоримо про кілька продуктів, які ще, можливо, працюють на різних ринках і мають різні бренди, то цю функцію треба консолідувати. Знову ж таки, працювати з нею на стратегічному рівні: навіщо вона треба, які пріоритети, які задачі і так далі. Тобто, давай так: CDO - це людина, яка будує дизайн як одну зі стратегічних переваг компанії. За рахунок чого будується бренд, за рахунок чого будується комунікація, а взаємодія з цифровими продуктами виходить за рамки цифрового середовища - наприклад, у магазини. І в цьому велика відмінність. Для мене це дуже зрозумілий і чіткий меседж - коли та чи інша функція є на C-level, а коли ні.

отут мій друг і колега пан Іван Роговченко ще написав мені по темі вище)

#124. Чому CTO існує майже в кожній компанії, а CDO — ні? Якось говорили з моїм менеджером про те куди росте дизайн-менеджер, типу чи має сенс очолювати і продакт-дизайн, і маркетинг-дизайн одночасно. Так от я далеко в цьому не впевнений. Маркетинговий дизайн виконує цілі CMO. Продуктовий — цілі CPO. Об'єднувати можна, але скоріше в тому випадку, якщо компанія ще невелика і був дефіцит людей. Але я став думати, що ніхто не сперечається про роль CTO, наприклад, — а питання "чи потрібен головний дизайнер" абсолютно нормальне навіть у великих компаніях (але зараз не про корпорації). Тому зараз порозмірковую на ніфіга собі контроверсійну тему, приберіть дітей від екранів телевізора. Мені здається питання в сфері відповідальності і "об'єкті управління". У кожного на C-рівні є щось конкретне, чим він управляє і за що відповідає. CTO — платформа, архітектура, технічний борг, надійність, безпека. Це реальний актив компанії. CPO — продукт, метрики, retention, активація, LTV, цінність для клієнта. CRO/CMO — гроші, через відповідальність за канали залучення клієнтів і їх конверсію в платника. Прибери будь-кого з них — за кілька кварталів компанія це відчує. Конкретно і боляче. А тепер CDO. Чим він управляє? Якщо відповідь — "дизайнерами і дизайн-системою" — це не об'єкт управління на рівні бізнесу. Це засоби. Якщо відповідь — "customer experience" — починається конфлікт. Бо customer experience — це ж і є продукт. Там вже живе CPO. Якщо відповідь — "ми несемо розуміння клієнта" — і тут конфлікт. Бо хороший CPO вже давно окопався в user research, JTBD і customer insights. А що наприклад з Chief Legal Officer (котрий теж не те шо б в кожній компанії є). Юридичний департамент існує, має бюджет і людей. Але юристи наче ніколи не претендували на стратегічний об'єкт управління — вони управляють специфічною експертизою, котра не пересікається з іншими С-напрямами. Дизайн же часто хоче бути за одним столом з CPO і CTO, але поки не може чітко пояснити — за що саме хоче відповідати. У великих компаніях дизайн завжди стає окремою системою зі своїми стандартами, процесами, кар’єрними треками і внутрішніми платформами на кшталт дизайн-систем. Саме тому ролі на кшталт Head of Design або VP Design виглядають цілком логічно. Але питання інше: чи достатньо цього для окремої функції на рівні C-suite? Прибери CTO — що станеться? За кілька кварталів почнуться проблеми з надійністю, масштабом, технічним боргом. Платформа — це незалежна система зі своїми законами. Прибери CDO — продукт не перестане існувати. Компанія не втратить здатність продавати чи розробляти. Наслідки скоріше будуть накопичуватися через фрагментацію і різні стандарти. Дизайнери розійдуться по продуктових і маркетингових командах. Можливо, якість просяде (а може й ні). Це неприємна думка для дизайнерів, але мені здається про це корисно подумати, тому що дизайн роками говорить про "місце за столом", про стратегічний вплив, про те що нас не пускають і не розуміють. Але може питання не в тому що не пускають, а в тому що дизайну як дисципліні досі важко сформулювати — за що саме він хоче відповідати. Чим він хоче "володіти" в термінах, які зрозумілі бізнесу. Багато сильних дизайн-лідерів рано чи пізно починають керувати не тільки дизайном. До їхньої відповідальності додаються Research, Customer Experience, Innovation, Product management. Тобто той самий CX вже виходить за межі продуктового департаменту. Можливо тому що вплив у компаніях зазвичай зростає разом із шириною відповідальності. І тоді виникає незручне питання. Якщо шлях до більшого впливу майже завжди проходить через розширення сфери відповідальності за межі дизайну — то чи є дизайн самодостатньою бізнес-функцією? І на яких етапах?

#123. Як зробити спілкування на вантуванах більш персональним Якось на консультаційному дзвінку дизайн-менеджер запитав: "Як зробити спілкування з репортом більш персональним? Ми спілкуємось регулярно, але якось поверхово." Гарне питання. І дуже часте. Типова картина: ван-ту-ван відбувається щотижня. Говорите про задачі, трохи про вихідні, може про новини — і розходитесь. Нікому не незручно. А потім виявляється що в людини щось відбувається — і ви навіть не підозрювали. Ніби спілкувались. Але по суті — ні. Рівні спілкування Gary Smalley виділив п'ять рівнів спілкування — ще в 70-х, але для робочих стосунків досі актуально: Ритуали або смолток — "привіт, як справи, як вихідні". Потрібні для початку, але поганий фінальний стан. Факти — обмін інформацією. "Задача не закрита", "є зустріч в п'ятницю". Безпечно, бо з фактами не посперечаєшся. Погляди — думки, оцінки, інтерпретації. Тут вже є ризик: можна підставитись, можна не погодитись. Почуття — що реально відбувається з людиною. Потрібна довіра і готовність бути чесними — з обох сторін. Відвертість — розмова про найглибше: страхи, цілі, сумніви, мрії. Більшість робочих стосунків зависають між першим і другим рівнем. Це безпечна зона — обидва не ризикують. І тому нічого справжнього не відбувається. Де це відчувається Ви говорите про задачі — і це нормально. Але якщо через рік ви досі не знаєте що реально мотивує людину, що її дратує, що вона хоче далі — це симптом. Часто проблема не в репорті. А в тому, що ви самі не виходите з безпечного простору першими. Якщо менеджер тримається в зоні фактів — люди зазвичай туди ж і лишаються. Шо з цим робити Часто в мене бувають дзвінки з репортами на яких ми взагалі не торкаємось задач. Тільки — шо робили на вихідних, які переживання допікають по життю, в яку гру грали, якісь історії. І це одні з найкорисніших дзвінків. Кілька речей, які допомагають Годинний формат. Не 30 хвилин — бо к 30 хвилинам тільки починається двіж. Якщо дуже зайняті — краще година раз на два тижні ніж пів години щотижня. Готуйтесь. Якщо між дзвінками щось прийшло в голову — занотуйте. Принесіть щось своє: спостереження, питання, рефлексію, книжку. Дзвінок де ви прийшли з порожніми руками дає відчуття шо людина вам не дуже цікава. Прибирайте телефон. Навіть вимкнений телефон в руках дає відчуття шо ви десь інде. Це помітно навіть на відео-дзвінках. Будьте справжніми. Ваші питання не повинні виглядати як анкета. Якщо людина вам реально цікава — це відчувається. Якщо ні — теж. Рухатись до глибшого спілкування можна тільки якщо ви самі відкриті першими. Не техніка, не формат. Просто справжній інтерес до людини. Де ви зараз з кожним репортом на цій шкалі?

#122. Хороший менеджер будує систему, а сильний — систему, яка розвиває себе сама Базовий рівень менеджменту — організувати систему так, щоб вона працювала. Команда зібрана, процеси запущені, задачі виконуються. Це вже непросто. Але є рівень далі. Наступний рівень — організувати систему так, щоб вона покращувала себе сама. Без постійного менеджерського поштовху. Як це виглядає на практиці: - команда проводить нормальні дизайн-критики без тебе - люди самі підсвічують проблеми в процесах — а не чекають поки помітить менеджер - фідбек-культура існує бо це норма, а не бо ти щоразу нагадуєш - команда сама помічає дизайн-борг і пропонує шо з ним робити - люди синхронізуються між собою, а не через тебе як роутер Простий тест: шо в команді покращилось само по собі за останній рік без твого прямого втручання? Це не значить, що після цього менеджер стає не потрібен, але є різниця між тим, коли системі для руху потрібен ти — і тим, коли вона рухається і без тебе. Тобто різниця не в тому, наскільки добре ти керуєш, а в тому, шо відбувається коли тебе немає.

#121. Що будувати першим у новій команді Як будувати shared reality коли люди ще не навчились читати одне одного Коли команда нова — або зовсім нова, або наполовину перетрясена — менеджер часто очікує від неї поведінки зрілої команди. Логічно: люди досвідчені, завдання зрозуміле, процеси є. І все одно шось не клеїться. Хтось каже шо цілі незрозумілі. Хтось шо не вистачає відчуття команди — є задачі, але немає відчуття шо ми разом. Мітинги є, але якісь порожні. Рішення приймаються повільніше ніж хотілось би. Кожен тягне своє. Це не ознака поганої команди. Це нормальна фаза. Нова команда — навіть з класних людей — це ще не команда в психологічному сенсі. Організаційно вона існує: є структура, є ролі, є загальний канал. Але shared reality ще немає. У кожного своя картина того, як тут прийнято думати, хто шо вирішує, шо важливо, а шо ні. Доки ці картини не почали перетинатись — команда і буде відчуватись не як команда, навіть якщо всі стараються. Важливо тут не переплутати. Дисфункційна команда — де є токсик, зіпсовані стосунки, хронічні конфлікти — це окрема проблема з іншими ліками. Нова команда яка ще не сформувалась — зовсім інший кейс. Тому на ранньому етапі задача менеджера — не налаштовувати процеси. А будувати цю спільну картину. Використовувати 1:1 не тільки для задач. Починати варто з безпеки. Коли люди просять "більше живого спілкування" — вони рідко мають на увазі корпоратив. Вони хочуть зрозуміти менеджера: як він думає, як реагує, де можна бути відвертим. Це перевірка безпеки. І поки вона не пройдена — всі наступні кроки будуть половинчастими. Переформатувати регулярні мітинги. Якщо зустріч можна замінити повідомленням — вона не будує команду. Вона просто синхронізує таски. Команда формується коли люди думають разом, сперечаються, дивляться на одну проблему з різних боків. Ознака шо це починає працювати — коли на мітингах з'являються незгоди. Не конфлікти, а незгоди. Люди почали довіряти достатньо шоб говорити відверто. Зробити "чому" видимим. Менеджер часто думає шо він пояснив ціль. Але насправді — оголосив результат. "Нам треба підняти конверсію на 15%" — це результат. Шо за ним стоїть? Чому саме 15%? Які варіанти розглядались? Де є простір для рішень команди, а де вже вирішено? Без цього кожен заповнює прогалини сам — і заповнює по-різному. Спільний контекст — це не слайд з цілями. Це розуміння розумового шляху, який привів до рішення. Та і якби люди розуміли всі пояснення — це був би другий світ. Будувати зв'язки між людьми, не тільки через менеджера. Якщо вся взаємодія йде через менеджера — він стає bottleneck, а команда не навчиться читати одне одного. Спільна робота, пар-розбори, крос-функціональні обговорення — все це прискорює формування shared reality. Не поспішати з оптимізацією. Нова команда ще не навчилась нормально комунікувати, а менеджер вже вводить KPI, матриці і правила. Спочатку — система взаємодії. Потім — все решта. Коротше, сильна команда — це не коли всі дружать. А коли люди достатньо розуміють і довіряють одне одному, шоб ефективно працювати в невизначеності. Менеджер будує це першим — систему взаємодії між людьми. Процеси, KPI і структури — потім.

#120. Трохи цифр з реального хайрингу Закривав того тижня позицію сініор продакт дизайнера в команді, то подумав може колегам хайрінг-менеджерам буде цікаво порівняти цифри, а тим хто шукає — зрозуміти краще шо взагалі відбувається на одній конкретній вакансії. 25 березня відкрили і запостили вакансію — 20 квітня був прийнятий офер (27 календарних днів, 19 робочих). 197 → 1 Подались 197 кандидатів. Я уважно передивився кожного особисто, шо б знизити вірогідність пропуску класних людей. Автоматичної системи відбору в нас нема, якщо що, і я думаю це добре. 17 кандидатів я пропустив на етап до рекрутера. Трошки перегрузив я рекрутера звісно, але якось домовились. 10 попали на "професійне інтервью" до мене. 4 я пропустив на співбесіду до продакт-менеджера, шо б він подивився зі свого боку, і на людину яка піде до нього в команду. 3 попали на останній етап до COO/HRD. Це в основному перевірка на культурно-мотиваційний фіт. Ну і зрозуміло 1 офер. Статистика по реджектам 82 (42%) not enough experience — тобто я подивився сіві, портфель і тд, і це не дотягувало до потреб вакансії. 56 (29%) irrelevant skills — це ті в кого досвіду достатньо в цілому, але він не підходить під мою вакансію. Наприклад, хардовий досвід в аутсорсі, або фінтеку/крипті, або чистий UX, або маркетинг-дизайн. 18 (9%) not a fit — тут трошки специфічно вийшло — в основному сюди попали ті хто очевидно не знають українську мову на вільному рівні. Але також я додавав сюди тих хто подавався з якихось причин декілька разів підряд, шо б не заплутатись де оригінальна подача. 16 (8%) not a cultural fit — сюди попали спеціалісти з гембли. 8 (4%) position closed — в цей статус попали ті хто на будь-якому етапі вже не встиг на момент прийняття оферу фіналістом. 6 (3%) salary expectations — це ті хто написав в очікуваннях більше чим був мій максимальний бюджет на цю позицію. Чесно кажучи, я очікував тут буде значно більше людей. 4 (2%) job hopper — це ті в кого в сіві вказана купа позицій не більше ніж по півроку на кожній. Ще 4 людини попали в категорії overqualified або ми не змогли з ними зв'язатись. Висновки 1. Як і завжди, більшість кандидатів відсіюється на етапі загального фіту по сіві і портфелю. 2. 197 подач до одного оферу — це досить висока конкуренція, хоча я очікував шо буде значно більше. Я думаю це пов'язано з тим, що в Skylum в нас в основному україномовний ринок, який звісно менше світового. 3. Як я і писав раніше, позиціонування важливе, і подаватись з нерелевантним досвідом — мало сенсу. Зі сторони кандидата це виглядає як "ну я думаю я розберусь в домені", а зі сторони хайрингу це "якщо це не зіркове сіві по іншим показникам, то я не готовий давати шанс людині розбиратися". Тобто конкуренція і так велика, точно будуть люди з більшим розумінням домену, хто зможе увірватись значно швидше. Ринок маленький, черга велика. Треба точити сіві і портфель під вакансію щоб підвищити шанси.

#119. Ніхто не виділить тобі час на редизайн Бачив таке не раз: команда хоче зробити редизайн або нарешті нормально дослідити користувачів. Проходить квартал. Нічого не зроблено. Команда каже: нам не поставили в пріоритет, не виділили часу, нікому це не потрібно. Але справа не в часі і пріоритетах. І логіка начебто є: завжди є релізний цикл, завжди є гарячі задачі на вчора, забитий беклог. Редизайн — важливо, але потім, коли з'явиться вікно. Тільки вікна не буває. Ніхто не виділяє час на те чого не існує Ніхто ніколи свідомо не виділяє час на розмиту задачу. Беклог не зберігає наміри, він зберігає задачі. "Редизайн" і "user research" — це не задачі. Поки немає відповіді на "що конкретно хочемо змінити", "який ризик зменшуємо", "що дізнаємось і що далі з цим робимо" — це не потрапить у пріоритет. Ніколи. Ніхто в здоровому глузді не дасть недосвідченому дизайнеру експериментувати з складними мутними задачами. А досвідченому не треба давати, він сам візьме. Бо він на досвіді знає навіщо їх треба робити, заради якого результату, може їх декомпозувати. А недосвідченому треба спочатку піддивитись це в когось на практиці, або вчитись декомпозувати до мікроскопічних кроків. Безпечні задачі Є пул задач на котрі простіше знайти мотивацію, і навіть не розуміючи шо з ними робити — пропхати їх в беклог правдами і не правдами. Дизайн-системна інфраструктура, аксесібіліті, якоюсь юзабіліті-двіжуха — задачі теж мутні, але за них є соціальне схвалення. Курси кажуть що це важливо. Спільноти обговорюють. В соцмережах лайкають. За них не осудять — вони виглядають правильно і "дизайнерськи". Є активність, є що показати на ревью. Але це не те шо потрібно продукту чи компанії саме зараз. Просто коли немає чіткого і зрозумілого напряму куди рухатись — люди рухаються туди де є відчуття зрозумілого результату і схвалення ззовні. Що робити Досвідчений дизайнер не приходить з "хочу зробити редизайн". Він робить кроки самостійно, а потім приходить з конкретикою: "ось де ми втрачаємо користувачів, ось що хочу перевірити, ось що зроблю за два тижні і що ми з цього дізнаємось". Перед тим як ми зробили Documents X в Readdle, я прийшов до свого продакта і сказав "Я знаю як заредизайнити класно всю апку за місяць, а потім за 2-3 місяці максимум це задевелопити". А там ми ще й фічей потім накрутили топових. Перший результат — кредит довіри. Кредит довіри — левередж. Левередж — час і ресурс на більше. Коротше, ніхто не виділить тобі час на редизайн чи щось інше велике — доки це побажання, а не набір зрозумілих задач із зрозумілим очікуванним результатом.

От доречі мемасик шо наштовхнув на думку)

#118. Чому перформанс-ревью частіше імпровізація ніж система Про очікування які існують тільки в голові менеджера і що з цим робити Ще одна з поширених проблем в менеджменті це формування і донесення очікувань від роботи. Людина приходить: "хочу більше грошей, я класно працюю". Менеджер: "ну так ми тебе і наймали шоб ти класно працював". Пауза. Людина: "окей, а шо мені тоді треба зробити шоб отримати підвищення?" — Треба перевищити очікування. — Які? Як? — Ну... зробити шось неймовірне. На цьому розмова зазвичай закінчується. Людина не знає шо запитати. Менеджер — шо відповісти. "Відповідає очікуванням" — це не комплімент. Це підтвердження шо базова домовленість виконана. Людину найняли на посаду, вона робить шо на цій посаді треба. Клас, молодець. Це і є "відповідає". Не більше і не менше. Але де тоді межа між "відповідає" і "перевищує"? Хто її встановлює? Встановлює менеджер і межа досить субʼєктивна. І тут починаються питання. Чи сформував ти як менеджер собі розуміння шо таке "норма" до того як оцінювати. Чи уважно дивишся на роботу. Чи збираєш фідбек з інших сторін шоб не судити тільки зі свого кута. Найчастіше очікування або не сформульовані взагалі, або такі абстрактні шо їх не перевіриш, або з'являються постфактум — коли вже треба давати оцінку. Фактично — вони існують тільки в голові. Якщо їх не проговорили наперед — це не система оцінки, це імпровізація. І "перевищити очікування" тоді означає вгадати шо там у цій голові. Але є ще один рівень. Очікування менеджера теж не у вакуумі. Вони залежать від того шо керівництво вважає важливим, від культури компанії, від того шо взагалі помічається і цінується. Я бачив таке: менеджер щиро вважає шо дизайн — це красиво, естетично, доступно, за всіма гайдлайнами. І оцінює команду саме по цьому. А бізнес хоче конверсію, ретеншн, швидкість. В результаті дизайнер може системно "перевищувати очікування" свого менеджера і при цьому не створювати жодної цінності для компанії. Ну і навпаки теж буває — коли людина робить важливі речі, але "не відповідає" бо менеджер дивиться не туди. І ще один момент. Навіть якщо людина справді перевищує очікування — це ще не означає шо їй щось винні. В аутсорсі і агенціях вигідно вирощувати людей: ростуть скіли — ростуть рейти з клієнтів. В продуктових компаніях ця логіка не завжди працює — ROI інший. Бо платять не за зростання людини, а за зростання продукту. В аутсорсі продукт — це люди, а в продукті — ну ви поняли. Компанія платить не за зусилля і не за старання, а за вплив на результат. Коротше, якщо очікування не можна пояснити — їх не існує.

#117. Аналітика все ще тільки ритуал Часто зтикаюсь з тим що дизайнери трохи агресивно просять аналітику, або пояснюють помилки чи проблеми тому що не дали аналітику. Але здебільшого я бачу що це робиться, бо так "треба". Проблема також в тому, що у більшості продуктів тієї аналітики особливо нема. А якщо навіть і є — дизайнери туди все одно не заходять. Аналітика стала ритуалом. Просять, бо навчили на курсах, хайп-статтях і постах. Але не навчили що з нею реально робити і як будувати на ній гіпотези чи збирати докази. Дизайнер має приймати рішення на основі даних — звучить розумно, але шо робити далі? Як заходити в Amplitude (чи не його, зараз купа систем), шо шукати, як читати маленькі цифри — цього, як правило, ніхто не показує. А якщо і показує — в загальних словах, без конкретики. А ще стат.значимість. В результаті три типові ситуації: - даних нема взагалі (більшість продуктів саме такі), - дані є але дизайнер не знає як туди дивитись, - доступи є але ніхто не заходить. І у всіх трьох — аналітика залишається темою розмов, а не роботи. Я думаю шо проблема тут не в доступах, а в навчанні і звичках. Якщо немає скілу — ти не робиш, якщо скіл є — робиш. Коли в команді немає культури роботи з даними, типова історія скинути це все на продакта: хай робить зводки, приносить дані. "Якщо мені не принесли цифри, то я не винен". Аналітика це не панацея, аналітика не скаже що робити. Далеко не завжди те шо вона є — вирішує всі проблеми. Мій меседж шо треба зупинитися і подумати, шо конкретно ви хочете отримати, коли пушите аналітику. Бо якщо нічого конкретно, то ви просто втрачаєте репутацію в очах команди, рекрутера, наймаючого менеджера. Аналітика це про те що відбувається. Рішення все одно ваше, його все одно доведеться приймати самому, і тільки аналітики не вистачить. Що дизайнерам реально треба від аналітики Не “глибоке занурення”. Не “ідеальна дата”. І точно не “аналітика скаже нам, що робити”. Потрібен верхньорівневий sanity-check свої рішень. Мінімум, який швидко дає контекст: - базова воронка або ключова конверсія по сценарію, який ви чіпаєте - 1-2 зрізи (платформа/країна/сегмент — що у вас є) - просте “до/після” як орієнтир, а не як доказ Типові граблі, які я бачу постійно 1. “Я не лізу, поки не зрозумію все” — так можна не лізти взагалі. А потім чесно казати “аналітика складна”. 2. Маленькі цифри і фальшиві висновки — 10 людей натиснули одне, 50 інше, і вже хочеться приймати рішення, бо відсотки то різні. Часто це не значить нічого. Просто шум, який виглядає переконливо. 3. Очікування, що дані замінять прийняття рішень — не замінять. Доведеться все одно самим формулювати гіпотези і робити вибір. Як покращувати ситуацію в компанії 1. Зробіть мінімальний едукейшн-івент Один воркшоп на 60–90 хв. Показати: де дивитись базове, як читати 2–3 типові чарти, і що робити з малими числами. Повторювати періодично і в тому числі на онбордингу. 2. Вшийте аналітику в постановку задач Додайте в бриф пункт “подивитись Amplitude”. І вимогу: 1–2 скріни або лінк на дашборд прямо в контекст задачі. Це мінімальний стандарт, який змушує реально зайти й подивитись, а не просто “попросити аналітику”. Аналітика не дасть вам відповідей, але допоможе прибрати частину фантазій. А клеріті, як правило, ніхто не приносить. Її доводиться забирати самому.

#116. Intent does not matter Типова сцена на ревью: людина чує фідбек — і щиро дивується. Вона ж так старалась. Вона ж хотіла як краще. Вона ж стільки думала над цим завданням, переживала, не спала. Звідки раптом негатив? Зсередини це виглядає абсолютно логічно. Але проблема в тому, що вона і менеджер/компанія дивляться на одну й ту саму ситуацію через зовсім різні шкали. Як ми оцінюємо себе - Я старався - Я хотів як краще - Я довго думав над цим - Хтось же мав спробувати → Отже, я молодець. Як ми оцінюємо інших - Що вийшло? - Яка користь для команди або продукту? - Якщо результату немає значить спеціаліст "так собі"... Слабенький. Ніхто тут особливо не злий і не несправедливий. Штука в тому, що свої наміри ми знаємо — весь контекст, всі думки, всі переживання. А чужих намірів просто не видно. Видно тільки результат. Тому і оцінки різні. Звідси росте половина конфліктів в командах: - образи на ревью ("я ж так старався, чому не помічають?") - нерозуміння промоушнів ("я роблю більше за всіх, чому не підвищують?") - здивування зарплатам і бонусам - конфлікти дизайнер ↔ PM - конфлікти співробітник ↔ менеджер Якось я грав у God of War — і там є сцена де Кратос, бог війни, зупиняє сина після помилки і коли той виправдовується каже: "Intent does not matter, only consequences." Намір не має значення. Тільки наслідки. Кар'єра майже завжди оцінюється по outcome, а не по intent. Система не бачить твоїх намірів. Вона бачить результат. І ніхто не зобов'язаний копати глибше. Бо намір це субʼєктивно. І це стосується не тільки джунів. Я бачив мідлів і сеньйорів з роками досвіду, які щиро не розуміли чому їх не підвищують. Вони старались. Вони дійсно старались. Але не вміли переводити наміри в результати — і показувати ці результати. Що з цим робити - Формулювати результат заздалегідь. До початку роботи — домовитись як виглядає успіх. Не "я зроблю дизайн", а "після цього ми матимемо X". - Міряти результат. Не "я зробив", а "ось що змінилось після того як я зробив". - Комунікувати результат. Якщо ніхто не знає — вважай його не було. Коротше, старатись — необхідно, але недостатньо. Система оцінює наслідки, а не наміри. І якщо не навчитись їх в першу чергу досягати, а в другу ще й показувати — відчуття що тебе недооцінюють буде постійним. І, на жаль, з боку системи це буде справедливо.

#115. Нелояльність до менеджера — це глухий кут Частий кейс у командах: людина не погоджується зі своїм менеджером. Вона бачить проблеми в рішеннях, процесах або культурі, і замість того, щоб адаптуватися чи змінити контекст, починає з цим боротися. Зʼявляються спроби довести, що менеджер неправий, знайти підтримку у колег і топ-менеджерів або підсвітити “реальну проблему” на ширшому рівні. Зсередини це може виглядає абсолютно раціонально. Людина не просто чинить опір — вона вважає, що хоче зробити краще, виправити помилки і досягти кращого результату (інколи це так, але частіше ні). Часто є відчуття, що якщо достатньо чітко пояснити ситуацію, всі "розберуться" і визнають, що ти — герой. Але в більшості організацій це працює інакше. Компанія майже завжди стане на сторону менеджера. Навіть якщо він "неідеальний" або допускає помилки, його будуть розвивати, підтримувати і намагатися вирівняти через зворотний звʼязок. Конфлікт же знизу вгору частіше сприймається як деструктивна ініціатива. Це швидше сигнал, що з цією людиною складно працювати і вона створює додаткові ризики для команди. У цьому місці часто плутають поняття лояльності. Її сприймають або як сліпу згоду, або як щось токсичне і принизливе. Насправді лояльність значно простіша і практичніша. Це не про те, щоб мовчати або підтримувати будь-яке рішення. Це про розуміння того, в якій системі ти працюєш і які в ній правила гри. У кожного менеджера є свої цілі, обмеження і KPI. І твоя роль у цій системі — допомагати досягати цих цілей. Це не означає відмову від критичного мислення. Можна і потрібно давати фідбек, сперечатись, пропонувати альтернативи. Але різниця в тому, чи ти працюєш всередині цієї логіки, чи намагаєшся її зламати. Окремий важливий момент — це ситуації, коли ти не згоден з рішенням, але воно вже прийняте. Таке буде регулярно. Не всі рішення будуть ідеальними, не всі будуть збігатися з твоїм баченням, і не завжди в тебе буде достатньо аргументів або впливу, щоб це змінити. Тепер задача не саботувати рішення і не доводити заднім числом, що "воно було поганим". Тепер задача — зробити його настільки добре, наскільки це можливо в заданих умовах. Для мене це в тому числі ознака зрілості — зрілий спеціаліст вміє відпустити дискусію в момент, коли рішення прийнято, і переключитися в режим виконання. Незрілий — продовжує боротьбу через пасивний опір, затягування, зниження якості, токсичні розмови. Твій менеджер — це точка, через яку ти створюєш цінність в компанії. Не абстрактна "компанія", не "користувач", не "продукт", а конкретна людина з конкретними очікуваннями до твоєї роботи. А в нього чи неї так само є свій менеджер. І так до того, хто фінансує всю цю вечірку: фаундери, борд, інвестори. Тому якщо виникає системна незгода — не з окремими рішеннями, а з підходом, цілями і способом роботи — це вже не про дискусію. Якщо немає довіри і бажання працювати в цій логіці, проблема не в культурі і не в політиці. Це означає, що ти не в тій команді. Що робити А. Синхронізуватись: зрозуміти очікування, домовитись про правила гри. Б. Пробувати впливати корректно і професійно: через аргументи, через результат, через довіру. В. Йти: без драми, без "останнього слова", без спроб "довести правду". Нелояльність у цій історії не дає виграшної стратегії. Вона не допомагає змінити систему, але стабільно шкодить репутації і зʼїдає твій час. Ти або граєш в цю гру разом з менеджером, або витрачаєш час дарма.

#114. Робота в продукті — це прийняття рішень без повної інформації Типова помилка дизайнерів у продуктових командах — намагатися максимально прибрати невизначеність перед тим, як почати роботу. Логіка зазвичай звучить так: давайте спочатку зробимо повний ресерч. Звучить наче правильно, але в продуктовій роботі рідко працює так. Чому так думають У навчальних UX-моделях робота виглядає дуже акуратно: спочатку дослідження, потім синтез, потім ідеї, потім тестування. Процес виглядає послідовним. І створює відчуття, що спочатку треба повністю розібратися в проблемі, а вже потім переходити до рішень. Де ця логіка ламається У реальному продукті і бізнесі майже ніколи немає повної інформації, не буває достатньо часу, не буває впевненості у правильному рішенні. Команда повинна рухатися швидко. Є дедлайни, є плани запусків, є конкуренти. Тому чекати, поки вся невизначеність зникне, зазвичай просто неможливо. Тимпаче нереально досягнути 100% визначеності. Більшість продуктових рішень приймаються в умовах неповної інформації. І чим більше ти в ієрархії компанії, тим з меншою визначенністю тобі доводиться приймати рішення. Чим вище рівень рішення — тим: - менше даних - більше ставок - більше невизначеності - більший радіус впливу І це прямо пояснює чому senior-рівень відрізняється від junior. Junior хоче: - більше інформації - більше інструкцій - більше впевненості Senior вміє: - приймати рішення з 60%(умовно) інформації - запускати експерименти - рухати роботу вперед попри невизначенність Топ-менеджери майже ніколи не мають повної картини. Вони приймають рішення на основі часткових даних, сигналів і гіпотез. Як насправді працюють продуктові команди Зазвичай робота виглядає інакше — команда робить дві речі паралельно. 1. Робить те, що вже зрозуміло Наприклад: - базовий флоу - зрозуміла логіка фічі - існуючі патерни продукту Немає сенсу відкладати цю частину тільки тому, що інша ще не досліджена. 2. Розбирається з тим, що незрозуміло Наприклад: - як користувач приймає рішення - де виникають проблеми - який із варіантів працюватиме краще Тут вже має сенс робити дослідження, тестування або аналіз. Тому реальна робота рідко виглядає як красивий UX-процес, а скоріше робимо те, що зрозуміло, досліджуємо те, що незрозуміло, уточнюємо рішення по дорозі Це ітеративний режим, а не послідовний. Bias for action Саме тому в продуктових командах дуже цінується bias for action. Здатність рухати роботу вперед, приймати рішення при неповній інформації, уточнювати рішення по ходу. Багато дизайнерів намагаються зменшити невизначеність перед тим, як почати роботу. Продуктові команди зменшують невизначеність через роботу. Штука в тому, що б розуміти: - де потрібно зупинитися і розібратися - де достатньо робочого припущення - де потрібно просто почати робити І дуже часто найшвидший спосіб зрозуміти правильне рішення — почати щось робити і подивитися на результат. Fuck Around — Find Out

#113. Чому UX на курсах і UX у реальному продукті — це різні речі У дизайнерському середовищі UX часто сприймають як набір обовʼязкових інструментів: Double Diamond, дослідження, CJM, UX-метрики, оптимізація кількості часу котрий юзер витрачає на флоу. Цей список добре знайомий кожному, хто проходив будь-які курси або дивився UX-кейси. Але чомусь в реальності компаніям цей процес не дуже-то і потрібен. Компаніям потрібно інше — зменшити ризик від неправильних продуктових рішень. Де тут користувачі В вас виникне питання: "А як же турбота про користувача?", "А як же якість продукту?". Проблема в тому, що для бізнесу ці речі майже ніколи не є самоціллю. Компанії інвестують у UX тому що: - кращий UX → вища конверсія - кращий UX → краща активація - кращий UX → вище retention - кращий UX → сильніша конкурентна позиція. І для цього потрібна першочергова проблема з конверсією, з активацією, з ретеншном, чи з конкурентами котрі забирають ринок кращим юексом. Тобто турбота про користувача — це не моральна позиція. Саме тому поганий UX може існувати роками у монополіях або enterprise-софті — ризик втрати користувача там просто нижчий. Ви бачили колись Salesforce? Це ад. UX не може бути однаковим всюди Багато дизайнерів намагаються застосовувати один і той самий набір інструментів у будь-якій компанії. Але продукти живуть у різних фазах: ранній стартап, продукт у фазі росту, зрілий продукт, перезрілий продукт. І задачі там радикально різні. Тому і UX-інструменти будуть різні, та в різному рівні глибини відпрацювання. UX-процес не універсальний. Він залежить від стадії продукту і задач бізнесу. UX — це не набір ритуалів. Це спосіб зменшити невизначеність перед тим, як команда витратить час і гроші граючі в "угадайку". Early stage Коли продукт тільки шукає product-market fit, головне швидко перевіряти ідеї, знаходити напрямок, зрозуміти користувача. Корисні інструменти: інтерв’ю, швидкі прототипи, грубі перевірки гіпотез Не важливі: точні UX-метрики, оптимізація секунд Головний ризик тут зробити продукт, який нікому не потрібен. Але теж, може інвестору вистачає яєць і віри в себе. Growth stage Коли продукт вже працює і починає масштабуватися. Фокус змінюється: активація, onboarding, retention, експерименти. Тут UX-практики допомагають: - знаходити точки росту, але багато хто справляється і без них. - не ризикувати бюджетом випускаючі фічі, в котрих немає шансу активувати або утримати користувача. Зрілі продукти У продукті, який вже має PMF і стабільний бізнес, з’являються інші задачі, але з мого досвіду відбувається постійно одна й таж двіжуха. Багато рішень приймається на здоровому глузді, логіці і досвіді. Так працює більшість продуктових команд. Але у такого підходу є проблема, бо коли з’являються складні рішення, починаються суперечки: дизайнери думають, що рішення зрозуміле; продакт сумнівається і не хоче ризикувати, топ-менеджмент каже: "херня — перероблюйте". І тут без дослідження нічим відповісти. UX-метрики і "перезрілий" продукт Якщо говорити про "класичні" метрики юексу: час проходження сценарію, кількість кліків, micro-friction то це прерогатива великого бюрократичного бізнесу. Де треба шось оптимізовувати, але без різких рухів. Я працював в досить великих продуктах, і там ніколи нікого не збуджували фрази накшталт "Ми скоротили сценарій з 42 до 36 секунд". Такі метрики починають мати сенс тільки на гігантському масштабі, де навіть невелика оптимізація дає великий фінансовий ефект. Ну чи стає частиною багатострінкового звіту. Коротше UX не варто сприймати як набір обов’язкових практик. Хороший дизайнер дивиться на продукт і питає себе: де зараз найбільший ризик, де найбільша невизначеність, де команда може витратити багато грошей на неправильне рішення. А вже потім обирає інструменти для вирішення цих питань, і адаптує ці інструменти під ситуацію. У всіх інших випадках виходить дискредитація методик і нашої професії.

#112. Менеджмент як проектування аха-моментів, а не впровадження процесів На цих вихідних думав про те, що популярна тема з аха-моментом в менеджменті продуктів, дуже класно вкладається і на менеджерську роботу. Що таке аха-момент: Це момент, коли користувач вперше відчув реальну цінність продукту. І більшість великих продуктів намагається прискорити і закріпити цей момент, аби користувач скоріше і глибше відчув це "аха!". Приклади про пережиту цінність в команді: - Перший раз отримав корисні результати з ресьорчу — "ого, воно може працювати!" - Вперше привʼязав своє рішення до метрик і менеджмент погодився — "нічосі" - Почали планувати задачі і зменшилась паніка і срачка — "а шо так можна було" Якщо аха-моменту не сталося, цінність не отримана і не відчута, позитивного досвіду не має, активація не відбулась — ініціатива, проект, процес, артефакт відмирають. Приклад з процесом Короткостроковпе планування задач робити зазвичай дуже ліньки. Середньострокове на пару місяців тимпаче. Але якщо зробити хоча б більшменш адекватно, зʼявиляється передбачуваність і зникає частина фонового стресу. Аха-момент це саме коли ти розумієш шо ти знаєш шо треба буде робити, що ти робив і всі більш-менш заалайнені навкого цього. Звісно шось залетить незаплановане, але це не буде 100% незапланованого. Якось мені дизайнер каже: “Ти знаєш, я в пʼятницю знаю, що буду робити наступного тижня. Раніше в неділю нервував, що може на тижні прилетіти.” Приклад з артефактом Завжди на певних задачах підпушую робити тестування з користувачами. Для того щоб тут стався аха-момент, треба шо б була підходяща задача (а не будь-яка для якої тестування не зіграє ролі), шоб прийшли хоч трохи корисні результати, щоб вони допомогли потім захистити свою позицію перед командою. І отут теж "о, тепер в мене є сильна база для прийняття рішень". А потім команда починає челенджити задачу в дусі "нам здається що не зрозуміє ніхто", а ти вже "обмазався ресьорчем" і на всі мутні питання є що відповісти. З цього моменту ресьорч перестає бути "зайвою бюрократією" — він стає інструментом підкріплення позиції і аргументації. Приклад з розвитком команди Можна написати гарний документ по розвитку на 6 місяців, а можна подумати: де буде перший досвід зростання? Виділили, наприклад, необхідність качати комунікацію і презентацію. Можна залишити людину з цим, хай розбирається — єдине шо тут можна мабуть придумати сходу це пошукати курс "комунікація і презентація". А можна вибудувати досвід перших 2-4 тижнів навколо наступного: 1-2 дзвінка де ви нагадуєте і формулюєте основні теоретичні штука по презентації і комунікації, на другому тижні плануєте невеличкий виступ людині в середині команди (в своїй команді простіше), на третій тиждень на більш широку публіку на якомусь ревью, допомагаєте з підготовкою. Потім допомагаєте зібрати трошки позитивного фідбеку. Таким чином інвестиція часу і зусиль отримує своє повернення інвестицій, людина втягується, і вже вистачить мотивації і розуміння розвивати навичку далі. Що робить Отже ми можемо сфокусуватися не на впровадженні практик, а на доведенні людей до першого пережитого доказу цінності цих практик. Якщо ви не можете відповісти на питання “де людина вперше відчує користь цього процесу?” цей процес, швидше за все, помре. Тут можна навести приклади: новий шаблон, який тільки ускладнює; новий документ, який ніхто не читає; новий артефакт без швидкої користі. Перед тим як вводити нову практику, варто подумати: - Де і як швидко буде перший measurable результат? - Чи він буде видимим? - Як зробити щоб людина пережила його як власну перемогу?