Про сложность и размер

В универе я получил один абсолютно бесполезный для современного мира навык: писать много и говорить сложно. Ведь если ты пишешь курсовую, реферат или диплом – у тебя обязательно есть ограничение по количеству страниц. Если объяснить свою мысль на паре листов А4, используя формулировки, которые поймут даже дети – тебя обязательно пошлют переделывать, ведь это не серьезно. Такой вот анти-метод Фейнмана.

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

Ещё из разработки я запомнил: если код получается слишком сложный – мы делаем что-то не так. Причем иногда проблема где-то на другом этапе, не в коде (а в проектировании, в дизайне, в самой идее новой фичи). Этот триггер можно использовать для всего: если у вас получается сложный/непонятный процесс, письмо, отчёт – в нём что-то не так, надо порефакторить.

В общем, хотите повысить конверсию людей в действия? Не отнимайте у них много времени и объясняйте проще, что вы от них хотите.

Про проактивность

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

Приятным бонусом к проактивности идёт свобода действий:

– Если разработчик рассказывает, что он делает и какие у него проблемы – менеджеры не докучают ему вопросом «ну че, когда будет готово?».
– Если менеджер предоставляет руководителю в отчете всю нужную информацию о проекте/команде – руководитель не будет навязывать свой формат отчёта или процесс, его проблему уже решили.
– Если разработчик пишет код для других разработчиков, а не для машины, заботится о читаемости и объясняет непонятные места – ему не нужно тратить время на ответы другим разработчиком во время ревью, а апрув он получает быстрее.
– Если дизайнер объяснил свою идею текстом/стикерами/схемами на макетах, а не просто скинул картинки – команде не придётся назначать звонок «обсуждаем новые макеты», а дизайнер этот час времени будет заниматься любимыми делами.

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

Приходит работник к барину и говорит: «Барин, скажи, почему ты Семёну такому же работнику платишь 5 рублей в день всегда, а мне только 5 копеек?». Барин говорит: «Садись, сейчас объясню. Ой, смотри, за окном телега едет. Сбегай и спроси, не сено ли везут». Работник сбегал и говорит: «Да, сено везут». Барин опять говорит: «А ты спросил с каких лугов везут? С Семёновских?». Работник: «Не знаю». Барин: «Ну, сходи спроси». Работник сходил. Пришёл и говорит: «С Семёновских». Барин опять спрашивает: «А какой покос? Первый или второй?». Работник опять побежал спрашивать. Пришёл и ответил, что первый. Барин опять: «Почем они будут продавать?». Работник опять не знал ответа на этот вопрос. Хотел бежать спрашивать.*

В этот момент заходит Семён и говорит: «Барин, там сено везут с Семёновских лугов первого покоса, стоит 5 рублей, но я уже сторговался на 3. И пока телегу завернул, она стоит в нашем дворе. Что дальше делать будем?».

В общем, будьте как Семён. Качайте проактивность.

Про делегирование

1. Все задачи, которыми я занимаюсь очень важны. Я не могу от них отказываться.
2. Нужно быть очень ответственным, чтобы их выполнять. У нас пока нет другого такого человека, кроме меня.
3. Описывать задачу и погружать другого человека в контекст дольше, чем сделать самому.

Какая из этих мыслей регулярно крутится у вас в голове? Если хотя бы одна из трёх – поздравляю, вам нужно учиться делегировать. Например, почитать гайд от @skillsetter, в котором я поделился полезным лайфхаком:

Делегирование задач: зачем это делать, как правильно и что мешает

Кстати, если у вас есть свои лайфхаки или инструменты делегирования – закидывайте в комменты.

Про правильные привычки в разработке

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

1. Работать прозрачно
2. Двигаться по чуть-чуть
3. Говорить просто
4. Делать скучно
5. Соблюдать баланс

Подробности про каждый принцип - в статье, которуя я написал для @skillbox_media_code

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

1. Time-to метрики
2. Что развивать лидеру?
3. Про неопределённость
4. Про проактивность
5. Про объяснения

Про детализацию информации

Мечтаю о таком приложении, которое позволит изменять детализацию в любом потоке информации.

