lessonslearned,

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

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

и еще очень важно как можно раньше получить некий работающий продукт, в котором реализованы пусть даже не все функции
для качественной проработки требований почти всегда не хватает ресурсов - лучше все требования собирать в процессе эксплуатации.
Например, внедряем учетную систему.
Ясно, что кардинально ее переделывать никто не будет - не хватит денег. То есть практически с самого начала можно достаточно подробно прописать, кто, с какими модулями и объектами и как работает (то есть написать черновик документа№1) И протестировать в первом приближении - на это уйдет до недели.
Естественно, при этом выявится МНОГО абсолютно необходимых вещей, без которых работать НИКАК НЕЛЬЗЯ )))
каждая из хотелок внимательно анализируется - никак нельзя вообще в будущем или вот прямо сейчас действительно никак нельзя обойтись без такой доработки. 90% хотелок можно оставить на потом - как-то работать можно и без них, а 10% действительно нужны сразу. делаем эти доработки (создавая документ №2) и запускаем систему - и начинаем новые итерации - реализуем все прочие хотелки. Для достижения всех целей проекта потребуется скорее всего не менее 10-20 дополнительных циклов по "доделке", но управляемость проекта вырастет на порядок.

По моему мнению итерационность для мелких проектов НАМНОГО важнее, чем для больших. И крайне важно сделать цикл как можно короче. Если первый работающий прототип не получится через 2-4 месяца - проект скорее всего будет сорван.
А так как в идеале длительность первого цикла не больше 1,5 - 2,5 месяцев (остальные циклы улучшений - не более 2 недель), то и все этапы надо продумывать исходя из этого.

s_ustinovменеджеров, которые ими управляют, скорее всего не больше 3-5.


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

lessonslearned
Т.о. проект, выполняемый итерационно в плане пересмотра его объема рискует не быть завершенным, т.к. требования будут меняться на каждой итерации.

Почему вдруг вы так решили? Где вы увидели связь между итерационным подходом к разработке и пересмотром объема проекта?

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


А в чем вы измеряете объем проекта? :-))))))))))))) А в чем измеряет заказчик? :-))))
Особенно интересно услышать применительно к "фиксируют объем проекта на начальных стадиях" ;-)))))


lessonslearned
По поводу фокуса на реализации бизнес процессов в системе и изменениях в системе - согласен, фокус на них должен быть. Только, скажите, вы говорите про use case и функциональном дизайне или о чем-то другом?

Не совсем. Что представляет ценность для заказчика? Сама система + описание как с ней работать пользователям +
описание, как работать специалистам поддержки (какие изменения и настройки были сделаны). ВСЕ остальные документы по проекту предназначены для использования командой внедрения в процессе внедрения и заказчик за них платить не будет (они не представляют для него никакой ценности). На малых проектах согласование действий команды внедрения не представляет такой проблемы, как на больших, плюс ОЧЕНЬ ограничены ресурсы - следовательно, можно и нужно использовать два документа, нужных заказчику, и для нужд команды внедрения.

lessonslearned
По поводу тестирования, за неделю какой вид тестирования вы предполагаете? Я полагал, что все-таки необходимо писать тестовые сценарии, которые затем прогонять. Хорошие тестовые сценарии даже для малой системы мне кажется очень сложно написать и прогнать за неделю.

я писал не о тестировании. это черновой вариант анализа + проектирования + частично разработки.
а что касается тестирования... "Хорошие тестовые сценарии" при "бюджет проекта до 1 млн. руб." (то есть до 35'000 долларов) - что именно понимается под написанием и прогонкой тестовых сценариев?

lessonslearned
И еще, какие конкретные действия (изменения) вы предлагаете внести в методику?

Алексей, у меня встречное предложение - попробуйте описать 2-3 примера проекта "внедрения ИТ систем на малых предприятиях". Описать очень грубо, каждый пример - 2-3 абзаца - что внедряем, тип компании, срок, бюджет, этапы и задействованные на каждом этапе ресурсы (люди). При этом учитывая вами же установленные ограничения по срокам и ОСОБЕННО по бюджету (кстати, я так и не понял - в бюджет стоимость лицензий и железа входит или нет?). И вы не ошиблись с бюджетом - может речь шла о бюджете до 100 - 150 тысяч долларов? После этого мы сможем обсуждать более предметно - сейчас идет описание "сферического коня в вакууме" :-)))
lessonslearned
И еще, могу я продублировать ваш пост к себе в форум, т.к. планировал обсуждение вести там (хотелось бы услышать мнение не только членов сообщества sql.ru, но и других)?

