Все записи с тэгом «PM»

Чем отличается опытный менеджер от неопытного?

17.02.2015

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

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

Отсюда

#PM

Добавить комментарий

User story vs. Use case

12.02.2015

В последнее время для спецификации требований все чаще используют технику пользовательских историй (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

#PM #разработка ПО

Добавить комментарий

Управление требованиями

12.02.2015

Написано множество разнообразных многословных определений этой задачи. Но по сути это: управление границами решения/проекта + управление изменениями + трассирование требований + приоритизация требований. Всё.

#PM

Добавить комментарий

Конференция-фестиваль мобильных разработчиков mobileFest — 2013

13.09.2013

Предложили рассказать о процессе разработки приложения Redigo на конференции mobileFest — 2013 в Питере. В Москве было холодно и мокро, а в северной столице — солнечно и +18, так что грех было бы отказываться.

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

#PM #разработка ПО #чекин

Добавить комментарий

Про скорость мышления

22.06.2012

Читая несколько лет назад самурайское «наставление по Бусидо» почему-то не запомнил данное высказывание, а тут наткнулся и, пожалуй, соглашусь. Ожидая от людей реакции или поступков надо помнить, что:

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

Ямамато Цунэтомо, «Сокрытое в листве» («Хагакурэ»)

#PM #книги #настроение

Добавить комментарий


Реклама