​​🐦 Хокку о менеджменте

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

Все они были великими (для своего времени) менеджерами, но исповедовали разные подходы к управлению. Современники описали эти подходы тремя хокку на общую тему «Если птица не поет».

Ода Нобунага: «Если птица не поет, она должна быть убита».

Тоетоми Хидэеси: «Если птица не поет, я заставлю ее запеть».

Токугава Иэясу: «Если птица не поет, я дождусь, когда она запоет».

Обратите внимание, здесь нет: «Если птица не поет, ее нужно лучше кормить».
И уж, тем более, нет варианта «если птица не поет, я спою сам».

​​🚀 О Королеве, Келдыше и жизни на Марсе

Истории про космические проекты всегда интересные и поучительные.

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

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

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

Обычно дальше эту историю рассказывают так: Келдыш предложил провести эксперимент на Земле, чтобы понять, работает прибор или нет. Создали техническое окружение, сходное с тем, что было на аппарате, включили прибор, записали результаты измерений и стало понятно, что, по мнению хитрого девайса, в казахской степи жизни нет. Прибор не годится! Так гениальный Келдыш сэкономил 12 кг массы для космического аппарата.
Дескать, ищите тривиальные решения, включайте здравый смысл и получайте значимый для проекта результат.

Чушь.  

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

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

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

​​😱 Новые горизонты проектного управления

Мир проектного управления сильно изменился, друзья мои.
PMBoK, который был абсолютно бесполезен еще пятнадцать лет назад, можно спокойно использовать по назначению (аккуратнее только, там плотная бумага). 
Регламенты проектной деятельности можно использовать так же, но не забудьте удалить электронные первоисточники - все эти девяносто две версии с правками от процессных аналитиков, комментариями юристов и высерами дружественных подразделений. 
Что, писали эту мутотень, тратили по полгода на согласование тонких нюансов процедур управления изменениями со всеми заинтересованными сторонами, мучились и пыхтели? Ну и дураки. Я тоже тратил, тоже дурак. Ну ладно, ладно, мы просто шли в ногу со временем в соответствии с нашим пониманием о том, что значит "в ногу".) 

Смысл остается только в управлении проектными рисками, но этим в России все равно никто никогда не занимался. Да и само управление сильно меняется - на помойку отправляются все ваши псевдоматематические модели по оценке рисков (это комплимент - у вас их все равно нет). Да какие у вас риски с недельными итерациями выпуска продукта и с релизом MVP через три месяца после старта проекта? Начальство с Мальдив вернуться не успеет, а вы уже все сделали и дальше побежали. 

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

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

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

Хороший канал

Набрел на интересный канал про менеджмент и анализ: @analysis_paradisis. Годных каналов сейчас - Матроскин нарыдал. Этот годный, тем более что ведет его менеджер из Тинькоффа. 

Навскидку: 

https://t.me/analysis_paradisis/21 - о задаче, которую можно давать аналитикам на интервью - про инопланетянина и стул. ) 

https://t.me/analysis_paradisis/52 - про то, как правильно выявлять требования заказчика. Те, кто на темной стороне, смогут даже навязать ему свои требования.) 

https://t.me/analysis_paradisis/109 - про обязательные и необязательные параметры в ТЗ (не бойтесь, написано не скучно). 

https://t.me/analysis_paradisis/247 - про книжки профессиональной тематики, прочитанные автором канала за прошлый год. Список хороший, сам это все тоже читал, хоть и не в прошлом году.) 

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

​​🍟🥢 О процессе и результате