Без проблем - дублируйте :-)))

lessonslearned
Связи между итерационным подходом к разработке и пересмотром объема проекта нет. Если имеется ввиду итерационная разработка, то значит я не правильно понял. Я думал итерации касаются и определения требований, а не только разработки. Пример (прошу не судить строго, сайтами не занимался. Пример привожу такой, т.к. не представляю как что-то крупное внедрять итерационно):
1 июня принято решение запуска сайта для продаж через интернет. Бюджет - 600 000р. Срок - 6 мес. У заказчика выбран ПМ, разработка сайта передана на подрядчика. Запуск продаж назначен на 1 декабря, чтобы успеть под НГ.
1 июля сформированы требования из 50 фич для реализации
1 августа реализованы 11 и добавлены 14
1 сентября реализованы 14 и добавлено 5
1 октября реализовано 10
1 ноября реализовано 18 и добавлены 15
1 декабря реализовано еще 10.
Сайт не доделан, а срок наступил...

1 июля подписан контракт, в котором определен объем работ - 50 фич, стоимость совокупная и сроки. 1 августа ПМ подходит к руководителю проекта со стороны заказчика и говорит - появились требования на 14 новых фич - есть три варианта - не делаем новые (стоимость и сроки не меняются); делаем все новые и старые (меняем стоимость и сроки); делаем часть новых и часть старых (стоимость и сроки меняются или не меняются) - и заказчик выбирает, что ему нужно.
так как в момент подписания контракта у заказчика не было очень точного понимания того, что ему нужно, такой вариант намного продуктивнее. а вот если сделать все 50 изначальных, но не сделать что-то, что упустили на начальном этапе, но без чего сайт не нужен (не заработает) - это провал проекта
а водопад именно этим и страшен. очень часто пользователи просто забывают о чем то упомянуть (для них это или мелочь, или само собой разумеется). и пока не начинают работать с системой, это что-то не всплывает
а когда начинают работать - нет уже ни времени, ни ресурсов, и поменять ничего нельзя - и или превышение бюджета и сроков, или вообще провал проекта

lessonslearnedОбъем проекта - ну, например, в человекоднях :) Имею ввиду разновидность Fixed price контрактов. Обычно в них работы фиксированы.
Что, вот так приходили к заказчику, а он и говорил - мне надо 15367 человеко/дня? ;-))))
И если вы потратили 15367 человеко/дня, то проект успешный? ;-))))) хотя, если вам за них заплатили - то конечно успешный... :-))) правда, не думаю, что заказчик с такой трактовкой согласится... ;-)))
но главное - точность расчета объема проекта... пришли, НЕДЕЛЮ расспрашивали ключевых пользователей (на микропроектах МАКСИМУМ пара дней - иначе фирма в трубу вылетит - слишком большие затраты на заключение сделки, а проекты то маленькие) - подписали договор - и когда начали настраивать амортизацию по производственному методу - выяснилось, что ее надо считать ОЧЕНЬ извращенным способом (но для этого предприятия именно такой способ и есть самый правильный) - в системе есть производственный метод, но именно такого - нет - и выливается все в доработку на три - четыре недели... неужели у вас в практике ничего такого не было, и вы умудрились ХОТЯ БЫ НА ОДНОМ проекте в самом начале посчитать точно объем? без использования принципа "и еще 30% запаса"? :-)))
если вы можете в самом начале ТОЧНО рассчитать объем проекта - вам не проджектом и тем более не на мелких проектах надо работать ;-)))))))))))
и это когда проект рассчитан на тысячи человеко/дней, ошибка на 50-60 человеко/дня укладывается в погрешность и ее легко "распределить"... :-))))))))) некоторые, правда, такие фокусы подтасовкой называют... :-)))))))))
а на мелком 50 человеко/дней - это 10% бюджета...

