Имя: Пароль:
LIFE
Админ
OFF: Методология работы франчей по проектам
,
0 spock
 
13.08.14
08:23
Коллеги, поделитесь пожта информацией, как методологически работают франчи на проектах. Можно на конкретных франчах.

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

Все ли здесь перечисленное отражает методологию работы франчей?
Понятно, что на каждом пункте есть отклонения, но меня в данном случае волнует эталонная модель.
32 Chum
 
13.08.14
09:37
(31) даже так? а давайте всех франей накормим, напоим и денег с собой дадим.
33 Господин ПЖ
 
13.08.14
09:40
франь заходит, франь выходит

все встают, РП сажают...
34 Yuwa
 
13.08.14
09:40
(31) Подобные вещи неэтичны. Когда мы делали - всегда согласовывали формулировки с проверяемым франчом.
35 Chum
 
13.08.14
09:41
(31) какую компетенцию ты имеешь в виду? В ИТ?

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

гы...

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

а то что у них падает клиент, ибо их код писал явно бывший клюшечник и он крив как сабля турецкая - это им на пальцах объяснять надо
37 Timon1405
 
13.08.14
09:48
(35) Компетенцию в предметной области. а если (по "необсосанному с франем ТЗ") вам напроектируют регистр, который не закрывается и у вас база через год встанет, кто будет виноват? франь вам скажет "у нас все по ТЗ", а виноват будет РП со стороны заказчика
38 NcSteel
 
13.08.14
09:48
Вот тебе примерный сокращенный план, естественно в реальности он другой.

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

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

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

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

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

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

- Актуализированное описание  бизнес-процессов предприятий до 3-го уровня
- Сценарии интеграционного тестирования
- Протоколы ролевого интеграционного тестирования
- Детальная инструкция по первоначальной настройке системы
- Программа обучения
- Инструкции пользователей
- Учебные материалы по сценариям работы в системе в соответствии с диаграммами целевых бизнес-процессов ARIS
- Протоколы обучения и акты допуска к работе с системой
- Протоколы миграции данных
- Протоколы готовности к переводу в ОПЭ
- Методика проведения и анализа результатов работы в ПЭ
- Отчёт о готовности к переводу в ПЭ
- Приказы о вводе системы в промышленную эксплуатацию
- Приказы о выделении конечных пользователей
- Отчет о результатах работы в ПЭ
- Акт передачи системы в техническую поддержку
39 Yuwa
 
13.08.14
09:49
(36) выше было сказано: 1) выбираем правильного партнера 2) договариваемся по чесноку на берегу 3) контролируем ход процесса
40 х86
 
13.08.14
09:49
(0)пелотное внедрение забыл
41 spock
 
13.08.14
09:50
(29) Не нужно отвечать на вопросы из своей головы. Там имелось ввиду совсем другое.
42 Yuwa
 
13.08.14
09:52
(38) Отлично. За такое не стыдно просить существенные деньги. Бумаги-бумаги-бумаги
43 NcSteel
 
13.08.14
09:55
(42) Без контроля и документирования на должном уровне высоки риски срыва проекта по срокам и бюджету.

Да забыл в список включить работы по информированию, составлению рабочей группы... протоколы рабочих совещаний и подобное.
44 Yuwa
 
13.08.14
09:57
(43) Да я согласен. Я о том, что при таком подходе легче защитить достойный бюджет проекта
45 Господин ПЖ
 
13.08.14
09:59
>1) выбираем правильного партнера

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

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

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

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

клиент наворачивается когда выжирает всю память отпущенную ему богом и Гейтсом при проведении документа. Тех. эксперты франя говорят надо купить сервер. Что тут контролировать? Некомпетентность работников франя? К чему тогда ваши рейтинги, ваши ISO, ваши бумажки если в итоге все спихиваете на клиента
46 Лодырь
 
13.08.14
10:00
(45) Контролировать риски.
47 Guk
 
13.08.14
10:03
(45) +100...
48 NcSteel
 
