Уйти в АйТи

Авось Частенько вокруг в жизни проскакивает "авось". Встречается не только в 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 хопов с несколькими людьми и так далее. Потом я подумал, что на самом деле это желание было во мне довольно давно - много лет, просто я, видимо, не мог это понять. И тут я вспомнил, что относительно недавно говорил с одним теперешним коллегой. Он поделился, что в какой-то момент перешел с позиции тимлида на позицию тех. менеджера в Яндекс. И я такой - ну может оно, надо поизучать. А дальше дело техники и времени. В апреле вышел на новую работу и закрутилось. Итог. Я всем доволен и получил, что на самом деле хотел. Иногда нужно остановиться, выдохнуть и хорошо подумать, что ты на самом деле хочешь. А когда решение принято, не сомневаться и делать. Звучит просто, знаю, а по факту мы часто работаем по накатанной и не хотим что-то менять, хоть и хочется, а может даже и надо на самом деле. --- В новом году я желаю всем больше слушать себя, думать своей головой. Не бояться принимать решения! Больше доделывать, получать значимую дельту, а не просто работу работать. С наступающим!

Тайное знание Простите, что долго не писал сюда. Постараюсь исправиться и в следующем посте расскажу, почему так произошло и какие изменения у меня случились в текущем 2024 году. Сегодня хотел напомнить про один из «лайфхаков», который поможет каждому делать работу лучше и быть на хорошем счету у всех, с кем ведешь дела. Совет до безобразия прост. Я живу так сколько себя помню. Однако, я за свою практику в it, раньше часто сталкивался с его игнорированием другими людьми. Примерно последний год в работе такого нет, а раньше достаточно часто наблюдал такое у разных людей. Совет хорошо работает и для других сфер деятельности. Итак: после того, как ты сделал работу, проверь её сам. Можно какой-то встречной проверкой. Если собираешь данные - найди другую метрику, которую делал не ты и сравни с ней. Или попробуй пересчитать через смежные данные. В общем, нужно проверить свою работу через другие данные. Это могут быть не отчеты или данные, а код для код ревью, например. Посмотрите сами на PR прежде, чем показывать его кому-то. Точно ли там все ок? Все ли закоммитилось или что-то не так? Тоже самое с передачей задач в QA. Стоит прокликать базовые сценарии самому. Я лично смотрел очевидно плохие PR-ы с неработающей логикой, где, чтобы найти ошибку, нужно было хотя бы один раз запустить свой код. Звучит просто, делается не всегда просто. Многие игнорируют. Однако имхо сдавать проверенную самим собой работу - это база. Лет 10 назад, во времена моей работы в рекламе, я наблюдал, как аналитик хватался отчетом, в котором при первом взгляде было видно, что средняя цена подушки для сна выходила около 10 млн рублей. И это на главной странице отчета, без фильтраций и пр. Т.е. это то, что видно без каких-то дополнительных кликов. Очевидно, человек не проверил отчет сам. В общем, подход - проверяй себя сам, позволит сдавать работу гораздо более высокого качества и не даст вам прослыть человеком, за которым нужно все прибирать и который часто сдает плохо сделанную работу. А теперь о минусах. Это отнимает время. Можно зависнуть очень на долго, считая и перепроверяя копейки или не супер важные вещи. Важно понимать, стоит ли игра свеч. Возможно, достаточно будет понять, что в целом будет так-то, чекнуть это и не ввязываться в детализацию. Добавлю, что в этом деле, как и во многих других, важна прозрачность, поэтому нужно обязательно сообщить всем участникам процесса о том, как сделана и проверялась работа, где вы срезали или собираетесь срезать углы. Прозрачность - тоже база, писал про это в канале ранее. Всех с наступающим!

