Олег Якубенков написал о разнице между Customer Development и Custdev.

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

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

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

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

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

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

О собеседованиях и найме

На днях прочитал отличную статью (https://vas3k.ru/inside/46/) о собеседованиях и найме. Написано в основном о том, как нанимать программистов, но озвученные мысли подходят и для остальных. Идеи близки мне по духу, потому что я считаю, что типичные собеседования это пустая трата времени. Вопросы о сложности алгоритмов или о бинарных деревьях не покажут ничего, кроме того, что человек об этом слышал и запомнил, а интервьюер тешит своё эго, потому что прочитал об этом 5 минут до интервью. А заставлять писать код на бумаге или на доске это вообще лютый зашквар.

Требования к будущим сотрудникам отличаются в каждой компании. Мы, как стартап, в первую очередь ориентируемся на то, чтобы человек был командным игроком и умел делать работу. Под "умел делать работу", подразумевается – брать и делать, без отговорок. Идеальный кандидат понимает бизнес и почему принимаются те или иные решения. Он готов иногда писать неидеальный код для быстрого тестирования гипотез. Он не пытается строить архитектуру на века, если в этом нет необходимости и не решает несуществующие проблемы. Такие качества человека проявляются в разговоре "за жизнь". Наблюдайте, как человек рассуждает, какие вопросы задает, как анализирует информацию.

ОК, на этом этапе определились, что человек нам нравится и мы готовы с ним работать в одной команде. Но как проверить технические знания? Для меня лучший тест – это сесть и вместе решить задачу, которую сами недавно решали в продукте. В таком варианте интервью будет сразу понятно как человек мыслит, как строит логические цепочки, какие аргументы за и против приводит, какие потенциальные проблемы видит, на какие грабли наступал и т. п.

После этого даём возможность задать вопросы о нас, чтобы понять заинтересован ли кандидат работать в компании в принципе. Ну а после этого жмём друг другу руки и готовим оффер, либо письмо благодарность за потраченное время.

О гибком мышлении.

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

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

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

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

Гибче Вас!

Про видимую демократию

Про видимую демократию

Я недавно вскользь упомянул такой способ принятия решений, но он достоин большего внимания.

Вы наверняка такое видели или даже делали сами (я точно грешен): руководитель организует встречу для обсуждения какой-то проблемы. Но приходит туда с готовым решением или идеей. Или даже презентацией. Ну потому что ты же руководитель/снователь `— ты всегда должен знать, что делать дальше 🙂

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

В итоге, участники чувствуют себя обманутыми, время на фиктивную встречу уже не вернуть, а возможность повлиять на что-то в ходе следующих встреч, никто больше не верит.

Но самое интересное начинается потом. Ведь это директор (а не команда) решил что-то делать. Единолично. Другие участники вряд ли хотят реализовывать решение, скорее всего не брали на себя никаких обязательств и уж точно не горят этой затеей. Короче, ничего сделано не будет.

Что с этим можно сделать руководителю? Во-первых, расслабиться и понять, что готовые решения никому не нужны. Не нужно пытаться быть самым сильным, смелым и умелым в работе с командой своих коллег. Командная работа не про это.

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

Чинить баги по TDD

Один из кейсов, которые я рассмотрю на своём мастер-классе 26 октября (https://tdd.timepad.ru/event/1074439/?utm_source=telegram&utm_medium=messenger&utm_campaign=mypost-bugs) — это исправление багов по TDD.

Вот прилетает к нам задача, скажем «Жму на кнопку — не работает». Обычно мы чиним такие баги весьма тупо — поднимаем фронт и бек, придумываем гипотезу, и начинаем дебажить: вносим исправление и жмём на кнопку. Если заработало — отлично, если нет — просто перебираем дальше гипотезу за гипотезой. Иногда мы перебираем гипотезы настолько беспорядочно, что даже не убираем следы предыдущих попыток.

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

Правильный процесс выглядит так: открываем контроллер в API, куда ходит кнопка, а дальше ставим под сомнение каждый нижележащий метод, проговаривая про себя гипотезы, к примеру: «я сомневаюсь, что метод get_users() не возвращает неактивных пользователей». Если сразу не находим теста, который доказывает обратное — пишем свой. Если тест падает — отлично, у вас уже есть тест, и остаётся только написать код. Если написанный тест не падает — git checkout --, и ставим под сомнение следующий метод.

Такой процесс заставляет вас тестировать баги изолированно — вы никогда не натолкнётесь ещё на один баг, который создали во время предыдущих бесплодных попыток. А ещё вы никогда не отправите в прод неработающее говно, потому что у вас нет состояния «кажется всё заработало» — всё или заработало, или нет.

Про адаптацию стажеров и младших специалистов

Наш руководитель веб-направления Таня Аладина интересно написала про адаптацию стажеров и младших специалистов:

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

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