Здравствуйте, Saddo, Вы писали:

S>Как эти проблемы решается в других компаниях?

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

> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.

Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.

Здравствуйте, Gaperton, Вы писали:

S>>Как эти проблемы решается в других компаниях?

G>Есть сложная методика, которая применяется во многих компаниях уже десятки лет, и неплохо себя зарекомендовала. Она состоит в соблюдении двух сложных правил.
G>1) Программист берет книгу о предметной области, и внимательно ее читает. Например. Если программист занимается автоматизацией бухгалтерии — он должен знать основы бухучета. Если он пишет софт для трейдеров — он изучает пару учебников для трейдеров. Если он занимается колл-центрами — он читает книгу про коллцентры. Это очень необычный и смелый ход — вот так просто взять, и изучить терминологию предметной области, я понимаю, однако во всех компаниях, где я работал, люди поступали именно так.
G>2) Очень важно делать пункт (1), читая книги по предметной области ВМЕСТО книг по DDD. Это очень сложно, но совершенно необходимо. В сочетании с первым пунктом, это правило практически гарантирует а) огромную экономию времени, б) полное отсутствие указанных проблем, и в) отсутствие потребности в переводчиках с русского на русский.

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

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

Но ведь суть-то в том, что программисты — люди, и поддаются изменениям, навязываемым извне, с большим трудом. Это будет действительно здорово, когда программер начинает читать книги по предметной области, ибо он делает первый шаг к тому, чтобы стать аналитиком. Почти любая компания, в которой что-то понимают в управлении, готова вбухать немало денег в этот процесс, потому что это — очень выгодные вложения. Увы, бить по площадям (всем программерам) — слишком дорого, вследствие малого КПД, поэтому обычно ограничиваются лидами — у них КПД выше. Такова жизнь. Большинство программистов в гробу видели эту предметную область, и если их неосторожно пинать на ее изучение — а равно на изучение DDD — они просто уйдут.

>> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.

G>Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.

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

В необходимости переводчика присутствуют риски, связанные с его незаменимостью, и, как следствие, перегруженностью. Именно эти риски следует убирать в первую очередь, переводя его работу хотя бы на лидов. Что и пытается сделать автор темы. Не спорю, перенести сразу на программеров — во много раз лучше, но во столько же раз дольше, дороже и рискованнее.

А от DDD зачем избавляться? Он здесь совершенно не при чем. Ну хочется человеку поиграться с новым процессом — пускай, если условия позволяют. Уже в третий раз пишу: возьмите любой другой процесс — проблемы останутся те же.

Здравствуйте, nvb, Вы писали:

G>>Есть сложная методика, которая применяется во многих компаниях уже десятки лет, и неплохо себя зарекомендовала. Она состоит в соблюдении двух сложных правил.
G>>1) Программист берет книгу о предметной области, и внимательно ее читает. Например. Если программист занимается автоматизацией бухгалтерии — он должен знать основы бухучета. Если он пишет софт для трейдеров — он изучает пару учебников для трейдеров. Если он занимается колл-центрами — он читает книгу про коллцентры. Это очень необычный и смелый ход — вот так просто взять, и изучить терминологию предметной области, я понимаю, однако во всех компаниях, где я работал, люди поступали именно так.
G>>2) Очень важно делать пункт (1), читая книги по предметной области ВМЕСТО книг по DDD. Это очень сложно, но совершенно необходимо. В сочетании с первым пунктом, это правило практически гарантирует а) огромную экономию времени, б) полное отсутствие указанных проблем, и в) отсутствие потребности в переводчиках с русского на русский.

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

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

Разумеется меньше, если их противопоставлять изучению предметной области. От одного изучения оной + сокращения цепочки коммуникации будет заметный и быстрый, качественный эффект. Существенно превышающий эффект от перечисленного, если оно будет делаться _вместо_ изучения предметной области. Ибо понимание предметной области — the must, оно фундаментально, а остальное на самом деле рюшечки и оборочки. Можно, скажем, вовсе не строить моделей, а грамотно двигаться короткими итерациями. При адекватном инструменте и задаче может получиться не хуже, а лучше.

Меня вообще изумляет, что сейчас это является предметом дискуссий. Раньше, лет 10 назад, до появления дикого хайпа вокруг "методик", это как-то всем казалось очевидным.

