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 пользователей - вполне укладывается в ограничения )))
и кстати, написать одну методику для сайта и для той же упп не получится - сложность систем сильно разная, а в таких случаях "размер имеет значение" ;-)))