IraRum | записки РПешника

Указание срока получения ответа в письме Когда я только начинала работать, я думала над каждым исходящим письмом. И указывать срок получения ответа в письме мне было очень неловко. Я стеснялась указывать в письме сроки, в которые требуется предоставить ответ. Мне казалось, что это грубо. Что я как будто указываю получателю письма, когда нужно поработать. Да и вообще, кто я такая получателю письма, чтобы назначать ему сроки! Со временем я изменила свое отношение. Правда не кардинально. У меня все еще при указании сроков в письме мелькает на секундочку чувство дискомфорта. Тем не менее: ➖указание срока позволяет спланировать (не указывать, а именно спланировать) работу ➖указание срока (ну только в случае, если срок адекватный) дает понимание о срочности задачи ➖формулировкой а-ля “Просьба дать ответ до ХХ, либо сообщить срок”, как будто смягчается просьба ➖когда подошел срок, а ответ не получен, нужно самому напомнить (иначе очень блекло выглядит указание сроков) Таким образом, указание срока получения ответа в письме - норм. Причем независимо от того, кто автор письма и кто получатель.

Кичиться нехваткой времени Мне кажется, что нам свойственно жаловаться на нехватку времени, чтобы выполнить рабочие задачи. И не просто жаловаться, а даже в какой-то мере кичиться этим. То ли чтобы пожалели, то ли чтобы придать важности себе, то ли другой мотив. И я сейчас не про ситуации в проекте, когда действительно нужно концентрированно много поработать. Например, случилась какая-то авария на проде и ее нужно починить. И да, приходится сидеть полночи, чтобы починить. Я сейчас про жалобы на хроническую нехватку времени. Когда это уже превратилось в рутину. В такое вот ежедневное нытье, что работать приходится больше 8ми часов. Однако, мне кажется, что это самообман. И невозможно постоянно работать на протяжении 8 часов, что уж говорить про большее время. Мозг как будто найдет варианты себя защитить, а не фигачить все это время. Отсюда появляются длительные и частые перерывы на кофе или, сидя за компом, отвлечения на посторонние дела, или что-то другое, что дает разгрузку мозгу. Если такое заметили за собой, то не стоит продолжать, а нужно задуматься. Задуматься о том, что можно поменять в работе, чтобы это искоренить. И я себе в такие моменты повторяю фразу: "работать нужно не 12 часов, а головой".

Конференции Когда я смотрела всякие разные доклады с конференций, частенько меня посещали мысли, что содержание докладов либо капитанство, либо сильно упрощенные идеи. И из-за этого мне было сложно перенести информацию из докладов на реальную рабочую ситуацию. Ведь в жизни все сложнее, да и, как известно, дьявол всегда кроется в мелочах. Затем я попробовала сама выступать. И просто офигела от того, как это сложно! ➖во-первых, нужно подготовить содержание. Нужно выразить мысль, оформить ее в слайды, текст. И да, приходится упрощать :) Невозможно уместить все детали в один доклад, а мысль донести очень хочется ➖во-вторых, нужно поработать над подачей. Если будешь скучно рассказывать, то какие бы умные мысли не были, слушать никто не будет. А тут же еще прибавляется мой страх публичных выступлений Поэтому сейчас я более лояльно слушаю доклады. Я пытаюсь вникнуть в суть, домыслив из своего опыта нюансы, да и просто перенять опыт. Наверняка что-то может быть полезное для меня. Сейчас грядет конференция https://inbetween.ru/. Мне, как всегда, больше всего интересны темы про команду и лидерство. Перегруппировка команды, как быть не спасателем, а точкой опоры для команды - такие темы звучат как темы проверенные опытом. Очень жду, что будет выжимка из реальных кейсов!

