Коллеги, поделитесь пожта информацией, как методологически работают франчи на проектах. Можно на конкретных франчах.

Из того, что знаю точно по шагам:
1. Франч заходит на предприятие и проводит обследование:
   - цель обследования:
      - зафиксировать фактическое состояние процессов;
      - собрать функциональные требования;
      - погрузиться в предметную область самим;
      - сформулировать перспективную концепцию;
   - способ:
      - интервьюирование с ключевыми фигурами;
      - конспектирование и рассылка протоколов встреч;
   - результат:
      - документ "Отчет об обследовании", в котором зафиксированы фактическое состояние процессов, предложена перспективная концепция;
2. Формулирование технических (функциональных) требований в терминах бизнеса;
   - цель:
      - получить формальный документ, который бы содержал в себе ожидания и требования Заказчика;
   - результат:
      - документ "Технические (функциональные) требования", в котором перечислены все требования функциональных заказчиков, ограничения, регламенты и процессы;
3. Формулирование технического задания в терминах программирования;
   - цель:
      - получить формальный документ, которым бы могли пользоваться конкретные исполнители (программисты);
   - результат:
      - документ "Техническое задание", в котором описана объектная модель, подлежащая кодированию;
4. Кодирование;
   - результат:
      - программный продукт, соответствующий техническим (функциональным) требованиям;
5. Тестирование;
6. Внедрение;

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

(31) даже так? а давайте всех франей накормим, напоим и денег с собой дадим.

франь заходит, франь выходит

все встают, РП сажают...

(31) Подобные вещи неэтичны. Когда мы делали - всегда согласовывали формулировки с проверяемым франчом.

(31) какую компетенцию ты имеешь в виду? В ИТ?

Заказчику сугубо пофиг какой код внутри, ему незачем в нем разбираться. Заказчику нужен результат и он не станет обсасывать с франем каждое измерение того или иного регистра. Работает корректно? Да - хорошо, нет - исправляйте. Работает быстро? Да - хорошо, нет - оптимизируйте.

>Заказчику сугубо пофиг какой код внутри, ему незачем в нем разбираться. Заказчику нужен результат и он не станет обсасывать с франем каждое измерение того или иного регистра. Работает корректно? Да - хорошо, нет - исправляйте. Работает быстро? Да - хорошо, нет - оптимизируйте.

гы...

так эти дебилоиды из франей начинают чего-то бубнить про "купите сервер 1с 64" и наступит счастье...

а то что у них падает клиент, ибо их код писал явно бывший клюшечник и он крив как сабля турецкая - это им на пальцах объяснять надо

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

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

1. Подготовка проекта

1.1. Выполняемые работы:
- Разработка и утверждение Устава проекта и план-графика проекта
- Разработка концепций и регламентов
1.2 Выходные документ и результат:
- Устав проекта
- Детальный план-график проекта
- План по управлению организационными изменениями
- Презентация о старте проекта
- Концепция обучения
- Концепция миграции данных
- Программа и методика испытаний
- Проектное решение по формированию ролей и полномочий
- Концепция перехода в опытно-промышленную эксплуатацию
- Концепция поддержки пользователей
- Регламент по сопровождению пользователей
- Методика проведения и анализа результатов работы в ОПЭ
- Требования к техническому обеспечению
- Описание настроек Системы
- Руководство по администрированию системы

2. Ввод в эксплуатацию на всех предприятии, включая приемочное

2.1. Выполняемые работы:

- Проведение обследования предприятий и формирование фиксированного перечня функциональных требований
- Разработка концепции и инструментов миграции данных для исторических баз предприятий
- Тестирование инструментов миграции данных
- Доработка системы в соответствии с утвержденным перечнем функциональных требований
- Проведение приемочного тестирования
- Выезд на предприятия с целью консультирования пользователей при проведении приемочного тестирования в соответствие со сценариями тестирования
- Продуктивный запуск и поддержка пользователей предприятий
- Консультирование пользователей по работе с системой

1.2 Выходные документ и результат:

