От Lessonslearned:
 
To s_ustinov:
Спасибо за развернутый ответ.

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

По поводу предложенной методики. Не вижу особых противоречий.
 
s_ustinov

Диагностика

* Определение списка требований к системе, которые необходимо (желательно) выполнить в данном проекте. Список состоит из достаточно крупных блоков. В требования включаются только прикладные задачи, технические аспекты обсуждаются отдельно. Кроме прямо упоминающихся клиентом надо обязательно уточнить, какая функциональность имеющейся системы или систем используется.

Также было в предложенном мною варианте.

Все требования делятся на несколько групп:

s_ustinov

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

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

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

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

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

Приоритезация требований - разумеется будет. В данном случае не была описана, поскольку планировался иной подход, т.е. хотелось сначала расписать большими мазками фазы проекта, определить подход и количество фаз, а уже далее расписывать более подробно действия. Кроме того, для конкретных действий типа приоритезации требований есть BABoK в котором все подробно расписано и откуда планировал взять то, что понадобится...

s_ustinov

* Составляется таблица наличия возможностей по внедрению каждого из требований. Существует 4 области оценки:
1. Знания и навыки клиента в данной области: -1 - не выполняют такие функции (нет опыта); 0 - выполняют, но результатом выполнения недовольны (возможно, неправильный подход или алгоритм - есть знание, как не получится (неправильно) делать); 1 - выполняют такие функции и результат удовлетворительный (есть необходимый опыт и знания, хотя возможно сейчас делается не самым эффективным способом). Обязательный (критический) функционал по определению имеет уровень 1, за исключением тех случаев, когда клиент начинает заниматься новой деятельностью или сильно поменялись условия работы.
2. Возможности предлагаемой системы в данной области: -1 - нет требуемого функционала; 0 - есть функционал, но работает некорректно (внедрения такого функционала были неудачными или требовали больших переделок); 1 - в системе есть необходимый функционал (возможно, требует незначительных модификаций).
3. Знание консультантами исполнителя требуемого функционала предлагаемой системы: -1 - с таким функционалом не сталкивался; 0 - изучал функционал, но не внедрял; 1 - внедрял, но в другой системе; 2 - внедрял в предлагаемой системе, но данный функционал не заработал (или весь проект провальный, или неудачное внедрение именно этого модуля); 3 - внедрял в предлагаемой системе, внедрение удачное.
4. Знание консультантами исполнителя предметной области: -1 - о данной задаче ничего не знает; 0 - есть теоретические знания, на практике не сталкивался; 1 - работал (в штате или на проекте внедрения) в организации, где подобную задачу пытались решить, но решение оказалось неудачным (не заработало, работало неправильно); 2 - работал (в штате или на проекте внедрения) в организации, где подобную задачу успешно решали; 3 - работал (в штате или на проекте внедрения) в организации, где подобную задачу успешно решали, при этом специфика работы организации (имеющая отношение к данной задаче) такая же, как у клиента.

Максимальный совокупный балл по всем областям оценки равен 8 (вероятность успешного внедрения в заранее оговоренные сроки и стоимость близка к 1), минимальный -4 (есть высокая вероятность того, что данное требование вообще не получится выполнить).