nvb>Но ведь суть-то в том, что программисты — люди, и поддаются изменениям, навязываемым извне, с большим трудом. Это будет действительно здорово, когда программер начинает читать книги по предметной области, ибо он делает первый шаг к тому, чтобы стать аналитиком.

Правда? Это теперь так называется? "Изменения, навязанные извне"? "первый шаг к тому, чтобы стать аналитиком"? Это ничего, что, скажем, у нас в CQG не было аналитиков, и каждый инженер первым делом _сам_, без понуканий, разбирался в основах биржевой торговли без цели стать каким-то дебильным "аналитиком"? Это что, становится сейчас нормальным — работать программистом над, скажем, софтом для трейдеров, не имея элементарного понятия о том, что такое "фьючерс" или "опцион"? А программисту работающему над бухгалтерским пакетом — теперь стало нормально не знать, как сводится балланс, да? Две недели влом потратить на чтение книги после найма, рассчитанной на первокурсника, я не пойму?

nvb>Почти любая компания, в которой что-то понимают в управлении, готова вбухать немало денег в этот процесс, потому что это — очень выгодные вложения. Увы, бить по площадям (всем программерам) — слишком дорого, вследствие малого КПД, поэтому обычно ограничиваются лидами — у них КПД выше. Такова жизнь.

"Жизнь такова"? Вы меня изумляете. Я не знаю, в каком бизнесе вы работаете, если элементарное ознакомление программистов с предметной областью для вас "дорого", а внедрять процессы — "дешево". Вот честно.

nvb>Большинство программистов в гробу видели эту предметную область, и если их неосторожно пинать на ее изучение — а равно на изучение DDD — они просто уйдут.

Большинство тех программистов, кого я знаю — не видели это в гробу, а напротив — весьма живо этим интересуются. С точки зрения _всего_ моего опыта — вы рассказываете про какое-то зазеркалье.

>>> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.

G>>Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.

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

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

И, кстати, мне не вполне понятно, откуда у него возьмется нагрузка по 12 часов в день на закрытии этапов. Это весьма расслабленный период, ибо требования обычно идентифицируются в начале работы, а не в конце. Или мы говорим об особом типе проектов, в которых все наоборот?

nvb>В необходимости переводчика присутствуют риски, связанные с его незаменимостью, и, как следствие, перегруженностью. Именно эти риски следует убирать в первую очередь, переводя его работу хотя бы на лидов. Что и пытается сделать автор темы. Не спорю, перенести сразу на программеров — во много раз лучше, но во столько же раз дольше, дороже и рискованнее.

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

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

nvb>А от DDD зачем избавляться? Он здесь совершенно не при чем. Ну хочется человеку поиграться с новым процессом — пускай, если условия позволяют. Уже в третий раз пишу: возьмите любой другой процесс — проблемы останутся те же.

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

Здравствуйте, Gaperton, Вы писали:

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

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

G>Разумеется меньше, если их противопоставлять изучению предметной области. От одного изучения оной + сокращения цепочки коммуникации будет заметный и быстрый, качественный эффект. Существенно превышающий эффект от перечисленного, если оно будет делаться _вместо_ изучения предметной области. Ибо понимание предметной области — the must, оно фундаментально, а остальное на самом деле рюшечки и оборочки.

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

G>Можно, скажем, вовсе не строить моделей, а грамотно двигаться короткими итерациями. При адекватном инструменте и задаче может получиться не хуже, а лучше.

Это только на малых проектах, преимущественно продуктовых. Возьмем заказной проект в 50 человеко-лет — в продвинутых компаниях понимают, что нельзя сразу начинать итерации, там вначале модель строят, согласуют ее с заказчиком — не начинающие программеры, разумеется — и только после этого приступают к ее реализации. Лучше, действительно, итерациями.

nvb>>Но ведь суть-то в том, что программисты — люди, и поддаются изменениям, навязываемым извне, с большим трудом. Это будет действительно здорово, когда программер начинает читать книги по предметной области, ибо он делает первый шаг к тому, чтобы стать аналитиком.

G>Правда? Это теперь так называется? "Изменения, навязанные извне"? "первый шаг к тому, чтобы стать аналитиком"? Это ничего, что, скажем, у нас в CQG не было аналитиков, и каждый инженер первым делом _сам_, без понуканий, разбирался в основах биржевой торговли без цели стать каким-то дебильным "аналитиком"? Это что, становится сейчас нормальным — работать программистом над, скажем, софтом для трейдеров, не имея элементарного понятия о том, что такое "фьючерс" или "опцион"? А программисту работающему над бухгалтерским пакетом — теперь стало нормально не знать, как сводится балланс, да?