не Слушать встречки Когда на встрече коллега выступает с темой, которая косвенно относится к твоей, то зачастую ты его не слушаешь. Мне кажется, что причины могут быть следующие: 🌀у тебя слишком много встреч. Устаешь от беготни от созвона к созвону. И так мозг пытается разгрузиться 🌀у тебя много своих задач. Ну ничего же не мешает свернуть окно созвона и продолжать работу, но два дела делать одновременно нереально (как бы не казалось, что получается) 🌀тебе лень вникать. Тупо лень вникать в смежные (или вообще не смежные) задачки. Рассуждения а-ля это не моя зона ответственности, если понадобится, то спрошу лично У меня в разные периоды времени срабатывают все эти причины. Но чаще всего работает вторая. У меня есть иллюзия, что то, что мне нужно, как-то само собой услышится. Даже если в это время я делаю свою задачку. А ведь бывает очень полезно послушать и вникнуть в то, что говорят коллеги! Пусть это даже практически не относится к твоей задаче. Проект это сложная, с кучей нюансов и особенностей, субстанция. И там, где кажется нет ну вообще никакой взаимосвязи, порой может сильно отрикошетить в тебя. Более того, мне кажется, что сила в информации. И чем больше ты владеешь информацией, чем шире кругозор на происходящее, тем ты сильнее как спец.

Решение вопросов на созвонах Голосом проговорить вопрос, получить ответ, а еще и сразу обсудить ответ, а еще задать уточняющие вопросы... Кажется достаточно продуктивный способ решения вопроса/задачи/проблемы. Я думаю, что так и есть на самом деле. Но бывает, что этим способом слишком часто пользуются. Мне кажется, что злоупотребление происходит чаще всего из-за непонимания самого вопроса. Голосом то проще промычать какой-нибудь невнятный вопрос, чем оформить его же в текст. И получается вот это бесконечное: давайте созвонимся и обсудим. Созваниваешься, а тебе вместо вопроса - поток сознания. И если такое происходит часто, это очень сильно раздражает. А когда пытаешься оформить вопрос в текст, то так будто больше задумываешься. У меня бывает, что пока я составляю письмо, сама уже поняла и нашла ответ🙂 В следующий раз, когда захочется предложить созвониться и обсудить, подумайте, может быть продуктивнее будет способ через текст.

Мямльство Задал вопрос, а в ответ тишина. И тут же спрашивающий начинает пояснять свой вопрос: другими словами повторять, выдавать какую-то дополнительную информацию... Чаще всего это звучит как какое-то оправдание за свой вопрос. Я это называю мямльство. Если это обычный рабочий вопрос, то еще хоть как-то нормально выглядит. Хотя тоже очень чувствуется, что это не продолжение вопроса, а именно заполнение паузы. А вот если вопрос более-менее неудобный (про сроки, про финансы и тому подобное), то такое заполнение паузы очень уж слабо выглядит. И как будто спрашивающий сам же начинает смягчать свой вопрос. Как-то давно мне на такое мое мямльство указал мой коллега. Ситуация была такая. Я была в роли РП и объясняла затраченное время Заказчику. Ну и задала вопрос Заказчику, согласен ли он с трудозатратами. В следующую же секунду ответа не последовало, и я тут же начала мямлить, по сути приводить доводы, что трудозатраты справедливы. После встречи коллега указал мне, что таким образом я себя ставлю сразу в слабую позицию. Я задумалась... и правда. Тогда я очень прониклась этой мыслью и начала работать, чтобы искоренить такое пустое заполнение паузы. Иногда бывает, что я за собой такое замечаю. Чаще всего это происходит в стрессовых переговорах. Однако, стараюсь следить и не делать так. Я приучаю себя к следующему: 🌀выдерживаю паузу, 20 секунд можно и помолчать, ничего страшного 🌀если ответа так и нет, то обращаюсь по имени к тому, от кого жду ответа 🌀уточняю, понятен ли вопрос 🌀и только если просят дополнить/переформулировать - привожу дополнительную информацию Так это не выглядит как мямльство. А выглядит как уверенные переговоры.

Советы советовать Если вы услышите какую-нибудь проблему, поверхностно узнаете детали, то, как мне кажется, будет очень просто дать совет. Или даже не совет, а сделать вполне себе четкое заявление: делать нужно вот так вот и это решит проблему. Я это называю советы советовать. Например, такое частенько происходит, когда подключается новый участник к проекту. Видит какую-нибудь штучку и сразу, не углубляясь, такой: а зачем так делать? можно же делать вот так и так, и будет все круто. И иногда, иногда действительно он бывает прав. И можно делать по-другому и будет реально круто! Потому что замыливается глаз и легкое, простое решение не видится. И такой вот свежий взгляд со стороны помогает. Но, из моей практики, то, что совет действительно полезный, бывает крайне редко! А чаще всего поведение «советы советовать» не дает никакого результата. А только раздражает. А если это происходит постоянно - то уже и нормальненько так бесит. При этом человек, посоветовавший совет, скорее всего считает себя полезным. Ну вот, разрулил же проблему, вернее сказал, что нужно делать, чтобы разрулить. А мне все-таки кажется, что сила не в умении советы советовать, а в умении пользоваться самому этим советом и воплотить его в жизнь.

