Заметки про управление дизайн-отделом

Когда от вас напрямую зависят десятки или сотни сотрудников, вы невольно упираетесь в лимит времени, который можете потратить на каждого конкретного специалиста. Это описывается числом Данбара, т.е. кол-во социальных связей в зависимости от частотности общения с каждым отдельным человеком. 5-6 людей это близкий круг, то есть лиды, синьоры, ведущие специалисты, замы. Еще 10-15 человек это ребята на вырост, те, кто может через сколько-то лет стать лидом или шагнуть на один грейд выше. И все остальные 50-100 человек, о существовании которых вы знаете, с которыми иногда взаимодействуете, но не более того.

Людей много, и у руководителя возникает потребность делегировать, так как уделить время всем 150 людям — физически невозможно. Для делегирования нужно выбрать сотрудника, дать соответствующую зону ответственности, определиться с направлением его роста, и убедиться в наличии нужных навыков. И второй блок, про который многие забывают — наличие ресурса у сотрудника. Если сотрудник берет дополнительную работу при 100% нагрузке — что-то нужно убирать. Также, проверить наличие доступов/контактов к ЛПРам. На первую важную встречу можно прийти вместе с дизайнером и представить его как контактное лицо отдела дизайна для этой конкретной команды. На встрече сотрудник может заCommitиться — в данном контексте договориться, пообещать выполнить поставленные цели. Далее остается лишь планирование и контроль в зависимости от грейда сотрудников. И договориться о том, какой артефакт мы ожидаем в конце работы сотрудника. Это DoD (Definition of Done) — в данном контексте описание критериев, при которых задача считается успешно выполненной. И eNPS как оценка удовлетворенности команды.

Вам, как руководителю, подчиняется не человек, а конкретная роль/позиция. Это формальное подчинение мест друг другу, не важно, речь о функциональном подчинении или прямом. Подчинение идет исключительно по навыкам и должностным инструкциям конкретного дизайнера. Но раз есть формальное подчинение, значит есть и неформальное. Скажем, у нас есть обычный мидл-дизайнер как винтик в механизме, идеально подобранный исполнитель роли. Но в IT играет роль личность человека — тот, кто переживает за результат, структурирует работу, мучается от несовершенства результата, стучится в закрытые двери. И нужны границы, нельзя полностью размывать границу между ролями и личностями. При этом, организационная структура и структура личностей коллектива никогда не совпадут, но должны дополнять друг друга. Нужен эксперт с полей — есть описанный выше мидл-дизайнер, который лидер направления iOS E-commerce, а если нужно использовать формальную власть для принятия решения — есть лид-дизайнер. В такой системе неизбежен рост команды за счет взаимоотношений между сотрудниками. Кто-то может быть коучем, т.е. задавать вопросы. Или ментором, т.е. давать советы. Ментор — всегда играющий капитан, с энергией в голосе и интересом/экспертизой к предметной теме. Чтобы быть хорошим ментором, нужно интересоваться людьми. Один из критериев результата работы с ментором или коучем это уверенность. Лид может поговорить с джуном и стать более уверенным в принятом решении. Да, бывает и такое.

Но даже если вы отладили все процессы производства и у вас предсказуемый производственный задел, ваша команда закрывает высокие требования к качеству, опыт и способности команды превосходят ожидания, это не отменяет рисков, что клиент вовремя не согласует макет и/или не предоставляет информацию/контент. И если ваш ключевой сотрудник не работает по причине болезни/отпуска/увольнения, и его не получается заменить, то это провал в выручке на конкретном заказе. А уж если полностью передать команду под управление неквалифицированного менеджера на стороне клиента, то вероятность появления мелкого пушистого зверька на проекте чуть больше, чем 100%. Это то, на что необходимо уделять свое личное время, а не пытаться спихнуть на замов. Это все часть риск-менеджмента, и карьера менеджера всегда на кону за невыполнение своих обязательств. У любого риска есть вероятность его наступления и у риска есть последствия.

