121

Управление Проектом / Re: Дружеские отношения или жесткая корпоративная этика

« : 12 Октября 2010, 17:47:30 »

Для проекта лучше всего, чтобы подобные вопросы никак не влияли на его успех. Но это совсем не значит, что их не надо обсуждать.

Проект в любом случае будет затронут, вопрос в том насколько сильно.

122

Управление Проектом / Re: Дружеские отношения или жесткая корпоративная этика

« : 12 Октября 2010, 17:46:19 »

что-то мне подсказывает, что у Вас в загашнике еще много тем из серии "научите меня по-быстрому...", не так ли?

Я кому то мешаю вопросами ? Не надо меня ничему учить, тем более "по быстрому". Я пытаюсь узнать опыт других специалистов. По моему форум для этого и нужен.

По сабжу, конечно со мной работают ЛЮДИ. И я с этими людьми вступаю в ОТНОШЕНИЯ. А вот что это за отношения, и как те или иные виды отношений сказываются на проекте - это мне интересною

123

Управление Проектом / Дружеские отношения или жесткая корпоративная этика

« : 12 Октября 2010, 15:33:12 »

Недавно у коллег вышел спор о том, какую линии поведения выбирать на работке. Один утверждает что очень важны дружеские отношения, другой что необходимо придерживаться корпоративной этики. Что лучше для проекта? 

124

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 15:29:42 »

На самом деле, довольно много предложиk bas - в начале обсуждения. Но все спасибо за предложенные варианты.
Из всего вышесказанного можно сделать вывод. Что при возникновении спорных ситуаций, надо собрать всех вместе, обьяснить им варианты, выслушать их мнения и заставить принять решение того кто платит

125

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 12:29:32 »

Господа, да нет у меня никакой своей линии, если бы была, я бы у вас не спрашивал.
Это вы думаете что нет вопросов и последовательностей и т.д. Некоторые наши коллеги считают иначе.
Естественно что все строго индивидуально, но для других же процессов есть какие то шаблоны, которые потом дотачиваются под конкретный проект и заказчика. Никто не говорит о том что нужно учить заказчика, прочитайте первые посты. Вопрос стоял - предпочтения кого и как выбирать при возникновении противоречий, а не о том что нужно внедрять что то на свое усмотрение.

126

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 12:10:29 »

ida - здесь речь не идет о каком-то ПО или других инструментах. Речь идет о методах, а они вполне применимы и в общении. Метод утюга и паяльника отлично позволяет эффективно узнавать пароли у пользователей. Кто говорил о том что человек не хочет кого-то слушать?

Вы правы что инструменты имеют границы, но их задает не человек использующий их, а мировая практика использования и т.д. Подобные обсуждения как раз помогают узнать о новых горизонтах использования тех или иных методов. Просто сесть и поговорить с заказчиком - безусловно хорошо, но гораздо лучше сесть и поговорить со знанием дела, задавая правильные вопросы правильным людям в правильной последовательности.

Никто не говорил, что не понимает как работать с заказчиком, если бы это было так, многие были бы без работы. Да и ПО волшебное тоже никто не просит.

127

Системный Анализ и Требования / Re: Противоречивость требований

« : 12 Октября 2010, 10:04:30 »

В целом понятно, спасибо!

128

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 11 Октября 2010, 22:53:36 »

Ну предположим "фича" может падать когда параллельно с ней открыты одноклассники. А такую ситуацию не оттестируешь сразу (это утрированный пример). А всплывет это после внедрения и нужно будет потратить время, что бы эту ошибку локализовать.

Так может кнопку сразу убрать и не показывать заказчику вообще ?

Как правило эти внутренние инструкции очень плохо систематизированы. И найти в них что то непросто.

129

Системный Анализ и Требования / Re: Противоречивость требований

« : 11 Октября 2010, 14:01:07 »

Я пытаюсь выяснить если какие - то формализованные методы решения подобных противоречий. Судя по ответам решение одно - усадить всех за стол, все рассказать и заставить договориться.

130

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 11 Октября 2010, 12:37:38 »

По поводу не сопровождения фич это спорно. Если клиент говорит что при нажатии на такую то кнопку что-то падает, то ее надо починить что-бы не падало. Сказать ему "Не нажимайте" вы не заказывали будет некорректно.

Так же если функционал оставить но не включить в ТЗ, то как потом отслеживать "откуда оно появилось" ?

131

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 17:09:18 »

Почему система не принятая в эксплуатацию - с неопределенным набором функций ? Мне казалось что они как раз описываются до разработки и уже указаны в контракте, иначе как проводить приемку ?

Я еще раз напоминаю, что не нужно углубляться в те или иные процессы.

Речь идет не о том как правильно организовать поддержку, а о том стоит ли такой функционал включать в ТЗ и описывать (тем самым беря на себя ответственность за него) или его стоит искоренить (даже если это затратно). И если стоит оставить, то почему и какие профиты с этого можно поиметь.

132

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 17:04:56 »

Коллеги,

я лишь хотел узнать о методах решения таких противоречий или моделях поведения в такой ситуации.
Я прекрасно понимаю что в любом случае надо договариваться (о чем я писал выше) и согласовывать ТЗ, иначе о успехе проекта не может быть и речи.

Я и пытаюсь выяснить как "правильно" договариваться и какие особенности здесь могут быть !?

133

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 14:24:30 »

Я немного другое имел ввиду.
Допустим мы провели предпроектное исследование и т.д. Формируем требования и т.д. В итоге получаем систему в набором функ-ий (например 10).

Согласовываем и получаем что наши 10 фун-ий стоят 100 т р. Там же оговариваем поддержку, есть круглосуточный сапорт 24/7, которая обойдется в 200 т р. клиенту. И примерно знаем что будет 50 обращений в месяц для которых хватит ресурсов 2 х сотрудников.

А по факту выходит что у нас не 10, а 12 фун-ий. И если мы их оставляем - мы должны их поддерживать. В итоге будет на 50, а 60 обращений и 2х сотрудников саппорта не хватит. В итоге мы несем затраты.

134

Системный Анализ и Требования / Re: Противоречивость требований

« : 08 Октября 2010, 14:17:02 »

Я написал что систему менять нельзя Так что не подходит !

135

Системный Анализ и Требования / Re: Функционал не описанный в требованиях.

« : 08 Октября 2010, 12:00:01 »

Об этом я писал уже выше. Действительно, если в дальнейшем клиент скажет что "Да классно, мне нравится, но вот тут бы допилить", ему можно ответить "Ок, 200к"  .  И тогда это только плюс.

Поддержка оговаривается в рамках контракта на внедрение. И если поддержка не лимитирована (то есть должен чинить все и всегда), то вполне реальна ситуация, когда клиент говорит что "ваша левая" фича падает и ее нужно починить и допилить. А это ресурсы. А деньги те же что и без нее, так как согласовывались до ее появления. В итоге - убытки.