Как экономить время на встречах и успевать работать

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

Познаем дзен.
Откройте свое расписание. Пробегитесь по каждой встрече и ответьте на вопрос:
Я вообще нужен на этой встрече?

Если вы просто слушаете и ничего не решаете, то пора "отпустить".

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

😗"Без меня что-то пойдет не так".
Доверие к коллегам такой же хороший инструмент, как и контроль. Доверие не означает отсутствие контроля.
Попросите писать резюме по встрече. (Вы что их еще не пишите?) Прочесть резюме - 1 минуту, молча не влиять на исход встречи в переговорке или скайп-колле - 60.
Если делегируете встречу - спрашивайте как проходит сам процесс у ведущего, может ему нужно помочь с фасилитацией.

Этот же вопрос задайте себе, когда принимаете приглашения на встречи.
И когда создаете их. Сюрприз.

Ставьте сердечки, если интересно узнать как я "чищу" свое расписание.

#софтскилы

Переезд и поиск работы на карантине

4 истории ИТ специалистов в формате интервью, которые искали работу во время пандемии.

Посмотрим как отразился кризис и режим самоизоляции на поиске работы для Программиста, Менеджера проектов, Аналитика и HR менеджера.

Забегая вперед, это истории не только про потери, но и про новые возможности, которые ребята открыли для себя.

Тыц-тыц на ссылочку, материал пушка.

https://telegra.ph/Pereezd-i-poisk-raboty-na-karantine-04-15

#карьера #интервью

Мои KonigLabs ребятули из Калининграда записывают подкасты.
Основная идея ИТ-кулера - узнать как можно больше о ролевых моделях в IT-сфере, чтобы показать разнообразие и масштаб этой сферы. Так они помогают найти своё место и своих людей в этом водовороте событий.

Мы удаленно записали с ребятами подкаст, где обсудили следующие темы:
- Это заказчик плохой человек или у менеджера не хватает компетенций?
- Сравнили опыт работы в большой компании в Москве и в небольшой в Калининграде.
- Какие скилы нужны менеджерам и разработчикам.
- Обсудили мое выступление про ДОДинг на калининградском WTM.
- Как стать project-менеджером? Какие навыки нужны? Что делать, чтобы научиться? Куда расти дальше? - в формате блица

👉 Apple Podcasts
👉 Breaker
👉 Google Podcasts
👉 Overcast
👉 PocketCasts
👉 RadioPublic
👉 Spotify

Также, у них можно послушать беседу с разработчиками - почему программистов считают элитой, интервью с продакт оунером, подкаст с олдскульным программистом, который погрузит вас в тему «как это было в 90-х» и совсем скоро выйдет выпуск с Ксенией Щербиной - CEO компании Let’s Rock.
Заглядывайте к ребятам на огонек.

​​На днях у меня была беседа с командой по поводу дат релиза.
У нас было несколько напряженных спринтов подряд, дважды сдвигались сроки инициативы - демотивация, разруха, слезы, пот и кровь.

На ретро были озвучены пункты:
🤔 ETA спускается сверху, нас никто не спрашивает;
🤔 Мы перерабатываем, либо постоянно в напряге;
🤔 Гонимся за статистикой, но не качеством.

Поэтому я решила провести с ребятами разговор на тему ETA - это конец света или нет. Хочу поделиться с вами этой информацией тоже.

Почитать сюда.

Ссылка на презентацию.

Если вы не знаете куда деть время, то можно даже посмотреть. Это на 40 минут дольше, чем почитать.

#разработка

Чеклист менеджера при планировании проекта

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

✔️ Отпуска.
Не спросить про отпуска команды это моветон, нужно уточнять любое отсутствие. Даже если Вася 4 месяца назад сказал, что точно пойдет в отпуск в июне - уточнить. Карантин и никто никуда не едет - всех все равно по 10 раз спросить.

✔️ Праздники.
Тут, как и с отпусками. Частая ошибка всех, кто планирует - забывать про производственный календарь. В итоге, кто-то в команде радуется, что "О, 3 дня выходных", а кто-то (тимлид) потом работает в этот выходной, потому что на него надавили/попросили/он сам так решил - не подводить же команду и ожидания заказчика.

Лайфхак: если вы планируетесь на коленке или в excel, то попробуйте инструмент для планирования с визуализацией в диаграмме Гантта. Во-первых, всем нужна визуализация, особенно бизнесу. Во-вторых, чаще всего там можно настроить календарь отсутствий и график работы. Мы пользуемся плагином BigPicture для Jira.

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

Лайфхак: договоритесь с заказчиком об определенной квоте времени команды на эти работы. Например, 6 часов в неделю на поддержку или мелкие хотелки заказчика в продукте. У нас это называется малым портфелем, такие задачи мы оцениваем и груммим за спринт.

✔️ Приемка заказчиком учтена.
Вы разложили ресурсы в диаграмме Гантта и готовы уже называть даты релиза? Ответьте себе на вопрос, учтена ли приемка заказчиком. Если вы еще не договорились, как проходит приемка фичей, то бросаем все и бегом к заказчику - договариваться. Имейте ввиду, что не все фичи принимаются одинаково. У нас бывает так, что какую-то фичу помимо продакта должна посмотреть редакция, так как она выступает для этой фичи конечным заказчиком.

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

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

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

