AXForum  
Вернуться   AXForum > Рынок > Рынок труда Microsoft Dynamics
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.12.2010, 23:02   #11  
Lz_ is offline
Lz_
Участник
 
50 / 32 (2) +++
Регистрация: 20.07.2007
Адрес: Минск (BY)
Цитата:
Сообщение от dmitryul Посмотреть сообщение
Lz_, Вы что-то путаете.
Нет, я ничего не путаю .

Скорее всего путаница возникает из-за не правильного использования терминологии. Термин Техническое задание (ТЗ) - это гостированный термин. Говоря проще, есть государственный стандарт, который определяет состав и содержание данного документа. Если документ соответсвует этим требованиям, то этот документ можно назвать ТЗ. Иначе, это что угодно, очень похоже, но это не ТЗ. Приводя аналогию это: Масло сливочное - ГОСТ XXXXXXX, Маслице сливочное - ТУ YYYYYYYY. Разницу чувствуете? Поробуйте - сразу почувствуете. Что написано в ГОСТе известно, что в ТУ - хз. Так именовать одинаковым названием продукты нельзя, а документы можно. От этого и вся путаница.


Цитата:
Сообщение от dmitryul Посмотреть сообщение
После диагностики бизнес-процессов клиента (не всегда он платит за это деньги) появляется документы "Коммерческое предложение", "План проекта" или что-то похожее, где указаны (приблизительно) рамки проекта и его стоимость. Очень приблизительно.

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

Цитата:
Сообщение от dmitryul Посмотреть сообщение
После того, как интегратор выбран, клиент перечисляет деньги ему за обследование предприятия (сроки и стоимость кстати, желательно для клиента зафиксировать). Если сроки не прописаны - тут вина исключительно заказчика, интегратор может месяцами обследовать предприятие, получая за это деньги и с 0 результатом на выходе.
После того, как интегратор выбран, клиент и интегратор заключают договор. Первым пунктом которого является Предмет договора. Вот тут и должно быть описано что и как будет сделано. Определены сроки и деньги.
Далее, прежде чем деньги получить, вы сначала работу сдайте. А то больно горячи, предоплату получить, а потом резину тянуть. Обследование, панимашли, у них , заказчик у них виноват, что сроки не указал. Типичный распил бабла. Аж смешно такое читать. Воинствующий дилетантизм, я бы так сказал

Цитата:
Сообщение от dmitryul Посмотреть сообщение
Результатом обследования (анализа бизнес-процессов) является ТЗ на проектирование (или Дизайн проекта - кто как называет),
Клиент не заказывал анализ бизнес-процессов, ему система нужна новая, а не анализы старой. Тем более, что новая система будет сделана по модели "как надо", а старая "как есть". Надеюсь, не нужно объяснять про несовпадение этих моделей и возможность трансформации и перераспределения функций пользователей в новой системе.

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


Цитата:
Сообщение от dmitryul Посмотреть сообщение
где подробнейшим образом оговорены:
1.Объем работ (с точностью до поля в таблице, кнопки - одним словом, очень детально)
ВОПРОС: Вы описываете только дополнительно создаваемые поля, кнопки формы или существующий функционал тоже описывается?

На этапе ТЗ п 1 технически не реализуем, т.е. не выполним. Как я уже писал, ТЗ может писаться на систему без привязки к платформе. В общем случае, система может быть реализована на нескольких платформах. Какие тогда таблицы, какие формы, о чем вы? П.1 это часть Технического или Рабочего проекта.

Цитата:
Сообщение от dmitryul Посмотреть сообщение
2. План-график работ с конкретными сроками сдачи этапов
Вот это правильно. Одобрям-с.

Цитата:
Сообщение от dmitryul Посмотреть сообщение
3. Пресловутый список и компетенция исполнителей на проекте
4. Стоимость исходя из компетенции по каждому пункту (форма такая-то, потребуется ПМ x часов, консультант y часов, разработчик z часов, исходя из их ставок форма стоит xxx евро).
Вот это все за борт . Если описанные исполнители уволились - переписываем ТЗ?
Вот как раз то, о чем я и писал. Продажа услуг, т.е освоение часов

ВОПРОС: Клиент говорит: Все ок меня все устраивает, но вот эта и эта, и вон та форма дорого, платить не буду. Что делаем?

ВОПРОС: Где документация по проекту? Где инструкции пользователей и конкретных рабочих мест? Когда появляется эксплуатационная документация?

Цитата:
Сообщение от dmitryul Посмотреть сообщение
Если сроки неправильно рассчитали, заказчик за них не переплачивает - сумма остается фиксированной!
Еще бы, а штраф за срыв сроков не хотите заплатить?

Цитата:
Сообщение от dmitryul Посмотреть сообщение
И еще, работал во многих крупных консалтинговых компаниях - где Вы видели почасовую оплату и освоенные часы, если это нормальный проект, а не под распил?

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

Если нет Дизайна - это возможно, но если оговорен четко объем работ и сроки, есть подписанный контракт на определенную сумму - какие тут часы?
Судя по вашему посту, вы весьма далеки от понимания того, когда, какие документы составляются по проекту и для чего они нужны. Это уровень ПМ, вам еще расти и расти до него.

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

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

Вот уж воистину, до проектов с фиксированной ценой нужно дорасти.

з.ы. Многа букаф, извините, больше не буду.
За это сообщение автора поблагодарили: mifi (-1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Различия между модулями CRM Vorman Сравнение ERP-систем 15 03.10.2008 13:31
Разница между консультантом и программистом Галина Рынок труда Microsoft Dynamics 28 18.03.2005 03:20
Сделка между Navision и Microsoft может быть сорвана [compulenta.ru] Nikolson Microsoft и системы Microsoft Dynamics 3 30.05.2002 09:21
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:45.