13.08.14
10:07
(44) да какой бюджет! Важно же что бы Заказчик был доволен результатом!)
49 supremum
 
13.08.14
10:07
(42) Да, деньги, и только деньги, а результат дело десятое. Если для больших денег нужно много бумаги - значит ее нужно нагенерить в необходимом количестве.
50 supremum
 
13.08.14
10:11
+(49) Есть так же мнение, что количество бумаги снижает риски. Против этого сложно аргументировано возражать.
51 Yuwa
 
13.08.14
10:11
(45) 1) Правильный партнер- это тот, кто имеет компетенции в данной отрасли. Думаю, что есть партнеры, кто в теме по нашей отрасли, кроме нас. Для этого референц-визиты, вебинары, презентации практикуют
2) Дык, любой проект может быть подвергнут экспертизе. Не вник в смысл.  Вообще экспертиза - обоюдоострое оружие.
3) Контролировать сроки, качество, результаты. В проекте должен быть как РП со стороны партнера, так и со стороны клиента. Чтобы что-то внедрить- клиент должен сам пытаться изменяться. Согласитесь, что в проект- это общее дело клиента и автоматизатора.
52 supremum
 
13.08.14
10:15
+(50) Но почему же тогда проекты срываются несмотря на тонны макулатуры, бюджетов со многими нулями, толпой народа с громкими титулами. И что интересно, в начале проекта все себя пяткой в грудь бьют какие оне крутые.
53 Злопчинский
 
13.08.14
10:15
>  Включить пункт, что вся переписка по электронной почте имеет юридическую силу.
.
Обязательным условием проекта - наличие и ведение всей документации/переписки по проетку в рамках какой-нить грпвре/багратка/хелпдеска.
.
Эл.почта жутко неудобна. ее имеет смысдл использовать если проект не дольше недели, а количество задейстованных субъектов - по одному с каждой стороны ;-)
54 Yuwa
 
13.08.14
10:17
(52) Все проекты срываются по двум причинам: либо партнер не смог, либо клиент. Чаще все это переплетено.
55 supremum
 
13.08.14
10:18
(54) Точно сказано. Из двух человек виноват кто-то один или оба )
56 Злопчинский
 
13.08.14
10:19
(52) потому что - нет знания предметки. а те знания которые есть - носят достаточно общий характер если чо. Никакой франь не будет погружаться в сугубые тонкости частностей конкретного заказчика - это жрет очень много времени, да и не факт что у исполнителя есть такие спецы которые смогут реально погрузиться так.
.
надо учитывать что зачастую прописанноре в ТЗ/ТП описывает некую иделаьную ситуацию. в реальности - все оказывается совсем не так. дальше начинаются столкновения интересолв/меркантильные вопросы.
.
имхо это всего лишь часть причин.
57 Yuwa
 
13.08.14
10:21
(56) Абсолютно согласен. Поэтому я и сказал- главное знание предметной области
58 Злопчинский
 
13.08.14
10:23
... проект - это всегда компромисс между целями Заказчика и Исполнителя. Если Исполнитель уверяет вас что его цель - удовлетворить вас - плюньте ему в глаз. а лучше в оба. Соответсвенно успех проекта - зависит от того насколько гибки и готовы идти на копромиссы стороны.
.
ну и если у заказчика нет своего вменяемого специалиста - любой проект исполнителя будет успешен.
59 supremum
 
13.08.14
10:25
(56) Так если бы бюджет был маленький или сроки ограничены было бы понятно. А так да, несмотря на уставы, презентации, концепции с...ть все хотели на реальные процессы. Главное генереть макулатуру и осваивать бюджет. И что любопытно, если бы действительно было бы что нить сложное, обычное производство, ну немного большое, ну пусть куча вспомогательных производств, но таких тысячи по всей России.
60 spock
 
13.08.14
10:26
(58) "..если у заказчика нет своего вменяемого специалиста - любой проект исполнителя будет успешен.."
Это только с точки зрения исполнителя :)
61 Господин ПЖ
 
