Comments 4
1. А что такое "корпоративный интернет-проект"? Используйте более точные определения.
2. На момент начала сбора требований должна быть уже утверждена цель проекта. Вот в зависимости от цели проекта (а так же от того, что есть в PMBOK, но не упоминается в статье) предпринимаются остальные шаги. То, что вы собрали тут с миру по нитке - это классический способ угробить любой проект.
Нет времени расписать каждое слово, тут всё плохо и не относится к PM, поэтому тоже проминусую топик.
2. На момент начала сбора требований должна быть уже утверждена цель проекта. Вот в зависимости от цели проекта (а так же от того, что есть в PMBOK, но не упоминается в статье) предпринимаются остальные шаги. То, что вы собрали тут с миру по нитке - это классический способ угробить любой проект.
Нет времени расписать каждое слово, тут всё плохо и не относится к PM, поэтому тоже проминусую топик.
за свой опыт подтвердил для себя 2 утверждения:
1. чем точнее требования - тем быстрее они устаревают.
2. чем более размытые требования, тем сложнее показать что они удовлетворены в рамках проекта.
поэтому мне кажется важно не столько их структурирование, сколько умение их быстро воплощать.
1. чем точнее требования - тем быстрее они устаревают.
2. чем более размытые требования, тем сложнее показать что они удовлетворены в рамках проекта.
поэтому мне кажется важно не столько их структурирование, сколько умение их быстро воплощать.
Всё это специалист должен уметь учитывать, не расписывая — а расписывать для себя, лишь пока учится.
Как учебный материал — статья хороша, только вот акцент в ней стоит сделать, что она учебная, а не что она про о, что так надо работать.
Как учебный материал — статья хороша, только вот акцент в ней стоит сделать, что она учебная, а не что она про о, что так надо работать.
Что-то Вы смешали требования функциональные и нефункциональные, удобнее их все таки разделять.
Тут перечислены типы потребностей, которые должны быть включены в ТЗ. Интереснее узнать об опыте формирования самого ТЗ, по подобным потребностям.
Например, в таких проектах можно использовать сценарии, описывающие действия пользователей, администраторов, модераторов и т.д. Отсюда вытекает необходимость в требованиях определить роли пользователей, их цели (потребности) в продукте. и т.п.
Тут перечислены типы потребностей, которые должны быть включены в ТЗ. Интереснее узнать об опыте формирования самого ТЗ, по подобным потребностям.
Например, в таких проектах можно использовать сценарии, описывающие действия пользователей, администраторов, модераторов и т.д. Отсюда вытекает необходимость в требованиях определить роли пользователей, их цели (потребности) в продукте. и т.п.
Sign up to leave a comment.
Управление требованиями корпоративного интернет-проекта