Всем привет! Я думаю, что каждый разработчик, переходящий на роль тимлида, изначально стремится вернуться к кодированию и решению задач вместе с командой. Позже мы начинаем охватывать больше бизнес-задач и проблем, углубляясь в проблемы, связанные с бизнесом, общением между отделами или клиентами и архитектурой. С этого момента у нас уже нет ни времени, ни желания заниматься чем-то другим. Календарь типичного тимлида начинает напоминать следующее: Как мне вернуться к разработке и снова начать программировать? С чего мне начать? Также важно оценить, насколько вы действительно заняты и как выглядит ваш типичный рабочий день. Занимаетесь ли вы самосовершенствованием после работы или нет? Это все решающие факторы. Основываясь на своем опыте, предлагаю пройти путь от «нет времени ни до, ни после работы, нет желания и возможности» к «Я все время за компьютером, и это моя страсть». Блокируйте свое время! Эффективной отправной точкой является выделение времени для разработки. Просто выделите «время кодирования» в своем календаре на час или больше. Если возможно, подумайте о том, чтобы каждую неделю выделять полдня или целый день специально для решения технических задач. Да, это может включать перенос встреч, исключение ненужных или обсуждение необходимости посещения некоторых из них. Однако подумайте о том, актуальны ли для вас определенные сеансы ухода. Возможно, вы проведете там час без особого эффекта? Направьте это время на программирование! Проверка кода вместе с вашей командой! Второй и наиболее важный аспект оптимизации определенных процессов вокруг вас — это донесение ценностей или подходов проекта до ваших коллег. Не каждый разработчик видит одинаковый подход к решению проблем, поэтому важно заранее определить стили кодирования, тестовое покрытие, а также фундаментальные методы и механику платформы или сервисов отдельно. Всегда проводите обзоры кода, а если есть ощущение, что вопрос затягивается, соберите команду для быстрого решения проблем в запросах на включение (PR). Как показывает практика, такой подход ускоряет время решения проблем и, как следствие, сокращает время вывода функций на рынок. Со временем ваша команда полностью поймет и начнет применять подходы к разработке, требующие меньшего внимания. Вы будете сосредоточены исключительно на решении поставленной задачи и ее логике, что сэкономит первоначально несколько минут, а в долгосрочной перспективе потенциально часы времени разработки. За что вы несете ответственность? Возможно, это не самая очевидная задача, но спросите себя, за что вы несете ответственность? Что вам нужно сделать? Запишите все эти пункты на листе бумаги и посмотрите, не взяли ли вы на себя ничего лишнего. Возможно, вы выполняете чужую работу только потому, что это вошло в привычку. Возможно, вы помогали соседней команде в ее процессах и все еще участвуете в ней. Четко определите свою позицию и то, какой вклад вы вносите в проект или компанию. Если вы возглавляете большую команду, используйте заметки, в которых можно создать очередь задач и проблем. Всегда проводите проверки и убедитесь, что, например, если вы являетесь руководителем DevOps, вы случайно не выполняете задачи, предназначенные для разработчиков мобильных приложений. Если вы оказались перегружены задачами и зависимостями, стоит остановиться, поговорить с начальством и разобраться, почему это происходит в вашем отделе. Например, если вы являетесь командой DevOps, отвечающей за инженеров по обработке данных, и у них есть собственный руководитель, возможно, имеет смысл делегировать обязанности обратно их руководителю, а не вашему отделу. Создавайте спецификации и необходимые документы для оформления соглашений или любых скрытых деталей по настройке или обслуживанию и возвращайте людей в соответствующие команды. Важно отметить, что это всего лишь пример, и у каждого свои команды и принципы их формирования. Приоритизация и делегирование Возможно, вы не успеваете сделать что-то, потому что приоритеты постоянно меняются. Вся компания работает по двухнедельным спринтам, но вас такая схема больше не устраивает, и вы не видите в ней ценности. Функции не доходят до завершения в течение спринта из-за слабых приоритетов. Это актуально для сервис-ориентированных команд. Рассмотрите возможность изучения канбана или подхода «водный поток». Наши команды — как отдельные острова, на которых мы имеем право попробовать изменить процессы к лучшему. Тестируйте переход на новый подход в течение месяца и наблюдайте за своими показателями. По моему опыту, пары недель хватило, чтобы заметить, что Scrum нам не подходит, и мы перешли на Kanban. Наше время выхода на рынок резко сократилось, поскольку теперь приоритеты могут меняться дважды в неделю, что позволяет нам быстрее решать проблемы. Далее попробуйте разбить команду на доменные зоны, но не слишком детально. Погружайте каждого члена команды, следуя правилу 70/30: 70% посвящены своему основному стеку, проекту или продукту 30% на все остальное Если в вашей команде более 5 человек, вы охватите все услуги и функции, что позволит сотрудникам быстрее погрузиться в предметную область. Чего это дает? Это позволяет вам делегировать некоторые задачи команде, а не делать все самому, если вы видите, что у разработчика уже есть хорошее понимание и погружение. Вам не нужно описывать весь алгоритм и интеграции! Они уже все это знают! Тайм-менеджмент и продуктивность Как команда планирует свое рабочее время? Начнем с простого: как работать в команде? Посмотрите на свои оценки и на то, как вы оцениваете задачи. Все ли в порядке? Возможно, есть возможности для улучшения или введения коэффициента загруженности? Коэффициент рабочей нагрузки помогает понять, насколько загружен каждый член команды в течение спринта или недели, учитывая потенциальные отвлекающие факторы для поддержки. Например, если вы являетесь сервисной командой, которой нужно поддерживать собственный продукт, другие команды могут обратиться к вам за помощью или запросить улучшения, что приведет к трате времени на общение в рамках спринта. То же самое касается борьбы с ошибками; вы часто можете отвлекаться на решение неотложных проблем в производственной среде. Но это отдельная тема, и я бы посоветовал просмотреть мою предыдущую статью о том, как постепенно улучшать эту область. https://hackernoon.com/just-go-ahead-and-test-your-project-part-1?embedable=true Теперь вернемся к коэффициенту. Если мы признаем, что каждого из нас вызывают в чат или встречу хотя бы 1 день из 5 для решения проблемы, учтите это при планировании. Таким образом, вам реально удастся выполнить задачи, которые действительно принесут пользу команде, потенциально высвободив время для написания кода. Попробуйте технику Помидора. Ничего новаторского; просто используйте приложение на своем телефоне, которое позволяет вам сосредоточиться на задаче в течение определенного интервала времени, например, 45 минут. Думаю, ничего особенного. Используйте трекеры. Проведите расследование, на что вы тратите свои 8 рабочих часов — записывайте каждый час и минуту вашей деятельности в течение недели или месяца. Вы можете обнаружить факторы, которые вас отвлекают, или заметить, что 15-минутная прогулка после обеда помогает вам работать более эффективно — возможно, это ключ к успеху? Или, если у вас три встречи подряд, вы обнаружите, что целый час ничего не делаете, просто читаете спецификации? Может быть, для вас это сложно? Цель состоит в том, чтобы внимательно изучить то, что вы делаете, и я верю, что вы определите области, требующие улучшения. Участие в технически сложных проектах Если вы не можете присутствовать на собраниях, посвященных проектированию систем или архитектурным решениям, прочтите последующие материалы или документацию. Постарайтесь понять, как и что решает проблему. Такие встречи желательно не пропускать и стремиться максимально погрузиться в технические аспекты. Выберите проекты или аспекты проекта, которые требуют глубокого погружения в код. Это поможет вам быть в курсе новых технологий и методологий разработки. RnD для вас Если вы заметили области проекта, в которых есть проблемы или функциональность которых можно улучшить, смело создавайте прототипы. Это не только позволит вам визуализировать предлагаемые изменения, но и предоставит команде реальный материал для обсуждения и принятия решений. Основная цель — не просто продемонстрировать идеи, а реализовать их в проекте, если они окажутся действительно значимыми или полезными. Например, если вы всегда мечтали перенести устаревшие сервисы с Java 1.8 на версию 21, почему бы не попробовать? Создайте прототип, покажите его команде, разработайте решение и тщательно задокументируйте весь процесс для дальнейшего использования. Такой подход помогает не только реализовать технические улучшения, но и создать общее понимание внутри команды относительно потенциальных изменений. Таким образом, вы сможете внести конструктивный вклад в проект, обеспечив его эффективное развитие и способствуя инновациям. Обзорная точка! у вас будет пара часов, чтобы написать код, предложить решения, а затем можно будет передохнуть. Конечно, руководящая позиция просто не позволит вам делать и то, и другое, и если вы по-прежнему сосредоточены на развитии, возможно, стоит подумать о возвращении. На этом этапе В этом нет ничего плохого — осознавать, что управление становится для вас скучным, даже если вы в нем преуспеваете, — это нормально. Просто на данный момент это потеряло для вас свою привлекательность. Если у вас еще есть свободное время Обучение и саморазвитие Постоянно обучайтесь, читая техническую литературу, изучая образовательные курсы и участвуя в технических конференциях. Это поможет вам быть в курсе последних тенденций и лучших практик в разработке программного обеспечения. Чтение технической литературы дает уникальную возможность углубиться в глубины новых технологий, методологий и передового опыта. Это могут быть книги, статьи, блоги и другие материалы, освещающие различные аспекты разработки программного обеспечения. Прохождение образовательных курсов — это структурированный и систематический способ получить знания по новым темам и технологиям. Платформы онлайн-курсов предлагают широкий спектр курсов по различным языкам программирования, платформам и концепциям. Участие в технических конференциях открывает возможность не только узнать о последних тенденциях и инновациях, но и пообщаться с профессионалами отрасли. Конференции предоставляют платформу для обмена опытом, обсуждения сложных вопросов и налаживания связей внутри технического сообщества. Таким образом, непрерывное обучение посредством чтения, прохождения курсов и посещения конференций позволяет разработчикам программного обеспечения не только идти в ногу с последними тенденциями, но и активно интегрировать новые знания и навыки в свою повседневную работу. Примеры: Leetcode, Udemy или Youtube (иногда там можно найти действительно хороший БЕСПЛАТНЫЙ контент!). Работа над личными проектами Если возможно, работайте над личными проектами в свободное время. Это не только улучшит ваши навыки программирования, но и послужит источником новых идей для вашей основной работы. Кроме того, объединение этого занятия с пунктом исследований и разработок из статьи может стать дополнительным стимулом для творчества и инноваций. Работа над личными проектами позволяет вам применять свои навыки в практических сценариях, экспериментировать с новыми технологиями и решать реальные проблемы. Эти проекты могут включать разработку собственных веб-приложений, создание проектов с открытым исходным кодом или участие в интересных побочных проектах. Интеграция этой деятельности с упомянутыми ранее исследованиями и разработками (НИР) позволяет вам создавать прототипы и демонстрировать их на своем рабочем месте. Открытие вашего проекта для публики, например участие в разработке с открытым исходным кодом, не только улучшает ваши навыки, но также способствует построению ценных профессиональных связей и получению признания вашего творчества. Однако важно помнить, что соблюдение политики конфиденциальности (NDA) вашей основной работы является приоритетом. Прежде чем приступать к личным проектам, желательно проконсультироваться с юристами и руководством, чтобы убедиться, что ваш творческий процесс не нарушает установленных правил, и способствовать свободному развитию вашей творческой энергии при сохранении конфиденциальности конфиденциальных данных. Заключение Поиск времени для программирования в качестве руководителя группы требует сознательных усилий и эффективного управления приоритетами. Помните, что ваша роль предполагает не только непосредственное руководство командой, но и поддержание ваших технических навыков на удовлетворительном уровне. Это будет непросто, и я желаю вам удачи! Проблему я увидел уже давно. Если вы хотите читать профессиональные книги, я бы порекомендовал вам прочитать книги: и ссылка ссылка.
