Работа с техническим бэклогом

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

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

- Рефакторинг и/или разделение модулей

- Доработка покрытием тестов

- Выделение новых стендов (если это не делается просто в вашей компании)

- Наполнение стендов тестовыми данными

- Проведение нагрузочного тестирования

- Разбивка проекта на сервисы

- Ресерч, который направлен на поиск лучших решений для проекта

- и т.д.

Все это должно быть собрано в одном месте, приоритезировано и оценено.

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

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

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

Максим Шаламов
#советы

Где граница, когда разработка может менять задачи бизнеса, а когда нет?

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

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

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

Где точно можно разгуляться?
Со своей стороны вы тоже должны выстраивать собственные границы. Вы отвечаете за качество проекта и все технические решения. Поэтому то, что вы на 100% можете менять в проекте это техническая сторона. Вы должны выбирать, как будет строится проект внутри. Если во время выполнения задачи вы поняли, что другое техническое решение подойдет лучше, а бизнес внешне получит тоже самое, то никакого отдельного подтверждения от вам здесь не нужно. Есть только один нюанс: нельзя менять техническое решение, если это затронет метрики бизнеса. Вы вольны делать с технической стороной проекта все, что вам нужно, пока по функционалу, по метрикам и по времени, затраченного командой на работу, для бизнеса ничего не меняется. Если вы вдруг решили потратить 2 месяца чистого времени на смену фреймворка, да еще и проект после этого стал работать в два раза медленнее, то бизнес вам точно спасибо не скажет. Оценивайте, насколько технические изменения касаются бизнеса, если они заметно сказываются на бизнес-части проекта, привлекайте к решению бизнес. Как правильно подавать свое решение и убеждать бизнес в необходимости изменений, мы подробно говорили в документации к работе с ПО,

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

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

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

Александра Шаламова
#agile_который_работает

Ребят, у нас вышло видео с моими фишками прохождения собеседований. Я там много делюсь своим опытом и реальными историями, рассказываю один постыдный случай, как я мега облажалась на собесе 🤦🏼‍♀️ и как я это пережила. Ну и конечно рассказываю, что мне всегда помогало собирать предложения из таких компаний, как Яндекс, Авито, Сбертех, Lazada, Mail.ru и прочих. Заходите, буду вам рада 🥰

https://youtu.be/vP4fmlzPwos

Ощущение рутины - первый признак начала деградации

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

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

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

А вы что думаете по этому поводу? Обязательно напишите в комментариях свое мнение. Или выразите его хотя бы реакцией к посту - для нас это очень важно!

#советы

"Почему меня не уважают?"

Этот вопрос нередко задают, а еще чаще о нем думают. Сюда же можно добавить про восприятие в серьез и про "почему меня не слушают". Поделюсь, как всегда, своим мнением.

Я обычно в ответ задаю простой вопрос: "а за что тебя должны уважать (слушать/…)?". Часто мы приходим к несоблюдению своих обещаний, постоянным конфликтам на ровном месте, боязни отстаивать свое мнение и т.д.

Чтобы тебя уважали другие (слушали, воспринимали и т.д.), нужно уважать себя самому и уважать других. Для того, чтобы уйти от расплывчатых философских измышлений поясню свою мысль.

Как нужно себя вести, чтобы тебя уважали:

- На твои обещания можно положиться. Обещал - сделал, сложности это твои проблемы. В самом худшем случае, вовремя сообщаешь о проблеме, при этом объективность проблемы должна быть очевидна всем.

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

- Ты должен уметь слышать и адекватно воспринимать чужое мнение. Ты можешь быть не согласен, но вести спор или обсуждение нужно корректно и по существу. Ты должен быть готов, что выберут не твое предложение и уметь уступать, а не обижаться на весь мир и сводить все к срачу.

- Ты должен быть готов брать на себя ответственность за провалы, а не только лавры победы. Сложно уважать человека, который не может принять свои ошибки и ходит обвиняет всех вокруг. Так же, как и того, кто пытается присвоить себе успехи всей команды. Успех общий, неудачи обычно имеют имена (в моих командах неудачи тоже общие, но при разборе конкретных проблем всегда есть имена).

Лично я никогда не мучал себя вопросом, кто уважает меня, а кто нет. Однако, прийти к общей стратегии с коллегами или подчиненными обычно удается, поэтому для себя я вижу этот вопрос так.

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

Максим Шаламов
#руководителю #разработчику

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

https://youtu.be/EpMjYQTCGnU

О чем мы писали в Марте

Если вы что-то пропустили в прошлом месяце, то самое время наверстать:

Зачем разработчику уметь работать по процессам, если есть руководители и скрам-мастера

Что я получу взамен, если возьму на себя ответственность?

Алгоритм работы с техническим бэклогом

Когда разработка может менять задачи, не спрашивая бизнес

Чем опасно ощущение рутины

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

Оставайтесь с нами, в заготовленных постах уже лежит много интересного! А если хотите пост на свою тему, то задавайте вопросы в нашего бота.

Зачем я здесь пишу?

Люди часто задают вопросы “зачем ты что-то делаешь”. Сегодня расскажу, зачем я делюсь своими мыслями здесь на канале. У меня есть две причины.

