Уйти в АйТи

Авось Частенько вокруг в жизни проскакивает "авось". Встречается не только в IT. Не осознавая того, мы полагаемся на случай, что создаёт риски для проектов. Тот самый "авось не со мной", "авось как-то само разгребётся". Так вот, как было сказано в одном фильме "Надежда - это не тактика". Киты управления Менеджер управляет тремя "китами": люди, процессы и технологии. Где-то еще маячит бюджет, но не всегда им возможно именно управлять, однако он очень сильно может как зажать команду, так и дать воздуха. Стоит упомянуть, что если результатов от команды нет, то и бюджет скорее всего не увеличат. Тут все просто. Итак: - Люди — это основа любого проекта, их мотивация и навыки определяют успех. - Процессы обеспечивают структуру и последовательность действий, помогая избегать хаоса. - Технологии предоставляют инструментарий для реализации проектов, и их актуальность напрямую влияет на эффективность работы команды. Если не заниматься всеми тремя аспектами, то пойдет перекос, и проект рискует не сойтись и быть заваленным. Практическое применение в IT Если говорить про IT, то нужны как минимум: - открытость с теми, с кем работаешь - регулярная обратная связь - прозрачность в планировании, отчетности и принятии решений - регулярные релизы, автотесты - краткосрочное, среднесрочное, долгосрочное планирование. Оно помогает держать дальний фокус, иметь ближайшие цели и цели на "через полгода" - постоянное обучение команды, чтобы идти в ногу со временем и технологиями - процессы разгребания багов, чтобы пользователи были довольны - улучшения технологии ("точить топор") - обновлять библиотеки, подключать AI и прочее Эти принципы не только помогают избежать проблем, но и создают доверие внутри команды. Процессы должны быть гибкими и адаптивными, чтобы быстро реагировать на новые обстоятельства или требования. Раньше я часто видел команды - "Процесс, значит процесс", которых попросту было не расшевелить, чтобы хоть что-то от них получить в обозримом будущем. Все атрибуты аджайла там были, а пользы для бизнеса, увы, почти никакой. Тут в очередной раз посвечу, что мы как правило всегда работаем не для себя - нужно быть полезным и делать то, что нужно тогда, когда нужно. Реальные примеры 1. В одной компании несколько лет назад у моего знакомого PM, в надежде "защитить" команду, руководитель не рассказывал, что дела стали идти хуже, скорее говорил наоборот. С одной стороны человека понять можно: он хотел сохранить команду. С другой команда не слепая и по косвенным признакам всё равно всё видела. Привело это к тому, что часть команды все равно разбежалась, а менеджер потерял время. Ведь если бы он вовремя и открыто поделился с командой, что есть проблемы, которые нужно решать, то скорее всего смогу бы "опереться" на команду и решать проблемы не в одиночку. Вовлечение команды в процесс решения проблем может не только предотвратить потери, но и укрепить коллективный дух и улучшить результаты. 2. Легаси-код, который не переписывают, так как "компания уже заплатила один раз". С этим скорее всего сталкивались почти все. Тут палка о двух концах - с одной стороны важно, чтобы код был актуален, с другой стороны зачем постоянно переписывать не добавляя ценности. Тут, как и во всем, нужен баланс и умение говорить ртом вести аргументированный диалог. Нужно учитывать, что нужно будет добавить в проект в плане фич, куда планируется развивать проект, какие еще фичи нужно сделать сейчас в срочном порядке и много другое. Тут универсального рецепта как мне кажется нет - нужно общаться и делать самое важное, что будет двигать ваш проект вперед. Если легаси мешает, его нужно убирать, возможно, даже очень срочно. Если не особо мешает, то может быть нет ничего страшного, если такой код полежит еще полгода в кодовой базе. Слепое переписывание без добавления ценности может быть ресурсозатратным и необоснованным. В общем, не давайте проектам идти на самотек. Не бойтесь смотреть вглубь проблем и использовать все ресурсы вашей команды для их решения. Не надейтесь на "авось", стройте стратегию и действуйте осознанно!

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