- Актуализированное описание  бизнес-процессов предприятий до 3-го уровня
- Сценарии интеграционного тестирования
- Протоколы ролевого интеграционного тестирования
- Детальная инструкция по первоначальной настройке системы
- Программа обучения
- Инструкции пользователей
- Учебные материалы по сценариям работы в системе в соответствии с диаграммами целевых бизнес-процессов ARIS
- Протоколы обучения и акты допуска к работе с системой
- Протоколы миграции данных
- Протоколы готовности к переводу в ОПЭ
- Методика проведения и анализа результатов работы в ПЭ
- Отчёт о готовности к переводу в ПЭ
- Приказы о вводе системы в промышленную эксплуатацию
- Приказы о выделении конечных пользователей
- Отчет о результатах работы в ПЭ
- Акт передачи системы в техническую поддержку

(36) выше было сказано: 1) выбираем правильного партнера 2) договариваемся по чесноку на берегу 3) контролируем ход процесса

(0)пелотное внедрение забыл

(29) Не нужно отвечать на вопросы из своей головы. Там имелось ввиду совсем другое.

(38) Отлично. За такое не стыдно просить существенные деньги. Бумаги-бумаги-бумаги

(42) Без контроля и документирования на должном уровне высоки риски срыва проекта по срокам и бюджету.

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

(43) Да я согласен. Я о том, что при таком подходе легче защитить достойный бюджет проекта

>1) выбираем правильного партнера

что значит правильный? это "нормальный" вполне себе вендор отраслевого решения, имеющий статусы всякие и прочие "рейтинги +18"

>2) договариваемся по чесноку на берегу

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

>3) контролируем ход процесса

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

(45) Контролировать риски.

(45) +100...

(44) да какой бюджет! Важно же что бы Заказчик был доволен результатом!)

(42) Да, деньги, и только деньги, а результат дело десятое. Если для больших денег нужно много бумаги - значит ее нужно нагенерить в необходимом количестве.

+(49) Есть так же мнение, что количество бумаги снижает риски. Против этого сложно аргументировано возражать.

(45) 1) Правильный партнер- это тот, кто имеет компетенции в данной отрасли. Думаю, что есть партнеры, кто в теме по нашей отрасли, кроме нас. Для этого референц-визиты, вебинары, презентации практикуют
2) Дык, любой проект может быть подвергнут экспертизе. Не вник в смысл.  Вообще экспертиза - обоюдоострое оружие.
3) Контролировать сроки, качество, результаты. В проекте должен быть как РП со стороны партнера, так и со стороны клиента. Чтобы что-то внедрить- клиент должен сам пытаться изменяться. Согласитесь, что в проект- это общее дело клиента и автоматизатора.

+(50) Но почему же тогда проекты срываются несмотря на тонны макулатуры, бюджетов со многими нулями, толпой народа с громкими титулами. И что интересно, в начале проекта все себя пяткой в грудь бьют какие оне крутые.

>  Включить пункт, что вся переписка по электронной почте имеет юридическую силу.
.
Обязательным условием проекта - наличие и ведение всей документации/переписки по проетку в рамках какой-нить грпвре/багратка/хелпдеска.
.
Эл.почта жутко неудобна. ее имеет смысдл использовать если проект не дольше недели, а количество задейстованных субъектов - по одному с каждой стороны ;-)

(52) Все проекты срываются по двум причинам: либо партнер не смог, либо клиент. Чаще все это переплетено.

(54) Точно сказано. Из двух человек виноват кто-то один или оба )

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

(56) Абсолютно согласен. Поэтому я и сказал- главное знание предметной области

... проект - это всегда компромисс между целями Заказчика и Исполнителя. Если Исполнитель уверяет вас что его цель - удовлетворить вас - плюньте ему в глаз. а лучше в оба. Соответсвенно успех проекта - зависит от того насколько гибки и готовы идти на копромиссы стороны.
.
ну и если у заказчика нет своего вменяемого специалиста - любой проект исполнителя будет успешен.

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

(58) "..если у заказчика нет своего вменяемого специалиста - любой проект исполнителя будет успешен.."
Это только с точки зрения исполнителя :)

(46) пилять...

