Рубрики
Мотивация Управление проектами

Почему мы откладываем стратегические задачи?

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

И вы не делаете отчёт ни этим ни следующим вечером. Почему так?

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

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

Рубрики
Мотивация Управление проектами

Доклад — Принцип экономии мыслетоплива / Максим Дорофеев

Посмотрел отличный доклад  Максим Дорофеев о том, что такое мыслетоплево и как его экономить — рекомендую!

Рубрики
Управление проектами

ЧЕРНАЯ КНИГА СКРАМ. Автор: Иван Селиховкин

Предыстория

Иван Селиховкин нашел этот блокнот при переезде в новый офис. Раньше здесь располагалась крупная компания-интегратор. Они съезжали спешно и много бросили — Иван обнаружил записи, переставляя мебель. Автор, похоже, то ли рвал, то ли жег свое творение прямо на рабочем месте — не успел и забросил остатки в щель между кулером и стеной.

Рубрики
Управление проектами

Как быстро оценить масштаба внедрения и изменения

Для меня как для менеджера, всегда было проблемой определить масштаб изменения. Не так давно для оценки масштаба внедрения/изменения стал применять ромб Левитта. Это простой инструмент, который показывает взаимосвязи между организационными структурами, системами, задачами и людьми: если Вы проводите изменения в одной области, Вы должны учитывать их вероятные влияния на другие.
Рубрики
Управление проектами

НЖЯ — НеЖелательное Явление

НеЖелательные Явления (НЖЯ) — факты действительности, объясняющие почему настолько сложно достичь более высоких результатов работы системы. ‘Явление’ говорит о том, что существование данного факта несомненно. Могут быть споры о его размахе, но не о его существовании. ’Нежелательное’ говорит о том, что это явление представляет собой опасность для/уменьшает/не позволяет достичь важной потребности или цели системы.

10 правил НЖЯ

  1. НЖЯ — это постоянная проблема, которая существует в вашей действительности, из-за нее вы не можете достичь лучшего уровня деятельности.
  2. Это описание состояния, а не одноразового случая или действия. (НЖЯ не может содержать глаголы действий типа «взять», «идти» и т. д.)
  3. Это явление находится в вашей области ответственности.
  4. Относительно этого явления возможно что-то предпринять. (Например, «На улице слишком жарко» — это не НЖЯ. Мы не можем изменить то, что на улице жарко. Мы можем изменить только наши действия: то, что мы предпримем, чтобы нам не было жарко.)
  5. НЖЯ не должно обвинять кого-либо.
  6. НЖЯ не должно быть предполагаемой причиной.
    («Сотрудники недостаточно обучены» — это не НЖЯ, это предполагаемая причина: «Поскольку сотрудники недостаточно обучены…»)
  7. НЖЯ не должно быть завуалированным решением (желанием того, как можно было бы решить проблему).
  8. НЖЯ не должно требовать пояснения того, какой негативный эффект оно вызывает.
  9. НЖЯ не может содержать причинно-следственную связь.
  10. НЖЯ не должно быть субъективным утверждением: не должно содержать оценочных прилагательных и наречий, таких как «сложный / сложно», «хороший / хорошо», «плохой / плохо», «минимальный», «максимальный» и т. п.

Источник: Одед Коуэн, Елена Федурко «Основы Теории Ограничений», 2012г.
http://tocpractice.com/ru/terminy-i-koncepcii-toc/2015/08/14/nzhya-nezhelatelnoe-yavlenie/

Рубрики
Тех. решения Управление проектами

Алгоритм системного решения проблем

Допустим, упал сайт. Или у кого-то отображается не тот номер телефона в подменах. Или в рекламной кампании обнаружены лишние ключевые фразы. Реакция по умолчанию: исправить и забыть. Такая реакция приводит к плохим последствиям: сложность проекта растёт, на починку уходит всё больше времени, а на настоящую работу — всё меньше.

Я для себя пришёл к такому алгоритму:

1. Обнаружена проблема
Сработал мониторинг. Или клиент прислал. Или сами заметили.

2. Подтвердить получение проблемы и срок реакции
Записать в тикет-систему / баг-трекер / докс. Уведомить менеджера / команду / клиента. «Принял, разбираюсь прямо сейчас». «Принял, посмотрю после задачи Х через час».

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

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

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

4. Убедиться, что проблема действительно есть
Чтобы решить проблему, надо сначала её воспроизвести. Иногда это сложно. Надо либо воспроизвести, либо доказать, что её нет. «У меня не воспроизводится» — не ответ.

Снять проблему может только тот, кто о ней сообщил. Пока не снял, считаем проблему актуальной.

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

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

Но информировать обязательно — для прозрачности, ощущения контроля и доверия.

6. Исправить
Исправить.

7. Проинформировать
Проинформировать, что исправили и рассказать, что собираемся делать дальше.

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

8. Сделать контрольную проверку
Проверить, что ошибка действительно исправлена. Обязательно сделать это другим способом. Желательно на следующий день со свежим взглядом. Например, сайт посмотреть в других браузерах и в мониторинге. Рекламу посмотреть не в интерфейсе, а в поиске и в статистике.

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

9. Проинформировать
Мало кто делает контрольные проверки. У всех Нет Времени. Сделать и расказать — +1 в карму.

10. Что могло сломаться рядом? Что могли сломать, пока чинили?
Починили вёрстку в одном браузере? А в других? А на мобилках? А в версии для печати?
Изменили работу калькулятора на лендинге? А на основном сайте? А в других регионах? А события не поломали?
Обнаружили лишнее ключевое слово в одной РК? А есть в других? А в SEO? А в списке услуг на сайте?

Вообще-то, это надо делать сразу, но неплохо проверять ещё раз после.

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

11. Проинформировать
Ну вы поняли.

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

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

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

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

13. Проинформировать
Вот здесь больно, да.

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

Кстати, «человек ошибся» — это не разовая ошибка. Люди ошибаются всегда, поэтому людей считаем системной ошибкой.

Ещё бывают редкие ошибки и дешёвые ошибки. Их может быть дешевле не лечить и честно об этом сказать. Например, глючащий несколько дней сервис онлайн-консультанта снизит выручку на 40 т.р.. Цена смены сервиса с переобучением людей и перестройкой аналитики — ~400 т.р. и ещё не известно как на конверсию повлияет. Решение Всё Поменять здесь было бы поспешным.

15. Проинформировать
Если не спрашивают, всё равно рассказать. Системные решения — это же самое важное.

16. Сделать отчёт для себя / команды / клиента в будущем
Отчёт идёт прямо по этому формату. По этим отчётам потом хорошо искать причины похожих проблем. И учить новеньких.

17. Что осталось сделать?
Закрывать тикет можно только когда ответ на этот вопрос пуст.

Как быть уверенным, что сделано действительно всё? Доверять внутреннему чутью. Чутье — это накопленный опыт и боль.

Ещё раз алгоритм списком (можете скопировать к себе)

  1. Обнаружена проблема
  2. Подтвердить получение проблемы и срок реакции
  3. Оценить критичность и составить план действий
  4. Убедиться, что проблема действительно есть
  5. Подтвердить, что проблема есть, и сказать, когда исправите
  6. Исправить
  7. Проинформировать
  8. Сделать контрольную проверку
  9. Проинформировать
  10. Что могло сломаться рядом? Что могли сломать, пока чинили?
  11. Проинформировать
  12. Посчитать цену ошибки
  13. Проинформировать
  14. Найти системное решение
  15. Проинформировать
  16. Сделать отчёт для себя / команды / клиента в будущем
  17. Что осталось сделать?

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

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

Спасибо за статью Всеволоду Устинову.
Источник: http://vsevolodustinov.ru/blog/all/algoritm-sistemnogo-resheniya-problem/