Обучение Когда я работала в 1Сных франчах, надо было получать много сертификатов. Потому что, чаще всего, это было условием повышения ЗП. Было все достаточно прозрачно. Какой областью ты занимаешься, по той и получай сертификаты. При этом процесс подготовки к экзамену (а получение сертификата происходит через сдачу экзамена) понятный: есть курсы, есть материалы для подготовки. Процесс подготовки достаточно прозрачный, а вот от тебя нужно много времени и желания. А с тех пор, как я стала менеджером, такой вот четкой карты обучения у меня нет. Может быть и не надо? Конечно, есть варианты, где поучиться, какой сертификат получать. Но тема достаточно обширная, и лично мне сложно выбрать что-то действительно интересное, а главное полезное. Встречающиеся курсы про управление очень часто из разряда: делай хорошо, а плохо не делай. Или совсем для новичков. Сейчас мое умение складывается из: 🌀 докладов на конференциях 🌀 статей на хабре 🌀 канальчиков в телеге 🌀 книг (причем что-то около психологическое) 🌀 и самое главное: набивания шишек и саморефлексии А вообще я нахожусь в поиске какого-нибудь очень увлекательного обучения.

Онбординг Как-то на одном проекте у меня случилось ужасное лето: тогда мой проект лишился половины команды. А так как проект, конечно же, продолжал жить, то каждому искали замену, а следом подключали новых людей к проекту. Было сложновато. Проект не был готов к смене большого количества участников. Приходилось дофига времени тратить, чтобы ввести каждого в курс дела. Мною выводы из этой ситуации были сделаны: теперь я отдельное внимание уделяю онбордингу. И мне кажется, что я вывела достаточно удобный способ онбординга. Если садиться составлять документ только для новичков, то как будто бы это не очень полезная задача. Жизнь проекта идет прямо сейчас, есть куча оперативных вопросов, которые надо решать. И тратить время на составление такого документа (мне во всяком случае) было как-то жалко. Причем это же не просто составить документ, это его еще постоянно обновлять надо... А вот если составлять документ не только для новеньких, но и чтобы его можно было использовать в ходе проекта, то это уже кажется полезной задачей. Именно так я и поступаю, причем уже не первый проект! Вот что из моего опыта должно быть в этом документе: 🌀указать, как расшифровывается проект. Частенько для названия проекта используется аббревиатура или другие сокращения. Попробуйте спросить у команды, все ли знают, как расшифровывается аббревиатура :) Думаю, что результаты вас удивят 🌀состав команды. Каждому указываю его основную роль на проекте, % загрузки, время работы, контакты. 🌀принципы команды. На старте проекта я использую принципы работы, которые мне важны. Например: затупить нестрашно, страшно не исправиться. А потом уже в ходе проекта вырабатываем специфичные для нас принципы и я обновляю этот раздел. 🌀договоренности в команде. Сюда выделяю то, что принимается командой за правило. Когда на встрече вы слышите “давайте договоримся, что поступаем вот так…”, значит самое время добавлять новую договоренность в этот раздел🙂 🌀регулярные встречи. Тут перечисляю и указываю время всяких дейликов, ретро, планирования и прочих регулярных встреч. 🌀инфа про проект. Это самый большой раздел. Первая часть - это общая инфа. Это то, что бы я сказала про проект, если бы рассказывала коллеге с другого проекта. Вторая часть - это подробности проекта. Это то, что бы я голосом рассказывала про проект новому участнику проекта. Третья часть - это уже всякие важные нюансы. Всякие необычности, важности и проч про проект. 🌀 правила работы с документами, учетными системами и тому подобное. Тут и ссылки на важные документы проекта могут быть. А также правила работы/заполнения ключевых артефактов проекта. Прочая полезная инфа. Часто бывает, что себе в блокнотик записываешь что-то, как нужно делать (чтобы не забыть). И если ты сам к этому обращаешься не первый раз - то это достойно быть в этом разделе. И если на встречках слышится несколько раз одно и то же, а особенно если “блин, я забыл как это делал…”, то точно пора обновлять раздел с полезной инфой. Что важно при работе с этим доком: 🌀 не забивать, а постоянно обновлять. Это не занимает так много времени, как может показаться. Внести изменения и бросить сообщение об этом в проектный чатик чаще всего недолго. Проверено. 🌀 приучать команду пользоваться документом в повседневной рабочей жизни. Прям внедрять привычку обращения к этому документу: Возник вопрос, что-то забыл - ну так посмотри в документе! Непонятно в документе? Давай обновлю, допишу, чтобы было понятно. И когда подключается новый человек, я даю почитать этот документ. Чтение никак не отменяет личного общения с новым участником. Но этот документ структурирует инфу для новичка и до личного общения, и после. Мне кажется, что это очень удобный способ онбординга новых людей и крутой инструмент для повседневной работы команды.

