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

Вообще, как помог понять эксперимент, большая часть моих запросов идёт по одному из 3 путей:

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

Справка от ИИ дольше формируется, в ней ту самую очень базовую информацию надо всё-таки выцеплять. А если запрос неоднозначен, как с теми же аббревиатурами, ИИ может дать отличную справку, но - по другому значению)

Это частично устраняется более подробным формулированием запроса ("что значит ABC в контексте X"), но... зачем писать больше?

Наоборот, поиск подробной информации по какому-то вопросу. Поиск тут нужен только для того, чтобы выйти на статью, где будут расписаны все детали. Короткая выжимка от ИИ обычно неплоха, но закрывает только 60-70% тех самых интересных мне деталей, так что всё равно приходится нырять в первоисточники.

Сюда же, кстати, можно отнести поиск изображений чего-то. Тот же Perplexity выдаёт и картинки, но 3-4 штук не всегда достаточно.

И, наконец, просто использование поисковика для ленивого перехода на нужный сайт. Ну да, это как в Гугле писать "Яндекс", но иногда это... проще?

И вот эти три сценария - это примерно 90% запросов в омнибоксе браузера. Моего, your mileage may vary. Так что пока я всё же предпочту оставить поиск поиском, а нейросетям выделю постоянное место в боковой панели браузера и закреплённые вкладки.

Про задачи, роли и позиции

Сегодняшняя тема, казалось бы, очевидна - но на практике приходилось сталкиваться с очень странно построенными командами. Поговорим о важности разделения трёх понятий: задачи, роли и позиции. И начнём с определений:

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

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

И третий уровень - позиция. Конкретная должность под конкретного человека.

В идеальном мире одна роль = одна позиция (или несколько одинаковых позиций). По факту сплошь и рядом бывает, что одному человеку приходится брать на себя несколько ролей. И это само по себе не страшно, пока соблюдаются два правила:

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

• Нельзя разделять одну роль между двумя позициями. Если вы договорились, что у вас аналитик и ТЗ пишет, и согласованием занимается, то тот, кому эта роль досталась, и должен это делать. Опять же, если постоянно согласование достаётся другому человеку - нужно либо перебросить задачу на другую роль, либо роль согласующего выделить другому.

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

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

Про нетерпимость к неопределённости

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

Но в разговорах между собой мы вечно утыкались в непонимание:

— Вот план на квартал. Три фичи.

— Не, ты скажи, какая когда будет.

— Вот относительные приоритеты, делать будем в таком порядке. Но точные даты будут только после ресёрча. Не страшно: по зависимостям никого не держим; по метрикам - всё просчитано, неделя туда или сюда именно здесь погоды не сделает.

— Не, ну даты-то какие?

— Точные даты я тебе могу назвать, но они ж из головы будут.

— Пусть так, но пусть будут.

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

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

Кто-то в ней плавает как рыба в воде - где-то данными, где-то вопросами, где-то просто допущениями собирая для себя и для других точки опоры.

Кому-то это некомфортно - но зато если им эти точки опоры дать, они разгонятся и принесут результат.

Хороший продакт должен уметь и то, и то - собственно, discovery это как раз процесс превращения неопределённости в определённость, а delivery - превращения определённости в импакт. Но и продукты, и продакты - разные, поэтому фактор готовности к неопределённости тоже обязателен к учёту для выбора работы и сотрудника.

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

Подбирался я к этой теме долго. От общего понимания, что разным людям по-разному даются разные задачи; через разделение задач на нацеленные на развитие и на операционную работу; через явное разделение команд на Run и Change.

Окончательно паззл сложился во время менторинга, когда я услышал похожие истории сразу от нескольких менти. Работа понятна, реализуема, но - не идёт. Слишком много операционки. Или наоборот, все хотят делать по науке, но недостаточно быстро.

И тогда я стал задавать прямой вопрос - а какой стиль работы в целом ближе? На развитие или на получение результата здесь и сейчас?

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

Людей с майндсетом Run:

• драйвит быстрый результат;

• не беспокоит необходимость возвращаться к одному и тому же предмету несколько раз;

• а вот подход "лучше день потерять, зато потом за час долететь" вызывает раздражение.

Типичные Run-овые задачи - это поддержание страниц в актуальном состоянии, поддержка, запуск экспериментов.

А майндсет Change:

• драйвит картина чего-то большого и красивого - но впереди;

• не любит возвращаться к уже сделанному, предпочтёт более сложную реализацию на перспективу;

• предпочтёт потратить побольше времени на подготовку.

Тут задачи уже другие: выстраивание процессов, инфраструктурные проекты, доделывание продукта после MVP.

Разумеется, шкала тут не дискретная, но всё же совсем универсалов я практически не видел - все явно склонялись либо к одному, либо к другому концу.

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