Это обычный Gap analysis. Он в моем варианте присутствует на фазе анализа. Причина того, что Gap analysis помещен на стадию Анализа, а не Диагностики в том, что по предложеной мною методике на стадии Диагностики контракт еще не заключен, а ни один консультант не станет проводить Гап анализ бесплатно. Из своего опыта могу сказать, что обычно Гапы для системы составляются отдельно от поставщика и только когда уже происходит их рассмотрение обединяют пары Поставщик/системы. Если в данном случае речь идет не о полноценной стадии Гап анализа, а просто о заполнении некого опросника, то в предложенной мною методике это есть (см. Диагностика - Описание
Кстати, в какой момент у вас заключается договор на внедрение?

s_ustinov

* Выясняются прочие ограничения и требования к проекту внедрения.
* Анализируется возможность выполнения проекта внедрения в целом с учетом всех требований и ограничений. Требования к системе с оценкой возможностей внедрения 1 и ниже являются рискованными и существует высокая вероятность ошибки со сроками и стоимостью их внедрения, или же вообще провала внедрения данного функционала. Готов ли заказчик к внедрению системы с гарантированным внедрением только тех требований, которые получили высокую оценку возможности внедрения? Возможно, есть и другие препятствия - недостаточный срок или бюджет для такого объема работ или еще что-то.

Все вышеперечисленное есть в предложенном мною варианте в стадии Диагностики.

s_ustinov

* Разрабатывается предварительный план проекта. Весь требуемый функционал делится на три группы:
1. Будет внедрено к запуску системы в эксплуатацию.
2. Будет внедрено в течении некоего периода (скорее всего речь будет идти об 1-2 месяце) после запуска.
3. Нет жестких временных рамок по моменту внедрения.

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

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

s_ustinov

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

Из моей практики, мало кто соглашается на предварительную стоимость. Обычно все требуют Fixed price контракты. Договоры вида Cost reimbursement или T&M любят консультанты, но я бы не сказал, что они у нас сильно распространены.

s_ustinov

* Проводится "обучение" ключевого персонала заказчика - в стандартной базе проводится тренинг по выполнению основных бизнес процессов в системе. Вводятся новые товары, покупатели, меняются цены, выписываются документы продажи и т.п.

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

s_ustinov

В первую очередь очень подробно рассматривается обязательный для клиента функционал (работа с тестовыми данными и примерами) и фиксируются все замечания и пожелания.

Примеры уже готовы? Это, как я понимаю для стандартного функционала? Если да, то об этом же я писал в посте от 24 фев 10, 15:57
 
s_ustinov

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

Я уже писал, что не уверен, что кто-то согласится выполнить все это как пресейл, т.е. бесплатно. Это мое мнение...

s_ustinov

* Если проводилось "обучение", заключается доп соглашение к договору, в котором более детально прописывается объем функционала, который будет внедрен к старту системы и в течении ограниченного времени после запуска, сроки и стоимость.

См. выше.

Продолжение в следующем посте, а то слишком длинные посты получаются...
Да, какой срок планируется для стадии Диагностики?
 

s_ustinov

Внедрение функционала, необходимого для выполнения повседневных операций и запуск системы в эксплуатацию

* Если не проводилось "обучение" - проводится и выявляются все нюансы, которые должны быть выполнены.
* Если объем работ по реализации нюансов превышает тот объем работ, что были зафиксированы в договоре - проводятся дополнительные переговоры с заказчиком и уточняются сроки, бюджет и объем внедряемого функционала.

Вот тут-то и возникнут трения насчет цены и т.д. Т.е. если Заказчика не удовлетворит цена, то получится, что подрядчик стадию Диагностики выполнил бесплатно.

s_ustinov

* Составляется полный список всех справочников и остатков, которые должны быть введены в систему к запуску. Определяется, откуда и как будет получена вся необходимая информация к моменту старта и как она будет введена в систему. Выполняются работы по подготовке данных и методики их получения и загрузки (ETL).
* Составляется список сотрудников, которые должны начать работать с системой сразу с момента запуска (не обязательно точный список с фамилиями, можно указать должности, типы выполняемых операций и количество сотрудников для каждой должности).
* Производится установка системы на сервер.
* Выполняется настройка системы.
* Выполняются (при необходимости) доработки стандартного функционала.
* Готовятся краткие "Руководства пользователя" - инструкции по выполнению наиболее часто встречающихся операций. Готовятся на основе типовых инструкций с учетом модификаций и настроек конкретного внедрения.
* Тестируется возможность работы пользователей с системой - вход в систему и работа с терминалов в основном офисе, в удаленных офисах, печать документов, сохранение и открытие файлов и т.п.
* Производится тестовая загрузка справочников и остатков.
* Проводится тестирование системы и одновременно базовое обучение пользователей - как можно больше пользователей заходят в систему и пытаются выполнить свои обычные действия с тестовыми данными и остатками.
* Исправляются все обнаруженные недочеты с загрузкой справочников и остатков, настройками системы, руководствами пользователя и решаются прочие выявленные проблемы.
* Выполняется рабочая загрузка справочников и остатков и проверяется корректность и полнота загруженных данных.

По сути описан roll-out план, совмещенный с планом миграции, которые присутствуют у меня на стадиях Разработки и Развертывания...
Описаны работы уровнем ниже. У меня они не описаны именно потому, что сначала необходимо определиться с подходом и стадиями работ...
Слишком подробно для описания фаз проекта. По сути несколько фаз предложенных мною объединены в одну. Нет работ по составлению ТЗ или ТП, т.е. функциональные требования каким-то образом превратились в доработки, что приведет к отсутсвующей документации и подсаживанию клиента на одного подрядчика, а также к итерационным доработкам вида: "...а пусть вот эта кнопочка будет синей и в левом верхнем углу...".

s_ustinov

Внедрение прочего обязательного функционала и часть желательного функционала (повышающего удобство работы / производительность труда)

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

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

Обычно работы по внедрению релиза 2 и дальнейших повторяют работы по внедрению первого релиза...

s_ustinov

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

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

s_ustinov

Внедрение прочего функционала, входящего в проект

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

* Анализ. С сотрудниками заказчика подробно обсуждаются требования. Так как концентрируются на одной задаче, легче выявить все нюансы. Также очень помогает то, что пользователи уже имеют опыт работы в системе и понимают, в каком "окружении" будет выполнятся внедряемый функционал.
* Согласование. Уточняется на основе тщательного анализа требуемый объем работ и с заказчиком согласовывается уточненная стоимость и сроки внедрения данного функционала (предварительная оценка была сделана на этапе диагностики).
* Разработка. Выполняется настройка системы и/или выполняются доработки.
* Тестирование, исправление ошибок и обучение. Совместно с пользователями проверяется корректность работы внедряемого функционала. При необходимости вносятся исправления. Параллельно выполняется обучение пользователей использованию нового функционала.
* Ввод в эксплуатацию. Функционал начинает использоваться в работе.
* Подписание акта с заказчиком и получение оплаты.

На мой взгляд, здесь описаны обычные процессы поддержки...

s_ustinov

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

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

s_ustinov

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

Не зависит от методики. По прошествии времени после внедрения сотрудники при любом подходе будут разбираться в системе лучше, чем в начале проекта.

s_ustinov

Поддержка и дальнейшее усовершенствование системы

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

Согласен с тем, что данный этап не входит в проект. Поэтому я его и не включал. Про передачу системы на поддержку и про контракт на поддержку у меня есть в этапе Закрытия
 

От s_ustinov:
 
lessonslearned

Приоритезация требований - разумеется будет. В данном случае не была описана, поскольку планировался иной подход, т.е. хотелось сначала расписать большими мазками фазы проекта, определить подход и количество фаз, а уже далее расписывать более подробно действия. Кроме того, для конкретных действий типа приоритезации требований есть BABoK в котором все подробно расписано и откуда планировал взять то, что понадобится...

зачем приоритеты в моей методике - понятно. а для чего именно они в вашей?

lessonslearned

Это обычный Gap analysis. Он в моем варианте присутствует на фазе анализа. Причина того, что Gap analysis помещен на стадию Анализа, а не Диагностики в том, что по предложеной мною методике на стадии Диагностики контракт еще не заключен, а ни один консультант не станет проводить Гап анализ бесплатно. Из своего опыта могу сказать, что обычно Гапы для системы составляются отдельно от поставщика и только когда уже происходит их рассмотрение обединяют пары Поставщик/системы. Если в данном случае речь идет не о полноценной стадии Гап анализа, а просто о заполнении некого опросника, то в предложенной мною методике это есть (см. Диагностика - Описание
Кстати, в какой момент у вас заключается договор на внедрение?

а можно ссылочку? :-))))))))
все, что я видел предназначалось немного для других целей и соответственно выполнялось не совсем так. по времени - 2-3 часа - ближе к опроснику. и опять же у вас есть, но не оно - для других целей. ну а то, что будет делать сам поставщик... :-))))))))))) почитайте описания потенциальных клиентов в ваших же примерах ))))

