-
Георгий Баркан
-
Выпускник МФТИ. С 1995 года прошел путь от программиста до руководителя проектов для DEC, Compaq, Hewlett-Packard. В российском офисе Quest Software руководил реализацией решений для PricewaterhouseCoopers, Merrill Lynch, Fidelity Investments, MSN.com, CIBC, HSBC, Volkswagen и других крупнейших заказчиков. Успешно реализовал модель выявления требований и пилотирования функциональности коробочного продукта на основе заказных проектов. В настоящее время руководит разработкой технологической стратегии развития пользовательских продуктов «Лаборатории Касперского».
Практика и чуть-чуть философии управления требованиями
Мы обсудим три самых, на наш взгляд, насущных вопроса управления требованиями исходя из опыта реализации как заказных проектов, так и коробочной продуктовой разработки. Методики и книжки не часто дают на них ответы, да и вряд ли есть готовые рецепты на все случаи жизни. Но «предупрежден, значит вооружен» — всегда можно найти приемлемое решение в конкретном случае.
- Сущность требований: вечная дилемма «что» и «как». Все знают, что требования должны быть ответом на вопрос «что нужно сделать?». А вот насколько подробно или общо отвечать на него? Как избежать и абстрактности и ненужных деталей реализации? Как выявить истинные потребности пользователя или заказчика? Небольшое философское отступление на тему мотивации и пирамиды потребностей приведет нас к очень простому и практичному способу выявления исходных требований.
- Сбор требований: как человеческий фактор может все испортить. Почему заказчик и пользователь не могут четко сформулировать свои желания? Обсудили, договорились, но каждый понял договоренности по-своему. Как распознать опасные ситуации ложного или вынужденного согласия? Как осуществить «пересадку мозга» от заказчика исполнителю? Организационные и психологические вопросы совершенно нельзя игнорировать в процессе выявления требований. Во многом управление требованиями является и управлением ожиданиями.
- Управление требованиями: все хорошо в меру. Насколько формально следует подходить к специфицированию требований? Где золотая середина между формой и содержанием? Какую методику выбрать? Почему для каждого проекта оптимальный формат описания требований уникален? Как управление требованиями на 90% обеспечивает управление проектом?



















































































