В теме 5 ответов, и 3 участника, последнее обновление сделано пользователем 
check 14 г, 3 мес. назад.
-
Сообщения
-
Специфика проекта такова, что сначала компания продает "болванку" продукта, а после начинает его доработку и кастомизацию. Разумеется фирма старается продать продукт максимально большому числу покупателей. В итоге приходится управлять требованиями для 20+ заказчиков. Расскажите пожалуйста, как можно сделать свою работу более эффективной? На проекте документация не ведется, запросы от заказчиков поступают через веб систему тикетов (Work Items), либо по телефону, но потом в любом случае заносятся в систему для ведения отчетности.В вопросе уже есть часть ответа
1. Начать вести документацию (аналитик ты или кто?
). Если одного тебя не хватает, то привлечь самому еще аналитиков для решения боевой задачи, или поднять актуальность этого вопроса с начальством, чтобы совместно решить проблему.
2. Насколько я понимаю, сам продукт уже поддерживает branches (различные версии для каждого клиента или для группы). Если это не так, то надо это вводить.
3. Учитывая п.2 каждый Change Request / Bug должно быть возможным протрейсить до создателя (поле Originator, Source или еще как-нибудь в ворк айтеме)
4. Если заказчиков 20+, то я предполагаю, что работы много. В таком случае надо либо
а. вводить понятие "версия одна для всех", которая учитывает всевозможные пожелания и, скажем, возможность кастомизации продукта самим клиентом своими силами
б. вводить категории клиентов, объединяя для них версии продукта по каким-то общим критериям (географическая близость, необходимость в одинаковых фичах и т.д.), тем самым уменьшится кол-во необходимых версий
в. нанимать армию аналитиковНавскидку, пока всё.
Может, если ты расскажешь, что именно получается или не получается на данный момент, будет проще подсказать тебе соответствующее решение.Загруженность на проекте относительно не большая, просто время от времени бывает, что в один день всех сразу надоумит запостить новых требований. Мне понравилась идея разбить клиентов на категории, так можно будет выделить более-менее похожие системы в отдельные группы и тогда с ними будет проще работать.
Из документации присутствуют только самые значимые факты о модификациях системы. Как вариант, я думаю можно создать единую спецификацию, где будут описаны все возможности системы и обозначено какие фичи установлены на конкретном клиенте.Насчет документации.. Если эту спецификацию у тебя попросит заказчик, сам понимаешь какие проблемы могут возникнуть. Просто предусмотри это.Да, хранить единую спецификацию имеет смысл, но, как правильно заметил @Gerych, надо помнить про то, что одни клиенты не должны видеть версий продукта (требований) других клиентов.
Я бы предложил так:· Выдели и создай общую часть спеки
· Создай частные спеки для каждой группы клиентов или клиента
· Распиши и утверди формальный алгоритм внесения изменений в общую и частные спеки
· Распиши и утверди формальный алгоритм предоставления требований заинтересованным лицам (склеивание общей и определенных частных спек)
· Заставь всех (начиная с себя) придерживаться утвержденных алгоритмовЕсли всё сделать правильно и затем не нарушать своих же правил, то и спеку сможешь вести и не бояться, что клиенты увидят чужие версии спек.
Спасибо за советы!
Клиенты гарантировано не увидят спеку, так как на их стороне не ведется никакой документации и у нас они ее не заказывают. Спека получится исключительно для внутреннего использования.
Вы должны авторизироваться для ответа в этой теме.