Если разработка идет по тяжелым процессам — вполне. Аналитики пишут частные ТЗ и после этого обезьяны начинают кодить. Правильно это, или нет — вопрос второй. Наверное, нет, но множество крупных компаний пока идут по этому пути.
У вас в CQG был свой процесс, в котором упор делался на индивидуальные компетенции. Он доказал свою жизнеспособность, но, наверное, что-то было в нем особенное, что помешало всем остальным компаниям пойти за вами вслед. Полагаю, это были люди, которые ставили этот процесс

G>Две недели влом потратить на чтение книги после найма, рассчитанной на первокурсника, я не пойму?

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

nvb>>Почти любая компания, в которой что-то понимают в управлении, готова вбухать немало денег в этот процесс, потому что это — очень выгодные вложения. Увы, бить по площадям (всем программерам) — слишком дорого, вследствие малого КПД, поэтому обычно ограничиваются лидами — у них КПД выше. Такова жизнь.

G>"Жизнь такова"? Вы меня изумляете. Я не знаю, в каком бизнесе вы работаете, если элементарное ознакомление программистов с предметной областью для вас "дорого", а внедрять процессы — "дешево". Вот честно.

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

nvb>>Большинство программистов в гробу видели эту предметную область, и если их неосторожно пинать на ее изучение — а равно на изучение DDD — они просто уйдут.

G>Большинство тех программистов, кого я знаю — не видели это в гробу, а напротив — весьма живо этим интересуются. С точки зрения _всего_ моего опыта — вы рассказываете про какое-то зазеркалье.

Насчет _всего_ — не надо. Мы оба работали в ИТМ, отлично знаем, что там — не так, и вбито это на уровне официально декларированных процессов. Впрочем, это вырожденный случай

>>>> В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.

G>>>Избавьтесь от переводчика с русского на русский и от DDD. Уйдут и названные Вами проблемы. Как по волшебству. Наличие "переводчика" замедляет вам изучение предметной области (и скорее, делает это вообще невозможным, ибо вряд-ли он по своей воле сложит с себя полномочия), и значительно понижает КПД разработки.

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

Нет такой должности — переводчик. Эту роль выполняют аналитики, а у них и так работы хватает.

G>И, кстати, мне не вполне понятно, откуда у него возьмется нагрузка по 12 часов в день на закрытии этапов. Это весьма расслабленный период, ибо требования обычно идентифицируются в начале работы, а не в конце. Или мы говорим об особом типе проектов, в которых все наоборот?

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

nvb>>В необходимости переводчика присутствуют риски, связанные с его незаменимостью, и, как следствие, перегруженностью. Именно эти риски следует убирать в первую очередь, переводя его работу хотя бы на лидов. Что и пытается сделать автор темы. Не спорю, перенести сразу на программеров — во много раз лучше, но во столько же раз дольше, дороже и рискованнее.

G>Риски тут вторичны. Корень проблемы не в рисках. Лишнее звено в коммуникации способствует искажению информации, и замедлению обмена этой информацией. И все. Особенно, если звено перегружено — искажений будет гораздо больше, причем, это незаметно и трудноуловимо, выяснять вы это будете именно на сдаче.

А это разве не то, что называется описанием рисков?

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

По стоимости эти варианты примерно одинаковы, но "устранение звена" эффективнее — если выбирать только из этих двух.

G>А лиды они на то и лиды, чтобы очень хорошо разбираться в предметной области.

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

nvb>>А от DDD зачем избавляться? Он здесь совершенно не при чем. Ну хочется человеку поиграться с новым процессом — пускай, если условия позволяют. Уже в третий раз пишу: возьмите любой другой процесс — проблемы останутся те же.

G>Процесс здесь очень даже причем. Человек сместил фокус с проблемы, и непосредственного восприятия действительности, на "процесс", глядя на реальность через его "призму", существенно снизив собственные шансы докопаться до природы проблемы, и ее исправления. Все потому, что придает ему слишком большое значение. Тут я, разумеется, догадываюсь, может быть, он на самом деле вовсе не придает ему большого значения. Но мне пока кажется так.

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