Первое, я пишу о том, что попробовал и с чем у меня или моих коллег / подчиненных были проблемы. Чтобы помочь их пройти правильно (по крайней мере на мой взгляд). Моя позиция, что, чем больше сильных специалистов и руководителей будет вокруг, тем более амбициозные проекты будут запускаться и реализовываться. Тем больше возможностей будет и у меня в том числе. Считаю ли я, что могу вырастить себе конкурентов и что-то потерять? Конкуренция это хорошо, у меня сильно развит соревновательный дух и такая возможность меня скорее радует, чем пугает.

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

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

Максим Шаламов

Не знаешь, что делать? Пиши план.

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

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

Часто пишете план работ, прежде, чем брать за задачу? Делитесь в комментариях. Кстати, у меня есть видео-пример, как я сама составляю план работ перед началом проекта.

Александра Шаламова
#советы

Моя главная ошибка в карьере

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

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

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

Не забывайте ставить под сомнение свою правоту, чтобы не мешать себе расти.

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

Больше полезных вопросов для своего роста вы найдете в мини-курсе по борьбе с рутиной. Какое отношение рутина имеет к росту мы недавно рассказывали.

Александра Шаламова
#советы

Недоступен - не решаешь

Сегодня поделюсь очень короткой, но от этого не менее важной мыслью. Много проблем у начинающих лидов бывает с ситуациями, когда они хотят стать точкой входа по изменениям в команде. Чтобы, если меняются требования, это не расползалась по людям, а собиралось и фильтровалось в них. Идея правильная и они даже могут убедить начать так делать. Но все ломается, если вы не будете доступны. То есть, если нужно обсудить изменения, а вы выпадаете на день, два, три, то конечно никто через вас работать не будет. Это касается любых коммуникаций. Хотите, чтобы работали через вас, в оговоренное время или по понятному сценарию (например по выставленным в свободные слоты встречам), - вы всегда доступны, подключаетесь и вовлечены в процесс. Иначе это работать не будет.

Максим Шаламов
#руководителю

“Почему меня не слушают, я же начальник”

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

В чем проблема
Смысл проблемы в том, что у большинства руководителей их жалоба звучит примерно как “он меня не послушал, а ведь я начальник”. Я конечно согласен, что субординация важна, но не всегда слов “я начальник” достаточно, чтобы что-то случилось или начало делаться, как вы хотите. Давайте разберемся по частям с этой проблемой.

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

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

Как лучше делать
Лично я всегда иду от другого и люди, которых я считаю хорошими руководителями, обычно делают также. Я иду либо от ответственности, либо от знания. И обычно, когда я слушаю подобные возмущения от руководителей, которых я считаю хорошими, они звучат примерно как “мне не важно, что он считает. Отвечать мне, поэтому мы сделали, как я сказал”. Сама по себе подача себя через ответственность лично у меня вызывает больше понимания. Я понимаю, что за каждый большой провал сначала ответит мой руководитель, а потом, если считает правильным он сам, вызовет отвечать меня. И он это понимает. Поэтому глобальных проблем с принятием права последнего слова у меня нет. Так же, как если ты признанный у себя в команде эксперт, то можно идти от того, что ты точно знаешь и берешь ответственность на себя. Знание и принятие ответственности тоже имеет вес, но это скорее хорошо работает в среде тех, кто вас давно знает.

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

Максим Шаламов
#руководителю #советы

О чем мы писали в апреле

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

"Почему меня не уважают?" - разбираем вопрос

Зачем я здесь пишу

Не знаешь что делать - пиши план

Моя главная ошибка в карьере

Недоступен - не решаешь

"Почему меня не слушают, я же начальник?" - разбираем вопрос

Оставайтесь с нами, в заготовленных постах уже лежит много интересного! А если хотите пост на свою тему, то задавайте вопросы в нашего бота.

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

Знаю, что многие все равно не удержатся, чтобы что-нибудь не поучить, не почитать, потому что среди работы на это откровенно редко хватает времени. Сами с Максимом по паре книжек уже прикупили, чтобы спокойно почитать в выходные. Поэтому сделала и вам промокод на 25% скидки на все наши обучающие продукты: MAY_2024, а еще в конце поста есть ссылка на один бесплатный.

Что самое полезное можно посмотреть? Я бы выбирала от того, что именно сейчас вас больше всего беспокоит.

Надоело делать однотипные задачи? Посмотрите план по борьбе с рутиной.

Чувствуете, что близки к выгоранию и смене работы? Тогда берите инструкцию, как избавится от выгорания.

Хотите, чтобы ПО вас уважал, прислушивался и менял задачи по вашим советам? Берите документацию по работе с ПО.

Надоело смотреть, как все все делают неправильно и хотите взять управление командой в свои руки? Тогда это решение специально для вас.

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

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

До встречи в середине мая!

Почему важно думать о решении задачи заранее, а не в процессе

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

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

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

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

Александра Шаламова
#советы

Относительная оценка точнее, чем точная. Парадокс? Но правда. Разбираемся, как это работает, в новом видео.

https://youtu.be/U6sH00Tf_ls

История о том, как я опять наступила на грабли с отсутствием плана работ 🤦‍♀