Великолепная методичка от VersionOne по интернет-маркетплейсам. Концентрат знаний как он есть, ничего лишнего.

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

1. Решить, как вы будете принимать решение
Указание — решение принимается без вовлечения других.
Консультация — информация собирается от членов группы, после чего кем-то принимается решение.
Голосование — решение принимается большинством голосов.
Консенсус — все приходят к полному согласию и поддерживают окончательное решение.

2. Определить, проговорить и записать (!), кто и что будет делать и к какому сроку
Нужно ясно описать ожидаемый результат и определить действия по отслеживанию и контролю («Позвони мне как сделаешь домашнее задание, а потом можешь пойти погулять с друзьями»).

Из книги «Трудные диалоги»

Селиховкин Иван (PMLead) выложил очень толковый ликбез в четырех частях.

Читать дальше →

Чем отличается опытный менеджер от неопытного? Неопытный спрашивает: «А ты сделаешь макет ко вторнику? Успеешь?» Опытный же устраивает пытку открытыми вопросами: «Когда ты пришлёшь макет?», «Когда ты пришлёшь первый черновик?», «Расскажи, с каким сложностями ты столкнулся при разработке этого макета и поэтому не успеваешь?», в середине дедлайна «Расскажи, как продвигается задача? Какая информация от меня или клиента тебе нужна?»

Люди делают классные вещи в классном состоянии. Хороший менеджер ездит в отпуск без страха провалить проект, ходит в кино и не поглядывает в телефон, вдруг пришло какое-то сообщение (вдруг по работе!). Не распространяет беспокойство. Хороший менеджер — скала. Он знает закон: все всегда будет плохо. Иначе он был бы не нужен. Когда всё начинает валиться и сыпаться, должен появиться менеджер и помочь разрулить ситуацию: ты — держи жгут, ты — делай непрямой массаж сердца, ты — звони в скорую. Появился пульс — отдал парамедикам и пошёл дальше смотреть кино.

Отсюда

В последнее время для спецификации требований все чаще используют технику пользовательских историй (User story), а не вариантов использования (Use case). Однако, это не означает, что они лучше.

Пользовательские истории — это быстрый способ документирования на повседневном языке. Требование записывается в виде одной формализованной фразы, определяющей актора, потребность и ожидаемый результат (например, «As a WHO I want WHAT so that EXPECTED OUTCOME»). Такой способ экономит ресурсы на создание и поддержание требований, но требует тесного взаимодействия между исполнителем и заказчиком системы. User Story, к сожалению, не соответствует в полном объеме таким критериям «хороших требований» как полнота, однозначность и проверяемость. Хотя с этим можно бороться определяя критерии приемки.

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

UPD:
Как писать хорошие user story

UPD 2:
См. также User story vs. Job story