lessonslearned
Про тестирование. Ну, применительно опять же к выбранному примеру. Поскольку на сайте выполняются некие действия, заполняются некие формы, жмутся кнопки и ожидаются результаты, то можно написать следующие сценарии (ручные). Входные данные (значения каждого поля), действия пользователя (нажатие каждой кнопки. Один шаг в сценарии - одно действие). Ожидаемый результат и фактический результат. Можно добавить пункт Тест пройден/Не пройден.
я знаю, что такое тестирование. вопрос был немного про другое - откуда мы на ХОРОШЕЕ тестирование ресурсы возьмем на мелком проекте? я уверен, что МНОГО проектов внедрения УПП укладываются в рамки до 1 млн. руб.
И как на таком проекте КАЧЕСТВЕННО протестировать тот же расчет себестоимости? даже сайт (а он НАМНОГО проще) качественно протестировать - это довольно затратная процедура.

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

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

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


У заказчика есть понимание. Вы пришли к нему, а он вам говорит - у меня сейчас две большие головные боли:
1. бухгалтерия постоянно ноет, что они ничего не успевают, что работают как лошади, сводят баланс по выходным и т.п. - я хочу, чтобы они прекратили ныть, и чтобы при этом все отчеты для налоговой готовились правильно и вовремя
2. у нас неконтролируемо растет дебиторка. а когда я начинаю наезжать на начальника отдела продаж - он говорит, что не может проконтролировать все - я хочу, чтобы у нас был механизм, позволяющий контролировать рост общей суммы дебиторской задолженности, и если она опять начнет расти, то я мог бы с чистой совестью уволить начальника отдела продаж, полностью уверенный что это он накосячил

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

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

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

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


lessonslearned
По поводу погрешностей, может я не прав, но разве меньшие по размерам проекты не проще просчитать с более высокой точностью, чем крупные проекты? Соответственно, на малых проектах, по-идее, и ошибки в 50 чел./дн. быть не должно...
нет. у маленьких часто те же проблемы, что и у больших. только денег меньше :-))))

lessonslearned
Насчет того, что тестирование затратная процедура я не спорю. Но выхода-то нет. От него никуда не деться. И, думаю agile тут не поможет... Я имею ввиду сквозное тестирование всех процессов. Если я не ошибаюсь в agile, в конце каждой итерации должен быть готовый продукт, так вот, что не понятно, ведь готовый продукт подразумевает успешное прохождение тестирования. А если мы на следующей стадии реализуем какую-то фичу и она поломает что-то из того, что до сих пор работало? Если мы проводим в конце каждой итерации регрессивное тестирование, мы конечно, об этом узнаем и поправим, но это очень затратно получается. А если не проводим, то получается узнаем только в производственной эксплуатации. Или я не так понимаю?

возможно, я не точно выразился
по моему мнению, после первой (максимум второй) итерации ВВОДИМ В ЭКСПЛУАТАЦИЮ. не тестовую, а нормальную.
да, большая часть требований еще не выполнена
да, работа некоторых сотрудников становится более трудоемкой (нет необходимого им функционала)
да, возможны ошибки, которые мы не выявили, так как не проводили качественное тестирование и по умолчанию считаем, что в стандартном функционале нет ошибок (нет у нас ресурсов на кроликах экспериментировать - поэтому придется людям побыть кроликами))))...

НО так у проекта больше шансов быть успешным

lessonslearned

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

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

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

lessonslearned
Ладно, мы ушли в споры, имеющие, по-моему опосредованное отношение к теме. Хорошо, допустим я не прав с водопадом, тогда как оно должно быть? Какие стадие (если есть)? Вы же понимаете, что внедрение по типу "сейчас начнем делать что-нибудь, а там разберемся..." ни к чему хорошему не приведет. Как вы считаете должно выглядеть внедрение систем на малых предприятиях (сайты, 1С...)?


опишите примеры - без этого разговор ни о чем
заодно и мои слова о ресурсах поймете
в качестве одного из примеров возьмите внедрение той же УПП на 10 пользователей - вполне укладывается в ограничения )))
и кстати, написать одну методику для сайта и для той же упп не получится - сложность систем сильно разная, а в таких случаях "размер имеет значение" ;-)))

LSVТема методологий внедрения излишне раздута, ИМХО.
Тонны макулатуры тыщи хтмл/пдф-страниц вещают о методологиях внедрения. Полжизни надо, чтоб их перечитать.

Мне кажется, что всю информацию о типичных МВ можно уложить в 20-50стр. Не более.
Но этого никто не делает. Потому что из этого выгодно делать целую отрасль с дорогими курсами/сертификациями/книгами/семинарами/маркетингом и пр.
Думаю, дело в другом. всем хочется получить некие "волшебные" правила - делай так, и каким бы идиотом ты не был, все будет хорошо - действуя по алгоритму, внедрение пройдет успешно... :-)))
а "серебряную пулю" найти никак не удается...
вот все и переживают - как же так, ну ведь должна же быть некая универсальная методология, которая всем поможет... :-)))
и пишут, пишут, пишут...

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

