AL
Более того вы путаете ТЗ и проект.
Если у нас есть некий дизайн, которому что-то должно соответствовать, то почему оно не часть ТЗ?
А если оно не часть ТЗ, то почему оно должно ему соответствовать?
Size: a a a
2020 November 21
GK
А если часть ТЗ, то как это проверить?
PD
Нет. Вы путаете задачи проектирования и производства.
Э, это точно мне? Тогда поясни?
SV
Э, это точно мне? Тогда поясни?
Это мне ))
SV
А если часть ТЗ, то как это проверить?
А тут мы уже приходим к тому, как принимается результат. И вот тут мы вполне можем договориться, что является комплектом документации, необходимой для предоставления заказчику. Но тут уже у архитектора несколько другая роль.
GK
Есть. Все кодогенераторы ужасны (
Вот что значит, давно сам этот вопрос не "трогал")
SV
Занимался кодогенерацией openapi на java, там все нормально. Не идеально, но нормально.
SV
Typescript не трогал, на flow сам писал генерацию типов, но без методов.
Хотя по сути все эти генераторы пол конкретный проект пишутся быстро. Долго костылями прикручивать что-то к swagger codegen если что-то не понравится.
Хотя по сути все эти генераторы пол конкретный проект пишутся быстро. Долго костылями прикручивать что-то к swagger codegen если что-то не понравится.
AL
А тут мы уже приходим к тому, как принимается результат. И вот тут мы вполне можем договориться, что является комплектом документации, необходимой для предоставления заказчику. Но тут уже у архитектора несколько другая роль.
Мы тут подходим к сути работ, а не к "способу приёмки".
GK
А тут мы уже приходим к тому, как принимается результат. И вот тут мы вполне можем договориться, что является комплектом документации, необходимой для предоставления заказчику. Но тут уже у архитектора несколько другая роль.
всего два варианта:
- сразу описывать по "стандарту", пусть и упрощённому
- описывать, когда есть ощущение, что проект приближается к пи*децу
Во втором варианте разрабочики не хотят "прозрачности", очевидно почему.
В обоих случаях, привет а-ля карточки/шаблоны)
- сразу описывать по "стандарту", пусть и упрощённому
- описывать, когда есть ощущение, что проект приближается к пи*децу
Во втором варианте разрабочики не хотят "прозрачности", очевидно почему.
В обоих случаях, привет а-ля карточки/шаблоны)
AL
Например классикой может являться "ТЗ на проектирование ИС". Или "ТЗ на опытно-конструкторскую работу" или "ТЗ на внедрение ИС" и так далее.
AL
Если у вас идёт условное проектирование ИТ-системы, то и верхнеуровневый дизайн и код будут разрабатываться в рамках одного проекта. И тут в ТЗ у вас только назначение системы.
AL
Ну ещё всякие предположения, допущения о качественно-количественных характеристиках, которые должны быть достигнуты в том месте, где она будет работать.
SV
Это всё верно.
AL
всего два варианта:
- сразу описывать по "стандарту", пусть и упрощённому
- описывать, когда есть ощущение, что проект приближается к пи*децу
Во втором варианте разрабочики не хотят "прозрачности", очевидно почему.
В обоих случаях, привет а-ля карточки/шаблоны)
- сразу описывать по "стандарту", пусть и упрощённому
- описывать, когда есть ощущение, что проект приближается к пи*децу
Во втором варианте разрабочики не хотят "прозрачности", очевидно почему.
В обоих случаях, привет а-ля карточки/шаблоны)
SV
Но в этой картине мира архитектор снова выступает тем, кто якобы платит деньги и хочет от разработчиков что-то получить согласно принятым в контракте договоренностям.
AL
Но в этой картине мира архитектор снова выступает тем, кто якобы платит деньги и хочет от разработчиков что-то получить согласно принятым в контракте договоренностям.
По сути - да. Разработчики должны ему представить доказательства того, что они сделали то, что от них просили.
AL
И я не про должность "архитектора". Я про его функциональную роль в проекте.
SV
Да... вот только такое редко бывает. Ну, на моей небольшой практике.
AL
Да... вот только такое редко бывает. Ну, на моей небольшой практике.
Не, можно конечно загрузить проверкой качества разработанного кода тестеров, но это крайне неэффективно.