13.08.14
10:36
(46) пилять...

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

т.е. чтобы франь, увешанный бумажками как елка не завалил проект надо нанимать какой-то "ночной дозор" чтобы ходил и по рукам бил
62 Злопчинский
 
13.08.14
10:39
(60) ну с точки зрения заказчика - то кто будет оценивать...? - если я анчоусов не видел, но знаю только что это что-то из еды - впарить можно любую фуагра..
.
я например стотыщ лет думал что анчоусы - это что-то овощное...
63 NcSteel
 
13.08.14
10:40
(61) Еженедельные совещания с представителями руководителей всех рабочих групп со стороны Заказчика и Исполнителя позволяют выявить текущее состояние работ по проекту.
64 Господин ПЖ
 
13.08.14
10:42
>1) Правильный партнер- это тот, кто имеет компетенции в данной отрасли. Думаю, что есть партнеры, кто в теме по нашей отрасли, кроме нас. Для этого референц-визиты, вебинары, презентации практикуют

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

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

вообще ниочем... давайте купим сервер! давайте! помогло? нет. виноват опять клиент... не контролировал он "сертифицированных" изготовителей г.внокода
65 spock
 
13.08.14
10:45
(62) так оценивать будут конкретные потребители. Если заказали определенную функциональность, а по результатам ее либо не получили, либо получили костыльную фабрику, то проблема эскалируется до руководителей, а дальше все просто - эти люди не будут выяснять про неудобство расположения кнопок, либо работает и все(!) потребители довольны, либо финансирование заморозили.
66 Господин ПЖ
 
13.08.14
10:46
(63) что хреново и козе ясно
67 Турист
 
13.08.14
10:46
Что-то мне кажется, что проект из (0) уже завален ))
68 supremum
 
13.08.14
10:47
(64) +1
(66) Митинг собрать надо, как же иначе! :)
69 NcSteel
 
13.08.14
10:47
(66) Обычно что наступило хреново без рабочих совещаний выясняется только когда какая либо веха просрочена или на этапе ОПЭ...

Поэтому рабочие совещания под протокол позволяют выявить проблему на ранних этапах. Конечно это не панацея, но 90% выявляются.
70 Господин ПЖ
 
13.08.14
10:56
меня просто поражает, что есть методики общеизвестные для IT, есть методики "специализированные для 1с" с учетом низкой компетентности по IT, зыбкости нормативки и прочего...

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

как доходит до дела - вывод всегда один = виноват клиент. Не проконтролировал, не оценил риски, не оттащил от пульта, оставил одного в серверной
71 Timon1405
 
13.08.14
10:57
(63) Совещания это конечно хорошо(в том числе чтобы не отказывались потом от своих слов), но кто на этом совещании проверит, что в коде запросы в цикле не пишут? Финдир проверять точно не будет). Проблема может быть в том, что по бумагам уже танк собран, а на деле оглобля стоит на заднем дворе и к ней по ночам пытаются гусеницы нитками пришивать.
(65) "работает и все(!) потребители довольны" - ниочем без критериев того что именно должно работать. а угрозы "финанисирование заморозили" ни к чему хорошему не приведут при грамотном договоре
72 NcSteel
 
13.08.14
11:00
(70) Виноваты всегда оба. Обычно один не дорабатывает, а другой просто забил... вот и пагубный результат.
73 saasa
 
13.08.14
11:01
(1) шаришь ;)
74 NcSteel
 
13.08.14
11:01
(71) А зачем это проверять? Если код на тестовом стенде выполнят тестовое задание на 4-5 баллов по индексу апдекс, то и проверять ничего и не надо. Для этого и пишутся документы по нагрузочному тестированию.
75 Злопчинский
 
13.08.14
11:02
(71) что именно и как именно должно работать - это все зашибись. только проект тогда займет года три. и пока будут писать/решать что именно и как именно должно работать - все поменяется. или у франча/заказчика ведущий специалист сдрыснет куда нить... и по новой.
76 Господин ПЖ
 
