Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: fedor от 30 Октября 2007, 19:33:35
-
Добрый день коллеги и примкнувшие к ним программисты :) :)
Допустим есть новый проект
происходит обследование организации
как результат есть документация явлющаяся результатом обследованием -назовем ее КД1
( в 1 случае когда обследовали с целью внедренияя западной XXX системы -
это вордовский файлы - с встроенными арис диаграммами)
Проект загнулся по причине (а не важно)
А интеерсует собственно вото что
1 у кого что является резульататом обследования КД1
2 Кто пользуется этим ( заказчик программисты аналитики) и пользуется ли вообще
3 Как КД1 меняется с течением времени и какова вообще ее судьба если внедрение идет скажем >1 года
зы Хотелось бы услышать людей с ПРАКТИЧЕСКИМ ОПЫТОМ
-
Федор,
Вам сейчас быстренько Боатман по полочкам все разберет, но успею сунуть свои 5 копеек
Ответы на ваши вопросы:
1. Концептуальный документ (Vision), читаем статьи Боатмана по этому поводу.
2. Концептуальным документом пользуются Аналитики и Заказчики
3. Не понятно что Вы имеете ввиду под КД. Если мы говорим о Визион, то он может меняться по мере уточнения требований, но надо стремится к минимуму изменений после фиксации целей и потребностей. Просто тут проблема в том что под документом об обследовании считается просто описание БПроцессов организации, что в корне не верно.
Небольшая ремарка:
* Если целью стало Внедрение, то это роковая ошибка, поэтому и внедрилось ничего.
* Идем в раздел целеполагание и там изучаем все ветки внимательно.
* КД - это что у вас за сокращение?? Обычно это Конструкторская Документация. У вас видимо это комплект документов
-
--У вас видимо это комплект документов
да
Концептуальный документ (Vision),
? Vision (знаю только Visio) что за оно
ссылку плиз почитаю
-- Концептуальным документом пользуются Аналитики и Заказчики
пару слов сюда расшифруйте КАК пользуются
особенно заказчики - ПРАКТИЧЕСКИ ? (кто)
ps to bas & boatman елси не секрет вы внедряете западные или местные системы,
на базе или писанные с нуля ?
имхо может быть большая разница
-
Я внедряю две вещи:
1. Заказные разработки с нуля
2. Кастомизация собственного большого ПО
В чем вопрос то??
-
Концептуальный документ (Vision),
? Vision (знаю только Visio) что за оно
ссылку плиз почитаю
оп-пана. Народ не знает что такое вижын - вижын - это видение проекта. Т.е. то что обсуждается с самого начала и содержит фиксацию проблем, их анализ, цели системы, ожидаемые свойства системы.
ссылок конкретных очень много - поиск рулит.
-- Концептуальным документом пользуются Аналитики и Заказчики
пару слов сюда расшифруйте КАК пользуются
особенно заказчики - ПРАКТИЧЕСКИ ? (кто)
В нем зафиксировано понимание того, что нужно сделать на самом общем абстрактном уровне. Он поределяет границы проекта, системы, позволяет выявить риски, составить план проекта, дать общие оценки финансирования, понять, что будет разработано, а что возможно куплено на стороне.
Крэг Ларман, Лиффенгуэлл, Коберн, Кратчен, Рамбо, Блаха - кроме того можно посмотреть здесь: http://www.epfwiki.net/wikis/openupru/
-
Спасибо ВСЕМ за ответы
1? честно говоря я так и не понял каим образом ЗАКАЗЧИК пользуется КД1-
(сам то я думаю что в 9 из 10 никак а вот про 10 и хотелось бы спросить :))
>> В нем зафиксировано понимание того, что нужно сделать на самом общем абстрактном уровне. Он поределяет границы проекта, системы, позволяет выявить риски, составить план проекта, дать общие оценки финансирования, понять, что будет разработано, а что возможно куплено на стороне.
замечательно а вот где бы посмотреть ну хотя бы рыбу из ПРАКТИКИ
(понимаю что это комм. тайна - короче все что ей не является)
те примерно структуру РЕАЛЬНОГО док-та
ЗЫ Я посмотрел http://www.epfwiki.net/wikis/openupru/
все это интеерсно но к сожалению далековато от моей текущей ситуации
+что то там язык то русс. то англ.
вот интересно Stakeholder - имеет доп. задачу Create Test Cases
на нашей практике что-то я сильно сомневаюсь в реальности такого
более того и тестеров на наших (СНГ) проектах очень мало
-
Возможно вам поможет эта ссылка:
http://www.intuit.ru/department/itmngt/analisis/7/
Примеры Вы врядли найдете, но поиск в гугле по словам: system/software vision sample/example может помочь
-
Подыму тему по результатам SEF 2009
был там правда к сожалению не на всех семинарах (накладка по времени с работой) - товарищ был на всех uml2.ru (он там все книжки пеерчитал)
Честно г-ря впечатления средние - в ообщем толковый пересказ учебников
местами интеересно местами не очень
прямо скажем UML мастер класс сильно разочаровал
к сожалению без каких-то примеров РЕАЛЬНЫХ проектов и удачн. решений
ошибок на них (а не скажем какие штуки есть в UML).
Понятно что время ограничено комм. тайна и т.д и др. сложности
но вообщем бы хотелось бы в след. раз услыашть что-то практическое
ну да ладно платила контора
а больше всего меня интеерсует образец документа Vision ну или хотя бы выдержки из него пусть 10 летней давности
или скажем с замеными названиям ОАО Рога и Копыта
ну хоть шаблон
зы по мотивам беседы с Д.Безуглым я так понял что это нужно в 1 очередь для
самого аналитика - для приведения в порядок мыслей т.к. начальству обычно показываются картинки - поэтому любые образцы и т.д.
ззы гогл я еще в тот раз юзал - безрезультатно
-
а больше всего меня интеерсует образец документа Vision ну или хотя бы выдержки из него пусть 10 летней давности
или скажем с замеными названиям ОАО Рога и Копыта
ну хоть шаблон
Так и быть, раскрою один профессиональный секрет. :) Только тс-с-с-с! ;)
На странице uml2.ru, в левой колонке, есть такой блок "поиск по сайту". Ввожу туда запрос "шаблон концепции". Нажимаю кнопочку. Получаю результат поиска. Кликаю по второй ссылке (первая предлагает версию для печати). А там - опаньки! - вот такая ссылка:
Vision for UML2 (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&action=dlattach;topic=268.0;attach=308)
8)
-
Честно г-ря впечатления средние - в ообщем толковый пересказ учебников
местами интеересно местами не очень
Можете дать ссылки на учебники, в которых раскрыты 1) риски аналитика, 2) проблемы выявления требований и 3) постановка процесса УТ? спасибо.
а больше всего меня интересует образец документа Vision ну или хотя бы выдержки из него пусть 10 летней давности
Вот образцы от Вигерса: http://www.processimpact.com/process_assets/sample_requirements_documents.zip
-
Федор,
Вот Vision - это реально баян, но мы постарались вроде рассказать на СЕФ что-то действительно новое, чего нет в учебниках. А за отзыв спасибо, будем еще тщательнее думать перед Конференцией. Могли бы Вы назвать темы, которые Вам были интересно услышать на Конференциях?
-
смодерирую :)
Могли бы Вы назвать темы, которые Вам были интересно услышать на Конференциях?
к сожалению без каких-то примеров РЕАЛЬНЫХ проектов и удачн. решений
ошибок на них (а не скажем какие штуки есть в UML).
вообщем бы хотелось бы в след. раз услыашть что-то практическое
Поддержу fedor'а. Я вчера смотрел презентации. Рекомендации все дельные, подписался бы. Но одно дело, когда ты сам это сто раз пережил на практике, то и все эти слова кажутся само собой разумееющимися. А для новичков, видимо, действительно не хватает ПРИМЕРОВ - была такая-то конкретная проектная ситуация, применили вот такой метод, стало лучше таким-то вот образом, при этом, однако, огребли вот такие наведенные проблемы, но все равно выгоды перевесили минусы потому-то - вот это было бы совсем зачетно.
-
А для новичков, видимо, действительно не хватает ПРИМЕРОВ - была такая-то конкретная проектная ситуация, применили вот такой метод, стало лучше таким-то вот образом, при этом, однако, огребли вот такие наведенные проблемы, но все равно выгоды перевесили минусы потому-то - вот это было бы совсем зачетно.
Всё правильно, но учтите, что докладчикам давали всего по полчаса, и им было интереснее запихнуть как можно больше рекомендаций, а не разжёвывать конкретные кейсы. Возможно, зря )
-
По поводу конкретных примеров Vision - нашел в загашнике два примерчика, за публикацию которых, надеюсь, меня компания не привлечет по статье :)
Правда, это примеры vision не на программные проекты, а на консалтинговые, но да разница небольшая. По сути, документ должен определить границы проекта, а для какого проекта это делать - хоть программного, хоть консалтингового, хоть землекопательного - все равно делать это надо, и специфика технологии на данном этапе не сильно влияет.
Пример 1 - это презентация, с которой выступали перед заказчиком. Пытались донести суть работ по проекту, сформировать ожидания результатов проекта. Там еще прикладывался план работ по проекту, но я его по понятным причинам секвестировал.
Пример 2 вообще коротенький, это делалось в командировке за один день, реально примерно за 1,5 часа - приехали на пресейл, выслушали заказчика, набросали vision (вот этот), согласовали с заказчиком - и пошли делать проект.
-
Только уточню на всякий случай - хотя топик называется "документация по результатам обследования", но в практике нашей компании Vision пишется не по результатам обследования, а до его начала.
Обследование - это уже, как правило, часть проектных работ, а vision пишется обычно на этапе, предшествующем началу активных боевых действий. Задача этого документа - удостовериться вместе с заказчиком, что мы правильно вообще поняли, куда идти надо, и застолбить границы работ (и границы обследования, в том числе).
Иногда, конечно, vision делается и по итогам обследования, но это реже, и на этом этапе роль именно vision'а как проектного артефакта существенно ниже. Собственно, на данном этапе уместнее написать отчет об обследовании или даже ТЗ. По крайней мере, те vision'ы, которые делались "по результатам обследования", было безумно трудно запихать хотя бы в 10-15 страниц, потому что аналитики уже нарыли кучу деталей, и вся эта куча страшно выпирает. Эти вижны ОЧЕНЬ похожи на краткие ТЗ. Там 5% информации по целям и границам проекта, 10% про потребности пользователей, еще 5% всякие планы и риски, и 80% - это требования, требования, требования... Имхо теперь когда читаю эти документы задним числом - не могу понять, зачем мы это оформили как vision, почему не написали сразу ТЗ.
-
Михаил,
Честно говоря, Vision, которые Вы предоставили, - это скорее организационные документы, чем аналитические, т.е. Вы в них определяете план на первые этапы проекта, т.е. границы не с точки зрения функционала Системы, а с точки зрения проектных работ. Безусловны эти документы ценны для проекта, но к классическому Vision не имеют никакого отношения.
Если у Вас сильно выпирает Vision после обследования, то его можно просто разделить на два документа Vision и драфт ТЗ, или Vision и Описание БП.
-
смодерирую :)
Поддержу fedor'а. Я вчера смотрел презентации. Рекомендации все дельные, подписался бы. Но одно дело, когда ты сам это сто раз пережил на практике, то и все эти слова кажутся само собой разумееющимися. А для новичков, видимо, действительно не хватает ПРИМЕРОВ - была такая-то конкретная проектная ситуация, применили вот такой метод, стало лучше таким-то вот образом, при этом, однако, огребли вот такие наведенные проблемы, но все равно выгоды перевесили минусы потому-то - вот это было бы совсем зачетно.
Примеры обычно не выносятся в презентации. А выступление Дениса Бескова вообще ни в какую статическую презентацию не впишется.
Я вот вчера прослушивал доклад Александра Орлова (http://www.happy-pm.com/blog/?p=1840). Презентация не даёт почти никакого представления о том, что он говорил на самом деле.
Мы вели видеосъёмку на SEF, выложим видеозписи в ближайшее время.
-
Я вот вчера прослушивал доклад Александра Орлова (http://www.happy-pm.com/blog/?p=1840). Презентация не даёт почти никакого представления о том, что он говорил на самом деле.
Так и должно быть (по моему мнению)
-
Вы в них определяете план на первые этапы проекта, т.е. границы не с точки зрения функционала Системы, а с точки зрения проектных работ.
Ну да, я же и оговорился, что это консалтинговые проекты. Какой там может быть функционал системы... Тем не менее, эти документы свою роль - согласование с заказчиком границ проекта - превосходно сыграли.
Но если кто-то готов предоставить примеры "более правильных" vision-ов, с удовольствием сам ознакомлюсь.
-
Спасибо всем ответившим
и персонально greesha - указавший что здесь есть шаблон Vision- (как ни странно сам я его до этого не нашел)
и Михаилу за то что он выложил
я бы тоже с БОЛЬШИМ интересом посмотрел бы и документы других если у
кого-то будет возможность выложить Vision (или даже ТЗ - к-е можно будет взять за образец)
хотя ТЗ мне приходилось читать а вот Vision только здесь
зы просьба мой пост про SEF2009 не рассматривать в качестве наезда это всего лишь мое имхо (и еще 1 человека сидящего рядом со мной) и пожелания
( сам я оратор вообще никакой). Я с большим уважением отношусь ко всем кто выступал на конференции
-
я бы тоже с БОЛЬШИМ интересом посмотрел бы и документы других если у
кого-то будет возможность выложить Vision (или даже ТЗ - к-е можно будет взять за образец)
ну и собственно пример концепции от меня (http://www.pmdays.ru/u/_files/files/0/31.ppt).
-
Вопрос к гуру по вижнам. Чем отличается с точки зрения практики применения в отечественной действительности vision от ТКП (технико-коммерческого предложения)?
В теории - шаблоны разные, все понятно.
А на практике - если вы высылаете заказчику ТКП на будущий проект, вы пишете еще отдельно vision? Или все, что вы могли бы написать в vision'e, вы пишете в самом ТКП?
-
Главное не как назвать документ, а что в него вложить.
Что должно быть в Концепции постарался кратко написать в ЖЖ:
http://bas4all.livejournal.com/26079.html
-
Александр, но все же, и Концепция, как Вы пишете, призвана ответить на вопрос "Почему или Зачем мы разрабатываем\дорабатываем Систему?". И в ТКП, по сути, мы раскрываем ту же тему.
Почему я считаю важным на это указать?
Не во всех компаниях развита практика формирования vision'ов перед началом проекта. Многие до сих пор спрашивают, а что это? а зачем это? Ну уж ТКП-то, наверное, каждая организация пишет, у которой есть какие-то заказчики, ведутся какие-то продажи.
Отсюда вывод - можно взять те ТКП, которые пишутся в организации (например, по проектам разработки софта) и с некоторой долей условности можно их считать примерами vision'ов.
Как вам такая гипотеза?
-
К сожалению нет единой терминологии даже в этом вопросе. Например, мы это называем не ТКМ, а КМ (просто ком. предложение).
Еще раз повторюсь, если Вы пишете в ТКМ "Почему или Зачем мы разрабатываем\дорабатываем Систему?", т.е. определяете решаемые проблемы и реальные цели (а не просто автоматизация деятельности), то и называйте это ТКМ, я лично только за.
Просто обычно в ТКМ или КМ максимум что перечисляют, так это функционал будущей Системы, а на главный вопрос "Зачем весь этот функционал нужен?" никто не отвечает, тем самым этот функционал все время пересматривается и народ жалуется на кучу Изменений Требований от Заказчика.
-
Пример Видения, написанный моей студенткой. Не все блестяще, но помоему и не совсем плохо
-
Эд, в общем, совсем неплохо.
-
обычно в ТКМ или КМ максимум что перечисляют, так это функционал будущей Системы, а на главный вопрос "Зачем весь этот функционал нужен?" никто не отвечает
Но это же не догма. Можно это и написать.
Тут важный момент, о котором иногда забывают. Все аналитические документы - и vision, в частности, имеет смысл рассматривать в контексте как конкретного выполняемого проекта, так и общих взаимоотношений с заказчиком. На какой стадии проекта мы находимся? Проект уже продан или нам только предстоит убедить заказчика в его целесообразности? Договор уже заключен (а к нему, видимо, и какое-то задание на работы или ТЗ приложено) или мы как раз пытаемся выяснить границы работ, чтобы четко составить договор (и сколько времени у нас на это есть)? Спонсор проекта со стороны заказчика имеет четкое и детальное представление о том, что он хочет получить за свои деньги, или только "в общем и целом", а что конкретно, надо прояснять? С заказчиком у нас высокая степень доверия, и мы уверены, что все неясности и неточности сможем потом прояснить в рабочем порядке и без конфликтов, или мы знаем, что любая закорючка будет использована как повод повозить нас мордой об стол?
Эти вопросы оказывают существенное влияние на то, что и как мы должны написать в vision'е (или в ТКП). Поэтому я считаю, что нет универсально хорошего vision'а для всех времен и народов. Спасибо товарищу Вигерсу, что порадовал нас шаблоном оного, но даже беглый анализ практических примеров, выложенных в этой ветке, показывает, как сильно они отличаются друг от друга и все вместе - от вигерсовского шаблона. И это нормально, наверное. Оценивать, хорош вижн или нет, надо исходя из той конкретной проектной ситуации, которую этот документ призван был решить, и именно с пониманием - решил или нет.
-
Естественно серебренной пули нет, но если мы более детально проработаем проблемы и цели в начале проекта, тем легче нам будет потом ...