lessonslearned
План проекта, правда у меня разрабатывается на стадии Анализа. На стадии Диагностики можно только весьма высокоуровневый план составить. Разбивка на несколько групп присутствует почти на любом проекте. Обычно это называется релизами. Соответственно в первый релиз, действительно включается только критический функционал, все остальное выносится в последующие релизы. Релизы, для тех кто не понял имеются ввиду не программные, а проектные, т.е. не обязательно требуется разработка.

то есть сперва фиксируем цену, а потом пишем план...
и почему бывают превышения бюджета? )))))))))

lessonslearned
Из моей практики, мало кто соглашается на предварительную стоимость. Обычно все требуют Fixed price контракты. Договоры вида Cost reimbursement или T&M любят консультанты, но я бы не сказал, что они у нас сильно распространены.

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

lessonslearned
У меня тренинги вынесены на стадию Проектирования, т.к. я не был уверен, что к моменту Анализа будет готов прототип и уж тем более не прокатит обучение на стадии Диагностики (т.е. до заключения договора.). Если подразумевается, что есть готовая среда тестирования к моменту стадии Анализа, то, наверное, да, можно перенести тренинги туда. Но я те уверен. Прошу сообщество высказаться по этому поводу, где должно быть обучение системы и можно ли определить его точно на какой-то стадии или же оно может быть на любой, в зависимости от проекта.

