Почему все так любят велосипеды

Давече обсуждали с Артёмом Ерошенко его новую версию Allure 3.0 задавались вопросом: зачем тестировщикам в 2024 году таблички с тестами, если есть инструменты, которые работают лучше? Но, как показывает практика, велосипеды — это не только о тестировании.

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

Вот мой топ-5 самых популярных:

1. Свои инструменты разработки. “Jira? Нам это не подходит, у нас — ‘Реестр задач 2.0’ в Excel. CI/CD? Мы не гугл - у нас FTP.”, “API тестировать не нужно, клиенты его не видят.” В итоге вместо готовых инструментов — своё родное.

2. Уникальные роли. У вас не Project Manager, а “Координатор зон ответственности”. Вместо тестировщика — “Архитектор проверки” и “Менеджер багов”. Звучит красиво, но на деле никто не понимает, кто за что отвечает. Нанять нового сотрудника? Удачи.

3. Свое планирование. “Scrum нам не надо, а Kanban — это вообще для японцев.” Зато у нас есть “динамическая сессия по согласованию задач”. Это когда задачи записываются в “нашу джиру-табличку”, которая обожает терять строки. Приоритеты прыгают каждые два часа, дедлайны — понятие философское.

4. Сопротивление внешнему опыту. “Вы не понимают нашей уникальности.” Конечно, ведь в других местах никто не видит красоту джира-таблички, которая “держит” всю систему. В итоге нанимают людей, готовых учиться внутренней культуре, вместо того чтобы привносить что-то новое.

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

Что из этого выходит?

Это и есть “искажение уникальности” — удобный способ избегать изменений, маскируя хаос под творчество. Роббинс и Джадж в “Организационном поведении” называют это ловушкой, которая приводит к:

1. Сложностям в росте. Новичков невозможно адаптировать, потому что даже опытным людям сложно объяснить это творчество.
2. Зависимость от героев. Всё держится на 2-3 “Васях”. Ушёл Вася — и его велосипед сразу развалился, так как педали крутить некому.
3. Замедлению бизнеса. Вместо работы над продуктом компания бесконечно чинит свой “уникальный” подход.

Если ты думаешь: “У нас всё работает”, — поздравляю, пока что работает. Но как только начнётся масштабирование или кто-то из ключевых уйдёт, всё это превратится в хаос.

Трушная уникальность — это не велосипеды, а умение адаптировать лучшее под себя.

В колхозе больше всех пахала лошадь и ты

Когда я только начинал, мне казалось, что чем больше я работаю, тем ближе успешная жизнь. Работать по 10-12 часов? Конечно, ведь так я стану незаменимым, правда? А потом смотришь на коллегу, который закончил в обед, уехал на новом мерсе, пока ты сидишь до вечера, а домой едешь на метро.

Много работы ≠ много результата

Работать без остановки — это не героизм, а путь в депрессию и покупку купе (клубу 30+ привет). Как говорил Тим Феррис (Как работать по 4 часа в день), эффективность всегда важнее усилий. Ты можешь сделать больше, если сосредоточишься на главном, автоматизируешь рутину, делегируешь задачи и… используешь готовые решения.

Суть херачить — в том, чтобы потом не херачить

1. Автоматизируй рутину. Если ты QA, делай автотесты и пайплайны. Менеджер? Используй трекеры и шаблоны. Каждая минута на автоматизацию сегодня — это часы, которые ты сэкономишь завтра.
2. Фокусируйся на важном. Роберт Шарма (Клуб 5 утра) советовал начинать день с главных задач. 3 выполненные задачи лучше 10 размытых попыток. Работай на результат, а не на «занятость».
3. Делегируй. Ты не супергерой, и это нормально. Делегирование — это не слабость, а умение сосредотачиваться на том, что действительно важно.
4. Запускай быстро. Как писал Руслан, идея, запущенная за 2 недели, даст тебе 80% результата. А стремление к идеалу обычно оставляет проект на этапе «почти готово».
5. Используй готовое. Я уже писал о «велосипедах»: если есть готовое решение, не трать время на изобретение нового. Возьми Trello, а не строй таск-трекер, или бери Allure для отчётов вместо кривой html подделки.

Насмотренность

Если не знаешь, что выбрать, сначала посмотри вокруг. Открой интернет, сходи на конференцию или найди того кто уже делал твою задачу. Мир уже давно придумал большинство решений. Учись смотреть и слушать, иначе все вокруг будут идти вперёд, пока ты с утра до ночи пилишь то что послезавтра выкинешь.

Включай голову

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

Вререди 6 дневная рабочая неделя и долгожданный оливье и отдых. Держимся ребятки ❤️

7 признаков, что ваша команда застряла в 00-х

За годы работы я часто видел команды, которые превратили стабильность в культ, восхваляя процессы и инструменты из 00-х как нечто святое. Любая попытка изменений встречается фразами вроде «У нас так всегда работало» или «Мы не гугл, нам так удобно». Это классический застой, о котором писал Ицхак Адизес: компания достигает стадии «расцвета», но вместо развития цепляется за прошлые успехи, попадая в ловушку ошибки выжившего.
Признаки, что ваш подход пора обновить:

1. Отделы вместо команд. «Разработчики пишут код, QA ищут баги. Всё строго и по полочкам.» В итоге проблемы обнаруживаются на финальных тестах, когда сроки уже горят. Совместная работа? Не слышали.

2. Тяжёлые процессы и Waterfall. «Нужно всё досконально спланировать заранее.» Пока вы согласовываете годовой план, Agile-команды уже выпустили несколько релизов.