что клиент тут может "контролировать"? риски чего, по каким метрикам?

т.е. чтобы франь, увешанный бумажками как елка не завалил проект надо нанимать какой-то "ночной дозор" чтобы ходил и по рукам бил

(60) ну с точки зрения заказчика - то кто будет оценивать...? - если я анчоусов не видел, но знаю только что это что-то из еды - впарить можно любую фуагра..
.
я например стотыщ лет думал что анчоусы - это что-то овощное...

(61) Еженедельные совещания с представителями руководителей всех рабочих групп со стороны Заказчика и Исполнителя позволяют выявить текущее состояние работ по проекту.

>1) Правильный партнер- это тот, кто имеет компетенции в данной отрасли. Думаю, что есть партнеры, кто в теме по нашей отрасли, кроме нас. Для этого референц-визиты, вебинары, презентации практикуют

очередные поиски неуловимого Джо, у которого все работает и кисельные реки

>3) Контролировать сроки, качество, результаты. В проекте должен быть как РП со стороны партнера, так и со стороны клиента. Чтобы что-то внедрить- клиент должен сам пытаться изменяться. Согласитесь, что в проект- это общее дело клиента и автоматизатора.

вообще ниочем... давайте купим сервер! давайте! помогло? нет. виноват опять клиент... не контролировал он "сертифицированных" изготовителей г.внокода

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

(63) что хреново и козе ясно

Что-то мне кажется, что проект из (0) уже завален ))

(64) +1
(66) Митинг собрать надо, как же иначе! :)

(66) Обычно что наступило хреново без рабочих совещаний выясняется только когда какая либо веха просрочена или на этапе ОПЭ...

Поэтому рабочие совещания под протокол позволяют выявить проблему на ранних этапах. Конечно это не панацея, но 90% выявляются.

меня просто поражает, что есть методики общеизвестные для IT, есть методики "специализированные для 1с" с учетом низкой компетентности по IT, зыбкости нормативки и прочего...

фране чего совещаются, скачут в мешках по корпоративам, учатся, сертифицируются...

как доходит до дела - вывод всегда один = виноват клиент. Не проконтролировал, не оценил риски, не оттащил от пульта, оставил одного в серверной

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

(70) Виноваты всегда оба. Обычно один не дорабатывает, а другой просто забил... вот и пагубный результат.

(1) шаришь ;)

(71) А зачем это проверять? Если код на тестовом стенде выполнят тестовое задание на 4-5 баллов по индексу апдекс, то и проверять ничего и не надо. Для этого и пишутся документы по нагрузочному тестированию.

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

>Виноваты всегда оба.

ну да... один лечил, а второй умер

(74) согласен. мне вот пофигу что там внутри написано. если удовлетфоряет по функционалу и скорости.

(76) такое случается. увы...

(77) скорость еще проверять надо на рабочих объемах.

(79) Это и есть нагрузочное тестирование. Генерируются объемы с запасом и прогоняется тестирование.

(76) Если Заказчик не заинтересован, то увы риски провала большие ((((

одинеснеков, как и "таджиков" нельзя оставлять без надзора и палки :)

пока стоишь с дубиной и контролируешь - все хорошо, чуть отвлекся - пошло, поехало.

(81) + уточню. Не просто Заказчик, а именно топ менеджмент Заказчика. ТОлько через топов можно продавить ответственность со стороны Заказчика на каждом этапе проекта.

(82) Это общая методика и тут не вопрос в 1С.

(81) смотря что считать провалом :)

если франч получил по договору сполна - это успех !

(80) Оно как привидение - о нем много говорят, но практически никто его не видел :)

(82) скрипт пошёль, пошёль... в серверную пришёль, а там hasp ешильме бишельме, рауз кирдык, себестоимость ек... раскривушка нада на выходные и вазилин - очень секаса не хватает

(84) ага

(86) не все до него доживают :)

(86) Мы применяем.
Нужно открыть для себя КИП

(87) как то так, да.

(81) заказчик заинтересован в реальном решении проблемы, а не в советах по прикладыванию подорожника на гангрену