Примеры уже готовы? Это, как я понимаю для стандартного функционала? Если да, то об этом же я писал в посте от 24 фев 10, 15:57

Я уже писал, что не уверен, что кто-то согласится выполнить все это как пресейл, т.е. бесплатно. Это мое мнение...

"обучение" - платная услуга, но по себестоимости - все таки часть пресейла. хотя все зависит от объема. просто в течении пары часов показать клиенту - бесплатно.

а в посте от 24 фев 10, 15:57 ничего по этой теме не нашел - о чем вы?

lessonslearned

Да, какой срок планируется для стадии Диагностики?

2-3 дня (не полностью) без обучения - пол дня беседы с клиентом, пол дня заполнение опросника, составление плана и подсчет приблизительной суммы, пол дня заключение договора - итого 12 часов.
обучение - 2-3 дня 

От s_ustinov
lessonslearned

Вот тут-то и возникнут трения насчет цены и т.д. Т.е. если Заказчика не удовлетворит цена, то получится, что подрядчик стадию Диагностики выполнил бесплатно.

да

lessonslearned

По сути описан roll-out план, совмещенный с планом миграции, которые присутствуют у меня на стадиях Разработки и Развертывания...
Описаны работы уровнем ниже. У меня они не описаны именно потому, что сначала необходимо определиться с подходом и стадиями работ...
Слишком подробно для описания фаз проекта. По сути несколько фаз предложенных мною объединены в одну. Нет работ по составлению ТЗ или ТП, т.е. функциональные требования каким-то образом превратились в доработки, что приведет к отсутсвующей документации и подсаживанию клиента на одного подрядчика, а также к итерационным доработкам вида: "...а пусть вот эта кнопочка будет синей и в левом верхнем углу...".

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

Обычно работы по внедрению релиза 2 и дальнейших повторяют работы по внедрению первого релиза...

это не релиз 2
фактически это "доводка" релиза 1

lessonslearned

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

пользователи УЖЕ работают с системой несколько недель.

lessonslearned

На мой взгляд, здесь описаны обычные процессы поддержки...

нет
внедряется функционал, ради которого и затевался проект внедрения.

lessonslearned

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

см предыдущий пост

lessonslearned

Не зависит от методики. По прошествии времени после внедрения сотрудники при любом подходе будут разбираться в системе лучше, чем в начале проекта.

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

От s_ustinov:
 
Алексей, не надо концентрироваться на пунктах, которые совпадают - очень многое и должно совпадать.
если вы думаете, что я не знаком с описанной вами методикой - это не так.
у меня где то в архивах есть презентация, которую мы показывали на пресейле навижина, в том числе описывали нашу "самую правильную" методику внедрения;-))) презентацию готовил не я (откуда взяли методику точно не знаю), но названия этапов и краткие описания совпадают практически полностью :-)))
вы случайно заготовку не с MBS потянули? ;-)))