Определение ролей в команде Для выполнения проекта в команде должны быть все необходимые роли. Капитанство, но так оно и есть. Причем один участник команды может совмещать в себе несколько ролей. Бывает, конечно, когда участник команды совмещает или выполняет ненужную роль… Но сейчас не об этом. Хочется поговорить про определение проектных ролей в команде. 1 - Роли сами выстраиваются У меня были проекты, где не нужно было четко фиксировать кто что делает. Роли в команде сами распределялись со временем, причем необязательно роль полностью соответствовала должности. 2 - Роли четко фиксируются У меня были проекты, когда приходилось четко фиксировать кто-что делает. Что именно ожидается от каждой позиции. Чаще всего со ссылкой на функции, которые зафиксированы в отделах. Оба варианта, мне кажется, имеют право на существование. И тут нет единого правильного варианта. Наверное, какой подход применить, больше зависит от РПешника, ведь так или иначе он подбирает себе в команду людей. Мне ближе и у меня чаще работает вариант 1. Люблю, когда органично все получается. А вот когда в команде возникают вопросы а-ля: “почему я должен это делать”, “я не понимаю, чем кто-то занимается” ,то это прям сильные звоночки к тому, что не происходит определение ролей само по себе. И тогда уже нужно принудительно определять и фиксировать роль каждого участника проекта.

Постоянно откладываемая задачка У меня была задачка, которую я постоянно откладывала. Я ее завела себе в yougile, поставила срок. Но очень не хотелось ее делать. Задачка несложная, просто надо было сделать то, что я не люблю делать :) Ну и так я постоянно передвигала срок вправо по этой задачке. При планировании очередного спринта я решила добавить ее себе в список задач на спринт. На протяжении спринта я вспоминала о ней, но всё никак не приступала. И вот в последние дни спринта я выделила себе время, собралась и сделала её! Потому что: ➡не хотелось тащить ее в следующий спринт ➡хотелось получить завершенный спринт, тем более я могла это сделать Наверное, это не очень взрослая позиция, когда не хватает самоорганизованности сделать задачку, а нужен такой вот пинок “извне”. Однако, у меня это сработало. Включая задачку в Спринт, как будто бы происходит принятие неизбежного - тебе нужно сделать эту задачу и нужно сделать именно в этот срок. Для меня это сработало и я буду этим пользоваться. PS. А вот если бы я не сделала ее в спринт, то перенос ее в следующий спринт мне бы уже не помог. Мне кажется, я бы морозилась от этой задачи, пока не забила бы на ее выполнение!

скрин результатов нашего рето