Ставьте сердечки, если какие-то практики для вас были новыми и вы хотите попробовать их, и смайлик "умника", если вы уже все знаете и практикуете.

#разработка

Нужно оставаться человеком

▪️Все ок, едем дальше
▪️ Жалко или грустно
▪️ Обида или злость
▪️ Апатия

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

На прошлой неделе у меня в команде мечты произошли большие перестановки.
Неделю назад у меня было 2 команды, 3 продукта в разработке и 2 на поддержке.
Сегодня у меня 3 команды, 3 продукта в разработке и 4 на поддержке.
3 команды получились не в результате 2к + 1к, а как 2к - 1к + 2к.

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

Если вы переживаете подобный экспириенс или знаете, что он вас еще ждет - не забывайте быть человечным. Будьте добрее к коллегам, внимательнее, оказывайте заботу и поддержку.

Тому, кто отстранился - не всегда пофиг. Тот, кто не пишет, может обрадоваться вашему "привет, как оно?". Тот, кто бурчит на вас, может тяжело принимать изменения.
Понимаете? Сделайте что-то поддерживающие для своей команды и прямо сейчас. Мы же тут за людей.🤞

4 варианта планирования разработчика на неделю

40 часов в неделю

Ни разу не видела, чтобы хорошо работало, но еще не перевелись менеджеры и компании(!), которые так планируют. Потом, правда, мы видим следующее:
а) задачи переезжают, едут сроки,
б) задачи выполняются с переработками, через месяц человек уже воет.

Если вам нужна полная отчетность за все 40 часов, то никто не запрещает добавить задачи на мероприятия команды и встречи. Вы можете планировать качественное время разработчика на 30 часов, а остальное закладывать на процессы/болталки, при этом показывая это в отчетности.

Неправильные мотиваторы:
⛔️ "У нас же один разработчик на проекте, нам больше не надо".
⛔️ "Все задачи тимлид декомпозировал и оценил, бери и делай, думать не надо".
⛔️ "А стендап с заказчиком, ты в задачу спиши".
⛔️ "Он же сеньер, сделает все уже к среде".

35 часов в неделю

Вариант очень близкий к 40, сдобренный иллюзией, что 5-ти часов хватит на всю коммуникацию и выяснение деталей.
Даже в маленькой команде (до 4х человек), 5 часов в неделю может не хватать. Из-за отсутствия взаимопонимания, команда начинает делать НЕ ТО или НЕ ТАК. Один сказал одно, другой понял иначе, третий не переспросил. Урежем общение до 5 часов в неделю - рискуем сделать не то, что нужно заказчику.

Неправильные мотиваторы:
⛔️ "5 часов в неделю на скрам мероприятия в команде за глаза".
⛔️ "У нас аналитик хорошо описывает задачи, все понятно".
⛔️ "А заказчик все равно с командой не общается".
⛔️ "Разработчики разные модули пилят".

25-30 часов в неделю

Чаще всего - это самый оптимальный способ планирования, а еще комфортный для разработчика. Золотая середина у каждого своя и может варьироваться как от длины спринта, так и от активностей, которые предусматривает спринт (поддержка, мелкие задачи).
Мы сейчас планируемся в этом диапазоне, при этом команды логируют время полностью (40 часов/неделя).

Неправильные мотиваторы:
⛔️ "Пока Петя въезжает в проект, не будем на него 40 часов планировать, давайте 30?"

20 часов в неделю и менее

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

Но чаще всего 20 часов в неделю тоже не здоровая ситуация. Причин может быть много: неправильная оценка разработчиков, старший разработчик оценивает за джуна и это адаптируют в спринте, плотные задачи на part-time разработчиках. Надо искать проблему и выводить команду на эффективное планирование.

Неправильные мотиваторы:
⛔️ "Тимлид должен 50% кодить"
⛔️ "На джуна больше и не запланируешь"
⛔️ "Наша скорость команды 20 story point'ов в неделю на человека"
⛔️ "50% времени уходит на мифический рефакторинг, время списываем в унитаз".

#разработка

​​Как лечить планирование спринта длинною в жизнь

Собирается в п̶е̶р̶е̶г̶о̶в̶о̶р̶к̶е̶ скайп-коле 14 человек: 7 разработчиков, 2 тестера, 1 тимлид, 1 менеджер, 1 продакт и 2 стакхолдера.

14 человеко-часов тратится на то, чтобы запланировать недельный спринт. Половина участников засыпает на 20-ой минуте, потому что речь идет о задачах, которые не относятся к ним. Но и на этом не заканчивается история. После планирования тимлид еще с разработчиком дооценивает "а возьмите тикет №12345 еще, очень горит, сутра появился".

Знакомо?
Давайте сократим это время до 15 минут?

Планирование спринта — это не работа для 14-ти человек. 80% работы делает менеджер или тимлид при подготовке спринта к планированию, чтобы время команды не тратилось впустую.

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

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

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