3. Автоматизация? Нет, спасибо. «Мы пробовали автоматизировать, всё сломалось, поэтому лучше вручную.» Современные инструменты вроде Cypress и Playwright надёжны и эффективны. Но зачем, если можно продолжать работать дважды дольше?

4. CI/CD — не для нас. «Автоматизированные пайплайны? Это слишком сложно.» Ручные релизы — это как ездить на телеге в эпоху электромобилей. Пока вы вручную запускаете код, конкуренты ускоряют релизы в разы.

5. Монофункциональные роли. «Я тестировщик, и точка. Остальное не моё дело.» Узкие роли тормозят процессы, но зато вам не нужно напрягаться учиться чему-то новому.

6. Массовые планёрки. «Чем больше людей, тем лучше.» Два часа обсуждений, почему кнопка зелёная, а не красная, вместо коротких и продуктивных встреч.

7. Никаких экспериментов. «Мы уже пробовали это, и оно не сработало.» Вчерашние неудачи — это не оправдание стоять на месте. Технологии и контекст меняются.

Вывод:

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

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

С наступающим!

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

В 2025 желаю всем лёгких релизов, больших денег и мирного неба. Пусть это будет год смелых экспериментов и крутых результатов. 🚀 🎅🏼🍾

Пиратство или бюрократия?

В 2015 году я пришёл в стартап CarPrice, и первое время просто офигевал. До этого я работал в классической компании с отделами где разработчики пишут код а QA ищут баги, всё строго по полочкам. А тут — продуктовые команды, OKR-ы, кальянная в офисе и в целом пахнет свободой. Моей первой реакцией было: «это хаос, так нельзя» Но чем больше я наблюдал, тем яснее становилось: можно. И нужно.

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

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

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

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

3. KPI против пользователя. В отчётах всё идеально, каждый отдел отработал свою часть. А пользователь заходит в продукт и думает: «Что это за хрень?» Итог: всем всё пофиг, но метрики сданы.

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

1. Интеграция. Разработчики, QA, аналитики — все работают над одним продуктом, решая проблемы на месте, а не перекладывая их по вашему длиннющему воркфлоу в джире.

2. Фокус на результат. Задачи вроде «протестировать фичу» заменяются целью «сделать фичу, которая увеличит конверсию». Работа на продукт, а не на отчёты.

3. Культура экспериментов. В командах нет страха перед ошибками. Гипотезы проверяются быстро, данные собираются на лету, решения адаптируются без бюрократии.

Отделы — это отличный способ навести порядок на старте. Но если компания хочет двигаться вперёд, расти и оставаться конкурентоспособной, это больше не работает. В ВК и Сбере переход к командам дал автономность людям делать пользу, участил деплои и сократил time2market. Мы видели, как идеи превращались в релизы за недели, а не месяцы.

Посмотрите на свою структуру: она двигает вас вперёд или тянет назад?

Как выбесить команду разработки

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

1. Будь мастером микроменеджмента. Следи за каждой строчкой кода, комментируй каждое решение команды. Постоянно уточняй, что и как они делают. Если разработчик не прислал статус за 15 минут – пиши ему в личку: “А где мы с этим?”. Никто не должен расслабляться.

2. Устраивай бесконечные встречи. Статусы, стендапы, созвоны, викли, ретро – и так каждый день. Минимум 6 часов встреч в календаре у каждого члена команды. Команда ведь обожают созвоны с тобой.

3. Придумывай правила на ходу. Зачем использовать проверенные инструменты и подходы, если можно придумать свой? Например, вместо стандартного гитфлоу введи “уникальный подход к веткам”, который никто не понимает, или заменяй спринты хаотичными недельными пушами. Каждый твой новый процесс — это подарок, который никто не просил, но все обязаны оценить.

4. Игнорируй обратную связь. Кто-то пытается предложить улучшение процесса? Забудь. Ты знаешь лучше. Либо пропускай предложения мимо ушей, либо ставь их под сомнение фразами вроде: “А зачем нам это?”

5. Внедряй “фичи-сюрпризы”. Зачем команда планирует спринты? Чтобы ты внезапно добавил новую критическую хрень на второй неделе. Так ребята лучше поймут, что в этом мире нет ничего постоянного.

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

Айтишка - маленькая деревня

В 2018 году, когда я был молод и глуп, уходя из стартапа хлопнул дверью, переругавшись с CPO и CTO и ушёл с чувством собственной значимости. Тогда казалось, что это мощный ход — пусть знают, кто тут батя. А потом в других компаниях я раз за разом натыкался на людей, которые работали с ними, учились вместе или просто были знакомы. Спойлер: со временем обиды загладили, общаемся нормально. Но именно тогда я понял: айтишка — это маленькая деревня, где все друг друга знают, даже если ты об этом не в курсе.

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

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

А если хочешь, чтобы двери сами открывались, работай на своё имя. Если тебя знают как нормального, адекватного и профессионального, вакансии будут находить тебя сами. Люди будут рекомендовать, звать, предлагать крутые проекты. А если хоть раз жахнуть по мосту — потом будешь долго удивляться, почему все дороги куда-то не туда. Так что вопрос простой: каким тебя запомнят, когда ты выйдешь из чата?

Ребята привет.
Пост новостей и найма.

Новость 1 - Я в Делимобиль (будут посты как тут интересно)
Новость 2 - Ищу в команду героев👨🏻‍🎤

QA Lead направления B2C
Senior QA команды Платформы
Senior QA команды Billing

Пишем на Kotlin/Java/Swift. Строим лучшую платформу качества среди каршеринг сервисов 🤌🏽

Писать мне или откликаться тут https://career.delimobil.ru/