Коллеги! Прошу вашей помощи

hellfire · 22.10.2010

Коллеги! Прошу вашей помощи

собственно, то ли у меня уже крыша едет, то ли действительно клиент такой тяжёлый...

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

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

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

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

вот что с ним делать, а?

maxshevtsov · 22.10.2010

ржу не могу, афтор пиши исчо

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

. И скажи что подругому ты не работаешь и все

Kompot · 22.10.2010

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

dr_mousefly · 22.10.2010

hellfire сказав(ла):
собственно, то ли у меня уже крыша едет, то ли действительно клиент такой тяжёлый...

трудно сказать сразу, не зная клиента конкретно.
но за исследования и проектирование по понятным причинам никто платить не хочет. просто не надо их показывать в смете и все.

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

maxshevtsov · 22.10.2010

dr_mousefly сказав(ла):
трудно сказать сразу, не зная клиента конкретно.
но за исследования и проектирование по понятным причинам никто платить не хочет. просто не надо их показывать в смете и все.

пишите лучше "создание прототипа". желательно, чтобы прототип

Ы это как

, это время затраченое на создание спеки и утверждение с клиентом прятать или назвать созданием протатипа

Причем тут водопадный процес, обговорили (не бесплатно), обсудили фичлист

, запрограмели, потестили

все.

hellfire · 22.10.2010

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

вы повеселились? если можно, покиньте тему и не мешайте.

Kompot сказав(ла):
пусть клиент выделит менеджера с мозгами который будет вести в вами переговоры

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

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

какую альтернативу водопаду вы используете?

generatorglukoff · 22.10.2010

плюсую к прототипированию.
вроде и проектирование и какойто кот есть

dr_mousefly · 22.10.2010

maxshevtsov сказав(ла):
Ы это как , это время затраченое на создание спеки и утверждение с клиентом прятать или назвать созданием протатипа

с каких это пор "создание спеки" стало называться проектированием?

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

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

hellfire сказав(ла):
какую альтернативу водопаду вы используете?

Scrum.

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

maxshevtsov · 22.10.2010

dr_mousefly сказав(ла):
с каких это пор "создание спеки" стало называться проектированием?

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

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

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

А вы ему а вот в вспеке так описано

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

К ТС, смеятся больше не буду, так как человек вы серьезный.

neocortex · 22.10.2010

Не нужно проектирование выделять в отдельный, тяжеловесный этап. В англоязычных источниках это называется Big Design Up-Front (BDUF), и в настоящее время в большинстве случаев считается плохой практикой, так же как и Big Requirements Up-Front, т.е. создание детальной спеки с самого начала.

Вместо этого, развивайте вашу архитектуру постепенно. Проектируйте лишь то, что необходимо для реализации конкретной фичи - следуйте принципам YAGNI (You Are Not Gonna Need It) и KISS (Keep It Simple, Stupid - ни в коем случае не в качестве личного оскорбления!). Но при этом обязательно пишите юнит-тесты. Их, кстати, в эстимейте не всегда нужно показывать, в вашем случае я бы не стал. И - освойте рефакторинг, т.к. при таком подходе архитектура может значительно меняться по ходу проекта.

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

Зависит от типа проекта... если fixed budget - то это оправданный подход, да и то в случае неадекватного клиента, решившего "похалявить". Если time & material - то, наоборот, побольше change request'ов, хороших и разных

dr_mousefly сказав(ла):
и да, внтури цикла - таки маленький водопадег.

Вынужден возразить - в "труЪ" Agile фазы внутри итерации (спринта) перекрываются, т.е. разработка начинается до того, как окончательно утрясены все требования, тестирование начинается как только в билде появится первая фича, а не дожидается code freeze и т.п.

Klez · 23.10.2010

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

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

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

hellfire · 23.10.2010

dr_mousefly сказав(ла):
Scrum.

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

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

1. доступ на уровне модуль/функция
2. глобальный пул данных
3. глобальный пул объектов (пока под вопросом)

ну и это всё должно работать :ги:

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

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

neocortex сказав(ла):
Не нужно проектирование выделять в отдельный, тяжеловесный этап. В англоязычных источниках это называется Big Design Up-Front (BDUF), и в настоящее время в большинстве случаев считается плохой практикой, так же как и Big Requirements Up-Front, т.е. создание детальной спеки с самого начала.

Вместо этого, развивайте вашу архитектуру постепенно. Проектируйте лишь то, что необходимо для реализации конкретной фичи - следуйте принципам YAGNI (You Are Not Gonna Need It) и KISS (Keep It Simple, Stupid - ни в коем случае не в качестве личного оскорбления!). Но при этом обязательно пишите юнит-тесты. Их, кстати, в эстимейте не всегда нужно показывать, в вашем случае я бы не стал. И - освойте рефакторинг, т.к. при таком подходе архитектура может значительно меняться по ходу проекта.

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

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

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

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