У Джона Кехо в книге "Практический курс счастья" есть такая история:
"Много лет назад, путешествуя по Тибету, я видел, как создаются рисунки из песка. Каждый день на местном рынке монахи, одетые в оранжевые накидки, выкладывали разноцветные песчинки, рисуя сложные формы. Все детали прорабатывались с необычайной тщательностью. Над каждой картиной трудилось не менее шести монахов. Приходя день за днем на рынок, я наблюдал, как картина постепенно приобретает законченный вид. Для ее создания обычно требовалось больше недели. Затем следовала торжественная церемония, а после нее происходило нечто неожиданное. Картину просто стряхивали на землю. Сотни часов, потраченных на создание уникального произведения, уничтожались одним движением руки. Меня это всегда удивляло.
Увиденное шло вразрез с нашим западным менталитетом. Мы привыкли, что целью любого труда является некий результат. Для нас особую важность имеет то, что мы создаем, затрачивая свои усилия, но для буддистов процесс важнее конечного результата. Главной ценностью для них является ежесекундное внимание, которое требуется в ходе создания картины, а не картина как таковая. В этом заключается важный урок для тех, кто стремглав мчится по жизни в погоне за успехом."

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

На самом деле, противопоставление это искусственное. Правильнее было бы объединить слова "процесс" и "результат" одним понятием - "цель". И тогда все становится просто и ясно - цель может быть какой угодно, лишь бы она была. 

Ровно поэтому в проектной деятельности говорят о цели проекта, а не о странной парочке "процесс-результат".

И буддистские монахи это хорошо понимают. Вы, надеюсь, тоже.

​​❌💻❌ Почему не надо брать ноутбук на встречу

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

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

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

В-третьих, не видно рук человека и того, что именно он пишет – а вдруг он все неправильно понял и записал? А ему вообще интересно, о чем я там говорю?  

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

Если же ваша цель – сократить на пять минут время написания протокола после встречи, то, да, конечно, доставайте ноутбук и ковыряйте свои клавиши. У вас какая цель?  

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

Берите бумагу, ручку, отправляйтесь на встречу... и не будьте придурками.

​​🛠 Об определении проекта

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

Ответы вы получите на любой вкус:
"Это такой набор документов".
"Это такой продукт".
"Это схема".
"Это когда какие-то люди что-то делают".
"Это когда есть план и вехи".
"Это... это... ну, вы и сами же это понимаете".
"Как в книжке не скажу... Впрочем... Не, вообще никак не скажу..."
И мой любимый вариант:
"Зачем вы меня спрашиваете? Я вам не теоретик, а практик!"

Был один кандидат, который удачно пошутил, сказав, что проект - это важное понятие в антропологии Сартра. Мы с ним эту тему подробно обсудили. Умный парень, но предлагаемый уровень зарплаты его не устроил. А жаль, умные люди с чувством юмора нам нужны.

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

Готов спорить, что вы точнее не сформулируете. )

Кстати, именно поэтому проектом (= работой) можно управлять. Попробуйте-ка поуправлять набором документов.

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

Еще хороший канал

Автор канала @product_love - продукт-менеджер из издательства МИФ. Пишет про свой менеджерской опыт, полезные книжки, продуктовые инсайты и лайфхаки.)

Что запомнилось:

https://t.me/product_love/70 - про важные мелочи и правильный сервис.

https://t.me/product_love/78 - про то, как помочь команде отказаться от интересных задач в пользу денежных.

https://t.me/product_love/89 - про лайфхаки чтения.

https://t.me/product_love/204 - девять способов не продать свою идею бизнесу.

https://t.me/product_love/211 - зачем нужен сводный бэклог проектов.

Пишет хорошо, рекомендую.

​​📩 📩 О двойных продуктовых стандартах и супераппах

Вот интересно устроен продуктовый мир. Если известный банк вдруг начинает предлагать нам билеты в кино или бронирует столик в ресторане – это для всех ок. Если поисковая система сдает нам машины в аренду, подписывает на просмотр сериала или музыку – это ни у кого не вызывает недоумения. Если почтовый сервис вдруг доставляет нам еду или рекомендует, какую недвижимость купить, – это тоже воспринимается нормально.
Все это обсуждается по всем каналам и называется суперприложением. Лучшие продуктовые менеджеры и их команды день и ночь трудятся, чтобы только сделать еще одного доброго советчика и старательного помощника по расходованию наших честно заработанных. )

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

Откуда двойные стандарты, почему так несправедливо? ))  

