От alexeyvg:
 

lessonslearned

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

Тут есть ещё один момент.

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

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

А ведь бюджет и сроки определяют срзау - детальное описание требований и проектирование - это большая и затратная часть проекта...

lessonslearned

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

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

От serg_s:
 

1С продвигает технологию внедрения ТБР - Технология быстрого результата, как раз подходит для внедрения мелкого и микро уровня

http://supremum.com.ua/supremum/supremum/Meropriytiy/Konferencii/Strateg...
Prezent/1C.pdfl

От lessonslearned:
 

Спасибо большое за ссылку. Постараюсь сегодня-завтра прочитать и ответить...

От s_ustinov:
 

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:
 
s_ustinov,

Скопировал отсюда.

Если в начале проекта у заказчика не было понимания, что ему нужно, то проект не пройдет стадию сбора функциональных требований и все.
Собственно, вы говорите, о том, что пользователи пока не потрогают систему могут что-то не вспомнить. В водопаде есть прототипы, хотя, конечно для малых предприятий это не потянуть...
Когда я говорил про человекочасы, то имел ввиду в чем измерять проект. Не успешность, а именно объем. Т.е. изменение состава или порядка работ автоматически влечет изменение объема проекта (человекочасов), т.к. вам нужно хотя бы проанализировать влияние изменений на проект.
Были, конечно, и ошибки (это я про ваш пример с амортизацией). И запас тоже закладывается (какой - не скажу :) ). Но, честно говоря, мы больше намучались с изменением требований, чем с их неполным выяснением. По поводу погрешностей, может я не прав, но разве меньшие по размерам проекты не проще просчитать с более высокой точностью, чем крупные проекты? Соответственно, на малых проектах, по-идее, и ошибки в 50 чел./дн. быть не должно...
Насчет того, что тестирование затратная процедура я не спорю. Но выхода-то нет. От него никуда не деться. И, думаю agile тут не поможет... Я имею ввиду сквозное тестирование всех процессов. Если я не ошибаюсь в agile, в конце каждой итерации должен быть готовый продукт, так вот, что не понятно, ведь готовый продукт подразумевает успешное прохождение тестирования. А если мы на следующей стадии реализуем какую-то фичу и она поломает что-то из того, что до сих пор работало? Если мы проводим в конце каждой итерации регрессивное тестирование, мы конечно, об этом узнаем и поправим, но это очень затратно получается. А если не проводим, то получается узнаем только в производственной эксплуатации. Или я не так понимаю?

От alexeyvg:
 

lessonslearned

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

По моему, это синонимы.

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

Поэтому-то и пишут в книгах, посвящённых требованиям - работа по изменению требований заканчивается при закрытии проекта.

А вообще, s_ustinov уже всё очень хорошо объяснил, аплодирую!

От lessonslearned:
 

s_ustinov,

Скопировал отсюда.

Если в начале проекта у заказчика не было понимания, что ему нужно, то проект не пройдет стадию сбора функциональных требований и все.
Собственно, вы говорите, о том, что пользователи пока не потрогают систему могут что-то не вспомнить. В водопаде есть прототипы, хотя, конечно для малых предприятий это не потянуть...
Когда я говорил про человекочасы, то имел ввиду в чем измерять проект. Не успешность, а именно объем. Т.е. изменение состава или порядка работ автоматически влечет изменение объема проекта (человекочасов), т.к. вам нужно хотя бы проанализировать влияние изменений на проект.
Были, конечно, и ошибки (это я про ваш пример с амортизацией). И запас тоже закладывается (какой - не скажу :) ). Но, честно говоря, мы больше намучались с изменением требований, чем с их неполным выяснением. По поводу погрешностей, может я не прав, но разве меньшие по размерам проекты не проще просчитать с более высокой точностью, чем крупные проекты? Соответственно, на малых проектах, по-идее, и ошибки в 50 чел./дн. быть не должно...
Насчет того, что тестирование затратная процедура я не спорю. Но выхода-то нет. От него никуда не деться. И, думаю agile тут не поможет... Я имею ввиду сквозное тестирование всех процессов. Если я не ошибаюсь в agile, в конце каждой итерации должен быть готовый продукт, так вот, что не понятно, ведь готовый продукт подразумевает успешное прохождение тестирования. А если мы на следующей стадии реализуем какую-то фичу и она поломает что-то из того, что до сих пор работало? Если мы проводим в конце каждой итерации регрессивное тестирование, мы конечно, об этом узнаем и поправим, но это очень затратно получается. А если не проводим, то получается узнаем только в производственной эксплуатации. Или я не так понимаю?

От LSV:
 

Ужас, сколько букв ! На 90% - хоть и умные, но пустые слова.... ни о чем.
Слоганы, красивые обороты, кони в вакууме.

А реалии жизни немного другие.
Тут как в тренерстве. Вроде все понятно и одинаково, но один может создать команду мирового класса, а другой только дворовую. :)
"Дьявол в деталях", неписанных правилах, нюансах и интуиции.
Книжек по методикам - пруд пруди. А качественных внедрений - кот наплакал. Почему ? Потому что книги подчас далеки от практики. Их писали техн. писатели. Иногда даже без реальной практики.

ЗЫ: немного утрирую. :)

От alexeyvg:
 

LSV

Ужас, сколько букв ! На 90% - хоть и умные, но пустые слова.... ни о чем.
Слоганы, красивые обороты, кони в вакууме.

Это как - не нужно обсуждать и планировать, как вести проект, всё равно всё это пустые слова?

Если человек ничего не читает и ни о чём не разговаривает, он не то что проект вести не сможет, он и читать и разговаривать не научится :-)

От s_ustinov:
 

lessonslearned

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

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

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

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

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

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

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

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

lessonslearned

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

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

lessonslearned

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

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

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