Красный флаг Есть моменты, когда необходимо привлечь особое внимание руководителя или коллеги из смежного отдела, стейкхолдера и пр. Если вы столкнулись с проблемой, которая требует срочного решения и помощи, не стесняйтесь поднимать красный флаг! Пример. Ваша команда уперлась в то, что нужно дорабатывать внешний sdk на незнакомом языке программирования. В саппорт приходят всё новые и новые пользователи, которые жалуются на этот момент. Как именно решать вы не понимаете или кажется, что исправление займет сильно много времени. При этом ваша команда обещала улучшить качество саппорта в этом году и получается, что вы можете нарушить обещание, если не будете решать эту проблему. Действия. Что тут можно и нужно сделать: 1. Рассказать команде о проблеме. Удостовериться, что это действительно проблема. Попытаться найти решение или план. Это нужно сделать достаточно быстро, если импакт проблемы большой. 2. Предупредить пользователей, что вы в курсе проблемы и занимаетесь ее решением. Если быстро решить не получается - предупредить их о том, что нужно будет подождать. Далее не пропадать и коммуницировать время от времени. Прозрачность в коммуникациях - крайне важна! Сидеть втихую и ничего не говорить неправильно. Даже если вы в это время занимаетесь решением проблемы. Пустота быстро заполнится чем угодно, но не тем, на что вы рассчитываете =) 3. Если решения нет или оно влияет на сроки проекта - поднимайте красный флаг. Общайтесь с руководителем по этому поводу, ему как минимум нужно бысть в курсе того, что проблема есть. Скорее всего он направит вас по правильному пути или порекомендует к кому обратиться. Правильно доносите серьезность. Поднять флаг важно не между делом в рамках какого-то иного обсуждения. Простое высказывание вашего переживания может попросту утонуть в потоке задач и проблем, которые сыпятся на голову вашего руководителя. Укажите на проблему четко и ясно. Это поможет акцентировать внимание на важности вопроса и минимизировать риски его упущения. Ваша проактивность может быть ключом к успешному решению проблемы и дальнейшему движению вперёд в рамках проекта. Хорошо работают встречи 1х1, планирование спринта, с командой на дейлике и подобное. Как понять, что пора. Помните, что нас нанимают, чтобы решать проблемы, а не создавать их постоянно. Поэтому этот инструмент, как и все остальные нужно использовать по месту и вовремя. Однако, если вы промолчите про пробемы на важном проекте и он не сойдется, то вы можете подставить своего руководителя под удар. Поэтому, как говорится, зависит от многих факторов.