13.08.14
11:02
>Виноваты всегда оба.

ну да... один лечил, а второй умер
77 Злопчинский
 
13.08.14
11:02
(74) согласен. мне вот пофигу что там внутри написано. если удовлетфоряет по функционалу и скорости.
78 Злопчинский
 
13.08.14
11:03
(76) такое случается. увы...
79 saasa
 
13.08.14
11:03
(77) скорость еще проверять надо на рабочих объемах.
80 NcSteel
 
13.08.14
11:04
(79) Это и есть нагрузочное тестирование. Генерируются объемы с запасом и прогоняется тестирование.
81 NcSteel
 
13.08.14
11:05
(76) Если Заказчик не заинтересован, то увы риски провала большие ((((
82 saasa
 
13.08.14
11:05
одинеснеков, как и "таджиков" нельзя оставлять без надзора и палки :)

пока стоишь с дубиной и контролируешь - все хорошо, чуть отвлекся - пошло, поехало.
83 NcSteel
 
13.08.14
11:06
(81) + уточню. Не просто Заказчик, а именно топ менеджмент Заказчика. ТОлько через топов можно продавить ответственность со стороны Заказчика на каждом этапе проекта.
84 NcSteel
 
13.08.14
11:06
(82) Это общая методика и тут не вопрос в 1С.
85 saasa
 
13.08.14
11:06
(81) смотря что считать провалом :)

если франч получил по договору сполна - это успех !
86 Джинн
 
13.08.14
11:06
(80) Оно как привидение - о нем много говорят, но практически никто его не видел :)
87 Господин ПЖ
 
13.08.14
11:06
(82) скрипт пошёль, пошёль... в серверную пришёль, а там hasp ешильме бишельме, рауз кирдык, себестоимость ек... раскривушка нада на выходные и вазилин - очень секаса не хватает
88 saasa
 
13.08.14
11:07
(84) ага
89 saasa
 
13.08.14
11:07
(86) не все до него доживают :)
90 NcSteel
 
13.08.14
11:07
(86) Мы применяем.
Нужно открыть для себя КИП
91 saasa
 
13.08.14
11:08
(87) как то так, да.
92 Господин ПЖ
 
13.08.14
11:08
(81) заказчик заинтересован в реальном решении проблемы, а не в советах по прикладыванию подорожника на гангрену
93 Джинн
 
13.08.14
11:09
(81) Гы... Нынешняя контора в чистом виде! Все топы жестко саботируют проект. Как прикрываясь бюрократическими процедурами, так и нагло динамят. Клерки, глядя на них, тоже энтузиазмом не горят. Уже пришлось перепланировать проект два раза, увеличив срок на 4 месяца.
94 saasa
 
13.08.14
11:10
(93) в мутной воде рыбы больше :)

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

Обычно, франчи после внедрения оказывают услуги сопровождения, в период которого доделываются все косяки. Здесь можно и нужно работать с франчом, эксплуатируя его по полной программе. Стоимость этого этапа соизмерима со стоимостью основного этапа. Значит, чтобы обезопасить себя, как Заказчика, нужно обеспечить какие-то стимулирующие меры, при которых Исполнитель не хотел бы соскочить с проекта, не доведя все до конца.
96 Господин ПЖ
 
13.08.14
11:11
(93) >Все топы жестко саботируют проект. Как прикрываясь бюрократическими процедурами, так и нагло динамят.

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

А если Заказчик заинтересован, то обычно идут всегда на встречу и организуют рабочие группы со своей стороны, назначают руководителя проекта и т.д.
98 Timon1405
 
13.08.14
11:12
(74) Вы все прям в 10ку пишете! Если еще и удается донести это   до Заказчика у которого изначальное понятие о критериях сводится к "-ну эт самое, Все работает, все проводится" и "все пользователи довольны", то просто респект вам.(ни тени сарказма)
99 saasa
 