nvb>У вас в CQG был свой процесс, в котором упор делался на индивидуальные компетенции. Он доказал свою жизнеспособность, но, наверное, что-то было в нем особенное, что помешало всем остальным компаниям пойти за вами вслед. Полагаю, это были люди, которые ставили этот процесс

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

nvb>Не надо добавлять дополнительные условия. Сразу после найма, разумеется, свежеиспеченный выпускник-программер будет читать книжки по предметной области — куда ж ему деваться, бедняге. А вот через пару лет после найма — тут бабушка надвое сказала.

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

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

Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?

Здравствуйте, Gaperton, Вы писали:

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

Здравствуйте, VGn, Вы писали:

nvb>>У вас в CQG был свой процесс, в котором упор делался на индивидуальные компетенции. Он доказал свою жизнеспособность, но, наверное, что-то было в нем особенное, что помешало всем остальным компаниям пойти за вами вслед. Полагаю, это были люди, которые ставили этот процесс

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

Это только до времени сдачи своего первого проекта. Потом они прозревают — если, конечно, в компании по окончании проекта предусмотрен разбор полетов и по его итогам — морковка, спереди или сзади. Либо переходят в другую компанию, с прежними убеждениями, как непонятые гении

nvb>>Не надо добавлять дополнительные условия. Сразу после найма, разумеется, свежеиспеченный выпускник-программер будет читать книжки по предметной области — куда ж ему деваться, бедняге. А вот через пару лет после найма — тут бабушка надвое сказала.

VGn>Через пару лет должно быть то же самое, если конечно специалист не "в лес смотрит", а это уже вопрос мотивации.

"Честные люди должны получать достойную зарплату а воры должны сидеть в тюрьме" — утверждение из той же оперы. Да, согласен, но редко встречал на практике. Может быть, мне в жизни не повезло

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

VGn>Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?

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

Здравствуйте, nvb, Вы писали:

VGn>>Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?

nvb>Это хорошо подходит для продуктовых проектов, в заказной разработке сложнее — обычно из-за неопределенности в контракте процесса внесения изменений в требования. И, как следствие, в сроки и цену — контракт-то подписан ДО прототипирования. А вообще — никто не мешает, конечно. Есть еще множество способов избежать вышеописанного геморроя. Но почему-то их не используют и проекты проваливаются.

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

Насчет изменений в тьребованиях. Процесс внесения изменений в требования в контракт не вносится, потому как достаточно четко определен в ЕСПД (ГОСТ 19). Достаточно в договоре прописать ссылки на него. Более того, в контракте можно не прописывать сумму, она, так же как состав, сроки, и стоимость этапов, является частью ТЗ, процедура изменения которого определена. Более того, сроки и стоимость этапов (но не их состав) могут быть вынесены в отдельный документ — "ведомость исполнения" или "план-график", которые править еще легче.

И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.

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

Здравствуйте, Gaperton, Вы писали:

VGn>>>Всё о мЕтОдОлОгиях? Что мешает просто улучшить обратную связь за счёт прототипирования и, например, обкатки в фокус-группе?

nvb>>Это хорошо подходит для продуктовых проектов, в заказной разработке сложнее — обычно из-за неопределенности в контракте процесса внесения изменений в требования. И, как следствие, в сроки и цену — контракт-то подписан ДО прототипирования. А вообще — никто не мешает, конечно. Есть еще множество способов избежать вышеописанного геморроя. Но почему-то их не используют и проекты проваливаются.

G>Если при заказной разработке в условиях неопределенности не сделать прототипа, не управлять требованиями и не получать обратной связи, все вылетит в трубу еще быстрее и вернее, чем при продуктовой. И никакие мЕтОдОлОгИи не помогут, если этого не делать. Природу не обманешь.

Я постоянно открещиваюсь от методологий, а мне их с упорством приписывают

G>Насчет изменений в тьребованиях. Процесс внесения изменений в требования в контракт не вносится, потому как достаточно четко определен в ЕСПД (ГОСТ 19). Достаточно в договоре прописать ссылки на него.

Подскажите, в каком ГОСТе это есть, очень интересно. Все контракты, что проходили через меня, обычно ограничивались фразой типа "Изменение Заказчиком требований оформляется дополнительным соглашением Сторон с приложением протокола контрактной цены, которые с момента их подписания являются неотъемлемой частью настоящего контракта. Объем доптребований и цена контракта не могут быть изменены более чем на хх %". Говоря коротко — только через допсоглашение.

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