Замы могут увольнять. Если сотрудник не особо ценный, и постоянно косячит — увольнение по 81 статье ТК. Нельзя человека уволить на основании устных заявлений, необходимо фиксировать нарушения. Оставить включенным ноутбук и отойти за кофе — уже нарушение, которое можно зафиксировать. Если компания обеспечивает нужный режим соблюдения NDA, то это будет прецедентом. Но такие моменты должны быть заранее прописаны в трудовом договоре с сотрудником, или в дополнительном соглашении. Вы не можете запустить DLP-систему для слежения за сотрудником и использовать ее как доказательную базу, ведь сотрудник пойдет в трудовую инспекцию. Сначала легитимизируем DLP-систему, прописываем в договоре с сотрудником, что слежение за выполнением трудовых обязанностей будет вестись через DLP. И лишь потом увольняем за факт фриланса, использования ресурсов компании по не назначению и так далее. За общение с семьей в рабочее время нельзя уволить, это личная жизнь сотрудника, прописанная в конституции. Куда проще увольнять за регулярное нарушение KPI план/факт, уменьшение срока доставки фичи, кол-во дизайн-багов на продакшене, время проверки гипотез (должны быть часы, а не месяцы). Но сотрудник всегда может позвать трудовую инспекцию, так что аккуратнее.

Процесс увольнения также входит в грейдовую схему:

Лид/С-левел: определит, что из-за сокращения прибыли пора сокращать отдел на 30%.

Сеньор: решит, кого уволить, кому отменить премии и какие активности свернуть, чтобы пережить турбулентность, но при этом сохранить костяк команды когда/если ситуация улучшится.

Мидл: определит коммуникационные активности, не станет поддерживать негатив сотрудников.

Джун: напишет жалобный пост в интернете, что его уволили.

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

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

Потребуется регулярная рефлексия как представление в сознании, что делает сотрудник. Это противоположность абстрактному мышлению. Так как рефлексия неизбежно базируется на нашем личном жизненном и профессиональном опыте, то велик шанс ловушки по превращению прошлого в будущее и будущего в прошлое. Или более просто: ожидать, что наш прошлый опыт предскажет будущее, а это всегда ошибка. Если вы 15 лет назад смогли убедить C-level в необходимости делать мобильное приложение, не факт что аналогичных результатов добьется выбранный сотрудник. Не потому, что он хуже вас 15 лет назад, а потому что знания C-level’а, внешние экономические условия, наличие ресурсов на рынке, цели компании и государства совершенно не такие, как были 15 лет назад.

  • Грейты (grade) — это те самые джун, мидл, синьор, к которым привязаны условные 80, 150 и 300k.
  • Рейты это оплата за час.
  • Аутстафф — передача человека на сторону заказчика, скорее всего уровень стагнирующего мидла.
  • Аутсорс — человек выполняет задачи для вашего клиента по контракту с гарантией за результат.
  • Тимлид больше про бизнес, техлид про технологии.

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

Признаки роста мидла в синьора: углубляется в технологии, или другие намеки на профилизацию. Берет OKR на квартал, в конце квартала приносит результат. Если мидл решает задачи, то синьор — проблемы. Начинает работать с высоким уровнем неопределенности. Декларативно, синьор это тот, кого взяли на позицию синьора. Императивно, это тот, кто помогает расти бизнесу, а не просто делает задачки. Синьор берет проблему и решает, а не создает. Учитывая коммуникацию между командами. Как в криминальном чтиве: человек, который приезжает и все решает.

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

Признаки роста синьора в техлида: умеет переключаться между стилями лидерства Херси-Бланшара (директивный, наставнический, делегирующий, поддерживающий).

Вы как руководитель должны проводить one-to-one и Performance Review.
Вы отвечаете за задачи, бюджет и сроки. Если детальнее, то обязанности могут включать:
•‎ планирование ресурсов для выполнения задач
•‎ контроль сроков и качества выполнения задач
•‎ организация инфраструктуры проекта
•‎ контроль бюджета и рентабельности задач
•‎ приемка задач
•‎ актуализация документации
•‎ коммуникация с клиентом (и с бизнесом, и с техническими департаментами)
•‎ эскалация проблем
•‎ формализация задач для исполнителей
•‎ ответственность за сложные вещи