да )) отличная идея )))

eugene_kr · 23.10.2010

В конечном итоге нужно что бы клиент (заказчик) был доволен. Заказчик имеет проблему (задачу) и желает её решения. Значит, нужно решить следующую задачу.
Дано: проблема заказчика.
Требуется: решение проблемы.
Решение:
формула удовлетворенности заказчика:
У=Р-З
, где У - удовлетворённость, Р - решение проблемы, З - затраты.
Применимо к заказчику-бизнесмену (человек, которые вкладывает деньги для их получения прибыли) формула адаптируется:
Удовлетворенность = ожидаемый доход от использования предоставленного решения - (минус) затраты на решение.

Что бы найти "решение проблемы", которое даст максимальную удовлетворённость заказчика, нужно выяснить, как заказчик-бизнесмен ожидает получить доход от его использования, то есть какие цели он преследует и как он определяет, что цель достигнута. Таким образом выделяются значимые для заказчика ожидания и критерии их удовлетворения. Дальше, нужно найти такой "проект решения" для данных условий, что бы формула давала положительное значение удовлетворённости. Иногда, полное решение для удовлетворения ожиданий даёт отрицательную удовлетворённость заказчика. Тогда нужно донести это заказчику и отказаться от реализации проекта.
В "проект решения" обязательно должен быть рассмотрен совместно с расчётом затрат на "реализацию решения".
Так вот, за "проект решения" заказчик не хочет платить. И это нормально для заказчика-бизнесмена. В тоже время бизнесмен-заказчик согласен и готов платить за "реализацию решения". Значит в стоимость "реализации решения" должна быть включена стоимость (время) проектирования ("проект решения"). Есть риск, что не будет найден проект решения такой, который даст положительную удовлетворенность заказчика. В таком случае будет "условная положительная удовлетворённость" бизнесмена-заказчика, так как вы уберегли его от затрат на решение, которое его в конечном итоге не удовлетворит его. Это в долгосрочной перспективе даст вам плюс. Напомню, что избежать рисков нельзя, нужно ими управлять.
Со ссылкой на публичные выступления Ефименко из Unitecsys могу сообщить, что поиск "проекта решения" может составить до 50% (сложный проект) - 100% (проект от реализации которого стоит отказаться) времени проекта, стоимость поиска "проекта решения" не оплачивается заказчиком "отдельно" и, одновременно, данная стратегия коммерчески выгодна в среднесрочной и долгосрочной перспективе.

lala-fa · 23.10.2010

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

Я б не взял на себя разработку сложного ПО без этапа проектирования, потому как 7 раз отмерь - один раз отрежь.

dr_mousefly · 23.10.2010

neocortex сказав(ла):
Вынужден возразить - в "труЪ" Agile фазы внутри итерации (спринта) перекрываются, т.е. разработка начинается до того, как окончательно утрясены все требования, тестирование начинается как только в билде появится первая фича, а не дожидается code freeze и т.п.

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

maxshevtsov сказав(ла):
А вы ему а вот в вспеке так описано

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

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

и что тут страшного?
мы включаем в цену lifetime support. не индусы же бросать клиентов на произвол судьбы.

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

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

hellfire · 23.10.2010

dr_mousefly сказав(ла):
и что тут страшного?
мы включаем в цену lifetime support. не индусы же бросать клиентов на произвол судьбы.

кстати, о саппорте. у меня пол года любого саппорта. а дальше lifetime за бабло. а как вы работате?

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

dr_mousefly · 23.10.2010

hellfire сказав(ла):
кстати, о саппорте. у меня пол года любого саппорта. а дальше lifetime за бабло. а как вы работате?

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

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

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

hellfire сказав(ла):
изначально, заказчик просто обрисовал суть системы, т.к. она у него патентованная.

э... только заметил..
патенто-тролль?? о нет, бегите от него как от огня немедленно!!!

eugene_kr · 23.10.2010

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

Слова - золото!

Klez · 23.10.2010

слово в карман не положишь (c)

neocortex · 23.10.2010

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

Да нет никакого секрета. Просто нужно чуть менее догматично рассматривать понятия potentially shippable increment и user story, так как в реальной жизни далеко не всегда можно однозначно сопоставить user story и minimum marketable feature (MMF). Более того, Скрам вроде как даже не требует, чтобы в продакт бэклоге были ТОЛЬКО user story, он оперирует более широким понятием product backlog item.

И, люто, бешено плюсую dr_mousefly:

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

Коллеги! Прошу вашей помощи

lala-fa