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

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

Все ли здесь перечисленное отражает методологию работы франчей?
Понятно, что на каждом пункте есть отклонения, но меня в данном случае волнует эталонная модель.
1 Трик
 
13.08.14
08:26
(0) чиво?

вот вся метода франча.

Прикидываем сложность проэкта.

Проэкт простой - кидаем туда студня.
проект средний - кидаем туда студня и разводим на предпроэктное обследование
Проэкт сложный - трем ладошки - кидаем туда студня - разводим на предпроэктное обследование. если заказчик не отказался от нас говорим что делим все на этапы, трем ладошки и т.д.
2 vqwy
 
13.08.14
08:31
(1) гыыыыыы
3 vqwy
 
13.08.14
08:32
(1) чувствуется, что человек с опытом работы во франче
4 Yuwa
 
13.08.14
08:34
(0) У нас примерно так.
5 Лодырь
 
13.08.14
08:38
(0) Все может быть совершенно не так, или не совсем так. имхо формат вопроса не форумный и публика не та.
6 spock
 
13.08.14
08:41
(5) "Все может быть совершенно не так.."
Это понятно, все-таки акцентирую внимание на эталонную модель методологии франчей.
7 Yuwa
 
13.08.14
08:44
(6) Никакой эталонной модели не существует
8 Chum
 
13.08.14
08:44
(0) отсутствует пункт "Обучение пользователей"

Если твой интерес, как Заказчика, то помимо этого плана действий есть несколько важных нюансов.
1. В договоре четко прописать, что франь не имеет права привлекать сторонников, только собственными силами, а то нарисуют цену за проект, а на самом деле наймут подрядчиков за тарелку супа. Дельту ессно в карман;
2. Т.к. сотрудники франя будут работать на Заказчика, то затребовать развернутое резюме на каждого, а СБ Заказчика пусть не поленится и проверит;
3. Если у франя не было успешного аналогичного проекта на родственном предприятии, то гнать взашей. Если проекты были, то съездить туда и посмотреть что к чему и как, пообщаться с руководством и пользователями;
4. В договоре процесс внедрения разбить на блоки, прописать критерии выполнения по каждому и условия оплаты. Акт выполненных работ по каждому пункту. Поможет снизить риски невыполнения обязательств франем;
и т.д.

Иначе получайте (1).
9 Лодырь
 
13.08.14
08:46
(6) Эталонная модель примерно соответствует эталонной методике управления ИТ проектами вцелом. Что выхотите услышать сверх этого?
10 ReaLg
 
13.08.14
08:46
(6) ИМХО тогда еще нужно упомянуть, что заказчик тоже "эталонный". Т.е. он понимает, зачем ему нужны все эти этапы, что будет если выбросить один или несколько из них и т.д.
11 spock
 
13.08.14
08:47
(8) про СБ и аналогичные проекты, на которые следует съездить, важные замечания, спасибо.
12 spock
 
13.08.14
08:51
(9) у всех мало-мальски серьезных франчей есть методология работы, которой они придерживаются. Отсылка к стандартам ведения ИТ-проектов не совсем корректна, т.к. стандарты общие, а 1С определила свою нишу с устоявшимися подходами.
13 Yuwa
 
13.08.14
08:52
(11) С моей точки зрения, предметная компетенция партнера - самое главное. Тогда п.1-3 вашей модели делается за один проход. У нас это все один этап.
14 Yuwa
 
13.08.14
08:52
(12) В (9) верно сказано. 1С никакого своего метода не выдумывала
15 spock
 
13.08.14
08:55
(13) Готов согласиться, только с несколькими оговорками:
- франч небольшой - если большой, то франч мотивирован запустить, как можно больше, специалистов;
- на предприятии отсутствует своя компетенция;
16 gae
 
13.08.14
08:57
(0) В п.1 обычно проводится "горизонтальное" обследование, направленное на выявление всех блоков, взаимосвязей между ними, обследуется информационная система. Упор делается на "что делается" и на взаимосвязи.
А углубленное "вертикальное" обследование по отдельным блокам делается уже в п.2, с упором на "как делается", сразу же с анализом ситуации, возможностей программы и с формулировкой оптимальных тех. требований.
17 йети
 