lessonslearned

Как я понял, требуются примеры внедрений, на которые рассчитывается методика. Ок.

Примеры следующие:


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

Например, внедрение сайта:
Насколько я понимаю, в стандартном функционале нет расчета стоимости и сервис деска.
0. обсуждение целей и границ проекта, общее видение, кто именно из сотрудников заказчика и чем будет заниматься в проекте, подписание договора.
1 Установка системы на сервер. Доступ к системе только сотрудникам. - выполняет один администратор и один специалист по CMS в течении 2-8 дней. при этом настраивается форум и раздача файлов (должно быть в стандартном функционале). при этом с заказчиком обговаривается и сразу же настраивается структура сайта, если в чем то нет уверенности - используем "типовые" решения
2. Первоначальное наполнение сайта контентом и обучение сотрудников, которые будут с ним работать - в процессе наполнения контента. 3-4 недели. один специалист по CMS занят первую неделю 100%, остальное время 50%
3. Разработка функционала сервис деска - один специалист (разработчик) по CMS в течении 3 недель (тут сложно оценить трудозатраты - смотря какие требования и смотря какая система, возможно можно будет взять готовое и слегка настроить) - пункт 3 ведется параллельно пункту 2.
4. сотрудникам фирмы - заказчика дается задание - в течении 2 часов полазить по сайту и попытаться найти ляпы (больше времени тратить смысла нет - не будут все равно внимательно всматриваться) по результатам тестирования устраняются ляпы - 1-2 дня
5. запуск сайта - чистим от тестовых записей в сервис деске, открываем доступ всем, регистрируем в поисковиках (если надо) - 0,5 рабочего дня администратора
итак, через 1 - 1,5 месяца сайт стартовал, но без функции расчета стоимости
завершен первый этап
если к этому моменту сервис деск не доработан - стартуем без него

6. разрабатываем функционал расчета стоимости - 1 месяц - работает один специалист (разработчик) по CMS
7. те, кто и определяют стоимость (сотрудники заказчика), тестируют готовое решение - 4 часа
8. исправление найденных ошибок 4 дня
9. запуск расчета стоимости - 0,5 дня админа
10. техподдержка пользователей CMS в течении месяца с момента запуска (5) - один спец по CMS (загрузка 10% в день - они ведь уже прошли обучение)
итого через 2 - 2,5 месяца имеем работающую систему со всеми нужными функциями, которая уже проработала 1 месяц
завершен второй этап и проект
скорее всего останутся нерешенными ряд "хотелок" заказчика - например, есть пожелания по улучшению дизайна, функциональности системы и т.п. все это оставляем на потом

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

стоимость надо просчитать отдельно

к сожалению, в CMS системах я разбираюсь очень слабо, и могу ошибится с оценкой трудоемкости, но не думаю что ошибка будет в несколько порядков

примерно так
но это мое видение проекта, и как я думаю, достаточно хорошо вписывается в ограничения по срокам и бюджету

и оно сильно не совпадает с предложенной вами методологией
опишите ваше видение проекта по каждому из примеров - и тогда можно обсуждать методологию

lessonslearned
Где-то так... Что скажете?
Не верю :-)))

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

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

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

