Улучшенная версия реестра рисков – RAID

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

Это реестр рисков.

Иногда, кроме рисков хочется записать и другие штуки.

Например, что другая команда нам висит кусок скоупа (зависимость). Или, что субподрядчики задержали поставку фичи уже на 2 недели (проблема). Или, что мы считаем, что требования нового закона “переводятся” в вот такие фичи (допущение).

Для таких “расширений“, есть хороший формат – RAID.

RAID это тоже табличка, куда вносят:

R – risks (риски);
A – assumptions (допущения),
I – issues (проблемы);
D – dependencies (зависимости);

Я использую RAID как журнал того, что случилось на проекте. Например, встречаюсь с новым стейкхолдером и рассказываю ему, что было в “предыдущих сериях”. Особенно помогает на длинном проекте, т.к. вещи забываются.

Еще такая табличка помогает рефлексировать над проблемами – полезно открыть перед ретрой или когда делаешь SWOT-анализ.

Пример заполненного RAID для проекта “next day delivery” 👇

Этим сообщением я закрепляю за собой авторское право на всю информацию, опубликованную в этом канале.

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

Когда до последнего ждешь встречи с дорогими коллегами

Джира + гугл таблицы = бомбические отчеты

Недавно делал трекинг для своей программы.

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

К моему большому удивлению, соединить джиру с таблицами, можно только через API ключ. А его еще поди получи у ИТ секьюрити.

Спасением стал вот этот плагин. Все, что он делает – вытаскивает задачи по JQL фильтру и записывает их в таблицу. Получается ряд колонок из джира-данных: статусы, даты закрытия, assignee.

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

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

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

Держи в голове вопрос

Я постоянно сталкиваюсь с ситуациями, где спросили одно, а человек отвечает на другое.

Например:

⁃ Какие задачи вы закроете, если мы добавим человека вам на проект?

⁃ Понимаешь, этот проект вылетает с первого дня, требования неточные, стейкхолдеры по неделе не отвечают…

⁃ [так а задачи? 🫠]

Еще это очень распространенная ошибка мок-интервью:

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

так а задача?

🫠]

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

Проблема в том, что мы порой забываем, о чем нас вообще спросили.

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

Если понимаю, что ухожу в дебри, то сам себе напоминаю вслух:

- Отвечая на твой вопрос, с дополнительным человеком, мы закроем эпики….

Или:

- Я наверное плохо объяснил, как связаны неточные требования и что дополнительно мы закроем. Давай объясню….

Эпик фейл

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

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

Пишу на русском: “Пашка, красава, что все разрулил! Он обычно хмуро отвечает, а тут даже похвалил“. Вскоре приходит ответ, тоже на русском: "Я не есть хмурый”. От заказчика. 🤦

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

Фейлы бывают у всех и это ОК. Через них хорошо учиться, например, проверять отправителя в письме.

Расскажете про свои?

8 советов по гугл-таблицам

Последние 3 года я провел 30% рабочего времени в гугл таблицах. Насмотрелся на хорошие и плохие примеры, и я хочу дать 8 советов самому себе из прошлого:

1️⃣Перекрась границы ячеек в белый. Получится аккуратненько и даже немного похоже на лендинг!

2️⃣Обрежь неиспользуемые столбцы права и строки внизу. Этим ты дашь пользователю ощущение законченности и спокойствия, т.к. сразу видно весь документ.

3️⃣Если в таблице много вкладок, сделай первую Intro – о чем и для кого этот документ.

4️⃣Преобразовать в таблицу делает апгрейд для твоей таблицы – добавляет фильтры, сортировку, типы данных и наводит красоту. Раньше все это надо было добавлять руками самому, а теперь в один клик.

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

6️⃣Вот этим плагином можно вытащить кучу данных из джиры и построить отчеты на их основе.

7️⃣Получить ссылку на эту ячейку – делает ссылку на конкретные столбцы и строки из таблицы. Супер удобно, когда надо что-то объяснить и привести пример на данных.

8️⃣Храни данные в одной вкладке, а их преобразования и отчеты - в другой. Это облегчает чтение документа, т.к. обычно пользователям нужен результат, а не вычисления.

———

Другие фичи sheets изменили вашу к лучшему? Расскажите об этом в комментариях 👉

Клиент продавливает сроки. Что делать?

Когда заказчик продавливает сроки, есть несколько классических приемов, которые помогут в них вписаться:

▫️упростить требования
▫️распараллелить работу
▫️добавить людей
▫️урезать качество
▫️овертаймы

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

Иногда этого недостаточно, и заказчик просит сделать еще быстрее.

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

Для программиста, как и для повара, давление со стороны хозяина может определять запланированный срок завершения задачи, но не может определять время ее фактического завершения. Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. 
У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.

Взаимоконнекты в Линкедине

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

Менеджера от боженьки читают умные и классные менеджеры. А значит здесь можно расширить свой нетворк полезными контактами.

Сегодня стартуем взаимоконнекты в Линкедине!

Рекламируйте свой профиль и добавляйте в контакты классных менеджеров.

Напишите про себя 3-5 предложениях со ссылкой на свой профиль (разрешены только линкедин-ссылки!). Работает эффективнее с хорошим интро и фоткой.

И добавляйте меня, конечно: https://www.linkedin.com/in/roman-kovalevsky/

Как нормально эскалировать, ч1

Некоторые ситуации без эскалации не решить.

Например, однажды разработчик мне сказал: “Рома, я ухожу через месяц. Мне пофиг на эти дедлайны, не планируй важных задач на меня”. Я пытался найти интересные для него задачи и другие точки мотивации, но безуспешно – пришлось эскалировать ресурсному менеджеру и просить замену.

Есть ощущение, что эскалировал = не справился на своем уровне. Но это не так: у ПМа не всегда есть полномочия, чтобы решить проблему самому, и тогда приходится подключать людей выше.

За 12 лет в проджект-менеджменте, я редко эскалировал, чаще получалось договориться самому. В среднем, прошу помощи пару раз в год, в духе: “помоги убедить менеджера Х сделать У для нашего проекта”.

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

Поэтому используйте эскалацию с осторожностью.

В следующем посте опишу несколько принципов, которыми пользуюсь, когда эскалирую.