Ретроспективы Я ни разу не работала на проекте с настоящим Agile. Каждый раз - это адаптация принципов Agile-а под проект. И мой текущий проект не исключение. Мы сейчас с командой выстраиваем такой Agile, который подходит под наш проект. Ну и куда ж без ретро, решено проводить ретроспективы! Правда, пока что мы провели только один раз. Но оно, как мне кажется, получилось результативным, потому что: 🟢у нас небольшая команда, 4е человека со мной. Поэтому ретро не превратилось в нудную встречу 🟢мы вместе работаем практически больше полугода. Поэтому не тратили время на всякие “притирки”, а сразу сплоченно общались 🟢у нас в команде, ну как мне кажется, достаточно высокий уровень доверия. Поэтому говорили честно и про околопроектные проблемы тоже затронули План ретро получился достаточно стандартный: 🟣10 минут, чтобы заполнить стикеры 🟣выступление каждого с пояснением стикеров 🟣а вот голосование не устраивали. Я на правах лида выделила интересные стикеры, мы их проговорили и взяли в работу на этот спринт Может быть в правильном Agile должно быть по-другому. И ретроспективы более эффективные... Может быть я когда-нибудь попаду в настоящий Agile и узнаю это :) А пока что у меня такие мысли по поводу ретроспективы: 🌀я достаточно скептически отношусь ко всяким этим хипстерским игрищам. Но пользуюсь ими :) Но отношусь к этому, как к быстрому варианту объяснить правила встречи 🌀ретро на 10+ человек (а я такие как-то проводила) полная фигня 🌀если человек не хочет писать никакой стикер, то не надо его заставлять. Я слышала, как всякие коучи начинают “разговаривать” специалиста, типа ты должен что-то написать. И начинается серия общих, наводящих вопросов. В результате человек просто выдавливает из себя какое-то капитанство. Не понимаю смысла такого стикера 🌀конечно же, как я уже писала раньше, нужно обязательно отрабатывать по задачам, которые выделили в результате ретро 🌀наверное уже лишнее, но в очередной раз скажу, что результат обсуждения должен быть общедоступным для команды. Т.е. должен быть выложен в командное пространство Мне очень хочется, чтобы эти встречи были не потому что “надо”, или чтобы был повод не работать в это время. Мне хочется, чтобы это был рабочий инструмент общения.

Плохо работающий опытный чувак Я не люблю, когда опытные чуваки плохо работают. Это в большинстве случаев относится к управленческим позициям - лиды, менеджеры. Сложно определить четкие критерии этой “плохой” работы, часто это ощущается на интуитивном уровне. Однако, мне кажется, что можно выделить следующие пункты: 🚩постоянные рассказы о своем предыдущем опыте. И причем о каком-нибудь очень крутом, эпичном опыте. При этом - только общий рассказ. При мало-мальской попытке получить конкретику - сразу сыплется 🚩придание важности своим техническим проблемам. Например, не работал микрофон и об этом обязательно нужно заявить на встрече. Перезагружался компьютер - конечно же, об этом тоже нельзя не упомянуть. Как будто бы в оправдание безрезультатно потраченному рабочему времени 🚩капитанство. Вот эти вот советы из разряда делай хорошо, а плохо не делай. Использование общих фраз, неприменимых к текущей ситуации, к текущему проекту 🚩постоянное откладывание дел. Каждый раз общение строится в будущем времени. Хочется сказать: чувак, ну пора уже делать, а не рассуждать Если все это в одном человечке, то это трындец. Чаще всего в человеке проявляются несколько пунктов и с разным уровнем выраженности. Для меня эти пункты - ред флаги. Я стараюсь максимально дистанцироваться от работы с такими людьми. Однако, конечно же, не всегда получается и приходится взаимодействовать. И тут я для себя выработала следующую стратегию работы: 🟢не вестись на его задачи. Например, если такой человек приходит ко мне с какой-то срочной задачей, тем более вне рабочего времени, я не бросаюсь делать 🟢формализация. Договоренности фиксирую в письме, ну а куда ж без этого 🟢намеренно использую технические подробности. Скорее всего такой человек несильно погружен в предметку, поэтому я могу накидать всяких технических штучек, которые ему нечем будет парировать. Наверное, это не очень красивый прием, но так я могу достаточно быстро отвязаться от человечка Иногда бывает даже обидно, сравниваю свою и его работу. Ну типа он же тоже зарплату получает, а иногда еще больше, чем ты сам. Но это уже не про рабочее, а про эмоциональное состояние. Мне тут помогает только принятие ситуации и направление внимания внутрь себя.