Э.. Я сейчас подумал — может я чего забыл, и просмотрел ГОСТ на ТЗ. Как ни странно, ничего нового не обнаружил. Допускается в ТЗ вводить пункт "Стадии и этапы разработки", это да, но умные люди так обычно не поступают, во всяком случае — дважды, поскольку пересогласовать ТЗ на нескольких десятках страниц — это совсем не то же самое, что пересогласовать ведомость исполнения на двух страницах. Ведомость как была приложением к контракту, так и осталась. Про нее никакого упоминания в 201 ГОСТе нет. Да и с точки зрения здравого смысла, это логично — срыв сроков не должен приводить к переделке ТЗ. ТЗ — обычно приложение №1 к контракту, ведомость исполнения — приложение №2.

Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.

G>И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.

Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов

G>Насчет множества способов избежать вышеописанного геморроя — их все-таки не множество, а ровно два. Прототипы и ранняя обратная связь за счет укорачивания цикла разработки и "итеративности", и второй — анализ требований, что что полагается на внутреннюю экспертизу в предметной области. Все, ничего радикально другого человечество не придумало, все остальное — частности и вариации. И знаете, их очень многие используют, и проекты не проваливаются. Некоторые даже не стесняются использовать комбинацию этих способов .

Ну я же написал третий, и думаю, что не последний Не всегда возможна итеративность — если система сложная, первая итерация появится не скоро — и не всегда возможна экспертиза — если компания лезет в новую для себя (или вообще для человечества) прикладную область. Хотя для 95% проектов, согласен, более чем достаточна вышеописанная комбинация. Я-то писал, что беда в том, что она не всегда применяется.

G>>Насчет изменений в тьребованиях. Процесс внесения изменений в требования в контракт не вносится, потому как достаточно четко определен в ЕСПД (ГОСТ 19). Достаточно в договоре прописать ссылки на него.

nvb>Подскажите, в каком ГОСТе это есть, очень интересно. Все контракты, что проходили через меня, обычно ограничивались фразой типа "Изменение Заказчиком требований оформляется дополнительным соглашением Сторон с приложением протокола контрактной цены, которые с момента их подписания являются неотъемлемой частью настоящего контракта. Объем доптребований и цена контракта не могут быть изменены более чем на хх %". Говоря коротко — только через допсоглашение.

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

nvb>Э.. Я сейчас подумал — может я чего забыл, и просмотрел ГОСТ на ТЗ. Как ни странно, ничего нового не обнаружил. Допускается в ТЗ вводить пункт "Стадии и этапы разработки", это да, но умные люди так обычно не поступают, во всяком случае — дважды, поскольку пересогласовать ТЗ на нескольких десятках страниц — это совсем не то же самое, что пересогласовать ведомость исполнения на двух страницах. Ведомость как была приложением к контракту, так и осталась. Про нее никакого упоминания в 201 ГОСТе нет. Да и с точки зрения здравого смысла, это логично — срыв сроков не должен приводить к переделке ТЗ. ТЗ — обычно приложение №1 к контракту, ведомость исполнения — приложение №2.



nvb>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.

Бывает ещё одностраничный документ "Этапная программа". Обычно так деньги проще всего по кусочкам выскребать . Военка кстати так и работает.

nvb>Ну я же написал третий, и думаю, что не последний Не всегда возможна итеративность — если система сложная, первая итерация появится не скоро — и не всегда возможна экспертиза — если компания лезет в новую для себя (или вообще для человечества) прикладную область. Хотя для 95% проектов, согласен, более чем достаточна вышеописанная комбинация. Я-то писал, что беда в том, что она не всегда применяется.

В таких случаях итеративность возможна на отдельных фазах.
А вообще не плохо бы тогда не пропускать фазы по ГОСТу:
бумага

Автор: VGn
Дата: 07.03.08

Здравствуйте, VGn, Вы писали:

nvb>>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.

VGn>Бывает ещё одностраничный документ "Этапная программа". Обычно так деньги проще всего по кусочкам выскребать . Военка кстати так и работает.

Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.

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

Можно получить описание этого документа — ссылку или что-то еще?

Здравствуйте, nvb, Вы писали:

nvb>Здравствуйте, VGn, Вы писали:

nvb>>>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.

VGn>>Бывает ещё одностраничный документ "Этапная программа". Обычно так деньги проще всего по кусочкам выскребать . Военка кстати так и работает.

nvb>Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.

