Fullstack Founder

Метка: мышление

  • Когда опыт мешает

    Когда опыт мешает

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Лиды нужны слабым агентствам

    Лиды нужны слабым агентствам

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

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

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

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

    Итак, агентству нужны лиды:
    – если агентство оказывает услугу средне или плохо и/или клиенты недовольны. NPS < 7 - если агентство выводит новую услугу и нужны первые случайные жертвы - если агентство решает масштабировать свою услугу и набрало новый персонал - если агентство делает редкую услугу с маленьким сроком жизни клиента Агентство даёт прямую рекламу и остро нуждается в клиентах? Скорее всего, заказ будут делать слабые сотрудники, сделают плохо, а агентство скоро закроется. Хотите поговорить об этом с потенциальным подрядчиком?

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

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

    В 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% проблем. Находите этих пользователей и проводите тестирование до большого релиза. Это дёшево и просто. В оригинале предлагается поймать добровольца в коридоре компании, но сейчас эра удалёнки — найдите их онлайн.

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