Я узнал о ментальных картах, когда один из учредителей холдинга, в котором я работал, порекомендовал мне книгу Тони Бьюзена "Супермышление".

Найти ее можно например здесь. 

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

А идея классная.

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

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

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

Жили в лесу мышки, и все их обижали.

И решили они просить совета у мудрого филина. Пришли и говорят:

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

Что нам делать?

Филин подумал и говорит:

— Отрастите колючки. Тогда вы станете как ежики, а ежики хоть и маленькие, но они с колючками и их никто не обижает.

Мышки обрадовались и побежали домой. Но по дороге одна мышка сказала:

— Как же мы отрастим колючки?

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

Прибежали и спросили:

— Мудрый филин, а как же мы отрастим колючки?

И ответил им филин:

— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь.

Анекдот

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

***

Не стоит ждать чуда.

Волшебной таблетки не существует.

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

Этот пост не о том, что аналитики бесполезны, что анализом и оптимизацией бизнес-процессов не нужно заниматься. Он про другое, больше про то, что "один в поле не воин", что реинжиниринг бизнес-процессов - это совместная работа всех: первого лица, ТОП менеджеров (я их часто дальше буду называть функционалами, подразумевая под этим руководителей подразделений) и, конечно, аналитика.

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

Господи, дай мне силы изменить то, что я могу изменить,

дай мне мужества принять то, что я не в силах изменить,

и мудрости отличить одно от другого

(предположительно) Рейнхольд Нибур

Бывали у Вас ситуации, когда Вы были обижены на своего работодателя?

"Да я столько сделал, никто это не ценит. Никому это не надо. Все!!! Держите меня семеро, я ухожу".

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

- контролировать нужно было чаще, давать больше обратной связи;

- оно в общем-то и не нужно, есть вещи поважнее и понужнее, шансов запустить это - ноль.

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

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

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

Каникулы в Простоквашино

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

Когда задач много, а ресурса ИТ на всех не хватает.

Я несколько раз  наступил на эти грабли сам. Слышал много историй от коллег.

Близкими проблемами являются "Никому не нужный подвиг" и "Супер-аналитик оптимизатор".

Теперь суть:

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

Любая строчка кода пишется только тогда, когда заказчик готов тратить время и силы на:

• постановку: беседу с аналитиками для составления ТЗ;
• внедрение: работу с сопротивлением, повышенную нагрузку при имплементации.

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

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

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