Влюблятельные встречи
Однажды в МИФе заметили, что книги, которые нам нравятся — лучше продаются. Если маркетолог или пиарщик влюблен в нее — он творит какие-то чудеса и книга становится бестселлером. Если она его не вдохновляет — результат «ну такое». Поэтому все, кто занимался продвижением, тщательно просматривали все, что выходит. Хотя бы по диагонали. Но с развитием издательства книг рос и ассортимент. В какой-то момент, хоть и команда росла, стало физически невозможным каждому все отсматривать.
Так появились влюблятельные встречи. Это открытие встречи внутри компании. Любой сотрудник мог присоединиться к ней и рассказать о недавно прочитанной книге, которая его зацепила. Или послушать коллег. Эти рассказы давали возможность коллегам присмотреться или влюбиться. Я никогда не выходила из встречи без списка того, что хочу почитать. И чаще всего этот список двигал текущие приоритеты. Потому что никто лучше не продаст, чем тот кто ее прочитал.
Я всегда думала, что эта встреча работает только в бизнесах, где у тебя каждый день появляется новый ассортимент и ты не успеваешь все отслеживать, но в последнее время все чаще начала рассказывать о ней, когда говорю процессе работы с приоритетами беклога.
Вот представьте, у вас с разных мест падают задачи в беклог. Есть понятные, есть непонятные. Есть понятные — скучные, понятные — нескучные. И так дальше. Некоторые лежат в беклоге годами по разным причинам. И часто потому что у нас нет к ним никаких эмоций.
Если включить в процессы влюблятельную встречу, например раз в месяц, куда бы приходили авторы задач и потенциальные исполнители. И первые бы вторым рассказывали почему они так сильно хотят чтобы их задачи реализовали. Делились бы своим исследованием, мыслями, переживаниями. Мне кажется, что у многих задач менялись бы приоритеты, а скорость реализации увеличивалась, потому что по своей природе мы любим помогать, если понимаем зачем и что это значит для другого человека.
#принципы_работы, #управление_проектами
Однажды в МИФе заметили, что книги, которые нам нравятся — лучше продаются. Если маркетолог или пиарщик влюблен в нее — он творит какие-то чудеса и книга становится бестселлером. Если она его не вдохновляет — результат «ну такое». Поэтому все, кто занимался продвижением, тщательно просматривали все, что выходит. Хотя бы по диагонали. Но с развитием издательства книг рос и ассортимент. В какой-то момент, хоть и команда росла, стало физически невозможным каждому все отсматривать.
Так появились влюблятельные встречи. Это открытие встречи внутри компании. Любой сотрудник мог присоединиться к ней и рассказать о недавно прочитанной книге, которая его зацепила. Или послушать коллег. Эти рассказы давали возможность коллегам присмотреться или влюбиться. Я никогда не выходила из встречи без списка того, что хочу почитать. И чаще всего этот список двигал текущие приоритеты. Потому что никто лучше не продаст, чем тот кто ее прочитал.
Я всегда думала, что эта встреча работает только в бизнесах, где у тебя каждый день появляется новый ассортимент и ты не успеваешь все отслеживать, но в последнее время все чаще начала рассказывать о ней, когда говорю процессе работы с приоритетами беклога.
Вот представьте, у вас с разных мест падают задачи в беклог. Есть понятные, есть непонятные. Есть понятные — скучные, понятные — нескучные. И так дальше. Некоторые лежат в беклоге годами по разным причинам. И часто потому что у нас нет к ним никаких эмоций.
Если включить в процессы влюблятельную встречу, например раз в месяц, куда бы приходили авторы задач и потенциальные исполнители. И первые бы вторым рассказывали почему они так сильно хотят чтобы их задачи реализовали. Делились бы своим исследованием, мыслями, переживаниями. Мне кажется, что у многих задач менялись бы приоритеты, а скорость реализации увеличивалась, потому что по своей природе мы любим помогать, если понимаем зачем и что это значит для другого человека.
#принципы_работы, #управление_проектами
Копать проблему, а не решение
К продактам клиенты или внутренние заказчики часто приходят с решением и если продакт зрелый — он обязательно откатится до базовой проблемы, чтобы подобрать оптимальное решение.
Иногда оно может совпадать с решением, которое предложил заказчик, а иногда в корне другим.
Например, на днях у меня случился яркий пример. Ко мне пришел клиент с запросом научить его команду затаскивать проекты в срок. Я сначала ему предложила просто купить подписку на краш-курс, но он сказал, что все сложнее и мы договорились встретиться обсудить контекст.
Когда я спросила, какую проблему он пытается решить и почему краш-курс не подходит — оказалось, что он считает, что на его взгляд, проджекты слабые и ему нужен кто-то скилластый, который научит. Типа курс они бросят, нужен ментор, погруженный в контекст.
Я начала копать почему он так считает и в процессе стало очевидным, что слабые проджекты — это лишь симптом. И его можно полечить, но проблема с оргструктурой и процессами. Проджекты банально не имеют полномочий принимать решения, даже если могут. Появился план действий, что нужно сделать в первую очередь, а обучение проджектов стало вторичным.
Если я не провела бы эту встречу — он бы купил курс или мой менторинг и врятли это решило его задачу. Потому что это только песчинка, которая принесет маленький выхлоп.
Вывод: если хотите чтобы специалисты решали вашу боль — приходите с проблемой, а не решением, иначе получите только лечение симптома. Если вам приносят решения — не стесняйтесь тратить время на то, чтобы откатиться до базовой проблемы. Ваша ценность в глазах заказчика вырастет в разы.
#принципы_работы, #управление_проектами, #чендж
К продактам клиенты или внутренние заказчики часто приходят с решением и если продакт зрелый — он обязательно откатится до базовой проблемы, чтобы подобрать оптимальное решение.
Иногда оно может совпадать с решением, которое предложил заказчик, а иногда в корне другим.
Например, на днях у меня случился яркий пример. Ко мне пришел клиент с запросом научить его команду затаскивать проекты в срок. Я сначала ему предложила просто купить подписку на краш-курс, но он сказал, что все сложнее и мы договорились встретиться обсудить контекст.
Когда я спросила, какую проблему он пытается решить и почему краш-курс не подходит — оказалось, что он считает, что на его взгляд, проджекты слабые и ему нужен кто-то скилластый, который научит. Типа курс они бросят, нужен ментор, погруженный в контекст.
Я начала копать почему он так считает и в процессе стало очевидным, что слабые проджекты — это лишь симптом. И его можно полечить, но проблема с оргструктурой и процессами. Проджекты банально не имеют полномочий принимать решения, даже если могут. Появился план действий, что нужно сделать в первую очередь, а обучение проджектов стало вторичным.
Если я не провела бы эту встречу — он бы купил курс или мой менторинг и врятли это решило его задачу. Потому что это только песчинка, которая принесет маленький выхлоп.
Вывод: если хотите чтобы специалисты решали вашу боль — приходите с проблемой, а не решением, иначе получите только лечение симптома. Если вам приносят решения — не стесняйтесь тратить время на то, чтобы откатиться до базовой проблемы. Ваша ценность в глазах заказчика вырастет в разы.
#принципы_работы, #управление_проектами, #чендж
Ключевая привычка — ко всему готовиться
Одна из моих любимых книг «Как читать книги» Мортимера Адлера. В ней автор учит, как читать, чтобы получать больше пользы от прочитанного нонфика.
В одной из первых глав он говорит о том, что прежде чем начать книгу задайтесь вопросом зачем она вам? Что по итогу вы хотите узнать/получить/сделать? Потом перейдите к содержанию и задайте те же вопросы к каждой главе.
Когда я читала первый раз этот совет — думала, что это полный бред. Но когда начала применять — поняла, что это тренировка осознанности, во-первых. А во-вторых, задавая вопросы перед чтением, я настраиваюсь на перекладывание прочитанного на мой контекст. У меня как будто появляется диалог с автором. И это совершенно другой уровень пользы.
Фактически эта подготовка к чтению помогает выйти на уровень выше — не просто читать, а критически читать и применять. Без подготовки — это просто времяпровождение.
Я поняла, что привычка готовиться ко всему — это то, чему должны учить родители/учителя в школе и т.д. Потому что от подготовки зависит очень многое.
Например, если готовиться:
— встречи перестанут быть бесполезными,
— сложные переговоры реже будут заходить в тупик,
— собеседования будут проходить менее стрессово.
— …(список можно продолжать)
Это кажется довольно очевидным, ведь если посмотреть на тех же спортсменов можно понять, насколько это важно. Они иногда даже по две тренировки в день отрабатывают.
Но когда, например, я предлагаю своим клиентам — руководителям команд добавить в календарь встреч время на подготовку к ним — встречаю искреннее удивление или огорчение, что места уже нет. Тогда чаще всего я спрашиваю «зачем вам столько встреч, если вы не успеваете к ним готовиться?». И как только клиент начинает следовать правилу «выделять в календаре время на подготовку» ко встрече/переговорам и т.д — качество менеджмента вырастает в разы.
#принципы_работы, #управление_проектами, #книги
Одна из моих любимых книг «Как читать книги» Мортимера Адлера. В ней автор учит, как читать, чтобы получать больше пользы от прочитанного нонфика.
В одной из первых глав он говорит о том, что прежде чем начать книгу задайтесь вопросом зачем она вам? Что по итогу вы хотите узнать/получить/сделать? Потом перейдите к содержанию и задайте те же вопросы к каждой главе.
Когда я читала первый раз этот совет — думала, что это полный бред. Но когда начала применять — поняла, что это тренировка осознанности, во-первых. А во-вторых, задавая вопросы перед чтением, я настраиваюсь на перекладывание прочитанного на мой контекст. У меня как будто появляется диалог с автором. И это совершенно другой уровень пользы.
Фактически эта подготовка к чтению помогает выйти на уровень выше — не просто читать, а критически читать и применять. Без подготовки — это просто времяпровождение.
Я поняла, что привычка готовиться ко всему — это то, чему должны учить родители/учителя в школе и т.д. Потому что от подготовки зависит очень многое.
Например, если готовиться:
— встречи перестанут быть бесполезными,
— сложные переговоры реже будут заходить в тупик,
— собеседования будут проходить менее стрессово.
— …(список можно продолжать)
Это кажется довольно очевидным, ведь если посмотреть на тех же спортсменов можно понять, насколько это важно. Они иногда даже по две тренировки в день отрабатывают.
Но когда, например, я предлагаю своим клиентам — руководителям команд добавить в календарь встреч время на подготовку к ним — встречаю искреннее удивление или огорчение, что места уже нет. Тогда чаще всего я спрашиваю «зачем вам столько встреч, если вы не успеваете к ним готовиться?». И как только клиент начинает следовать правилу «выделять в календаре время на подготовку» ко встрече/переговорам и т.д — качество менеджмента вырастает в разы.
#принципы_работы, #управление_проектами, #книги
Не закупоривать энергию в трубе на себе
Представьте себе, следующую ситуацию: команда работает над запуском. Не важно чего: новой версии продукта, MVP, или акции в магазине. Все работают на износ. И тут час икс — вы публикуете анонс во вне, обмениваетесь стикерами в чатике и немного выдыхаете.
Через несколько минут или час начинаются сыпаться разные реакции, начиная с позитивных «Вау, как круто! Вы такие молодцы» и заканчивая проблемными «У меня тут не работает, помогите».
Как-то мы так устроены, что большинство пойдет фокусироваться на проблемных. Ведь «надо срочно решить». И здесь нет ничего плохого, хочется ведь хорошо.
Проблема лишь в том, что негативное мы помним лучше и на его фоне обесценивается хорошее. А если команда еще и не видит все отзывы, а особенно хорошие, то в ее глазах запуск выглядит провальным. А как иначе можно подумать, если тебе сыпятся сплошные баги.
Поэтому стараюсь в день запуска писать команде письмо благодарности. Особенно в большие запуски, когда напряжение возрастает. Чтобы рассказывать реалистичную картинку и не обесценивать хорошее. И не закупоривать на себе энергию в трубе, чтобы не было «вижу хорошее, но транслирую только плохое, потому что это сейчас важнее». Потом никогда не дойдут руки похвалить.
Для примера, на днях писала такую благодарность (cм.скрин к посту) команде «Феди и Самата» за крутой апдейт нашей платформы для обучения. А сегодня хочу сказать еще спасибо большое нашей Зое, которая искала ошибки еще до того, как их увидели ученики и помогала придумывать быстрые решения по их устранению. Получилась очень крутая коллаборация!
Вообщем:
1/ Не жалейте времени на такие письма. Это поможет команде чувствовать ценными. Писать займет 5-10 минут, а пользы в разы больше.
2/ Если вы у нас в прошлом году что-то покупали, но не видели мой анонс об обновлении — велкам смотреть https://lms.tough-dev.school/ и радоваться вместе с нами 🎉
—-
Про формулу благодарности писала в отдельном посте.
#коммуникации #управление_проектами
Представьте себе, следующую ситуацию: команда работает над запуском. Не важно чего: новой версии продукта, MVP, или акции в магазине. Все работают на износ. И тут час икс — вы публикуете анонс во вне, обмениваетесь стикерами в чатике и немного выдыхаете.
Через несколько минут или час начинаются сыпаться разные реакции, начиная с позитивных «Вау, как круто! Вы такие молодцы» и заканчивая проблемными «У меня тут не работает, помогите».
Как-то мы так устроены, что большинство пойдет фокусироваться на проблемных. Ведь «надо срочно решить». И здесь нет ничего плохого, хочется ведь хорошо.
Проблема лишь в том, что негативное мы помним лучше и на его фоне обесценивается хорошее. А если команда еще и не видит все отзывы, а особенно хорошие, то в ее глазах запуск выглядит провальным. А как иначе можно подумать, если тебе сыпятся сплошные баги.
Поэтому стараюсь в день запуска писать команде письмо благодарности. Особенно в большие запуски, когда напряжение возрастает. Чтобы рассказывать реалистичную картинку и не обесценивать хорошее. И не закупоривать на себе энергию в трубе, чтобы не было «вижу хорошее, но транслирую только плохое, потому что это сейчас важнее». Потом никогда не дойдут руки похвалить.
Для примера, на днях писала такую благодарность (cм.скрин к посту) команде «Феди и Самата» за крутой апдейт нашей платформы для обучения. А сегодня хочу сказать еще спасибо большое нашей Зое, которая искала ошибки еще до того, как их увидели ученики и помогала придумывать быстрые решения по их устранению. Получилась очень крутая коллаборация!
Вообщем:
1/ Не жалейте времени на такие письма. Это поможет команде чувствовать ценными. Писать займет 5-10 минут, а пользы в разы больше.
2/ Если вы у нас в прошлом году что-то покупали, но не видели мой анонс об обновлении — велкам смотреть https://lms.tough-dev.school/ и радоваться вместе с нами 🎉
—-
Про формулу благодарности писала в отдельном посте.
#коммуникации #управление_проектами
«Правильно ли я понимаю?»
Собираюсь сделать презу для выступления в Школе, хочу в красивом шаблоне, но пока его нет. Решаю не ждать и сделать без шаблона, а потом отдать Зое, нашему проджекту, чтобы она переделала в шаблоне. Иначе потом у меня не будет времени чтобы делать презу.
Пока я делаю презу, шаблон появляется, Зоя мне его присылает, но я решаю, что уже не буду отвлекаться. Не так много там нужно будет переделывать. Как долелала презу — скидываю Зое со словами «переделаешь мою презу?».
Зоя соглашается. Потом оказывается, что мне надо еще доделать. И я говорю «Если будут правки — я пришлю тебе отдельно». На что Зоя мне пишет «может ты сразу на чистовик сделаешь?». А я «ну давай».
Мои ожидания, что Зоя переделает презу в шаблоне, а я в нее внесу свои правки, а Зоя думает, что я просто возьму шаблон и сама все переделываю. Но мы это не уточняем и расходимся.
В итоге спустя несколько дней, я пишу «Зоя, когда ты мне презу пришлешь, мне надо ее доделать?». Зоя в недоумении (это я так думаю), говорит «так мы договорились, что ты сделаешь сама в шаблоне». От чего я тоже в недоумении.
Мы потеряли время и загнали себя в стресс, потому что надо быстро разруливать. Этого можно было избежать, если бы хотя бы кто-то из нас задал вопрос «правильно ли я понимаю?». Вопрос-сверка из коучинга, который помогает выровнять ожидания.
Например, я как заказчик спросила бы: «Зоя, правильно ли я понимаю, что ты переделаешь мою презу и пришлешь тогда-то, чтобы я могла потом докрутить?». На что бы Зоя ответила «Нет, я думала, что ты сделаешь сама в шаблоне, т.к я тебе его прислала». И дальше мы бы договорились за пару минут. Или Зоя могла бы спросить, правильно ли меня поняла.
Вывод: Марьяна, в следующий раз, если хочешь больше предсказуемости результата задачи — задавай вопрос из коучинга «правильно ли я понимаю», когда ставишь или когда получаешь эту задачу. Он повышает шансы. Еще и количество коммуникации уменьшишь.
#коммуникации, #управление_проектами
Собираюсь сделать презу для выступления в Школе, хочу в красивом шаблоне, но пока его нет. Решаю не ждать и сделать без шаблона, а потом отдать Зое, нашему проджекту, чтобы она переделала в шаблоне. Иначе потом у меня не будет времени чтобы делать презу.
Пока я делаю презу, шаблон появляется, Зоя мне его присылает, но я решаю, что уже не буду отвлекаться. Не так много там нужно будет переделывать. Как долелала презу — скидываю Зое со словами «переделаешь мою презу?».
Зоя соглашается. Потом оказывается, что мне надо еще доделать. И я говорю «Если будут правки — я пришлю тебе отдельно». На что Зоя мне пишет «может ты сразу на чистовик сделаешь?». А я «ну давай».
Мои ожидания, что Зоя переделает презу в шаблоне, а я в нее внесу свои правки, а Зоя думает, что я просто возьму шаблон и сама все переделываю. Но мы это не уточняем и расходимся.
В итоге спустя несколько дней, я пишу «Зоя, когда ты мне презу пришлешь, мне надо ее доделать?». Зоя в недоумении (это я так думаю), говорит «так мы договорились, что ты сделаешь сама в шаблоне». От чего я тоже в недоумении.
Мы потеряли время и загнали себя в стресс, потому что надо быстро разруливать. Этого можно было избежать, если бы хотя бы кто-то из нас задал вопрос «правильно ли я понимаю?». Вопрос-сверка из коучинга, который помогает выровнять ожидания.
Например, я как заказчик спросила бы: «Зоя, правильно ли я понимаю, что ты переделаешь мою презу и пришлешь тогда-то, чтобы я могла потом докрутить?». На что бы Зоя ответила «Нет, я думала, что ты сделаешь сама в шаблоне, т.к я тебе его прислала». И дальше мы бы договорились за пару минут. Или Зоя могла бы спросить, правильно ли меня поняла.
Вывод: Марьяна, в следующий раз, если хочешь больше предсказуемости результата задачи — задавай вопрос из коучинга «правильно ли я понимаю», когда ставишь или когда получаешь эту задачу. Он повышает шансы. Еще и количество коммуникации уменьшишь.
#коммуникации, #управление_проектами
Проговорить ожидания и дать власть
Мы сейчас готовим новый курс с Антоном Давыдовым. Уроки запланировали в формате лонгридов. Курс хардовый, писать его очень тяжело.
Обычно мы с Федей редактируем все тексты, но в этот раз решили привлечь профессионального редактора, потому что знаем, что с его помощью тексты станут круче и понятнее. Это стало особенно важным в этом курсе из-за сложности и объема информации, которую нужно переварить. Редактором выступил Тимур Зарудный.
Тимур с Антоном начали работать. У них случился хороший тандем, но результатом мы с Федей были недовольны. Вроде тексты ок, но прочитать их было сложно. Ты начинаешь читать и мозги закипают. Как будто бы Тимур меньше вникает в смыслы и больше работает с формой того, что есть. Антон же как будто попадает в ловушку, когда эксперт хочет в один курс засунуть все что он знает (что в общем-то нормально).
В итоге у нас получаются портянки по 80-90 тыс знаков, которые сложно воспринимать. И даже мы с Федей, заинтересованные и с высокой мотивацией, не можем осилить. Как тогда осилят ученики?!
Я в какой-то момент подумала, что может надо сделать в формате видео, мол смотреть проще. Но потом поняла, что это одно и тоже — работа с формой, а надо со смыслами. Еще мы думали, что может дело в том, что редактирует не Федя, а Тимур — у него же нет знаний в предметной области. Типа надо либо самому, либо получится фигня.
Но у меня было четкое убеждение, что редактор способен влезать в смыслы и делать классные тексты. Тем более, что Тимур талантливый редактор, я обожаю его тексты и знаю, что он может говорить понятно на разные темы.
Тогда я задумалась, как мы ставили задачу и наделили ли редактора властью. Оказалось, что сказали «редачь тексты, чтобы хорошо читалось».
Вроде понятно, а вроде не очень то и прозрачно. Мы даже не проговорили кейсы в духе «А можно ли спорить с экспертом?», «А мне только тексты причесывать, или в смыслы влезать?» Вот он и редачил и считал автора главным. Если автор уходил в сторону — значит так и должно быть. Хотя автор может это делать неосознанно.
Так мы решили собрать встречу, чтобы разобраться. Вот что выяснилось:
1/ Плохо поставили задачу. Тимуру было непонятно, во что ему можно влезать, а куда нельзя. Да и тупо чего мы ждем, какой продукт хотим, что должен испытывать ученик, читая материалы курса. Регулярно проскакивали фразы «ну я не совсем понимаю что можно отрезать, а что нет», «есть места где мне понятно, а есть где нет».
2/ Не дали Тимуру власть. Я знаю, что Тимур офигенно во всем может разобраться и у него есть преимущество перед Антоном, у которого замылен глаз из-за того, что много внутри контента. Тимур смотрит на все глазами ученика, если он поймет материал — любой поймет. И я сказала «Тимур, ты можешь задавать вопросы, если тебе непонятно. Писать когда чувствуешь, что мысль оборвалась или ушла куда-то в сторону. И это тебя сбило». Я дала Тимуру власть.
3/ Убрали сомнения по поводу смыслов. Мы договорились о том, что Федя с Антоном будут проверять смыслы, чтобы случайно не потерять важное. Это увеличит время, но зато тексты можно будет намазывать на хлеб и наслаждаться.
Мы разошлись и через неделю получили лонгрид совершенно другого качества. Теперь мы довольны.
А могли бы просто посчитать это неудачным экспериментом:
— отказаться от коллаба с Тимуром и делать все самому;
— закрыть проект и не создать новый курс с Антоном, который ждут наши ученики;
— перейти в формат видео или сохранить текущий вид, через который не продрется наш ученик.
А надо было всего лишь обсудить задачу, проговорить ожидания и дать людям власть делать свою работу. Но главное, что вовремя все починили и курсу быть в ближайшее время.
#управление_проектами, #команда
Мы сейчас готовим новый курс с Антоном Давыдовым. Уроки запланировали в формате лонгридов. Курс хардовый, писать его очень тяжело.
Обычно мы с Федей редактируем все тексты, но в этот раз решили привлечь профессионального редактора, потому что знаем, что с его помощью тексты станут круче и понятнее. Это стало особенно важным в этом курсе из-за сложности и объема информации, которую нужно переварить. Редактором выступил Тимур Зарудный.
Тимур с Антоном начали работать. У них случился хороший тандем, но результатом мы с Федей были недовольны. Вроде тексты ок, но прочитать их было сложно. Ты начинаешь читать и мозги закипают. Как будто бы Тимур меньше вникает в смыслы и больше работает с формой того, что есть. Антон же как будто попадает в ловушку, когда эксперт хочет в один курс засунуть все что он знает (что в общем-то нормально).
В итоге у нас получаются портянки по 80-90 тыс знаков, которые сложно воспринимать. И даже мы с Федей, заинтересованные и с высокой мотивацией, не можем осилить. Как тогда осилят ученики?!
Я в какой-то момент подумала, что может надо сделать в формате видео, мол смотреть проще. Но потом поняла, что это одно и тоже — работа с формой, а надо со смыслами. Еще мы думали, что может дело в том, что редактирует не Федя, а Тимур — у него же нет знаний в предметной области. Типа надо либо самому, либо получится фигня.
Но у меня было четкое убеждение, что редактор способен влезать в смыслы и делать классные тексты. Тем более, что Тимур талантливый редактор, я обожаю его тексты и знаю, что он может говорить понятно на разные темы.
Тогда я задумалась, как мы ставили задачу и наделили ли редактора властью. Оказалось, что сказали «редачь тексты, чтобы хорошо читалось».
Вроде понятно, а вроде не очень то и прозрачно. Мы даже не проговорили кейсы в духе «А можно ли спорить с экспертом?», «А мне только тексты причесывать, или в смыслы влезать?» Вот он и редачил и считал автора главным. Если автор уходил в сторону — значит так и должно быть. Хотя автор может это делать неосознанно.
Так мы решили собрать встречу, чтобы разобраться. Вот что выяснилось:
1/ Плохо поставили задачу. Тимуру было непонятно, во что ему можно влезать, а куда нельзя. Да и тупо чего мы ждем, какой продукт хотим, что должен испытывать ученик, читая материалы курса. Регулярно проскакивали фразы «ну я не совсем понимаю что можно отрезать, а что нет», «есть места где мне понятно, а есть где нет».
2/ Не дали Тимуру власть. Я знаю, что Тимур офигенно во всем может разобраться и у него есть преимущество перед Антоном, у которого замылен глаз из-за того, что много внутри контента. Тимур смотрит на все глазами ученика, если он поймет материал — любой поймет. И я сказала «Тимур, ты можешь задавать вопросы, если тебе непонятно. Писать когда чувствуешь, что мысль оборвалась или ушла куда-то в сторону. И это тебя сбило». Я дала Тимуру власть.
3/ Убрали сомнения по поводу смыслов. Мы договорились о том, что Федя с Антоном будут проверять смыслы, чтобы случайно не потерять важное. Это увеличит время, но зато тексты можно будет намазывать на хлеб и наслаждаться.
Мы разошлись и через неделю получили лонгрид совершенно другого качества. Теперь мы довольны.
А могли бы просто посчитать это неудачным экспериментом:
— отказаться от коллаба с Тимуром и делать все самому;
— закрыть проект и не создать новый курс с Антоном, который ждут наши ученики;
— перейти в формат видео или сохранить текущий вид, через который не продрется наш ученик.
А надо было всего лишь обсудить задачу, проговорить ожидания и дать людям власть делать свою работу. Но главное, что вовремя все починили и курсу быть в ближайшее время.
#управление_проектами, #команда
Убирать препятствия вместо того, чтобы пинать
Много лет назад в Бюро Горбунова заговорили о том, что менеджеры не нужны. Я помню, что искренне не понимала, почему так хейтят менеджеров проектов, они же помогают команде, зачем их убирать.
Но потом я поняла, в чем ловушка и что делать, если вы менеджер и вас хейтят или к вашей команде прикрепили менеджера, от которого вы мечтаете избавиться.
По классике ключевая задача менеджера проектов — привести команду к цели (выполненный проект) в срок, в достаточном качестве. Многие воспринимают это буквально и начинают пинать: «у нас дедлайн, когда задеплоиете фичу», «сроки горят, а у нас ещё не написан текст» и т.д. Как будто мы дети, которые не ориентируются в сроках. Это не только не помогает, а еще и создает дополнительное напряжение. Обычно задержка со сроками возникает из-за какой-то сложности, а не потому что забыл. Обычно так, если это команда взрослых людей, которые не только ради зарплаты работают. Вишенкой на торте будет еще микроменеджмент «ты чем занимался? Задача до сих пор не готова»
Но, представьте, что менеджер вместо того, чтобы ныть «сроки, сроки» скажет: «Слушай, я вижу что ты не успеваешь со сроками, расскажи в чем сложность. Вдруг я смогу кого-то привлечь на помощь?». Чувствуется поддержка? Задавая этот вопрос, я часто помогала человеку выйти из тупика и получить задачу в срок.
Или еще может быть так: «Слушай, вижу тебе надо текст для промостраницы написать, и ты не успеваешь. Я накидала рыбу страницы, как вижу структуру и ключевые мысли в тексте. Вдруг тебе поможет». В этом случае, я просто сделала какую-то говняшку, и тем самым помогла коллеге побороть страх чистого листа. Потому что всегда начатое переделать сильно проще, чем с нуля. Или как минимум завела документ и что-то начала, тем самым создала среду для работы и сэкономила коллеге время.
Вообщем, ключевая задача менеджера проектов — не пинать, а убирать препятствия. Только в этом случае он помогает, а не мешает команде двигаться вперед. Если вы менеджер — посмотрите в эту сторону, если у вас в команде пинатель — дайте обратную связь, и если не сработает — гоните. Такой товарищ в долгосрочной перспективе скорее тащит назад, чем двигает вперед.
#управление_проектами, #команда
Много лет назад в Бюро Горбунова заговорили о том, что менеджеры не нужны. Я помню, что искренне не понимала, почему так хейтят менеджеров проектов, они же помогают команде, зачем их убирать.
Но потом я поняла, в чем ловушка и что делать, если вы менеджер и вас хейтят или к вашей команде прикрепили менеджера, от которого вы мечтаете избавиться.
По классике ключевая задача менеджера проектов — привести команду к цели (выполненный проект) в срок, в достаточном качестве. Многие воспринимают это буквально и начинают пинать: «у нас дедлайн, когда задеплоиете фичу», «сроки горят, а у нас ещё не написан текст» и т.д. Как будто мы дети, которые не ориентируются в сроках. Это не только не помогает, а еще и создает дополнительное напряжение. Обычно задержка со сроками возникает из-за какой-то сложности, а не потому что забыл. Обычно так, если это команда взрослых людей, которые не только ради зарплаты работают. Вишенкой на торте будет еще микроменеджмент «ты чем занимался? Задача до сих пор не готова»
Но, представьте, что менеджер вместо того, чтобы ныть «сроки, сроки» скажет: «Слушай, я вижу что ты не успеваешь со сроками, расскажи в чем сложность. Вдруг я смогу кого-то привлечь на помощь?». Чувствуется поддержка? Задавая этот вопрос, я часто помогала человеку выйти из тупика и получить задачу в срок.
Или еще может быть так: «Слушай, вижу тебе надо текст для промостраницы написать, и ты не успеваешь. Я накидала рыбу страницы, как вижу структуру и ключевые мысли в тексте. Вдруг тебе поможет». В этом случае, я просто сделала какую-то говняшку, и тем самым помогла коллеге побороть страх чистого листа. Потому что всегда начатое переделать сильно проще, чем с нуля. Или как минимум завела документ и что-то начала, тем самым создала среду для работы и сэкономила коллеге время.
Вообщем, ключевая задача менеджера проектов — не пинать, а убирать препятствия. Только в этом случае он помогает, а не мешает команде двигаться вперед. Если вы менеджер — посмотрите в эту сторону, если у вас в команде пинатель — дайте обратную связь, и если не сработает — гоните. Такой товарищ в долгосрочной перспективе скорее тащит назад, чем двигает вперед.
#управление_проектами, #команда
Проекты-жвачки и ритм
Есть такие проекты, которые никак не запустятся, потому что у них много тягомотины. О них говорят обычно так: «мы вроде все делаем, но чет так долго. Уже 10 раз концепцию поменяли и кажется ненавидим этот проект». Я называю их проектами — жвачками.
Главный признак жвачки — отсутствие ритма. Но ритм — это не о том, есть ли у нас ежедневные стендапы или еженедельные регулярные встречи по проекту. Потому что эти встречи не панацея, можно запускать много всего и без них.
Ключевое в ритме — это то, как команда щелкает задачки. Есть ли чувство тыц-тыц. Когда я думаю об этом — у меня возникает образ того, как работает гоночная команда на пит-стопе. Гонщик подъезжает и есть несколько минут, чтобы привести машину и водителя в порядок. Один колеса меняет, второй масло заливает, третий болты закручивает. За несколько минут творится магия. Если никогда не видели — очень советую посмотреть.
В проектах-жвачках все ровно наоборот: каждый делает свою задачу, но не передает на следующий этап. Никто не думает о том, что будет дальше и как эффективнее сделать. В лучшем случае, менеджер проекта ходит как нянька за всеми и служит этим связующим звеном.
Какие-то части постоянно выпадают и все сыпется из рук. Потому что начинает что-то быть срочным, возникают ошибки и т.д. Или начинается тягомотина из-за того, что команда постоянно отодвигает сроки, потому что не укладывается в обещанные, а менеджера-пинателя никто не слушает.
Иногда жвачка возникает из-за того, что никто не готов принять решение: «давайте сделаем так», начинается обсуждения решения, перемываются ему косточки по 10 раз, но так и не принимается решение. Начинает теряться энергия, появляется скука. И как следствие, хочется закрыть проект или что чаще поменять концепцию. И это топтание на одном месте может длится месяцами, а иногда и годами (я и такие случаи видела).
Когда-то я писала, что ритм в проекте — как пульс в теле. Если следите за ним, не будет ни жвачки, ни выгорания.
#управление_проектами, #команда
Есть такие проекты, которые никак не запустятся, потому что у них много тягомотины. О них говорят обычно так: «мы вроде все делаем, но чет так долго. Уже 10 раз концепцию поменяли и кажется ненавидим этот проект». Я называю их проектами — жвачками.
Главный признак жвачки — отсутствие ритма. Но ритм — это не о том, есть ли у нас ежедневные стендапы или еженедельные регулярные встречи по проекту. Потому что эти встречи не панацея, можно запускать много всего и без них.
Ключевое в ритме — это то, как команда щелкает задачки. Есть ли чувство тыц-тыц. Когда я думаю об этом — у меня возникает образ того, как работает гоночная команда на пит-стопе. Гонщик подъезжает и есть несколько минут, чтобы привести машину и водителя в порядок. Один колеса меняет, второй масло заливает, третий болты закручивает. За несколько минут творится магия. Если никогда не видели — очень советую посмотреть.
В проектах-жвачках все ровно наоборот: каждый делает свою задачу, но не передает на следующий этап. Никто не думает о том, что будет дальше и как эффективнее сделать. В лучшем случае, менеджер проекта ходит как нянька за всеми и служит этим связующим звеном.
Какие-то части постоянно выпадают и все сыпется из рук. Потому что начинает что-то быть срочным, возникают ошибки и т.д. Или начинается тягомотина из-за того, что команда постоянно отодвигает сроки, потому что не укладывается в обещанные, а менеджера-пинателя никто не слушает.
Иногда жвачка возникает из-за того, что никто не готов принять решение: «давайте сделаем так», начинается обсуждения решения, перемываются ему косточки по 10 раз, но так и не принимается решение. Начинает теряться энергия, появляется скука. И как следствие, хочется закрыть проект или что чаще поменять концепцию. И это топтание на одном месте может длится месяцами, а иногда и годами (я и такие случаи видела).
Когда-то я писала, что ритм в проекте — как пульс в теле. Если следите за ним, не будет ни жвачки, ни выгорания.
#управление_проектами, #команда
Задачи-вентили
Каждый день, я начинаю работу не с проглатывания лягушек, как завещал Трейси, а с открытия вентилей. Задачи-вентили — это такие, которые стопорят основной процесс работы над проектом.
Например, мы открыли продажи нового курса и нужно запустить рекламу. Если я не пересмотрю список площадок для рекламы и не дам обратную связь команде — никто дальше не пойдет договариваться с площадками, не проведет оплаты и не забронирует слоты. Вентиль будет по прежнему закрыт.
В итоге реклама не запустится — продажи не начнутся. Мы потеряем время и упустим выгоду. Но если я сделаю свой кусочек — шестеренки закрутятся и у нас появится шанс заработать денег.
Когда я рассказываю про задачи-вентили — мне возражают, мол «тогда у меня не будет времени на свои задачи, я только буду других обслуживать». Например, недавно одна подписчица привела пример: «когда я ставлю вперед задачи других, например code review, постановка задач в трелло — я до своих задач часто не дохожу, поэтому отказалась от этого подхода».
Но проблема не в подходе, а в том, что вышеперечисленные задачи в примере не вентили, а рутина в процессе. И с нее правда не стоит начинать день, потому что сколько бы рутины не было, она все равно не кончается.
Вентиль — это более глобальная история. Например, вы делаете новый продукт и нужно проанализировать прототип, который сделал дизайнер, чтобы потом дальше команда разработки могла оценить задачу, выстроить архитектуру и запилить код. Пока ты внимательно не изучишь прототип — вентиль не откроется.
#принципы_работы, #управление_проектами
Каждый день, я начинаю работу не с проглатывания лягушек, как завещал Трейси, а с открытия вентилей. Задачи-вентили — это такие, которые стопорят основной процесс работы над проектом.
Например, мы открыли продажи нового курса и нужно запустить рекламу. Если я не пересмотрю список площадок для рекламы и не дам обратную связь команде — никто дальше не пойдет договариваться с площадками, не проведет оплаты и не забронирует слоты. Вентиль будет по прежнему закрыт.
В итоге реклама не запустится — продажи не начнутся. Мы потеряем время и упустим выгоду. Но если я сделаю свой кусочек — шестеренки закрутятся и у нас появится шанс заработать денег.
Когда я рассказываю про задачи-вентили — мне возражают, мол «тогда у меня не будет времени на свои задачи, я только буду других обслуживать». Например, недавно одна подписчица привела пример: «когда я ставлю вперед задачи других, например code review, постановка задач в трелло — я до своих задач часто не дохожу, поэтому отказалась от этого подхода».
Но проблема не в подходе, а в том, что вышеперечисленные задачи в примере не вентили, а рутина в процессе. И с нее правда не стоит начинать день, потому что сколько бы рутины не было, она все равно не кончается.
Вентиль — это более глобальная история. Например, вы делаете новый продукт и нужно проанализировать прототип, который сделал дизайнер, чтобы потом дальше команда разработки могла оценить задачу, выстроить архитектуру и запилить код. Пока ты внимательно не изучишь прототип — вентиль не откроется.
#принципы_работы, #управление_проектами
Проект можно считать закрытым, если…Эволюция моей позиции
Когда-то окончанием проекта я считала его запуск. Например, делаем интернет-магазин: запуск в нем — это когда на сайте возможно купить товар. Потом, когда мы рассказали об этом аудитории.
Со временем я узнала про цикл PDCA (Plan-Do-Check-Act) и что в нем часть Check-Act не менее частая, чем Plan-Do, к которой мы больше привыкли. И решила, что запуск проекта — это когда ты сделал весь цикл и ставила галочку закрытия проекта, когда подвела итоги. Этому и учила людей, которые приходили ко мне на наставничество.
Потом я познакомилась с Dragon Dreaming — подходом к управлению проектов через празднование и начала учиться праздновать запуск, независимо от того, какой он успешен. Галочка закрытия переместилась на Запустить → Подвести промежуточные итоги → Отпраздновать. Или если долго ждать итогов проекта: Запустить →Отпраздновать → Подвести промежуточные итоги.
Сейчас я считаю, что проект закрыт, если о нем ты рассказал другим. Когда побыл маркетологом/пиарщиком своего результата: сделал презентацию, позвал коллег, поделился с руководителем и т.д. Не скромным письмецом, а так если бы ты сам этот интернет-магазин, который запускаешь. Вообщем следовал принципу «Покажи свою работу» из одноименной книги Остина Клеона. Я считаю, что это прям очень важная штука, которую у нас в культуре не особо принято проявлять.
Но она важна, потому что рассказать о проекте это как минимум идеальный способ для того, чтобы:
1/ поднять себе зарплату, если ты круто все сделал. Легко на проекте показать, как выросла твоя ответственность, насколько много пользы ты принес компании.
2/ возможность получить авторитет и власть. Коллеги узнают, что ты делаешь и будут приходить к тебе за подобным или захотят вписываться в команду твоих многих проектов
3/ повод посмотреть в свои «хочу» и заявить руководителю какие проекты ты хочешь делать, а какие нет. Пока к тебе максимальная лояльность.
4/ а еще это способ поработать со своим самозванцем и присвоить себе результат.
#принципы_работы, #управление_проектами
Когда-то окончанием проекта я считала его запуск. Например, делаем интернет-магазин: запуск в нем — это когда на сайте возможно купить товар. Потом, когда мы рассказали об этом аудитории.
Со временем я узнала про цикл PDCA (Plan-Do-Check-Act) и что в нем часть Check-Act не менее частая, чем Plan-Do, к которой мы больше привыкли. И решила, что запуск проекта — это когда ты сделал весь цикл и ставила галочку закрытия проекта, когда подвела итоги. Этому и учила людей, которые приходили ко мне на наставничество.
Потом я познакомилась с Dragon Dreaming — подходом к управлению проектов через празднование и начала учиться праздновать запуск, независимо от того, какой он успешен. Галочка закрытия переместилась на Запустить → Подвести промежуточные итоги → Отпраздновать. Или если долго ждать итогов проекта: Запустить →Отпраздновать → Подвести промежуточные итоги.
Сейчас я считаю, что проект закрыт, если о нем ты рассказал другим. Когда побыл маркетологом/пиарщиком своего результата: сделал презентацию, позвал коллег, поделился с руководителем и т.д. Не скромным письмецом, а так если бы ты сам этот интернет-магазин, который запускаешь. Вообщем следовал принципу «Покажи свою работу» из одноименной книги Остина Клеона. Я считаю, что это прям очень важная штука, которую у нас в культуре не особо принято проявлять.
Но она важна, потому что рассказать о проекте это как минимум идеальный способ для того, чтобы:
1/ поднять себе зарплату, если ты круто все сделал. Легко на проекте показать, как выросла твоя ответственность, насколько много пользы ты принес компании.
2/ возможность получить авторитет и власть. Коллеги узнают, что ты делаешь и будут приходить к тебе за подобным или захотят вписываться в команду твоих многих проектов
3/ повод посмотреть в свои «хочу» и заявить руководителю какие проекты ты хочешь делать, а какие нет. Пока к тебе максимальная лояльность.
4/ а еще это способ поработать со своим самозванцем и присвоить себе результат.
#принципы_работы, #управление_проектами
«Последняя миля» vs Метод прогрессивного джипега
«Последняя миля» — один из самых популярных постов в этом канале. Он о задачах, которые по готовности на финишной прямой, но все еще не в релизе. Я рассказываю том, сколько они на самом деле стоят компании и почему их важно делать в первую очередь. Очень топлю за то, чтобы этих задачах было по минимуму в беклоге.
Но есть еще одна штука — метод прогрессивного джипега, когда мы наоборот фокусируемся не на доделке, а на том, чтобы сделать основную работу и понять по ней риски.
Общаясь с командами, я поймала противоречие, которое хочу прояснить на примере.
Возьмем простой по процессу продукт — курс из нескольких лонгридов.
Вводные такие:
1/ Дописываем его после открытия продаж. Т.е когда начнется обучения — контент еще будет в процессе подготовки. Делается это для того, чтобы совсем не улететь от запроса аудитории, которая пришла учиться.
2/ В работе над каждым есть этапы работы: допустим, написать черновик; несколько итераций редактуры; нарисовать иллюстрации, отдать на вычитку и сверстать.
3/ Работа идет параллельно над несколькими лонгридами. Пока автор пишет третий лонгрид, редактор читает второй, а иллюстратор рисует иллюстрации для первого. У каждого свои дедлайны.
4/ На каждом из этапов подключаются разные люди, а значит к автору лонгрида возникают вопросы/комментарии.
Если я спрошу, какой приоритет по задачам у автора, обычно мне отвечают: важно чтобы он сначала написал все черновики, чтобы потом не был стоппером. Стоимость переключений высока. Если вы так отвечаете, отчасти будете правы. Потому что это главное правило работы методом прогрессивного джипега.
Но следуя этому методу команды чаще всего попадают в следующую ловушку: курс начинается, а у команды первый лонгрид готов на 95%, второй на 80%, третий на 50% и т.д. Все начинают бегать и быстро все чинить, создавая множество ошибок.
Чтобы этого не случилось, очень важно балансировать прогрессивный джипег с инкрементом (готовым кусочком). Я топлю за то, чтобы фокусироваться на готовых штуках. Например, пока эксперт пишет черновик или большой его кусок — его нельзя трогать, переключения в этот момент крайне дорогое. Но, когда он его закончил его, физически он не сможет перейти на то, чтобы дальше улучшать черновик. Обычно нужно время на передышку. В этот момент нужно как раз вытащить все задачи по по доделкам предыдущих лонгридов.
То есть, мы соединяем не идем по плану что пока не закончили первый лонгрид, новый не берем (как я завещала в посте о последней миле), и работаем методом прогрессивного джипега, но паузы используем как раз с фокусом на последней миле.
#принципы_работы, #управление_проектами, #продукт
«Последняя миля» — один из самых популярных постов в этом канале. Он о задачах, которые по готовности на финишной прямой, но все еще не в релизе. Я рассказываю том, сколько они на самом деле стоят компании и почему их важно делать в первую очередь. Очень топлю за то, чтобы этих задачах было по минимуму в беклоге.
Но есть еще одна штука — метод прогрессивного джипега, когда мы наоборот фокусируемся не на доделке, а на том, чтобы сделать основную работу и понять по ней риски.
Общаясь с командами, я поймала противоречие, которое хочу прояснить на примере.
Возьмем простой по процессу продукт — курс из нескольких лонгридов.
Вводные такие:
1/ Дописываем его после открытия продаж. Т.е когда начнется обучения — контент еще будет в процессе подготовки. Делается это для того, чтобы совсем не улететь от запроса аудитории, которая пришла учиться.
2/ В работе над каждым есть этапы работы: допустим, написать черновик; несколько итераций редактуры; нарисовать иллюстрации, отдать на вычитку и сверстать.
3/ Работа идет параллельно над несколькими лонгридами. Пока автор пишет третий лонгрид, редактор читает второй, а иллюстратор рисует иллюстрации для первого. У каждого свои дедлайны.
4/ На каждом из этапов подключаются разные люди, а значит к автору лонгрида возникают вопросы/комментарии.
Если я спрошу, какой приоритет по задачам у автора, обычно мне отвечают: важно чтобы он сначала написал все черновики, чтобы потом не был стоппером. Стоимость переключений высока. Если вы так отвечаете, отчасти будете правы. Потому что это главное правило работы методом прогрессивного джипега.
Но следуя этому методу команды чаще всего попадают в следующую ловушку: курс начинается, а у команды первый лонгрид готов на 95%, второй на 80%, третий на 50% и т.д. Все начинают бегать и быстро все чинить, создавая множество ошибок.
Чтобы этого не случилось, очень важно балансировать прогрессивный джипег с инкрементом (готовым кусочком). Я топлю за то, чтобы фокусироваться на готовых штуках. Например, пока эксперт пишет черновик или большой его кусок — его нельзя трогать, переключения в этот момент крайне дорогое. Но, когда он его закончил его, физически он не сможет перейти на то, чтобы дальше улучшать черновик. Обычно нужно время на передышку. В этот момент нужно как раз вытащить все задачи по по доделкам предыдущих лонгридов.
То есть, мы соединяем не идем по плану что пока не закончили первый лонгрид, новый не берем (как я завещала в посте о последней миле), и работаем методом прогрессивного джипега, но паузы используем как раз с фокусом на последней миле.
#принципы_работы, #управление_проектами, #продукт
У задачи должен быть контекст
Для меня это обязательный пункт. Потому что от контекста зависит результат и приоритет. Для меня это очень очевидная штука, но почему-то в командах, с которыми я работаю часто встречаю, что этим пренебрегают. Даже скилластые ребята. Поэтому в этом посте хочу попробовать продать эту идею на конкретных примерах.
Итак, представьте, что вы решили реализовать брошенную корзину на сайте. Чтобы те, кто начинал покупать ваш товар, но бросил — получали письмо, в котором напоминали, что можно вернуться к покупке. Но прежде чем поставить задачу в разработку на реализацию, вы хотите посчитать сколько у вас сейчас бросают заказы, чтобы понять стоит ли игра свеч.
Поэтому, вы пишите аналитику и просите «Сделай мне выгрузку тех, кто бросил заказ за последний год. Помесячно». Аналитик открывает эту задачу и думает «Блин, а надо повторяющие заказы учитывать или нет? И вообще мне надо делать дашборд для СЕО, пусть сами делают свою выгрузку» В итоге либо вы уходите в ответы на вопросы и множите коммуникацию либо получаете игнор и остается без выгрузки.
А теперь представьте, что вы пишите тоже самое но добавляете контекст. Например, так «Ваня, я сейчас работаю над брошенной корзиной. Там предполагается интеграция с внешним сервисом и куча всего. Хочу сначала посчитать выгодно ли. По моим ощущениям эта задача может нам добавить 25% к текущей выручке. Мне нужна выгрузка за последний год, помесячно. Поможешь?».
Аналитик открывает задачу и думает «Ага, задача потенциально на 25% выручки. Как же я могу посмотреть? Давай я сделаю выгрузку помесячно, как просят. Поставлю два разреза: все заказы, уникальные и еще посмотрю вдруг это технические проблемы и бла-бла. Пойду скорее сделаю»
Во втором случае, зная контекст — аналитик не только сделает задачу, как вы просили, но и добавит то, чего вы не просили. Вы можете сказать, что в первом случае, вы сами могли бы добавить требования, какие данные вам нужны. Да, могли. Но вы точно знаете меньше аналитика, а что еще можно было бы посмотреть. Это тоже самое как рисовать дизайны руками дизайнера, а не доверяться ему в том, в чем он лучше вас.
И понимая контекст, приоритет тоже проще определить. Из какой-то непонятной выгрузки задача превратилась в то, что может принести 25% выручки.
#управление_проектами, #коммуникации
Для меня это обязательный пункт. Потому что от контекста зависит результат и приоритет. Для меня это очень очевидная штука, но почему-то в командах, с которыми я работаю часто встречаю, что этим пренебрегают. Даже скилластые ребята. Поэтому в этом посте хочу попробовать продать эту идею на конкретных примерах.
Итак, представьте, что вы решили реализовать брошенную корзину на сайте. Чтобы те, кто начинал покупать ваш товар, но бросил — получали письмо, в котором напоминали, что можно вернуться к покупке. Но прежде чем поставить задачу в разработку на реализацию, вы хотите посчитать сколько у вас сейчас бросают заказы, чтобы понять стоит ли игра свеч.
Поэтому, вы пишите аналитику и просите «Сделай мне выгрузку тех, кто бросил заказ за последний год. Помесячно». Аналитик открывает эту задачу и думает «Блин, а надо повторяющие заказы учитывать или нет? И вообще мне надо делать дашборд для СЕО, пусть сами делают свою выгрузку» В итоге либо вы уходите в ответы на вопросы и множите коммуникацию либо получаете игнор и остается без выгрузки.
А теперь представьте, что вы пишите тоже самое но добавляете контекст. Например, так «Ваня, я сейчас работаю над брошенной корзиной. Там предполагается интеграция с внешним сервисом и куча всего. Хочу сначала посчитать выгодно ли. По моим ощущениям эта задача может нам добавить 25% к текущей выручке. Мне нужна выгрузка за последний год, помесячно. Поможешь?».
Аналитик открывает задачу и думает «Ага, задача потенциально на 25% выручки. Как же я могу посмотреть? Давай я сделаю выгрузку помесячно, как просят. Поставлю два разреза: все заказы, уникальные и еще посмотрю вдруг это технические проблемы и бла-бла. Пойду скорее сделаю»
Во втором случае, зная контекст — аналитик не только сделает задачу, как вы просили, но и добавит то, чего вы не просили. Вы можете сказать, что в первом случае, вы сами могли бы добавить требования, какие данные вам нужны. Да, могли. Но вы точно знаете меньше аналитика, а что еще можно было бы посмотреть. Это тоже самое как рисовать дизайны руками дизайнера, а не доверяться ему в том, в чем он лучше вас.
И понимая контекст, приоритет тоже проще определить. Из какой-то непонятной выгрузки задача превратилась в то, что может принести 25% выручки.
#управление_проектами, #коммуникации
Обратное планирование
Если бы меня спросили, на чем сфокусироваться, если я хочу прокачать свои навыки управления проектами, я бы назвала три штуки:
1/ умение видеть и убирать препятствия вместо того, чтобы быть пинателем
2/ умение работать с рисками: уметь их находить и стелить солому,
3/ и уметь планировать от обратного
О первых двух я уже как-то рассказывала на канале, а о последнем пока нет. Мне всегда казалось, что это самое простое, но практически все мои клиенты, которые приходят в наставничество или консалтинг сталкиваются именно с ним.
Впервые с этим термином я столкнулась в древней книге «Уходим в отрыв» (глава 2). Ее автор говорит о том, что когда мы решили делать проект, мы обычно формулируем цель, а потом пытаемся выстроить последовательность шагов, чтобы ее достичь. И сначала нам что-то понятно, но ближе к цели становится сложно.
Нам нужно, например, запустить новое мобильное приложение для медитаций. Мы решили, что хотим его сделать за 10 недель. Т.е у нас есть цель «приложение для медитаций» и 10 недель.
Дальше мы обычно забуриваемся в задачи, которые сейчас и начинаем фигачить. В процессе уже не чувствуем связь с целью и дедлайном, который поставили. И в итоге чаще всего нас в конце ждет жопа или мы вообще ничего не запускаем.
Чтобы этого избежать, существует обратное планирование. Это когда мы сформулировав цель и дедлайн, начинаем расписывать что нам нужно сделать каждую неделю, чтобы приблизиться к результату. Почему с конца — потому что так проще не залезть в дебри.
Например, если у нас на 10-й неделе запуск, то когда у нас будет тестовая версия. Допустим на 7 неделе. Тогда на 8 и 9 у нас будут правки. А что нам нужно предпринять, чтобы получить на 7 неделе тестовую версию? На 6 у нас должна быть верстка, на 5 что-то еще и т.д.
Так появляются опорные пункты и понимание насколько реалистичный у нас дедлайн. Я в этот момент люблю еще почеленджить рисками, что может пойти не так на каждой из недель и подстелить соломки.
Важно понимать, что это план, а не высеченное в камне. Дальше, мы используем эджайл и ФФФ и уточняем каждую неделю.
Но у нас уходит история с пропастью между целью и тем, что мы сейчас на первой неделе из 10. Мы делаем базовую проверку и обретаем опору в том, что делаем.
Когда мне говорят, что есть штуки, которые вообще нельзя предсказать, я теперь рассказываю о кейсе из моего наставничества, когда команда ученых научилась предсказывать результаты экспериментов.
За 9 недель мы с ребятами прошли путь с «мы ничего не можем предсказать, мы в полной неизвестности» до «мы что-то уже можем предсказать с какой-то погрешностью».Они стали в план записывать свои гипотезы и предсказывать их вероятности. И их деятельность стала предсказуемой и понятной для них самих и бизнеса, в котором они работают.
#управление_проектами, #книги
Если бы меня спросили, на чем сфокусироваться, если я хочу прокачать свои навыки управления проектами, я бы назвала три штуки:
1/ умение видеть и убирать препятствия вместо того, чтобы быть пинателем
2/ умение работать с рисками: уметь их находить и стелить солому,
3/ и уметь планировать от обратного
О первых двух я уже как-то рассказывала на канале, а о последнем пока нет. Мне всегда казалось, что это самое простое, но практически все мои клиенты, которые приходят в наставничество или консалтинг сталкиваются именно с ним.
Впервые с этим термином я столкнулась в древней книге «Уходим в отрыв» (глава 2). Ее автор говорит о том, что когда мы решили делать проект, мы обычно формулируем цель, а потом пытаемся выстроить последовательность шагов, чтобы ее достичь. И сначала нам что-то понятно, но ближе к цели становится сложно.
Нам нужно, например, запустить новое мобильное приложение для медитаций. Мы решили, что хотим его сделать за 10 недель. Т.е у нас есть цель «приложение для медитаций» и 10 недель.
Дальше мы обычно забуриваемся в задачи, которые сейчас и начинаем фигачить. В процессе уже не чувствуем связь с целью и дедлайном, который поставили. И в итоге чаще всего нас в конце ждет жопа или мы вообще ничего не запускаем.
Чтобы этого избежать, существует обратное планирование. Это когда мы сформулировав цель и дедлайн, начинаем расписывать что нам нужно сделать каждую неделю, чтобы приблизиться к результату. Почему с конца — потому что так проще не залезть в дебри.
Например, если у нас на 10-й неделе запуск, то когда у нас будет тестовая версия. Допустим на 7 неделе. Тогда на 8 и 9 у нас будут правки. А что нам нужно предпринять, чтобы получить на 7 неделе тестовую версию? На 6 у нас должна быть верстка, на 5 что-то еще и т.д.
Так появляются опорные пункты и понимание насколько реалистичный у нас дедлайн. Я в этот момент люблю еще почеленджить рисками, что может пойти не так на каждой из недель и подстелить соломки.
Важно понимать, что это план, а не высеченное в камне. Дальше, мы используем эджайл и ФФФ и уточняем каждую неделю.
Но у нас уходит история с пропастью между целью и тем, что мы сейчас на первой неделе из 10. Мы делаем базовую проверку и обретаем опору в том, что делаем.
Когда мне говорят, что есть штуки, которые вообще нельзя предсказать, я теперь рассказываю о кейсе из моего наставничества, когда команда ученых научилась предсказывать результаты экспериментов.
За 9 недель мы с ребятами прошли путь с «мы ничего не можем предсказать, мы в полной неизвестности» до «мы что-то уже можем предсказать с какой-то погрешностью».Они стали в план записывать свои гипотезы и предсказывать их вероятности. И их деятельность стала предсказуемой и понятной для них самих и бизнеса, в котором они работают.
#управление_проектами, #книги
Толерантность к ошибкам: не ошибается только тот, кто ничего не делает.
Вчерашний вечер принес столько факапов, что, пожалуй, больше, чем за предыдущие месяцы. Короче, давно я так не обсиралась.
Началось все с вебинара по developer experience, который мы проводили вчера с Федей.
Сначала зум начал показывать фокусы. То он решил пережать качество картинки до такой степени, что презентация стала тупо нечитабельной. Потом меня пару раз выбросило из зума, из-за чего стиралась вся история чата, а мне надо было за ними следить. Еще периодически искажался звук, благо в моменты, когда не я говорила. Закончилось классикой — обновлением зума!
Еще я узнала, что запись, которую мы делали сделалась отдельно звук и картинка. Пришлось срочно отправлять на монтаж, чтобы как можно скорее отдать ребятам. Потом сам контент веба — половине очень понравилась, половина поставили ниже оценки, чем бывает. А я ожидала большего.
И, как вишенка на торте, пост Вани Замесина о краш-курсе, который вышел вечером. И внезапно оказалось, что почему-то люди на мобильной версии видели старую цену, которая пересчитывалась при покупке. Беда в том, что цены мы поменяли давным-давно и никто нам не писал, что что-то не так. Покупки падали и мы ничего необычного не замечали. В общем, Андрею пришлось разбираться, а нам с Ритой сапортить и извиняться.
Когда все это происходило я хватала дикую тревогу и стыд. Типа, какого черта, ты блин 15 лет делаешь новое, а тут такие детские косяки. «Не могла проверить, что ли?» или «Сколько можно ошибаться, ты же столько времени уже в этом деле?». «И вообще ты учишь людей прорабатывать риски, а сама что?».
Потом я подышала немного, успокоилась и напомнила важную мысль: не ошибается только то, кто ничего не делает. Проще всего сидеть и комментировать то, что у кого-то не получилось. А вот пойти и сделать может не каждый.
Ошибки — это сигнал того, что ты не стоишь на месте. Важно не тот факт, что ты ошибся, а то какие выводы и действия ты сделал после. А у тебя уже целый список, что нужно в следующий раз сделать.
Ты проработала видимые риски, но всегда могут быть те, которые ты не учла. Если ты учишь других, это не делает тебя неоспоримым экспертом в этой теме. Ошибаются все.
В общем, послание в будущее: в следующий раз, когда будешь третировать себя за ошибку — делай это в более щадящем режиме. И не позволяй настроению от того, что ты просрала —затмить твои заслуги: вебинар классный и ты знаешь, что сделать, чтобы было лучше. Получить ревью Вани Замесина на твой продукт тоже круто. Если ты сфокусируешь только на провалах — потеряешь эту классную энергию достижения, а значит новых может уже и не быть.
#управление_проектами, #принципы_работы
Вчерашний вечер принес столько факапов, что, пожалуй, больше, чем за предыдущие месяцы. Короче, давно я так не обсиралась.
Началось все с вебинара по developer experience, который мы проводили вчера с Федей.
Сначала зум начал показывать фокусы. То он решил пережать качество картинки до такой степени, что презентация стала тупо нечитабельной. Потом меня пару раз выбросило из зума, из-за чего стиралась вся история чата, а мне надо было за ними следить. Еще периодически искажался звук, благо в моменты, когда не я говорила. Закончилось классикой — обновлением зума!
Еще я узнала, что запись, которую мы делали сделалась отдельно звук и картинка. Пришлось срочно отправлять на монтаж, чтобы как можно скорее отдать ребятам. Потом сам контент веба — половине очень понравилась, половина поставили ниже оценки, чем бывает. А я ожидала большего.
И, как вишенка на торте, пост Вани Замесина о краш-курсе, который вышел вечером. И внезапно оказалось, что почему-то люди на мобильной версии видели старую цену, которая пересчитывалась при покупке. Беда в том, что цены мы поменяли давным-давно и никто нам не писал, что что-то не так. Покупки падали и мы ничего необычного не замечали. В общем, Андрею пришлось разбираться, а нам с Ритой сапортить и извиняться.
Когда все это происходило я хватала дикую тревогу и стыд. Типа, какого черта, ты блин 15 лет делаешь новое, а тут такие детские косяки. «Не могла проверить, что ли?» или «Сколько можно ошибаться, ты же столько времени уже в этом деле?». «И вообще ты учишь людей прорабатывать риски, а сама что?».
Потом я подышала немного, успокоилась и напомнила важную мысль: не ошибается только то, кто ничего не делает. Проще всего сидеть и комментировать то, что у кого-то не получилось. А вот пойти и сделать может не каждый.
Ошибки — это сигнал того, что ты не стоишь на месте. Важно не тот факт, что ты ошибся, а то какие выводы и действия ты сделал после. А у тебя уже целый список, что нужно в следующий раз сделать.
Ты проработала видимые риски, но всегда могут быть те, которые ты не учла. Если ты учишь других, это не делает тебя неоспоримым экспертом в этой теме. Ошибаются все.
В общем, послание в будущее: в следующий раз, когда будешь третировать себя за ошибку — делай это в более щадящем режиме. И не позволяй настроению от того, что ты просрала —затмить твои заслуги: вебинар классный и ты знаешь, что сделать, чтобы было лучше. Получить ревью Вани Замесина на твой продукт тоже круто. Если ты сфокусируешь только на провалах — потеряешь эту классную энергию достижения, а значит новых может уже и не быть.
#управление_проектами, #принципы_работы
Не доделывать в ночь перед запуском и не трястись в процессе
Недавно начала смотреть сериал The Bear и в 7-м эпизоде первого сезона я увидела себя. Точнее то, как раньше я запускала проекты. И что считала нормой.
Прежде чем рассказать почему, расскажу немного контекста из сериала, чтобы вы понимали о чем я. Без спойлеров, если в друг решите посмотреть целиком (очень рекомендую).
В общем главный герой, именитый шеф возвращается в ресторан своего брата и пытается наладить его дела, потому что они годами идут не очень. У него появляется талантливый су-шеф, который постоянно предлагает классные идеи. Одна из них — запустить предзаказ блюд через интернет.
И вот они запускают, им начинает падать очень много заказов, к которым они совсем не готовы. Я нашла в ютубе 2-мин отрывок. Обязательно посмотрите, чтобы прочувствовать все.
Часть сотрудников даже не в курсе, что у них планировалась фича. Все начинают жестко орать на друг друга и пытаться что-то делать, как-то спасать ситуацию. Заказы перемешиваются, блюда роняются на пол, творится полный хаос. Чем все закончилось, не буду говорить, чтобы не спойлерить.
Когда я смотрела этот кусок, казалось, что это про меня 7-10 лет назад. Так у меня происходил каждый запуск. Я всегда была центром информации в проекте, ко мне всегда все ходили чтобы что-то узнать или согласовать. Никто лучше меня не знает. И рассказывать всем некогда, по ходу дела разберемся — надо работу делать. Это все еще приправлялось хаосом внутри, какими-то моими набегами «давай все переделаем» или «я хотела по-другому», что способствовало переработке по ночам и напряжению в команде.
Я думала, что это нормально, это ведь запуск. И все делаю правильно: во имя качества продукта и счастья клиента. Ничего, что мы тут все страдаем.
А потом узнала о существовании Walnut Model, которая описывала групповую динамику. На ней четко показывалось, насколько важны процессы, согласованность в команде, понимание ролей.
Модель противоречила ключевому моему паттерну: каждый раз, когда мы начинали проект, я скипала обсуждения ролей, процессов, хотя люди каждый раз задавали все эти вопросы. Я либо сливалась либо делала это для галочки искренне считая ерундой. Ведь главное надо работу делать, «нам некогда».
На иллюстрации было четко видно, что такой паттерн закапывает проекты или заставляет тащить их на зубах. Я сильно вдохновилась и начала пробовать.
В итоге, стала затаскивать проекты с большей сложностью и непредсказуемостью. И не по ночам и в напряге. А с чувством поддержки команды. Все стало слаженым и стало не страшно ходить в отпуск.
Если у вас такой же паттерн, как был у меня:
1/ Знайте, что может быть по-другому. Страдать необязательно.
2/ Почитайте статью про Walnut Model, а если не сможете применить — почитайте краш-курс. Там в 6 письме, кейс Антохи, которому я по костям разбираю эту задачу и помогаю все настроить. И кроме модели там еще куча всего полезного. Не пожалеете
#управление_проектами, #команда
Недавно начала смотреть сериал The Bear и в 7-м эпизоде первого сезона я увидела себя. Точнее то, как раньше я запускала проекты. И что считала нормой.
Прежде чем рассказать почему, расскажу немного контекста из сериала, чтобы вы понимали о чем я. Без спойлеров, если в друг решите посмотреть целиком (очень рекомендую).
В общем главный герой, именитый шеф возвращается в ресторан своего брата и пытается наладить его дела, потому что они годами идут не очень. У него появляется талантливый су-шеф, который постоянно предлагает классные идеи. Одна из них — запустить предзаказ блюд через интернет.
И вот они запускают, им начинает падать очень много заказов, к которым они совсем не готовы. Я нашла в ютубе 2-мин отрывок. Обязательно посмотрите, чтобы прочувствовать все.
Часть сотрудников даже не в курсе, что у них планировалась фича. Все начинают жестко орать на друг друга и пытаться что-то делать, как-то спасать ситуацию. Заказы перемешиваются, блюда роняются на пол, творится полный хаос. Чем все закончилось, не буду говорить, чтобы не спойлерить.
Когда я смотрела этот кусок, казалось, что это про меня 7-10 лет назад. Так у меня происходил каждый запуск. Я всегда была центром информации в проекте, ко мне всегда все ходили чтобы что-то узнать или согласовать. Никто лучше меня не знает. И рассказывать всем некогда, по ходу дела разберемся — надо работу делать. Это все еще приправлялось хаосом внутри, какими-то моими набегами «давай все переделаем» или «я хотела по-другому», что способствовало переработке по ночам и напряжению в команде.
Я думала, что это нормально, это ведь запуск. И все делаю правильно: во имя качества продукта и счастья клиента. Ничего, что мы тут все страдаем.
А потом узнала о существовании Walnut Model, которая описывала групповую динамику. На ней четко показывалось, насколько важны процессы, согласованность в команде, понимание ролей.
Модель противоречила ключевому моему паттерну: каждый раз, когда мы начинали проект, я скипала обсуждения ролей, процессов, хотя люди каждый раз задавали все эти вопросы. Я либо сливалась либо делала это для галочки искренне считая ерундой. Ведь главное надо работу делать, «нам некогда».
На иллюстрации было четко видно, что такой паттерн закапывает проекты или заставляет тащить их на зубах. Я сильно вдохновилась и начала пробовать.
В итоге, стала затаскивать проекты с большей сложностью и непредсказуемостью. И не по ночам и в напряге. А с чувством поддержки команды. Все стало слаженым и стало не страшно ходить в отпуск.
Если у вас такой же паттерн, как был у меня:
1/ Знайте, что может быть по-другому. Страдать необязательно.
2/ Почитайте статью про Walnut Model, а если не сможете применить — почитайте краш-курс. Там в 6 письме, кейс Антохи, которому я по костям разбираю эту задачу и помогаю все настроить. И кроме модели там еще куча всего полезного. Не пожалеете
#управление_проектами, #команда
Признать и исправить, а не спорить и сваливать вину
Недавно я заказала в доставке суши на ужин. Был высокий спрос и сервис обещал, что везти будут час-полтора. Мне было ок, заказывала заранее. Но когда прошло 2 часа, я позвонила и спросила где мой заказ. Он все еще был на кухне: передо мной извинились и сказали что положили в подарок моти и скоро выезжают. Я в этот момент подумала: «зачем мне моти, если мне кушать хочется». Но ладно.
Через 2,5 часа суши так и не было. Я позвонила и попросила, чтобы мой заказ отменили. Девушка извинилась и отменила заказ. Это было мое первое знакомство с этим рестораном, настроение было мягко говоря не очень: пришлось срочно готовить ужин. Я твердо решила, что больше у них заказывать не буду.
На следующее утро мне вернули деньги и я закрыла для себя эту тему. Но днем позвонил управляющий или владелец, чтобы лично извиниться. В качестве компенсации он предложил мне бесплатно прислать идентичный заказ к ужину, чтобы доказать что они могут по-другому. Мол, мы молодые и не справились с наплывом, хотим исправиться.
Я согласилась, потому что вспомнила, как делала ровно так же, когда мы строили интернет-магазин в МИФе. Тогда мы открыли магазин и не справились, через неделю закрыли. Я всю ночь писала длинные письма клиентам с извинением и компенсацией. По итогу мы все исправили и, кажется, все из пострадавших клиентов стали лояльными и покупали у нас многие годы. Не удивлюсь если до сих пор они с МИФом)
В общем, суши были у меня ровно к ужину. Даже чуть раньше. Через час, мне написал этот же мужчина и спросила обратную связь: я сказала, что мне понравилось, а что нет. У нас завязался теплый разговор.
Я верю, что у ребят все получится. С таким подходом иначе может и не быть. Они борется за каждого клиента и принимают обратную связь с благодарностью, а не делают клиента виноватым (как часто бывает). Я точно вернусь к ним спустя несколько месяцев, чтобы посмотреть, что изменилось. А могла бы просто получить деньги обратно и забыть эту историю как страшный сон.
Выводы:
1/ самое худшее, что можно бизнесу сделать — это не признавать свои ошибки, а вместо этого сваливать вину на клиента.
2/ Если вы облажались — это еще не конец света, обработайте ошибку и получите шанс заполучить лояльного клиента.
#управление_проектами, #принципы_работы
Недавно я заказала в доставке суши на ужин. Был высокий спрос и сервис обещал, что везти будут час-полтора. Мне было ок, заказывала заранее. Но когда прошло 2 часа, я позвонила и спросила где мой заказ. Он все еще был на кухне: передо мной извинились и сказали что положили в подарок моти и скоро выезжают. Я в этот момент подумала: «зачем мне моти, если мне кушать хочется». Но ладно.
Через 2,5 часа суши так и не было. Я позвонила и попросила, чтобы мой заказ отменили. Девушка извинилась и отменила заказ. Это было мое первое знакомство с этим рестораном, настроение было мягко говоря не очень: пришлось срочно готовить ужин. Я твердо решила, что больше у них заказывать не буду.
На следующее утро мне вернули деньги и я закрыла для себя эту тему. Но днем позвонил управляющий или владелец, чтобы лично извиниться. В качестве компенсации он предложил мне бесплатно прислать идентичный заказ к ужину, чтобы доказать что они могут по-другому. Мол, мы молодые и не справились с наплывом, хотим исправиться.
Я согласилась, потому что вспомнила, как делала ровно так же, когда мы строили интернет-магазин в МИФе. Тогда мы открыли магазин и не справились, через неделю закрыли. Я всю ночь писала длинные письма клиентам с извинением и компенсацией. По итогу мы все исправили и, кажется, все из пострадавших клиентов стали лояльными и покупали у нас многие годы. Не удивлюсь если до сих пор они с МИФом)
В общем, суши были у меня ровно к ужину. Даже чуть раньше. Через час, мне написал этот же мужчина и спросила обратную связь: я сказала, что мне понравилось, а что нет. У нас завязался теплый разговор.
Я верю, что у ребят все получится. С таким подходом иначе может и не быть. Они борется за каждого клиента и принимают обратную связь с благодарностью, а не делают клиента виноватым (как часто бывает). Я точно вернусь к ним спустя несколько месяцев, чтобы посмотреть, что изменилось. А могла бы просто получить деньги обратно и забыть эту историю как страшный сон.
Выводы:
1/ самое худшее, что можно бизнесу сделать — это не признавать свои ошибки, а вместо этого сваливать вину на клиента.
2/ Если вы облажались — это еще не конец света, обработайте ошибку и получите шанс заполучить лояльного клиента.
#управление_проектами, #принципы_работы
«А что если этого недостаточно?»
Каждый раз, когда я работаю над проектом, задаюсь вопросом «А что если этого недостаточно?». Чтобы ускорить получение результата или хотя бы повысить его вероятность.
Например, нужно сдать квартиру. Сначала владелец квартиры вылизывает ее, фоткает, находит риелтора и отдает ему в работу. Дальше ждет. Потому что дальше работа не его. Он все сделал.
Когда-то читала какую-то книгу о мозге, в которой говорилось, что в этот момент для мозга задача уже закрыта. Поэтому, если риелтором или обстоятельствами не повезло, квартиру можно сдавать месяцами.
Что делаю я в этом случае? Задаюсь вопросом «А что если этого недостаточно?» Что если недостаточно одного риелтора, чтобы быстро сдать квартиру? Иду искать еще риелторов.
Руководствуюсь простой математикой: один риелтор = одна база клиентов, несколько риелторов = несколько баз. Даже если они вешают объявления на одной и то же площадке — у каждого есть лимиты по публикациям (например, 3 раза в день). 3 риелтора * 3 раза/день = 9 публикаций. Вероятность повышается, чувствуете?
Теперь рабочий пример. Нужно повысить долю б2б-продаж продукта. Например, мы решили пойти назначать встречи с потенциальными клиентами, чтобы на месте делать оффер.
Все идет хорошо, но что если этого недостаточно? Что если так мы будем продавать долго? Что еще мы можем сделать? Например, добавить на сайт «приходите к нам» или написать какую-то бомбическую рассылку нашей б2с аудитории и рассказать ей чтобы приводила нам б2б.
Цикл «а что если этого недостаточно?» можно продолжать вечно в рамках каждого кейса. В квартире можно улучшать фото, или добавлять декор. В продажах продукта — запускать таргет, например. Но главное, что результат будет. Может вы потратите на него больше усилий, но зато по пути научитесь новому или получите полезные контакты.
Чтобы не было расфокуса, я пробую ответить на этот вопрос на этапе планирования проекта, генерю гипотезы и шаги, что буду делать и когда. Так спустя несколько недель проверки одной гипотезы, подключаю другую. Чтобы по пути не потерять кучу времени ожидая результата от первой.
#управление_проектами
Каждый раз, когда я работаю над проектом, задаюсь вопросом «А что если этого недостаточно?». Чтобы ускорить получение результата или хотя бы повысить его вероятность.
Например, нужно сдать квартиру. Сначала владелец квартиры вылизывает ее, фоткает, находит риелтора и отдает ему в работу. Дальше ждет. Потому что дальше работа не его. Он все сделал.
Когда-то читала какую-то книгу о мозге, в которой говорилось, что в этот момент для мозга задача уже закрыта. Поэтому, если риелтором или обстоятельствами не повезло, квартиру можно сдавать месяцами.
Что делаю я в этом случае? Задаюсь вопросом «А что если этого недостаточно?» Что если недостаточно одного риелтора, чтобы быстро сдать квартиру? Иду искать еще риелторов.
Руководствуюсь простой математикой: один риелтор = одна база клиентов, несколько риелторов = несколько баз. Даже если они вешают объявления на одной и то же площадке — у каждого есть лимиты по публикациям (например, 3 раза в день). 3 риелтора * 3 раза/день = 9 публикаций. Вероятность повышается, чувствуете?
Теперь рабочий пример. Нужно повысить долю б2б-продаж продукта. Например, мы решили пойти назначать встречи с потенциальными клиентами, чтобы на месте делать оффер.
Все идет хорошо, но что если этого недостаточно? Что если так мы будем продавать долго? Что еще мы можем сделать? Например, добавить на сайт «приходите к нам» или написать какую-то бомбическую рассылку нашей б2с аудитории и рассказать ей чтобы приводила нам б2б.
Цикл «а что если этого недостаточно?» можно продолжать вечно в рамках каждого кейса. В квартире можно улучшать фото, или добавлять декор. В продажах продукта — запускать таргет, например. Но главное, что результат будет. Может вы потратите на него больше усилий, но зато по пути научитесь новому или получите полезные контакты.
Чтобы не было расфокуса, я пробую ответить на этот вопрос на этапе планирования проекта, генерю гипотезы и шаги, что буду делать и когда. Так спустя несколько недель проверки одной гипотезы, подключаю другую. Чтобы по пути не потерять кучу времени ожидая результата от первой.
#управление_проектами
Когда я нарушаю принцип FFF
На днях выступала для сотрудников одной компании и рассказывала о типичных ошибках ведения проектов. И конечно, же упоминала мой любимый принцип FFF (Fixed budget, fixed time, flexible scope).
Для тех кто не знает, его суть заключается в том, что в управлении проектом у нас всегда есть 3 сущности: фиксированный бюджет, фиксированное время (дедлайн) и гибкий объем работы. Т.е нам важно пытаться не увеличивать косты проекта (бюджетом), вписываться в дедлайн, но мы всегда можем урезать версию продукта, который выпускаем, если первые два параметра нарушаются.
Короче, рассказываю я про FFF людям и понимаю, что не всегда следую ему. Например, из недавнего — мы пишем наш тимлидский курс. И вот на выходных мы должны были отдать второй лонгрид ранним чтецам, но не отдали, потому что я решила, что недовольна им. Типа он классный, но есть чувство «но» из-за которого, мне не хочется его выпускать.
Мы разговаривали с Федей, пытались починить малой кровью, чтобы не срывать срок и не увеличивать ресурс. Но ничего не вышло. Я поняла, что хочу сменить структуру лонгрида и донести несколько новых смыслов.
Мы приняли решение нарушить сроки и бюджет, потому что понимали, что добавив всего 20% того и другого получим на выходе в разы лучше продукт. При этом, если бы нам надо было в воскресенье отдавать лонгрид ученикам, а не первым чтецам, скорее всего бы так не сделали. Но в текущих обстоятельствах, есть немного воздуха, которым можем воспользоваться, чтобы сделать лучше.
Итого,
1/ нарушать принцип FFF имеет смысл, если уверены, что добавив немного больше ресурса и времени, вы получите значимо лучший результат. Иначе лучше сегодня на 4, чем завтра на 5.
2/ лучше иметь два дедлайна, я называю их «тихий» и «громкий запуск». Чтобы был воздух на подобные решения.
#управление_проектами
На днях выступала для сотрудников одной компании и рассказывала о типичных ошибках ведения проектов. И конечно, же упоминала мой любимый принцип FFF (Fixed budget, fixed time, flexible scope).
Для тех кто не знает, его суть заключается в том, что в управлении проектом у нас всегда есть 3 сущности: фиксированный бюджет, фиксированное время (дедлайн) и гибкий объем работы. Т.е нам важно пытаться не увеличивать косты проекта (бюджетом), вписываться в дедлайн, но мы всегда можем урезать версию продукта, который выпускаем, если первые два параметра нарушаются.
Короче, рассказываю я про FFF людям и понимаю, что не всегда следую ему. Например, из недавнего — мы пишем наш тимлидский курс. И вот на выходных мы должны были отдать второй лонгрид ранним чтецам, но не отдали, потому что я решила, что недовольна им. Типа он классный, но есть чувство «но» из-за которого, мне не хочется его выпускать.
Мы разговаривали с Федей, пытались починить малой кровью, чтобы не срывать срок и не увеличивать ресурс. Но ничего не вышло. Я поняла, что хочу сменить структуру лонгрида и донести несколько новых смыслов.
Мы приняли решение нарушить сроки и бюджет, потому что понимали, что добавив всего 20% того и другого получим на выходе в разы лучше продукт. При этом, если бы нам надо было в воскресенье отдавать лонгрид ученикам, а не первым чтецам, скорее всего бы так не сделали. Но в текущих обстоятельствах, есть немного воздуха, которым можем воспользоваться, чтобы сделать лучше.
Итого,
1/ нарушать принцип FFF имеет смысл, если уверены, что добавив немного больше ресурса и времени, вы получите значимо лучший результат. Иначе лучше сегодня на 4, чем завтра на 5.
2/ лучше иметь два дедлайна, я называю их «тихий» и «громкий запуск». Чтобы был воздух на подобные решения.
#управление_проектами
Невидимые фановые проекты
Недавно ко мне пришел сын и сказал, что хочет копить себе на Nintendo Switch. У него было часть накоплений, но недостаточно. И мы начали думать, как заработать. Например, придумали организовать ярмарку для друзей, на которой дети будут продавать еду, которую вместе приготовили с родителями, а родители покупать.
Чтобы организовать подобное мероприятие нужно продумать многое: что дети будут продавать и по какой цене, объяснить им что такое реклама и как ее делать, создать пространство, где будут продавать, собрать родителей в чат, написать анонс и т.д. Полноценный проект, как видите.
Я их называю невидимыми и фановыми: они маскируются под задачу и чаще всего выходят из желания кому-то помочь. Например, коллега Маша попросила помочь с презентацией проекта, просто послушать и дать обратную связь. Вы слушаете и понимаете, что дело шляпа — начинаете откатываться и хоп — малюсенькая встреча «послушать» превращается в полноценный проект.
Пока вы помогаете Маше, ваши личные проекты не двигаются. Потому что два дела одновременно не сделаешь. И в конце недели, вы смотрите на то что сделали — видите, что не продвинулись по работе, но то что помогали Маше либо не учитываете либо забываете. Поэтому либо еще больше начинаете вкалывать, либо сдаетесь и выгораете.
Если это про вас — просейте свою работу на предмет невидимых фановых проектов и либо легализуйте их важность, либо отрежьте. И возьмите себе за привычку раз в несколько недель смотреть не нагребли ли снова чего.
#управление_проектами
Недавно ко мне пришел сын и сказал, что хочет копить себе на Nintendo Switch. У него было часть накоплений, но недостаточно. И мы начали думать, как заработать. Например, придумали организовать ярмарку для друзей, на которой дети будут продавать еду, которую вместе приготовили с родителями, а родители покупать.
Чтобы организовать подобное мероприятие нужно продумать многое: что дети будут продавать и по какой цене, объяснить им что такое реклама и как ее делать, создать пространство, где будут продавать, собрать родителей в чат, написать анонс и т.д. Полноценный проект, как видите.
Я их называю невидимыми и фановыми: они маскируются под задачу и чаще всего выходят из желания кому-то помочь. Например, коллега Маша попросила помочь с презентацией проекта, просто послушать и дать обратную связь. Вы слушаете и понимаете, что дело шляпа — начинаете откатываться и хоп — малюсенькая встреча «послушать» превращается в полноценный проект.
Пока вы помогаете Маше, ваши личные проекты не двигаются. Потому что два дела одновременно не сделаешь. И в конце недели, вы смотрите на то что сделали — видите, что не продвинулись по работе, но то что помогали Маше либо не учитываете либо забываете. Поэтому либо еще больше начинаете вкалывать, либо сдаетесь и выгораете.
Если это про вас — просейте свою работу на предмет невидимых фановых проектов и либо легализуйте их важность, либо отрежьте. И возьмите себе за привычку раз в несколько недель смотреть не нагребли ли снова чего.
#управление_проектами
Проджектам: на что обратить внимание при поиске работы
Недавно искала проджекта в команду. Неожиданно, быстро нашли подходящую кандидатку и, надеюсь, что все сложится. Удивительно и то, что на вакансию откликнулось очень много людей, поэтому была возможность выбирать лучших из лучших. Это приятно.
Однако некоторые не прошли базовый фильтр, на мой взгляд, по небрежности или глупости. Для меня это важный показатель того, как человек будет работать на этой позиции. Обсудила этот вопрос с коллегами на рынке, и все сошлись в том, что штуки, которые опишу далее важны.
Итак, топ-3:
1/ Резюме без выполнения тестового задания, если в условиях было указано другое. В условиях вакансии было указано сделать тестовое задание, однако некоторые кандидаты отправляли только резюме, видимо, не вникая в требования.
2/ Прислали тестовое задание, но не настроили видимость, так что я не могла открыть. Запрашивала доступ только у тех, кто указал на возможность таких трудностей в сопроводительном письме потому что видно, что человек старался, но что-то в процессе пошло не так.
3/ Несоблюдение условий тестового задания. Человек старался, но в итоге результат не соответствовал требованиям.
4/ Факап дедлайнов. Дедлайн давно прошел, а я до сих пор получаю тестовые с пометкой «посмотрите, может вам подойду». Не понимаю зачем люди тратят время, если дедлайн прошел. Так же с осторожностью смотрела на тех, кто присылал в последнюю минуту. Это тоже звоночек плохой привычки, а для меня это не ок.
Вроде мелочи, но для роли проджекта, на мой взгляд, критичны: человек может прочитать задачу и выполнить наполовину, сделать по-своему или не сделать совсем, прислав что-то другое. Каждый раз придется запрашивать доступ к файлу, что усложнит коммуникацию.
Если бы не было других вариантов, я бы дала шанс исправить такие ошибки. Но когда на другой чаше весов кандидаты, которые не только справляются с тестовым, но и внимательно относятся к форматированию и пишут понятное сопроводительное письмо — таким кандидатам хочется уделять внимание.
Марьяна, в следующий раз когда придут на консультацию по этому вопросу — напомни, что эти мелочи важны. Чтобы люди не наступали на те же грабли и могли пройти базовый фильтр и претендовать на работу.
Если вы нанимаете проджектов, на что обращаете внимание при первом фильтре? Напишите в комментариях — сделаю подборку.
#команда, #управление_проектами
Недавно искала проджекта в команду. Неожиданно, быстро нашли подходящую кандидатку и, надеюсь, что все сложится. Удивительно и то, что на вакансию откликнулось очень много людей, поэтому была возможность выбирать лучших из лучших. Это приятно.
Однако некоторые не прошли базовый фильтр, на мой взгляд, по небрежности или глупости. Для меня это важный показатель того, как человек будет работать на этой позиции. Обсудила этот вопрос с коллегами на рынке, и все сошлись в том, что штуки, которые опишу далее важны.
Итак, топ-3:
1/ Резюме без выполнения тестового задания, если в условиях было указано другое. В условиях вакансии было указано сделать тестовое задание, однако некоторые кандидаты отправляли только резюме, видимо, не вникая в требования.
2/ Прислали тестовое задание, но не настроили видимость, так что я не могла открыть. Запрашивала доступ только у тех, кто указал на возможность таких трудностей в сопроводительном письме потому что видно, что человек старался, но что-то в процессе пошло не так.
3/ Несоблюдение условий тестового задания. Человек старался, но в итоге результат не соответствовал требованиям.
4/ Факап дедлайнов. Дедлайн давно прошел, а я до сих пор получаю тестовые с пометкой «посмотрите, может вам подойду». Не понимаю зачем люди тратят время, если дедлайн прошел. Так же с осторожностью смотрела на тех, кто присылал в последнюю минуту. Это тоже звоночек плохой привычки, а для меня это не ок.
Вроде мелочи, но для роли проджекта, на мой взгляд, критичны: человек может прочитать задачу и выполнить наполовину, сделать по-своему или не сделать совсем, прислав что-то другое. Каждый раз придется запрашивать доступ к файлу, что усложнит коммуникацию.
Если бы не было других вариантов, я бы дала шанс исправить такие ошибки. Но когда на другой чаше весов кандидаты, которые не только справляются с тестовым, но и внимательно относятся к форматированию и пишут понятное сопроводительное письмо — таким кандидатам хочется уделять внимание.
Марьяна, в следующий раз когда придут на консультацию по этому вопросу — напомни, что эти мелочи важны. Чтобы люди не наступали на те же грабли и могли пройти базовый фильтр и претендовать на работу.
Если вы нанимаете проджектов, на что обращаете внимание при первом фильтре? Напишите в комментариях — сделаю подборку.
#команда, #управление_проектами