– Вернулся в интернет после месячного ретрита? Оно расскажет за 5 минут только о главных событиях (вы же не хотите читать весь твиттер за месяц и листать все новости?)
– Читаешь лонгрид на больную тему? Ставишь максимум детализации. Просто интересены шаги и выводы или мало времени? Двигаешь ползунок влево – в тексте пропадает вся литература и авторский стиль и остаются только факты.
– Интересно, как дела сейчас в компании? Видишь дашборд только с основными цифрами. За что-то зацепился глаз? Провалились в конкретную команду или проект, повысили детализацию и смотрим цифры, результаты и какие возникали проблемы.

Но пока управлять потоками информации могут только люди и важно понимать, кому и какой уровень детализации необходим. Внутри команды люди хотят понимать, чем они будут заниматься на этой неделе, где взять необходимые доступы и найти прототипы экранов. Соседняя команда хочет видеть, как продвигаются задачи, которые они просили делать. Руководители – понимать, приближаемся ли мы к поставленным целям. А если долго не приближаемся – «провалиться» в детали, найти, что пошло не так и помочь исправить это.

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

Как фокусироваться на главном?

Чем больше делаю задач, тем больше их становится, а времени они занимают всё больше. И тем чаще замечаю, что закон Паркинсона (что работа занимает всё отведённое на неё время) – правда.

Именно когда это понимаешь, осознаёшь важность сроков, особенно для себя самого. Задачу можно сделать по разному в зависимости от ресурсов (временных, интеллектуальных, денежных), которыми мы обладаем. В этом основная идея appetites из методологии Shape Up от Basecamp – мы фиксируем время, которое хотим потратить на фичу, а не скоуп этой фичи. Если успеваем – она будет доведена до идеала, если нет – пойдёт в продакшен в минимальном и простейшем виде.

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

В общем, хотите фокусироваться на главном? Ограничивайте своё время на выполнение задач.

Маркер фигни

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

Этот же вопрос работает и для продуктов, и для команд (и даже для кода!). Например:

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

В общем, хотите понять, а не фигнеё ли заняты люди вокруг? Просто спросите

Про отвлечения #toolset

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

Так вот, мессенджеры разрываются, в почту валятся десятки писем. В момент, когда они приходят всегда кажется, что это ОЧЕНЬ ВАЖНО и нужно отвлечься прямо сейчас. Как лечится – понятно. Отключаем уведомления. Сначала страдаем от ломки и FOMO, а потом ощущаем увеличение продуктивности, улучшение ментального состояния и осознание того, что многие задачи решаются без вашего участия. И то, что могло бы показаться срочной важной задачей заканчивается сообщением «не актуально, разобрались)»

Потом наступает новое состояние, когда любые 3 минуты свободного времени на автомате хочется открыть телеграм. А там ещё и новые интересные посты в каналах появились и вот, как нам кажется, мы заняты чтением полезного контента (но планировали мы заняться чем-то другим).

Рецепт моей борьбы:

1. Выбираем, как часто хотим читать мессенджеры

Например, раз в 15 или 25 минут и убираем с экрана любые напоминания о непрочитанных сообщениях.

2. Регистрируемся в inoreader

Тут мы будем хранить все наши подписки. Можно использовать аналогичные сервисы, типа feedly.

3. Добавляем все телеграм-каналы туда

В inoreader подписка на телеграм-каналы – платная фича, так что проще добавить все каналы через rsshub. Например, ссылка на мой канал: http://rsshub.app/telegram/channel/sn_hack.

4. Отписываемся от всех в телеграме!

И он снова становится просто мессенджером.

5. Планируем потребление контента

Чтобы не занимать любое свободное время разбором контента – запланируем его и явно добавим в календарь. Например, 2-3 раза в неделю по 30-45 минут вполне достаточно.

Бонус шаг: ставим Reeder. Это просто красивый интерфейс для чтения inoreader с возможностью добавлять статьи в read it later и чтением в оффлайне.


P.S. У такого подхода есть один неочевидный минус. Думаю многих авторов мотивирует количество подписчиков, просмотров постов и шейров/реакций, а отказ от официальных клиентов телеграма уменьшит эти числа. И что с этим делать я пока не придумал:)

Ностальгия по качеству

