В теме 2 ответа, и 2 участника, последнее обновление сделано пользователем 
Герман Шестеров 13 г, 11 мес. назад.
-
Сообщения
-
Привет всем,
Эта тема частично перекликается с топиком http://analyst.by/forum/rabota-s-trebovaniyami/s-chego-nachinat-izvlechenie-trebovanii, но все же более частная.
Итак, исходный посыл:Заказчик присылает вам вижн будущей системы на одной-нескольких страницах. Вижн построен по принципу "Я хочу систему, позволяющую делать… Там должно быть то, то, то…".
В данном случае отпадают (или сводятся к минимуму) такие активности как анализ бизнес-процессов, формулировка предложений по вариантам их автоматизации и т.п., так как заказчик, с некоторыми оговорками, представляет, что он хочет.Собственно, вопрос: есть ли у кого-нибудь чеклист — вопросы, которые надо покрыть для того, чтобы ничего не упустить из виду? Или более конкретно — что вы включите в первый разговор/письмо заказчику для того, чтобы по получении ответов предоставить эстимации (хотя бы грубые) на проект.
Вот мой вариант (который пришел мне сейчас на ум, ибо письменного чеклиста я к сожалению не имею, хотя представляется полезным иметь такой):
- Список юз кейсов/фич планируемой системы в объеме, достаточном, чтобы покрыть эстимациями;
- Доменная модель системы aka список всех возможных сущностей и взаимосвязей между ними;
- Четкое понимание жизненного цикла основных сущностей систем и business workflows при работе с системой (с четко заостренными моментами начала и конца работы);
- Аутентификация и авторизация — классы пользователей и, как следствие, роли, ограничения и т.д.№
- Требования к дизайну;
- В случае абсолютной непонятности скоупа гуя по исходному вижну — мокапы/описание отдельных страниц/окон;
- Если есть интеграция с внешними системами, то точный скоуп интеграции + API.
- Ограничения хостинга, железа и софта.Что бы вы добавили сюда? Или чем бы вы заменили этот список?
Сразу оговорюсь, что мне важно именно ваше практическое мнение, а не как работать по учебнику
Чеклист — достойный. Я бы добавил несколько пунктов, хотя большинство из них необходимы по обстоятельствам.1. Введение.
Это — не шутка. Иногда неплохо показать свои знания бизнес домена. А именно, рассказать кратко о бизнесе, проблеме (или возможности улучшения), которая есть и решении которое ее решит.2. В скоуп полезно также указать какая документация будет поставляться. Чтобы не получилось, что заказчик ожидает детальную спецификацию, а готовить будем — классический SRS.
3. Архитектурное решение. Полезно, наверное рассказать, какие технологии будут предположительно использоваться и как компоненты системы будут взаимодействовать. Наиболее популярная диаграмма здесь — диаграмма развертывания.
4. Предположения. Если при подготовке первоначального предложения вы в чем-то не были уверены, но предположили, что это так то и так то, то об этом нужно сказать.
5. Иногда необходимо описание процесса проекта. Т.е. какая модель работы будет использована (RUP, MDA, Agile, etc). На какие фазы предпологается разбить проект. Как будет происходить коммуникация между заказчиком и исполнителем. Кто отвечает за принятие решений с обеих сторон.
6. Риски. Если они есть — то обязательно нужно о них сказать. И также — указать как их можно избежать или сгладить.
7. Легальные аспекты. Это бывает нужно, если используются третьесторонние части системы или в результате заказчик не получает всех прав на продукт.
8. Цена проекта. Заказчик наверняка захочет знать что сколько будет стоить.
9. Поддержка продукта после его выпуска. Если об этом идет речь, конечно.
Вот. Как-то так.
Алексей, спасибо за комменты. Только я немного не тот чеклист имел в виду. По сути — пункты, которые стоит оговорить с заказчиком на первом митинге и пункты, которые необходимо как можно раньше выяснить с целью предоставления грамотных эстимаций — это разные вещи.
В целом, если отойти от темы — да, то, что написано выше, по-любому стоит обсуждения. И спасибо за полезную инфу.
Я бы только добавил такие комменты к этому:2 — А чем классический SRS не детальная спецификация? На мой взгляд SRS, особенно если заполнить все пункты классических шаблонов — детальнее некуда (если не брать, конечно, во внимание SDD, хотя это уже не чисто забота аналитика).
5, 6, 8, 9 — имхо это забота проектного менеджера. Хотя если бы у меня на проекте были аналитики, которые сами поднимали эти вопросы, я был бы ужасно рад и им это только в несомненный плюс.
Вы должны авторизироваться для ответа в этой теме.