а давайте обсудим второй пример - с фермерами.
он мне кажется как раз намного более "жестким" по срокам и бюджету.
вот только одно уточнение - планирование ДДС - каким оно должно быть?
я частично пересекался с "фермерами" - там действительно спланировать деньги без разрывов большая проблема. и цены на то же ГСМ (а это одна из наиболее существенных статей затрат) меняются достаточно быстро.
то есть вопрос вот в чем - как мне кажется, заказчику может хотеться получить следующее - я указываю, сколько солярки, удобрений, семян и т.п. и когда мне надо (и желательно с возможностью задавать диапазон по объемам и срокам), сколько и когда я смогу продать пшеницы, гречки, кукурузы и прочего сена, какие на это все цены, какие сроки платежей, какие еще мне работы надо заказать (например нанять самолетик опрыскать вредителей отравой), сколько у меня и каких относительно постоянных расходов (зарплата, аренда и т.п.) - и система мне рисует график с указанием всех разрывов. и чтобы в любой момент можно было указать другую цену или объем или добавить новый вид расходов - и все автоматом пересчиталось. также хорошо бы иметь возможность сравнивать план ДДС с фактом - за счет чего у нас не идет и на сколько - и заодно постоянно уточнять модель.
То есть основная проблема с деньгами у фермеров - возникновение доходов и расходов сильно разнесено во времени и суммы зависят от очень большого числа факторов - очень нестабильны - постоянно меняются необходимые объемы удобрений, цены на продукцию и ГСМ, планируемый объем и сроки урожая и т.п.
и планировать, указывая СУММЫ не получится - цена на горючее меняется на 20% (а это очень частое явление) - и все надо пересчитывать, что вручную крайне трудоемко и никто этого делать не будет.
ВСЕ ЭТО планируется внедрить за 350 тысяч (включая лицензии) и за 2,5 месяца? или это есть во внедряемом продукте? фраза - "позволяющая автоматизировать учет и отчетность" наводит на мысль, что ничего подобного для целей планирования там и близко нет :-)))
или же я неправ, и под планированием ДДС в этом проекте подразумевается нечто другое?

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

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

lessonslearned
Далее, этапы:
Поскольку система, как и предприятие типовое, то этапы Диагностики и Анализа не займут много времени.
1, 2. Диагностика и Анализ совмещаются в один этап. Договор на внедрение коробочного решения, отдельный договор на доработки. То, что договоры разделены, позволяет распараллелить работы, т.е. вести внедрение коробочного решения (3 недели, включает в себя, подписание договора на внедрение коробки, анализ и документирование необходимых первичных настроек (какие именно настройки необходимы – известно, т.к. решение типовое), проведение установки и настройки систем) и анализа доработок (выявление требований к планированию. Бухучет и отчетность – стандартные. Подписание второго договора на доработки.) 4 недели. Покупки дополнительного железа не требуется, т.к. мощности существующих ПК вполне достаточно. Т.о. общая длительность этапов – 4 недели.
3. Проектирование – т.к. доработки невелики, то пишется только техническое задание 2 недели (помним, что требования уже выяснены, нужно только формализовать для программиста).
4. Разработка – 2 недели абстрактной разработки по ТЗ (т.е. ТЗ + Реализация = 4 недель).
5. Развертывание – перенос системы на машины заказчика + приемочное тестирование. Т.к. решение типовое, то сценарии для базового функционала уже готовы. Нужно написать сценарии только для доработок 2 недели на все.
6. Завершение – 3 дня на архивацию результатов.

То есть клиент начинает вести бухучет через 3 недели или через 2,5 месяца? Немного непонятно написано...

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

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

lessonslearned
Бардак со справочниками решается за счет стандартного внедрения. Вы внедряете коробку, поэтому уже заранее знаете что именно вам нужно настроить. Вам нужны только значения настроек и справочников.
я именно про значения и говорил :-)))))))))
если там учет велся в екселе, да еще то сами, то привлеченный бухгалтер...
минимум неделя на справочники.
и еще один нюанс - на мелких внедрениях процедурой составления справочников и получением остатков руководят внедренцы (по крайней мере на успешных проектах)))), а достаточно часто приходится вообще самим часть делать...
lessonslearned
s_ustinov
в приведенном плане очень вероятен результат, когда заказчик получит работоспособную систему, которую он не сможет использовать или которая не будет решать его потребности - а это провал проекта.
необходимо заложить минимум 2 недели на проработку структуры статей ДДС.

Согласен, что не простой вопрос. На старте для выявления требований выделено 4 недели. Провала нет. :)

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


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