Управление ожиданиями Представьте, что вы договорились о том, что вам придут менять батарею в комнате в субботу в течение дня. Вы строите планы на выходные исходя их этого. В пятницу сами уточняете всё ли в силе и получаете ОК. В субботу сидите ждете, не идете гулять, а человек взял и не пришел. Хуже еще, если сам не звонит с извинениями и оправданием. Наверняка такое было с каждым. Что подумаете? Что будете делать? Захотите ли с ним работать? Разработка, как и другие виды деятельности, не исключение. При этом не важно какая должность, но чем выше, тем больше прозрачности от вас будут ожидать. Если вы о чем-то договорились и не можете это выполнить, то обязательно нужно как можно раньше предупредить и передоговориться. Делать это лучше с хорошими аргументами и планом, как будете решать схожие риски в будущем. По пунктам: ☝️Проактивно держите в курсе заинтересованных лиц ☝️Не бойтесь передоговариваться. Не укусят. Хуже будет, если будете молчать ☝️Не обещайте того, в чем не уверены. Говорить, что сейчас период неизвестности - нормально. Но агументируйте почему сейчас такая ситуация, а также расскажите план по снижению неопределенности и сроки. Понятное дело, часто так делать будет странно ☝️Если тема сложная - лучше сделать отдельную встречу для разбора и пояснений, чтобы не создавать винегрет в головах у коллег И еще раз - всегда лучше передоговориться, чем просто молча продолбать все сроки и ждать, что оно как-то само там разрулится. Оно разрулится, конечно, но не в вашу пользу.

Рубрика: простые истины ☝️Сотрудника нанимают для того, чтобы он решал проблемы, а не создавал их. Поэтому помните, что согласовывать придуманные вами решения - это ОК. Постоянно эскалировать проблемы до своего руководителя и спрашивать решения у него (или еще хуже вообще не эскалировать и тихо ждать, когда все загорится) - не ок. ☝️Наверняка вы работаете в команде. Команда должна достигать успеха. С вами команде должно быть лучше, чем без вас. Соответственно вместо того, чтобы придумывать, что помешает команде сделать задачу, придумайте как помочь команде или смежникам довести задачу до завершения. Завершение - это когда пользователи начали пользоваться и рады, а не когда код написан. ☝️Если кто-то, по вашему мнению, "творит какую-то дичь", надо это с ним обсудить и послушать почему делается именно так. Возможно нужна корректировка, а может бы все ок, просто вы не так видели проблему. -- p.s. Надеюсь, что неделя у всех выдалась продуктивная и теперь можно спокойно отдохнуть. Всем удачных выходных!

Коммуникации Хочется обратить внимание на эту тему коммуникаций. Часто сталкивался с тем, что человек что-то быстро тебе написал по пути и, кажется, даже не подумал, что его могут не так или не полностью понять. В итоге тратится очень много времени на уточнения, решения проблемы, когда "сделал выводы, правда не те", возможно нужно будет созваниваться и в общем-то расходывать сильно больше времени, чем могло бы на это уйти. В итоге день может превратиться в вязь растянутых по времени переписок, ты устанешь от когнитивной нагрузки и сделаешь мало дел. Рецепт тут простой: ☝️ Сформулируй в голове мысль, которую хочешь донести ☝️ Напиши и перед отправкой перечитай то, что получилось. Не ленись это сделать несколько раз, если будет нужно! Точность комуникации важна ☝️ Проверь доносит ли твой текст мысль полностью. Все ли будет понятно тому, кому ты пишешь (а не тебе), весь ли контекст есть, чтобы человек тебя успешно понял Тоже самое касается постмитингов. Не написал - скажут, что "этого не было", написал не точно - тоже мало смысла будет в этой активности.

Тот самый момент До компа у меня был Dandy в виде большой компьютерной клавиатуры. Там можно было картриджи вставлять и играть, а также запускать интерпретатор Basic. В какой-то момент старший брат такой важный со школы вернулся, сказал "ща покажу", открыл интерпретатор Basic и начал что-то с тетради школьной набирать. Потом всех позвал и нажал Enter. На экране начали рисоваться фракталы. Красивые такие. Анимация была плавной. Сказать, что я тогда офигел - ничего не сказать. Просто представить не мог, что школьник может сделать что-то, что будет на экране телевизора что-то рисовать. Вот тогда я понял - это моё. Позднее, с другом Лехой, мы много на чем кодили. Сперва на QBasic, потом Visual Basic, C++, Visual C++, так и закрутилось. В 2020 году я писал статью об этом всем. Сейчас постепенно мигрировал в менеджера, но кодить все равно очень люблю. Мне всегда было интересно как народ попадает в IT, поэтому если кто найдет в себе силы поделиться - буду рад.