nvb>Да и деньги по кусочкам очень даже неплохо выскребать через ведомость исполнения — разбить работы на этапы и прописать цену каждого этапа. Правда, в этом случае появляются дополнительные накладные расходы на закрытие каждого этапа, связанные с рожанием определенного количества бумаг.

nvb>Можно получить описание этого документа — ссылку или что-то еще?

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

nvb>Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.

Много видел в интернете военных контрактов?
Там же гриф минимум "конфиденциально".

Здравствуйте, nvb, Вы писали:

nvb>Подскажите, в каком ГОСТе это есть, очень интересно. Все контракты, что проходили через меня, обычно ограничивались фразой типа "Изменение Заказчиком требований оформляется дополнительным соглашением Сторон с приложением протокола контрактной цены, которые с момента их подписания являются неотъемлемой частью настоящего контракта. Объем доптребований и цена контракта не могут быть изменены более чем на хх %". Говоря коротко — только через допсоглашение.

Ну да, это звучит похоже на правду. Насчет процедуры изменения ТЗ я могу уточнить у нашего гуру по ТЗ. Это и в самом деле интересно.

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

nvb>Э.. Я сейчас подумал — может я чего забыл, и просмотрел ГОСТ на ТЗ. Как ни странно, ничего нового не обнаружил. Допускается в ТЗ вводить пункт "Стадии и этапы разработки", это да, но умные люди так обычно не поступают, во всяком случае — дважды, поскольку пересогласовать ТЗ на нескольких десятках страниц — это совсем не то же самое, что пересогласовать ведомость исполнения на двух страницах. Ведомость как была приложением к контракту, так и осталась. Про нее никакого упоминания в 201 ГОСТе нет. Да и с точки зрения здравого смысла, это логично — срыв сроков не должен приводить к переделке ТЗ. ТЗ — обычно приложение №1 к контракту, ведомость исполнения — приложение №2.

Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения. Традиция выполнения заказов по линии ФАП/минпромторг, не иначе.

nvb>Общая сумма прописывается в контракте, в пункте "Стоимость работ и порядок расчетов", да и с какой радости она появится в ТЗ? (интересно было бы посмотреть пример ТЗ с ценой). Суммы по этапам прописываются в ведомости исполнения.

Общая сумма не появляется, однако по этапам — могут. Я своими глазами видел такое ТЗ, пришедшее из ФАП-а.

G>>И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.

nvb>Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов

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

Вообще же уточнение ТЗ на этапе эскизного проекта, как предлагаете вы — это также отличный вариант. Вот видите — все вы знаете лучше меня . Зачем народ пугаете тогда? Можно, можно нормально работать на fixed cost. Руки только в циркулярную пилу совать не надо, и все будет хорошо .

G>>Насчет множества способов избежать вышеописанного геморроя — их все-таки не множество, а ровно два. Прототипы и ранняя обратная связь за счет укорачивания цикла разработки и "итеративности", и второй — анализ требований, что что полагается на внутреннюю экспертизу в предметной области. Все, ничего радикально другого человечество не придумало, все остальное — частности и вариации. И знаете, их очень многие используют, и проекты не проваливаются. Некоторые даже не стесняются использовать комбинацию этих способов .

nvb>Ну я же написал третий, и думаю, что не последний Не всегда возможна итеративность — если система сложная, первая итерация появится не скоро — и не всегда возможна экспертиза — если компания лезет в новую для себя (или вообще для человечества) прикладную область. Хотя для 95% проектов, согласен, более чем достаточна вышеописанная комбинация. Я-то писал, что беда в том, что она не всегда применяется.

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

А то, что не всегда применяется — ну так что на это сетовать. Не заставлять же людей, когда они просто не умеют. Я вот, например, уверен, что причина в том, что существующие методические материалы по менеджменту никуда не годятся. Ни к черту.

Здравствуйте, VGn, Вы писали:

nvb>>Свыше 10 лет имею дело с военкой, но ни разу не сталкивался с документом "Этапная программа". Поспрашивал знакомых — те тоже не знают. Поискал в гугле — нашел только один контракт, который ссылается на этот документ, но контракт не военный — гражданский.

VGn>Много видел в интернете военных контрактов?
VGn>Там же гриф минимум "конфиденциально".

Название документов перечислено в военном ГОСТ-е, а он вполне может лежать в сети. Документ действительно странный, я тоже никогда не слышал такого термина. С "план-графиком" не перепутал?

