Get things done для других

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

К примеру, get things done (Исчерпывающее руководство Getting Things Done (GTD) метода с примерами / Хабр) или «джедайские техники».
Да же? Все же использую? Ну? Скажите, что это так!

Ключевая фишка, что мне нравится - пиши в свою «напоминалку» простое действие, которое ты должен совершить.
Пример: мне нужно позвонить тим-лиду и обсудить с ним задачу. Часто мы, просто, вставляем тему письма в напоминалку и все.
Это сразу становится сложной задачей и мы будем откладывать ее каждый раз, пока не придет час Х.

Что мы можем сделать:
задать себе максимум контекста.
«Позвонить Максиму, проговорить отказ Алексея (архитектора) использовать rest сервисы в интеграции АС 1 и АС 2 и подготовит аргументы в пользу REST. При отказе от REST сдвиг сроков по проекту - до 3-х недель (а еще лучше, конкретную дату, а то вдруг, там майские праздники и сдвиг будет уже 5 недель или отпуск ключевого разработчика😉).»

Но! Как на счет того, чтобы точно также давать всю необходимую информацию другим?
Частая причина, почему вам кто-то не отвечает: ваше письмо/задача не понятны и человек все время откладывает ее выполнение.
Помогите ему.
К примеру, вы хотите, чтобы аналитик данных дал вам прогноз на текущий год по количеству входов в вашу систему.
Как ему помочь?

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

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

#career

@badtechproject

Крутые продукты подтверждают, что начинать всегда нужно с MVP, а не с космолета.
Что бы вы ни делали: трансформировали процесс, запускали новый продукт, учились чему-то новому.

Выбирайте базовые вещи и постепенно развивайте их.

Сейчас модно говорить о продуктах с точки зрения продуктовых менеджеров: новые фичи и т.п.

А что есть продукт руководителя?
«Здоровье» его команды, результаты его команды и процессы, которые он выстроил.

Да-да, процессы, площадки для синхронизаций и т.п. тоже являются продуктом руководителя.

@badtechproject

Здравый смысл в проектном управлении

Хорошая статья на тему того, на чем должен фокусироваться РМ в своей работает:
Здравый смысл и помни о смерти. Что действительно нужно проджект-менеджеру

Ключевое с чем я согласен:
👉🏼спонсор проекта ключевая фигура. Слабый спонсор, проект может не прийти к успеху
👉🏼Строй коммуникации со спонсором проекта: он поможет ускориться и решить все вопросы
🫡Получил приказ, не спеши приступать, может еще отменят.
👉🏼Soft skills - ключевой навык.
👉🏼Здравый смысл - это то, что помогает определить любые приоритеты.

@badtechproject

Ключевые задачи спонсора проекта

Спонсор проекта - одна из самых важных ролей (не в смысле бигбосс в замке из слоновой кости, а лицо, которое помогает двигать проект вперед). Рефлексируя недавно над одной из программ, что есть в портфеле я думал «почему у нас так долго принимаются решения» и вот ответ: руководитель программы не выделил явно спонсора.

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

Назначение руководителя проекта (ПМ) — необходимо убедиться, что ПМ понимает свою роль, задачи и полномочия.

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

Поддержка руководителя проекта — быть доступным для встреч и консультаций.

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

Активное продвижение проекта — активно продвигать проект внутри организации, демонстрируя его значимость и будущие выгоды.

Наставничество менеджера проекта — делиться своим опытом.

Согласование ключевых изменений — влияющих на результаты проекта.

Мониторинг и анализ прогресса — на регулярной основе.

Празднование успеха проекта — награждение команды и менеджера.

@badtechproject

«Села батарейка»🪫

Понравилась статья NUPP :: Nearly Universal Principles of Projects.
В ней на пальцах объясняется, основные принципы управления своим временем, фокусом и энергией.

Что я бы выделил:
🔋усталость от принятия решений: расходуйте свою энергию на важные дела. Микроменеджмент высасывает вашу энергию и не дает возможность принимать верные и действительно важные решения
🔋береги свою команду: да-да, это ваша обязанность как менеджера.
🔋береги себя: спи достаточно, ешь правильную пищу, занимайся спортом, занимайся семьей.
Банально? Так и нет никакой серебряной пули.

