Comments 14
Наверное, имеет смысл упомянуть Ильяхова с "Пиши. Сокращай", "Ясно. Понятно" и "Суть и смысл".
Я, конечно, не искушенный сомелье, смотрю на все больше со стороны управления разработкой, чем со стороны бизнеса, но в какой-то момент пришел к похожей, хотя немного другой системе. Любая наша деятельность - это постоянные выборы. Некоторые выборы приводят к проблемам. Проблема = любые лишние траты времени, нервов команды, и, естественно, бюджета. Некоторые выборы повторяются часто, вроде "по какому принципу называть переменные". Некоторые - редко, вроде "какую по специальностям команду собрать под проект". Но даже очень большие выборы повторяются. Поэтому возможен алгоритм:
цикл до посинения {
1. обнаружить повторяющуюся проблему
2. вне зависимости от ее важности/эпичности проанализировать контекст
-> узнать, какой повторяющийся выбор к ней приводит
3. в следующий раз в такой же ситуации сделать другой выбор
4. задокументировать для будущих участников
}
Даже если новый выбор будет иногда не очень - через N итераций инструментарий и процессы все равно вычищаются от выборов, которые стабильно приводят к проблемам. А то, что остается - "просто работает".
Мне такой подход нравится больше анализа конкретных больших успехов или провалов, потому что к завершению чего-то обычно приводит целая гора маленьких выборов, и не только инженерных, и постфактум сложно понять, а какие из них действительно помогали идти к цели, а какие мешали. Можно себя случайно убедить в том, что не имеет смысла. А методичная чистка просто потихоньку работает в фоновом режиме, полируя все процессы. Она работает как стабилизатор процессов. К успешному успеху сама по себе не приведет, но и не даст эпично провалиться на случайно сложившейся комбинации проблемных выборов.
Мой опыт показывает мне, что одно и то же решение может приводить к противоположным результатам. Поэтому, прежде всего стоит руководствоваться здравым смыслом.
Вот вам отличная идея, которая работает, тоже из опыта. Вместо базы знаний для менеджеров проектов, куда лучше будут работают тренинги, по настоящим кейсам из завершенных проектов. Я не говорю, что база знаний не нужна, как минимум, там должны быть основы. А ещё описание сложившихся бизнес-процессов компании. Плюс кейсы.
И немного подробнее про тренинги.
Суть в том, что кейсы у каждого на проекте свои, похожие, но при этом уникальные. Ведь они возникают на разных этапах. Клиенты разные. Как люди, так и размер компаний. А ещё команды разные, большие, малые, смешанные с командой клиента, несколько команд и т.д.
Эти кейсы можно просто копить. Когда встречается что-то интересное, руководитель отдела просто даёт задачу описать кейс менеджеру проекта для базы знаний. Пропуская его через свою редакцию.
Далее организуются обучения, например, 1-2 раза в неделю, в начале рабочего дня. Фиксированное время. И на этом обучении последовательно разбирается какой-нибудь этап работы менеджера, краткая теория. А потом практика, на живых кейсах, связанных с этим этапом. Менеджеры разбиваются на группы, каждому даётся роль (клиент, ПМ, продажник, разработчик) и обыгрываются эти кейсы. Предварительно, минут 5 команда совещается в рамках группы (ПМ, продажник, разработчик). Идёт поиск решения. Потом уже сам разговор с клиентом. Чтобы согласовать это решение. Отмечу, что не все кейсы могут быть связаны с клиентом. Обучение идёт 1 час.
Вот пример кейса. Продажник нашел клиента. Но он хочет точную цену, срок (каскадная разработка), а проект большой. Оценки дают слишком большие погрешности. Компания может взять проект лишь по tm (time&material). Продажник не может решать, как вести такой проект, он идёт к ПМ. Надо придумать решение, что устроит обе стороны. И немного деталей о самом клиенте (от личности лпр до размера фирмы).
Самое интересное, что это реальные кейсы, и уже известно, какое решение там принималось, и какие результаты. А значит, любое решение обучаемых менеджеров есть с чем сравнивать. А потом обсудить, почему так, а не иначе, или как можно было сделать это по-другому.
В итоге, получается мультипликативная польза:
Улучшение отношений между сотрудниками. Тимбилдинг.
Общение, обмен опытом
Отработка навыка по принятию решений. В процессе обсуждения решений объясняется логика принятия решения.
Лучше понимаются коллеги из смежных отделов (продажники, пресейл, разработчики)
Открытость, доверие. Кейсы могут быть с негативным результатом. И за это сотрудник не подвергается давлению. Кейсы обезличены. Это опыт, вполне вероятно, что никто из коллег не смог бы правильно решить проблему.
Диагностика (это для руководителя отдела). На тренинге сразу видно, кто как работает, я про активность, открытость. И если какой-то сотрудник замкнут на протяжении 6-8 тренингов (1 мес.), то очень вероятно, что он и в команде и с клиентами такой. И надо принимать меры.
Не смог припомнить ни одного примера когда одно и то же решение на схожих или типовых проектах приводило бы к противоположным результатам. Возможно я плохо старался. Кажется, что митапы, тренинги, база знаний и коллективный разбор кейсов - это более верхнеуровневый процесс, который направлен на то, чтобы привести уровень подготовки сотрудников с разной квалификацией, опытом и специализацией к единому стандарту компании. Если на типовых проектах один специалист выдает блестящий результат превосходящий все ожидания, а другой просто присутствует для фона - это может нанести компании некоторый репутационный ущерб.
Очень понравился пример про диагностику из пункта 6.
По стилистике текста уже прошлись и тут я горячо поддерживаю комментаторов.
Но меня терзает другая мысль.
Вот мы занимаемся деятельностью, и там регулярно происходят факапы. Мы их собираем, анализируем и больше не повторяем. А факапы все равно происходят (просто каждый раз другие).
Со стороны это может выглядеть как некоторая "проклятость" ПМ-а. А смотришь на другого ПМ-а а у него вроде все тоже самое, но если факап и случится, то ясно, что от такого в принципе не застрахуешься и вносить такое в уроки бесполезно. А в остальном, у второго все четко и гладко.
Отсюда и вопрос, вы предлагаете в уроки вносить факапы первого или второго ПМ.
И если первого, нет ли ощущения, что не в коня корм?
Если сбои происходят постоянно и непрерывно на всех проектах, то скорее всего не отлажены бизнес-процессы и нужно разбираться в причинах обуславливающих эти сбои. В случае если причиной сбоев являются систематические не верно принимаемые решения конкретного сотрудника, нужно, наверное, задуматься о целесообразности продолжения сотрудничества с ним. В документы я предлагаю вносить информацию согласно описанной в статье методике.
Присоединяюсь ко всем выше про "много воды, витиевато, излишне и ненужно длинные фразы" и так далее.
что попросту не обратил внимания на эту стилистическую неровность. Перед теми же кто, заметил этот мерзкий смысловой заусенец, мне искренне стыдно
Автору должно быть гораздо стыднее за многочисленные реальные ошибки в русском.
Также не показан самый главный и последний шаг (а даже и он не последний), хотя он и подразумевается - формальное изменение бизнес-процессов. А самый самый последний шаг - дальнейший мониторинг реального влияния этих изменений и окончательные выводы, оставлять ли изменения или откатывать их назад и лишь знать про некие особые случаи, которые надо иметь ввиду.
Не согласен с мнением, что формальное изменение бизнес-процессов это часть практики "выученные уроки". Это не входит в задачи для роли руководитель проектов. Внесение изменений в бизнес-процессы - это прерогатива владельца бизнес-процесса. Как, впрочем, и мониторинг результатов, которые приносят эти изменения.
Стилистика изложения конечно не на мой вкус. Тем не менее, полезное почерпнуть можно. Мой опыт изучения зарубежных практик показывает, что в целом структура вашего фреймворка соответствует лучшим аналогам, как и процессы управления извлеченными уроками. Не обнаружил процессов изменений на основе извлеченных уроков и обучения на основе опыта (есть хороший пример Shell, плюс выше товарищ описал про тренинги, это примерно про это же). Это все таки ради чего фиксируются уроки: сделать изменения, обучиться и обучить других. Также имел возможность внедрять подобные практики в российских компаниях, даже написал книгу на этот счет. Еще больше, разработал с командой решение на базе Битрикса (если кому надо, можете поискать в маркете Битрикса Извлеченные уроки от Novus-HCM). Но вот почему-то у нас более формальное извлечение уроков плохо приживается. Вроде уроки извлекают, но особо желания нет фиксировать, анализировать прошлый опыт. Кроме тех организаций, где это деятельно поддерживает первое лицо. Или где это связано с безопасностью (пилоты, пожарные и т.д. неплохо практикуют). Вероятно это связано как-то с культурным кодом, а может просто зрелостью корпоративного управления?
Процесс документирования не приносит быстрого результата в краткосрочной перспективе, и по этому не хочется тратить на это время. Но когда начинаются разборы полетов, документы, метрики и конкретные цифры (в очках, голах, секундах) - это отличные козыри в диалоге. Время потраченное на документирование - это, как правило, долгосрочная инвестиция.
Автор, вы знатный графоман и нарцисс. :-) Графоман, ибо идеи на пару тысяч символов растянули на 18000 символов. Нарцисс, ибо писали это для себя, чтобы потом самому перечитывать. Перечитывать это ради процеживания смысла мне кажется весьма затратным, а чтобы полюбоваться своим умением толочь воду в ступе - идеально.
Если осилите отредактировать и ещё раз опубликовать эту статью и выкинуть всё графоманство, заодно структурировав не просто на главы, но и списки, где это имеется, то будет вообще прекрасно! Пока это просто полезно*.
*- с учётом трудозатрат на выделение сути.
Первоначальный вариант статьи был регидрирован и сух. Прежде чем публиковать статью, я попросил ознакомиться с ней нескольких моих друзей. Среди негативных отзывов были строго противоположные тем, что озвучены выше в комментариях. В частности, недовольство вызвало: недостаточное раскрытие некоторых терминов, стиль изложения материала "как будто робот писал", наличие непонятных моментов, требующих пояснения и так далее. Пришел к выводу, что всем не угодишь. Опубликовал менее душный вариант.
«Выученные уроки» или «Никогда такого не было и вот опять»