Привет, Хабр! Я Николай Видов, разработчик в команде чатботов. Я работал как в небольших компаниях, так и в тех, которые на слуху: EPAM, QIWI, Т-Банке. За время работы я часто сталкивался с понятием продуктовости: «Разработчики должны активно участвовать в бизнесе», «Разработчики должны предлагать улучшения для продукта», «Разработчики должны аргументированно спорить, если не согласны с предложенной функциональностью».

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

Продуктовый разработчик — это следующая ступень эволюции разработчика, который активно участвует в бизнес-процессах. © Никита Пастухов, мейнтейнер FastStream

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

Принципы продуктового разработчика

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

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

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

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

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

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

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

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

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

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

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

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

Но тут есть нюанс: важно правильно донести информацию. Не «Ваня — ужасный сотрудник, он не отвечает уже два дня», а что-то вроде «Ваня не отвечает по вопросу N уже больше двух суток. Может ли кто-то другой помочь с этим?». Не «Это решение — полный провал», а «В этом решении есть недостаток: в нем не учитывается кейс M». Задача — не навязывать свое мнение, а подсветить проблему тем, кто за нее отвечает. Что они будут делать с этой информацией — уже их выбор.

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

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

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

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

Сопровождение задачи — это не просто «взял тикет, написал код, закрыл». Это процесс, который начинается с идеи и заканчивается подсчетом результатов А/B-теста. Это про понимание бизнес-процессов, про взаимодействие с аналитикой, про то, чтобы быть не просто исполнителем, а полноценным участником команды, который видит картину целиком. Именно это делает действительно ценным специалистом.

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

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

Несколько ключевых моментов при оценке сроков:

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

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

• Тестирование и ревью. Нужно учесть время, необходимое на тестирование и валидацию изменений. Это може�� включать как автоматизированные тесты, так и ручное тестирование.

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

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

Очень просто сказать: «Я отвечаю только за код». Но в реальном мире готовый код — это еще не готовая задача. Из-за этого у меня часто возникали проблемы со сроками, когда мои ожидания готовности не совпадали с ожиданиями лида или продакта. Это урок, который я усвоил на собственном опыте: планирование — это не только про код, но и про весь путь до продакшена.

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

И если вдруг что-то пошло не так (а такое случается у всех, кто работает), важно не прятаться за оправданиями или молчанием. Открытый разговор с руководителем о проблеме — это не слабость, а признак зрелости и готовности решать трудности. Это как сказать: «Да, я вижу, что-то пошло не так, и я готов это исправить».

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

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

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

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

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

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

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

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

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

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

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

Я работал с продуктом на Python 2.7 и Django 1.11, которому было больше 15 лет. Там техдолгом вообще никто не занимался. Это был настоящий кошмар. Каждое действие можно было выполнить тремя способами, а каждая новая фича могла сломать что-то в самых неожиданных местах. Задачи с багами появлялись в три раза чаще, чем задачи с новыми фичами. Это был продукт, который буквально кричал: «Пожалуйста, займитесь мной!» Поэтому, если хотим ехать не только быстро, но и далеко, решение техдолга должно стать правилом.

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

• тестировщиком, когда писал BDD-тесты и проводил ручное тестирование;

• солюшен-архитектором, когда проектировал новый сервис в SOA или микросервисной архитектуре;

• DevOps-инженером, когда писал куберманифесты и глобальные CI/CD;

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

• системным аналитиком, когда продумывал техспеку задачи, общаясь с заказчиками;

• даже иногда дата-аналитиком, когда готовил данные и пайплайны для аналитических отчетов;

• дата-сайентистом, когда запихивал модели в кастомный сервинг.

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

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

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

В продуктовой разработке нужен системный взгляд: понимание бизнес-целей, взаимодействие с пользователями и постоянное улучшение продукта. Иногда бывает так, что неделями не пишешь ни строчки кода, разве что участвуешь в code review. Раньше это могло вызывать тревогу — мол, а я вообще разработчик или кто? Но со временем приходит понимание: это нормально. Это часть новой реальности. Наша задача — решать проблемы, а не просто писать код. И это требует гибкости, стратегического мышления и умения адаптироваться.

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

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

• Ограничить количество задач. Я стараюсь не брать больше 1—2 задач, требующих концентрации. Это помогает избежать перегрузки и сохранить «мыслетопливо» для оперативных вопросов и задач, которые требуют быстрого реагирования.

• Установить четкие временные блоки. Я делю свой день на временные блоки, выделенные для работы над задачами, требующими концентрации, и для общения с командой. Это помогает оставаться продуктивным и не терять фокус.

• Использовать техники управления временем. Можно попробовать техники, такие как Pomodoro, чтобы поддерживать концентрацию и избегать выгорания.

Оставляй неприкосновенное время. Когда дело доходит до управления временем, готового рецепта, увы, нет. Из опыта могу сказать, что многие разработчики находят полезным выделять часы тишины для сосредоточенной работы. Это могут быть один или несколько слотов по 1—3 часа в зависимости от вашей загруженности и специфики работы.

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

Вот несколько советов, как организовать свое неприкосновенное время:

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

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

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

• Быть гибким. Иногда обстоятельства требуют изменений в расписании, поэтому важно уметь адаптироваться.

Неприкосновенное время — это личный ресурс для достижения максимальной продуктивности и качества работы. Для себя я выявил пиковые часы с 09:00 до 11:00, до дейлика, и периодически ставлю себе в Аутлук промежутки времени, когда я должен буду кодить, чтобы меня не отвлекали. Это помогает оставаться в фокусе и достигать лучших результатов.

Как не деградировать в разработке

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

