СБ - скоротечный больничный 🤒

Киллер фича корпоративной культуры в IT.
Думаю, в каждой компании такое должно быть: когда есть дополнительные дни, когда можно просто не работать, потому что.

Такая передышка раз в 2-3 месяца может спасти как от выгорания, так и от серьезных проблем со здоровьем 🛟

#опыт

Надо вчера ⌛️

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

Другой вопрос, когда задаче уже больше месяца, а то и года 🫣
Вопрос тот же, угол другой: почему не делаем?

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

Страшно не то, что мы не можем что-то сделать.
Страшно делать то, что не нужно и не сделать то, что нужно 😵

#опыт #увы

Краткая иллюстрация как я подбираю людей ☺️

Организация потока задач 🚰

Не раз моя работа в новой компании начиналась с формирования единого потока задач.

Другими словами, я доставал задачи из личек разработчиков и групповых чатов в трекер задач.

Зачем? Подумаешь, задачи в личку писали: "Быстрее же в группе с разрабами вопрос решить!".

Представим:
У нас есть 2-3 разработчика, пара тестеров.
И 5-6 заказчиков. У каждого заказчика еще 1-2 доверенных лица.

Какое количество коммуникаций произойдет, пока задача едет до прода?
Сколько раз придётся отвлечься от работы, чтобы ответить обеспокоенным зрителям на вопрос "когда?" или, что еще лучше, "а чего так долго?".
Будут ли заказчики мешать друг другу и разработчикам?

А сколько задач будет оформлено в трекере?
Или они, для скорости, будут идти прямым текстом "а вот тут надо сделать хорошо, а то как-то плохо… вы ведь понимаете? Сегодня сделаете?".

К чему это ведет: 🛣
1. Закаливающее кол-во коммуникаций, отвлекающих от работы
2. Бесконечный поток новых задач с низким уровнем проработки и непонятным приоритетом
=> задачи делаются медленно, заказчики чувствуют себя обманутыми, а разработчики - выгорают

Что нужно сделать, чтобы это остановить?
Договориться со всеми участниками рабочего процесса (заказчиками и DevTeam), что задачи теперь буду выполнены только в том случае, если пройдут конкретный и понятный путь.
Какой? Тот, о котором договоритесь или тот, который PjM сочтет оптимальным.

"А не будет тормозить"? ⏹
Если что-то надо срочно починить, то путь будет другим. Только если действительно надо срочно.

После всего этого текста у меня вопрос: какую мысль мне удалось донести?)

#опыт

Сегодня после очередного совещания чувствую себя ворчащим дедом 👴🏻

Я вижу как люди (мои коллеги) хотят выше, быстрее, сильнее... но у этого нет четкой цели 🎯
И я вижу в этом себя 5-7 лет назад.

Что могу сказать теперь, спустя эти ~5+ лет опыта?
У любой деятельности должна быть цель.
Достижение цели должно быть обмазано метриками.
Метрики, чаще всего, связаны с деньгами косвенно или напрямую.

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

Почему лучше так?
Когда двигаешься сверху, от цели, можно притянуть за уши, что у этого есть метрики и в этом есть деньги 💸

#опыт

Когда устал ждать тестирование

Когда решил наверстать упущенное.
Что-то наверсталось, это точно)

Back to Excel 🧮

Выжил после релиза и кое что понял.

Если ситуация сложна - используй самый простой инструмент с максимальной степенью свободы.
В моем случае, для управления потоком задач я решил вернуться к истоку - Excel!
Точнее Google Sheets, тк есть режим редактирования онлайн и совместной работы.

Какую проблему решил этим на данный момент ✅

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

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

Следующий шаг - сделать тоже самое в многострадальном трекере 🛠

#кейс

Так, кажется, я нашел идеальный фреймворк
Не благодарите!

https://govno.works/

Источник правды 🌊

Ситуация: у меня есть 5 истоников правды о том, как должно быть.
Как должна работать система.

1. Макеты. Новый дизайн показывает как должно быть. Но нет переходов между экранами и состояниями.
2. Задача. В общих чертах описаны изменения, есть описание нюансов.
3. Документация. Безнадежно устаревшая, но с нотками актуальности.
4. Владельцы продукта. Знают все, но как должно быть в идеальном мире.
5. Код. Старый добрый код, в котором все уже как-то работает.

Итак, куда смотреть, на что опираться?

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

Что же делать, капитан? 🚢
Думаю, что в первую очередь сделаю истоник правды в задаче.
Полное описание функционала. Дальше, задачи по мере выполнения будут отправляться в документацию.
Без задачи дизанй не смотреть - это уже в сторону DoR, когда надо понять, а можем ли мы вообще такую задачу оценить и взять в работу.
Все знания из заказчиков пишет в задачу и сверяемся с прогоном на проде + начать писать по модели AS IS/ TO BE.
Полный вперд, на встречу 🗻

#кейс

Привет! Я жив.
Постараюсь возобновить вещание на этом канале.
А пока - подкаст к вашему вниманию 🦅💝