А о чем встреча? Мне надо заранее как-то подготовиться? Наверняка вы хоть раз задавались вопросом: «А о чём будет встреча?» или сами его задавали. И наверняка замечали, что некоторые встречи проходят продуктивно и приносят результаты, а другие — нет. Часто причина в том, что у встречи нет чёткой структуры (для больших встреч) или хотя бы списка тем для обсуждения. Пришли, поговорили и разошлись. В этом посте я не буду объяснять, нужна ли вообще встреча. Предположим, она нужна. Представьте, что вы проводите совещание, чтобы обсудить новый проект. Без повестки и плана эта встреча рискует превратиться в хаотичное обсуждение разных идей и вопросов, которое легко может затянуться на несколько часов. При этом участники не смогут заранее подготовиться, потому что непонятно, что будут обсуждать. После такой встречи трудно вспомнить, что именно обсуждали и какие решения приняли. Как сделать встречу эффективнее? Рецепт прост: у каждой встречи должно быть описание (повестка), а в конце встречи нужно составить и отправить участникам резюме встречи (follow-up) и желательно убедиться, что его получили, прочитали и согласились. Зачем это нужно? ☝️ Структурность, целеполагание и экономия времени. Заранее определённая повестка помогает понять, на что направлены усилия встречи. Она организует обсуждение. Потенциально неважные вопросы можно заранее увидеть и вынести за рамки встречи или оставить их на конец. ☝️ Повышение качества коммуникации и вовлечённости. Повестка позволяет вовлечь всех участников в процесс, поскольку цель встречи понятна и каждый может подготовиться. Без повестки коллеги могут не понять, зачем им присутствовать на встрече и что от них требуется. Я, например, чувствую себя увереннее на встрече, когда знаю, какие темы будут обсуждаться, и заранее имею доступ к дополнительным материалам. ☝️ Запись итогов и последующие действия. У каждой темы должна появиться резолюция и, если нужно, задача (action item) с понятным исполнителем и сроками. Зафиксировать результаты встречи и отправить коллегам — одна из самых важных частей совещания! Ценность повестки особенно заметна при плотном графике встреч, когда приходится часто переключаться между разными задачами. Когда-то, когда у меня было 1–2 встречи в день, одна из которых дейлик, расписанная повестка не казалась чем-то очень нужным. Но сейчас, когда встреч гораздо больше, хорошо видно, что наличие повестки — это не формальность, а хороший инструмент, который позволяет проводить встречи продуктивнее. Фиксация итогов нужна в принципе всегда, чтобы посинкать ожидания всех участников встречи и зафиксировать, кто и что должен сделать. Тут, как мне кажется, иных вариантов вообще быть не может. --- Поздравляю всех с Новым Годом и желаю быть еще более продуктивными и полезными!

Как и обещал, пишу, какие изменения у меня случились в этом году. Итоги года не подвожу, просто расскажу небольшую историю. TL;DR Сейчас работаю техническим менеджером в Инфраструктуре Яндекса, занимаюсь Observability. Далее расскажу, как так получилось. Драконьего разговорного на собесах не было (кто понял, тот понял) 🙂 В январе 2024 года я задумался про смену работы - все было в порядке, просто хотелось бОльшего масштаба. Далее была череда собеседований в разные компании и началось все с поиска позиции тимлида. Что интересно, в разных компаниях это совсем разные обязанности. Мне не встретилось, кажется, ни одной вакансии, чтобы ожидания от тимлида повторились, везде свой нюанс. Где-то тимлид - это пипл менеджер, от которого вообще не ждут, что он будет программировать, т.е. совсем не нужно. Где-то ровно наоборт - это больше техлид, и вообще не пипл менеджер. Т.е. менеджментом людей там PM-ы или типа того занимаются. Где-то как из анекдота, что "вам нужен не сеньор, а целый отедел разработки". В каких-то компаниях было все в кучу с разными вариациями. Вопросов к этому всему нет, все спрашивают то, что им нужно. Было интересно и полезно. По ходу общения по вакансиям я все больше понимал, что меня в большей степени тянет в работу с людьми, execution и доведение до релиза каких-то больших фичей, а правильнее даже сказать проектов. Т.е. подумать и попланировать, как оно в целом будет работать, как на это мигрировать пользователей. И не только с точки зрения технической части проекта. Пойти договориться через 10 хопов с несколькими людьми и так далее. Потом я подумал, что на самом деле это желание было во мне довольно давно - много лет, просто я, видимо, не мог это понять. И тут я вспомнил, что относительно недавно говорил с одним теперешним коллегой. Он поделился, что в какой-то момент перешел с позиции тимлида на позицию тех. менеджера в Яндекс. И я такой - ну может оно, надо поизучать. А дальше дело техники и времени. В апреле вышел на новую работу и закрутилось. Итог. Я всем доволен и получил, что на самом деле хотел. Иногда нужно остановиться, выдохнуть и хорошо подумать, что ты на самом деле хочешь. А когда решение принято, не сомневаться и делать. Звучит просто, знаю, а по факту мы часто работаем по накатанной и не хотим что-то менять, хоть и хочется, а может даже и надо на самом деле. --- В новом году я желаю всем больше слушать себя, думать своей головой. Не бояться принимать решения! Больше доделывать, получать значимую дельту, а не просто работу работать. С наступающим!