Так, если рассмотреть навык создания дизайн-ассетов, то уровень по грейдам будет распределен следующим образом:

  • Middle: итеративная предсказуемая работа для создания и предоставления ассетов достаточного качества.
  • Senior: создает ассеты быстро с сильным пониманием фичей, для которых ассеты делаются. Это помогает команде быстрее двигаться вперед. Является источником знаний для команды о лучших практиках создания ассетов.
  • Lead: первое контактное лицо при возникновении сложных, трудных или запутанных проблем, требующих решения. Занимается задачами, с которыми возникают проблемы у менее опытных дизайнеров. Обеспечивает менторство для младших дизайнеров.
  • Design Director: не занимается созданием ассетов самостоятельно, а работает с командой, определяя лучшие практики, развивая всех сотрудников для максимально эффективной работы отдела в целом.
  • Design Executive: про создание культуры и пропагандирование UX/UI.

Технические знания:

  • Middle: в достаточной степени владеет инструментами и может быстро работать над типовыми задачами.
  • Senior: обладает экспертными знаниями об инструментах и методах работы. Является источником знаний для коллег по техническим вопросам. Часто повышает свою квалификацию без напоминаний.
  • Lead: эксперт в своей области. Общается с другими отделами про слодные задачи. Часто осваивает новые навыки.
  • Design Director: обладает глубоким пониманием технической стороны дизайна, но не обязательно все еще умеет работать руками. Отвечает за эффективное общение между отделами.
  • Design Executive: обладает достаточно глубоким пониманием дизайна, чтобы четко и лаконично формулировать позицию дизайн-отдела в соответствии с направлением развития компании.

Принятие решений:

  • Middle: решения на основе консенсуса, ждет согласования от старших коллег.
  • Senior: опытен в принятии решений, который может выделить необходимое количество времени для сбора информации из различных источников и принятия решения.
  • Lead: уверенно и обдуманно принимает решения. К нему часто обращаются менее опытные дизайнеры при ступоре и для решения проблем. Способен сам собрать информацию для принятия обоснованного решения.
  • Design Director: принимает решения высокого уровня, которые влияют на межфункциональные команды. На него смотрят во всем коллективе как на высокоэффективного сотрудника и человека, принимающего решения, который может разблокировать других. Принятые решения позволяют другим работать лучше.
  • Design Executive: принимает важные стратегические решения, которые влияют на итоговый результат компании. Дает полномочия. Формирует культуру принятия решений.

Понимание индустрии

  • Middle: в целом, примерно разбирается в тенденциях отрасли. При разработке дизайна часто полагается на интуицию.
  • Senior: хорошо разбирается в тенденциях отрасли и стандартах дизайна. Использует эти знания для разработки дизайна.
  • Lead: эксперт высокого уровня в дизайне (по своей специализации). Может сформулировать лучшие практики для команды. Помогает обосновать выбор дизайна продукта.
  • Design Director: обладает экспертными знаниями в своей области и имеет богатый опыт и понимание других областей дизайна.
  • Design Executive: отраслевой эксперт с проверенным послужным списком, пользующийся большим уважением в своей области.

Решение проблем

  • Middle: понимает проблемы, сформулированные руководством. Умеет эти проблемы решать, не всегда изящно.
  • Senior: обладает сильными навыками решения проблем и понимает, как правильно изолировать проблему с учетом контексте, решить ее и прийти к цели. Эффективно работает с другими заинтересованными сторонами, чтобы прийти к решению.
  • Lead: четко формулирует проблемы для команды, объединяя команду для решения больших проблем. Общается на межфункциональном уровне. Всегда решает проблемы в контексте пользователя, при этом следит за тем, чтобы цели заинтересованных сторон также принимались во внимание.
  • Design Director: является невероятно эффективным решателем проблем. Учитывает потребности как заинтересованных сторон, так и пользователей. Создает лучшие практики и позитивную культуру решения проблем, ориентированных на пользователя, для команды. Объединяет команды дизайнеров и другие дисциплины вокруг этих решений.
  • Design Executive: выявляет и упрощает сложные проблемы высокого уровня. Создает согласованность в направлении дизайна.

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

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

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