​​💡 Умное модное

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

Управляешь ты парой сотен человек - ты директор департамента. Только полсотни в подчиненнии? Тогда ты начальник управления, и не шурши. Ну, понятно, у всех начальников развивалась тяжелая форма Гоголь-синдрома - они соревновались в  коллекционировании душ.

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

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

Просто умное надо сделать модным.

​​🚮 Без капчи

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

Боишься ботов? Анализируй поведение посетителя, применяй интеллектуальные методы выявления роботов. Небось не с Терминатором бьешься. Можно сделать невидимое поле на форме – робот его заполнит, а человек нет. Профи знают еще миллион остроумных способов не погружать человека в капчевое болото.  

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

И эти люди потом еще смеют говорить что-то о UX.

​​🍩 Любимчики

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

Кстати, это понятно еще со школьной скамьи. Хорошие учителя никого явно не выделяют. 

Давайте будем хорошими менеджерами. Хотя бы в этом.) 

​​➡️ 🤷‍♀ ⬅️ Правило делегирования

Есть простое, но очень важное правило: можно делегировать задачу, но нельзя делегировать ответственность. 

Предположим, есть менеджер, у которого один подчиненный. Высокое начальство ставит менеджеру задачу – выкопать яму. Менеджер ставит эту же задачу подчиненному. Теперь голова по поводу задачи болит у подчиненного, а менеджер может заняться другими делами.
Но если яма не выкопана, высокое начальство будет применять репрессивные меры к менеджеру, а не к его подчиненному. 

Почти никто из начинающих менеджеров этого не понимает. А зря.

Еще один хороший канал про создание продуктов: @proudobstvo. Ведет его Миша Греков, действующий продукт-менеджер, так что фигни не пишет. Зато действительно немало пишет про то, как сделать продукт удобным для пользователя, и что этому может помешать.

Понравилось:

https://t.me/proudobstvo/218 - о продуктовом забиваке (и это не про талисман футбольного ЧМ)

https://t.me/proudobstvo/369 - о разнице между UX и UI, точнее... не, не буду спойлерить)

https://t.me/proudobstvo/236 - про хитро... гм... умных пользователей)

https://t.me/proudobstvo/367 - как ставить задачи по продукту, чтобы получать хороший результат

https://t.me/proudobstvo/362 - о том, как важно держать темп

Рекомендую.

​​🗣 В пользу эскалации

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

Это прекрасное качество для исполнителя, тем более армейского, да и замечательная черта национального характера, но лучше оставить ее для суровой годины. В управленческих же делах такая бездумная самоотверженность оборачивается не посмертной славой, а скорым забвением. А в проектах и того хуже - вечным позором.
Основная причина, по которой менеджер боится рассказывать о проблемах проекта - боязнь, что его признают некомпетентным и неспособным управлять. Это заблуждение. Хороший руководитель вовсе так про вас не подумает (пока объем вашей работы в списке его дел не превысит объем его собственной, но вы же не идиот). Он прекрасно понимает, что есть немало вопросов, которые без него вам не решить.

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

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

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

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

​​🖇 Об управлении ожиданиями

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

"Вот представь, сидишь ты в очереди к врачу или в какое-нибудь госучереждение. И единственное, что ты знаешь - что ты в очереди. Даже если она электронная, у тебя есть только номерок. Может, твоя очередь подойдет минут через десять, а может - через три часа. Ты жутко мучаешься от этого. 
Другое дело - если ты уверен, что в ближайшие три часа тебя точно не вызовут. Ты можешь планировать свое время - пойти в кафе, побродить в парке, сгонять в магазин. Ты чувствуешь, что можешь управлять своими действиями. 
Вот поэтому важно и планировать, и делиться планами."

Лучше и не объяснить.)

​​🧗🏻‍♂ О блуждающих менеджерах

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

Мне всегда нравились истории про людей, которые готовы начать новый проект, невзирая на возраст. И я говорю не о Рэе Кроке, я говорю о тех, кому от тридцати пяти до сорока пяти.

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

