скачать книгу бесплатно
1. О чем будет идти речь? (предмет)
2. Какую проблему вы решаете? (вопрос)
3. Каково решение вашей проблемы? (ответ – это и есть главная идея выступления)
4. Какова на данный момент ситуация в этой сфере?
5. Какие существуют трудности?
6. Выявлена ли проблема и решается ли она уже как-то?
Инструмент может быть основой для написания коммерческих предложений, презентаций к бизнес-плану, сообщения об изменениях для персонала компании и т. д.
Структура презентации на основе пирамиды Минто
Пирамида Минто – метод структурирования информации, разработанный Барбарой Минто, консультантом McKinsey & Company. Этот метод помогает эффективно представить информацию, делая её более понятной и убедительной для аудитории.
Основные принципы пирамиды Минто:
1. Главная идея наверху: начинайте с основной мысли или заключения. Это позволяет аудитории сразу понять, о чём идёт речь и почему это важно. Так называемый индуктивный метод размышления.
2. Поддерживающие аргументы: под основной идеей размещаются ключевые аргументы или основные пункты, которые поддерживают главную мысль. Эти аргументы должны быть логически связаны и структурированы.
3. Детали и доказательства: под каждым ключевым аргументом располагаются более детализированные данные, примеры и доказательства, которые подкрепляют каждый из этих аргументов.
Пример применения пирамиды Минто:
1. Главная идея: Компания должна инвестировать в разработку нового продукта.
2. Ключевые аргументы:
Рынок: Существует высокий спрос на этот продукт.
Конкуренция: Конкуренты уже работают в этом направлении.
Рентабельность: Ожидаемая прибыль превышает затраты на разработку.
3. Детали и доказательства:
Рынок: Исследования показывают, что 70% потребителей заинтересованы в этом продукте.
Конкуренция: Три основных конкурента уже запустили аналогичные продукты.
Рентабельность: Финансовый анализ показывает, что инвестиции окупятся в течение двух лет.
ИС – Историй (пользовательская история)
Фаза реакции: фаза реализации
Область реакции: продукт
Валентность (уровень вовлеченности): проектная команда
Периодичность: раз в проект
User stories (пользовательские истории) – это техническое задание. В целом, его можно использовать как шаблон для требований заказчиков или пользователей.
Пользовательская история – формулировка требований и намерений. Пользовательская история не является самым детальным описанием требований, это, скорее, хотелка того, что нужно сделать, чего хотелось бы достигнуть и так далее. Обычно техническое задание пишется отдельно, а уже на основании пользовательской истории разработчики, команда могут спланировать работы и подготовить технический проект. Конечно, мы здесь никогда не увидим каких-то деталей, детализированного описания поведения системы или её технических характеристик, потому что пользовательская история – это требование от пользователя, глубоко не погруженного в технические дебри разработки. Язык пользовательской истории – простой. Позже на основании пользовательских историй, мы, во-первых, создаем бэклог нашего продукта, планируем спринт и идем в разработку.
Принцип INVEST в подготовке пользовательских историй:
Согласно Wikipedia аббревиатура INVEST была разработана в 2003 году Биллом Уэйком как напоминание о том, какой должна быть хорошая пользовательская история. На данный момент этот подход стал стандартом де-факто и активно применяется в проектах с применением SCRUM, Kanban и XP.
Пользовательские истории должны быть ясными, короткими и очень точными, они должны быть понятны как разработчику, так и заказчику. Поэтому чаще всего используется простой бытовой язык. По сути, это небольшие инкременты, которые мы набираем для реализации в спринт.
Пользовательская история должна быть независимой от других пользовательских историй.
Она должна быть обсуждаемой. Заказчик сформулировал свои хотелки в пользовательской истории, но мы должны понимать, что у разработчика может быть альтернативное, более простое или более логичное решение.
Конечно, требование должно быть полезным, должно приносить какую-то ценность нашей системе в целом.
История должна быть оцениваемой, то есть измеримой как в количестве, так и в качестве, или и в том, и в другом.
Она должна быть очень компактной, явно это не пользовательская история длинной в спринт или больше. История должна быть относительно маленькой, чтобы поместиться в спринт, и чтобы она не занимала все время разработчика.
История должна быть тестируемой.
Что делать потом с пользовательскими историями?
С этим уже работают непосредственно разработчики. Они переносят истории на канбан-доску, где набирают задачи в спринт по объему и по приоритетам.
Чтобы историями было удобно управлять, администратор должен регламентировать работу с пользовательскими историями. Это значит, что вы должны прописать следующие три совершенно фундаментальные важные вещи, а все остальное на ваше усмотрение:
Первое – форма пользовательской истории. Эта форма будет в каком-то документе, в Trello или в другом формате.
Второе – легенда, то есть как расставляется приоритет, как определяется размер, в каких единицах и так далее. Это очень важная вещь.
Третье – должно быть описано, каким образом заполняется пользовательская история и как она поступает в разработку. Допустим, от заказчика приходит запрос на изменение от администратора. Ему отправляется форма пользовательской истории, заказчик заполняет её, и пользовательская история возвращается к администратору. Администратор проверяет её на наличие всех необходимых данных и отправляет разработчику с запросом на обратную связь – принимает ли он эту пользовательскую историю или нет. Если разработчик не принимает историю, он должен предоставить четкие комментарии. Администратор, в свою очередь, должен отправить эти комментарии заказчику.
Совершенно точно должна быть указана роль пользователя.
Для администратора это важно, так как вы будете знать, к кому обратиться за уточнениями, и кто будет работать с приемкой результата. Для разработчика важно понимать, кто будет выполнять определенные задачи в этой системе. От роли пользователя может зависеть упрощенная система реализации требований; разработчики могут предложить альтернативные варианты, такие как список ограничений для разных уровней пользователей.
Например, если линейный специалист работает в системе и формирует запрос на изменение, которое откроет ему доступ к данным других филиалов, то разработчики могут увидеть, что у его роли есть ограничение на получение информации о других филиалах, и они не смогут принять эту пользовательскую историю, хотя запрос был верным. То есть в этом случае вопрос должен быть решен на более высоком уровне – на уровне руководства – чтобы определить, открываем ли мы информацию линейным специалистам или нет.
Желательно проверять, чтобы были указаны возможность и желание, не просто история «Я хочу», а «Я хочу, чтобы у меня была возможность». Такая формулировка помогает более точно и конкретно обозначить требования.
Обязательно должна быть указана функциональность системы – нужно понимать, что система должна уметь делать. Не описание того, как система выполняет функции с технической точки зрения, а именно что делает система. Это очень важно, так как помогает пользователям сформулировать более точные требования и желания.
Лицевая сторона карточки
Оборотная сторона карточки, которая используется на ревью или во время тестирования
Хорошая пользовательская история должна содержать указание/обоснование. Разрабатывая шаблон пользовательской истории, вы всегда можете подсказать: «А давайте добавим строку про обоснования, давайте добавим строку с вопросом – какую ценность это добавит нашей системе».
Пример сортировки пользовательских историй в Excel
Пример сортировки пользовательских историй в Excel
ПФ – Портфелий (портфель проектов)
Фаза реакции: фаза инициации
Область реакции: административная функция
Валентность (уровень вовлеченности): основные стейкхолдеры
Периодичность: раз в месяц
У нас есть документ для управления загрузкой, который релевантен для программ проектов или портфеля проектов. Для одного проекта в таком документе нет необходимости. Когда проекты между собой не очень связаны, нам нужно понимать, где задействованы наши специалисты. Этот документ называется шаблоном управления портфелем проектов.
У нас есть легенда, из которой мы делаем выпадающие списки. Этот документ нужен для управления человеческими ресурсами. В выпадающих списках зашиты фамилии участников проектной команды, артикулы проектов, ничего не нужно записывать. Код проекта вводится вручную, если это необходимо, и используется для сортировки проектов. Также указывается процент занятости сотрудника в данном проекте, статус проекта (например, планирование, защита бизнес-плана и т.д.) и уровень незаменимости сотрудника (низкий, высокий или уровень «Бог» – его мы не трогаем точно, он должен быть в этом проекте).
Пример заполненного шаблона по управлению портфелем проектов
Это самый оптимальный документ для управления загрузкой. Руководителю понятно, какие ресурсы, где находятся и как их можно перераспределить в нужный момент. Также каждый участник команды может самостоятельно залезть в этот документ и сообщить о завершении проекта или актуализировать данные по своим проектам.
Шаблон «Управление портфелем проектов»:
Легенда
Уровень загрузки
ДП – Делипий (правила деловой переписки)
Фаза реакции: реализация работ
Область реакции: команда
Валентность (уровень вовлеченности): все стейкхолдеры
Периодичность: раз в проект
Обратили внимание, как размыто и избыточно много мы переписываемся? В проектах это настоящий бич.
Чек-лист для хорошей переписки:
1. Хорошая переписка – короткая.
a. Нет ничего хуже длинного полотна, в котором все начинается с исторической сводки и рассказа о дедушке. Заявление – аргументация – вывод. Структура на 500—1000 знаков.
b. Тренируйте команду писать кратко и четко.
c. Переписка должна быть в одном месте.
d. Уточнения пишите одним письмом или сообщением.
e. Забудьте о голосовых сообщениях при постановке задач. Это адский ад.
2. Хорошая переписка – грамотная.
a. Ну, в самом деле.
b. Не используйте термины, которые не понимаете. Особенно, когда пишете в ИТ. Это смешно.
c. Не пытайтесь сделать письмо умным, лучше – понятным.
d. Сомневаетесь в написании – погуглите.
e. Давайте обратную связь по ошибкам в письмах коллег.
3. Хорошая переписка – с ограниченным количеством участников.
a. Задействуйте только тех стейкхолдеров, кому есть до этого дело.
b. Не включайте тех, кто разводит сопли.
c. В идеале – руководитель + команда.
d. Даже если заказчик или владелец продукта настаивает быть в копии всех писем – и что?
e. Не надо ставить в копию акционеров. Для них готовьте отдельные целевые письма.
4. Хорошая переписка – без претензий.
a. Вы же вежливый и адекватный специалист. Все претензии – в лицо или через коуча.
b. Есть ожидания и претензии – организуйте сессию.
c. Есть претензии – подумайте: а не в вас ли собака зарыта?
d. Претензии в письмах – всего лишь повод попереписываться, но не решить их.
e. Наличие претензий говорит о проблемах в процессах.
5. Хорошая переписка – быстрая.
a. Не растягивайте коммуникацию на века. У всего есть точка актуальности. Внедряйте культуру скоростного ответа в проектах.