По soft skills трудно структурировать знания по конкретным навыкам. Благо, существует матрица софт-скилов Сета Година, из которой я для себя выделил следующие поинты:

  1. Первостепенно самоконтроль, стойкость в сложных ситуациях
  2. Выход из провалов и неудач, адаптивность к изменяющимся требованиям, принятие рисков, этика даже не публично, уметь искать способы сотрудничества, эмоциональный интеллект
  3. Далее мудрость: наставничество, дипломатия, критическое мышление, разрешение конфликтов. Начинает чувствоваться переход с мидла в синьоры или лиды. Из подмастерия в мастера.
  4. Влияние — управление талантами, создание социальных связей, обратная связь без эго, напористость
  5. Продуктивность — навыки совещаний, мужество и предпринимательское мышление, делегирование для повышения производительности
  6. Восприятие — инстинкты на тренды

Но ценности структурировать легче:

Attitude — отношение относится к мышлению, точке зрения и подходу к конкретной ситуации или цели.

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

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

Аналогично, структурирован и эмоциональный интеллект, спасибо за это Дэниелу Гоулману. Его модель принято объединять с картой эмоций Роберта Плутчика.

OKR

OKR (от англ. Objectives and Key Results «цели и ключевые результаты»). OKR — Метод, используемый в современном менеджменте для управления проектами. Позволяет синхронизировать командные и индивидуальные цели и обеспечить эффективный контроль над реализацией поставленных задач.

Планирование: цели-метрики-проекты-ресурсы. Цели и метрики связаны с OKR. Метрика это похудеть на 5кг, а цель это красиво выглядеть на пляже. Заработать x5 денег для компании это метрика, а для чего? Чтобы овнер купил себе яхту, и на заводе появилось новое оборудование к концу года — это цель. По каждой метрике ставится таргет, то есть сколько % роста должно быть на определенный момент времени. Таргеты пересматриваются, метрики остаются на долгий срок.

OKR планируется на квартал и год. Есть вдохновляющая цель, и под ней есть key results, которые к этой цели должны привести. Квартальные планы про наращивание метрик, или планирование на год — все это про ответ на вопрос, какую веху хотим пройти за отведенный срок.

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

Cynefin

Мы понимаем, что:

  • Чем выше твоя позиция, тем больше ты менеджер и меньше продакт;
  • Если ты хочешь регулярно получать предсказуемый результат, то придется ввести регулярный менеджмент;
  • Он действует для любой среды, но имеет разные формы и требует адаптации;
  • Определить среду поможет модель Киневина;

Модель Киневина (Cynefin Framework)  представляет собой управленческую концепцию, которая помогает принимать решения в зависимости от условий среды, в которой находится управленческая система. В регулярном менеджменте нету места подвигам, геройским оформлениям презентации за ночь до конференции и прочей романтике, т.к. мы стремимся к предсказуемой среде. Киневин помогает понять, в какой среде мы находимся, за счет причинно-следственных доказанных связей. Киневина состоит из трех базовых систем: ordered system, complex system и chaotic system. Дополнительно выделяют disorder system и simple system. Очень хорошо прочищает мозги. Особенности сред:

Хаотичная среда это очень редкое явление, когда нет времени на нормальную работу и просто катим на прод хоть что-то. Действуем -> получаем результаты -> реагируем. Конечно, многие думаю что живут в хаотичной среде, потому что у всех гибкий Agile. Но правда в том, что хаотичная среда это инновационные стартапы. Ты пилите мессенджер для государства и ничего не получается спланировать? Это не хаотичная среда, просто у вас не налажены процессы.

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

В простой среде наказывают за ошибки. Простая среда предсказуемая и с минимальными рисками. Если отошел от инструкции — это косяк, а значит получи штраф, и это ок. Это не ошибка эксперимента, а попросту косяк, т.е. человек знал, как надо сделать, но все равно не сделал. То есть все должно быть по регламенту. Регламент это описанный порядок действий с указанием этапов выполнения задачи, ответственных, сроков, точки контроля. Регламенты в больших компаниях пишутся отдельными отделами, но в продуктовой разработке, есть бизнес-процесс разработки, правила технического ревью, процесс выкатки и откатки на прод и возвращения на ре-дев. Например, регламент хранения информации обо всех проведенных исследованиях. Чтобы регламент работал, он должен быть включен в онбординг, описан простым языком и лежать на видном месте.