Но попробуй еще найди силы для такого рывка! Вот потому-то и интересен и ценен опыт тех, кто может это сделать. Лично мне нравится история о режиссере Энг Ли, который шесть лет был безработным, а потом смог переломить эту полосу невезения (ему было 37), и теперь мы знаем его "Халка", "Горбатую гору" и "Жизнь Пи". Да мало ли примеров. Владелец Zara до 37 лет работал продавцом в магазине. Основательница Mary Kay вообще до сорока с лишним лет трудилась торговым агентом. Кажется, даже гениальный Форд до 36 работал инженером в компании Эдиссона. А Говард Шульц, основатель Starbucks, писал про свои первые шаги в бизнесе: "Кем я был тогда? Наивным тридцатипятилетним мечтателем!"

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

"Not all those who wander are lost", - как писал старина Толкин, - "Не все, кто блуждает, - потерялись".

​​🐢 Об упущенных возможностях

Участвовал я как-то в выборе большой ИТ-системы для клиента. Был организован тендер, в котором участвовало 18 компаний. Среди них были все наши крупные системные интеграторы. На подготовку предложений у компаний было три месяца, в течение которых они могли активно консультироваться с заказчиками по любому поводу. В назначенный день мы пошли вскрывать пакеты с коммерческими предложениями.

И что же мы увидели?
Каждое предложение было не меньше чем на 100 листов. Каждое предложение начиналось с пространного описания достижений компании-внедренца. Некоторые предпочли начать с рассказа о своей славной истории, уходящей у кого в мрачные 90-е, у кого аж в романтические 80-е. Потом шел внушительный кусок текста, в котором описывалось, как они поняли основные требования к системе (copy-paste документов, полученных от заказчика). Потом рассказывалось о том, как выгодно с ними работать и какие классные проекты они уже сделали для других клиентов.

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

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

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

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

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

​​📋 Чек-лист постановки задач

Хотите, чтобы что-то было сделано, – ставьте задачу. Если исполнитель вашу задачу не делает, то либо он негодяй)), либо у вас нет полномочий ставить задачу этому человеку, либо вы ставите ее неправильно.

1. Первое правило хорошо поставленной задачи – начните ее с глагола, а не с существительного.  
Плохо (отглагольное существительное):
Тестирование модуля Х.
Разработка функции Y.
Хорошо (глагол):
Протестировать модуль Х.
Разработать функцию Y.

2. Больше конкретики – конкретную задачу легче делать и проще контролировать. Задача создается, чтобы ответить на вопрос «что сделать?», а не «что делать?».
Плохо (неконкретно):
Обдумать риски в проекте А.
Наметить дальнейшие шаги в проекте В.
Хорошо (конкретно):
Составить реестр рисков в проекте А.
Создать план проекта В.

3. Каждой задаче нужен срок исполнения. Нет дедлайна – нет стимула делать. Дедлайны дисциплинируют и помогают планировать.
Плохо (нет срока):
Создать документ D.
Хорошо (есть срок):
Создать документ D к 29.02.2020.

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

5. Описание должно включать все нужные для работы материалы. Исполнитель не должен бегать по разным источникам, по крупицам собирая информацию о задаче. Все, что ему нужно для выполнения, должно быть описано и приложено к задаче. То же касается любых ресурсов, которые нужны для выполнения задачи. Хочешь хорошего результата – создай человеку условия для работы.  

Собственно, больше ничего и не нужно. )

Еще хороший (авторский и качественный) канал про управление продуктами @vladimir_merkushev от Владимира Меркушева, продукт-менеджера из Казахстана. 

Например:

https://t.me/vladimir_merkushev/84 - про customer development методом погружения 

https://t.me/vladimir_merkushev/164 - про UX-тестирование как реалити-шоу

https://t.me/vladimir_merkushev/174 - что делать тем, кому в канбане не хватает скрамовских дедлайнов)) 

https://t.me/vladimir_merkushev/415 - как продакту использовать майндмапы 

Автор пишет часто и хорошо, рекомендую.