Блог

  • Самореализация и мотивация через ведение блога

    Первые попытки вести блог были ещё в детстве, когда дома появился первый компьютер, а я случайно открыл Publisher из пакета Microsoft Office. Так родился «Колосовский вестник», где я периодически описывал новости, произошедшие в нашей семье. Тогда я ещё не подозревал, что это была первая искра моего увлечения контентом.

    Прошли годы, и за плечами осталась не одна несистемная попытка начать вести блог «по-настоящему». Сейчас я наконец-то выработал подход, благодаря которому могу регулярно выделять время и силы на то, чтобы делиться интересными мыслями и находками с людьми вокруг.

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

    Самый ценный профит от ведения блога для меня — это глубокое погружение в тему. Ведь когда изучаешь что-то для других, сам понимаешь гораздо лучше. Это как известная мысль: «Ты по-настоящему разобрался в теме, если можешь объяснить её кому-то ещё».

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

    И да, никакой самоцензуры. Самоцензура — это худшее, что можно сделать со своим творчеством.

  • MINI-путешествие 4 – Великий Новгород – Псков – Печоры – Изборск – Санкт-Петербург

  • Про дедлайны

    Дедлайны и “задачи в срок” — моё самое нелюбимое действие. Я могу перед презентацией поставить себе задачу “Подготовиться к презентации”, но если к определённому дню нужно готовиться за несколько дней — это ужас.

    Во-первых, постоянная тревожность: день всё-таки наступит, и что-то обязательно пойдёт не так. Но заставить себя сесть и начать готовиться — ещё сложнее. Легче отказаться от затеи, чем терпеть это состояние. Думаю, что это какая-то патологическая непереносимость экзаменов. Ещё со времён самого первого курса института я не мог готовиться к ним. Приходилось идти без подготовки. Так я из своего первого института и отчислился.

    Поэтому у меня нет никакого духа соревнования или желания “доказать себе, что могу”. Я и так знаю, что могу, а что — нет. Каждый вечер вместе с нейросетями пытаться что-то сообразить прикольное для сайтика на WordPress — да. Подготовить проект к защите на этом же WordPress — спасибо, не надо.

    Спасают небольшие “чек-поинты”. Перед чем-то важным нужно поставить несколько “неважных” задач, к которым можно подготовиться заранее. Если это защита диплома — “написать введение для встречи с дипломником”. Это реально сделать за один день. “Накидать шаблон презентации”, чтобы показать его друллеге для ревью — тоже вариант. И тревожности сильно меньше, потому что идёшь не к какой-то глобальной цели, которую нужно выполнить в срок, а по-приколу готовишься к довольно дружеской встрече.

    Ну и мне ещё повезло с дипломником во втором институте. До сих пор считаю, что создание диплома с ним дало столько же, сколько всё обучение в этом институте. Крутой мужик, дай Бог ему здоровья.

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

    Но есть ещё несколько приёмов, которые мне помогают:

    Не пытаюсь сразу сделать всё идеально. Сначала — черновик, пусть даже кривой. Черновик легче исправлять, чем писать с нуля. То же с презентациями: накидал слайды — уже не страшно, дальше просто доводишь до ума.

    Иногда помогает таймер на 25 минут работы и 5 минут отдыха. В голове сразу появляется мысль: “Ладно, 25 минут я как-нибудь выдержу”. А потом втягиваешься и идёт легче.

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

    Иногда помогает психологический приём — представить себя в день дедлайна. Задать вопрос: “Чтобы в этот день не чувствовать себя ужасно, что я могу сделать прямо сейчас?” Ответ обычно оказывается простым: открыть документ, сделать первый слайд, списаться с коллегой.

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

    Так дедлайны становятся не катастрофой, а ещё одной историей, которую можно будет потом рассказать. Или написать пост в Tach – как этот, например.

  • Что делать, если проект идет не по плану

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

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

    Во-вторых, важно понять две вещи:
    В какой точке мы можем вернуться к изначальному плану?
    Если вернуться нельзя, какой есть альтернативный путь?

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

  • Что астрологи сказали про прошлую неделю? Мир вверх дном, а будущее уже на пороге: 3 главные новости

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

    Первое, о чём как-то мало говорят — Microsoft представила Majorana 1 — квантовый чип на основе топопроводников. Этот чип обещает революционизировать вычислительные мощности, используя новый тип материи — топологическое состояние.

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

    Мы не могли использовать кубитные процессоры, потому что использовали ограниченное количество кубитов. Вроде как этот чип решает эту проблему.

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

    То, что я хочу проверить за неделю своего отпуска: Очередное исследование учёных из США и Канады показало, что две недели без интернета на смартфоне могут значительно улучшить наше психическое здоровье и когнитивные способности.

    В это исследование я верю, потому что из 200 человек только 25 смогли дойти до конца.

    А это значит, что мы с вами зависимы от интернетов и поглощения информации, от рилсов, ТикТока и Ютуба.

    По общению с зумерами я замечаю, что многие из них включают ленту рилсов даже в короткую паузу в диалоге. А нужно быть зависимыми от моего профиля в Tach! tach.id/u/igor

    И самое криповое:
    Clone Robotics сделал Protoclone V1 — андроида, максимально имитирующего человеческую анатомию.
    С более чем 200 степенями свободы, 1000 искусственными мышечными волокнами и 500 сенсорами робот повторяет человеческие движения.

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

    Правда интересно, что же будет дальше?

  • Как я всё успеваю за день

    Короткий ответ: никак. Мне всегда кажется, что можно было бы сделать больше.

    Но если говорить о том, как мне удаётся двигаться вперёд, то всё держится на нескольких принципах.

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

    — “У меня теперь нет детей, они — джуны. После разговора с одним он уволился. Типичный зумер”.

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

    В-третьих, никаких бессмысленных созвонов и встреч.

    • У каждой встречи есть адженда и чёткое время.
    • Есть список обязательных участников.
    • Если обсуждение уходит не туда — встреча заканчивается.

    А теперь немного классики про тайм-менеджмент, но без воды:

    • Делегирование – спасает, если кто-то может сделать быстрее или проще.
    • Не перегружай себя планами. У меня есть два списка: то, что нужно сделать в этот день и то, что нужно делать по порядку. Когда заканчиваются дела “на день”, перехожу к “очереди”.
    • Работай в ритме. Используй Pomodoro и планируй большие блоки задач на неделю в календаре.
    • Фильтруй входящие. Почта, задачи, уведомления — не реагировать на всё подряд. Уведомления могут уходить “в очередь”, чтобы быстро их “прочекать”.
    • Оставляй время на отдых. Иначе организм сам устроит тебе незапланированный выходной. В лучшем случае это будет простуда, а в худшем – какая-нибудь клиника неврозов.

    И да, всё равно кажется, что можно было бы сделать больше.

  • Ставь задачи и получай результат

    Правильная постановка задачи — это ключевой момент для того, чтобы вся команда могла эффективно двигаться в одном направлении и понимать, что и как нужно делать.
    Когда задача сформулирована чётко, каждый член команды может легко её интерпретировать, независимо от того, на каком этапе работы он находится. Особенно это важно для тех, кто работает с багами или эпиками.
    Вот несколько примеров. Для багов я использую привычную структуру:
    «Платформа (FE, BE, iOS, Android) – Что случилось Где случилось».
    Это позволяет сразу понять, где именно возникла проблема и на какой платформе она проявляется. Допустим, «Android – Приложение вылетает при загрузке профиля» — никаких лишних слов, всё понятно с первого взгляда.
    Когда речь идет об эпиках или задачах, важно выбирать ёмкие выражения. Вместо общего «Комментарии+» лучше сказать конкретно, что нужно, например: «Я должен мочь прикрепить 100 фотографий в комментарий». Это не просто объясняет, что нужно сделать, но и задаёт конкретный критерий, который можно проверить.
    Пример плохой формулировки:
    ❌ «Комментарии+» – это что вообще значит? Увеличить лимит? Добавить эмодзи? Сделать вложенность?
    Пример нормальной задачи:
    ✅ «Я должен мочь прикрепить 100 фото в комментарий» – понятно, что делаем, где делаем и в каком объёме.

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

  • Как пройти собеседование на тестировщика? Чек-лист подготовки 📝💡

    Поиск работы и прохождение собеседований – это проект 🎯

    И как любой проект, у него должен быть план. Делюсь планом, который позволил бы пройти собеседование у меня на позицию сразу мидлового тестировщика. В офисе шутят: «После собеседования с тобой кандидат устроится в любую компанию» 😄

    1️⃣ Анализ вакансий и подготовка резюме 📄

    🔍 Проанализируй 30–40 вакансий, чтобы понять, какие технологии и инструменты востребованы прямо сейчас. Вакансии обновляются быстрее, чем статьи по тестированию.
    ⚡ Обрати внимание на ключевые требования:
    ✔️ Ручное тестирование
    ✔️ Автоматизация
    ✔️ Работа с багтрекингами (Jira, Яндекс.Трекер)
    ✔️ SQL, API, CI/CD

    📝 Подготовь резюме с акцентом на:
    ✅ Опыт тестирования (если только учебный проект – лучше взять реальный опыт у знакомых или на фрилансе)
    ✅ Знание инструментов и методологий тестирования
    ✅ Навыки работы с тестовой документацией
    ✅ Базовые знания SQL, API, автоматизации – хотя бы на уровне понимания

    2️⃣ Подготовка к общему собеседованию с HR 🤝

    🏢 Изучи информацию о компании: продукт, технологии, корпоративную культуру.
    💬 Подготовь ответы на вопросы:
    ❓ Почему выбрали тестирование? (ответ «из-за зарплат» – ❌)
    ❓ Как представляете свою работу в компании?
    ❓ Ваши сильные и слабые стороны?
    ❓ Опыт работы в команде (одиночная работа по таскам – это не командная работа 😅).
    🔎 Подготовь вопросы для HR (но не переусердствуй с дотошностью).

    3️⃣ Подготовка к техническому собеседованию 🛠

    3.1 Основные теоретические вопросы 📚

    🧠 Методологии тестирования:
    ✔️ Виды тестирования: функциональное, нефункциональное, регрессионное, интеграционное, нагрузочное, UI/UX.
    ✔️ Различия между черным, белым и серым ящиком.
    ✔️ Разница между smoke, sanity и regression testing.

    📄 Тестовая документация:
    ✔️ Что такое тест-кейс, чек-лист, тест-план, баг-репорт?
    ✔️ Как оформить баг-репорт, чтобы его приняли разработчики?

    🛠 Жизненный цикл ПО (SDLC, STLC):
    ✔️ Где на этом пути участвуют тестировщики?
    ✔️ Что такое DevOps, CI/CD, Agile, Scrum, Kanban?

    🚨 Приоритизация багов:
    ✔️ Severity vs Priority – разница и примеры.

    4️⃣ Практическая часть 🎮

    4.1 Тест-дизайн 📝

    🛠 Знание техник тест-дизайна:
    ✔️ Эквивалентное разбиение
    ✔️ Анализ граничных значений
    ✔️ Попарное тестирование (Pairwise)
    ✔️ Таблицы принятия решений
    ✔️ Классы эквивалентности

    4.2 SQL 🗄

    ✔️ Основные запросы: SELECT, JOIN, WHERE, GROUP BY, HAVING.
    ✔️ Как выбрать топ-10 записей из таблицы?
    ✔️ Как найти дубликаты в таблице?

    4.3 API тестирование 🌐

    ✔️ Основные HTTP-методы (GET, POST, PUT, DELETE).
    ✔️ Коды ответов сервера (200, 404, 500, 401, 403).
    ✔️ Тестирование API через Postman.

    4.4 Логика и аналитика 🤔

    💡 Любимая задача:
    “Представь, что ты директор «Вкусно и точка». Привезли новый автомат для газировки. Как его протестировать перед установкой в зале?”

    5️⃣ Подготовка к вопросам по автоматизации 🤖

    Если требуется автотестирование:
    ✔️ Основы Python или JavaScript.
    ✔️ Selenium (база) и Appium.
    ✔️ Тестовые фреймворки: PyTest, JUnit, Mocha.
    ✔️ CI/CD-инструменты: Jenkins, GitHub Actions.

    6️⃣ Дополнительные вопросы и лайфхаки 🎯

    ❓ Что делать, если баг не воспроизводится у разработчика?
    ❓ Как объяснить важность найденного бага продакту?
    ❓ Как протестировать банковское приложение без доступа к продакшену?

    7️⃣ Подготовка к последним этапам 🎭

    🔥 Проверка на стрессоустойчивость:
    ✔️ “Как справляетесь с конфликтами?”
    ✔️ “Как реагируете на нереально сжатые сроки?”
    📚 Могут спросить о хобби и книгах (не связанных с тестированием).

    📋 Тестовое задание:
    ✔️ Написание тест-кейсов, чек-листов, поиск багов в тестовом приложении.

    8️⃣ Подготовка к собеседованию морально 🧘‍♂️

    💆‍♂️ Расслабьтесь, интервьюеры – тоже люди.
    ⚡ Если изучили продукт заранее, можно указать на ошибки, но без резкой критики.
    💡 Выбирайте компании, в которых будет интересно работать.
    ⛔ Не спрашивайте про переработки – если они есть, значит, есть причины.

    9️⃣ Анализ после собеседования 📊

    📌 Запишите вопросы, которые вызвали трудности.
    📌 Получили отказ? – Спросите фидбек и доработайте слабые места.

    🎯 Следуя этому чек-листу, вы увеличите свои шансы на успешное прохождение собеседования на тестировщика в IT-компанию. Удачи! 🚀

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

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

    Кстати, мое открытие, что в травмпунктах снимки делают теперь цифровые, не нужно ничего печатать, травматолог видит снимки в компьютере сразу.

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

    Я отдохнул от спорта полторы недельки, и вернулся в бассейн. Но эти полторы недели отдыха от тренировок компенсировалась сильно нервной неделей в работе и целом в жизни.

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

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

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

    И это напомнило мне одну простую вещь: иногда важно не просто делать, а делать так, чтобы от этого был толк.

    Когда ты чем-то занимаешься, легко уйти в фанатизм продуктивности. Мне сегодня по дороге на работу Яндекс.музыка дала послушать Йемен – «Лучший работник». «15 пропущенных от коллег, 12 от начальника техотдела, я такой ёб… а в чем собственно дело? А дело в том, что на работе без меня пиздец, пообрывали все телефоны, мне кажется я наконец лучшей сотрудник нашей конторы».

    В целом, это тот мем про ритм жизни Москвы. Как говорил Комисаренко: «Я пока жил в Беларуси, я думал я очень быстро хожу, пока я не переехал в Москву, и понял что я вообще не двигаюсь, просто ты стоишь в метро и птфу – это бабка уфегачила вверх по эскалатору!».

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

    У меня был смешной диалог с психологом, к которому я перестал ходить после диалога. Он мне говорит:

    ·Если вы упретесь в стену, что вы будете делать?
    ·(рассказываю прикол про теорию вероятности)
    ·А я считаю, что можно взять кувалду, пробить стену, и пройти сквозь нее
    ·Но вы же тогда пройдете через дырку в стене, а не через стену

    Психолог завис, и дальше как-то не пошел.

    Но все-таки, инсульты в 35 существуют, поэтому иногда лучше отступить на шаг назад, поменять тактику — и тогда получится пройти дальше, а не инсульт.

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

    А вообще, если будете снимать мини-путешествия — смотрите под ноги. Особенно если видите единственное замерзшее место в лесу.

  • Разница проектного и продуктового подхода в управлении.

    В управлении проектами часто говорят о “проектном” и “продуктовом” подходе. В чем разница, если слова вроде похожи?

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

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

    Как понять, что у вас продуктовый подход?

    Вы ориентируетесь на пользователей, а не просто на список задач.

    Готовы менять планы, если появляются новые данные.

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

    Команда работает вместе, а не по принципу «разработчики сделали свою часть — дальше не наша проблема».

    Смотрите на метрики, а не просто закрываете таски.

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

    В Tach мы идем именно по этому пути. Для нас важно не просто добавить новую функцию, а сделать так, чтобы пользователям было удобно, понятно и приятно работать с платформой.