Поток

Весёлая приоритизация

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

Прямо сейчас в одной классной компании один классный человек управляет IT-разработкой. Его задача — к концу года прийти без тех.долга, выполнить вовремя все контракты компании и не упустить перспективные заказы на пресейлах.

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

Тема порядка в задачах — офигенная, суперполезная и бездонная, нетленка…

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

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

Как-только получится увидеть саму точку изменения, критерии, по которым надо выбирать работу, нарисуются сами…

Это прям прикольно работает. Ввалиться в скорость производства или в качество продукта — может вообще никак ни на чём не отразиться… А мы на уши поставили всю компанию, изменили систему управления работой, команды в стрессе, кто-то ушел, кто-то в курилке полдня обкуривает свой стресс, потому что теперь у него все иначе, а какого беса не понятно…

Тут на помощь приходит мысль, что команда разработки вообще не решает, чья задача вперед… Они такими решениями закапывают себя в могилу конкуренции за свой же ресурс, и оказываются козлами отпущения. У них есть «ручейки», по которым течёт работа от заказчиков, с которыми работают РМ-ы, им и решать кто первый, так-то…

Перевести стрелы, тоже не решение…

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

Мы запускаем любое событие ради какой-то динамики.

И повторяем это событие ради повторения динамики. И вносим изменение в событие ради изменения динамики.

Я нажимаю кнопку «play» — событие, потому что хочу послушать музыку — динамика.
Я вытягиваю в работу задачу «Написать текст», потому что хочу, чтобы его прочитали и выбрали меня.
Я не вытягиваю в работу задачу «Написать текст», потому что хочу, чтоб меня не выбирали.

Логика простая и понятная, думаю, для всех.

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

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

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