Привет! Клиент поставил задачу в устной форме, это оказалась задача не на один месяц и поэтому я решил её записать и далее показать клиенту, чтобы он понимал то что мы его правильно поняли и чтобы в дальнейшем не возникло недопониманий и расхождений. Я так полагаю "Техническое задание" и "Задача в письменном виде" (если такие вообще существуют) – это абсолютно разные вещи. Собственно вопрос: где найти информацию о том, как правильно составить и в дальнейшем редактировать и согласовывать эту задачу клиентом именно на этапе постановки задачи, а не выполнения. Какую структуру документа использовать? Как разбивать на мелкие задачи? Или может быть нужно небольшое бизнес-обследование? Поиск по рунету не дал особых результатов. Поделитесь своим опытом составления описания проекта.
По теме из базы знаний
- 1С:Документооборот - цена на лицензии КОРП, ПРОФ и ДГУ
- Как оценивать задачи программисту 1С
- Конфигурация Flowcon: Набор инструментов для управления задачами, проектами и бизнесом в 1С
- Бизнес-аналитики 1С: спрос есть, но кто они?
- Гибкий подход в управлении командой проекта автоматизации для крупных компаний
Найденные решения
Доброго вечера!
"Клиент поставил задачу в устной форме" - есть вариант, что клиент не готов работать используя документы вообще. К сожалению дальнейшее общение с клиентом в таком случае скатывается в базар, я даже не рекомендую дальше упорствовать на создании какого-либо документарного оформления работ, разве лишь с целью отбиться юридически, но тогда клиент может потребовать исполнений и возвратов "В НАТУРЕ", а люди которые не смотрят в документы потому в них и не смотрят, что соответствующие возможности.
Резюмирую, если клиент не хочет понимать сложность задачи - надо как можно быстрее и как можно корректнее с ним расстаться. ИМХО.
Если же клиент готов читать документы, то имеет смысл придерживаться стандартов, чтобы не только Вы и он, но и любой, кто посмотрит этот документ сказал, что это ТЗ. Для ТЗ есть ГОСТ (на вскидку ГОСТ 34). ТЗ должно состоять из правильно структурированного массива информации:
. 1. Введение.
2. Основание для разработки.
3. Назначение разработки.
4. Требования к программе.
5. Требования к персоналу.
6. Технико – экономические показатели.
7. Стадии разработки и внедрения.
8. Порядок контроля и приемки.
Если в документе присутствуют такие главы, то ПО ФОРМЕ это уже ТЗ. Спорить с этим могут лишь те, кто применяет другие стандарты (совместные предприятия с иностранными аудиторами в сфере ИТ). Может в нем и написана чушь, но соответствие с ТЗ очевидно.
То, что Вы пишете "Задача в письменном виде" - это функциональные технические требования (ФТТ) и это (2) и это 4 согласно стандарту. Многие Заказчики могут работать исключительно имея только ФТТ и не хотят такой тяжеловесной конструкции в ТЗ. Но если у вас не описано 8, то не всегда понятно, как Вашу работу вообще можно сдать, а Заказчику соответственно принять.
Если Вы пишете Код, то это программный продукт. Тут помимо Вашего желания возникают авторские отношения причем не только между Вами и Заказчиком, но и 1С и MS и Intel/AMD до кучи, все это регулируется лицензиями и законодательством, но я не советую Вам брать на себя ответственность за работоспособность этого пирога. Лучше всего будет написать отказ от гарантий в лучших традициях лицензионных соглашений.
И, наконец, сама суть работ - несомненно в технических требованиях, а для этого хочется иметь шаблон для их разработки. После прочтения статьи на Хабре я для себя нашел Confluence.
Последнее (а на самом деле первое) - это 2 (Назначение). Если правильно отделить цели от требований, то может случиться что у Заказчика нет целей для разработки вообще. Это неприятная новость и Вам решать доносить её до Заказчика или нет.
"Клиент поставил задачу в устной форме" - есть вариант, что клиент не готов работать используя документы вообще. К сожалению дальнейшее общение с клиентом в таком случае скатывается в базар, я даже не рекомендую дальше упорствовать на создании какого-либо документарного оформления работ, разве лишь с целью отбиться юридически, но тогда клиент может потребовать исполнений и возвратов "В НАТУРЕ", а люди которые не смотрят в документы потому в них и не смотрят, что соответствующие возможности.
Резюмирую, если клиент не хочет понимать сложность задачи - надо как можно быстрее и как можно корректнее с ним расстаться. ИМХО.
Если же клиент готов читать документы, то имеет смысл придерживаться стандартов, чтобы не только Вы и он, но и любой, кто посмотрит этот документ сказал, что это ТЗ. Для ТЗ есть ГОСТ (на вскидку ГОСТ 34). ТЗ должно состоять из правильно структурированного массива информации:
. 1. Введение.
2. Основание для разработки.
3. Назначение разработки.
4. Требования к программе.
5. Требования к персоналу.
6. Технико – экономические показатели.
7. Стадии разработки и внедрения.
8. Порядок контроля и приемки.
Если в документе присутствуют такие главы, то ПО ФОРМЕ это уже ТЗ. Спорить с этим могут лишь те, кто применяет другие стандарты (совместные предприятия с иностранными аудиторами в сфере ИТ). Может в нем и написана чушь, но соответствие с ТЗ очевидно.
То, что Вы пишете "Задача в письменном виде" - это функциональные технические требования (ФТТ) и это (2) и это 4 согласно стандарту. Многие Заказчики могут работать исключительно имея только ФТТ и не хотят такой тяжеловесной конструкции в ТЗ. Но если у вас не описано 8, то не всегда понятно, как Вашу работу вообще можно сдать, а Заказчику соответственно принять.
Если Вы пишете Код, то это программный продукт. Тут помимо Вашего желания возникают авторские отношения причем не только между Вами и Заказчиком, но и 1С и MS и Intel/AMD до кучи, все это регулируется лицензиями и законодательством, но я не советую Вам брать на себя ответственность за работоспособность этого пирога. Лучше всего будет написать отказ от гарантий в лучших традициях лицензионных соглашений.
И, наконец, сама суть работ - несомненно в технических требованиях, а для этого хочется иметь шаблон для их разработки. После прочтения статьи на Хабре я для себя нашел Confluence.
Последнее (а на самом деле первое) - это 2 (Назначение). Если правильно отделить цели от требований, то может случиться что у Заказчика нет целей для разработки вообще. Это неприятная новость и Вам решать доносить её до Заказчика или нет.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Держите пример ТЗ, помимо этого вам нужен план график этапов подписанный обеими сторонами, так же лучше предварительно провести обследование на готовность инфраструктуры, наличие необходимого ПО, готовности НСИ для переноса, нюансы доработок для переноса в нову/ые конфигурацию/ии.
ТЗ как таковое всегда нужно писать, не важно внутренний вы исполнитель или внешний исполнитель, ТЗ всегда может обезопасить от нападок, что вы чего то не доделали.
ТЗ как таковое всегда нужно писать, не важно внутренний вы исполнитель или внешний исполнитель, ТЗ всегда может обезопасить от нападок, что вы чего то не доделали.
Прикрепленные файлы:
пример ТЗ.docx
Доброго вечера!
"Клиент поставил задачу в устной форме" - есть вариант, что клиент не готов работать используя документы вообще. К сожалению дальнейшее общение с клиентом в таком случае скатывается в базар, я даже не рекомендую дальше упорствовать на создании какого-либо документарного оформления работ, разве лишь с целью отбиться юридически, но тогда клиент может потребовать исполнений и возвратов "В НАТУРЕ", а люди которые не смотрят в документы потому в них и не смотрят, что соответствующие возможности.
Резюмирую, если клиент не хочет понимать сложность задачи - надо как можно быстрее и как можно корректнее с ним расстаться. ИМХО.
Если же клиент готов читать документы, то имеет смысл придерживаться стандартов, чтобы не только Вы и он, но и любой, кто посмотрит этот документ сказал, что это ТЗ. Для ТЗ есть ГОСТ (на вскидку ГОСТ 34). ТЗ должно состоять из правильно структурированного массива информации:
. 1. Введение.
2. Основание для разработки.
3. Назначение разработки.
4. Требования к программе.
5. Требования к персоналу.
6. Технико – экономические показатели.
7. Стадии разработки и внедрения.
8. Порядок контроля и приемки.
Если в документе присутствуют такие главы, то ПО ФОРМЕ это уже ТЗ. Спорить с этим могут лишь те, кто применяет другие стандарты (совместные предприятия с иностранными аудиторами в сфере ИТ). Может в нем и написана чушь, но соответствие с ТЗ очевидно.
То, что Вы пишете "Задача в письменном виде" - это функциональные технические требования (ФТТ) и это (2) и это 4 согласно стандарту. Многие Заказчики могут работать исключительно имея только ФТТ и не хотят такой тяжеловесной конструкции в ТЗ. Но если у вас не описано 8, то не всегда понятно, как Вашу работу вообще можно сдать, а Заказчику соответственно принять.
Если Вы пишете Код, то это программный продукт. Тут помимо Вашего желания возникают авторские отношения причем не только между Вами и Заказчиком, но и 1С и MS и Intel/AMD до кучи, все это регулируется лицензиями и законодательством, но я не советую Вам брать на себя ответственность за работоспособность этого пирога. Лучше всего будет написать отказ от гарантий в лучших традициях лицензионных соглашений.
И, наконец, сама суть работ - несомненно в технических требованиях, а для этого хочется иметь шаблон для их разработки. После прочтения статьи на Хабре я для себя нашел Confluence.
Последнее (а на самом деле первое) - это 2 (Назначение). Если правильно отделить цели от требований, то может случиться что у Заказчика нет целей для разработки вообще. Это неприятная новость и Вам решать доносить её до Заказчика или нет.
"Клиент поставил задачу в устной форме" - есть вариант, что клиент не готов работать используя документы вообще. К сожалению дальнейшее общение с клиентом в таком случае скатывается в базар, я даже не рекомендую дальше упорствовать на создании какого-либо документарного оформления работ, разве лишь с целью отбиться юридически, но тогда клиент может потребовать исполнений и возвратов "В НАТУРЕ", а люди которые не смотрят в документы потому в них и не смотрят, что соответствующие возможности.
Резюмирую, если клиент не хочет понимать сложность задачи - надо как можно быстрее и как можно корректнее с ним расстаться. ИМХО.
Если же клиент готов читать документы, то имеет смысл придерживаться стандартов, чтобы не только Вы и он, но и любой, кто посмотрит этот документ сказал, что это ТЗ. Для ТЗ есть ГОСТ (на вскидку ГОСТ 34). ТЗ должно состоять из правильно структурированного массива информации:
. 1. Введение.
2. Основание для разработки.
3. Назначение разработки.
4. Требования к программе.
5. Требования к персоналу.
6. Технико – экономические показатели.
7. Стадии разработки и внедрения.
8. Порядок контроля и приемки.
Если в документе присутствуют такие главы, то ПО ФОРМЕ это уже ТЗ. Спорить с этим могут лишь те, кто применяет другие стандарты (совместные предприятия с иностранными аудиторами в сфере ИТ). Может в нем и написана чушь, но соответствие с ТЗ очевидно.
То, что Вы пишете "Задача в письменном виде" - это функциональные технические требования (ФТТ) и это (2) и это 4 согласно стандарту. Многие Заказчики могут работать исключительно имея только ФТТ и не хотят такой тяжеловесной конструкции в ТЗ. Но если у вас не описано 8, то не всегда понятно, как Вашу работу вообще можно сдать, а Заказчику соответственно принять.
Если Вы пишете Код, то это программный продукт. Тут помимо Вашего желания возникают авторские отношения причем не только между Вами и Заказчиком, но и 1С и MS и Intel/AMD до кучи, все это регулируется лицензиями и законодательством, но я не советую Вам брать на себя ответственность за работоспособность этого пирога. Лучше всего будет написать отказ от гарантий в лучших традициях лицензионных соглашений.
И, наконец, сама суть работ - несомненно в технических требованиях, а для этого хочется иметь шаблон для их разработки. После прочтения статьи на Хабре я для себя нашел Confluence.
Последнее (а на самом деле первое) - это 2 (Назначение). Если правильно отделить цели от требований, то может случиться что у Заказчика нет целей для разработки вообще. Это неприятная новость и Вам решать доносить её до Заказчика или нет.
Здравствуйте!
Самая распространенная система управления проектами это REDMINE
Если нет необходимости работать с удаленными клиентами и задачи ставятся непосредственно на предприятии, то можно поставить сервер apache и установить эту бесплатную CMS в локальной сети, или если есть корпоративный сайт то подключить эту CMS в поддомене.
В системе есть все, постановка задач, контроль выполнения и так далее.
можно посмотреть демо
Самая распространенная система управления проектами это REDMINE
Если нет необходимости работать с удаленными клиентами и задачи ставятся непосредственно на предприятии, то можно поставить сервер apache и установить эту бесплатную CMS в локальной сети, или если есть корпоративный сайт то подключить эту CMS в поддомене.
В системе есть все, постановка задач, контроль выполнения и так далее.
можно посмотреть демо
Вы можете бесплатно скачать BPWIN версии 4.0. Система BPwin, пожалуй самое лучшее средство для визуального моделирования бизнес-процессов. Он позволяет наглядно представить абсолютно любой вид деятельности или структуру в виде модели, что позволит выполнить оптимизацию работы предприятия, проверить его на соответствие стандартам ISO9000, создать организационную структуру, понизить издержки, исключить ненужные функции, увеличить гибкость и эффективность.
Поддерживает наиболее применяемые процессы IDF0, IDF1, IDF3, DFD.
Поддерживает наиболее применяемые процессы IDF0, IDF1, IDF3, DFD.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот