Важно, что это не задача:<\/p>\n
- \n
- Открытый вопрос может порождать множество задач, нацеленных на его решение.<\/li>\n
- У него свой жизненный цикл, набор описывающих параметров, поэтому лучше вести его в отдельном реестре.<\/li>\n<\/ol>\n
Приведу пример: ваш тимлид положил заявление на стол. Это проблема. Если с ней что-то не сделать, работа команды будет парализована.<\/p>\n
Как руководитель вы можете:<\/p>\n
- \n
- Пообщаться с тимлидом, попробовать его удержать<\/li>\n
- Пообщаться с руководителем, выбить бюджет, чтобы повысить тимлиду зарплату<\/li>\n
- Разместить новую вакансию<\/li>\n
- Написать знакомым руководителям, нет ли у них подходящих кандидатов<\/li>\n<\/ul>\n
Все это — задачи, и они падают в бэклог команды.<\/p>\n
Сам открытый вопрос «Иванов увольняется с такого-то числа» висит в реестре открытых вопросов, вы удерживаете на нем фокус, т. к. на каждой планерке рассматриваете открытые вопросы<\/p>\n
Универсальный алгоритм движения вперед<\/b><\/p>\n
Для меня работа с открытыми вопросами стала воплощением универсального алгоритма движения вперед.<\/p>\n
- \n
- Формулируем цель<\/li>\n
- Планируем действия по ее достижению<\/li>\n
- Выявляем проблемы, мешающие двигаться вперед<\/li>\n
- Планируем действия по ее устранению. При необходимости — возвращаемся на п.3<\/li>\n
- Повторяем, пока не получили результат<\/li>\n<\/ol>\n
На практике я реализую этот алгоритм, задавая вопросы:<\/p>\n
- \n
- Что делаем, какие следующие шаги? (записываем задачи в план)<\/li>\n
- Что мешает? (записываем открытые вопросы)<\/li>\n
- Что делаем с п.2? (записываем задачи в план)<\/li>\n<\/ol>\n
Это практически система-ниппель: мы либо двигаемся вперед, либо нам что-то мешает, тогда мы решаем, что делать, чтобы это устранить, и снова двигаемся вперед.<\/p>\n
Других вариантов нет, только вперед.<\/p>\n", "date_published": "2023-05-23T13:46:43+00:00", "date_modified": "2023-05-23T13:46:15+00:00", "_date_published_rfc2822": "Tue, 23 May 2023 13:46:43 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "123", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "97", "url": "https:\/\/blog.skalon.me\/all\/dolzhen-li-prodzhekt-menedzher-razbiratsya-v-predmetnoy-oblasti\/", "title": "Должен ли проджект менеджер разбираться в предметной области проекта?", "content_html": "
Часто встречаю мнение, что руководитель проекта должен хорошо разбираться в предмете проекта, которым он руководит. Например, если это проекты в финтехе — должен уметь разработать фин. модель продукта. Если это проект в ИТ — РП должен быть чуть ли не бывший программист.<\/p>\n
Сразу скажу: мне удавалось вполне успешно руководить проектами, в предметной области которых я очень мало понимал.<\/p>\n
Но вопрос непростой, давайте его разберем.<\/p>\n
Обычно люди, которые топят за менеджеров-экспертов, недооценивают объем чисто менеджерских, управленческих задач, которые надо выполнять: планирование, решение спорных ситуаций, управление стейкхолдерами, управление рисками и т. д.<\/p>\n
На больших проектах объем таких задач может быть существенным. Если речь идет об организационном проекте из нескольких компонентов, типа внедрения мощной корпоративной ИТ-системы, помимо РП может потребоваться еще и несколько администраторов.<\/p>\n
На маленьких и средних проектах объем управленческих функций меньше, поэтому руководитель может помимо чисто менеджерских задач выполнять какие-то работы. Например, разрабатывать технические задания, делать аналитические отчеты и пр.<\/p>\n
К сожалению, именно на таких проектах объем управленческих функций недооценивается, в результате менеджер не успевает как следует спланировать работы, коммуникации со стейкхолдерами, или оформить запрос на изменения. Иногда и сам менеджер, если он глубоко погружен в предмет, не может устоять перед соблазном, например, написать кусок кода.<\/p>\n
В результате страдает проект: выплывают риски, едут сроки, появляются недовольные стейкхолдеры.<\/p>\n
Поэтому первый вывод такой.<\/p>\n
Чем сложнее проект, тем меньше на менеджере должно быть исполнительских задач.<\/b><\/p>\n
Другой нюанс заключается в том, что в некоторых ситуациях менеджеру хорошо бы понимать, что происходит, чтобы принимать более верные решения. Особенно ярко это заметно в стройке. Если вы не знаете, условно, чем отличается цемент марки ХХХ от марки YYY — вам будет сложно руководить проектом, потому что вам будут пускать пыль в глаза.<\/p>\n
Руководя проектами, в которых я ничегошеньки не понимал, я сталкивался несколько раз с ситуацией, когда я не задавал какие-то вопросы, которые задал бы знающий человек, и это влияло на сроки проекта. Но ни разу это влияние не привело к неудаче проекта.<\/p>\n
Поэтому вот второй вывод:<\/p>\n
Классно, когда РП шарит в предмете, но обычно не критично, если он хорош в менеджменте, а проекты большие.<\/b><\/p>\n", "date_published": "2023-05-10T07:20:17+00:00", "date_modified": "2023-05-10T07:20:13+00:00", "_date_published_rfc2822": "Wed, 10 May 2023 07:20:17 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "97", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "76", "url": "https:\/\/blog.skalon.me\/all\/neochevidny-sposob-reshit-problemu-nehvatki-vysokokvalificirovan\/", "title": "Неочевидный способ решить проблему нехватки высококвалифицированных руководителей проектов (кейс)", "content_html": "
Есть отличный способ увеличить «пропускную способность» руководителей проектов, заодно снизив угрозы для «непрерывности бизнеса». Расскажу на примере.<\/p>\n
Я руководил пятью крупными тесно связанными проектами. Когда все они только запускались, я своевременно забил тревогу: дескать, сейчас все перейдет в стадию реализации, и меня погребет под задачами, что-то неизбежно пойдет не так. Выбил себе администратора проектов (до этого такая практика отсутствовала).<\/p>\n
Взяли ответственную девочку из операционного отдела. Я ее обучил, постепенно настроил процессы управления и делегировал ей их поддержание: задачи по ведению проектной документации, подготовке и протоколированию совещаний, поддержание порядка в ИТ системе и т. п. Ей — отличный опыт и обучение, мне — возможность сфокусироваться на функциях, которые я не могу делегировать: планирование, переговоры, принятие решений.<\/p>\n
В результате, компания увеличила «пропускную способность» одного синьор РП примерно вдвое за счет одной только девочки-администратора: без нее я бы не справился и с тремя такими проектами. При этом качество управления возросло, потому что у меня вечно не хватало сил и времени на качественное выполнение процедур проектного управления (каюсь).<\/p>\n
Даже если оценить только эффект по ФОТ, то это дико выгодно. Синьор РП стоит примерно в 3-5 раз дороже администратора проектов.<\/p>\n
Другой плюс в том, что когда я ушел из компании, проекты не встали: при поддержке администратора проектов они спокойно шли еще некоторое время, пока выходил новый руководитель, входил в курс дел и т. д. Разумеется, чтобы это стало возможно, я сначала настроил систему управления проектами, а перед этим разработал методологию и внедрил специализированную ИТ-систему.<\/p>\n
К тому же, из администратора проектов обычно довольно быстро вырастает руководитель проектов, который хорошо знаком с компанией, и ее спецификой, знает всех сотрудников и процедуры. С рынка такого взять не реально.<\/p>\n
В общем, отличное решение для больших проектов с большим количеством административных задач, типа организационных проектов (регуляторные, внедрение больших ИТ систем и т. п.). Ну или можно одного администратора шерить на много небольших проектов. Странно, что редко встречаю на практике.<\/p>\n
Часто наоборот, менеджеры говорят, что «Ну вот, буду я еще административный персонал раздувать». В результате «забивают гвозди микроскопом», тратя ресурс дорогущих РП на административные задачи.<\/p>\n", "date_published": "2023-05-05T11:35:00+00:00", "date_modified": "2023-05-05T11:34:57+00:00", "_date_published_rfc2822": "Fri, 05 May 2023 11:35:00 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "76", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "74", "url": "https:\/\/blog.skalon.me\/all\/luchshiy-sposob-sozdat-chuvstvo-srochnosti-u-chlenov-komandy\/", "title": "Лучший способ создать чувство срочности у членов команды", "content_html": "
Типичная ситуация в проекте. На планерке исполнитель говорит: «Мне на этой неделе некогда, надо переносить срок по задаче». А вы понимаете, что если снести этот срок, то им не ограничится. Но если исполнитель — большой руководитель или заказчик, возражать бывает сложно. Что делать?<\/p>\n
Поможет отличный инструмент: календарно-сетевой график проекта, a.k.a. график Гантта.<\/p>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/2023-05-05-19.25.27.jpg\")
\n<\/div>\nСила Гантта в том, что элементы в нем связаны, и сдвиг сроков по одной из работ может привести к сдвигу сроков всех следующих. Также в плане есть вехи, или контрольные точки — это значимые события, наступление которых можно проверить, и которые мы включаем в отчетность для руководства. Например:<\/p>\n
- \n
- Заключен договор с подрядчиком.<\/li>\n
- Выданы доступы исполнителям.<\/li>\n
- Сдан в ОПЭ модуль системы.<\/li>\n<\/ul>\n
За вехи очень полезно поставить ответственными членов команды.<\/p>\n
Так разговор из нашего кейса превращается примерно в такой:
\n— Мне на этой неделе некогда, надо переносить срок по задаче.
\n— Понял. Ну, что поделать, давайте попробуем… вот незадача, ай-яй-яй. У нас на полторы недели вперед уезжает веха, по которой вы — ответственный и о которой мы докладываем на Управляющем комитете. Давайте придумаем, что будем говорить куратору!
\n— Не надо, мы переприоритизируем свои задачи.<\/p>\nОбратите внимание: менеджер не давит авторитетом, не ругается. Он просто наглядно показывает последствия принимаемых решений.<\/p>\n
Разумеется, Гантт должен быть правильно разработан, чтобы оказать такое волшебное действие. Но календарное планирование — отдельная большая история, может когда-нибудь напишу.<\/p>\n
В наши дни повального «аджайла» Гантт, кажется, выходит из моды, однако это лучший из известных мне способов создать у исполнителя чувство срочности в отношении задач, находящихся далеко в будущем. И в этом плане он сильно недооценен. Об этом можно судить хотя бы по тому, что в большинстве инструментов, где все-таки Гантт присутствует, его реализация совершенно не юзабельна.<\/p>\n", "date_published": "2023-05-05T11:27:53+00:00", "date_modified": "2023-05-05T11:27:46+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/2023-05-05-19.25.27.jpg", "_date_published_rfc2822": "Fri, 05 May 2023 11:27:53 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "74", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/2023-05-05-19.25.27.jpg" ] } }, { "id": "59", "url": "https:\/\/blog.skalon.me\/all\/kak-minimizirovat-organizacionnoe-soprotivlenie-pri-vnedrenii-pr\/", "title": "Как минимизировать организационное сопротивление при внедрении проектного управления: подход «блэк бокс»", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/blackbox2@2x.png\")
\n<\/div>\nМой первый опыт внедрения проектного управления в компании был провальным.<\/p>\n
Я руководил проектным офисом — подразделением компании, отвечающим за разработку методологии проектного управления, формирование портфеля проектов, сбор отчетности по проектам и т. п. Я пытался заставить руководителей и кураторов проектов, не подчинявшихся мне напрямую, работать по новым правилам, например — проводить планерки по-новому, а они мне говорили: «Вася, ты будешь нам рассказывать, как планерки проводить? Мы и так отлично справляемся».<\/p>\n
Тогда я выяснил (а потом убеждался не раз), что проектный офис в компании находится в довольно слабой позиции, и даже мандат от первого лица не бесконечен.<\/p>\n
На основе того опыта я выработал подход к внедрению, который с тех пор применял много раз, и который полезен при внедрении многих организационных изменений. Сегодня поделюсь им с вами.<\/p>\n
Проектный офис часто «лезет не в свое дело»<\/h2>\n
Часто я вижу, как представители проектного офиса лезут в проекты с «добрыми советами»: пытаются обучить, заставить правильно проводить планерки, управлять рисками и т. д.
\nКогда на неё нет запроса, эта работа проектного офиса воспринимается как то, что он лезет, куда не просят, и говорит: «Вы неправильно живете» — проект неправильно оформили, не по процедуре, и т. д. Это как минимум раздражает, даже если правда.<\/p>\nИ если потом функциональные руководители приходят к биг боссам жаловаться на проектный офис, их административный вес обычно будет больше, даже если проектный офис прав. Потому что за каждым из функциональных руководителей стоит какая-то часть бизнеса, дающая очень конкретный и обычно измеримый вклад в общее дело. А проектный офис «координирует остальных участников», «задает правила игры»... а как конкретно помогает зарабатывать — очень сложно посчитать.<\/p>\n
Поэтому часто проектный офис скатывается в роль секретаря принеси-подай, бегает с жалобными глазами за руководителями, которые от него отмахиваются.<\/p>\n
Надо четко очертить границы проекта и не лезть в них<\/h2>\n
Мой инсайт заключался в том, чтобы представить себе проекты в качестве «черного ящика»: не важно, что происходит у него внутри, как именно руководитель проектов руководит. Но мне важны входы и выходы черного ящика. Моя линия аргументации примерно такая:<\/p>\n
- \n
- Компания инвестирует в проект определенные ресурсы. В обмен ожидает получить результат должного качества в согласованные сроки и бюджеты.<\/li>\n<\/ol>\n
- \n
- Для этого надо согласовать требования к результату, согласовать сроки и бюджеты. Это удобнее всего сделать с помощью паспорта проекта, реестра результатов с требованиями, графика контрольных точек (не принимайте за универсальный рецепт). Требования к этому оформлению вот такие (и я могу их обосновать<\/a>).<\/li>\n<\/ol>\n
- \n
- Проекту нужны коммуникации с руководством и промежуточный контроль — все это понимают, все взрослые люди. Поэтому раз в период вы будете предоставлять отчетность вот по этой форме. Она единая для всех проектов, руководству удобно ее смотреть, вам ее удобно предоставлять.<\/li>\n<\/ol>\n
- \n
- Внутри этих границ вы вольны руководить проектами как бог на душу положит: вы — профессионалы, мы вам доверяем. Не хотите проводить планерки — ваше дело.<\/li>\n<\/ol>\n
Чего я этим добиваюсь?<\/p>\n
Во-первых, это очень справедливые требования, понятно, зачем они (обратите внимание, они полностью согласуются с конфликтной стратегией<\/a>). Они не вызывают отторжения, легко добиться их соблюдения.<\/p>\n
Во-вторых, этих требований минимально достаточно, чтобы четко очертить границы проекта и насколько возможно устранить основные неясности: что будем делать, кто должен делать, в какие сроки и т. п.<\/p>\n
В-третьих, этих требований достаточно, чтобы контролировать ход проекта «снаружи» через отчетность по контрольным точкам.<\/p>\n
Учить разумному, доброму, вечному можно только при наличии запроса<\/h2>\n
Благодаря тому, что границы проекта очень четко очерчены и выстроен качественный промежуточный контроль, любое нарушение быстро становится заметно.<\/p>\n
Например, не выполняется в срок контрольная точка из плана:
\n«2022-09-13 — Сдан в ОПЭ модуль „Бюджетирование“»
\nМы можем 13 сентября сходить в бухгалтерию, и посмотреть своими глазами, сдан модуль в эксплуатацию или нет. И вот уже у нас есть неоспоримый факт: не соблюдена контрольная точка, и разговор проектного офиса становится гораздо конкретнее, и от него так не отмахнешься.
\n— Не выполнили контрольную точку? Вы должны инициировать процедуру переноса сроков, эскалации и т. д.
\n— Систематически не выполняются контрольные точки? Вот вам рейтинг руководителей или КПЭ, вы в нем в красной зоне. И вот уже руководителю проектов сложно сказать «я таких проектов сделал сотни, не надо меня учить». Глядишь, он и сам приходит на вебинар по управлению сроками, рисками и т. д.<\/p>\nКонечно, это не единственное условие, чтобы проектный офис не посылали: надо уметь приносить ощутимую пользу как минимум руководству. Но из характерной для проектного офиса позиции «сбоку» это наиболее безопасный и надежный способ организовывать работу проектам: четкие границы и работа с фактами.<\/p>\n
К сожалению, я неоднократно сталкивался с тем, что проектный офис наступает на те же грабли, что и я когда-то: начинает с того, что пытается учить руководителей проектов, «сеять разумное, доброе, вечное» среди них, хочет «принести пользу руководителям, а не только заставить их заполнять бумажки»... и каждый раз это заканчивается абсолютно одинаково. Разумное, доброе, вечное не всходит, польза оказывается не востребована, очередная попытка внедрения проектного управления буксует.<\/p>\n", "date_published": "2022-09-13T18:40:08+00:00", "date_modified": "2022-09-13T18:39:28+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/blackbox2@2x.png", "_date_published_rfc2822": "Tue, 13 Sep 2022 18:40:08 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "59", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/blackbox2@2x.png" ] } }, { "id": "53", "url": "https:\/\/blog.skalon.me\/all\/esli-vy-chuvstvuete-chto-v-vashih-proektah-nedopustimo-mnogo-hao\/", "title": "Если вы чувствуете, что в ваших проектах недопустимо много хаоса, проверьте, возможно вы неправильно распланировали совещания", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/regular_meetings@2x.png\")
\n<\/div>\nКо мне часто обращаются менеджеры, которым надо «навести порядок», «вернуть чувство руля», «систематизировать бизнес». Симптомы типичны:<\/p>\n
- \n
- Каждый член команды усердно работает над своими задачами, но общий результат оказывается не достигнут.<\/li>\n
- Задачи ставятся и теряются, находятся тогда, когда уже поздно.<\/li>\n
- Очередной раз «перепрыгнули пропасть на 99%».<\/li>\n
- Менеджер чувствует, что проект «разъезжается»: в шквале текучки теряется фокус на результатах и поддерживать его требует огромных усилий.<\/li>\n<\/ul>\n
Одна из вещей, с которых я начинаю решать проблему, это настройка регулярных управленческих совещаний.<\/p>\n
Менеджер должен регулярно «проверять домашку», иначе все забьют<\/h2>\n
Вспомните школьные годы. Если вы точно знали, что вас спросят домашнее задание на следующем уроке, каковы были шансы, что вы его подготовите? Для большинства людей — близко к 100%. Для взрослых это работает так же.<\/p>\n
Система исполнения базируется на регулярных управленческих совещаниях, в ходе которых менеджеры систематически уделяют внимание тому, что происходит в их управляемом периметре.<\/p>\n
На этих совещаниях они неизбежно «спрашивают домашку», т. е. смотрят отчетность, в которой зафиксированы основные показатели: что планировалось сделать, что сделано, где прогнозируется отклонение и т. д.<\/p>\n
При этом повестка совещаний сформирована так, чтобы «охватить вниманием менеджера» все аспекты, требующие управления.<\/p>\n
Регулярные совещания должны охватывать разные горизонты и аспекты управления<\/h2>\n
На разных временных горизонтах от менеджера требуются разные решения: раз в квартал мы подводим итоги и планируем, раз в неделю мы «нарезаем планы» на задачи, раз в день — координируемся друг с другом.<\/p>\n
Также есть разные аспекты, которыми нужно управлять: сроки, закупки, риски, управление персоналом, качество и пр.<\/p>\n
Аспекты проиллюстрируем на примере рисков. Если мы в принципе планируем рисками управлять — выявлять, принимать меры, контролировать статус — то нам понадобится обсуждение рисков на совещании. В зависимости от того, насколько серьезно мы этим планируем заниматься, нам понадобится регулярная выделенная риск-сессия, или мы можем включить работу с рисками в повестку других совещаний.<\/p>\n
Также рисками можно управлять на нескольких горизонтах: выявлять риски проекта целиком, координировать действия по их предотвращению или подключать «план Б» на оперативном горизонте.<\/p>\n
Таким образом, настраивая систему управления на проекте я определяю, чем менеджер управляет и разрабатываю цикл управленческих совещаний, которые покрывают весь управляемый периметр.<\/p>\n
Как настроить график совещаний так, чтобы ничего не упускать?<\/h2>\n
Что значит, что цикл совещаний настроен? Это означает, что совещания проходят с заданной регулярностью и с должным уровнем качества. Для этого каждое из совещаний должно быть описано:<\/p>\n
- \n
- Регулярность, длительность, участники, роли участников<\/li>\n
- Типовая повестка<\/a><\/li>\n
- Материалы, в первую очередь — отчетность, заточенная под повестку<\/li>\n
- Правила подготовки (в виде чек-листов)<\/li>\n
- Правила проведения совещания (Например, как делаем доклад? Как поступаем, если возникла посторонняя тема в обсуждении? Предусмотрено ли вообще обсуждение на встрече?)<\/li>\n
- Правила обработки результатов (ведение протоколов и пр.)<\/li>\n<\/ol>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/regular_meetings_notion@2x.png\")
\nВот пример таблицы с описанием совещаний. Внутри — чек-листы для подготовки, описание ролей и материалы.<\/div>\n<\/div>\nТаким образом, грамотно настроенный цикл управленческих совещаний — это система, которая позволяет ничего не упускать<\/i>. Если что-то все-таки проскочило мимо, это значит, что вы не все настроили: надо добавить совещание, скорректировать повестку существующего, улучшить качество подготовки или правила проведения.<\/p>\n", "date_published": "2022-06-07T16:50:34+00:00", "date_modified": "2022-06-07T16:50:07+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/regular_meetings@2x.png", "_date_published_rfc2822": "Tue, 07 Jun 2022 16:50:34 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "53", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/regular_meetings@2x.png", "https:\/\/blog.skalon.me\/pictures\/regular_meetings_notion@2x.png" ] } }, { "id": "52", "url": "https:\/\/blog.skalon.me\/all\/pervy-test-na-profprigodnost-rukovoditelya-proekta-dozhim-do-kon\/", "title": "Первый тест на профпригодность руководителя проекта: дожим до конкретики", "content_html": "
Очень важная компетенция руководителя проекта заключается в том, чтобы дожимать любые обсуждения до конкретики. Это особый навык, который не так просто дается, но по нему можно отличить опытного менеджера. Приведу пример из своего опыта.<\/p>\n
Без «кто, что, когда» никто нихрена не сделает<\/h2>\n
Я стал руководителем довольно крупного (для меня на тот момент) проекта. У меня в команде два методолога и один эксперт (все трое — старше и опытнее меня). Мы сидим на совещании, посвященном старту работ: обсуждаем концепцию решения, подход к командному взаимодействию, основные задачи. Совещание прошло продуктивно: мы всесторонне обсудили вопросы повестки, вся команда чувствует, что понимает проблему одинаково. Я заканчиваю обсуждение фразой: «Ну, отлично, тогда действуем, как обсудили. До встречи на следующем совещании!».<\/p>\n
После совещания эксперт, мой старший товарищ, задерживается со мной в переговорке и говорит: «Вась, а какие итоги совещания? Кто что делает, конкретно?» Я, немного раздражаясь, что он меня воспитывает, начинаю объяснять, что тут все взрослые люди, мы «синхронизировались», и все прекрасно понимают, кто что должен делать. Мой товарищ смеется и предлагает поспорить, что к следующему совещанию никто ничего не сделает.<\/p>\n
Он оказался прав. Более того, мне было сложно что-либо предъявить коллегам, потому что никаких конкретных договоренностей сформулировано не было, и все попытки «наехать» разбились об удивленные взгляды и возражения в стиле «мы ни о чем таком не договаривались».<\/p>\n
Что произошло?<\/p>\n
У руководителя проекта ничего не «само собой разумеется»<\/h2>\n
Во-первых, я поддался чувству, что все все понимают, и дальнейшие шаги «сами собой разумеются». Как выяснилось, это не так. Более того, впоследствии я узнал правило: «У руководителя проекта ничего не само собой разумеется».<\/p>\n
Во-вторых, моей ошибкой было предположить, что все коллеги сознательные и способны самостоятельно идти к целям. Со всем прискорбием сообщаю: нет, это не так. Конечно, в каком-то идеальном мире, или в окружении, когда вы на 100% влияете на членов своей команды, вы можете рассчитывать, что все сами приложат усилие и, если что-то непонятно, зададут уточняющие вопросы, добьются от вас ответа. Но на практике это исчезающе редкая ситуация.<\/p>\n
В-третьих, я ничего не зафиксировал письменно. Письменная фиксация необходима не только и не столько для последующего «разбора полетов», когда кто-то что-то не сделал, сколько для достижения четкости понимания. В отличие от разговора, когда часть общения происходит на невербальном (в частности — эмоциональном) уровне, сформулировать мысль в письменном виде сложно, не додумав ее. Кроме того, к записанной договоренности, задаче или проблеме можно легко вернуться, когда вы или ваш коллега найдет время, чтобы поработать над ней.<\/p>\n
Так как же дожимать до конкретики?<\/h2>\n
Это сложно: одна из самых ресурсоемких задач на совещании. Заложите на это время: где-то минут за 10 до окончания часового совещания можно уже начинать, если было много решений.
\nМы уже это обсуждали здесь<\/a>.<\/p>\nЗадачи должны быть сформулированы в совершенном виде, т. е. как ответ на вопрос: «Что сделать?», при этом желательно, чтобы при виде формулировки рисовалась в голове картинка.
\nНапример:<\/p>\n\n
❌ «Некорректные чеки!»
\n✅ «Назначить совещание “Разбор ошибок чеков коррекции”»<\/p>\n<\/blockquote>\n\n
❌ «Правила командной работы»
\n✅ «Выделить 30 минут, набросать предложения по правилам командной работы»<\/p>\n<\/blockquote>\nТакая постановка задачи сильно экономит «мыслетопливо». Это важно: в разгар рабочих будней, когда за ваше внимание борется десять разных задач, один взгляд на мутную, неясную формулировку вызывает отторжение и заставляет ее откладывать. Поэтому если вы правильно сформулируете задачу, это повысит вероятность ее исполнения.<\/p>\n
Для каждой задачи должен быть прописан срок и ответственный. Это как бы все знают, но на практике, когда все внимание уходит на то, чтобы привести группу к конкретным решениям, это еще один пункт, который надо дожимать, и на него может не хватить сил. Даже после стольких лет в проджект менеджменте у меня периодически такое случается. Помогает, если вы сразу вносите задачи в какую-то форму, например, табличку в экселе.<\/p>\n
Главное, что поможет внедрить этот навык: у вас должна сформироваться стойкая аллергия на любую неконкретность и размытость в итогах совещания. Можно прямо тупить: «Ребята, я наверное самый тормозной тут: все все поняли, но мне надо прям квадратно-гнездовым методом. Давайте в табличку запишем, а то я не догоняю, сорри». Пусть вас сначала ненавидят, чуть позже оценят.<\/p>\n", "date_published": "2022-02-22T18:26:37+00:00", "date_modified": "2022-02-22T18:33:34+00:00", "_date_published_rfc2822": "Tue, 22 Feb 2022 18:26:37 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "52", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "50", "url": "https:\/\/blog.skalon.me\/all\/prostye-principy-raboty-s-zadachami-dlya-postroeniya-nadezhnyh-s\/", "title": "Простые принципы работы с задачами для построения надежных систем управления", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/milestones@2x.png\")
\n<\/div>\nСвою консалтинговую карьеру я начинал в тайм-менеджменте больше 10 лет назад, и один из чудесных, простых и весьма результативных проектов, которые мы делали, был «Внедрение системы контроля поручений». Мы это делали средствами аутлука, но с тех пор я применял с десяток разных инструментов для настройки, включая комбо чат-бота и гугл таблиц, аутлук среди них удобен только повсеместностью и интеграцией с МС Офисом.<\/p>\n
Суть очень проста:<\/p>\n
- \n
- Настроить реестр, в котором хранятся все поручения менеджмента (или одного менеджера).<\/li>\n
- Настроить средство коммуникации по поручениям. В аутлуке можно слать отчеты по задачам, которые будут обновлять исходную задачу у автора (вы знали об этом?).<\/li>\n
- Обучить сотрудника, который все поручения будет вносить и контролировать по срокам. Обычно — ассистент руководителя.<\/li>\n
- Обучить людей, которые будут исполнять поручения.<\/li>\n<\/ol>\n
Как показала моя дальнейшая практика, помимо ИТ-настроек и обучения инструменту (как мы делали раньше), еще полезно очень конкретно описать ситуации, в которых на эти поручения будет смотреть руководство. А затем пару раз провести участников «за ручку» по повестке совещания, на котором рассматриваются поручения. Вот тогда инструмент работает просто отлично.<\/p>\n
Очень простой принцип, который позволяет двигать большие дела<\/h2>\n
Контроль поручений работает так хорошо за счет очень простого принципа:<\/p>\n
\n
Задача «попала на карандашик» — «вынь да положь» результат, или обоснуй, почему его нет<\/b><\/p>\n<\/blockquote>\n
Есть важное условие: руководство регулярно пользуется системой контроля поручений и требует от исполнителей результат. Почему это важно? На тренингах я всегда задаю вопрос: «Когда в школе вы знали, что учитель 100% спросит вас на следующем уроке, каковы были шансы, что вы сделаете домашку?» Обычно шанс близок к 100%. Со взрослыми работает точно так же.<\/p>\n
«Проверять домашку» удобнее всего на совещаниях. Если вы — высокоуровневый менеджер, то сбор информации с ответственных может делать секретарь. Правда, если у вас не жестко бюрократическая организация, я бы это оставил на крайний случай. Вопрос: «Ну что, где результат?» — гораздо убедительнее звучит в устной форме, сопровождаемый взглядом в глаза.<\/p>\n
Есть еще один удивительно простой и эффективный принцип, который запускает работу с поручениями в компании:<\/p>\n
\n
Нет просроченных поручений<\/b><\/p>\n<\/blockquote>\n
Точнее, нет открытых поручений, по которым прогнозный срок находится в прошлом. Напомню<\/a>, прогнозный срок — это коммуникация от исполнителя постановщику задачи. Прогнозный срок в прошлом — это «протухшая» информация. «Протухшая» информация по задаче означает, что исполнитель забил на коммуникацию. А это уже действие, которое подрывает всю систему, ведь если все забьют на коммуникацию, система умрет!<\/p>\n
И это кстати отличная метрика, показывающая «живость» системы для управления задачами: если в системе много открытых поручений с «протухшими» сроками, это значит, что ей не пользуются, не принимают решения на ее основе. Такой надежный индикатор — большая находка для менеджера.<\/p>\n
Ограничения контроля поручений<\/h2>\n
Благодаря простоте и неотвратимости, система контроля поручений — очень жесткий инструмент. В этом есть плюсы — чувство руля у руководителя, — но и минусы.<\/p>\n
Главный минус в том, что это инструмент «ручного управления». У меня был шеф, который так сыпал поручениями, только успевай ловить. Какое счастье, что он потом забывал процентов 70 из них, потому что иначе никто в компании ничем больше и не занимался бы, кроме отработки его поручений!<\/p>\n
Жесткость требует от людей быть в тонусе, но «быть в тонусе» отвлекает энергию от каких-то других вещей, которые руководитель часто не видит, и если слишком сильно закручивать поручения, обычно ломается где-то в другом, менее очевидном месте.<\/p>\n
Поэтому используйте контроль поручений мудро и очень дозированно.<\/p>\n
Не только контроль поручений<\/h2>\n
Как выяснилось, на этих простых принципах можно построить очень, очень большую систему.<\/p>\n
Если в плане проекта выделить ключевые вехи, то они могут превратиться примерно в те же самые поручения, только на весь проект у вас будет не две сотни работ, а семь-десять контрольных точек. Часть — для промежуточного контроля, часть — для итогового.<\/p>\n
Контрольные точки вносите в реестр и контролируете примерно так же, как поручения. Просрочилась маленькая промежуточная веха — задаем вопрос: «Что случилось? Не нужна ли помощь?».<\/p>\n
Если у вас сто проектов, по каждому из них 10 контрольных точек, то это 1000 контрольных точек. Предположим, что все проекты на год, это означает, что у вас примерно 80 контрольных точек в месяц. С контролем этих точек справится сравнительно небольшой проектный офис.<\/p>\n
Конечно, там миллион нюансов: правильно запланировать проекты, сделать контрольные точки проверяемыми, организовать приемку, наладить качественную регулярную отчетность и много других интересных задач. Однако принцип остается тем же самым, что и в системе контроля поручений: реестр, конкретные задачи и конкретные сроки, проверка исполнения, «нет просроченных поручений».<\/p>\n
Постараюсь в недалеком будущем рассказать кейс, как я настроил такую систему на экселе.<\/p>\n", "date_published": "2022-02-10T16:27:05+00:00", "date_modified": "2022-02-10T16:26:49+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/milestones@2x.png", "_date_published_rfc2822": "Thu, 10 Feb 2022 16:27:05 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "50", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/milestones@2x.png" ] } }, { "id": "48", "url": "https:\/\/blog.skalon.me\/all\/instrument-planirovaniya-kotory-ya-primenyayu-pochti-na-kazhdom\/", "title": "Инструмент планирования, который я применяю почти на каждом проекте", "content_html": "
Продолжаем разговор про планирование проекта. Составив в прошлый раз реестр результатов<\/a> мы определились, какие конкретные результаты будут созданы. Теперь надо наметить путь к ним. Это сложно:<\/p>\n
- \n
- Во-первых, проект по определению это что-то новое, и обычно довольно большое. Поэтому придумать, какие работы нужны для достижения отдаленных результатов требует большого количества мыслетоплива. Это мучительно.<\/li>\n
- Во-вторых, как только вы набрасываете большое количество работ, в них сразу же становится сложно ориентироваться, особенно — вашим бизнес-пользователям. Они будут вас игнорить, им будет сложно качественно проработать план, а виноват окажется руководитель проекта.<\/li>\n<\/ul>\n
И вот здесь хочу поделиться приемом, который не все применяют, а вернее, мало кто: прежде, чем набрасывать список работ, мы разработаем product flow diagram (инструмент из моего любимого PRINCE2, кстати). Не придумал, как это емко перевести на русский язык, приблизительно — диаграмма декомпозиции продукта проекта (помним, как отличаются и чем похожи результаты и продукты проекта<\/a>). Проще показать на примере.<\/p>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/PFD@2x.png.jpg\")
\n<\/div>\nЭто реальная диаграмма декомпозиции продукта одного из моих проектов. Мы получили ее в ходе нескольких сессий совместно с бизнес-пользователями. Каждое звено здесь — результат, продукт или промежуточный продукт проекта, а стрелочки показывают, что в какой очередности надо получать.<\/p>\n
Промежуточный продукт — это любой продукт, который не несет самостоятельной ценности для бизнеса, нужен только для создания какого-то другого продукта, но при этом его можно выделить как самостоятельный элемент.<\/p>\n
Например, двигатель не нужен пользователю сам по себе, но необходим, чтобы собрать готовый автомобиль. При этом мы можем отметить в плане, что двигатель будет готов в такой-то момент, и привязать к этому моменту следующие задачи в цепочке. Двигатель — промежуточный продукт, автомобиль — просто продукт или «итоговый продукт».<\/p>\n
Помимо того, что это просто красиво, это удобно:<\/p>\n
- \n
- Позволяет увидеть костяк плана, пока его не завалило отдельными работами. Это гораздо проще обсуждать с ключевыми пользователями. Диаграмму на иллюстрации все еще реально обсудить на одном совещании. План из 200+ работ можно только презентовать, со всеми ограничениями формата.<\/li>\n
- Промежуточные продукты — это важные вехи. Можно их использовать для планирования отдельных блоков работ: в крупных проектах их может создавать отдельная команда, а в маленьких они станут ключевыми результатами<\/a> в операционном плане.<\/li>\n
- К промежуточным результатам тоже можно описать требования. Это очень полезно, потому что на этом постоянно происходят срывы: команда разработки ждет от пользователей выгрузку данных текущих систем, выгрузка приходит, но в кривом формате. Проблема. Или команда разработки передает модули в тестирование, а пользователи не знают, с какой стороны к ним подходить: не прописали, что должен быть промежуточный продукт «сценарии тестирования», не заложили в план, не сделали.<\/li>\n<\/ul>\n
После того, как диаграмма декомпозиции разработана и согласована, на ее основе можно разрабатывать календарный план. Теперь это сделать гораздо проще, потому что есть уже костяк промежуточных продуктов, которые к вам гораздо ближе по времени, мельче и конкретнее.<\/p>\n
Диаграмму на картинке я разработал в программе Flying Logic Pro<\/a>. Программа удобна тем, что автоматически перестраивает диаграмму, чтобы минимизировать пересечения линий, а также позволяет сворачивать и разворачивать целые блоки на схеме. Если вам кажется, что это пустяки, попробуйте разработать схему из сотни блоков, после этого поговорим :) Также она позволяет готовую диаграмму экспортировать в МС Проджект. Правда, она платная, причем довольно сильно платная.<\/p>\n
Кроме этого приложения можно воспользоваться Миро<\/a> или другим приложением для разработки диаграмм. Не пользуйтесь пауэрпоинтом, проклянете и диаграмму, и меня, и себя.<\/p>\n", "date_published": "2022-02-01T18:28:48+00:00", "date_modified": "2022-02-01T18:26:28+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/PFD@2x.png.jpg", "_date_published_rfc2822": "Tue, 01 Feb 2022 18:28:48 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "48", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/PFD@2x.png.jpg" ] } }, { "id": "45", "url": "https:\/\/blog.skalon.me\/all\/instrument-kotory-pomozhet-vam-uderzhivat-fokus-na-rezultatah-pr\/", "title": "Инструмент, который поможет вам удерживать фокус на результатах проекта", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/resultsregistry@2x.png\")
\n<\/div>\nВ продолжение темы «бюрократии здорового человека<\/u>»<\/a> хочу рассказать об одной из своих любимых табличек: реестре результатов проекта. Это один из первых документов, с которого я начинаю разработку плана и управление требованиями. Удивительно, что вы не часто встретите его среди типовых шаблонов, которые рекомендуют эксперты, но я без него не обхожусь ни на одном проекте.<\/p>\n
Большая часть материала будет интересна менеджерам проектов, но я умудряюсь применять этот инструмент и для личного целеполагания. Правда, у меня может быть проф.деформация :)<\/p>\n
Чтобы управлять проектом нужна опись всего, что будет создано<\/h2>\n
Сначала расскажу небольшую историю.<\/p>\n
Я руководил большим проектом по изменению деятельности компании в соответствии с требованиями регулятора. Изменения затрагивали многие области: доработка документации по продуктам (сотни документов), изменение и переподписание договоров с партнерами (больше сотни договоров), доработка сайта, офисов компании, нескольких внутренних регламентов + массовое обучение для широких кругов сотрудников.<\/p>\n
Работая таким широким фронтом впервые, я столкнулся с тем, что разные направления «разъезжаются»:<\/p>\n
- \n
- по ним работают разные группы людей с разной долей автономии: кто-то почти все делает сам, кого-то надо микроменеджерить,<\/li>\n
- понимание, как правильнее выполнить требования закона постоянно уточняется\/меняется,<\/li>\n
- много направлений сложно удерживать в голове,<\/li>\n
- как следствие, мне невероятно сложно поддерживать фокус на результатах проекта: вроде уже думаешь все готово, а потом — бац! — забыли какой-то из документов обновить, потому что юристы поздно сказали, что его тоже надо делать.<\/li>\n<\/ul>\n
Анализируя свой опыт я понял, что:<\/p>\n
- \n
- Мне очень не хватало актуальной рабочей описи всего, что должно быть создано в по итогу проекта, которую мы бы регулярно смотрели\/актуализировали вместе со всеми участниками.<\/li>\n
- Мне надо было делегировать часть ответственности за консолидацию требований и сборку итогового результата.<\/li>\n<\/ol>\n
Именно с этой целью я разработал реестр результатов, который мне очень помог уже на следующем проекте.<\/p>\n
Сначала — согласовать образ конечного результата<\/h2>\n
Вообще, планирование проекта, конечно, начинается с паспорта. О нем я еще расскажу, но если в двух словах, там содержится самая важная информация о целеполагании проекта и отведенных на него ресурсах. Когда с целеполаганием определились, надо согласовать, что конкретно будет создано в ходе проекта<\/a>.<\/p>\n
Когда я впервые приступаю к заполнению реестра результатов с коллегами, я предлагаю им представить следующую картину: «Вот мы закончили проект. Приходим довольные к руководству и кладем на стол толстую папку с результатами: „Мы сделали“. Что в этой папке?» По опыту, этот вопрос очень помогает начать разговор.<\/p>\n
В качестве примера возьмем проект по внедрению CRM (система в которой работают продавцы) за сто миллионов рублей, хранящий миллионы записей о клиентах компании. Для каждого из результатов проекта описываем:<\/p>\n
- \n
- Название и расширенное описание. Например: «Модуль предиктивной аналитики». Расширенное описание: «Модуль, позволяющий на базе собранных данных сегментировать клиентов, выделять среди них группы по предпочтениям, а также прогнозировать спрос».<\/li>\n
- Формат. Что собой будет представлять результат? Если с модулем предиктивной аналитики более-менее понятно, что это «Модуль ИТ системы», то с инструкциями к системе уже больше нюансов. Полезно сразу обсудить, что это будут страницы в корпоративной вики, а не пдф.<\/li>\n
- Требования к результату. Здесь фиксируем ключевые требования: пожелания руководства, ключевых пользователей. Например: «Модуль должен предусматривать интеграцию с соц.сетями и анализ клиентских данных из соцсетей». Сразу замечу, что для полномасштабного управления требованиями нужны другие инструменты. В реестре результатов — только основные, но это уже очень полезно документировать и обсудить.<\/li>\n
- Поставщик. Сюда пишем тех, кто «работает руками» над получением этого результата. В нашем случае это может быть подрядчик и наш департамент ИТ.<\/li>\n
- Ключевые пользователи. Это те, кто выдвигает требования к результату и участвует в приемке. Для модуля предиктивной аналитики CRM системы это, скорее всего, отдел маркетинга.<\/li>\n
- Владелец результата. Вот здесь уже менее очевидный момент. Дело в том, что назначить «Ответственного» за результат бывает сложно: если в создании участвует пять человек, то каждый из них скорее всего будет сопротивляться, чтобы его назначили единственным ответственным. Поэтому я сформулировал роль «Владельца» как «единое окно» по данному результату, и он координирует все активности, связанные с его достижением. Это может быть любой из участников команды, но скорее всего — кто-то из ключевых пользователей.<\/li>\n
- Процедура приемки. Договариваемся о том, как будет происходить приемка. Здесь будет полезно написать, например, что регламент должен помимо ключевых пользователей согласовать еще и Департамент внутреннего контроля. Или что данный документ надо будет нести биг боссу, а для этого перекладывать его основные тезисы на слайды.<\/li>\n<\/ol>\n
Реестр результатов должен жить на протяжении всего проекта<\/h2>\n
Итак, мы описали все результаты проекта. Что теперь с ними делать?<\/p>\n
Планировать проект дальше.<\/b> Дальше мы декомпозируем итоговые результаты на промежуточные, для них определим работы и постепенно придем к календарному плану. Об этом я расскажу в одной из следующих статей.<\/p>\n
Проводить аудит результатов.<\/b> Очень полезно в ходе проекта задаваться вопросом, насколько мы продвинулись. Для этого можно добавить в реестр столбец «статус». Особенно это полезно делать, если вы консультант: когда вы приходите к заказчику с предложением подписать на следующей неделе акты, это лучший способ спровоцировать волну комментариев и отличных идей по доработке, которых так не хватало, пока вы работали над этим результатом. Аудит готовности позволит начать этот разговор сильно раньше: «Мы считаем, что этот результат готов на 50%». «А мы — что на 15%!».<\/p>\n
Опись результатов проекта.<\/b> У меня была отличная практика: когда на моем проекте работали консультанты, мы каждому результату присвоили уникальный код — типа РН-001П — и договорились о том, что все письма, в которых они нам передают те или иные результаты, будут содержать этот код. Благодаря этому я мог мгновенно найти в почте всю релевантную переписку, а после проекта все результаты лежали в кодированных папочках, а реестр результатов превратился в опись.<\/p>\n
В общем, прошу любить и жаловать реестр результатов. Отличный инструмент, странно, почему так редко его встречаю. Если надо, могу скинуть проверенный шаблончик. Пишите в Телегу<\/a>.<\/p>\n", "date_published": "2022-01-18T19:19:20+00:00", "date_modified": "2022-01-18T19:19:13+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/resultsregistry@2x.png", "_date_published_rfc2822": "Tue, 18 Jan 2022 19:19:20 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "45", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/resultsregistry@2x.png" ] } }, { "id": "41", "url": "https:\/\/blog.skalon.me\/all\/proektnaya-byurokratiya-zdorovogo-cheloveka\/", "title": "Проектная бюрократия здорового человека", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/bureaucrat@2x.png\")
\n<\/div>\nМногие ненавидят бюрократию. Заполнение любых бумажек таким людям кажется насилием над естеством, пустой тратой времени. К сожалению или к счастью, но управление проектами в большинстве случаев связано с большим количеством документации.<\/p>\n
Практически каждый раз, внедряя систему проектного управления в очередной компании, мы начинаем с того, что заказчик предлагает нам «сократить бюрократию», обойтись минимумом документов, и испытывает чувство вины, заставляя своих коллег заполнять уставы, реестры результатов, запросы на изменения и прочие чудесные документы. Да что там, я сам начал именно с этого: с чувства вины за «бюрократизацию» и стремления минимизировать количество бумажек.<\/p>\n
Однако с опытом приходит понимание, что есть некоторый «здоровый уровень бюрократии», который помогает радикально повысить качество управления проектами, и инвестиции в документирование проекта часто окупаются, причем многократно. Сегодня разберемся, как.<\/p>\n
Документ как чек-лист<\/h2>\n
Давайте для начала посмотрим на содержание какого-нибудь управленческого документа проекта.<\/p>\n
\n
Кстати, «управленческий документ» означает документ, который используется для управления проектом. Например, нужен, чтобы зафиксировать, кто за что отвечает в процессе управления, или результаты проекта<\/a>. А бывают еще документы, которые разрабатываются для других целей: инструкции к системе, регламенты, договоры с подрядчиками и пр.<\/i><\/p>\n<\/blockquote>\n
Возьмем, например, кусочек документа под названием «стратегия коммуникации».<\/p>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/registry@2x.png.jpg\")
\n<\/div>\nЧто мы видим? Таблица, в которой надо заполнить все ячейки по принципу «природа не терпит пустоты». При этом важно не только и не столько то, что мы их заполнили, а то, что мы обо всем этом подумали<\/i>.<\/p>\n
И вот здесь как раз кроется первый ключ к пониманию того, что собой представляет «бюрократия здорового человека». Заполнить управленческий документ означает подумать обо всем, о чем надо подумать. То есть, вы можете воспринимать документ как своего рода чек-лист, чтобы ничего не забыть.<\/p>\n
Почему нельзя просто задать один вопрос: «опишите, зачем нужен проект», — вместо того, чтобы заполнять в паспорте проекта «решаемые проблемы», «результаты» и «выгоды»? Ответ — можно, но качество ответов на этот вопрос очень сложно прогнозировать. Даже вы сами ответите на него по-разному в зависимости от вашего внутреннего состояния, запаренности в данный момент и кучи других факторов. Не говорю уже о разных руководителях проекта, которые в компании должны дать единообразный результат.<\/p>\n
Вот недавно мы как раз смотрели документ, в котором «зачем нужен проект» описано в одном поле, и выяснили, что руководитель проекта описал массу показателей, но забыл описать собственно проблему, на решение которой нацелен проект. Упс.<\/p>\n
Договориться и зафиксировать договоренности<\/h2>\n
Когда я объясняю на консультациях, как заполнять критерии завершения проекта, я говорю: представьте, что на основании написанного вы требуете, чтобы вам заплатили деньги, а вам не хотят платить. Как и с юридическими документами, четкие формулировки нужнее всего не в ситуации, когда все хорошо, а в спорных моментах.<\/p>\n
Чтобы понять, зачем нужен паспорт проекта, мы всегда приводим метафору: «паспорт проекта = договор между компанией и командой проекта». Думаю, все прекрасно понимают, что значит работать без договора: в каких-то случаях это прокатывает, но в каких-то ты попадаешь на кучу головняков.<\/p>\n
Поэтому обычно потратить силы на то, чтобы договориться по каждому из существенных моментов, а также закрепить эти договоренности — не лишняя трата времени.<\/p>\n
Ничего не потерять<\/h2>\n
Управляя большим проектом невозможно держать все в голове. Надо учитывать огромное количество вещей: требования заинтересованных сторон, поручения, запланированные действия, риски, открытые вопросы, документы с подрядчиками — я не перечислил и десятой доли того, что можно планировать, отслеживать статус, делегировать и т. п.<\/p>\n
Поэтому хочешь не хочешь, все это надо куда-то записывать и вести. Конечно, для управления проектами есть масса ИТ систем, но гораздо чаще, чем можно представить в наш век ноу-кода и изобилия всевозможных трекеров, вы будете пользоваться простой экселькой или гугл таблицами.<\/p>\n
Как сделать так, чтобы бюрократия не превращалась в бюрократизм?<\/h2>\n
Давайте представим, что вы попросили меня нарубить дров. Надо ли нам писать документ, чтобы согласовать образ конечного результата? В лучшем случае я уточню, где брать топор и куда класть нарубленные дрова. А если вы заказываете мне постройку ядерной электростанции? Думаю, мы нагенерим как минимум средних размеров вагон документации.<\/p>\n
Так вот, первое правило: детализация должна соответствовать сложности проекта.<\/p>\n
Другой важный момент заключается в том, что каждое поле должно использоваться. Помню, мой наставник по проектному управлению, который помогал мне сделать первые шаги в качестве руководителя проектного офиса, сказал: «Если какую-то информацию ты не используешь, ты не имеешь права ее запрашивать!». Этой максимой я с тех пор и руководствуюсь. К сожалению, понимание, что потребуется, а что — лишнее, нарабатывается в основном с опытом.<\/p>\n
И все же, когда вы будете с ненавистью смотреть на очередной документ по своему проекту, подумайте о том, что будет глупо сэкономить пусть даже 40 человекочасов на проработке документации на старте, чтобы ближе к концу проекта влететь на лишних пару месяцев работы всей команды из-за того, что вы не учли важнейший аспект или не раскрыли требование заказчика.<\/p>\n", "date_published": "2021-12-20T19:32:38+00:00", "date_modified": "2021-12-21T07:32:24+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/bureaucrat@2x.png", "_date_published_rfc2822": "Mon, 20 Dec 2021 19:32:38 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "41", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/bureaucrat@2x.png", "https:\/\/blog.skalon.me\/pictures\/registry@2x.png.jpg" ] } }, { "id": "39", "url": "https:\/\/blog.skalon.me\/all\/kak-ukazyvat-sroki-v-proektah-kogda-nihrena-ne-ponyatno-neskolko\/", "title": "Как указывать сроки в проектах, когда нихрена не понятно? Несколько полезных лайфхаков", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/waveplanning@2x.png\")
\n<\/div>\nОчень часто, когда я занимаюсь с командами планированием проекта — в качестве руководителя проекта или «играющего тренера», — возникает проблема с планированием сроков. Дескать, как можно прогнозировать какой-то срок по проекту, когда непонятно, что делать? С другой стороны, мы же не можем поставить в плане «ХЗ пока».<\/p>\n
Оставим в стороне гибкие методики управления проектами, которые вместо планирования предлагают быструю адаптацию к меняющимся условиям. Есть проекты, в которых сроки все-таки важны, и их надо планировать, но уровень неопределенности не позволяет.<\/p>\n
Так как же быть?<\/p>\n
Два вида сроков<\/h2>\n
В этой ситуации я всегда сначала объясняю, что на самом деле существует два вида сроков:<\/p>\n
«Когда можем»<\/b> — это технологически и ресурсно обусловленный срок. Мы понимаем, что нужно сделать и какие ресурсы доступны. Это позволяет нам сказать: окей, мы выполним эту работу к такому-то числу.<\/p>\n
«Когда надо»<\/b> — это срок, к которому необходимо получить результат. Например, мы точно знаем, какого числа должна начаться олимпиада. Или когда должны стартовать продажи нового товара. Нарушение этого срока ведет к убыткам, порой — огромным, как в случае с олимпиадой, поэтому на самом деле он является элементом обоснования целесообразности проекта.<\/p>\n
Мне рассказывали про одного члена Правления банка, который говорил: «Не можете сказать срок? Тогда я вам скажу срок!».<\/p>\n
Начинаем «крупными мазками»<\/h2>\n
Второй нюанс заключается в том, что проект можно планировать, постепенно повышая точность. Более того, в моем любимом PRINCE2 (британская методология управления проектами) это вообще способ по умолчанию. В других источниках это называется «метод набегающей волны».<\/p>\n
Вы планируете весь проект «крупными мазками», приблизительно. Набрасываете основные этапы, даты, когда нужно получить ключевые результаты. Можно пользоваться достаточно грубыми предпосылками.<\/p>\n
А вот ближайший этап вы планируете уже тщательно. При этом не забываете добавить в этап работы по планированию следующего этапа и уточнению плана всего проекта.<\/p>\n
Срок — это принятие обязательств «со звездочкой»<\/h2>\n
Если вы работали в гос.органах или в гос.компаниях, возможно вы сейчас подумали: «Ага, я скажу предварительный срок, а мне потом его „пришьют“. Нет уж, спасибо!». Действительно, такое бывает. Здесь уже надо включать мастерство управления ожиданиями заинтересованных сторон.<\/p>\n
Во-первых, поможет, если вы покажете конкретные сроки на ближайший период, и объясните, когда повысится точность дальнейших планов. Обычно руководство нормально относится к такому подходу: это все-таки подконтрольная ситуация и есть следующие шаги по снижению неопределенности.<\/p>\n
Во-вторых, если установлен жесткий срок «когда надо» для всего проекта, не терпящий никакой приблизительности, у вас остается вариант управлять содержанием и (иногда) бюджетом. Надо тут же на берегу договориться, что в этой ситуации приблизительными будут требования к результатам проекта: не будем успевать — придется что-то «отрезать».<\/p>\n
Сроки — не самое важное<\/h2>\n
К сожалению, есть руководители, которых не устраивает ни один из этих вариантов, считающие, что если сильно надавить, можно «впихнуть невпихуемое». Обычно это приводит к «выпихиванию ранее впихнутого», и, если заказчик сильно давит, это происходит в скрытом режиме и приводит к тому, что рвется что-то совсем в другом, неожиданном месте.<\/p>\n
Конечно, бежать к четким срокам чаще всего правильно: это позволяет не перерасходовать ресурсы, держать в тонусе команду и заказчиков, быстрее получать бизнес-результаты. Но это далеко не всегда так.<\/p>\n
Большое количество ИТ проектов оказывается неуспешным именно из-за недостаточных сроков: приходится жертвовать важными требованиями, архитектурой, наращивать технический долг, что приводит к появлению неприменимых решений.<\/p>\n
Поэтому гораздо более полезным критерием успешности проекта является «счастливый заказчик». Заказчик обычно счастлив, если результаты проекта принесли ту ценность, ради которой он задумывался<\/a>, при этом соблюдается приемлемое соотношение «вэлью фо мани».<\/p>\n
Ну и, конечно, важно помнить, что счастье заказчика = результаты — ожидания заказчика.<\/p>\n", "date_published": "2021-12-14T18:24:09+00:00", "date_modified": "2021-12-14T18:25:21+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/waveplanning@2x.png", "_date_published_rfc2822": "Tue, 14 Dec 2021 18:24:09 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "39", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/waveplanning@2x.png" ] } }, { "id": "36", "url": "https:\/\/blog.skalon.me\/all\/ya-otlichno-rukovozhu-proektami-bez-celi-kak-eto-poluchaetsya\/", "title": "Я отлично руковожу проектами без «цели». Как это получается?", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/goal@2x.png\")
\n<\/div>\nОдна из первых вещей, которая приходит в голову, когда мы планируем проект, или даже говорим о проектах, это цели. Иногда — «цели и задачи». Так вот, сегодня шокирующее откровение: я прекрасно обхожусь без «целей» проектов. И тем более, без «целей и задач проектов». Как так получается — рассказываю в сегодняшнем посте.<\/p>\n
У всех разное понимание того, что такое «цель»<\/h2>\n
Для начала расскажу случай из практики.<\/p>\n
\n
Мы запускаем портфель проектов по организационным изменениям в компании: есть стратегия СЕО, все подразделения готовят проекты. Я отвечаю за то, чтобы в каждом из проектов было корректно сформулировано, какие цели он преследует, каким образом и пр.<\/p>\n<\/blockquote>\n
\n
Мы с руководителями подразделений разрабатываем паспорта проектов, пишем в них цели, бьемся над ними по несколько часов. Приносим СЕО, и он нас разносит, буквально каждый раз. Я не понимаю, что происходит.<\/p>\n<\/blockquote>\n
\n
Так продолжалось довольно долго (слишком долго). В какой-то мы обсуждаем с шефом эту проблему, и выясняется, что мы никак не можем договориться о том, что собой представляют цели проекта (в ту пору я много спорил с шефом<\/a>). В какой-то момент ему пришла в голову идея нарисовать на доске схему, что мы понимаем под «целью», и выяснилось, что я понимаю под целями проекта то, что будет создано в рамках проекта, а он — то, ради чего проект в принципе делается, и что может выходить далеко за рамки проекта.<\/p>\n<\/blockquote>\n
Это был первый раз, когда я понял, что «цели» — очень, очень размытый термин, но с тех пор я убеждался в этом неоднократно. Правда я не сразу разобрался, как с этим быть.<\/p>\n
Так как же быть?<\/h2>\n
То, что получается в итоге и благодаря проекту, можно разделить на следующие группы (объясняю по-простому, методологов прошу заткнуть уши):<\/p>\n
- \n
- Продукт проекта. Это то, что непосредственно создается в ходе проекта. Какие-то физические объекты или материалы в электронном виде. Например, если мы разрабатываем новую версию сайта, продуктом проекта будут скорее всего элементы сайта (в зависимости от того, как нам удобнее управлять): отдельные страницы, онлайн-калькулятор, форма заказа — то есть, те элементы, которые мы можем разработать и передать в эксплуатацию цельными кусками. Или, например, выкинуть из проекта (хотя бы в теории).<\/li>\n
- Результаты проекта. Это изменение каких-то показателей, которое произошло благодаря сайту. Например, увеличение просмотров страниц (по сравнению со старым сайтом), показов рекламы, скорости регистрации\/покупки — то есть, улучшение процесса, которое произошло благодаря применению продукта проекта.<\/li>\n
- Выгоды проекта. Это измеримое улучшение бизнес-показателей, которое произошло благодаря результатам проекта. Выгоды чаще всего про деньги: прибыль, выручка, сокращение издержек. Иногда — увеличение доли рынка или иных показателей. В чем разница с результатами? Выгоды — это то, ради чего компания делает проект. Просмотры страниц вы «на хлеб не намажете»: обычно заказчик ожидает, что благодаря просмотрам вырастут какие-то финансовые показатели. Даже если вы делаете сайт-визитку, его тоже лучше привязывать к каким-то значимым и измеримым бизнес-показателям. Иногда это сделать сложно, но важно пытаться и задавать себе этот вопрос.<\/li>\n<\/ol>\n
Только если мы понимаем, ради чего мы делаем сайт (выгоды), за счет чего мы их получим (результаты) и что конкретно будет для этого создано в проекте (продукт), мы можем быть уверены, что определились с целеполаганием проекта.<\/p>\n
Обратите внимание: в описанной схеме нет такого понятия как «цели проекта». Потому что «выгоды», «результаты» и «продукт» гораздо точнее и позволяют определить, что и ради чего мы делаем.<\/p>\n
Знаю, что различие между этими терминами тяжело заходит, поэтому давайте на закрепление еще один пример. Проект «Внедрение CRM системы» (это система, где продавцы работают и ведут информацию о всех клиентах):<\/p>\n
- \n
- Продукт:<\/b> сама CRM система. Для удобства управления мы скорее всего поделим ее на модули: ключевой функционал, интеграция с соцсетями, интеграция с АТС и т. п.<\/li>\n
- Результат:<\/b> увеличилось количество звонков, увеличилось количество коммерческих встреч на продавца.<\/li>\n
- Выгоды:<\/b> увеличилась выручка компании.<\/li>\n<\/ul>\n
P.S.: А «Цели и задачи» вообще приехали из наших студенческих времен, когда мы писали курсовые. «Задачи» в проектном управлении есть, но означает совсем другое: в принципе то, что делается в рамках проекта, и «задач» могут быть сотни и тысячи. Точно не подходит для целеполагания всего проекта.<\/p>\n
P.P.S.: Предупреждаю: множество лучших умов в области проектной методологии сломали десятки копий над русскоязычной терминологией в этом вопросе. Я привел свою версию, но на всякий случай приведу английскую, с которой таких вопросов нет: output (продукт), outcome (результат), benefits (выгоды).<\/i><\/p>\n", "date_published": "2021-12-10T20:16:15+00:00", "date_modified": "2023-08-12T09:56:46+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/goal@2x.png", "_date_published_rfc2822": "Fri, 10 Dec 2021 20:16:15 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "36", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/goal@2x.png" ] } }, { "id": "31", "url": "https:\/\/blog.skalon.me\/all\/keys-organizaciya-ispolneniya-mnozhestva-odnotipnyh-zadach-na-ek\/", "title": "Кейс: организация исполнения множества однотипных задач на экселе (вариант 2)", "content_html": "
В отличие от предыдущего кейса<\/a>, в этот раз у меня один департамент делал несколько сотен однотипных задач (обновлял документацию по продуктам компании).<\/p>\n
Задача<\/h2>\n
Компания должна обновить несколько сотен документов, сгруппированных в комплекты, в соответствии с требованиями законодательства. Необходимо организовать мониторинг хода исполнения, а также спрогнозировать срок окончания в зависимости от объема выделяемых ресурсов.<\/p>\n
Решение<\/h2>\n
Настраиваю форму для заполнения<\/i> ответственными:<\/p>\n
\n![\"Таблица](\"https:\/\/blog.skalon.me\/pictures\/tablefill@2x.png.jpg\")
\n<\/div>\nВ столбцы таблицы — стадия разработки комплекта документации, строками — комплекты документации. На пересечении — статус «1» = «в работе», «2» = «готово», «3» = «Проблема!». Для «3» необходимо заполнить комментарий, незаполненный комментарий подсвечивается красным.
\nВ скрытых столбцах с начальником управления проставили оценочные трудозатраты по каждой из стадий разработки.<\/p>\nНа основе данных из первой таблицы строится аналитический свод<\/i>:<\/p>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/tablereport@2x.png\")
\n<\/div>\nСуммирую показатели с формы для заполнения. «∆» отражает разницу между текущим и предыдущим периодом (предыдущий период заполняется вручную из прошлого отчета методом «контрол ц, контрол в»).<\/p>\n
Для оценки объема трудозатрат перемножаю незаконченные стадии на трудозатраты, суммирую в совокупные человекочасы. Сопоставляю три сценария, отличающиеся объемом выделения ресурсов: «Если мы выделим на это 100% трех человек, когда мы закончим?» Текущий прогноз сравнивается с утвержденным планом, считается отклонение в днях. То есть, когда-то мы оценили, что закончим пятого июня. По мере того, как мы продвигаемся, мы видим, как изменяется эта оценка. Это позволяет нам заметить, что мы начинаем отставать от графика. Это, в свою очередь, может свидетельствовать о том, что мы выделяем недостаточно ресурсов.<\/p>\n
Процесс<\/h2>\n
Раз в неделю прошу ответственных заполнить информацию о статусе разработки документации. Заполнение занимает пару минут.
\nКопирую данные из предыдущего отчета для расчета отклонения («∆»).
\nСкриншот отчета отправляю руководству с комментариями, если что-то необычное.<\/p>\nРезультаты<\/h2>\n
Благодаря этой эксельке мы могли вести аргументированный разговор «на фактах»:<\/p>\n
- \n
- Добавить или урезать ресурсы на работу.<\/li>\n
- Почему прогресс отличается от ожидаемого.<\/li>\n
- Когда мы закончим с этой задачей.<\/li>\n
- Почему буксуют те или иные отдельные работы.<\/li>\n<\/ol>\n",
"date_published": "2021-12-05T18:37:06+00:00",
"date_modified": "2021-12-07T07:39:11+00:00",
"image": "https:\/\/blog.skalon.me\/pictures\/tablefill@2x.png.jpg",
"_date_published_rfc2822": "Sun, 05 Dec 2021 18:37:06 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "31",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/blog.skalon.me\/pictures\/tablefill@2x.png.jpg",
"https:\/\/blog.skalon.me\/pictures\/tablereport@2x.png"
]
}
},
{
"id": "30",
"url": "https:\/\/blog.skalon.me\/all\/chetkaya-peredacha-pasa-v-kommunikacii-pozvolyaet-ekonomit-uymu\/",
"title": "Четкая «передача паса» в коммуникации позволяет экономить уйму времени. Как?",
"content_html": "\n
![\"\"](\"https:\/\/blog.skalon.me\/pictures\/toaction@2x.png\")
\n<\/div>\nОчень важная привычка, которую должен развить у себя каждый, кто пишет деловые письма, это оценивать, насколько его письма побуждают к конкретным действиям. Поясню на примере, что я имею в виду.<\/p>\n
\n
Я поставил встречу с коллегой заранее. В день встречи приходит ответ на встречу «под вопросом» без дополнительных комментариев.<\/p>\n<\/blockquote>\n
\n
Пишу письмо: «Чувак, когда будешь знать точно? Встреча с внешним участником, надо его сориентировать».<\/p>\n<\/blockquote>\n
\n
Коллега: «Знаю точно, встречу переносим». Опять без дополнительных комментариев, при этом календарь в аутлуке он нормально не ведет, и мне приходится ему еще писать, затем звонить, отрывать от работы, договариваться о встрече.<\/p>\n<\/blockquote>\n
Что происходит? Коллега, разумеется, в запаре, и пишет мне письмо на айфоне левой пяткой, сидя на другом совещании, но ведь он таким образом создает себе лишний головняк на пустом месте. Сэкономил 20 секунд, получил еще два письма, лишний созвон, потратил мое время.<\/p>\n
Вместо этого он мог написать в сообщении об отмене встречи: «Вася, сегодня отбой, сорри. Предлагаю завтра до 11 или после 16 ч.». Все!<\/p>\n
Кто-то может сказать: «Да ладно, Вася, это же всего лишь 20 секунд против двух минут». К сожалению, когда мы это умножаем на количество писем в день, получается уже неплохо. А если мы к этому добавляем задачи, которые не сделаны (не сделаны вовремя), потому что было неясно, чего хотят от исполнителя, то масштабы проблемы подрастают. На уровне корпоративной культуры это вообще приобретает характер стихийного бедствия.<\/p>\n
Чтобы избегать таких ситуаций, надо каждое сообщение оценивать:<\/p>\n
- \n
- Чего я хочу от респондента? Любая коммуникация (любая!!!) имеет своей целью кого-то к чему-то побудить, даже информационная рассылка.<\/li>\n
- Сможет ли респондент предпринять конкретные действия на основе моего письма? Если нет, ваше письмо будет либо проигнорировано, либо вам будут задавать дополнительные вопросы. Конечно, даже идеально составленное алгоритмическое письмо может быть проигнорировано, но мутное письмо требует гораздо большей мотивации получателя, чтобы его прочли.<\/li>\n<\/ol>\n
П.2 на практике проще сказать, чем сделать. По моим наблюдениям, «конкретность» требует большого навыка. Попробуйте для тренировки визуализировать, что конкретно человек пойдет делать после получения письма: вот он встал и пошел куда-то, что-то сказал, получил какой-то ответ, пришел обратно, написал вам.<\/p>\n", "date_published": "2021-12-04T18:56:51+00:00", "date_modified": "2021-12-04T18:56:18+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/toaction@2x.png", "_date_published_rfc2822": "Sat, 04 Dec 2021 18:56:51 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "30", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/toaction@2x.png" ] } }, { "id": "27", "url": "https:\/\/blog.skalon.me\/all\/keys-organizaciya-ispolneniya-mnozhestva-odnotipnyh-zadach-pri-p\/", "title": "Кейс: организация исполнения множества однотипных задач при помощи экселя", "content_html": "
Как я уже рассказывал ранее<\/a>, прозрачная отчетность о прогрессе может творить чудеса. И для этой отчетности часто не нужна сложная автоматизация, достаточно подручного экселя. Сегодня небольшой кейс из практики.<\/p>\n
Задача<\/h2>\n
С большим количеством (>100) внешних организаций подписать дополнительные соглашения, проконтролировать размещение информации на их сайтах, обучить их сотрудников и т. п. Это взаимодействие контролируют три департамента внутри компании. Необходим механизм контроля исполнения, потому что ответственные от департаментов не очень жаждут заниматься подписанием доп. соглашений — для них это чистая нагрузка к основной работе.<\/p>\n
Решение<\/h2>\n
Разрабатываю форму для заполнения<\/b> ответственными департаментами:<\/p>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/form@2x.png.jpg\")
\n<\/div>\nВ столбцы таблицы — необходимые действия, строками — партнеров. На пересечении — статус «1» = «в работе», «2» = «готово», «3» = «Проблема!», «—» = «не применимо». Для «3» и «—» необходимо заполнить комментарий. В общей сложности, три формы для заполнения тремя ответственными на трех листах.<\/p>\n
Пилю аналитический свод:<\/p>\n
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/report@2x.png\")
\n<\/div>\nСуммирую показатели с трех форм для заполнения по каждому из направлений работы. Из суммы вычитаются статусы «—».
\n∆ отражает разницу между текущим и предыдущим периодом (предыдущий период заполняется вручную из прошлого отчета методом «контрол ц, контрол в»). Благодаря этому видно, какой был прогресс за прошедший период, кто — молодец, а кто нифига не делал.<\/p>\nИтоговый процесс:<\/h2>\n
Формы для заполнения рассылаются ответственным раз в период. Заполнение непосредственно формы в экселе занимает у ответственного пару минут, не считая сбора информации о статусе (но в этом отчасти и была цель опроса).
\nПолученные данные вставляются в итоговую таблицу методом «контрол ц, контрол в», заодно уточняются детали.
\nСкриншот обновленного отчета отправляется руководству в почте.<\/p>\nЭтими отчетами мы пользовались на всем протяжении данного блока работ. В какой-то момент можно собрать историю еженедельных отчетов и построить кривые в динамике.<\/p>\n", "date_published": "2021-12-01T19:26:36+00:00", "date_modified": "2021-12-01T19:28:48+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/analitycs@2x.png.jpg", "_date_published_rfc2822": "Wed, 01 Dec 2021 19:26:36 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "27", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/analitycs@2x.png.jpg", "https:\/\/blog.skalon.me\/pictures\/form@2x.png.jpg", "https:\/\/blog.skalon.me\/pictures\/report@2x.png" ] } }, { "id": "26", "url": "https:\/\/blog.skalon.me\/all\/para-priemov-pozvolyayuschih-zamoderirovat-dazhe-slozhnoe-sovesc\/", "title": "Пара приемов, позволяющих замодерировать даже сложное совещание", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/stages1@2x.png\")
\n<\/div>\nВ совещании, посвященном поиску решений, можно выделить несколько стадий (разные авторы по-разному), понимание которых поможет вам сориентироваться в совещании и, с одной стороны, не допустить, чтобы оно прошло безрезультатно, с другой — не перемодерировать его, дать участникам свободно пообщаться.<\/p>\n
Стадия «Синхронизация» — целеполагание встречи<\/h2>\n
В начале совещания обязательно надо проговорить цели встречи, повестку, желаемый результат. Для кого-то это может прозвучать тривиально, но я на удивление редко встречаю, чтобы кто-нибудь так делал. В крайнем случае — на ответственных совещаниях с руководством. А зря.<\/p>\n
Во-первых, участники могли уже позабыть, о чем вообще речь. Даже если вы отлично подготовили совещание, у них могло две минуты назад кончиться другое, и погрузить их в контекст будет просто человечно.<\/p>\n
Во-вторых, вы даете шанс участникам внести предложения по содержанию обсуждения. Это важно не только для того, чтобы повестка была актуальна для всех, но и для того, чтобы дополнительно легитимировать ее (сейчас расскажу подробнее).<\/p>\n
Также на данной стадии полезно договориться о формате обсуждения. Что это будет: свободная дискуссия? Стикеры в Миро? Высказывание позиции по очереди, затем дискуссия? Если вы предложили формат и все согласились, это очень поможет вам в дальнейшем модерировать дискуссию.<\/p>\n
Еще на «синхронизации» могут быть вводные доклады, например, описание проблемной ситуации, предыстории и пр.<\/p>\n
Стадия «Расхождение» — максимальная свобода в рамках повестки<\/h2>\n
На этой стадии происходит свободная или модерируемая дискуссия. По моему опыту, на рабочих встречах участники часто ценят просто удовольствие от потока разговора, и на этой стадии я стараюсь никого не загонять в жесткие рамки, чтобы не вызвать ощущение гонки или чрезмерной строгости. Даже если идет небольшое отвлечение от темы, я не спешу прерывать. Порой это даже помогает найти решение.<\/p>\n
Если вы чувствуете, что дискуссия идет конкретно не туда, хорошо подходят мягкие техники фасилитации, типа «шесть шляп мышления» Де Боно<\/a> (кстати, слышал про нее давно, а попробовал применять только недавно — и не пожалел).<\/p>\n
Конечно, выбор приемов на этой стадии зависит от культуры совещаний в организации, от темы и от вашего стиля.<\/p>\n
Стадия «Схождение» — концентрация смыслов и ценности<\/h2>\n
Где-то немного за середину совещания пора закруглять дискуссию и фокусировать участников на целях встречи. Здесь полезно сделать промежуточное резюме: что обсудили, какие выявили противоречия, какие основные идеи.<\/p>\n
После этого я деликатно, но настойчиво начинаю вести совещание к результатам. Иной раз это непросто, если дискуссия жаркая, или участники сильно выше вас в организационной иерархии. И вот тут как раз пригождается целеполагание, о котором мы договорились в начале встречи. Делюсь отличным приемом, который помогает замодерировать даже жаркую дискуссию членов Правления, будучи обычным проджект менеджером.<\/p>\n
Я говорю примерно следующее:<\/p>\n
— Коллеги, позволю себе вклиниться на правах модератора. — Если это стандартное рабочее совещание. Если это высокопоставленные участники, то я сначала прошу реплику, буквально в этой формулировке: «Прошу реплику» — лучше всего работает.<\/i><\/p>\n
— У нас идет отличная дискуссия, однако я боюсь, мы можем не успеть таким образом прийти к целям нашего совещания, о которых мы договорились<\/b>. Тема, действительно, важная, можем решить, что она важнее, чем заявленные цели, но давайте это явным образом проговорим?<\/p>\n
Обратите внимание на подкат: не я тут всех разгоняю, а мы договорились о целях. Если в начале вы цели не согласовали, то с этим ходом может выйти осечка. В большинстве случаев это поможет вернуть обсуждение к повестке, и вы перейдете к дожиму формулировок.<\/p>\n
Может статься, что вы действительно набрели на совещании на какую-то убер-важную тему, и она окажется важнее первоначальной темы совещания. Тогда можно отправиться «по этой дорожке». Если вы не согласны так просто отказываться от первоначальной темы, сделайте попытку ее отстоять, пользуясь конфликтной стратегией<\/a>: «Чтобы двинуться вперед по проекту<\/i>, надо принять решение сегодня, если не сегодня, то еще не скоро, а это просрочка» и т. д.<\/p>\n
Стадия «Резюме» — главный тест проджекта на профпригодность<\/h2>\n
Очень часто вижу, как люди скомкивают эту стадию, в лучшем случае до перечня буллит-поинтов, которые проджект тараторит, как официант, повторяющий заказ.<\/p>\n
В то же время, именно здесь вы должны дожать результаты до конкретики. Сделать это бывает очень тяжело, но от этого порой зависит эффективность всего совещания, а иногда и проекта. Ведь если участники занятые, то следующая встреча для обсуждения «недожатых» вопросов может случиться только через неделю, а это может быть критично.<\/p>\n
Очень помогает техника онлайн протоколирования<\/a>, которую я недавно описывал. Формулировки, до которых вы дожимаете, как правило должны быть предельно конкретны: кто, что и когда делает, какой результат получает. Чем визуальнее удастся обрисовать этот результат, тем лучше.<\/p>\n
\n
Плохо:<\/b><\/p>\n<\/blockquote>\n
\n
Обсудили, что <проблема> серьезная, и надо привлечь Иванова к решению.<\/p>\n<\/blockquote>\n
\n
Хорошо:<\/b><\/p>\n<\/blockquote>\n
\n
Петров: Встретиться с Ивановым, обсудить <проблему>. Результат обсуждения: тезисы для эскалации на Правление. Тезисы нужны к 15.12.2021<\/p>\n<\/blockquote>\n
Важно:<\/b> дожим до такого уровня конкретики может занять уйму времени и энергии. Бывает физически тяжело. Можно зарезервировать на этот процесс до 10 минут от часового совещания. Зато сразу после совещания вы выйдете с готовым, согласованным протоколом, а ваш проект двинется дальше.<\/p>\n", "date_published": "2021-11-30T19:28:03+00:00", "date_modified": "2021-12-01T06:10:13+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/stages1@2x.png", "_date_published_rfc2822": "Tue, 30 Nov 2021 19:28:03 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "26", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/stages1@2x.png" ] } }, { "id": "25", "url": "https:\/\/blog.skalon.me\/all\/odin-iz-moschneyshih-instrumentov-prioritizacii-trebovaniy\/", "title": "Один из мощнейших инструментов приоритизации требований", "content_html": "
Сегодня очередной лайфхак от опытного проджекта: бизнес-критичность. Это один из мощнейших инструментов приоритизации требований с заказчиком, но почему-то я довольно редко встречаю его использование.<\/p>\n
Бизнес-критичность — это степень влияния данной задачи или требования на функционал целевой системы. Можно выделить следующие уровни бизнес-критичности.<\/p>\n
- \n
- Blocker — эта задача стоит на пути у других задач. Например, если вы разрабатываете онлайн магазин, то запилить движок, на котором вы размещаете товары, будет блокером.<\/li>\n
- Сritical — без этой задачи системой невозможно пользоваться. Совсем. Для онлайн магазина кнопка «купить» скорее всего будет критичным функционалом.<\/li>\n
- Major — без этой задачи систему можно запускать, но польза сильно пострадает. В примере с онлайн магазином, это, наверное, «корзина». То есть, купить товар можно, но только по одной штучке со страницы товара. Очень неудобно.<\/li>\n
- Minor — без этой задачи функционал можно запускать. Польза страдает, но не сильно. В примере с онлайн магазином это может быть функционал сравнения товаров.<\/li>\n
- Trivial — это «бантики». Пожелания, которые не влияют на бизнес-функционал. В нашем онлайн-магазине это может быть функционал смены темы в зависимости от национальных праздников. Прикольно, конечно, но можно спокойно пережить.<\/li>\n<\/ol>\n
Если вы сейчас, читая примеры, на автомате придумали варианты ситуаций где, например, смена темы под национальный праздник стала мэйджор — отлично. Дело в том, что бизнес-критичность зависит от тех бизнес-целей, к которым мы идем, и в этом главная фишка.<\/p>\n
Бизнес-критичность помогает резать скоуп<\/h2>\n
Случай из практики. Я руковожу проектом, который мне передали на доделку по «джентльменскому соглашению», и скоуп уже трещит по швам. Значительная часть функционала работает кривовато, багов куча, фиче-риквестов тоже навалом. «Сходимость бэклога» не наблюдается — т. е. пополнение бэклога идет быстрее, чем опустошение, или как минимум поровну.<\/p>\n
Я провожу сессию целеполагания с заказчиком: какие бизнес-результаты мы хотим получить с применением системы. Выделяем несколько целевых сценариев, которые позволят заказчику «забить гол» и выполнить ключевые задачи, для которых нужна система.<\/p>\n
Затем все задачи в бэклоге мы классифицируем по бизнес-критичности относительно целевых сценариев.<\/p>\n
После этого говорим: «Дорогой заказчик, мы очень хотим принести вам пользу, поэтому мы подписали с вами „джентльменское соглашение“. Но наши ресурсы ограничены, поэтому мы сделаем для вас все задачи критикал и мэйджор, а остальные, сорри, когда вы у нас докупите работ».<\/p>\n
Так я сократил объем бэклога примерно на 30%.<\/p>\n
Обсуждение бизнес-критичности гораздо конкретнее, чем просто «мы хотим красненького добавить». Причем это работает не только в отношении софтовых проектов, но и в любых других ситуациях, где вам приезжают требования, которые вы исполняете. То есть, практически везде.<\/p>\n
Да, и не путайте с приоритетом<\/h2>\n
Приоритет задачи — это грубо говоря порядок относительно других в какой-то ситуации, например, когда вы собираете релиз. Высокий приоритет — должна войти в релиз, «кровь из носа». В какой-то момент задача критикал может идти с низким приоритетом, потому что сейчас мы допиливаем другой функционал. И задача тривиал может стать вдруг высокоприоритетной, если биг босс, которому показывали систему, попросил перекрасить кнопочку в красный цвет.<\/p>\n", "date_published": "2021-11-28T19:07:16+00:00", "date_modified": "2021-11-29T06:20:15+00:00", "_date_published_rfc2822": "Sun, 28 Nov 2021 19:07:16 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "25", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "24", "url": "https:\/\/blog.skalon.me\/all\/prostoy-sposob-optimizirovat-soveschaniya-idealny-dlya-onlayna\/", "title": "Простой способ оптимизировать совещания, идеальный для онлайна", "content_html": "
\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/onlinenotes@2x.png\")
\n<\/div>\nСегодня расскажу еще об одной своей любимой технологии, которая дает отличные результаты, если ее грамотно применить: онлайн протоколирование, т. е. разработка протокола прямо онлайн, так, чтобы все его видели непосредственно на совещании.<\/p>\n
Прожженные менеджеры, которые сейчас разочарованно махнули рукой, дескать, тоже мне новости, — подождите, есть вероятность, что кое-чем я все-таки смогу вашу копилку приемов пополнить.<\/p>\n
Для тех, кто не такой прожженый, рассказываю с начала.<\/p>\n
Технология простая и очень полезная, но ее можно даже улучшить при помощи пары лайфхаков<\/h2>\n
Технология элементарная: просто открываете заметку и выводите на экран (если онлайн) или на проектор (если в аудитории). Можно вести протоколирование непрерывно онлайн, можно в конце встречи выделять время на согласование протокола.<\/p>\n
В протокол можно писать только задачи, решения (решение это: «Решили отныне действовать таким-то образом») и открытые вопросы (что-то непонятное, надо разбираться). Если вы быстро печатаете — можно более подробно: кто что сказал, принципиальные тезисы и т. п.<\/p>\n
Конечно, удобнее, когда модерирует совещание и ведет протокол два разных человека, потому что динамика, конечно, страдает, пока вы формулируете. Но я умудрялся совмещать.<\/p>\n
\n
Хозяйке на заметку:<\/b><\/p>\n<\/blockquote>\n
\n
Заведите специальный гуглдок или иной текстовый инструмент для совместной работы и ведите все протоколы в нем. Ссылку разошлите всем участникам (можно вставить в повторяющуюся встречу в аутлуке). Каждый новый протокол обозначайте как заголовок: «2021-11-26 — планерка», тогда у вас сформируется удобное оглавление.<\/p>\n<\/blockquote>\n
\n
Также благодаря этому удобно разделить обязанности прямо на совещании: руководитель проекта как председатель идет по повестке и модерирует, секретарь совещания в это время пишет в гуглдоке. Наступает момент согласования, РП открывает и может сам что-то быстро дописать\/подкорректировать в том же документе.<\/p>\n<\/blockquote>\n
Очевидные бонусы:<\/p>\n
- \n
- Протокол готов сразу на совещании, не надо потом после совещания тратить время на написание протокола или фачить эту важную задачу с неизбежным чувством вины и рисками для проекта.<\/li>\n
- Что еще важнее, протокол согласован<\/i> сразу на совещании. Нет войны правок в почте, никто не скажет: «Ой, сорян, у меня столько писем, могло что-то затеряться», не надо ни за кем бегать, и задачки из протокола могут мгновенно переехать в таск-трекер.<\/li>\n<\/ol>\n
Неочевидные бонусы: скрытая фасилитация<\/h2>\n
Протоколируя онлайн вы можете быть не просто усердным стенографистом. Вместо этого вы можете обратиться к участникам совещания «за помощью» в формулировке тезисов под запись. Я написал «за помощью» в кавычках, потому что на самом деле, это вы помогаете участникам сформулировать мысли.<\/p>\n
Дело в том, что наш внутренний диалог устроен таким образом, что внутри головы мы не всегда додумываем мысли до конца (прочитал у Л. Выготского в книге «Мысль и слово»). Даже в устной речи, особенно в пылу мозгового штурма, это может проявляться в том, что человек многое оставляет как «само собой разумеющееся». Письменная речь организована иначе: вы вынуждены построить семантически корректное предложение.<\/p>\n
И вот фасилитатор (то есть, вы), прося людей сформулировать что-то ему под запись, заставляет додумать мысль.<\/p>\n
Другой прием фасилитации, уже не такой скрытой, заключается в том, что, зафиксировав какую-то мысль, вы можете к ней больше не возвращаться. Особенно мешают в дискуссии открытые вопросы, которые уводят в сторону от основной повестки. Их нужно «парковать» и переносить на конец совещания или на другую встречу.<\/p>\n
В общем, отличная технология, странно, что так редко встречаю ее применение.<\/p>\n
Да, кстати, подписывайтесь на меня в Телеге<\/a>: последняя площадка, на которой вы сами решаете, какой контент читать.<\/p>\n", "date_published": "2021-11-26T19:37:21+00:00", "date_modified": "2021-12-14T09:08:59+00:00", "image": "https:\/\/blog.skalon.me\/pictures\/onlinenotes@2x.png", "_date_published_rfc2822": "Fri, 26 Nov 2021 19:37:21 +0000", "_rss_guid_is_permalink": "false", "_rss_guid": "24", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/blog.skalon.me\/pictures\/onlinenotes@2x.png" ] } }, { "id": "18", "url": "https:\/\/blog.skalon.me\/all\/vazhneyshiy-instrument-bez-kotorogo-ne-poluchitsya-upravlyat-bol\/", "title": "Важнейший инструмент, без которого не получится управлять большими проектами", "content_html": "
- Результат:<\/b> увеличилось количество звонков, увеличилось количество коммерческих встреч на продавца.<\/li>\n
- Продукт:<\/b> сама CRM система. Для удобства управления мы скорее всего поделим ее на модули: ключевой функционал, интеграция с соцсетями, интеграция с АТС и т. п.<\/li>\n
- К промежуточным результатам тоже можно описать требования. Это очень полезно, потому что на этом постоянно происходят срывы: команда разработки ждет от пользователей выгрузку данных текущих систем, выгрузка приходит, но в кривом формате. Проблема. Или команда разработки передает модули в тестирование, а пользователи не знают, с какой стороны к ним подходить: не прописали, что должен быть промежуточный продукт «сценарии тестирования», не заложили в план, не сделали.<\/li>\n<\/ul>\n
- Внутри этих границ вы вольны руководить проектами как бог на душу положит: вы — профессионалы, мы вам доверяем. Не хотите проводить планерки — ваше дело.<\/li>\n<\/ol>\n
- Проекту нужны коммуникации с руководством и промежуточный контроль — все это понимают, все взрослые люди. Поэтому раз в период вы будете предоставлять отчетность вот по этой форме. Она единая для всех проектов, руководству удобно ее смотреть, вам ее удобно предоставлять.<\/li>\n<\/ol>\n
- Для этого надо согласовать требования к результату, согласовать сроки и бюджеты. Это удобнее всего сделать с помощью паспорта проекта, реестра результатов с требованиями, графика контрольных точек (не принимайте за универсальный рецепт). Требования к этому оформлению вот такие (и я могу их обосновать<\/a>).<\/li>\n<\/ol>\n
- Компания инвестирует в проект определенные ресурсы. В обмен ожидает получить результат должного качества в согласованные сроки и бюджеты.<\/li>\n<\/ol>\n
![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table1@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table2@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table3@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/table4@2x.png\")
\n<\/div>\n![\"\"](\"https:\/\/blog.skalon.me\/pictures\/summary@2x.png.jpg\")
\n<\/div>\n