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

По второй такой же простой список, где искать информацию: интернет, статьи, коллени итп

Был бы у тебя супер-список, ты бы сам его продавал :)

Я сомневаюсь в его качестве. Жалко 100$ на проверку

На самом деле там всё, что нужно: и личные связи, и где искать, и как искать, и вообще что делать. Серебряной пули нет. @Miriy08

По сути, да

Я бы плясал от доменной модели. А выход на неизвестные сущности через ассоциации и случайные упоминания

На точке сборки поэксперементируем

Может и нет, но я думаю не только у меня возникли такие вопросы.

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

Могут быть требования к детализации, например не менее 0.5 и не более 2 часов на одну запись. Могут быть жёсткие ограничения на овертайм, например физически нельзя отметить больше 8 часов. Может быть выстроена структура отметки, в зависимости от проектов и нельзя отметиться на проект, если ты на него не заассайнен. Могут быть даже таски для отметки заведены, чтобы выбирать, либо можно вводить вручную. И так далее

Всем привет!

Немного поделюсь своими граблями.

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

И всё было нормально, пока проекты были более-менее короткими (до 3-4 месяцев). Но тут добавился проект, длительностью в 10 месяцев + фазированием и началось веселье:
1. В зависимости от фаз начали часто меняться правила бизнес-валидации у различных функций (например сперва было ограничение на тестовую эксплуатацию, потом было расширено, а потом и вовсе снято).
2. Частенько нужно было на встречах или у себя в голове описывать существующие на текущий момент ограничения и их flow - когда наложены, кем, зачем, когда уйдут, поменяются ли, и т.д.

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

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

Решение:

Есть общая таблица бизнес-ограничений на проект. Поля:
- Группа - ограничения группируются по объектам, на которые действуют, чтобы было проще дать быстрый ответ, что и как ограничивает, например, входящий заказ.
- ID
- Описание
- Причина установки
- Стейкхолдер
- Статус ограничения

Есть в конкретных местах алгоритма бизнес-валидация. Поля:
- Действия системы (что должна сделать система, чтобы провести бизнес-валидацию);
- Поведение системы (кейсы, которые будут выполнены по результатам бизнес-валидации);
- Текст ошибки;
- Номер ошибки (опционально);
- Ссылка на идентификатор требования в таблице бизанес-ограничений;
- Текущий статус ограничения (active, deactivated, cancelled);
- Причина выставления статуса и причина/триггер возврата ограничения в работу;
- Дата изменения статуса - туда же моно и линковать таску, если есть.

Ну вот, теперь осталось только придерживаться принципа, при котором любые бизнес-огранчиения в таблице должны быть явно прописаны в и слинкованы в описании алгоримов ТЗ. Теперь можно быстро ориентироваться в том, как и что ограничивается.
Можно понять предпосылки ограничения, найти заказчика, понять в каком он сейчас статусе, поменять статус и указать причину и триггер возврата.

Надеюсь кому-то будет интересным. Но 100% правильность пока ещё не претендую, метод пока испытывается.

Посмотрите, может это поможет http://analystdays.com/ru/talk/71933

Спасибо

Вот ещё, пож другим соусом, но о том же https://2019.secrus.org/program/submitted-presentations/analyst-on-presale-notes-practice/

Message from самая та deleted. Reason: button (?)

Анна, добрый день!
А можете, пожалуйста, подсказать юридическое название компании- организатора конференции для корпоративной заявки на обучение?