G>С "план-графиком" не перепутал?
Нет.
План граФИК, на сколько я помню, об этапаХ.
А этапная программа о этапЕ.
Ведомость будет после.

Здравствуйте, Gaperton, Вы писали:

G>Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения. Традиция выполнения заказов по линии ФАП/минпромторг, не иначе.

Да тут дело даже и не в удобстве. Если заказчик скажем так, странен, он вполне может вместе с измененным графиком изменить и требования. Я один раз наткнулся на такое — обещали поменять один пункт в ТЗ, а поменяли три, никак об остальных двух не уведомив. Случайно наткнулся, проформы ради листая перед подписанием. Заказчик потом клялся и божился, что это его подчиненные напортачили, безо всякого злого умысла, машинально сохранив изменения, но, как говорится, осадок остался

G>>>И последнее — в ситуации большой неопределенности ТЗ со всей перечисленной требухой является результатом первого этапа работ. Во время которого вы можете делать все, что необходимо, чтобы уточнить ТЗ — в том числе и прототип. Это если уж совсем неопределенно все.

nvb>>Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов

G>Допускается. В случае, когда совсем жопа, ТЗ вообще полагается делать результатом отдельного НИР. И делают. Скажем, ТЗ на новый комплекс ПВО вообще делает отдельный НИИ, сильно напрягая при этом мозк. Также, допускается делать ТЗ результатом первого этапа — такая опция упоминалась, хотя на практике я с таким не сталкивался (а это наиболее интересный вариант).

В этом случае все равно будет ТЗ на ТЗ Или хотя бы технические требования на ТЗ. Ибо деньги платят за что-то, и это что-то фиксируется документально, причем отдельным документом. Причина вот в чем:

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

Разумеется, все вышесказанное справедливо только для крупных работ, имеющих сколь-нибудь значимое IP. Если надо поставить в магазин десять ящиков пива, в контракте так и напишут, на четырех пустых строчках прямо в тексте типового контракта.

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

Да я не спорю, прототипировать можно все — вопрос в степени приближенности прототипа к реальности. Модель системы на UML — это ведь тоже прототип, весьма полезный, кстати. Чем не первая итерация?
А вот если взять упомянутый процессор, и вписать в ТЗ фразу "военный диапазон температур", то первый работающий в железе прототип удатся получить хорошо, если через год, и никакие симуляторы не помогут узнать его реальную тактовую частоту, пока не будут созданы, оттестированы и нормализованы библиотеки элементов для разводчиков чипа, применительно к конкретному заводу.

Здравствуйте, nvb, Вы писали:

G>>Делают и так и так. Лучше, конечно, делать как говорите вы. Это удобнее. У нас, однако, делается так — состав этапов указывается в ТЗ, сроки и стоимость — в ведомости исполнения. Традиция выполнения заказов по линии ФАП/минпромторг, не иначе.

nvb>Да тут дело даже и не в удобстве. Если заказчик скажем так, странен, он вполне может вместе с измененным графиком изменить и требования. Я один раз наткнулся на такое — обещали поменять один пункт в ТЗ, а поменяли три, никак об остальных двух не уведомив. Случайно наткнулся, проформы ради листая перед подписанием. Заказчик потом клялся и божился, что это его подчиненные напортачили, безо всякого злого умысла, машинально сохранив изменения, но, как говорится, осадок остался

Без вашей подписи это все равно не пройдет, так что не проблема. Дело на мой взгляд в первую очередь в удобстве. Проверять ясен хрен надо. "Понятия", впрочем, также никто не отменял. Ходы то все записаны. Случайно прошедшие случайные изменения можно потом отменить. С накатом по шаловливым ручонкам.

nvb>>>Ммм... Не совсем так. ТЗ принимается сразу, но в него исполнителем прописывается фраза — сразу же после спорных пунктов — "Уточняется на этапе эскизного (технического) проекта". Заказчик обычно рычит на эти приписки, но его пыл охлаждает предложение "Тогда мы вынуждены увеличить сроки и цену, поскольку не знаем, во что выльется реализация этого пункта". Помню, было у меня ТЗ на НИОКР, где таких приписок было больше, чем в половине пунктов

G>>Допускается. В случае, когда совсем жопа, ТЗ вообще полагается делать результатом отдельного НИР. И делают. Скажем, ТЗ на новый комплекс ПВО вообще делает отдельный НИИ, сильно напрягая при этом мозк. Также, допускается делать ТЗ результатом первого этапа — такая опция упоминалась, хотя на практике я с таким не сталкивался (а это наиболее интересный вариант).

