привет, пользователь в тз пишет:

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

Какие у тебя правила для приема тз?

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

(0) Вам рано ещё об этом думать. Научитесь крутить циклы и конструировать условия.

И наймите симпатичную аналитичку, ТЗ писать и кофе носить)

(0) при приеме тз ты должен наклониться как можно ниже, глаза обязательно в пол и не поднимать их на господина. Когда ТЗ уже в руках - пятишься назад мелкими шагами до двери не выходя из поклона.

(0) ChatGPT в помощь ))

Подробности

Формирование правил приема технического задания (ТЗ) по доработкам решений на базе конфигурации 1С:Предприятие является важным этапом успешной реализации проекта. Эти правила позволяют структурировать требования заказчика, минимизировать риски недопонимания и обеспечить выполнение работ в установленные сроки и бюджет. Ниже приведены основные правила приема ТЗ:

---

### **1. Четкость формулировок**
- **Однозначность**: Все требования должны быть изложены четко и однозначно. Избегайте двусмысленных или расплывчатых формулировок.
  - Пример: Вместо "Добавить новый отчет" укажите "Добавить отчет 'Анализ продаж' с группировкой по клиентам за выбранный период".
- **Избегание общих фраз**: Не используйте неопределенные термины, такие как "быстро", "удобно", "красиво". Уточните критерии.

---

### **2. Полнота описания требований**
- **Детализация**: Каждое требование должно содержать описание:
  - Цели доработки.
  - Ожидаемого поведения системы.
  - Бизнес-процессов, которые затрагиваются.
  - Условий применения (например, роли пользователей, временные рамки).
- **Примеры входных и выходных данных**:
  - Укажите примеры данных, которые будут использоваться для работы функционала.
  - Уточните формат вывода результатов (например, таблица, график, файл).

---

### **3. Соответствие стандартам 1С**
- **Учет специфики платформы**: Требования должны быть реализуемы в рамках возможностей платформы 1С:Предприятие и выбранной конфигурации.
  - Пример: Если требуется доработка документа, уточните, будет ли это новая форма или модификация существующей.
- **Соблюдение типовых механизмов**: По возможности, требования должны соответствовать типовым механизмам 1С (например, регистры, справочники, документы). Это упрощает поддержку и обновление решения.

---

### **4. Наличие контекста**
- **Бизнес-логика**: Укажите, как новая функциональность впишется в существующие бизнес-процессы.
  - Пример: "Новый отчет необходим для анализа эффективности торговых представителей. Данные берутся из регистра накопления 'Продажи'".
- **Пользовательские роли**: Уточните, для каких ролей пользователей предназначена доработка.
- **Взаимосвязи**: Опишите, как новая функциональность взаимодействует с существующими объектами.

---

### **5. Приоритизация требований**
- **Разделение по важности**: Разделите требования на категории:
  - Критические (без которых невозможно продолжить работу).
  - Важные (влияющие на ключевые процессы).
  - Желательные (улучшающие удобство использования).
- **Последовательность реализации**: Укажите, какие требования должны быть реализованы в первую очередь.

---

### **6. Формальное оформление**
- **Структурированность**: ТЗ должно быть оформлено в виде документа с четкой структурой:
  - Введение (цель доработки).
  - Описание требований.
  - Схемы, макеты, примеры.
  - Приложения (если есть дополнительные материалы).
- **Использование шаблонов**: Рекомендуется использовать стандартные шаблоны ТЗ, принятые в вашей компании или на рынке 1С.

---

### **7. Проверка на реализуемость**
- **Техническая экспертиза**: Перед принятием ТЗ проведите техническую оценку:
  - Возможно ли реализовать требования в текущей версии конфигурации?
  - Есть ли ограничения платформы 1С?
  - Какие риски могут возникнуть при реализации?
- **Оценка трудозатрат**: Убедитесь, что сроки и бюджет согласованы с объемом работ.

---

### **8. Участие всех заинтересованных сторон**
- **Координация с заказчиком**: Убедитесь, что все требования согласованы с ключевыми пользователями и руководством заказчика.
- **Обратная связь**: Предоставьте возможность заказчику задать уточняющие вопросы или внести изменения в ТЗ до начала разработки.

---

### **9. Учет последствий доработок**
- **Поддержка обновлений**: Уточните, как доработки будут взаимодействовать с типовой конфигурацией при обновлении.
  - Пример: "Доработка должна быть совместима с будущими обновлениями типовой конфигурации".
- **Тестирование**: Укажите, какие тесты будут проведены для проверки корректности реализации.

---

### **10. Документирование изменений**
- **Фиксация требований**: После согласования ТЗ создайте его финальную версию и зафиксируйте в системе контроля версий.
- **История изменений**: Ведите журнал изменений ТЗ, если требования корректируются в процессе разработки.

---

### **Пример структуры ТЗ**
1. **Введение**:
   - Цель доработки.
   - Общее описание задачи.
2. **Описание требований**:
   - Основные функции.
   - Бизнес-процессы.
   - Примеры данных.
3. **Макеты и схемы**:
   - Эскизы интерфейсов.
   - Диаграммы бизнес-процессов.
