🤬 Почему пользователи ненавидят вашу документацию

Обратная связь от читателей-пользователей далеко не всегда бывает конструктивной и вдохновляющей. Почему же так получается? Маловероятно, что кто-то из технических писателей хочет специально выдать плохой документ. Скорее наоборот - авторы изо всех сил стараются, чтобы документация была полезной, понятной и удобной. Но, несмотря на все усилия, идеальный результат получается далеко не всегда.

LinkedIn: Александр Клименков, Tech Lead - Bercut

📖 Читать статью (~7 минут)

📖 @pmbbk / #meme

😨 Ответственность

С кандидатами-технарями я начинаю собеседование с простенького кейса:

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

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

Кандидаты бывают разные. Плохие доверяют разработчикам и устанавливают в продакшен. Хорошие - нет. Но есть еще одна категория кандидатов, малочисленная, но моя любимая. С ними происходит такой диалог:

- Как вы поступите?
- Я организую совещание!
- Совещание? И кого вы пригласите?
- Своего тимлида и представителя разработки. А еще кого-то от бизнеса.
- Почему?
- Хочу, чтобы все они приняли решение, ставить без тестирования или нет.
- Как совещание поможет? Разработчики уже высказались: они за установку без теста. Тимлид должен решать за вас?
- Тимлид опытнее и умнее меня...
- Но ведь это ваша задача, не так ли? Ок, а люди от бизнеса зачем? Они вообще ничего про ваши трудности знать не обязаны, им результат нужен.
- Пусть они тоже участвуют в принятии решения...
- То есть, если что-то пойдет не так, вы скажете, что это было коллективное решение, согласованное с вашим руководителем и бизнесом? И вы не виноваты? И для этого совещание?
- Да! Как скажут, так и сделаю!

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

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

Сам таких не нанимаю и вам не советую.

📖 @pmbbk / #idea

📖 @pmbbk / #meme

💸 Как ошибка ChatGPT стоила нам $10 000

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

LinkedIn: Asim Shrestha, Co-Founder & CEO - Reworkd AI

🇷🇺 Читать статью (~4 минут)

📖 @pmbbk / #meme

👾 Мета-ретроспектива

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

LinkedIn: Stefan Wolpers, Professional Scrum Trainer & Agile Coach - Berlin Product People GmbH

🇷🇺 Читать статью (~4 минут)

📖 @pmbbk / #meme

📖 @pmbbk / #meme

☠️ Scrum - рак убивающий индустрию

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

LinkedIn: Илья Казначеев, Lead Cloud and Applications Architect - Capgemini

🇷🇺 Читать статью (~7 минут)

📖 @pmbbk / #meme

📖 @pmbbk / #meme

🤹 5 стратегий управления мультипроектами

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

LinkedIn: Yasmina Khelifi, Senior Project Manager - Orange

🇷🇺 Читать статью (~6 минут)

📖 @pmbbk / #meme

🤔 Что вы делаете в первую очередь, когда вам назначают проект?

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

EAS893:

Паниковать.

chocolatedodo:

Пожаловаться своему менеджеру, что я уже перегружен.

AnAttackPenguin:

Открыть новую бутылку водки.

MisterGubbins:

Сначала решить практические вопросы. Установить дату начала, дату окончания, бюджет, объем работ. Что уже формально согласовано/документировано. Недавно я взялся за проект, который формально должен был начаться за 6 недель до этого! Это сразу же риск. Затем определите заинтересованные стороны, понимание и ожидания которых нужно получить.

pmpdaddyio:

Прочитать объем работ (SOW) или контракт. Такой же ответ, который я даю каждый раз, когда это спрашивают.

X_Comanche_Moon:

Всё зависит от вашей организации. Начните с организации вводного собрания с самыми важными заинтересованными сторонами, чтобы начать. Понимайте суть проекта, ресурсы, бюджет и т. д. Затем начните создавать устав проекта и т. д., после чего проведите обзор и запуск устава. Удачи с вашим первым проектом и помните, что менеджеры проектов НЕ ДЕЛАЮТ ВСЁ. Используйте своих экспертов-специалистов и держите их ответственными. Пишите в личные сообщения, если вам нужна помощь.

Aekt1993:

Вы спросили о "абсолютно первом", так что это понимание устава проекта/делового случая и определение ваших заинтересованных сторон.

phobos2deimos:

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

CognitiveAlchemy:

Задайте себе вопрос: Какая проблема должна быть решена? Какие желаемые результаты? Сначала общая картина. Затем углубляйтесь в детали.

MisguidedSoul:

Настройте папки своего проекта, журналы RAID и инструменты, затем возьмите SOW или Business Case и начните читать. Затем выстройте диалог со спонсором, чтобы убедиться, что я правильно понял объем работ или Business Case, и иду оттуда.

dgeniesse:

Понять объем работ. Затем работать с командой, чтобы понять основные деятельности. И разработка расписания, работа с командой для определения потока деятельности. Например, есть ли взаимосвязи. Затем разработка простого расписания.

C4ptainchr0nic:

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

essmithsd:

Определить команду - кто является владельцем продукта? Кто ответственен за исполнение? Кто заинтересованные стороны? Кто конечные пользователи? Какова заявленная цель / результаты для данного проекта, и каковы сроки? - У нас есть время / ресурсы, чтобы достичь целей? Мы уже разработали / определили объем работ? Работаем обратно от доставки, определяем высокоуровневые вехи / результаты и продолжаем разбивать их.

Impossible_Ad_3146:

Найдите всех спонсоров и потенциальных клиентов в LinkedIn.

📖 @pmbbk / #reddit

📖 @pmbbk / #meme

🔭 Как отслеживать проекты и выводы реальной катастрофы

Неправильное отслеживание проекта может быстро выйти из строя - достаточно взглянуть на фиаско Taylor Swift. Если кажется, что ваш собственный проект обречен на провал, возможно, пришло время пересмотреть методы отслеживания. Делимся примером того, как неэффективное отслеживание запятнало репутацию долгожданного концерта одной знаменитости. А также расскажем, почему отслеживание проектов жизненно важно, как эффективно отслеживать проекты, что вам нужно и чего следует избегать.

LinkedIn: Moira Alexander, Founder - PMWorld 360 Magazine

📖 Читать статью (~9 минут)

📖 @pmbbk / #meme

🚲 MVP - поиск баланса между минимумом и жизнеспособностью

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

LinkedIn: Prasoon Vidyarthi, Vice President Of Product Management - LPL Financial

📖 Читать статью (~3 минут)

📖 @pmbbk / #meme

💀 Я хочу, чтобы ты умер

Начинающие менеджеры не всегда понимают, но самое трудное в нашей профессии - это увольнять.

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

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

А в конце, по условиям игры, лидер должен избавиться от одного из членов команды - выкинуть его в открытый космос. Руководитель обязан подойти к человеку и, глядя ему в глаза, четко и громко произнести: "Я хочу, чтобы ты умер".

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

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

Уволить сотрудника, который не справляется с работой и создает проблемы для проекта, ещё можно. Но иногда менеджеру приходится увольнять человека, который не сделал ничего плохого ни команде, ни компании. Работник выполняет свои обязанности качественно и профессионально. Но изменились рыночные условия. Или начался очередной кризис, а продукт не оправдал ожиданий. Или у компании изменилась стратегия. Или её купили. Мало ли что может произойти.

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

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

Но в какой-то момент менеджеру придётся взглянуть в глаза сотруднику и выпроводить его в открытый космос.

📖 @pmbbk / #idea