За последние 2–3 недели я зарегистрировался в паре десятков сервисов, которые заявляют себя как «Создай иконку / интерфейс / веб-сайт / мобильное приложение / космический корабль по текстовому описанию». Половина из них даже не работают — собирают почты в waitlist. Думаю, что 80% из них закончат тем, что сделают еле работающую простейшую демку и пойдут искать инвесторов. Возможно, кто-то и найдёт, но, думаю, через год будет существовать максимум 3% этих продуктов. И вот они-то начнут делать классный, качественный продукт...

Ха-ха, конечно нет! Мы же не в 2010-м: они будут собирать всё криво, на коленке и с кучей багов. Первым делом будут работать над онбордингом, обещая внутри невероятные технологии, которые изменят ваш быт навсегда. Но обещать — не значит жениться. В реальности продукт будет способен делать процентов 10–20 от того, что будет обещано на лендинге и в онбординге. Странно, ведь в testimonials лучшие люди планеты пишут, как сильно изменилась их жизнь...

Может, мы просто попали в неудачный A/B-тест? Ладно, просто закроем приложение... До первого пуш-уведомления — ведь ретеншен сам себя не поднимет. Да, facebook может доказывать, что иногда лучше меньше пушей, чем больше. Но у pre-seed-стартапов нет столько времени и денег, чтобы ждать результаты в течение года, да и параллельные A/B-тесты проводить сложнее. Стат-значимый результат? В продакшен на 100%. В приложении баги, а на почте пачка предложений от пользователей? Оставим на потом, ведь продакт-менеджеров не повышают за внимание к деталям и отсутствие багов, если это не приводит к росту метрик. Следующая гипотеза — письмо «It's sad to see you're leaving» с предложением скидки после отписки от сервиса.

К чему это я? Понятно, что рынок решает, и такой подход максимально эффективен для бизнеса и фаундеров. Но грустно, что остаётся всё меньше и меньше продуктов и компаний, которые не занимаются бесконечным гроуз-хакингом, а делают классные до мелочей продукты. Знаете такие? Поделитесь в комментариях — хочется вернуть свою веру в IT 🙂

Почему ChatGPT меня не заменит

Когда я начинал заниматься вебом, я писал код в блокноте, копи-пастил хаки, чтобы полупрозрачность работала во всех браузерах, включая IE6, а единственным вариантом отладки JS-кода был window.alert (потому что DevTools тогда ещё не было и console.log писать было некуда). Меня всегда интересовали best-practices написания кода и способы ускорить то, что и так работает. Для этого приходилось закапываться в детали и постоянно следить за изменениями – в чем разница между http/2 и http 1.1? Как работает браузер и рендерит сайты? Что под капотом использует jquery/angular/react? Как сделать свой CI?

Постепенно веб обрастал тулингом и фреймворками и сейчас какой-нибудь next.js + vercel из коробки предоставит все best-practices и будет работать быстро и качественно – он за вас всё оптимизирует, порежет, сожмёт, раскатит. Достаточно просто следовать гайдам и ничего не сломать. Но даже используя next.js нужны опытные разработчики, просто они теперь решают другие проблемы, которые ещё не решены фреймворком.

Вслед за тулингом и фреймворками появились сотни курсов на которых учат использовать эти самые тулзы и фреймворки и обещают 300к/cек после окончания. Большинство выпускнинов ограничиваются поверхностными скилами в том, как использовать конкретные инструменты, но ценными разработчиками становятся те, кто закапывается в детали и понимает, как же всё работает под капотом. А работает всё почти так же, как и 15 лет назад.

Получается, что самые ценные знания – те, которые не меняются годами. За 15 лет не произошло ни одной "революции" ни в бекенде, ни во фронтенде, ни в базах данных. Всё, что происходило – небольшие планомерные дополнения и улучшения. Те, кто понимает базовые принципы разработки легко переходят с одного языка на другой. Те, кто понимает как работает браузер и JS легко переключаются с react на vue или svelte. В других областях знаний (дизайне, продажах, менеджменте) всё аналогично – фундаментальные знания и опыт намного важнее знания конкретных инструментов.

Так вот, теперь появляется новая волна тулинга – ChatGPT и прочие AI-ассистенты. Многие задумываются, а не заменят ли их эти ассистенты. И ответ для меня очевиден: нет, пока вы инвестируете своё время и силы в фундаментальные знания, которые не меняются годами. Именно в паре с этими знаниями ChatGPT станет ассистентом, а не заменой.