Михаил,

Честно говоря, Vision, которые Вы предоставили, - это скорее организационные документы, чем аналитические, т.е. Вы в них определяете план на первые этапы проекта, т.е. границы не с точки зрения функционала Системы, а с точки зрения проектных работ. Безусловны эти документы ценны для проекта, но к классическому Vision не имеют никакого отношения.
Если у Вас сильно выпирает Vision после обследования, то его можно просто разделить на два документа Vision и драфт ТЗ, или Vision и Описание БП.

смодерирую 
Поддержу fedor'а. Я вчера смотрел презентации. Рекомендации все дельные, подписался бы. Но одно дело, когда ты сам это сто раз пережил на практике, то и все эти слова кажутся само собой разумееющимися. А для новичков, видимо, действительно не хватает ПРИМЕРОВ - была такая-то конкретная проектная ситуация, применили вот такой метод, стало лучше таким-то вот образом, при этом, однако, огребли вот такие наведенные проблемы, но все равно выгоды перевесили минусы потому-то - вот это было бы совсем зачетно.

Примеры обычно не выносятся в презентации. А выступление Дениса Бескова вообще ни в какую статическую презентацию не впишется.
Я вот вчера прослушивал доклад Александра Орлова. Презентация не даёт почти никакого представления о том, что он говорил на самом деле.

Мы вели видеосъёмку на SEF, выложим видеозписи в ближайшее время.

Я вот вчера прослушивал доклад Александра Орлова. Презентация не даёт почти никакого представления о том, что он говорил на самом деле.

Так и должно быть (по моему мнению)

Вы в них определяете план на первые этапы проекта, т.е. границы не с точки зрения функционала Системы, а с точки зрения проектных работ.

Ну да, я же и оговорился, что это консалтинговые проекты. Какой там может быть функционал системы... Тем не менее, эти документы свою роль - согласование с заказчиком границ проекта - превосходно сыграли.

Но если кто-то готов предоставить примеры "более правильных" vision-ов, с удовольствием сам ознакомлюсь.

Спасибо всем ответившим
и персонально greesha - указавший что здесь есть шаблон Vision- (как ни странно сам я его до этого не нашел)
и Михаилу за то что он выложил
я бы тоже с БОЛЬШИМ интересом посмотрел бы и документы других если у
кого-то будет возможность выложить Vision (или даже ТЗ - к-е можно будет взять за образец)
хотя ТЗ мне приходилось читать а вот Vision только здесь

зы просьба мой пост про SEF2009 не рассматривать в качестве наезда это всего лишь мое имхо (и еще 1 человека сидящего рядом со мной) и пожелания
( сам я оратор вообще никакой). Я с большим уважением отношусь ко всем кто выступал на конференции

я бы тоже с БОЛЬШИМ интересом посмотрел бы и документы других если у
кого-то будет возможность выложить Vision (или даже ТЗ - к-е можно будет взять за образец)

ну и собственно пример концепции от меня.

Вопрос к гуру по вижнам. Чем отличается с точки зрения практики применения в отечественной действительности vision от ТКП (технико-коммерческого предложения)?
В теории - шаблоны разные, все понятно.
А на практике - если вы высылаете заказчику ТКП на будущий проект, вы пишете еще отдельно vision? Или все, что вы могли бы написать в vision'e, вы пишете в самом ТКП?

Главное не как назвать документ, а что в него вложить.
Что должно быть в Концепции постарался кратко написать в ЖЖ:
http://bas4all.livejournal.com/26079.html

Александр, но все же, и Концепция, как Вы пишете, призвана ответить на вопрос "Почему или Зачем мы разрабатываем\дорабатываем Систему?". И в ТКП, по сути, мы раскрываем ту же тему.

Почему я считаю важным на это указать?

Не во всех компаниях развита практика формирования vision'ов перед началом проекта. Многие до сих пор спрашивают, а что это? а зачем это? Ну уж ТКП-то, наверное, каждая организация пишет, у которой есть какие-то заказчики, ведутся какие-то продажи.

Отсюда вывод - можно взять те ТКП, которые пишутся в организации (например, по проектам разработки софта) и с некоторой долей условности можно их считать примерами vision'ов.

Как вам такая гипотеза?

К сожалению нет единой терминологии даже в этом вопросе. Например, мы это называем не ТКМ, а КМ (просто ком. предложение).

Еще раз повторюсь, если Вы пишете в ТКМ "Почему или Зачем мы разрабатываем\дорабатываем Систему?", т.е. определяете решаемые проблемы и реальные цели (а не просто автоматизация деятельности), то и называйте это ТКМ, я лично только за.

Просто обычно в ТКМ или КМ максимум что перечисляют, так это функционал будущей Системы, а на главный вопрос "Зачем весь этот функционал нужен?" никто не отвечает, тем самым этот функционал все время пересматривается и народ жалуется на кучу Изменений Требований от Заказчика.

Пример Видения, написанный моей студенткой. Не все блестяще, но помоему и не совсем плохо

Эд, в общем, совсем неплохо.

обычно в ТКМ или КМ максимум что перечисляют, так это функционал будущей Системы, а на главный вопрос "Зачем весь этот функционал нужен?" никто не отвечает

Но это же не догма. Можно это и написать.

Тут важный момент, о котором иногда забывают. Все аналитические документы - и vision, в частности, имеет смысл рассматривать в контексте как конкретного выполняемого проекта, так и общих взаимоотношений с заказчиком. На какой стадии проекта мы находимся? Проект уже продан или нам только предстоит убедить заказчика в его целесообразности? Договор уже заключен (а к нему, видимо, и какое-то задание на работы или ТЗ приложено) или мы как раз пытаемся выяснить границы работ, чтобы четко составить договор (и сколько времени у нас на это есть)? Спонсор проекта со стороны заказчика имеет четкое и детальное представление о том, что он хочет получить за свои деньги, или только "в общем и целом", а что конкретно, надо прояснять? С заказчиком у нас высокая степень доверия, и мы уверены, что все неясности и неточности сможем потом прояснить в рабочем порядке и без конфликтов, или мы знаем, что любая закорючка будет использована как повод повозить нас мордой об стол?

Эти вопросы оказывают существенное влияние на то, что и как мы должны написать в vision'е (или в ТКП). Поэтому я считаю, что нет универсально хорошего vision'а для всех времен и народов. Спасибо товарищу Вигерсу, что порадовал нас шаблоном оного, но даже беглый анализ практических примеров, выложенных в этой ветке, показывает, как сильно они отличаются друг от друга и все вместе - от вигерсовского шаблона. И это нормально, наверное. Оценивать, хорош вижн или нет, надо исходя из той конкретной проектной ситуации, которую этот документ призван был решить, и именно с пониманием - решил или нет.

Естественно серебренной пули нет, но если мы более детально проработаем проблемы и цели в начале проекта, тем легче нам будет потом ...