#личное #career

@badtechproject

Распространённые ошибки при обсуждении целей проекта

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

Проведите рабочую встречу так, чтобы помочь всем сосредоточиться на конечных результатах, а не на деталях реализации. Чтобы добиться этого, описывайте результаты существительными, а не глаголами. Иногда может помочь mind map — визуализирует иерархическую структуру проекта.

Mind Mapping, или как заставить свой мозг работать лучше / Хабр

@badtechproject

#пятничное
@badtechproject

Микроменеджмент 🧟

👉🏼Нет ничего более странного, чем менеджер, бездарно тратящий время, контролируя каждый шаг сотрудника и диктующий ему, как работать.
👉🏼Если я, как менеджер, уже разобрался в работе человека, в нюансах его задачи, то зачем мне нужен этот человек?
👉🏼Если вы стали менеджером, то ваше время стоит тратить на менеджмент: выстраивание эффективной команды и выравнивание процессов.
👉🏼Хотите быть уверены, что не потеряете компетенцию эксперта? Возьмите себе небольшой проект, на крайний случай.

@badtechproject

Хорошая подборка вакансий для PM’ов

https://facancy.ru/vacancies/18-vakansii-dlia-project-menedzherov-v-krupnykh-kompaniiakh

@badtechproject

Метод MoSCoW: учимся фокусироваться на главном🌇

Недавно узнал об одном из методов приоритизации, который используется в p3express.
Ничего особенного, на самом деле в нем нет, но вдруг, кому-то понравится из-за названия😁

Впервые этот метод стали применять в Oracle UK в 1994 году, после чего он стал неотъемлемой частью DSDM (Dynamic Systems Development Method: https://ru.wikipedia.org/wiki/DSDM).

Все задачи или требования делятся на 4 категории: must, should, could, would.
• Must – то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе.
• Should – не самые важные требования, но они тоже должны быть выполнены. Естественно, после реализации «must».
• Could – желательные требования, которые можно сделать, если останется время и будут ресурсы.
• Would – требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вреда для продукта.

@badtechproject

Шаблоны - сила 💪

Шаблоны — это это то, что позволяет сократить time to market и масштабировать решения с наименьшими затратами ресурсов. Шаблонов бояться не нужно - это один из лучших инструментов для старта работы.

👉🏼 Имейте шаблонный набор для агенды. К примеру такие разделы:
📍 Обязательные участники
📍 Цель встречи
📍 Текущий статус
📍 Следующие шаги
📍 Открытые вопросы

👉🏼 Имейте шаблон для первого письма при онбординге сотрудника.

👉🏼 Имейте шаблон для задачи в JIRA.

👉🏼 Имейте шаблон письма при уходе в отпуск.

Шаблоны позволяют не забывать что-то важное, шаблоны наталкивают на мысль.

Шаблоны - это круто!

@badtechproject
#projectmanagement #productmanagement #SOFTWARE #PO #PM #TPM #CAREER

Сложные подчиненные

«Одной из основных причин появления у нас в коллективах сложных подчиненных оказывается… является сам руководитель, который где-то не заметил успехов сотрудника и не похвалил его, где-то в мелочах не пошел навстречу, где-то сам спровоцировал, где-то публично покритиковал, где-то перестал приходить вовремя на работу, где-то пообещал и не выполнил, а где-то поставил задачу и не проверил, как она выполняется.»

Максим Батырев: «Сложные подчиненные. Практика российских руководителей.»

@badtechproject

Токсичность или требовательность?

В какой момент требовательность результата стала токсичностью?

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

Каждый раз, когда приходится начинать обсуждение постановки четких целей, дедлайнов и т.п., людям начинает казаться, что ты слишком токсичен.
Хм…разве результат - это не то, для чего мы работаем?
А собери 5 разных лидеров продукта и спроси о целях, которых мы стремимся достичь и услышишь 5 разных мнений.

Свою работу надо ориентировать на достижение результата, а не на имитацию.

@badtechproject