Комментарии 13
Главный вывод: всегда все прописывать в ТЗ как можно четче и детализировано, и тщательно проверять (перепроверять) ТЗ на возможность иного толкования заказчиком.
И да, согласен, нужно налаживать связь и общаться не только с заказчиком, но и с конечным пользователем и учитывать их пожелания и «хотелки», но опять же — в рамках ТЗ.
Материал классный :)
И да, согласен, нужно налаживать связь и общаться не только с заказчиком, но и с конечным пользователем и учитывать их пожелания и «хотелки», но опять же — в рамках ТЗ.
Материал классный :)
всегда все прописывать в ТЗ как можно четче и детализировано, и тщательно проверять (перепроверять) ТЗ на возможность иного толкования заказчиком.
К сожалению, невозможно «взять и единым махом разрешить все проблемы простым способом».
Подробное ТЗ — никакая не панацея.
Любой сколько-нибудь значимый проект описывается столь объемным ТЗ, что его потом и прочитать затруднительно, а вы еще предлагаете детализировать и детализировать.
В результате можно потратить годы только на ТЗ. Которое все равно потом если и будут читать — то только в случае факапа, чтобы задницу прикрыть. А это явно не та цель, для которой нужно ТЗ.
Уже не говоря о том, что сплошь и рядом возникают ситуации, когда разглядеть требования для ТЗ (или их несоответствие) можно только когда начнется выполнение.
Я полностью согласен с тем, что нельзя прописать в ТЗ детальные требования к каждой функции и каждому процессу. Как правило, ТЗ содержит требования, достаточные для понимания того, что и как должна делать система. Но я твердо убежден, что в ТЗ обязательно должно быть указано, что система делать НЕ должна. Любой заказчик может в процессе реализации сказать, что он бы еще хотел получить вот это и вон то, и что эти функции подразумевались им при написании ТЗ. И возразить что-либо на такие дополнительные требования достаточно сложно по различным причинам. Но если в ТЗ явно указано, что система не будет, например, вести справочник персонала заказчика, то навязать вам бесплатные работы по этому справочнику будет гораздо сложнее.
То для чего система не предназначена по определению гораздо больше, чем то для чего она предназначена, и поэтому прописать в ТЗ ВСЕ для чего она не предназначена вообще не возможно.
Конечно исходя из опыта прошлых проектов вы можете включить в ТЗ самые часто встречающиеся дополнительные требования, но во первых для этого сначала нужно таки наступить на грабли и это все равно будет дырявый зонтик.
Поэтому assumptions лучше прописывать в позитивной форме. На основе знания о вашей системе.
Например для вашего случая:
«до начала использования механизма синхронизации данных небходимо провести первоначальную загрузку данных методом А»
А это прописать в Нефункциональные требования:
«подразумевается что объём ежедневной передаваемой информации для механизма синхронизации меньше 100000 записей»
С другой стороны, при наличии нормальных отношений с заказчиком, всегда можно объяснить что не нужно пытаться добиться от системы того для чего она не предназначена, даже если это формально не прописано в ТЗ. Все равно это не будет работать.
Так что ещё один важный вывод из ситцуации который нужно было сделать: Должны быть нормальные взаимоотношения с клиентом, без попыток втоптать друг друга в грязь и/или подставить на деньги.
Конечно исходя из опыта прошлых проектов вы можете включить в ТЗ самые часто встречающиеся дополнительные требования, но во первых для этого сначала нужно таки наступить на грабли и это все равно будет дырявый зонтик.
Поэтому assumptions лучше прописывать в позитивной форме. На основе знания о вашей системе.
Например для вашего случая:
«до начала использования механизма синхронизации данных небходимо провести первоначальную загрузку данных методом А»
А это прописать в Нефункциональные требования:
«подразумевается что объём ежедневной передаваемой информации для механизма синхронизации меньше 100000 записей»
С другой стороны, при наличии нормальных отношений с заказчиком, всегда можно объяснить что не нужно пытаться добиться от системы того для чего она не предназначена, даже если это формально не прописано в ТЗ. Все равно это не будет работать.
Так что ещё один важный вывод из ситцуации который нужно было сделать: Должны быть нормальные взаимоотношения с клиентом, без попыток втоптать друг друга в грязь и/или подставить на деньги.
Конечно, не надо писать в ТЗ все подряд. Вот ограничение, которое Вы указали, как нефункциональное требование, очень подходит для ТЗ. Говоря о том, для чего система не предназначена, я имел в виду набор ограничений и допущений, которые должны быть включены в ТЗ. То, что их надо прописывать в позитивной манере, очень интересное предложение. Мы обычно использовали отрицательную форму: «Система не должна ...», «Система обрабатывает не более ....».
Что касается отношений с заказчиком, то они, безусловно, должны основываться на взаимоуважении. Причем, отношение к заказчику должно быть уважительным, как при непосредственном общении с заказчиком, так и внутри проектной команды. Очень часто внутри некоторых команд приходилось слышать фразы вроде «Эти идио… (не очень умные люди) опять прислали новые требования!». У нас подобные фразы практически отсутствуют. Уважение к заказчику должно начинаться внутри проектной команды. Заказчик это чувствует.
Что касается отношений с заказчиком, то они, безусловно, должны основываться на взаимоуважении. Причем, отношение к заказчику должно быть уважительным, как при непосредственном общении с заказчиком, так и внутри проектной команды. Очень часто внутри некоторых команд приходилось слышать фразы вроде «Эти идио… (не очень умные люди) опять прислали новые требования!». У нас подобные фразы практически отсутствуют. Уважение к заказчику должно начинаться внутри проектной команды. Заказчик это чувствует.
То для чего система не предназначена по определению гораздо больше, чем то для чего она предназначена, и поэтому прописать в ТЗ ВСЕ для чего она не предназначена вообще не возможно.
Категорически не согласен.
Моя практика показывает, что метод прописывания ограничений, того, чего не будет сделано — это очень хороший метод.
Попробуйте.
Весьма компактно и надежно защищает он недопонимания заказчика и претензий.
По структуре, в само ТЗ все пихать не нужно, согласен. Но в ТЗ можно сделать ссылку на документ, в котором уже будет прописано то, что необходимо. И таким образом разбить ТЗ на составные части, которые будут удобны для восприятия.
Которое все равно потом если и будут читать — то только в случае факапа, чтобы задницу прикрыть. А это явно не та цель, для которой нужно ТЗ.Как исполнителю, ТЗ вас выручит, если заказчик начнет дурить. В принципе, сейчас оно больше всего для прикрытия пятой точки и пишется, чтобы потом не было претензий со стороны заказчика, и соответственно незапланированных трат. Часто встречаюсь с тем, что ТЗ от заказчика, не совпадает с реальными требованиями конечного пользователя, и в итоге напрямую приходится работать уже с пользователем, чтобы понять что ему нужно, и потом все подгонять под ТЗ.
Не в тему, но все же — откуда иллюстрации в статье, кто художник? Есть в них что-то сильное и тяжёлое.
По теме — упомянутая NORMA — это полностью ваша собственная разработка? С чем вы конкурируете этим продуктом?
кто художник?
Вася Ложкин
NORMA — это полностью наша разработка. Система предназначена для управления НСИ (общероссийские, ведомственные, отраслевые справочники, реестры) и основными данными компании (контрагенты, договоры, оборудование и т.п.). Конкурируем мы с другими продуктами, предназначенными для управления MDM, например, 1C MDM, SAS MDM, Oracle MDM. Кроме того, сейчас наши потенциальные заказчики начинают рассматривать вместо отдельных систем MDM продукты (наборы продуктов) класса Data Governance (управление корпоративными данными). Мы тоже смотрим в этом направлении и готовим обновления и дополнения для нашей системы.
«Мы тут все работаем на продуктах Apple, у них есть определенный стиль, а ваша система в этот стиль не вписывается. Мы ее даже рассматривать не будем».
У Apple есть продукты для автоматизации???
У Apple, конечно, нет продуктов для автоматизации. Просто у заказчика все руководство и многие менеджеры работали на компьютерах Apple, использовали планшеты и телефоны Apple. И речь шла не о функциональных возможностях системы, а об интерфейсе. У нас используется интерфейс в стиле Windows, который на интерфейс Apple не очень похож.
Прекрасные жизненные кейсы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как не сойти с ума в разработке систем управления нормативно-справочной информацией. Из истории наших проектов