Ошибки бывают разные. Лично я делю их на ошибки недостатка навыков, ошибки неправильные решения и ошибки интерпретации. Примеры:

  • У свитча инвертированы состояния вкл/выкл — навыки
  • Отсутствует следование регламентам — навыки
  • Слабая эстетика — навыки
  • Чрезмерное усложение компонентов — навыки
  • Неправильное поведение в нетипичной ситуации — неправильные решения
  • Неправильная реакция на чрезвычайную ситуацию — неправильные решения
  • Превышение полномочий — неправильные решения
  • Неправильная оценка сроков — ошибки интерпретации

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

Simple / Clear — мы точно знаем один простой и понятный путь, как прийти из точки А в точку Б. Например, для решения типовой проблемы в офисе банка не нужен agile. Или если стоматолог начнет чинить зубы по agile, а не по четкой отработанной схеме, то наверное это плохой стоматолог. Идеально для операционных команд. Используются только лучшие практики и жесткие ограничения.

Изменчивая/запутанная среда требует регулярный менеджмент больше, чем предсказуемая/простая среда. Это поможет креативному мышлению в команде, так как появится время и пространство для экспериментов. Под регулярным менеджментом мы понимаем систему с описанными процессами, распределенными и записанными зонами ответственности, есть ресурсное планирование, понятная система опережающих метрик и предсказуемые результаты и, что не менее важно, предсказуемые усилия. В хаотичной и запутанной среде наказывают за невыполнение коммитов или любое нарушение доверия. Финансовые штрафы очень редко применяются, это самое последнее средство. Так как штраф это роспись руководителя в том, что он бессилен (в сложном IT). В качестве наказания можно сокращать плюшки, вроде понижение качества мед. страховки или требование формального процесса взятия больничных. Нематериальные наказания это уменьшение зоны ответственности, уменьшение объема интересной работы, понижение грейта, негативная обратная связь, более жесткий контроль, уменьшение кол-ва внимания на сотрудника, исключение из управления.

Complex — есть стартовая точка А, и есть несколько точка Б. Это как раз про Agile и эксперименты. Мы должны экспериментировать, смотреть на результат и реагировать. Выясняем ограничения и они развивают продукт.

Complicated — мы строим план на вере в идею, идем к желаемой идее, но должны экспериментировать. И реагировать. Сложная и упорядоченная среда. Самый простой пример это разработка ПО. Это Kanban. Редко на берегу понятно, что нужно делать на уровне детальных задач. Но так как команда умеет делать ПО, то она его сделает. Поэтому делается минимальный продукт -> рынок реагирует -> собираем аналитику и думаем. Это направляющие ограничения. В такой среде нужны очень квалифицированные и опытные специалисты, которые знают хорошие практики. OKR и диаграмма Ганта это основные инструменты. И цикл Деминга (PDCA = Plan -> Do -> Act -> Check), который обеспечил японское чудо. На примере диаграммы Ганта: разная информация для разных ролей. Например, степень детализации временной шкалы может быть как по дням, так и по месяцам. Дополнительно, можно отобразить комментарии с важных встреч. За каждую задачу назначен ответственный.

Среда склонна меняться. Любая индустрия начинается с хаотичной среды, потом становится сложной, но понятной (исследуй -> результаты -> реагируй). Со временем среда становится лучше, и модель работы переходит к осознай -> анализируй -> реагируй. И конечная точка развития это Все ясно: осознай -> категоризируй -> реагируй.

Бюджет отдела

Существуют разные модели финансирования отдела дизайна. В любом случае, считать нужно не часы, а деньги. Можно выделить два типа бюджетирования: по фикс-прайсу или time-to-material.