13.08.14
11:12
(95) косяки исправляются бесплатно в период гарантии
100 Джинн
 
13.08.14
11:13
(90) Я тоже такой умный был по молодости. И слова всякие мудреные знаю тоже.

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

Отсюда старый индейский способ - вспоминаем старые проекты со сходной нагрузкой и основываясь на них выдаем требования к оборудованию.
101 saasa
 
13.08.14
11:14
(100) х2 на всякий случай :)
102 NcSteel
 
13.08.14
11:15
(98) Поэтому обычно с шашлычниками и не работаем ) гос закупки, тендеры.
103 saasa
 
13.08.14
11:16
(102) т.е. с теми, кому пох на затрат :)
104 NcSteel
 
13.08.14
11:16
(100) Я уже старый человек )))) и тоже энтузиазм потерял, но по опыту понимаю что без должного прорабатывания проекта высоки риски проекта.
105 NcSteel
 
13.08.14
11:16
(103) Далеко не так, торговля идет до рубликов.
106 Господин ПЖ
 
13.08.14
11:20
(97) конечно не заинересован...

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

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

- не оценил "некие риски"
- не был заинтересован
- не контролировал "некие загадочные процессы"
107 saasa
 
13.08.14
11:20
(105) ты про размер отката ? :))
108 Лодырь
 
13.08.14
11:21
(106) Если ты не прописал требования в железу и не настоял на тестировании - нечего на зеркало пенять.
109 Джинн
 
13.08.14
11:22
(96) Весь прикол в том, что босс их жестко замотивировал. Они при провале теряют проекта на бонусах сумму, сопоставимую с годовым доходом хорошего одноэсника.

Вы думаете это работает? Хрен там! Сплошные детские обиды:"У нас тут так хорошо все было... А тут лезут к нам, тыкают мордой в колхозную организацию работы и что-то навязывают... У нас и так все под контролем! Ну да, бюджеты отклоняются на 46%.... Ну да, себестоимость готовой продукции у нас средняя за тонну по всей номенклатуре.... Ну дебиторки просроченной за 12 лет на 40 лямов... Зато мы 4 ляма на фонде оплаты труда съеконмили! Как ошибка в формулах бюджета? Как не съекономили 4 ляма, и профукали 6 лямов? Ну бывают мелкие ошибки. Но работает же контора! Продукцию выпускает, продает... Прибыль даже есть...".
110 Джинн
 
13.08.14
11:24
(101) Практика проектного менеджмента говорит, что гораздо точнее умножать на число "пи" :)
111 saasa
 
13.08.14
11:25
(109) не мешайте людям пи...ть. :)
112 NcSteel
 
13.08.14
11:25
(107) Да что ты.... какие откаты, я даже не знаю что это )
113 Господин ПЖ
 
13.08.14
11:28
(108) какое накуй железо... ватсон, что вы несете

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

тестирование чего? Это не доработки на внедрении, это их типовой г.внокод включенный в поставку когда динозавры были живы...
114 Господин ПЖ
 
13.08.14
11:30
(109) претензии к пугавицам есть?

и потом "все при деле".
115 Господин ПЖ
 
13.08.14
11:36
(113) +

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

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

зеркало надо франям чаще к роже подносить. Мы в данной ситуации выступали как сторонние эксперты - знакомый бухгалтер  попросил помощь - контора устала от "внедрюков"
116 Джинн
 
13.08.14
11:43
(111) Видите ли, если бы они тырили, то я бы мог их как-то понять... Была бы хоть какая-то логика. Весь геморрой в том, что они не воруют! Я за полгода уже въехал во внутреннюю кухню предприятия настолько, что больше их знаю о нем. Просто колхоз... Один большой колхоз.
117 Джинн
 
13.08.14
11:46
(114) Гы! Как раз на совещании эту фразу мы и озвучили. Теперь я их на ответы типы "Мы не выполнили задачу в срок, потому что бухгалтерия не выдала нам данные..." я просто пишу в ответ "Претензии к пуговицам есть?" :)) Как будто я должен разруливать вопросы взаимодействия, возникающие внутри их конторы.
118 Господин ПЖ
 
