Просмотр сообщений
2146
Управление Проектом / Re: Планирование софтверного проекта: Источник WBS?
« : 20 Февраля 2007, 07:37:39 »
Едем дальше, поясняю - при планировании проекта по созданию ИС или ПО, например, при создании старт-ап компании, в рамках заказа системы несофтверной компанией или скажем, создании сайта наподобие UML2.ru, зачастую нет взаимоувязанного набор работ, которые необходимо провести для получения желаемого результата. Причём, на мой взгляд, одна из важнейших проблем в сложившихся подходах - понимание в качестве результата некоторого "объекта поставки", а не ситуации.
Например, если вы будете считать, что в результате проекта по созданию сайта вам нужны следующие объекты поставки:
1) сам сайт;
2) какая-то документация к нему.
и будете строить весь проект исходя из получения такого результата, то вы легко можете придти к ситуации, когда заказчику будет передана CD-болванка с установленной и настроенной под проект CMS-системой и какой-то документацией. Формально результаты получены, но оказывается, что сайт:
1) не развёрнут на домене,
2) не наполнен контентом, или
3) он есть, но он не посещается, или он экстремально неудобен и т.д. и т.п. -
т.е. "не работает" не с точки зрения техники, а с точки зрения бизнеса, как некоторый инструмент.
И страусиная позиция многих разработчиков - "ну мы типа только программы делаем, всё остальное не наша забота, что хотите с этой системой то и делайте" мне кажется сильно недальновидной и неуместной в современных условиях необходимости тесного сотрудничества бизнеса и IT.
На мой взгляд возможно свести воедино весь комплекс работ по созданию работающей с точки зрения бизнеса системы, если использовать нечто вроде "глобального сценария" или "обобщённого бизнес-процесса", описывающего желаемую ситуацию относительно создаваемого продукта. Для многих проектов по созданию массовых веб-приложений, таким сценарием, на мой взгляд, мог бы быть следующий:
П. Пользователь приходит на сайт
Н. Пользователь получает нужное
Д. Пользователь остаётся довольным
Р. Пользователь рекомендует сайт знакомым
В. Пользователь возвращается на сайт
Далее можно рассматривать каждый шаг сценария как некоторое глобальное условие, которое должно быть выполнено и под него подкладывать детализированный набор задач и новых условий, к которому его можно свести. Само собой, этот сценарий можно и нужно модифицировать под проект, например за счёт введения пункта "О. Пользователь оплачивает продукт или услугу" и т.д.
Например, если вы будете считать, что в результате проекта по созданию сайта вам нужны следующие объекты поставки:
1) сам сайт;
2) какая-то документация к нему.
и будете строить весь проект исходя из получения такого результата, то вы легко можете придти к ситуации, когда заказчику будет передана CD-болванка с установленной и настроенной под проект CMS-системой и какой-то документацией. Формально результаты получены, но оказывается, что сайт:
1) не развёрнут на домене,
2) не наполнен контентом, или
3) он есть, но он не посещается, или он экстремально неудобен и т.д. и т.п. -
т.е. "не работает" не с точки зрения техники, а с точки зрения бизнеса, как некоторый инструмент.
И страусиная позиция многих разработчиков - "ну мы типа только программы делаем, всё остальное не наша забота, что хотите с этой системой то и делайте" мне кажется сильно недальновидной и неуместной в современных условиях необходимости тесного сотрудничества бизнеса и IT.
На мой взгляд возможно свести воедино весь комплекс работ по созданию работающей с точки зрения бизнеса системы, если использовать нечто вроде "глобального сценария" или "обобщённого бизнес-процесса", описывающего желаемую ситуацию относительно создаваемого продукта. Для многих проектов по созданию массовых веб-приложений, таким сценарием, на мой взгляд, мог бы быть следующий:
П. Пользователь приходит на сайт
Н. Пользователь получает нужное
Д. Пользователь остаётся довольным
Р. Пользователь рекомендует сайт знакомым
В. Пользователь возвращается на сайт
Далее можно рассматривать каждый шаг сценария как некоторое глобальное условие, которое должно быть выполнено и под него подкладывать детализированный набор задач и новых условий, к которому его можно свести. Само собой, этот сценарий можно и нужно модифицировать под проект, например за счёт введения пункта "О. Пользователь оплачивает продукт или услугу" и т.д.
Но я не жалею, "всё правильно сделал".