nvb>В этом случае все равно будет ТЗ на ТЗ Или хотя бы технические требования на ТЗ. Ибо деньги платят за что-то, и это что-то фиксируется документально, причем отдельным документом. Причина вот в чем:

Будет безусловно. ТЗ на НИР, с постановкой проблемы. Причина, собственно, в том, что ТЗ просто должно быть как на НИР так и на ОКР, и все . Просто там будут написаны разные вещи — ТЗ на НИР и ОКР натурально отличаются. Цель НИР — "исследование возможностей создания", в то время как цель ОКР — собственно "создание". Формы ТЗ, как вы безусловно знаете, немного разные на НИР и ОКР. В случае НИР, насколько я смутно припоминаю (года 2 с ними не сталкивался), всего где-то примерно три основных части в ТЗ, и оно сильно проще.

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

nvb>Да я не спорю, прототипировать можно все — вопрос в степени приближенности прототипа к реальности. Модель системы на UML — это ведь тоже прототип, весьма полезный, кстати. Чем не первая итерация?

Да практически ничем. Это не прототип ни в коем разе, ибо его нельзя испытать и исследовать его свойства экспериментально. Это один из артефактов "эскизного проекта". UML-диаграмма — это гипотеза. Испытания прототипа — это эксперимент. Инженерия использует физический подход гипотеза-эксперимент.

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

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

Здравствуйте, VGn, Вы писали:

G>>С "план-графиком" не перепутал?
VGn>Нет.
VGn>План граФИК, на сколько я помню, об этапаХ.
VGn>А этапная программа о этапЕ.
VGn>Ведомость будет после.

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

Здравствуйте, Gaperton, Вы писали:

G>Без вашей подписи это все равно не пройдет, так что не проблема. Дело на мой взгляд в первую очередь в удобстве. Проверять ясен хрен надо. "Понятия", впрочем, также никто не отменял. Ходы то все записаны. Случайно прошедшие случайные изменения можно потом отменить. С накатом по шаловливым ручонкам.

Зависит от отношений с заказчиком, а они на финальном этапе могут испортиться.

nvb>>Да я не спорю, прототипировать можно все — вопрос в степени приближенности прототипа к реальности. Модель системы на UML — это ведь тоже прототип, весьма полезный, кстати. Чем не первая итерация?

G>Да практически ничем. Это не прототип ни в коем разе, ибо его нельзя испытать и исследовать его свойства экспериментально. Это один из артефактов "эскизного проекта". UML-диаграмма — это гипотеза. Испытания прототипа — это эксперимент. Инженерия использует физический подход гипотеза-эксперимент.

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

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

G>Да никаких проблем нет с этим требованием. Симуляторы, во-первых, помогут узнать его реальную тактовую частоту — уже симуляция на раннем этапе (нетлист) дает коридор точности примерно 20%.

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

G>Симуляция топологии — даст ее гораздо точнее. И покажет тепловыделение с энергопотреблением. Библиотеки элементов специально тестировать не надо — их параметры дает фабрика.

Подойдите к военпреду с этим предложением — использовать фабричные библиотеки западных заводов для военных целей, и послушайте, что он скажет. Предварительно убрав женщин из комнаты. Топология — это вопрос очень чувствительный. Уж на что раздолбаи в Элвисе — а даже они на своих библиотеках делали... ну, во всяком случае, декларировали. Вот запустят линию 90 нм на Ангстреме — тогда можно будет использовать фабричные, но сколько до этого еще осталось...

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

Потому что есть у военных жесткое правило — "Отбор запрещен". Температурные параметры микросхем, равно как и все прочие, должны обеспечиваться на стадии проектирования. Понятно, что есть искушение схитрить и использовать отбор, но оно легко пресекается процедурой приемки. Поговорите с военпредом, возьмите у него документ, описывающий эту процедуру. Если у вас заложен военный диапазон — а он пару лет назад был расширен — это самое серьезное требование в ТЗ, которое съест больше всего денег и времени. Риски огромные, а вы никак не реагируете на них(вернее, реагируете стратегией "принятие"), что очень опасно.

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

А вообще-то мы ушли от темы, как проектного управления, так и программирования. Давайте больше не будем про процессоры, хорошо? Или в личку.