13.08.14
11:47
(116) изображение бурной деятельности... кому-то страшно что окажется не нужным, кто-то попадет под чужое влияние т.к. сфера ответственности пропадет или сузится. Негде будет играть в вахтера и гонять за бумажками по отделами нельзя
119 Джинн
 
13.08.14
11:51
(118) Да, я склонен сводить все к завышенному ЧСВ. Т.е. риски чисто психологические и я их недооценил на этапе планирования. Попытки заинтересовать и вовлечь с моей стороны были, но не привели к результату. Либо я не так это делал, либо одно из двух :)

Но это тоже опыт. Хоть и отрицательный. В будущем буду учитывать и такого рода риски.
120 Yuwa
 
13.08.14
11:55
В целом получилось дельное обсуждение. Есть люди- кто в теме. Это приятно. Автору респект
121 Злопчинский
 
13.08.14
11:57
(82) золотые слова!
122 Господин ПЖ
 
13.08.14
11:58
(119) этим пренебрегать нельзя, особенно в конторах "специфического" склада
123 tenikov
 
13.08.14
12:03
(0) как делал я:
1. Обучение ключевых пользователей на примерах из демо-базы.
2. Фиксирование объема требований к системе и разделение их на "решается настройкой системы \ нужна разработка", оценкой объема, сроков, выставлением приоритетов и т.п.
3. Настройка системы, написание функциональных спецификаций для разработчиков.
4. Демонстрация ключевым пользователям реализации той части требований, которая покрывается настройкой.
5. Разработка, внутреннее тестирование.
6. Демонстрация ключевым пользователям реализзации полного объема требований.
7. Опытная эксплуатация (UAT).
8. Запуск (Go Live).

ЗЫ Франчи делают так, как в (1)
124 Timon1405
 
13.08.14
12:09
(123) как-то странно, то есть заказчик вот так с полпинка(пункт1) отрывает своих сотрудников от работы, чтобы освоить программу, которая ему, быть может, и не подойдет?? то есть вы всегда знаете, что именно будете внедрять?
125 saasa
 
13.08.14
12:12
(124) размер конторы же ;)
126 tenikov
 
13.08.14
12:13
(124) ну да.

этап пресейла, как по мне, в проектную методологию не входит.
у франчей, понятное дело, другое мнение на этот счет :)
127 NcSteel
 
13.08.14
12:15
(124) Обучать типовому функционалу надо, это позволяет на этапе обследование. Еще на этапе обучения идет первичный сбор требований и разъяснений что куда.
128 NcSteel
 
13.08.14
12:17
(127) + Насчет конфигурации, да первичный выбор обычно уже определен Заказчиком и обучение происходит на нем. И после обучения ясны поверхносные разрывы в функционале, которые позволят объяснить выбор другой конфигурации.
129 tenikov
 
13.08.14
12:17
(125) да, нюанс :)

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

все мои проекты - это различные виды финансового учета (ну, и расчет зарплаты временами).
конечных пользователей на таких проектах 20-30 максимум, из них 3-4 - ключевых (руководители направлений и\или отделов).
130 PR
 
13.08.14
12:20
(0) Эталонная модель как минимум раза в два больше.
Но обычно она даже меньше написанной.
На проекте в пару миллионов никакого смысла в некоторых вещах нет, только деньги расходовать.
131 PR
 
13.08.14
12:23
Вообще общая логика по поводу того, как бы попасть в бюджет, следующая.
Либо берется фикс-прайс по четко написанному заданию, который больше предполагаемых реальных трудозатрат раза в два — три.
Либо почасовка с примерной оценкой каждой текущей выполняемой задачи.
Дураков нет. Франч не будет за свои деньги делать клиенту счастье. Особо хитровыдуманные открывают книги по 1С и учатся программировать сами.