Например, у нас бюджет 5 млн / 30 дизайнеров ≈ 1 500 000 / чел в год. В месяц это 125к или 744 ₽/ч. Зарплата также считается просто: НДФЛ на данный момент 13%. Фонды ПФР, ФСС, ОМС, ФСС — 7.8% для IT-компаний. ЗП + (ЗП * 0.13 / 0.87) + (ЗП + НДФЛ) * 0.078), например 200 000 + 29 885 + 17 929 = 247 814. Теперь добавим немного реалистичности: 247 814 / 135 (месячная выработка за вычетом отпусков, отгулов, выходных, больничных) = 1 835. + сверху докидываем затраты на смузи и признаем, что мы уже взрослая компания. Настоящий стартап это не смузи, денег же нету. Если вы получаете деньги в долларах от клиента, то и сотрудники должны их получать в долларах. Иначе на скачках курсов валют можно разориться и не выполнить зарплатные обязательства. Если же вы в корпорации, то для повышения зарплаты придется общаться с C&B.

При стандартной минимальной маржинальности для студии 20-30% можно составить такую табличку:

РольСколько стоит месяцСколько стоит час
Middle веб-дизайнер 180 0002 650
Senior дизайнер iOS200 0002 850
Продуктовый дизайнер250 0003 400
Middle веб-дизайнер 160 0002 400
Графический дизайнер/иллюстратор140 0002 200
Lead веб-дизайнер 350 0004 500
Ведущий продуктовый дизайнер400 0005 050
Middle iOS-дизайнер160 0002 400
Middle Android-дизайнер160 0002 400

Отслеживание оперативного списка задач:

ДатаПроектЗадачаОписаниеТрудозатратыКомментарий
01.07.2022Qewc monitoringСсылка на Jira8
02.07.2022Qewc monitoringСсылка на Jira8
03.07.2022Qewc monitoringСсылка на Jira8
04.07.2022AZAQСсылка на Jira8
05.07.2022Qewc monitoringСсылка на Jira8
08.07.2022Qewc monitoringСсылка на Jira8
09.07.2022Qewc monitoringСсылка на Jira8
10.07.2022COWI Gulf AS Ссылка на Jira8
11.07.2022Qewc monitoringСсылка на Jira8

Проверка оплаты за работу по задачам:

Дата отгрузкиСуммаНаправлениеКонтр
агент
Приме
чание
Статус счетаДата ожидаемой оплатыСтатус оплатыСтатус акта
12.07.2022МскВыставлен18.07.2022ОплаченВыставлен
12.07.2022БангалорНе выставлен18.07.2022Не оплаченВыставлен
12.07.2022МскВыставлен18.07.2022ОплаченВыставлен
12.07.2022СингапурНе выставлен18.07.2022Не оплаченВыставлен
13.07.2022МскНе выставлен19.07.2022Не оплаченВыставлен
13.07.2022БангалорВыставлен19.07.2022ОплаченВыставлен
13.07.2022СингапурНе выставлен19.07.2022Не оплаченВыставлен
13.07.2022СингапурНе выставлен19.07.2022Не оплаченВыставлен
13.07.2022БангалорВыставлен19.07.2022ОплаченВыставлен
15.07.2022БангалорНе выставлен22.07.2022Не оплаченВыставлен
15.07.2022СингапурНе выставлен22.07.2022Не оплаченВыставлен
15.07.2022СингапурВыставлен22.07.2022ОплаченВыставлен
18.07.2022БангалорНе выставлен25.07.2022Не оплаченВыставлен
22.07.2022СингапурВыставлен25.07.2022Не оплаченВыставлен

Проверка, что сотрудник приносит отделу прибыль:

ОплаченоНе оплаченоКлиентОбщ. ставкаСтавка
176Сбер1232
10076Альфа824
176Сбер1032
176Сбер1220
176СовКомБанк1224
176Сбер832

Нигде выше не указаны стажеры и джуны. Стажеров всегда считают отдельно, так как они очень дешевые и не всегда полезные.

От проектов с фиксированной оплатой нужно энергично отказываться в пользу T&M уже на 15–20 сотрудниках, иначе рост отдела/студии невозможен. Для роста нужно выходить на крупных клиентов, которые умеют управлять дизайнерами сами. И не бояться давать прямой доступ к своим сотрудникам. Если сотрудники и клиенты обладают соответствующим уровнем навыков и адекватности, разумеется. Управление проектом на стороне клиента не равно его компетенции в вопросе, это видно во всех клиентских сегментах, за исключением компаний, кто через аутстаф пылесосит рынок. Тендерные проекты в 90% случаев не предполагают T&M. Даже если вы умеете управлять проектом/продуктом не хуже клиента, все равно оказывается выгоднее, спокойнее и лучше и для вас, и клиента, и продукта, и пользователей, работать по T&M.

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

