Fullstack Founder

Метка: стресс

  • Подними свои продажи

    Подними свои продажи

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

    Когда говорить про деньги? Как красиво аргументировать цену? Как вести себя, если клиент торгуется? Частные специалисты начинают стрессовать и впадают в ступор от любой сделки, которая пошла не по плану. Это всё потому, что продажи нужно отрабатывать на тренировках, а не только в теории. Как в боксе!

    Если у вас повышается давление от разговоров про деньги, рекомендую пройти авторский курс-тренинг Игоря Уманского “Продавай легко”.

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

    На курсе “Продавай легко” вы узнаете и закрепите навыки для продажи своих услуг:
    – Выработаете личный стиль продаж
    – Научитесь понимать вашего клиента
    – Создадите свой оффер и отстройку от конкурентов
    – Сделаете сценарии продаж в вашем стиле
    – Создадите скрипты для чатов, звонков и встреч
    – Отработаете возражения и узнаете о методах убеждения

    Это как раз та база, которая нужна фрилансерам, репетиторам и начинающим предпринимателям.

    Только для моих подписчиков Игорь подготовил особые бонусы: личную консультацию и скидку 50% на продвинутые тарифы. Назовите промокод SENSEI, когда дойдёте в воронке до оформления.

    Пройдите курс-тренинг — разберётесь, как продавать, и жить станет легче.

    Первый урок и тест на архетип продавца уже на лендинге курса. Там же — все подробности про программу.

  • Дедлайн

    Дедлайн

    Ехал мимо церкви и подумал, что у понятий Успение и Deadline есть очень схожий мотив. В обоих случаях это про смерть, а не только про сроки.

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

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

    Эти же люди придумали “Red Line” — искусственный дедлайн, который сообщают только исполнителю. Если он не успеет к сроку, останется запас времени на доработки. Снова обман!

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

  • Как победить стресс при перегрузке задачами

    Как победить стресс при перегрузке задачами

    Посмотрел советы бывшего шпиона ЦРУ о принятии решений в состоянии стресса. Захотелось поделиться со всеми, но видео на английском. Так что я сделал небольшой конспект.

    TL;DR: Когда завален задачами — делай самое простое следующее действие. Не пытайся решить всё сразу, освобождай пространство и возвращай контроль шаг за шагом. Практикуй эту технику, пока она не станет инстинктивным поведением в состоянии стресса.

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

    Правило “минус 2”: уменьшить количество одновременных задач. Подумай, сколько ты можешь задач затащить одновременно, и вычти две. Кажется, что ты можешь делать пять — вычти две и решай не более трёх задач одновременно. Это увеличивает количество твоих ресурсов на каждую задачу, а значит, ты их сделаешь лучше и быстрее.

    Прими, что ты уже перенасыщен задачами. Ты не сможешь сделать всё сразу, это уже факт. Отсортируй задачи по времени на их выполнение. Самые быстрые задачи должны оказаться сверху.

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

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

    Всё это работает потому, что так были устроены наши предки. Метод “делай следующую самую простую штуку” работал на их выживание, работает для нас и сейчас.

    Формируй привычку делать простое и быстрое в первую очередь, пока это не станет автоматизмом. Практикуй дома и на работе, в любой ситуации с перегрузкой задачами.

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

  • Основатели агентств, которых я сам читаю

    Наталья Фёдорова и Антон Власов
    Основатели клуба диджитал агентств Галера, активные спикеры и практики. Прошли весь путь от студентов-предпринимателей до заметных игроков агентского рынка со Сбером и Авито в клиентах. Поменяли к лучшему жизнь сотен основателей агентств, однозначно подписка.

    Андрей Терехов — Основатель сводного рейтинга Ruward. Хранитель аналитики по рынку агентств, источник трендов, инсайтов и понятных инструкций по приведению агентства в порядок. Канал обязателен к изучению каждому руководителю агентства. Не раз был на его выступлениях — очень помогает проверить, правильно ли понимаешь конкурентный ландшафт и своё положение на рынке.

    Сила Головатый — коуч, ментор, психолог и спасатель.
    Вместе с Силой мы получили по награде «Ментор года» по версии клуба Галера. Сила — спасатель МЧС и дипломированный коуч. Рассказал мне, что ментор — это тот, кто помогает пройти уже пройденный им путь. А коуч задаст тебе вопросы, которые ты сам себе не задашь.

    Марина Колмыкова — основатель агентства Таргетерия. В прошлом году мы оба получили награду «Амбассадор года» в Галере.
    Марина вырастила свой канал всего за год до 13 тысяч подписчиков и рассказывает, как ей это удалось в интервью Наталье Фёдоровой.
    Я посмотрел, подписался и записался на её новый курс по развитию канала — тоже рекомендую.

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

    Собрал подборку рекомендаций на три части, но буду выкладывать постепенно.
    А кого из агентского рынка читаете вы?

  • Obsidian как второй мозг

    Obsidian как второй мозг

    Obsidian как второй мозг.

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

    Потом появился Obsidian. Это редактор текстовых файлов, чем-то напоминающий IDE для редактирования кода. Множество плагинов, подключенных к единой среде для всех моих записей. Записи также лежат в папках, но теперь в формате markdown — .md вместо .txt. Markdown поддерживает заголовки, форматирование текста, списки, таблицы, чеклисты, хэштеги, ссылки на документы и внешние файлы, вставленные картинки. Быстро ищет по файлам на моём компьютере и моментально открывает нужный. Интернет для работы с заметками не нужен.

    В отличие от Evernote, Google Docs и Notion, все записи находятся на моём компьютере, а не в облаке. Значит, их не будут читать сотрудники корпорации-разработчика или западные спецслужбы, нет возможности заблокировать доступ к моим записям. Приходится самому синхронизировать и хранить копию на случай потери системы или жесткого диска. Но можно делать это любым привычным способом, потому что записи — папка с простыми файлами, которые можно читать даже без Обсидиана. У меня стоит плагин, который автоматически сохраняет все изменения в приватный git-репозиторий на моём сервере.

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

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

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

    Обхожусь минимальным набором плагинов: Календарь, Горячие клавиши из VS Code, Git. В сообществе есть сотни плагинов, которые можно подобрать на свой вкус и потребности.

    Заметки для этого канала тоже изначально пишу в Обсидиане.

    Скачать Obsidian бесплатно: https://obsidian.md/

  • Тестовые задания для разработчиков

    Тестовые задания для разработчиков

    Тестовые задания для разработчиков.

    Не люблю я тестовые задания. И разработчики не любят.

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

    Мидл не оскорбится, но проверить его навыки у вас тоже получится плохо. С выдуманным маленьким тестовым он справится без труда. Большое тестовое бесплатно делать не захочет. Задание нужно компетентно проверить и затем обсудить. Кто будет тратить на это ресурсы?

    Джун может посыпаться даже на простом задании. Вы же собираетесь его доучивать? Проверите разве что базовые навыки: нажимать на кнопки, смотреть в документацию и кормить вашими тестовыми нейросеть.

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

    Задайтесь вопросом, что мы на самом деле пытаемся у кандидата тестовыми заданиями узнать? Можно ли эти ответы получить иначе?

    Моя практика с тестированием навыков такая:
    1) Для сеньоров и мидлов — начать с обсуждения тестового ТЗ, очень похожего на реальный проект. Тут вы действительно сможете понять логику, оценить предлагаемые решения и обсудить реализацию. На пальцах и за 20 минут. Такое ТЗ без проблем составит ваш ПМ.
    2) Дать настоящие задачи и оплатить их выполнение. Я стараюсь вывести всех перспективных кандидатов на тестовую неделю. Мы увидим всё — навыки коммуникации, командной работы, скорость работы, владение реальными инструментами и возможность решать задачи реального мира. В любой момент тестовой недели обе стороны могут остановить тест и безопасно разойтись.
    3) Для джуна — он же не только у вас собеседование проходит. Спросите, какие ещё тестовые он проходил — и попросите показать результат. Сомневаюсь, что он подписал на тестовые NDA. Заодно поймёте, как подбирают разработчиков ваши коллеги и конкуренты.
    4) У всех кандидатов просить реальный код любого проекта. Можно не с прошлой работы, можно пет-проект. Этот код можно скормить на аудит нейросетке.

    А у вас как с тестовыми? Были случаи, когда они реально необходимы?

  • Пройти Тест Джоэля

    Пройти Тест Джоэля

    В 2000 году Джоэль Сполски — сооснователь StackOverflow и Trello, написал список из 12 вопросов, известные как Тест Джоэля. Часто ссылаюсь на этот тест, поэтому прокомментирую эти вопросы.

    1. Используете систему контроля версий?
    Кажется, что git — уже обязательная вещь. Но до сих пор встречаются проекты без системы контроля версий.
    Для тех, кто уже использует, вопрос всё ещё актуален, но теперь звучит так: Вы действительно используете систему контроля версий? У вас есть стратегия ветвления, процедура слияния веток, понятные правила для работы с репозиторием?

    2. Сборка проекта происходит в один шаг?
    Проект должен собираться в 1 команду и она должна быть написана в readme. Если для запуска проекта требуется поставить несколько сервисов, иметь нужную версию компилятора и запущенную базу данных — стоит прописать все эти зависимости в docker-compose и запускать одной командой. После прихода виртуализации оправданий для многошаговой сборки и зависимости от среды больше нет.

    3. У вас настроен CI/CD?
    В оригинале Джоэль говорит про daily build — оперативная сборка софта каждый день. Сейчас в большинстве команд нет нужды синхронизировать код раз в день, можно делать это автоматически каждый раз, когда код попадает в репозиторий.
    Настройте автоматическую сборку и выкатку приложения на тестовый сервер.

    4. У вас же есть база багов? Правда?
    Громоздкая Джира не единственный вариант. Эксель тоже подойдёт! Если у вас есть общий зафиксированный список проблем, вы можете с ними работать и планировать их устранение.

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

    6. У вас есть план работ со сроками?
    План, который знают все и который связан с реальностью. Roadmap, этапы или просто дата, в которую надо запуститься.
    Работа ведёт себя как газ — занимает всё выделенное время. Ставьте сроки.

    7. У вас есть спецификация?
    Банально, но без ТЗ результат ХЗ. Сейчас не нужно писать исчерпывающее финальное тех задание — требования поменяются по ходу разработки. Достаточно написать концепцию, сделать прототипы, записать user story и опубликовать. Задачи тоже нужно записать и поставить в трекер.

    8. У разработчиков есть тихие рабочие места?
    Ваш разработчик всё ещё сидит в опенспейсе? Зря-зря. Скорее всего, он уже обзавёлся наушниками и пытается от вас отвернуться. Помогите ему создать изолированную среду.

    9. У разработчиков лучшая техника и инструменты?
    Быстрый комп, 2ой монитор, современный софт, быстрые серверы — стоят копейки относительно времени программиста. Планка памяти стоит как час работы разработчика. Ускоряйте их всеми доступными способами, это очень дёшево.

    10. У вас есть тестировщики?
    Если баги ищут только разработчики — значит, баги находят пользователи.
    Менеджеры и программисты проверяют, что код работает. Тестировщики проверяют, ищут где он не работает. У вас должен быть хотя бы 1 тестировщик в команде на нескольких разработчиков.

    11. Пишут ли кандидаты код на собеседовании?
    Это единственный пункт, с которым я сейчас не полностью согласен в его изначальной формулировке. Изучить код и мышление кандидата на собеседовании получится, а вот показать реальные навыки в стрессовой ситуации собеседования — вряд ли. Мой рецепт — выводить подходящих кандидатов на тестовую неделю и смотреть совместимость без давления в реальной обстановке.

    12. Вы делаете usability тесты на добровольцах?
    Соберите группу для тестирования. Первые 5 случайных пользователей укажут вам на 95% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.

    Если вы фаундер или руководитель и у вас есть ответы “Нет” — их точно стоит обсудить с командой.

  • Как нанять разработчика: Отбор кандидатов

    Как нанять разработчика: Отбор кандидатов

    Вакансия нравится соискателям и к нам поступают десятки откликов.
    Но количество откликов не означает их качество…
    Многие разработчики не владеют навыком создания хорошего резюме. По резюме зачастую ничего не понятно.

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

    В анкете 50+ вопросов. Спросим про часовую ставку, условия работы, работает ли с таймером, пишет ли тесты и любые другие интересные нам детали.
    Самый большой блок — отдельные вопросы про каждую технологию и навык, который может потребоваться у целевого кандидата.
    Какой опыт с _____?
    Варианты ответа: Не было опыта, Изучал/Пробовал, Практик, Эксперт.

    Кажется, что тут легко обмануть и приукрасить. Да, но навряд ли на 2 ступени. 🤡
    Любой крупный обман в анкете вскроется на интервью и реальных задачах. А если что-то приукрасил — сам будет навёрстывать.

    Разработчик с удовольствем заполнит анкету вместо 30-минутного интервью с рекрутёром. Анкету можно заполнить на текущем рабочем месте или после работы. Без стресса и спешки.

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

  • Как не надо нанимать программистов

    Когда сталкиваются HR и IT, происходит столкновение материи с антиматерией.
    Экстравертные эмпатичные коммуникаторы агитируют скептично-бездушных асоциальных чудаков.

    Вследствие этого столкновения рождаются очень занятные идеи:
    – Пригласить человека, привыкшего медленно думать в одиночестве, на супер важное “сделай-или-провалишься” интервью. Интроверты привыкли к давлению.
    – Тараторить ему про корпоративную культуру на высокой скорости и звонким голосом. Его ждут очень весёлые корпоративы, тим билдинг и море общения в весёлом офисе. Ведь он именно общения ищет в углу за монитором.
    – Спрашивать его на старте академическое определение полиморфизма, чтобы он вспомнил все ощущения с экзаменов в универе. Заодно покажем, кто тут главный.
    – Заставлять включать камеру — он точно захочет показать и проявить себя с незнакомыми людьми на первом звонке.
    – Замучали до заикания на вопросах? — теперь время писать код по только что увиденному ТЗ под надзором незнакомого тех директора. Именно в живую, как никогда не будет происходить после.
    – Соискатель прошёл 3 стадии экстравертного ада — самое время узнать об условиях работы в Джоб оффере, который сгорит за N дней. Срочно соглашайся, у HR есть KPI!
    – Не очень понятно, зачем программисту работать именно у нас. Давайте завалим его деньгами и едой? Алчные айтишники только этого и ждут!

    В конечном итоге выигрывает HR — программист нанят. Удовольствие найти проигравших оставлю читателю данного эссе.

    А как можно нанимать программистов без стресса я расскажу завтра.