Мне кажется, хороший системный аналитик = хороший автор текстов.
В нашей работе мы очень много пишем:
требования, документацию, ТЗ, постановки задач, письма, комментарии, минутки встреч.
Можно идеально знать UML, BPMN, SQL, интеграции и всё остальное, что требуется от аналитика,
но одной кривой формулировкой устроить команде неделю созвонов и переделок 😅
Если из описания не до конца понятно, что делать, это может раздражать коллег.
Если текст можно понять по-разному и интерпретировать по-разному, значит что-то не так и лучше ещё раз подумать над формулировкой.
Давно-давно ведущий аналитик скинул мне на ревью ТЗ. Я поняла его совсем не так, как он имел в виду. Но странной выставили меня 😅
Типа: «Ну как можно было не понять, что тут имеется в виду?»
Но тут вопрос именно к формулировкам как по мне. Я прочитала и поняла так, другой прочитает и поймёт третье. Если хоть кому-то не понятно, лучше переписать от греха подальше.
Поэтому навык письменно и однозначно формулировать мысли для аналитика очень важен.
Вот в нашей работе очень помогают форматы вроде:
«Если, то, иначе», «И, ИЛИ, НЕ».
Мне нравится использовать это для описания элементов пользовательского интерфейса. Идеально, чтобы описать, по какой логике отображать элемент, какой текст подставлять в зависимости от комбинации параметров и пр.
И, конечно, классный инструмент Use Case. У него есть структура и шаблон. Там уже многое придумано за нас, нужно просто следовать формату.
Если интересно почитать про это:
📚 Алистер Коберн «Современные методы описания функциональных требований к системе»
А чтобы описывать задачи с точки зрения пользователя, хорошо подходит формат User Story:
📚 Дж. Паттон «Пользовательские истории. Искусство гибкой разработки»
А для навыка писать лаконичнее:
📚 «Пиши, сокращай»
Мне повезло, я очень люблю писать 😄
Люблю длинные тексты, статьи, посты и рада, что в работе аналитика это так пригодилось.
Хотя знаю, что многие аналитики эту часть работы вообще не любят 😅
А вы любите писать документацию и продумывать формулировки?
💬 MAX
В нашей работе мы очень много пишем:
требования, документацию, ТЗ, постановки задач, письма, комментарии, минутки встреч.
Можно идеально знать UML, BPMN, SQL, интеграции и всё остальное, что требуется от аналитика,
но одной кривой формулировкой устроить команде неделю созвонов и переделок 😅
Если из описания не до конца понятно, что делать, это может раздражать коллег.
Если текст можно понять по-разному и интерпретировать по-разному, значит что-то не так и лучше ещё раз подумать над формулировкой.
Давно-давно ведущий аналитик скинул мне на ревью ТЗ. Я поняла его совсем не так, как он имел в виду. Но странной выставили меня 😅
Типа: «Ну как можно было не понять, что тут имеется в виду?»
Но тут вопрос именно к формулировкам как по мне. Я прочитала и поняла так, другой прочитает и поймёт третье. Если хоть кому-то не понятно, лучше переписать от греха подальше.
Поэтому навык письменно и однозначно формулировать мысли для аналитика очень важен.
Вот в нашей работе очень помогают форматы вроде:
«Если, то, иначе», «И, ИЛИ, НЕ».
Мне нравится использовать это для описания элементов пользовательского интерфейса. Идеально, чтобы описать, по какой логике отображать элемент, какой текст подставлять в зависимости от комбинации параметров и пр.
И, конечно, классный инструмент Use Case. У него есть структура и шаблон. Там уже многое придумано за нас, нужно просто следовать формату.
Если интересно почитать про это:
📚 Алистер Коберн «Современные методы описания функциональных требований к системе»
А чтобы описывать задачи с точки зрения пользователя, хорошо подходит формат User Story:
📚 Дж. Паттон «Пользовательские истории. Искусство гибкой разработки»
А для навыка писать лаконичнее:
📚 «Пиши, сокращай»
Мне повезло, я очень люблю писать 😄
Люблю длинные тексты, статьи, посты и рада, что в работе аналитика это так пригодилось.
Хотя знаю, что многие аналитики эту часть работы вообще не любят 😅
А вы любите писать документацию и продумывать формулировки?
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥16❤5👏4
Всех с первым днём лета ☀️
У кого какие планы на лето?)
У меня поездка на море, к родственникам мужа, к моим родственникам и корпоратив на работе 😊
Любая поездка означает, что нужно с кем-то оставить Норберту.
Поэтому мы отправляем её на курорт, в отель для рептилий 😏
В этом all inclusive:
🦎 свой террариум
🦎 уборка «номера»
🦎 кормёжка по привычному графику
Рацион у неё тоже расписан:
🥬 зелень и овощи
🥬 через два дня снова зелень и овощи
🦗 ещё через два дня сверчки
Сверчки - её любимый день.
Покажу потом отпускницу перед заселением 😄
У кого какие планы на лето?)
У меня поездка на море, к родственникам мужа, к моим родственникам и корпоратив на работе 😊
Любая поездка означает, что нужно с кем-то оставить Норберту.
Поэтому мы отправляем её на курорт, в отель для рептилий 😏
В этом all inclusive:
🦎 свой террариум
🦎 уборка «номера»
🦎 кормёжка по привычному графику
Рацион у неё тоже расписан:
🥬 зелень и овощи
🥬 через два дня снова зелень и овощи
🦗 ещё через два дня сверчки
Сверчки - её любимый день.
Покажу потом отпускницу перед заселением 😄
😍14❤2
Сколько раз разработчики задавали вам вопросы вроде:
* А что будет, если поле не заполнено?
* А что будет, если у пользователя другая роль?
* Из какого параметра брать значение?
* А если статус другой?
* А если выполняется только одно условие из двух?
Очень часто причина в том, что логика описана не до конца.
Чтобы не упустить детали, я почти всегда использую конструкции:
ЕСЛИ, ТО, ИНАЧЕ
И, ИЛИ, НЕ
Они помогают убрать неоднозначности и делают требования понятнее для команды.
🔵 Кнопка "Удалить заказ"
Отображается, если:
* роль пользователя входит в список ролей, которым разрешено удаление заказа (см. раздел «Роли пользователей»)
* И значение поля orderStatus НЕ входит в список:
IN_DELIVERY
DELETED
Иначе не отображается.
🔵 Кнопка "Отправить"
Активна, если:
* все обязательные поля формы заполнены и прошли валидацию (см. раздел «Форма создания заказа»)
Иначе неактивна.
🔵 Информационное сообщение по заявке
Если:
* значение поля applicationStatus = REJECTED
* И поле rejectReasonText заполнено
То отображать значение поля rejectReasonText.
Иначе отображать значение поля displayText для текущего значения applicationStatus из справочника статусов заявки (см. раздел «Статусы заявки»).
🔵 Параметр fullName
Если поле middleName заполнено
То передавать fullName = name + " " + middleName
Иначе передавать fullName = name
🔵 Статус заявки
Если:
* все обязательные поля анкеты заполнены (см. раздел «Анкета клиента»)
* И все обязательные документы загружены (см. раздел «Документы клиента»)
* И номер телефона подтверждён (phoneVerified = true)
То установитьapplicationStatus = READY_FOR_REVIEW
Иначе установить applicationStatus = DRAFT
Обратите внимание ещё на один момент.
Я специально не расписываю здесь:
* какие бывают роли
* какие бывают статусы
* какие поля обязательны
* какие документы нужно загрузить
Всё это лучше один раз подробно описать в отдельных разделах документации и дальше ссылаться на них.
Так требования проще поддерживать в актуальном состоянии и меньше риск, что в одном месте описание обновили, а в другом забыли.
Такие вещи кажутся мелочью, но именно из таких мелочей потом складывается документация, которую одинаково понимают аналитики, разработчики и тестировщики.
Кстати, на курсе «Системный аналитик с нуля до старта» мы отдельно разбираем подобные приёмы оформления требований и учимся писать требования так, чтобы у команды оставалось меньше вопросов.
А вы используете такие конструкции в своих требованиях или предпочитаете описывать логику по-другому?
* А что будет, если поле не заполнено?
* А что будет, если у пользователя другая роль?
* Из какого параметра брать значение?
* А если статус другой?
* А если выполняется только одно условие из двух?
Очень часто причина в том, что логика описана не до конца.
Чтобы не упустить детали, я почти всегда использую конструкции:
ЕСЛИ, ТО, ИНАЧЕ
И, ИЛИ, НЕ
Они помогают убрать неоднозначности и делают требования понятнее для команды.
🔵 Кнопка "Удалить заказ"
Отображается, если:
* роль пользователя входит в список ролей, которым разрешено удаление заказа (см. раздел «Роли пользователей»)
* И значение поля orderStatus НЕ входит в список:
IN_DELIVERY
DELETED
Иначе не отображается.
🔵 Кнопка "Отправить"
Активна, если:
* все обязательные поля формы заполнены и прошли валидацию (см. раздел «Форма создания заказа»)
Иначе неактивна.
🔵 Информационное сообщение по заявке
Если:
* значение поля applicationStatus = REJECTED
* И поле rejectReasonText заполнено
То отображать значение поля rejectReasonText.
Иначе отображать значение поля displayText для текущего значения applicationStatus из справочника статусов заявки (см. раздел «Статусы заявки»).
🔵 Параметр fullName
Если поле middleName заполнено
То передавать fullName = name + " " + middleName
Иначе передавать fullName = name
🔵 Статус заявки
Если:
* все обязательные поля анкеты заполнены (см. раздел «Анкета клиента»)
* И все обязательные документы загружены (см. раздел «Документы клиента»)
* И номер телефона подтверждён (phoneVerified = true)
То установитьapplicationStatus = READY_FOR_REVIEW
Иначе установить applicationStatus = DRAFT
Обратите внимание ещё на один момент.
Я специально не расписываю здесь:
* какие бывают роли
* какие бывают статусы
* какие поля обязательны
* какие документы нужно загрузить
Всё это лучше один раз подробно описать в отдельных разделах документации и дальше ссылаться на них.
Так требования проще поддерживать в актуальном состоянии и меньше риск, что в одном месте описание обновили, а в другом забыли.
Такие вещи кажутся мелочью, но именно из таких мелочей потом складывается документация, которую одинаково понимают аналитики, разработчики и тестировщики.
Кстати, на курсе «Системный аналитик с нуля до старта» мы отдельно разбираем подобные приёмы оформления требований и учимся писать требования так, чтобы у команды оставалось меньше вопросов.
А вы используете такие конструкции в своих требованиях или предпочитаете описывать логику по-другому?
1❤13👍3💯3
1🔥9👍6❤2
Вера Коновалова | Системный аналитик в IT pinned «Мои курсы по СА на Stepik 👉 Системный аналитик с нуля до старта 👉 Практикум»
Вторую неделю отпуска провожу с пользой 😄
Готовлю небольшие, но важные обновления по курсу.
Спойлер: они будут связаны с документированием. Моей любимой темой 😊
Пока пересматриваю материалы, в очередной раз убеждаюсь, сколько нюансов скрывается в хорошей документации.
Казалось бы, написал требования и готово. Но на практике именно здесь возникает множество вопросов: что описать, как описать, где дать ссылку, а где расписать логику подробнее.
Поэтому хочется сделать материал ещё полезнее и добавить то, что действительно помогает в работе каждый день.
Надеюсь, не буду сильно затягивать и в ближайшее время порадую вас обновлениями ☀️
А ещё потихонечку настраиваюсь на рабочую неделю.
Самое приятное, что после неё мне нужно будет отработать всего три недели, и начнётся следующий двухнедельный отпуск 😅
Поедем к родственникам Юры на Урал.
Всем хороших выходных ❤️
Готовлю небольшие, но важные обновления по курсу.
Спойлер: они будут связаны с документированием. Моей любимой темой 😊
Пока пересматриваю материалы, в очередной раз убеждаюсь, сколько нюансов скрывается в хорошей документации.
Казалось бы, написал требования и готово. Но на практике именно здесь возникает множество вопросов: что описать, как описать, где дать ссылку, а где расписать логику подробнее.
Поэтому хочется сделать материал ещё полезнее и добавить то, что действительно помогает в работе каждый день.
Надеюсь, не буду сильно затягивать и в ближайшее время порадую вас обновлениями ☀️
А ещё потихонечку настраиваюсь на рабочую неделю.
Самое приятное, что после неё мне нужно будет отработать всего три недели, и начнётся следующий двухнедельный отпуск 😅
Поедем к родственникам Юры на Урал.
Всем хороших выходных ❤️
❤13🔥7👍2
Кажется, впервые за долгое время мне удалось по-настоящему отключить голову.
А такое со мной бывает очень редко.
В первую неделю отпуска мы поехали в Турцию. Я решила, что эту неделю не буду думать ни о работе, ни о курсах. И как только в голове появлялись такие мысли, сознательно говорила себе: «Нет. Через неделю».
Первый день приходилось себя немного останавливать. А потом получилось отпустить.
Кажется, именно смена места и отсутствие компьютера помогают мне лучше всего.
Потому что дома обычно всё наоборот.
Закрыла рабочий ноутбук, открыла личный. И снова работа. Только уже над курсом 😄
Вроде всего семь дней отпуска, но мы успели очень много.
Четыре дня просто отдыхали в отеле и на пляже. Купались, смотрели на рыб, читали книги.
Ещё ездили гулять по Аланье, посмотрели крепость и пещеру. Поднимались в горы, были в древнем городе, который построили ещё до V века. Потрогали, кажется, каждый камень 😄
Но знаете, что мне понравилось больше всего?
Это ощущение, что никуда не нужно спешить. И при этом есть какая-то приятная предсказуемость.
Есть завтрак. Потом море. Потом обед. Потом снова море. Потом мороженое. Потом ужин. А вечером шоу.
И между этим просто живёшь, болтаешь, читаешь, смотришь на море и горы.
И спустя всего неделю я поймала себя на мысли, что мне снова захотелось что-то делать.
Вернулась в Петербург, и голова снова постепенно переключается на работу, курс и новые идеи 😊
А такое со мной бывает очень редко.
В первую неделю отпуска мы поехали в Турцию. Я решила, что эту неделю не буду думать ни о работе, ни о курсах. И как только в голове появлялись такие мысли, сознательно говорила себе: «Нет. Через неделю».
Первый день приходилось себя немного останавливать. А потом получилось отпустить.
Кажется, именно смена места и отсутствие компьютера помогают мне лучше всего.
Потому что дома обычно всё наоборот.
Закрыла рабочий ноутбук, открыла личный. И снова работа. Только уже над курсом 😄
Вроде всего семь дней отпуска, но мы успели очень много.
Четыре дня просто отдыхали в отеле и на пляже. Купались, смотрели на рыб, читали книги.
Ещё ездили гулять по Аланье, посмотрели крепость и пещеру. Поднимались в горы, были в древнем городе, который построили ещё до V века. Потрогали, кажется, каждый камень 😄
Но знаете, что мне понравилось больше всего?
Это ощущение, что никуда не нужно спешить. И при этом есть какая-то приятная предсказуемость.
Есть завтрак. Потом море. Потом обед. Потом снова море. Потом мороженое. Потом ужин. А вечером шоу.
И между этим просто живёшь, болтаешь, читаешь, смотришь на море и горы.
И спустя всего неделю я поймала себя на мысли, что мне снова захотелось что-то делать.
Вернулась в Петербург, и голова снова постепенно переключается на работу, курс и новые идеи 😊
❤11🔥4👍2
Добавила в курс новый урок 🥳
Он называется «От макета к требованиям: пишем документацию к UI».
В нём на примере страницы оформления заказа в ресторане показываю, как можно оформить документацию к пользовательскому интерфейсу.
Разбираю:
🔵 описание формы для заполнения данных
🔵 отображение данных, полученных с бэкенда
🔵 статичный текст
🔵 динамический текст, который зависит от параметров и бизнес-логики
🔵 вызовы с фронтенда: когда и какие запросы должны выполняться
🔵 логику отображения элементов
🔵 как не дублировать информацию и правильно связывать разделы документации между собой
И самое главное, показываю, как объединить всё это в одной документации, чтобы её было удобно читать, поддерживать и дорабатывать.
Сейчас продолжаю развивать этот же пример.
Следующим уроком покажу, как эту документацию можно дополнить Use Case. Всё будет на том же примере. Хочу показать, как разные артефакты могут дополнять друг друга и в каких случаях это имеет смысл.
Он называется «От макета к требованиям: пишем документацию к UI».
В нём на примере страницы оформления заказа в ресторане показываю, как можно оформить документацию к пользовательскому интерфейсу.
Разбираю:
🔵 описание формы для заполнения данных
🔵 отображение данных, полученных с бэкенда
🔵 статичный текст
🔵 динамический текст, который зависит от параметров и бизнес-логики
🔵 вызовы с фронтенда: когда и какие запросы должны выполняться
🔵 логику отображения элементов
🔵 как не дублировать информацию и правильно связывать разделы документации между собой
И самое главное, показываю, как объединить всё это в одной документации, чтобы её было удобно читать, поддерживать и дорабатывать.
Сейчас продолжаю развивать этот же пример.
Следующим уроком покажу, как эту документацию можно дополнить Use Case. Всё будет на том же примере. Хочу показать, как разные артефакты могут дополнять друг друга и в каких случаях это имеет смысл.
🔥17❤3👍2