если мы внедряем стандартный функционал заказчику, потребности которого совпадают с потребностями предыдущих наших клиентов - составлять ТЗ не требуется, и это только зря потраченные деньги (почитайте о внедрениях 1С Бухгалтерии), если же нам надо что-то дорабатывать, особенно если ни клиент таких задач не выполнял, ни мы - необходимо ОЧЕНЬ качественное ТЗ, которое крайне сложно получить.

Вот цитата из Мифического человеко месяца Брукса (16 глава)
"Уточнение требований и быстрое макетирование. Самая трудная отдельная задача в разработке программной системы - это точно решить, что разрабатывать. Ни одна другая задача работы над концепциями не является столь трудной, как разработка подробных технических требований, включая все интерфейсы пользователей, машинные интерфейсы и интерфейсы к другим программным системам. Ни одна другая часть работы не наносит такого ущерба готовой системе, если сделана неправильно. Ни одна другая часть не исправляется позднее с бoльшим трудом.
Поэтому наиболее важной функцией, осуществляемой разработчиками для своих клиентов, является повторяющееся получение и уточнение требований к продукту. Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации. Даже простой ответ - "сделайте так, чтобы новая программная система работала так, как наша старая ручная система обработки информации" - оказывается в действительности слишком упрощенным. Клиенты никогда не хотят этого в точности. Более того, сложные программные системы действуют, движутся, работают. Динамику этого действия трудно себе представить. Поэтому при планировании любых действий необходимо оставить резерв для многократного взаимодействия между клиентом и проектировщиком при описании системы.
Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют.
...
Сегодня многие процедуры приобретения программного обеспечения основываются на предположении, что можно заранее задать технические требования для желаемой системы, рассмотреть предложения разработчиков, получить разработанную систему и установить ее. Я думаю, что такое предположение в корне неверно, и из-за этой ошибки проистекают многие проблемы при приобретении программ, поскольку эти проблемы нельзя устранить без пересмотра основ, для которого требуется интерактивная разработка и спецификации макетов и продуктов."

Написано очень давно, но до сих пор справедливо на 100%. в 20 главе можно почитать о водопаде:
"Не разрабатывайте программ на выброс, каскадная модель неверна!
В главе 11 дается радикальный совет: "планируйте выбросить первую программу, вам все равно придется это сделать". Сейчас я считаю это ошибочным - не в силу чрезмерного радикализма, но в силу чрезмерной упрощенности.
Самой большой ошибкой этой концепции является косвенное принятие классической последовательности - в виде каскада - модели создания программы.
...
Глава 11 - не единственная, на которую повлияла каскадная модель. Она проходит через всю книгу, начиная с правила планирования в главе 2. Это практическое правило отводит 1/3 времени на планирование, 1/6 - на написание программ, 1/4 - на тестирование компонентов и 1/4 - на системное тестирование.
...
Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы.
"Планируйте на выброс" действительно резко нападает на это заблуждение. Ошибка не в диагнозе, а в лекарстве. Сейчас я предположил, что первую систему можно отбросить или перепроектировать не всю целиком, а по частям. Хорошо, если это так, но при этом не затрагивается корень проблемы. В каскадной модели системное тестирование, а следовательно и тестирование пользователем, отодвигается в конец процесса создания программы. Поэтому есть шанс обнаружить крайние неудобства для пользователя, или неприемлемые технические характеристики, или опасную уязвимость к ошибкам или злонамеренным действиям пользователя лишь в самом конце разработки. Изучение спецификаций при альфа-тестировании нацелено на раннее обнаружение таких ошибок, но ничто не может заменить непосредственных пользователей.
Вторым недостатком каскадной модели является предположение, что система строится сразу вся целиком для тестирования с начала до конца после того, как завершены все проектные разработки, большая часть написания программ и значительная часть тестирования компонентов."
(выделения мои)

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

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

Сергей, согласен, отклонился от темы выискивая вашу неправоту и свою правду :) Прошу прощения.
Да, заготовка методики - микс из Sure Step (методология внедрения MBS), AIM (Oracle, понравился нахлест этапов, повторное использование артефактов проекта) и собственного опыта, который получен в том числе при работе с крупными компаниями имеющими свою методологию внедрения.

