Цитата:
Сообщение от
Atar
1. А Вы уверены, что исполнителя устроит качество и детализация прописанных операций и требований?
2. Опытный специалист знает, как много он ещё не знает. Остальные думают, что за день можно оценить степень несоответствия и необходимость изменений, да ещё и задокументировать их.
Это действительно, к продавцам партнёров.
Вас правильно направили.
Я вижу, что Вы опытный специалист, поэтому недоумеваю, откуда такие противоречия в требованиях.
У меня как раз противоречий нет. Но, т.к. никто из присутствующих, судя по всему, такой документ не делал, то и возникает непонимание. Просто нет опыта работы с такой технологией.
Опишу свой подход к методологии, и что я подразумеваю под этой работой еще раз. Может быть, не все точно скажу, не придирайтесь, пожалуйста.
Этап Анализа:
1. Проводим анкетирование, интервьюирование, собираем документы, процедуры, учетные политики, отчетные формы - что есть, короче.
2. Составляем документы:
- Лист операций/требований. - экселевская таблица: БП/Операция/Требования к операции, тип требования, .. какие-то аналитики еще..приоритеты...
- Альбом печатных и отчетных форм.
Для финансов еще могут быть, понятно, план счетов, операции/проводки, ну для каждого контура автоматизации своя специфика..
3. Согласовываем список операций и требования - что все правильно, ничего не забыли.
4. Fit-gap анализ - в той экселевской таблице, которую только что согласовали, садится консультант и прописывает - что есть в системе, чего нет, где можно применить обходной путь, какую можно сделать доработку, сколько стоят доработки и т.д.
Вообще такой документ составить несложно, если вы систему знаете, опыт у вас был, да и вообще, пока вы обследование делаете, вы уже наполовину все придумали, надо только систематизировать, проверить, аккуратно прописать, ничего не забыть.
Про 1-2 это была оценка работы именно на моем проекте, потому что 1) у нас Аксапта уже много лет есть, перечень требований известен, обдуман и понятен, вопрос только (!) в функциональности 2012 версии - что-то, может быть, там добавилось, что может облегчить наше существование... На это много времени не надо. К тому же, есть подозрение, что по на большинство вопросов ответ будет "нет".
Почему именно хотелось, чтобы кто-то из Майкрософта помог сделать этот анализ - потому что мнения о функциональности 12й разняться. Например, мне в МС говорили, что появилась новая складская аналитика "Канал дистрибуции", а нам как раз это очень надо. Спросила у нашего нового подрядчика по Аксапте - они очень удивились, пошли в Аксапту посмотреть - нет такого. Не нашли такой аналитики в системе. Меня такие вещи настораживают. Коллеги из другого партнера тоже смотрят на наши требования - говорят "ничего нет". А у МС в презентациях все есть... Как так? Кому верить? Если есть - пусть покажут как работает..
5. С заказчиком просматриваем этот документ, и принимаем решение по доработкам - сколько стоит, какова важность требования, какой у заказчика бюджет - исходя из этих факторов проставляется в файлике решение что делаем по gap-требованиям - а - обходной путь б - доработка в - снимаем требование г - переносим доработку на более поздний этап.
6. При необходимости можно также написать текстовый документ "Отчет об обследовании", но, в целом, я считаю, это деньги на ветер. Только если заказчик сложный, и любит бумажки.
7. По итогам этапа подписываются: перечень требований, перечень доработок с разбивкой по этапам, альбом отчетных/печатных форм.
Также по итогам согласования перечня доработок уточняется бюджет на следующие этапы.
Этап Дизайн:
1. Берем табличку с операциями/требованиями, добавляем несколько колонок, и пишем в них дизайн системы и кратко идеи доработок.
2. Настраиваем прототип системы на тестовой базе. Обязательно для всех операций.
Помогает убить двух зайцев - 1 - консультант не ошибется в дизайне, потому что проверит свою идею, настроив ее в системе. А то бывало так поначалу - прочитал в мануале, что есть такой функционал, кнопки даже соответствующие в системе проверил, заложился на это в дизайне... А потом при внедрении вдруг обнаружилось, что это либо не работает вообще, либо работает совсем не так, как написано в мануале.. И начинается...
2 - заказчик увидит в системе настроенным весь свой контур, сразу может дать обратную связь, консультант что-то в дизайне поправит. Чем раньше замечание получено, тем дешевле оно обходится... Заказчику так легче согласовать дизайн и актировать работы по этапу. И для него при внедрении не будет уже новостью как это все будет работать.
3. Согласовываем дизайн.
Тестовый дизайн также можно написать при необходимости, но без фанатизма. Не копи-паст руководства пользователя.
Один партнер нам заявил как-то - да, у нас Дизайн системы является руководством пользователя, мы не пишем отдельного руководства. Редчайший бред.
Корректируем бюджет на этап Разработки при необходимости.
Этап Разработки
Пишем ТЗ, делаем разработку, тестирование...
ну дальше не буду расписывать..
Эта методология очень дешевая, эффективная и быстрая. Пишу это, потому что здесь звучат отсылки к заказчику, что, мол, это все дорого прописывать детально, поэтому только если заказчик отдельно готов платить.
Это как раз очень дешево. И быстро для консультанта. Выгодно всем - заказчик не платит лишнего, консультант не тянет время на написание многотомных документов, которые все равно никто не будет читать. Только рабочие функциональные таблицы, которые быстро пишутся, и по ним хорошо и легко потом работать.
Естественно, не претендую на то, что этот подход самый или единственно верный. Но он технологичный. Подсмотрен, кстати, у европейских консалтеров. Вообще им за науку большое спасибо.
Технология - это когда ты не делаешь лишних движений, это энергосберегающий режим. Это важно для снижения себестоимости проекта. Мы же работаем ради прибыли.. Качество работы тоже повышается, потому что снижается риск ошибок консультанта. Какие бы у тебя умные не были консультанты или разработчики, если нет эффективной, простой технологии - все будет дорого, и много ошибок, в первую очередь архитектурных.
Конечно, ваши рекомендации по методу решения этой проблемы - найти опытного специалиста у партнера - да, на практике так можно решить проблему. Если повезет. Если найдется хороший консультант (или несколько), если он не ошибется, если покопаться в коде, пособирать информацию везде.. это метод. Но это не система, это какое-то затыкание дыр. А я хочу выстроить систему. Это не просто, не быстро, но под лежачий камень вода не течет. Спасение утопающих - дело рук самих утопающих.
Вы пишете, что 1С внедряется без методологии.. В чем-то 1С может это себе позволить, она гораздо проще и более документированная. Аксапта более сложная система, рисков больше, здесь важно все делать аккуратно.
Я придерживаюсь правила "семь раз отмерь, один отрежь". Поэтому, прежде чем что-то внедрить или запрограммировать, хочу абсолютной уверенности в правильно выбранной архитектуре.Потому что эти ошибки самые дорогие. Не так страшно плохо запрограммировать что-то - это всегда можно поправить, как принять неправильное решение по архитектуре. Отсюда вся эта тема, и вопросы к Майкрософту. Потому что версия новая - х.з. как она там работает - куда стоит соваться, куда нет..Второй раз методом тыка и без документации изучать систему уже желания нет - это как стать второй раз гастарбайтером... "Опытные партнеры" тоже могут оказаться не такими уж опытными, как уже не раз случалось.
Anyway, всем спасибо за участие в дискуссии.