4. **Технические требования**:
   - Версия платформы 1С.
   - Версия конфигурации.
   - Особенности интеграции.
5. **Приложения**:
   - Дополнительные материалы (макеты документов, примеры данных).

---

### **Заключение**
Правила приема ТЗ по доработкам решений на базе конфигурации 1С:Предприятие направлены на обеспечение четкости, полноты и реализуемости требований. Соблюдение этих правил позволяет минимизировать риски и повысить качество выполнения проекта.

**Ответ:** ☐ Правила приема ТЗ включают четкость формулировок, полноту описания, соответствие стандартам 1С, приоритизацию требований, формальное оформление и учет последствий доработок.

(4) даже тупой кодер по такому ТЗ сможет, скукота-скукотища

а как же митинги и ДДД (договорились договариваться дальше)?

у самурая нет цели... есть только путь и зряплата

(2) Такая подойдет ?

(0) блоксхема решает все вопросы

(1) +1

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

(9) " Никто аргументированно не докажет что это неправильно"

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

"Программа не рабоооотает" - и пока в примеры носом не натыкали, не соглашался.

В итоге сошлись на том, что постановщик ТЗ ошибся и с проверками. и с примерами.

(0) Ну, лично я не стал бы делать задачу в такой постановке.

(0) проблема в том, что "зокащек" не знает, что он хочет, пока не увидит плоды твоего труда

ясен хер - будешь переделывать/доделывать много раз :)

главное, чтобы концепция не поменялась*

(0) Если есть аналитик, который может расписать User story и Acceptance Criteria, то хорошо. Если нет, то примерно то же, но в вольном исполнении можете написать вы или заказчик в ТЗ.

(5)
А как такое тех.задание ?

Финдир присылает скриншот и приписку
-- Мультук, ну что это за херня ?

В 99% случаев и он и я понимаем, что это херня.
И что это именно херня, тоже понимаем.

В основном вопрос стоит "а почему ?"
А еще хуже "ну почему, опять ?"

(14) никогда такого не было и вот опять

на такие траблы/проблемы/инциденты вполне достаточно скриншота и приписку "срончо, срончо!"

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

(0) К кому Вы обращаетесь на "ты" в первом посте? Выглядит странно. Похоже, нейросеть спалилась!

(16) ТС цитирует пишущего ему. Все норм, это человек. Тупой правда.

(16) ты - %username% (каждый из нас то есть) - какие у тебя, %username%, правила приема тз? )))

Тоже так хочу. Можно к вам устроиться под вымышленным именем?

утащено с одного корпоративного форума

"Что должно быть в ТЗ

1.    Подробное описание проблемы. Объяснение, почему ситуация в принципе считается проблемной. Это необходимо для определения важности задачи и ее приоритета.
2.    Анализ причин вызвавших проблему. Это необходимо для определения адекватности предлагаемых мероприятий. Если предлагаемые мероприятия не устраняют причину проблемы – ТЗ, скорее всего, не будет принято.
3.    Перечень предлагаемых мероприятий. Перечень мероприятий  должен быть указан для разных сценариев. Для каждого сценария необходимо указать участников процесса, последовательность действий, перечень информации, которой участники процесса обмениваются на каждом этапе и между ними. Если необходима проверка информации (сумм, скидок, наличия договоров и т.п.) на этапах и между ними, должны быть описаны правила проверок.
4.    Все предлагаемые мероприятия должны пройти проверку на совместимость как с имеющимися замещаемыми, так и со смежными процессами, регламентами, инструкциями и т.п. При необходимости должны быть подготовлены предложения по их изменению.
5.    Необходимо наличие порядка ввода в действие новых мероприятий (или изменения старых). Должны быть предусмотрены и подготовлены инструктажи для участников процессов. Должны быть назначены ответственные за инструктирование.
6.    Необходимо наличие контрольных мероприятий, которые подтвердят устранение или уменьшение проблемы. Контрольные мероприятия окончательно определят качество подготовки ТЗ.
7.    Все предлагаемые мероприятия по всем сценариям должны пройти тестирование в ручном режиме (на бумаге, в Excel'е, в Outlook'е, иным способом), до реализации ТЗ в 1С. Процессы должны быть составлены так, что их исполнение не должно зависеть от применяемого инструмента.
8.    Предлагаемые мероприятия должны в максимально возможной мере устранять проблему с первого раза (это зависит от тщательности подготовки ТЗ, от полноты анализа возможных сценариев и степени отыгранности каждого сценария со всеми задействованными отделами). Варианты с запуском ТЗ в «тестовом» режиме с последующими многократными правками по вновь выявляемым неописанным в ТЗ ситуациям нежелательны, в силу ограниченности мировых ресурсов и невозможности под каждую задачу выделять отдельного человека."

(21) пока напишут такое ТЗ, задача перестанет быть актуальной )))

(0) Напиши по ТЗ свой вариант ТЗ, и отправь заказчику :)

(22) пока напишут такое ТЗ - задача по добавлению кнопочки на форму превратится в проект. ну и если отвалится/протухнет - еще лучше