(81) Гы... Нынешняя контора в чистом виде! Все топы жестко саботируют проект. Как прикрываясь бюрократическими процедурами, так и нагло динамят. Клерки, глядя на них, тоже энтузиазмом не горят. Уже пришлось перепланировать проект два раза, увеличив срок на 4 месяца.

(93) в мутной воде рыбы больше :)

порядок мало кому нужен

(71) "..при грамотном договоре.."
Как раз в этом и дело. Понимая логику франча, можно спрогнозировать, в каком месте он может повести себя непрофессионально, и, введя соответствующие пункты в договор, обезопасить все стороны.

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

(93) >Все топы жестко саботируют проект. Как прикрываясь бюрократическими процедурами, так и нагло динамят.

это понятно и вопросов даже не вызывает

(92) Далеко не факт, что Заказчик заинтересован в результате проекта.
Сталкивался с ситуацией, когда головная организация навязывала свой продукт на предприятие, соответственно Предприятие брыкалось.

А если Заказчик заинтересован, то обычно идут всегда на встречу и организуют рабочие группы со своей стороны, назначают руководителя проекта и т.д.

(74) Вы все прям в 10ку пишете! Если еще и удается донести это   до Заказчика у которого изначальное понятие о критериях сводится к "-ну эт самое, Все работает, все проводится" и "все пользователи довольны", то просто респект вам.(ни тени сарказма)

(95) косяки исправляются бесплатно в период гарантии

(90) Я тоже такой умный был по молодости. И слова всякие мудреные знаю тоже.

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

Отсюда старый индейский способ - вспоминаем старые проекты со сходной нагрузкой и основываясь на них выдаем требования к оборудованию.

(100) х2 на всякий случай :)

(98) Поэтому обычно с шашлычниками и не работаем ) гос закупки, тендеры.

(102) т.е. с теми, кому пох на затрат :)

(100) Я уже старый человек )))) и тоже энтузиазм потерял, но по опыту понимаю что без должного прорабатывания проекта высоки риски проекта.

(103) Далеко не так, торговля идет до рубликов.

(97) конечно не заинересован...

это же круто - ждать проведение документа 15 мин и получать краш. системы. Потом звонить франю чтобы их консультант через rdp заходил на сервер и проводил документ на серваке - там памяти хватало.

потом потратить 100 000? или сколько сейчас сервер приложений стоит за 64 бита? потратить время/деньги на перенастройку/перезапуск сервера. И получить "куй на блюде" и в итоге опять оказаться по вашей версии виноватым:

- не оценил "некие риски"
- не был заинтересован
- не контролировал "некие загадочные процессы"

(105) ты про размер отката ? :))

(106) Если ты не прописал требования в железу и не настоял на тестировании - нечего на зеркало пенять.

(96) Весь прикол в том, что босс их жестко замотивировал. Они при провале теряют проекта на бонусах сумму, сопоставимую с годовым доходом хорошего одноэсника.

Вы думаете это работает? Хрен там! Сплошные детские обиды:"У нас тут так хорошо все было... А тут лезут к нам, тыкают мордой в колхозную организацию работы и что-то навязывают... У нас и так все под контролем! Ну да, бюджеты отклоняются на 46%.... Ну да, себестоимость готовой продукции у нас средняя за тонну по всей номенклатуре.... Ну дебиторки просроченной за 12 лет на 40 лямов... Зато мы 4 ляма на фонде оплаты труда съеконмили! Как ошибка в формулах бюджета? Как не съекономили 4 ляма, и профукали 6 лямов? Ну бывают мелкие ошибки. Но работает же контора! Продукцию выпускает, продает... Прибыль даже есть...".

(101) Практика проектного менеджмента говорит, что гораздо точнее умножать на число "пи" :)

(109) не мешайте людям пи...ть. :)

(107) Да что ты.... какие откаты, я даже не знаю что это )

(108) какое накуй железо... ватсон, что вы несете

>не настоял на тестировании

тестирование чего? Это не доработки на внедрении, это их типовой г.внокод включенный в поставку когда динозавры были живы...

(109) претензии к пугавицам есть?

и потом "все при деле".

(113) +