По поводу внедрения 1С - к сожалению, не нашел их методологии внедрения, хотя получал ссылки.
По части Брукса у нас есть одно различие, вы считаете что водопад не подходит для разработки и внедрения, а я что только для разработки, несмотря на то, что частично проблемы разработки присутствуют и на проектах внедрения, т.к. при внедрении (особенно небольших систем) этап разработки, на мой взгляд не будет самым критическим.
Если вам нужны ответы на вопросы из топиков выше (с цитатами) готов ответить, просто опасаюсь, что мы совсем уйдем от цели топика (разработка методики)... Напишите, нужен ли ответ.
По части авторитета Брукса не спорю :)
Попробуем вернуться к теме обсуждения, т.к. целью топика было все-таки постараться выработать некую методику, а не отстоять свою точку зрения или доказать в каких проектах я участвовал :).

Как я понял, основной критикой является:
1. Использование водопа не является эффективным подходом для внедрения малых систем
В связи с чем возникает вопрос какая именно методика подходит за основу? Я брал за основу Sure Step, что предложете вы (помимо собственной)?
2. Я так понимаю, что этапов предполагается только 4+поддержка
Диагностика
Внедрение функционала, необходимого для выполнения повседневных операций и запуск системы в эксплуатацию
Внедрение прочего обязательного функционала и часть желательного функционала (повышающего удобство работы / производительность труда)
Внедрение прочего функционала, входящего в проект
Особняком, Поддержка и дальнейшее усовершенствование системы
3.Основная проблема - конечный пользователь не видит системы на ранней стадии и, соответственно, не может корректно сформулировать свои потребности -> упущенные требования и кривости в системе

Продолжите список критики с вариантами решений?

теперь уже точно переношу на форум. Сейчас приходится писать на три форума, планирую подключить к обсуждению 1С-ников, специалистов по сайтам и т.д. Тогда нереально будет писать во все форумы отдельно...

От s_ustinov:
 
lessonslearned

Как я понял, основной критикой является:
1. Использование водопа не является эффективным подходом для внедрения малых систем
В связи с чем возникает вопрос какая именно методика подходит за основу? Я брал за основу Sure Step, что предложете вы (помимо собственной)?

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

lessonslearned

2. Я так понимаю, что этапов предполагается только 4+поддержка
Диагностика
Внедрение функционала, необходимого для выполнения повседневных операций и запуск системы в эксплуатацию
Внедрение прочего обязательного функционала и часть желательного функционала (повышающего удобство работы / производительность труда)
Внедрение прочего функционала, входящего в проект
Особняком, Поддержка и дальнейшее усовершенствование системы

 
да, все правильно
 

lessonslearned

3.Основная проблема - конечный пользователь не видит системы на ранней стадии и, соответственно, не может корректно сформулировать свои потребности -> упущенные требования и кривости в системе

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

lessonslearned

Продолжите список критики с вариантами решений?

 
некорректные ТЗ - это основной косяк. возможно, есть и другие, но их не видно за основным :-)))

От s_ustinov:
 
lessonslearned

Сейчас приходится писать на три форума, планирую подключить к обсуждению 1С-ников, специалистов по сайтам и т.д. Тогда нереально будет писать во все форумы отдельно...

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

От s_ustinov:

s_ustinov

lessonslearned

3.Основная проблема - конечный пользователь не видит системы на ранней стадии и, соответственно, не может корректно сформулировать свои потребности -> упущенные требования и кривости в системе

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

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

сложность приводит к проблемам с ТЗ, проектированием системы (как все вместе будет работать, причем не только система, но и пользователи), выполнением доработок, обучением пользователей.

если добавляешь по одной функции за раз, таких проблем нет.

От Dmitry V. Liseev:
 
Нету тут никаких методик. Ни планов, ни проектов, ни сроков, ни кучи многостраничных документов. Я просто беру и внедряю. В одиночку. Портал внедрили, crm внедряем, потом полномасштабный erp будет.