кстати, это очень хороший пример того, как можно сильно ошибиться на самом раннем этапе с объемом работ
и если реализовывать так, как ты описал - вылезет все уже в самом конце
описываешь заказчику, вот мол так и так - он, не разбираясь глубоко в предмете, кивает - ага, ага (подразумевая, что звучит красиво и вроде примерно такое ему и надо)
и вот все сделано, разработчики протестировали функционал, начали показывать все заказчику - пробуют составить приблизительный план
говорят - а вот здесь укажите, сколько вы денег на солярку потратите по месяцам...
а фермер в непонятке - а откуда я знаю - там все от погоды зависит (когда посевная, когда уборочная), да и цены меняются... ну хоть примерно - ну тонны 5 на посевную...
а в деньгах?...
в результате заказчик понимает, что система не может ни диапазоны нормально обрабатывать (от 3 до 4 тонн), ни автоматически пересчитывать суммы, когда ей указываешь изменение цен, ни нормально сроки сдвигать - посевная, уборочная и т.п. - сильно зависят от погоды, и сдвигаются плюс-минус неделя-две (соответственно, и все платежи сдвигаются)
в результате заказчик заявляет - че вы мне фигню пытаетесь подсунуть? такое, что вы мне предлагаете, я и сам в екселе могу, а ексель у меня уже на компе стоит.. и не буду я вам за все это платить - мы как договаривались - что вы сделаете что-то, что поможет мне реально планировать ДДС, а эта фигня мне в этом не помогает - следовательно, денег вы не получите.

я примерно про такие ситуации и говорил, что на мелких проектах ошибки бывают ОЧЕНЬ значительные

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

seiderlessonslearned, я конечно понимаю что сложно реализовать систему для микро предприятия, но я считаю, что нужно ёё сначала спроектировать в каком либо Case-средстве(программе) наподобие Rational Rose 2000 Enterprize Edition и/или Erwin, а потом непосредственно приступать к созданию
отчётных документов и программированию.
Речь идет не о создании, а о внедрении уже СУЩЕСТВУЮЩЕЙ системы. То есть доработки возможны, но не обязательны и даже не очень желательны.

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

Август.

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

Сентябрь.


Проведение ревизии склада (инвентаризация) – четкое определение остатков, выставление долгов по поставщикам, покупателям и прочим клиентам.


Я правильно понимаю, что частично работа начинается в первый же месяц, а полноценная работа через 2 месяца?

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


lessonslearned
s_ustinov
и опять же, если говорить именно о фермерах, "классический" вариант реально не заработает - то есть можно будет добиться того, что какие-то цифры куда то заносятся, но практическое планирование выполнить будет практически невозможно


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

объем внедряемого функционала
когда внедряется "все и сразу", намного легче пропустить косяк такого рода
с утверждением "не заработает при обоих подходах" я согласен

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


lessonslearnedНапишите, какой подход у фермеров к планированию ДДС сработает и, думаю мы увидем, что противоречия с методикой внедрения данного подхода к планированию ДДС не будет :)
в рамках ограничений примера проекта внедрения (сроки, бюджет) данную задачу (планирование ДДС) решить скорее всего нельзя


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

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

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

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

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


И как этого избежать (ошибок с оценкой трудоемкости и нехватки опыта)?

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

Андрей Ж.Я правильно понимаю, что частично работа начинается в первый же месяц, а полноценная работа через 2 месяца?

Всё сильно зависит от конкретного объекта автоматизации! В приведённом случаю со срока "перестраховался" - реально было быстрее...

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

несколько общих замечаний

Проблемы водопада
главные проблемы - нет механизма управления сложностью проекта и НЕРЕАЛЬНО высокие требования к качеству ТЗ.
внедрения сайта - относительно простая задача. внедрение бухучета - уже задача значительно сложнее. а внедрение бухучета, продаж и закупок, склада, производства, планирования денег и продаж и изощренного ценообразование с кучей скидок - это уже ОЧЕНЬ сложная задача. на практике, когда я слышал о внедрении большого количества модулей, ВСЕГДА проект был или неудачный, или со срывом сроков и превышением бюджета (речь идет и о больших и о малых предприятиях). возможно, я не о всём слышал, и есть где то примеры успешных внедрений, когда успешно сразу внедрялось всё... буду рад услышать ссылку на такой пример.


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

Но несмотря на эти недостатки, итеративный метод дает более предсказуемый результат и меньше проблем при такой методике.

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

также при итеративной методике на обучение пользователей отводится на ПОРЯДОК больше времени, и обучаются они по более "правильному" с точки зрения психологии способу - сперва относительно простые вещи, которые делаешь постоянно, потом более редкие и сложные, которые требуют более глубокого понимания работы системы. а в водопаде учат сразу всему, и у пользователей чаще происходит отторжение системы.

кусок, еще не все дописал, но уже можно смотреть

Методология внедрения
Этапы проекта.
Диагностика

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

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

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

* Составляется таблица наличия возможностей по внедрению каждого из требований. Существует 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 (есть высокая вероятность того, что данное требование вообще не получится выполнить).

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

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

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


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

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

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