"тестирование" если на то пошло показало что кодированием занимаются бывшие клюшечники не читавшие ИТС и способы решения проблемы предложенные вендором к реальной жизни отношения не имеют никакого

> нечего на зеркало пенять.

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

(111) Видите ли, если бы они тырили, то я бы мог их как-то понять... Была бы хоть какая-то логика. Весь геморрой в том, что они не воруют! Я за полгода уже въехал во внутреннюю кухню предприятия настолько, что больше их знаю о нем. Просто колхоз... Один большой колхоз.

(114) Гы! Как раз на совещании эту фразу мы и озвучили. Теперь я их на ответы типы "Мы не выполнили задачу в срок, потому что бухгалтерия не выдала нам данные..." я просто пишу в ответ "Претензии к пуговицам есть?" :)) Как будто я должен разруливать вопросы взаимодействия, возникающие внутри их конторы.

(116) изображение бурной деятельности... кому-то страшно что окажется не нужным, кто-то попадет под чужое влияние т.к. сфера ответственности пропадет или сузится. Негде будет играть в вахтера и гонять за бумажками по отделами нельзя

(118) Да, я склонен сводить все к завышенному ЧСВ. Т.е. риски чисто психологические и я их недооценил на этапе планирования. Попытки заинтересовать и вовлечь с моей стороны были, но не привели к результату. Либо я не так это делал, либо одно из двух :)

Но это тоже опыт. Хоть и отрицательный. В будущем буду учитывать и такого рода риски.

В целом получилось дельное обсуждение. Есть люди- кто в теме. Это приятно. Автору респект

(82) золотые слова!

(119) этим пренебрегать нельзя, особенно в конторах "специфического" склада

(0) как делал я:
1. Обучение ключевых пользователей на примерах из демо-базы.
2. Фиксирование объема требований к системе и разделение их на "решается настройкой системы \ нужна разработка", оценкой объема, сроков, выставлением приоритетов и т.п.
3. Настройка системы, написание функциональных спецификаций для разработчиков.
4. Демонстрация ключевым пользователям реализации той части требований, которая покрывается настройкой.
5. Разработка, внутреннее тестирование.
6. Демонстрация ключевым пользователям реализзации полного объема требований.
7. Опытная эксплуатация (UAT).
8. Запуск (Go Live).

ЗЫ Франчи делают так, как в (1)

(123) как-то странно, то есть заказчик вот так с полпинка(пункт1) отрывает своих сотрудников от работы, чтобы освоить программу, которая ему, быть может, и не подойдет?? то есть вы всегда знаете, что именно будете внедрять?

(124) размер конторы же ;)

(124) ну да.

этап пресейла, как по мне, в проектную методологию не входит.
у франчей, понятное дело, другое мнение на этот счет :)

(124) Обучать типовому функционалу надо, это позволяет на этапе обследование. Еще на этапе обучения идет первичный сбор требований и разъяснений что куда.

(127) + Насчет конфигурации, да первичный выбор обычно уже определен Заказчиком и обучение происходит на нем. И после обучения ясны поверхносные разрывы в функционале, которые позволят объяснить выбор другой конфигурации.

(125) да, нюанс :)

я не внедрял (и не стремлюсь) всякие "риал-тайм производства на 100500 одновременно работающих пользователей".

все мои проекты - это различные виды финансового учета (ну, и расчет зарплаты временами).
конечных пользователей на таких проектах 20-30 максимум, из них 3-4 - ключевых (руководители направлений и\или отделов).

(0) Эталонная модель как минимум раза в два больше.
Но обычно она даже меньше написанной.
На проекте в пару миллионов никакого смысла в некоторых вещах нет, только деньги расходовать.

Вообще общая логика по поводу того, как бы попасть в бюджет, следующая.
Либо берется фикс-прайс по четко написанному заданию, который больше предполагаемых реальных трудозатрат раза в два — три.
Либо почасовка с примерной оценкой каждой текущей выполняемой задачи.
Дураков нет. Франч не будет за свои деньги делать клиенту счастье. Особо хитровыдуманные открывают книги по 1С и учатся программировать сами.