Как собрать итоги работы для повышения

Собрать итоги работы бывает сложнее, чем саму работу работать. В Performance Review оцениваются достижения, и с этим боль почти всегда.

Вот топ-5 лайфхаков, чтобы ваши achievements залетели:

1. Пишите про успехи, а не про задачи. Никто не впечатлится “делал свою работу”. Не “тестировал”, а “уменьшил количество багов”.
2. Добавьте метрики. Оцените, насколько вы “молодец”, в цифрах.
3. Краткость рулит. Как и в резюме: больше не значит лучше, без поэм.
4. Привяжите к командным целям. Важно, как ваши успехи повлияли на общие результаты.
5. Покажите, чему научились. Полгода прошли, вы выросли — расскажите, как это помогло в проекте.

“Человек стоит столько, насколько он способен себя оценить” — Франсуа Рабле.

Всем по ляму в секунду, пирожочки, не киснем.

Узнавайте куда идет ваша компания

Сидишь, работаешь, за окном уже снег вовсю, а тут твой лид заявляет: «Вася, мы завтра летим в космос, а ты не космонавт, так что, сорян, остаешься на земле». Вопрос «какого, собственно, х… я остаюсь и зачем нам космос?» уже риторический — и задавать его поздно.

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

Если вы не помогаете стратегии, вы за бортом.

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

Если не хотите, чтобы космические идеи вашего продакта и СЕО застали вас врасплох, начните с того, чтобы спросить своего лида: «Какая у нас IT-стратегия на год?» Если её нет — печально. Если есть — ищите, как вы ей помогаете, или в космос могут полететь без вас.

В любой ситуации — стройте свою стратегию

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

Основные блоки айти стратегии:
- Цели и задачи
- Команда и её развитие
- Техстек и инструменты
- Процессы и автоматизация
- Метрики, как вы измеряете успех

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

Не будь в коконе

Когда-то я работал в онлайн-аукционе для б/у тачек. Мне довелось общаться с одним из фаундеров из списка Forbes, который регулярно выезжал на аукционы и лично осматривал машины, чтобы понять, как оптимизировать процессы. После планёрки с топами в костюмах, обсуждая ярды, он засучивал рукава и шёл фоткать VIN-номер старой гнилой Газели на морозе.

Но ты не такой. Ты сидишь дома на диване, хомячишь чай с булкой, а реальные проблемы людей для тебя — просто баги в джире. «Саша, тикетов в саппорте за q3 стало больше на 7%». А в этот момент оценщик на морозе, с 3G, загружает минутное 4K-видео работы двигателя в твоё идеально протестированное и pixel-perfect приложение.

Реальность на аукционе выглядела иначе: грязь, холод, нескончаемый поток машин и их владельцы, севшие на ухо оценщику про их «ласточку» — которая лучше всех. На месте я понял: то, что работает в дашборде, часто ломается в реальности. Много тестов пришлось переделывать — менять сценарии, добавлять проверки, сокращать шаги. Только когда мы реально разобрались, как пользователи работают с приложением в условиях аукциона и поменяли подход к тестированию, обращения в саппорте пошли на спад.

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

Что должно быть в стратегии QA на 2025 год

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

1. Генеративный ИИ для автоматизации
Генеративный ИИ уже вовсю генерит тесты, анализирует данные и находит слабые места, сокращая время тестирования. Microsoft использует ИИ для генерации тестов в продуктах Office, а Meta — для анализа кода и поиска багов. Если ещё не пользуешься, то следующий год — самое время.

2. Комплексная автоматизация
Автоматизация — это не просто набор тестов, а основа стабильности. Полное покрытие — от юнитов до регресса, с интеграцией в CI/CD и регулярным обновлением — делает релизы быстрее и стабильнее. Тот же Amazon тесты интегрируют на каждом этапе разработки, чтобы QA-команда всегда держала качество продукта на уровне.

3. Метрики и аналитика
По ним оценивают ваш прогресс и результаты. Метрики показывают, как QA влияет и почему это важно для бизнеса. Google использует метрики качества кода и покрытия, чтобы принимать решения о релизе. Прозрачные и понятные отчёты, которые видят не только QA, но и руководство, делают вклад команды очевидным и значимым. Если метрики не говорят за тебя — пора их пересмотреть.

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

