Практика и чуть-чуть философии управления...
24
Практика и чуть-чуть философии управления требованиями Георгий Баркан Руководитель направления технического развития пользовательских продуктов «Лаборатория Касперского»
-
Upload
george-barkan -
Category
Technology
-
view
41 -
download
6
description
Мы обсудим три самых, на наш взгляд, насущных вопроса управления требованиями исходя из опыта реализации как заказных проектов, так и коробочной продуктовой разработки. Методики и книжки не часто дают на них ответы, да и вряд ли есть готовые рецепты на все случаи жизни. Но «предупрежден, значит вооружен» — всегда можно найти приемлемое решение в конкретном случае. 1) Сущность требований: вечная дилемма «что» и «как». Все знают, что требования должны быть ответом на вопрос «что нужно сделать?». А вот насколько подробно или общо отвечать на него? Как избежать и абстрактности и ненужных деталей реализации? Как выявить истинные потребности пользователя или заказчика? Небольшое философское отступление на тему мотивации и пирамиды потребностей приведет нас к очень простому и практичному способу выявления исходных требований. 2) Сбор требований: как человеческий фактор может все испортить. Почему заказчик и пользователь не могут четко сформулировать свои желания? Обсудили, договорились, но каждый понял договоренности по-своему. Как распознать опасные ситуации ложного или вынужденного согласия? Как осуществить «пересадку мозга» от заказчика исполнителю? Организационные и психологические вопросы совершенно нельзя игнорировать в процессе выявления требований. Во многом управление требованиями является и управлением ожиданиями. 3) Управление требованиями: все хорошо в меру. Насколько формально следует подходить к специфицированию требований? Где золотая середина между формой и содержанием? Какую методику выбрать? Почему для каждого проекта оптимальный формат описания требований уникален? Как управление требованиями на 90% обеспечивает управление проектом?
Transcript of Практика и чуть-чуть философии управления...
Практика и чуть-чуть философии управления требованиямиГеоргий БарканРуководитель направления технического развития пользовательских продуктов«Лаборатория Касперского»
«ЧТО?» И «КАК?»Сущность требований
Требования Дизайн Реализация(Система)
«Что?» «Как?»
«Наблюдаемые извне
характеристики системы»*
* Davis, 2005
ПредположенияОжидания
«Зачем?»
Писать в невесомости
Ручка, пишущая в
невесомости
«Что?» «Как?»«Как?»
«Что?»
* Wikipedia // Space Pen
Space Pen*
Карандаш
Писать в невесомости
Ручка, пишущая в
невесомости
Писать в космическом
корабле
Писать на любой
поверхности
Не пылить
«Как?»«Что?» «Как?»
«Зачем?»
«Как?»«Что?»
Space Pen
Карандаш
Электронный планшетПисать в
космическом корабле
Фиксировать результаты
научных экспериментов
Терминал с клавиатурой
«Зачем?»
Фиксировать результаты
научных экспериментов
Провести научные
исследования
Выполнить программу
полетаДобиться успеха
космической программы
?
?
?
«Зачем?»
«Зачем?»
«Зачем?»
Рамки проекта
ЧЕЛОВЕЧЕСКИЙ ФАКТОРСбор требований
Мотивация*
Требования
* Wikipedia // Metamotivation
Истории из жизни• «Большой начальник»• «Легкий саботаж»• «В чем проблема?»• Вынужденное согласие• Покупатели и пользователи• Бизнесмены и разработчики
Пользо-ватель
Внешний заказчик
• Эксплуатация• Закупка• Руководство
Заказчик продукта
• Product Management
• Маркетинг
Произво-дитель
• Продажи• Разработчики• Поддержка
Цена
Удобство
Возможности
Качество
Продаваемость
«Политика»
Самореализация
Достижения
Люди — ненадежный источник• Свойственно ошибаться• Неправильно понят вопрос• Неверно интерпретирован ответ• Важное и неважное• Различные предположения• Правда, но не вся• Сознательный обман
Мотивация
Активное слушание*Ожидания
Предполо-жения
Social Engineering**
Коммуникация
* Wikipedia // Active listening** Hadnagy, 2010
ВСЕ ХОРОШО В МЕРУУправление требованиями
Понимание Фиксация
Спецификация
Цель — однозначное понимание требований заинтересованными лицами
Формат — уникален для проекта
Формализм: примеры• Юридический контракт и UML-диаграммы• Use Case диаграммы*• Class диаграммы
* Martin Fowler’s Bliki // UseCases
Нужно договариваться
Требования изменяются. Всегда*
Сначала скажите «нет»**
* Wikipedia // Impermanence** Кэмп, 2009
Триажтребований*
Заказчик /рынок
Менеджерпроекта
DON
E2.0
2.1 2.2
3.0TBD
Требования—Время—Затраты * Davis, 2005
ПриоритетТр
удое
мкост
ь
Дополнительные факторы• Риски• Рынок
– Размер– Окно– Проникновение
• Возврат инвестиций– Цена– Прибыль– Затраты
Итоги• Сущность требований: «Зачем?»
– Мотивация• Сбор требований
– Активно слушать и проверять– Выявлять предположения– Управлять ожиданиями
• Управление требованиями– Спецификация: все хорошо в меру– Триаж: поиск компромисса
• Alan M. Davis. Just Enough Requirements Management: Where Software Development Meets Marketing. Dorset House, 2004.
• http://wikipedia.org/wiki/Space_Pen• http://wikipedia.org/wiki/Metamotivation• http://wikipedia.org/wiki/Active_listening• Christopher Hadnagy. Social Engineering: The Art of Human
Hacking. Wiley, 2010.• http://martinfowler.com/bliki/UseCases.html• http://wikipedia.org/wiki/Impermanence• Джим Кэмп. Сначала скажите «нет». Технологии ведения
переговоров, которые профессионалы хотели бы от вас скрыть. Добрая книга, 2009.
• http://ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html
Careerlab, ITONLINE GROUP 2011 Команда Software People
+7 (495) [email protected]
http://twitter.com/gbarkan
http://linkedin.com/in/gbarkan
http://slideshare.net/gbarkan
How great leaders inspire action*
* TED // Simon Sinek
«Как?»
«Что?»
«Зачем?»