Итоги года Я люблю подводить итоги года для команды. Новый год для этого отличный повод. В воздухе витает праздничное настроение, впереди выходные и как будто бы итоги сами напрашиваются, чтобы их подвели! Я работаю на достаточно крупном проекте, весь наш проект поделен на блоки, я веду один из блоков. Так вот у нас не было итогов по всему проекту, да и мне кажется, что лиды других блоков не подводили итогов, хотя рада буду ошибаться. А я же решила подготовиться и подвести итоги года для команды. Я готовлю презентацию и стараюсь, чтобы вся команда собралась лично в офисе. Но в наше время это далеко не всегда получается, поэтому часто это переговорка + видеосвязь. В этом году у меня небольшая команда, и я подгадала так, чтобы все оказались в офисе. Это, конечно, идеальный вариант. В презентации я отражаю следующие моменты: 🌀 достижения этого года. В этом году у меня команда небольшая, поэтому я выделила индивидуальные достижения. Кстати, свои тоже 🌀 объем проделанной работы. А именно - сколько сделали по плану проекта 🌀 статистику по работе. Причем что-нибудь прикольное, например: количество задач, сделанных каждым; количество часов, списанных на проект 🌀 облако слов. Эту идею мне подсказала коллега. Выгружаю чат за год, загоняю в генератор облака слов и получаю картинку - самые используемые слова. На этом обычно команда залипает 🌀 планируемые изменения в команде. Ну если они есть 🌀 крупными вехами о том, что нас ждет по плану проекта. Прям очень крупными мазками что ждет 🌀 ну и, конечно же, благодарность за работу! После встречи сохраняю презентацию в пдф-ку и выкладываю в общую папку, чтобы у всей команды был доступ. Меня немного расстраивает, что как будто бы не всем участникам интересно. Чувствую, что у некоторых ребят происходит абстрагирование. Воспринимается это как обычная рабочая встреча. А ведь эта встреча делается для команды и хочется больше участия. В этом году я осваиваю figma, презентацию делала в ней. И мне показалось, что у команды интерес был больше к этому инструменту. Даже, наверное, больше вопросов было именно по figma, а не по самой презентации. На следующий год планирую обновить формат: в подготовку презентации вовлечь команду. Например, чтобы часть презентации ребята сами подготовили. Но продумывать это буду в декабре 2025.

Переключение между задачами Часто ловлю себя на том, что мне сложно сосредоточиться на одной задачке. Сейчас стал популярен СДВГ - может быть это он и есть? Ну вот правда, начинаешь делать задачку и … всё. Понеслось. Моментально приходят письма, бжикают чатики и проч и проч. А если вдруг ничего не приходит и не бжикает, то я обязательно вспоминаю какие-нибудь дела, которые надо сделать, причем не только рабочие, но и домашние. Я поймала себя на том, что слишком уж часто зарываюсь в мелкие дела, а потом сижу и думаю: “блин, а что я делала то?!” Мне кажется, у меня уже вошло в привычку иметь одновременно несколько дел в работе. И когда я спокойно сажусь за одну задачу, срабатывает моя привычка, мне становится дискомфортно и я сама себе пытаюсь создать аврал. Меня все еще выручает мое правило: не переключаться на новую задачу, а фиксировать ее в ToDo лист. ➡️ если пришло письмо - то я стараюсь его не читать. После того, как закончу с задачей, проверю почту. ➡️ если пришло сообщение в чатик - то я стараюсь его не читать. Опять же, почитаю чатик и отвечу, когда выполню задачу. ➡️ а если пришло личное сообщение - то скорее всего прочитаю. Ну или в уведомлении начало сообщения прочту, чтобы понять, стоит отвлекаться или подождет. ➡️ если вспомнила про какое-то дело - то открываю yougile и записываю туда это дело. Но все равно переключаюсь. Даже сейчас пишу этот пост и отвлекаюсь на другие дела… Чтобы мне было еще спокойнее концентрированно работать над одной задачей я ввела себе еще одно правило: разбирать записанный ToDo после завершения работы над задачей. Ну или максимум на следующий день. Дольше стараюсь не откладывать - иначе сложно вспомнить весь контекст, да и дело это со временем может превратиться в задачу-обузу. Пока спасаюсь такими правилами.