Найм сотрудников

HOGAN — Это международная система независимой оценки личности для отбора и развития персонала. Очередной стандартизированный опросник. Для выявления мотиваций часто проводится тест Хогана. И тесты про спиральную динамику. Из более классических, старый добрый «дом-человек-дерево»: сначала кандидат рисует дом, человека и дерево, и далее заполняет специальный опросник. Так, если первым рисуется дерево, то кандидат про сохранение своей духовной энергии. Другой тест это несуществующее животное, после рисунка спрашиваются вопросы, типа чем животное питается? где обитает? чего боится?

Если идти более сложным путем, то оценка экспертов может производиться по индексу Хирша. Этот индекс никто не любит, но он активно используется и базируется на кол-ве опубликованных научных работ и уровне цитирования. Звучит подходяще для нас? Скорее всего нет, тогда возьмем второй популярный метод PageRank или HITS. Аналог ранжирования страниц, но для поиска экспертов.

Вопросы, которые также можно задать потенциальному сотруднику:

  • Что вам нужно в вашей следующей роли, чтобы вы были довольны своим выбором работодателя? Какие вещи для вас не подлежат обсуждению.
  • Какой самый ценный отзыв вы когда-либо давали? А получали? Что сделало его таким ценным?
  • Как много сотрудников с прошлого места работы продолжают работать с вами сейчас?
  • Чем вы больше всего гордитесь на сегодняшний день? И это не обязательно должно быть связано с работой.
  • Можете ли вы рассказать нам о случае, когда вы получили конструктивную обратную связь и что вы сделали с ней после?
  • Можете ли вы рассказать нам о случае, когда вы давали конструктивную обратную связь и как она была воспринята человеком?
  • Как вы узнаете, что что-то «достаточно хорошо»?» «Как вы выявляете недостатки и устраняете их?
  • Вы не успеваете выполнить задачу к дедлайну. Ваши действия?
  • Как выглядит успех для этой роли, и как вы видите ее развитие в ближайшие 1/2/3/5 лет (в зависимости от стабильности экономики)?
  • Что бы вы сделали, если бы посчитали, что кто-то действует вопреки интересам компании?

Также, на какие вопросы вы должны иметь ответы:

  • Какова политика неоплачиваемого отпуска?
  • Какие цели нужно достигнуть во время испытательного срока?
  • Что вы больше всего цените в культуре компании, и никогда бы не изменили?
  • Использование отпусных дней авансом, до их начисления
  • Разделение на оклад и премию. Серая/белая/черная зарплата.
  • Как рассчитывается бонус и какой показатель был за последний год.
  • Понижается ли зарплата на испытательный срок?
  • Есть ли система грейдов для прозрачного роста.
  • Тип офиса: опенспейс, кубиклы, отдельные комнаты.
  • На какой системе принято работать: MacOS, Windows, Linux.
  • Ставите ли вы таймтрекеры с снимальщики экранов?

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

Судный день

Минимум раз в год вы проводите performance review ваших сотрудников. Нужно дать обратную связь сотруднику про его уровень работы. Возможно, увеличить зарплату или порезать бонусы. Возможны следующие варианта оценки: meets none, meets some, meets most и meets all. И более позитивные: exceeds expectations, greatly exceeds expectations, redefined expectations. Очевидно, что оценка это не экспертное мнение руководителя, есть критерии. Первый и самый важный это влияние на продукт, например, подняли метрики. Под вторым номером уровень совершенства технического мастерства: не испортили ли сотрудники дизайн-систему или написали неподдерживаемый код. Третье — уровень менеджмента себя и команды, умение работать по задачам. Нравится ли людям делать задачи по инструкциям вашего сотрудника? Хорошая ли репутация у сотрудника? Можно завязаться на карту компетенций/star map, в которой отмечать навыки, которые сотрудник улучшил или растерял за год.

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

«Взаимодействуя с данным сайтом, вы, как пользователь, автоматически даете согласие согласие на обработку персональных данных» Согласие

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.