Предыдущий пост из серии «онлайн психолог» Вы можете найти здесь.
Сегодня мы поговорим о процессе сбора требований к технической реализации. Но не о конкретном сборе, а о методологии как к этому делу лучше подойти.
Ни для кого не секрет, что требования к проекту очень важны. Они сродни аксиомам, на которых строиться вся остальная «теория» проекта. И если даже слегка менять аксиомы, то в одном случае мы можем получить «Евклидову геометрию», а в другом «геометрию Лобачевского»! Поэтому к сбору требований рекомендую подходить со всей ответственность, а не в режиме «мозгового штурма», как это обычно делается.
Итак, из чего состоит процесс сбора требований? Мы рекомендуем организовать его следующим образом:
На счет целеполагания рекомендую в начале прочитать следующую недавнюю публикацию.
От себя добавлю: цели как векторы и точно так же они складываются и приводят к более «высоким» целям. Рекомендую во всех проектах выстраивать цели исходя из своих личных целей. Так вам будет значительно легче мотивировать самого себя, а так же определять значимость вещей.
К примеру, вы говорите: «Я хочу быть богатым». Соответственно к любому Вашему проекту цель превращается во что-то типа: «Реализация данного проекта должна помочь мне стать богаче». Если проект заказной, а не чисто ваш, то цель может быть например такая: «Реализация данного проекта для заказчика А, должна принести мне как деньги, так и новые связи и хорошие отношения, так как сотрудничество в будущем будет весьма выгодным по отношению к моей главной цели».
Для нашего проекта мы сформулировали цель так: «Максимум опыта». Деньги будут позже — без желания получить их (и побольше!) практически никуда:) Но пока хотим получить побольше опыта, чтобы в дальнейшем уже грамотно балансировать между «дайте нам побольше денег» и «клиент всегда прав».
Стороны можно условно разделить на две группы:
Помимо выявления каждой из сторон рекомендуем определить цель ее участия. Наиболее трудно это сделать для пассивной группы, но здесь рекомендую к этому подходить как к проекции вашей основной цели. Вот что у нас получилось:
Я думаю, достаточно понятный для каждого пункт. Но рекомендую перед каждой «беседой» самостоятельно постараться выписать требования данной стороны по отношению к ее цели, а так же к вашей глобальной. Это:
Здесь тоже, надеюсь, все просто. Но есть маленькая рекомендация делать две оценки. Одна оценка по отношению к стороне, которая заявила такое требование, а вторая от ваша личная оценка по отношению к вашей глобальной цели. К примеру, одним из требований от психологов у нас была возможность перевода «заработанных» денег из онлайн кабинета к себе на счет или в электронную валюту. Психологом было оценено в 8 из 10. Но по отношению к нашей глобальной это абсолютно не важно, так как мы всегда можем сделать это в ручную и заодно проконтролировать все ли ок со счетами и т.д.
Для чего именно две оценки? Для того чтобы во время обнаруживать краеугольные вещи, которые очень важны стороне, а вам это безразлично — ну и наоборот. Таким вещам в ходе проекта стоит уделять отдельное внимание.
На этом этапе важно понять, что то что вы задокументировали совпадает с реальными ожиданиями сторон. А так же дать понять, что оценка требования нужна не для того, чтобы что-то исключить навсегда, а чтобы расставить данные требования по временной шкале реализации.
UPD: Если минусуете, то объясните, пожалуйста, за что?
Сегодня мы поговорим о процессе сбора требований к технической реализации. Но не о конкретном сборе, а о методологии как к этому делу лучше подойти.
Ни для кого не секрет, что требования к проекту очень важны. Они сродни аксиомам, на которых строиться вся остальная «теория» проекта. И если даже слегка менять аксиомы, то в одном случае мы можем получить «Евклидову геометрию», а в другом «геометрию Лобачевского»! Поэтому к сбору требований рекомендую подходить со всей ответственность, а не в режиме «мозгового штурма», как это обычно делается.
Итак, из чего состоит процесс сбора требований? Мы рекомендуем организовать его следующим образом:
- Формулирование главной цели проекта
- Определение сторон
- Получение требований от каждой из сторон
- Определение важности требований по отношению к цели
- Согласование требований и их важности со сторонами
Формулировка главной цели проекта
На счет целеполагания рекомендую в начале прочитать следующую недавнюю публикацию.
От себя добавлю: цели как векторы и точно так же они складываются и приводят к более «высоким» целям. Рекомендую во всех проектах выстраивать цели исходя из своих личных целей. Так вам будет значительно легче мотивировать самого себя, а так же определять значимость вещей.
К примеру, вы говорите: «Я хочу быть богатым». Соответственно к любому Вашему проекту цель превращается во что-то типа: «Реализация данного проекта должна помочь мне стать богаче». Если проект заказной, а не чисто ваш, то цель может быть например такая: «Реализация данного проекта для заказчика А, должна принести мне как деньги, так и новые связи и хорошие отношения, так как сотрудничество в будущем будет весьма выгодным по отношению к моей главной цели».
Для нашего проекта мы сформулировали цель так: «Максимум опыта». Деньги будут позже — без желания получить их (и побольше!) практически никуда:) Но пока хотим получить побольше опыта, чтобы в дальнейшем уже грамотно балансировать между «дайте нам побольше денег» и «клиент всегда прав».
Определение сторон
Стороны можно условно разделить на две группы:
- Активные: явно заинтересованы или непосредственно участвуют в достижении цели проекта
- Пассивные: в достижении цели участвуют косвенно. К примеру: «поисковые системы».
Помимо выявления каждой из сторон рекомендуем определить цель ее участия. Наиболее трудно это сделать для пассивной группы, но здесь рекомендую к этому подходить как к проекции вашей основной цели. Вот что у нас получилось:
- Владельцы бизнеса: новый опыт по отношению к искусству извлечения денег, а так же как минимум рентабельный бизнес через пол года
- Специалисты психологи: получать достаточный доход
- Клиенты: получить качественный сервис при малой стоймости
- Серверное оборудование(пассив): минимизация нагрузки
- Поисковые системы(пассив): оптимизация контента
Получение требований от каждой из сторон
Я думаю, достаточно понятный для каждого пункт. Но рекомендую перед каждой «беседой» самостоятельно постараться выписать требования данной стороны по отношению к ее цели, а так же к вашей глобальной. Это:
- Дает некую отправную точку для стороны к дальнейшим размышлениям. Для последнего очень помогает включение весьма «спорных» пунктов в первоначальный список.
- Дает правильное русло для размышлений по отношению именно к вашим целям. Если этого не делать, то каждый в требованиях начинает тянуть одеяло на себя.
Определение важности требования
Здесь тоже, надеюсь, все просто. Но есть маленькая рекомендация делать две оценки. Одна оценка по отношению к стороне, которая заявила такое требование, а вторая от ваша личная оценка по отношению к вашей глобальной цели. К примеру, одним из требований от психологов у нас была возможность перевода «заработанных» денег из онлайн кабинета к себе на счет или в электронную валюту. Психологом было оценено в 8 из 10. Но по отношению к нашей глобальной это абсолютно не важно, так как мы всегда можем сделать это в ручную и заодно проконтролировать все ли ок со счетами и т.д.
Для чего именно две оценки? Для того чтобы во время обнаруживать краеугольные вещи, которые очень важны стороне, а вам это безразлично — ну и наоборот. Таким вещам в ходе проекта стоит уделять отдельное внимание.
Согласование требований и их оценки
На этом этапе важно понять, что то что вы задокументировали совпадает с реальными ожиданиями сторон. А так же дать понять, что оценка требования нужна не для того, чтобы что-то исключить навсегда, а чтобы расставить данные требования по временной шкале реализации.
UPD: Если минусуете, то объясните, пожалуйста, за что?