13.08.14
08:59
(0) смотри 1С:ПрофКейс
18 Chum
 
13.08.14
08:59
(11) пожалуйста. Поездка  на другое предприятие называется референс-визит и организовать должен франь.

Кстати, весьма немаловажным является изучение судебной практики франя: с кем, когда и почему они судились, каков результат.

Сам договор лучше оформить, как договор подряда, а не оказания услуг. Включить пункт, что вся переписка по электронной почте имеет юридическую силу.
Обязательна подписанная карты ответственных лиц, как со стороны франя, так и со стороны Заказчика.
И т.д.
19 Yuwa
 
13.08.14
08:59
(15) Я бы на вашем месте не методики проекта обсуждал, а приложил все усилия, чтобы выбрать компетентного в вашей отрасли партнера. Большой он и ли маленький- вам какая разница. Лишь бы на ваш проект хватало ресурсов.
20 Yuwa
 
13.08.14
09:04
(19)+ Меня всегда раздражает, когда парикмахер меня спрашивает, типа вас ножницами стричь или машинкой.. Я сообщаю, что мне без разницы чем, лишь было бы красиво.
21 Трик
 
13.08.14
09:08
(17) звучит как 1С:ПокерФейс
22 spock
 
13.08.14
09:18
(20) я сковырнул какую-то болячку?

Вопрос, поднятый мной в (0), имеет и должен иметь место быть. Потому что с людьми нужно договариваться "на берегу". А не устраивать тяжбу, когда в процессе подстригли садовыми ножницами, по принципу: "какая вам разница, чем вас стричь, ведь мы профессионалы".
23 mmk
 
13.08.14
09:20
(0) Да много чего нет. Этапы согласований, Инструкции, Обучение, Сопровождение и т.д.
24 Yuwa
 
13.08.14
09:23
(22) Нет, на моем толстокожем теле болячки не бывают. Я согласен, что договариваться нужно на берегу, только не стоит пытаться учить парикмахера как ему стричь, а доктора учить как лечить ваши прыщи. И доктора и парикмахера просто нужно уметь выбирать. Такая вот простая мысля
25 Лодырь
 
13.08.14
09:28
(22) Дык развернутый ответ на ваш вопрос занимает не одну толстую книжку. Иначе он (ответ) будет только вреден, поскольку будете пытаться сделать то, чему не обучены и нести глупые затраты непонятно на что.
26 spock
 
13.08.14
09:28
(24) "..не стоит пытаться учить.."
Я был неправильно понят, моя цель спрогнозировать шаги франча и заранее понять, куда меня ведут, чтобы вовремя среагировать.
27 spock
 
13.08.14
09:31
+26 а для этого нужно понимать, по какой методичке они работают.
28 Yuwa
 
13.08.14
09:31
(26) Тогда вы уже достаточно осведомлены. То, что вы написали- называется проектным подходом. Это хорошо, если реально работать так, а не иммитировать
29 Лодырь
 
13.08.14
09:32
(27) Бог мой, если вы работая с внешним подрядчиком, не понимаете что будет дальше - меняйте РП. Это его провал.
30 Chum
 
13.08.14
09:35
(24) Именно - уметь выбирать. На практике многие ведутся на яркую вывеску и внешний лоск, под которыми зачастую скрываются даже не студенты, а ПТУ-шники.

(26) "И Опыт - сын ошибок трудных...". Дабы не гадать на кофейной гуще просто обзвони родственные предприятия, поговори, спроси кого нанимали, как успехи и т.д. Так и франя приличного найти можно, а пока будешь составлять конкурентный лист, то включи в него цены основных внедренцев с сайта 1С.
31 Timon1405
 
13.08.14
09:36
(0) можно добавить пункт 3.1 - экспертиза ТЗ другим франчом, если в штате нет компетентного специалиста
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С и учатся программировать сами.
Здесь можно обсудить любую тему при этом оставаясь на форуме для 1Сников, который нужен для работы. Ymryn