5. Единое видение и связь с бизнесом
Тестирование — это не гонка за багами, а вклад в цели компании. Создавайте единое видение, где каждый понимает, как его работа помогает бизнесу. Обсуждайте приоритеты, делитесь результатами и показывайте метрики, которые важны не только для QA, но и для руководства. Чем лучше команда понимает, как её работа влияет на компанию, тем меньше вопросов «а зачем нам QA?». В своих проектах именно для этого использую OKR-ы и практику стратегий, чтобы держать фокус и связь.

Это не волшебная палочка, но поможет вашей команде держаться на уровне. В следующем году нас ждёт ещё больше автоматизации и командной работы. Полный текст большого отчёта World Quality Report 2024-25.

Не бойся ломать прод.

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

Страх — яд для команды

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

Ответственность за релиз — на всей команде

Релиз — это результат работы всей команды и Тимлида. Вы вместе пилите фичу, вместе её тестите и катите. И никто никогда не хочет намеренно что-то сломать. Так что отвечать за результат должны все — от разработчиков до тимлида, а не один тестировщик (как много где принято).

Дух пиратства — лучший настрой для команды

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

И помните

Быстро откатанное — упавшим не считается

Всем пятницы и хороших релизов ребятки ❤️

Как стать лучше 99% QA на рынке

За сотни собеседований, которые провел я видел много классных ребят, но слабых QA. Большинство их проблем, что их фокус на инструментах и задачах, а не на цели сделать лучше. Они пишут фреймворки, находят ошибки, формируют отчёты, но от крутых ребят ждут куда больше. Когда ты называешь себя QA - ты должен быть гарантом, что продукт качественный на каждом его этапе. Ты не исполняешь инструкции, а предотвращаяешь проблемы на всем цикле разработки от Discovery до Delivery.

Я выделаю 3 основные вещи, которые должен знать QA, чтобы стать крутым:

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

2. Ты автоматизируешь свою работу, а не тесты. Сфокусируйся на автоматизации рутинны: регресса, метрик, отчетов. Оптимизируй свои процессы, чтобы больше времени уделять качеству архитектуры и работы с пользователями. QA измеряется не количеством автотестов, а скоростью с которой поставляются новые (качественные) релизы.

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


Если сейчас ты подумал: «на кой мне это? я просто тесты пишу», — окей, пиши дальше и скоро придёт кто-то, кто делает всё это, и тебя заменят. Если же ты подумал: «Ну да, я и так это знал», — круто, ты на правильном пути. Только вот одно дело знать, другое — делать. Делай всегда.

Если хочешь стать действительно QA, а не Тестировщиком — начни использовать эти советы.

Плюшкины в тестировании

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

Почему это проблема? Потому что тесты, как и хлам у Плюшкина, не решают задач, а захламляют ваш Allure. План “писать тесты на всё” или “автоматизируем все баги” — это утопия, которая осталась в 2010-х. QA — это не про перепись продукта, а про минимизацию рисков.

Меня часто спрашивают: “Что делать с хламом в тестах и самими Плюшкиными? Как разрулить?” С удовольствием расскажу.

1. Если Плюшкин - ваш руководитель. Печальные новости: если он настаивает, чтобы вы собирали хлам вместе с ним, вы вряд ли что-то докажете. Объяснять бесполезно, менять его подход — ещё сложнее. Мой совет? Не трать время. Ищи место, где ценят качество, а не количество.

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

3. Если ты руководитель Плюшкина - помоги ему провести уборку. Задавай правильные вопросы: “Какой набор тестов нужен для этой фичи?” или “Что проверяет этот тест?”. Если ответа нет — отправляй всё в архив или на удаление. Тесты — это инструмент, а не музейная коллекция. Генерирует хлам дальше? Увольняй.

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

Супергерои только в фильмах

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

Что происходит с такой командой?

1. Команда похожа на беспомощных детей. Никто не принимает решений, все бегают к Вася.
2. В тестах срач. Хлам вместо структуры, автоматизация на нуле, релизы только через ручное тестирование. Разобраться может только Вася.
3. Команда не растет. Вместо процессов — культ Васи, который подменяет систему собой и блокирует рост.

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

Что делать с Васей?

Если у вас в команде Вася, вот план:

1. Покажите Васе, что его подход больше не работает. Скажите, что продукту нужна самостоятельная команда, а его гиперопека тормозит развитие и команды и самого Васи. Сделайте ему свой индвидуальный план развития.
2. Начинайте менять систему без него. Стройте процессы, формируйте метрики, перерабатывайте тесты, внедряйте автоматизацию. Покажите, команде, что она может работать без Васи.
3. Если Вася не меняется — прощайтесь. Да, всем будет грустно. И вы словите немало хейта при этом решении. Но знаете что? Команда быстро забудет и задышит, а продукт начнёт развиваться быстрее.

Вывод

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

А Вася? Он будет скучать и, возможно, где-нибудь напишет, что “Даня всё разрушил”. Только команда уже научилась жить без “супергероя”. И ей теперь намного лучше.

Как писать в чат тестировщику, чтобы всех выбесить

Если ты нормальный QA, ты знаешь, что вся команда ждёт именно тебя. Разработчики, менеджеры — все живут в ожидании твоего финального вердикта: “работает или нет?”. Но давай честно: просто сообщать результат скучно. Настоящий мастер QA превращает мессенджеры в инструмент хаоса, где каждый твой месседж становится точкой напряжения. Расскажу, как это делать правильно.

1. Меншены — наше всё. @developer — это слишком просто. Активно пользуйся @here и @everyone, чтобы все знали, что твой баг — это самая важная проблема на планете.

2. Пиши с пассивной агрессией. Вместо скучного “баг воспроизводится” пиши: “Ну, как обычно, не работает”. С лёгкой ноткой разочарования в человечестве — это важно.

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

4. Скидывай логи без комментариев. Не трать время на объяснения. Пусть команда сама разбирается в том, что значат эти 10 000 строк текста. Это их проблема, а не твоя.

5. Никакого контекста. Просто напиши: “кнопка не работает” — и пропади. Пусть они сами разберутся, какая кнопка, где она находится и что вообще происходит.

6. Капс — твой лучший друг. “ВСЁ ЛЕЖИТ!!!!!!!!!!!” — идеальное сообщение. Добавляй побольше восклицательных знаков и побольше слова “СРОЧНО”, чтобы команда почувствовала реальный драматизм ситуации.

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

8. Разбивай сообщения. Если у тебя есть мысль из 10 слов, отправь каждое слово отдельным сообщением. Это поможет держать команду в тонусе и сделает чат настоящим полем битвы.

Потому что спокойная команда — это скучная команда. Великие продукты рождаются в состоянии лёгкой ярости, а ты — ключевой двигатель этого состояния. QA, который умеет писать в чат так, чтобы всех довести, — незаменимый инструмент в любом проекте. 😉

Пишите в ChatGPT - «based on you know about me, draw a picture of my life»

У меня получилось вот так - нравится 🙂

Я на встрече самый глупый

«Я не понимаю весь код, который пишут разработчики, вдруг они подумают, что я дурачек.»

«Кажется, мне просто повезло, когда прошел интервью. Рано или поздно все поймут, что я тут случайно.»

«Как вообще тестировать архитектуру, если я даже не знаю, где она хорошая или плохая?»

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

1. Сомневаешься? Это хорошо. Если у тебя есть синдром самозванца, это значит, что ты осознаешь пробелы в своих знаниях. Это не слабость — это сила. Знание своих слабых сторон открывает дверь к росту. Признай это и составь четкий план: что ты хочешь узнать? Каких навыков тебе не хватает?

2. Ты не обязан быть идеальным. Ты не машина, которая знает всё и сразу. Нормально не разбираться во всех архитектурах или фреймворках автоестов. Не знаешь что-то? Найди эксперта, который знает.

3. Ошибаться — это нормально. Да, ты можешь пропустить баг. Да, твой тест может упасть. Ошибки — это не провал, это часть процесса. Даже у Маска ракеты падают, у тебя тоже есть на это право.

Заключение

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

Так что не бойся своих сомнений — это нормально. Именно они делают тебя профессионалом.
У тебя всё получится, дружище. 🚀

Все готовы к новогодним корпоративам?

Это я готовлюсь толкнуть ахуенную мотивационную речь своим сотрудникам в декабре 2024, вместо тринадцатой зарплаты

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

Давече обсуждали с Артёмом Ерошенко его новую версию 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 в компании мечты. Сегодня тимлид спорит с тобой на митинге, а завтра он дает о тебе рекомендацию в новую компанию. Ты думаешь, что прошлое осталось позади, но внезапно твой бывший коллега знаком с твоим будущим начальником. А теперь угадай, что он о тебе расскажет? Айтишка - это клуб старых знакомых, которые регулярно пересекаются.

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

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