#разработка

Вам решать каким менеджером быть

Когда к вам переходит новый проект другого менеджера, к вам переходят еще и его обещания. Естественно, вы о них ничего не знаете. Обязательства сваливаются на вас, как гром среди ясного неба, когда товарищ Н. наконец-то найдет вас и скажет: "Но обещали же сделать это после майских праздников!"

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

Но человек не виноват, что договоренности не передали, ему важно решить его проблему. Сравните 2 варианта реакции.

"Я только 2 недели тут работаю, когда пришел на проект мне ничего о вас не сказали. Извините, но сейчас ничего не сделаю уже, напишите мне через 2 месяца, сейчас команда занята другим."

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

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

#софтскилы

​​Ретроспектива, на которой всё у всех хорошо, улучшать не надо

Скорее всего, если на ретроспективе всё хорошо - это вы и ваша команда на картинке к посту. А если так происходит не в первый раз, то ну 100% - вы.

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

Четыре идеи, которые вы можете попробовать уже в эту пятницу, без особых усилий:

🍕 Попробуйте поменять формат.
Если что-то старое идет на новый манер, то в этом интересно поучаствовать. Не нужно тратить много усилий на выбор формата в гугле - возьмите первый, который понравился и экспериментируйте.
🍕 Пригласите нового участника, чтобы получить свежий взгляд на происходящее.
Например, кого-то из заказчиков или техподдержки.
🍕 Поменяйте ведущего.
Смена ведущего - это как смена формата. Свежая кровь - новые впечатления.
🍕 Задавайте не привычное "Что могло быть лучше", а более индивидуальные вопросы.
Если вы знаете, что Петю в начале спринта бомбило от задачи №3241 - помогите ему ответить на вопрос "что могло быть лучше" постепенно уточняя его до контекста этой задачи.

Ставьте сердечко, если у вас тоже были ретроспективы, на которых все "хорошо".

#разработка

​​Вредные вопросы бизнес-заказчиков

"Это что так сложно сделать?" / "Это же легко?"

Сейчас подобный вопрос скорее вызовет у меня улыбку, хотя раньше меня могло тригерить.
Конечно, проджект ответит что-то вроде: "Мы оценим и дадим вам знать". Особо уставший проджект скажет с сарказмом "2 недели", хотя задача на 1 час.

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

Забавно, но среди разработчиков тоже встречается такая болезнь, на днях в комментах к задаче товарищ написал:
"Пункт А будем делать долго и муторно, а вот пункт Б - легко."
Я попросила расшифровать в часах, но шуткующих разработчиков было уже не остановить. В чатике появилась картинка из интернетов. Заглядывайте в нее и вы. По моим ощущениям "легко" = "хз".

#заказчик

Из проджекта в продакты

На канале у Менеджера от боженьки вышел интересный материал про продактов, которые когда-то были проджектами в формате интервью.

Получилось интересно и годно. Делюсь ссылкой на Medium:
https://bit.ly/2XDQhTR

​​Мышление, которое мотивирует

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

Некоторые товарищи по цеху, переходят в продакты по этой причине. Там бум-бум, аналитика, А/Б тесты, гипотезы, кастдев, ROI считаем и сразу результат работы видно.

В такие моменты, как в Гарри Поттере и Узнике Азкабана, нужно искать в себе свет.

👍 Вот тут процесс не сломался и команда довольна.
👍 Тут фичу выпустили в сроки.
👍 Заказчик в курсе и понимает, зачем нужен тех. анализ новой фичи.
👍 Пользователи стали положительно отзываться.

Результат работы проджекта - это не то, что ты план нарисовал. Тех, кто просто планы рисует, долго не держат.

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

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

#кризис

Когда лучше не говорить "Мы не готовы сейчас ответить, давайте потом"

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

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

Вот что можно сделать, если вы почуяли конфликт:
👉 прямо сейчас и здесь залезть в детали и дать ответ.
Например, у вас нет на руках инфы сколько времени еще нужно на завершение фичи N. Но у вас есть возможность зайти в эпик и посчитать остатки у всех на виду. Это может казаться долгим действием или даже не относящимся к повестке, но чтобы не обострять конфликт, эти 5 минут стоят своего.
👉 прямо сейчас и здесь позвонить человеку, который может дать ответ.
Не отвечает в условном скайпе - достаем телефон. Мастхев фича проджекта - уметь достать из-под земли кого угодно и когда угодно.

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

#заказчик

Как QA искал работу

В апреле у меня вышел материал о том, как ребята ищут работу в разгар пандемии.

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

Знакомьтесь - Антон, менял работу в Москве. Устроился в Mail

Кто ты по профессии?

QA инженер.

Почему начал искать работу на карантине?

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

Сколько времени занял поиск работы?

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

Сколько офферов получил?

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

Предлагали меньше денег из-за кризиса?

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

Почему решил остановиться на первом оффере? Не было желания еще поискать?

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

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

Какие особенности найма по удаленке ты можешь выделить?

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

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

#карьера #интервью