Написали о том, как увеличивали дизайн-команду

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

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

В конце интенсива неделю назад (программа в инкубаторе состоит из недельного интенсива и последующих воркшопов до 2020) мы тренировались питчить. На нас даже пришли посмотреть внешние слушатели-инвесторы.

На питч отводилось строго 3 минуты. Обрисовывать (питчить) стартап придется бессчетное количество раз, поэтому в инкубаторе это первое с чего все начинается, последнее, что нас ждет на «Демо-дне» и самый частотный инструмент при общении с любым советником, партнером, инвестором и так далее.

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

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

Неплохо также заранее разобраться с какой стороны от экрана выгоднее всего стоять и вообще подумать про образ, но об этом отдельно. Я на прогонах тренировал только механику (к негодованию нашего тренера), а с историей выкладывался только на самом выступлении, мне так проще сохранять энергию.

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

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

Знание термина Customer Development в англоязычном IT очень низкое. Не говорите, что вы кастдевили своих клиентов, вас не поймут. Также это будет звучать странно в контексте изначального значения термина.

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

1. Обнаружение клиентов;
2. Подтверждение клиентов;
3. Создание клиентов;
4. Построение компании.

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

В русскоязычном IT методология сузилась до конкретного метода проверки гипотез — глубинных интервью. То, что мы называем кастдев, англоязычные коллеги называют User Research.

https://gopractice.ru/customer-development-custdev/

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

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

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

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

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

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

Индустрия — это экосистема. Большинство проектов реализуется несколькими компаниями, командами и отдельными специалистами в симбиозе. Клиенты обращаются в компанию, которая нанимает себе в помощь продакшн для разработки и т. п.

Типовая производительность в час — полная профанация. Точная предварительная оценка проекта невозможна в принципе. Всё зависит от конкретного проекта и конкретного специалиста.

Типы проектов:
1. Мозги — решение ранее неизвестных задач. Проект похож на исследовательскую работу и привлечённые специалисты должны быть опытными профессионалами, имеющими сложившийся подход к поиску нестандартных решений.
2. Седина — внедрение проверенных отраслевых или технологических наработок, которыми обладает компания-подрядчик. Например, программа лояльности в розничной сети. Компании, работающие над такими проектами, специализируются на определённых отраслях.
3. Процедуры — типовые задачи, с которыми могут справиться различные специалисты с заданной квалификацией. Например, разработка программных компонентов по детальной спецификации в уже определённой технологической среде.

Слабые специалисты не вытянут проект типа «мозги». Если крутые будут делать слишком простые проекты, разработка будет слишком дорогой, а специалисты потеряют мотивацию и покинут компанию.

Типы исполнителей:
1. Фармацевт (самый распространённый) — классический аутсорсинг. Клиент приходит со сформулированной задачей, исполнитель через некоторое время выдаёт результат.
2. Сиделка — агентства. Исполнитель интенсивно общается с клиентом, работа выстроена вокруг долговременных целей клиента.
3. Нейрохирург — системные интеграторы и технологические исследовательские центры. Похоже на фармацевта, но часто сутью задачи является выяснение, в чём именно заключается проблема клиента и поиск её решения. У задач — преимущественно технологический характер.
4. Психотерапевт — продюсеры ИТ-проектов. Клиент обозначает проблемы в бизнесе или возможные точки развития, а исполнитель помогает подобрать наиболее удачный способ решения.

Бизнес-модели:
1. Ресурсная — продажа труда специалистов по часам или проектам. Компания должна продать как можно больше ресурсов, что неизбежно приводит к типу проектов «процедуры» и формату работы «фармацевт» или «сиделка». Клиент всегда может сменить подрядчика. Подрядчики конкурируют ценой, уровнем специалистов и качеством менеджмента.
2. Продажа уникальных знаний — цена услуги формируется не себестоимостью, а ценностью для клиентского бизнеса.

«Любая компания с регулярными расходами пытается добиться регулярного поступления оплат от клиентов. А они возможны в случае, когда команда специалистов как можно дольше работает над одним и тем же проектом, и её состав не меняется. Именно с этим связана любовь компаний-разработчиков к скраму, т. к. у проекта нет разных по стоимости этапов, команда максимально однородна и специалисты взаимозаменяемы. Работа над проектом разбита на равные отрезки времени — спринты, за которые удобно выставлять регулярные счета. Дело как обычно в деньгах, а вовсе не в каком-то волшебном качестве скрама».

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

https://mityakin.ru/paranoid-method-book-1