Работать по 1—2 часа в день — это, конечно, слишком мало, но и 8 часов — не всегда оптимально. ИМХО, и��еальное количество — это 6—7 часов, когда нет горящих бизнесовых задач. Но все же это индивидуально и каждый выбирает свой подход.

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

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

Кроме технических задач у нас есть:

• Внутренние курсы — отличная возможность прокачать свои навыки и узнать что-то новое.

• Доступ к внешним ресурсам, например к библиотеке O'Reilly, где можно найти массу полезной информации.

• Выступления на конференциях — как внутренних, так и внешних, где можно поделиться опытом и узнать о последних трендах.

• Внутренние техномикрофоны — это такие мини-сессии, где каждый может рассказать о том, что ему интересно.

А во внерабочее время можно читать книги по программированию, изучать статьи, осваивать новые инструменты или работать над open-source-проектами. 

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

Следуй своему ИПР. Если ты чувствуешь, что твои глаза разбегаются и хочется делать все и ничего одновременно, стоит обратиться к руководителю. Обычно такие ситуации решаются через ИПР — индивидуальный план развития. Этот план помогает отталкиваться от цели, которой хочется достигнуть.

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

Иногда выдумывать ИПР с нуля может быть сложно. Поэтому перед составлением плана хорошо определить цель и подготовить идеи.

Если руководитель готов участвовать в таких активностях, это отлично. Если нет, существуют площадки для внешнего менторинга, такие как GetMentor.

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

Откуда брать энергию и время

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

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

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

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

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

Для начала можно поставить себе достижимую цель, например прочитать «Властелина колец». Важно руководствоваться принципом самурая: «У самурая нет цели, только путь». Цель — это лишь средство для выработки привычки, не более.

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

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

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

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

Вот несколько шагов, которые могут помочь:

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

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

3. Обсудить с руководителем. Если передать задачи некому, но активностей слишком много, нужно обсудить это с руководителем. Возможно, он сможет помочь перераспределить нагрузку или предложить другие решения.

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

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

Отдыхай правильно. Важно давать своему мозгу отдыхать не только в обеденное время, но и в течение рабочего дня. Делать перерывы. Будь то техника Pomodoro или какая-то своя методика — это не так важно. Главное — делать это часто (раз в час, два или три) и правильно. Если сложно выделить время для отдыха, можно поставить его в календаре. 

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

Самый качественный отдых — это когда ничего не надо решать, никто от тебя ничего не хочет и ничего нового не происходит.

Примеры качественного отдыха:

• Прогулка по знакомому маршруту.

• Прослушивание любимой музыки.

• Созерцание вида из окна с кружкой чая.

• Глажение своего кота.

• Выполнение домашних рутинных дел.

• Лежание под пледом, глядя в потолок.

• Пересмотр уже известного сериала.

• Любое другое действие, где мозг не напрягается.

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

Как жить в продуктовом мире

У нас есть:

• Разработчик, который не только разрабатывает.

• У которого могут быть побочные активности на работе.

• Который обучается и развивается как разработчик в рабочее и внерабочее время.

Значит, нужно снизить когнитивную нагрузку по максимуму. И вот что я использую у себя в работе и предлагаю использовать вам.

Приведи в порядок документацию на работе. Особенно это актуально, если продукт состоит из множества сервисов и микросервисов. Часто документация превращается в свалку и устаревает. Более того, она может быть раскидана по разным местам: что-то закреплено в мессенджере, что-то находится в десяти спейсах в Confluence, а часть может быть в собственных сервисах типа DAAS (Docs as a Service), как правило, автосгенерированных. Плюс становится непонятно, к кому обращаться по вопросам определенных сервисов.

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

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

Используй чек-лист. Чек-листы — это простой, но мощный инструмент. Вот как они помогают и почему это важно:

• Освобождают память. Чек-листы позволяют не держать все задачи в голове. Это освобождает оперативную память для более важных и креативных задач.

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

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

• Снижают стресс. Знание того, что есть план и ничего не упустишь, помогает снизить уровень стресса и тревожности.

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

Разберись с активностями на работе. Этот шаг поможет подготовиться к разговору с руководителем, если чувствуешь, что не справляешься с текущей нагрузкой. Вот как можно подойти к этому процессу:

• Составить список активностей. Определить все текущие и доступные побочные активности. Это могут быть как основные обязанности, так и дополнительные задачи.

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

• Обсудить с руководителем. Это поможет ему понять текущую загрузку и предпочтения, а также найти способы оптимизации работы.

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

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

Примеры автоматизации:

• CI/CD. Если в процессе разработки есть задачи, которые выполняются вручную, можно попробовать интегрировать их в CI/CD. Это может включать автоматическое тестирование, сборку и деплой.

• Использование LLM. Сегодня происходит бум больших языковых моделей (LLM). Некоторые компании создают своих агентов или предоставляют корпоративный доступ к существующим, таким как GPT. Это открывает еще больше возможностей для автоматизации генерации гипотез, создания MVP, генерации текстовых описаний или генерации документации. 

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

Выводы

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

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

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

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

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

У нас в Т-Банке вводят ИИ во все сферы жизни — от кодинга до помощи операторам. Возможно, это изменит структуру будущих команд. Но одно знаю точно: я стараюсь быть в тренде, а значит, не останусь у разбитого корыта и буду этим всем в конечном счете управлять.

На прощание оставляю несколько полезных ссылок. И залетайте в комментарии поделиться своим опытом ?

Полезные ссылки:

На тему техдолга:

• Техдолг. Большое руководство

• Техдолга не существует

На тему эффективного управления временем и задачами:

• Сначала лягте, потом читайте: как перестать уставать на работе

• Многозадачности больше не существует. Зачем снова становиться однозадачным