От s_ustinov:

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

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

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

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

От s_ustinov

s_ustinov

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

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

От lessonslearned:
 
Добрый день! Да, я согласен по поводу того, что взята просто упрощенная методология внедрения, используемая на крупных проектах. Теперь о причинах, почему так, а не иначе. Честно говоря, я не очень понимаю Agile (не являюсь специалистом в гибких методологиях) в плане того, как она подходит для управления проектами. Именно проектами, а не продуктами. Проект - действие ограниченное во времени. В конце проекта мы должны получить некий результат, которым будем пользоваться. Как правило, продукт проекта ожидается к какой-то дате, т.е. присутствует deadline и нельзя сказать, что продукт будет "когда закончим работу". Итерационный подход, в Agile, подразумевает повторяющиеся итерации предназначенные для формализации новых требований. Т.о. проект, выполняемый итерационно в плане пересмотра его объема рискует не быть завершенным, т.к. требования будут меняться на каждой итерации. Зато это очень хорошо подходит для поддержки продукта, когда он постоянно совершенствуется и команда разработчиков постоянно имеет план работ (на текущую итерацию).
Собственно, проекты выполняемые по традиционной методологии водопада фиксируют объем проекта на начальных стадиях и впоследствии, довольно трудно изменить этот объем. Поэтому для проектов, где важны сроки, как мне кажется, наиболее подходит именно водопад.

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

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

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

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

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

И еще, могу я продублировать ваш пост к себе в форум, т.к. планировал обсуждение вести там (хотелось бы услышать мнение не только членов сообщества sql.ru, но и других)?

С уважением,
Алексей

От

alexeyvg:

lessonslearned

Честно говоря, я не очень понимаю Agile (не являюсь специалистом в гибких методологиях) в плане того, как она подходит для управления проектами.

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

А идея Agile простая.

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

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

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

Так что тоже кажется, что методики должны всё таки отличаться существеннее, чем некоторые несужественные оговорки в описании.

От lessonslearned:
Ну, насчет подтасовки вы загнули. По крайней мере ни один вменяемый ПМ не станет подтасовывать что-то серьезное, тем более на крупных проектах. Голову снимут (говорю только об ИТ, в других сферах не знаю). Гораздо проще упереться и контролировать проект не допуская сильных отклонений и разрешая проблемы через руководство.

И, по повод оценки "от балды". Да, такая оценка бывает, но на крупные проекты обычно нанимают консультантов. И плюсы от них значительные. Приведу пример. Вы внедряете какую либо систему. Сложно оценить сроки? Сложно. Но ведь как правило, кто-то ее уже внедрял и имеет опыт. Чем крупнее компания, тем больше у нее опыта. Как результат - достаточно точная оценка. Исключение - первое внедрение, но на первом внедрении как правило закладываются по срокам и снижают цены, т.ч. если в сроки не укладываются, небольшим утешением является низкая цена.

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

От Siemargl:
 

lessonslearned

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

Что то по опыту работы кажется, что что тут не так =)

А по СМБ мне кажется, что свой опыт большого проекта Вы пытаетесь неудачно привязать к малым - т.е. больше правды у s_ustinov.

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

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

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

От LSV:

Разговоры о методологиях внедрения на 80% пустая болтовня и "глубокая туфта" (с)

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

ЗЫ: "Давать не то что просят, а то что им нужно" (с)

От s_ustinov:
 

lessonslearned

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

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

lessonslearned

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

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

lessonslearned

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

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

lessonslearned

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

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

lessonslearned

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

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

lessonslearned

И еще, могу я продублировать ваш пост к себе в форум, т.к. планировал обсуждение вести там (хотелось бы услышать мнение не только членов сообщества sql.ru, но и других)?

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

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

Итак, начну отвечать.

To s_ustinov:

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

Объем проекта - ну, например, в человекоднях :) Имею ввиду разновидность Fixed price контрактов. Обычно в них работы фиксированы.

Насчет проектных документов - согласен, обычно, заказчику они не нужны. Хотя в процессе эксплуатации системы и для реализации будущих проектов они, обычно, пригождаются. Даже заказчику.

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

По поводу примеров - его сейчас рассматриваем :)

To alexeyvg:

Точно работал. Не все так плохо в России :) Не всегда и не все подтасовывается.

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

По поводу делают что успеют как-то диковато звучит... Надо обдумать...