Работа системного аналитика заключается не только в понимании данных и архитектуры хранилища или умении писать и оптимизировать sql-запросы. Важную часть работы занимает общение со всеми сторонами процессов и написание грамотной документации.
Техническое задание (ТЗ) — важнейший документ в работе системного аналитика. В реальном мире заказчики редко приходят с чётким пониманием что и как они хотят получить, часто их требования звучат как "найди чёрную кошку в чёрной комнате", и будет хорошо, если известно, что нужно найти именно кошку 😄
Поэтому очень важно ещё на старте выяснить, описать, зафиксировать и согласовать все пожелания заказчика. Это ответственный момент в работе, так как некорректно собранные требования приведут к потери времени команды, срыву сроков и сорванным планам заказчика, в лучшем случае. Для команды же плюсом будет чёткое понимание задачи и возможность избежать ситуаций "мы так не договаривались".
Согласованная документация — всегда win-win история.
Поэтому я всегда топлю за структурированную, понятную всем сторонам, однозначную, согласованную и непротиворечивую, полную документацию. Да, этот процесс занимает время и иногда кажется, что он бессмысленен ("тут задача на пару часов, просто напишу инженеру в личку"). Но в любых процессах всплывают подводные камни и всегда лучше "подстелить соломку". Плюс в большой компании в любой момент времени может уйти один из сотрудников, участвующих в процессе. И вот уже не сыскать концов почему именно так был реализован тот или иной процесс, для какой бизнес-цели и кто является заинтересованной стороной.
Хорошая документация — не просто обязанность, а инвестиция в будущее проектов.
#документация
Техническое задание (ТЗ) — важнейший документ в работе системного аналитика. В реальном мире заказчики редко приходят с чётким пониманием что и как они хотят получить, часто их требования звучат как "найди чёрную кошку в чёрной комнате", и будет хорошо, если известно, что нужно найти именно кошку 😄
Поэтому очень важно ещё на старте выяснить, описать, зафиксировать и согласовать все пожелания заказчика. Это ответственный момент в работе, так как некорректно собранные требования приведут к потери времени команды, срыву сроков и сорванным планам заказчика, в лучшем случае. Для команды же плюсом будет чёткое понимание задачи и возможность избежать ситуаций "мы так не договаривались".
Согласованная документация — всегда win-win история.
Поэтому я всегда топлю за структурированную, понятную всем сторонам, однозначную, согласованную и непротиворечивую, полную документацию. Да, этот процесс занимает время и иногда кажется, что он бессмысленен ("тут задача на пару часов, просто напишу инженеру в личку"). Но в любых процессах всплывают подводные камни и всегда лучше "подстелить соломку". Плюс в большой компании в любой момент времени может уйти один из сотрудников, участвующих в процессе. И вот уже не сыскать концов почему именно так был реализован тот или иной процесс, для какой бизнес-цели и кто является заинтересованной стороной.
Хорошая документация — не просто обязанность, а инвестиция в будущее проектов.
#документация
Доки должны быть качественными
Ранее я писала о важности документации, теперь пришло время поговорить о её качестве. Очевидно, что не вся документация хорошая и полезная. Чем более запутано и неструктурированно написан документ, тем больше проблем он принесёт при реализации.
При написании доков можно следовать чек-листу из требований к качеству.
Свойства хорошей документации:
☑ Осуществимость
☑ Полнота
☑ Краткость
☑ Непротиворечивость
☑ Атомарность
☑ Однозначность
☑ Понятность
☑ Приоритизированность
☑ Тестируемость
В следующих публикациях раскрою каждое из этих свойств подробнее.
#документация
Ранее я писала о важности документации, теперь пришло время поговорить о её качестве. Очевидно, что не вся документация хорошая и полезная. Чем более запутано и неструктурированно написан документ, тем больше проблем он принесёт при реализации.
При написании доков можно следовать чек-листу из требований к качеству.
Свойства хорошей документации:
☑ Осуществимость
☑ Полнота
☑ Краткость
☑ Непротиворечивость
☑ Атомарность
☑ Однозначность
☑ Понятность
☑ Приоритизированность
☑ Тестируемость
В следующих публикациях раскрою каждое из этих свойств подробнее.
#документация
Качества документации: ТЗ должно быть полным, но кратким
Всем известна фраза "краткость — сестра таланта" и она отлично ложится на написание документации. Сплошную стену текста одним абзацем с пространными рассуждениями никто читать не будет или будет, но по диагонали и крайне невнимательно. Что обязательно скажется на скорости и качестве разработки, либо её поддержке.
Всегда цените своё время и время коллег.
ТЗ должно содержать минимум воды, только технические факты. Но шутка в том, что писать кратко =/= писать мало. В ТЗ не должно быть моментов "а вот это итак очевидно, указывать не буду". То, что очевидно сегодня, будет никому неизвестно завтра, когда придёт другой сотрудник или что-то просто забудется.
Поэтому важно соблюдать баланс между многабукаф и "ничего не понятно".
Лайфхаки:
— Проработайте шаблоны под типичные для компании типы ТЗ.
— Логику процессов прописывайте пошаговым списком.
— Вместо текста, там где это возможно, используйте таблицы, графики, майнд-карты.
— При написании ТЗ ставьте себя на место разработчика. Всё ли вам понятно?
— Используйте заголовки и оглавление.
— Выделяйте важный текст и не бойтесь подчеркиваний. Но без фанатизма. Система выделений и цветов не должна пестрить и должна быть понятной.
— Дописав, сделайте паузу на чай и/или другую задачу. Вернитесь и перечитайте.
#документация
Всем известна фраза "краткость — сестра таланта" и она отлично ложится на написание документации. Сплошную стену текста одним абзацем с пространными рассуждениями никто читать не будет или будет, но по диагонали и крайне невнимательно. Что обязательно скажется на скорости и качестве разработки, либо её поддержке.
Всегда цените своё время и время коллег.
ТЗ должно содержать минимум воды, только технические факты. Но шутка в том, что писать кратко =/= писать мало. В ТЗ не должно быть моментов "а вот это итак очевидно, указывать не буду". То, что очевидно сегодня, будет никому неизвестно завтра, когда придёт другой сотрудник или что-то просто забудется.
Поэтому важно соблюдать баланс между многабукаф и "ничего не понятно".
Лайфхаки:
— Проработайте шаблоны под типичные для компании типы ТЗ.
— Логику процессов прописывайте пошаговым списком.
— Вместо текста, там где это возможно, используйте таблицы, графики, майнд-карты.
— При написании ТЗ ставьте себя на место разработчика. Всё ли вам понятно?
— Используйте заголовки и оглавление.
— Выделяйте важный текст и не бойтесь подчеркиваний. Но без фанатизма. Система выделений и цветов не должна пестрить и должна быть понятной.
— Дописав, сделайте паузу на чай и/или другую задачу. Вернитесь и перечитайте.
#документация
Качества документации: непротиворечивость
Продолжим говорить о качествах документации. До этого мы рассмотрели краткость и полноту, сегодня поговорим о непротиворечивости.
ТЗ и Соглашения не должны противоречить ни другим требованиям внутри проекта, ни самим себе. Если в начале документа мы говорим "сделай так", а в конце "сделай эдак", или в одном документе указываем что поле содержит данные Х (например, дату возврата товара), а в другом это же поле содержит данные У (н-р, дату возврата денег клиенту) — ничего хорошего от данных мы в итоге не получим.
Ещё один простой пример: в ТЗ указано время обновления витрины раз в сутки, в jira требование — "обновление раз в 15 минут", какой результат ожидать от инженера? Будет круто, если он придёт за уточнением, но это бывает не всегда. Плюс время потраченное на разбирательства явно можно использовать более эффективно.
Второй пример, в компании "Рога и копыта" было решено все даты в хранилище хранить в UTC, это было зафиксировано в соглашении "Обработка часовых поясов". По прошествии лет, после некоторой ротации сотрудников об этом регламенте было забыто. И новый аналитик реализует загрузку данных в хранилище в местном времени, затем на основе старых и новых данных строятся аналитические отчёты. О каком качестве полученной информации мы можем говорить?
Конечно, проект — живой организм и в реальности часто получается так, что соглашения изменились, но исправились только в одном месте (или вообще нет), затем пришёл новый сотрудник, который не смог разобраться где правда, и решил мести новой метлой. Но в будущем такой подход приведёт к потере доверия к данным, что в свою очередь сделает хранилище малопригодным для принятия важных бизнес-решений.
Что делать? Ревью, ревью и ещё раз ревью. Как самостоятельные, так и проводимые другими аналитиками.
Второй момент — поддержание документации (как минимум основных соглашений) в актуальном и консистентном состоянии. Да, это требует усилий, времени и внимания, но они окупятся в будущем.
Важно подчеркнуть, что даже наличие качественной документации не гарантирует отсутствия тех или иных ошибок. Если документация слишком объемная, сложная для понимания или спрятана в недрах проекта так, что о ней никто не знает, то толку от неё будет мало🥂
#документация
Продолжим говорить о качествах документации. До этого мы рассмотрели краткость и полноту, сегодня поговорим о непротиворечивости.
ТЗ и Соглашения не должны противоречить ни другим требованиям внутри проекта, ни самим себе. Если в начале документа мы говорим "сделай так", а в конце "сделай эдак", или в одном документе указываем что поле содержит данные Х (например, дату возврата товара), а в другом это же поле содержит данные У (н-р, дату возврата денег клиенту) — ничего хорошего от данных мы в итоге не получим.
Ещё один простой пример: в ТЗ указано время обновления витрины раз в сутки, в jira требование — "обновление раз в 15 минут", какой результат ожидать от инженера? Будет круто, если он придёт за уточнением, но это бывает не всегда. Плюс время потраченное на разбирательства явно можно использовать более эффективно.
Второй пример, в компании "Рога и копыта" было решено все даты в хранилище хранить в UTC, это было зафиксировано в соглашении "Обработка часовых поясов". По прошествии лет, после некоторой ротации сотрудников об этом регламенте было забыто. И новый аналитик реализует загрузку данных в хранилище в местном времени, затем на основе старых и новых данных строятся аналитические отчёты. О каком качестве полученной информации мы можем говорить?
Конечно, проект — живой организм и в реальности часто получается так, что соглашения изменились, но исправились только в одном месте (или вообще нет), затем пришёл новый сотрудник, который не смог разобраться где правда, и решил мести новой метлой. Но в будущем такой подход приведёт к потере доверия к данным, что в свою очередь сделает хранилище малопригодным для принятия важных бизнес-решений.
Что делать? Ревью, ревью и ещё раз ревью. Как самостоятельные, так и проводимые другими аналитиками.
Второй момент — поддержание документации (как минимум основных соглашений) в актуальном и консистентном состоянии. Да, это требует усилий, времени и внимания, но они окупятся в будущем.
Важно подчеркнуть, что даже наличие качественной документации не гарантирует отсутствия тех или иных ошибок. Если документация слишком объемная, сложная для понимания или спрятана в недрах проекта так, что о ней никто не знает, то толку от неё будет мало
#документация
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Принцип DRY при написании документации
В разработке принцип "Не повторяйся" (Don't Repeat Yourself, DRY) является одним из ключевых для эффективности и качества итогового продукта. Его же можно использовать и в подготовке документации.
Основной смысл: каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы.
Согласитесь, очень часто мы забываем и о системе (концентрируясь лишь на единственной его части), и о непротиворечивости (правим доки в одном месте и забываем о других).
Мои советы по использованию этого принципа:
1. Внедрение шаблонов
Большинство документов подлежит стандартизации. Используйте шаблоны не только для сокращения бесполезного труда, но и для систематизации. Хорошо структурированный документ всегда понятнее и чаще всего оставляет меньше простора для явных ошибок.
2. Использование ссылок
Вместо дублирования информации, старайтесь использовать ссылки на уже существующие материалы. Тогда и исправлять придётся не по всему пространству, и концы найти будет проще.
3. Контроль версий
Системы контроля версий актуальны не только для кода и разработки, но и для поддержания информации в актуальном виде — мы всегда можем "откатиться" к старой версии или понять кто, что и когда изменял (и пойти к этому человеку с вопросами). Сейчас контроль версий есть в большинстве систем для работы с информацией (Notion, Confluence, Google Docs, etc).
Ключ к хорошей документации — в постоянном стремлении к упрощению и оптимизации процесса её написания. В конце концов, некачественная документация столь же бесполезна, как и её полное отсутствие.
#документация
В разработке принцип "Не повторяйся" (Don't Repeat Yourself, DRY) является одним из ключевых для эффективности и качества итогового продукта. Его же можно использовать и в подготовке документации.
Основной смысл: каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы.
Согласитесь, очень часто мы забываем и о системе (концентрируясь лишь на единственной его части), и о непротиворечивости (правим доки в одном месте и забываем о других).
Мои советы по использованию этого принципа:
1. Внедрение шаблонов
Большинство документов подлежит стандартизации. Используйте шаблоны не только для сокращения бесполезного труда, но и для систематизации. Хорошо структурированный документ всегда понятнее и чаще всего оставляет меньше простора для явных ошибок.
2. Использование ссылок
Вместо дублирования информации, старайтесь использовать ссылки на уже существующие материалы. Тогда и исправлять придётся не по всему пространству, и концы найти будет проще.
3. Контроль версий
Системы контроля версий актуальны не только для кода и разработки, но и для поддержания информации в актуальном виде — мы всегда можем "откатиться" к старой версии или понять кто, что и когда изменял (и пойти к этому человеку с вопросами). Сейчас контроль версий есть в большинстве систем для работы с информацией (Notion, Confluence, Google Docs, etc).
Ключ к хорошей документации — в постоянном стремлении к упрощению и оптимизации процесса её написания. В конце концов, некачественная документация столь же бесполезна, как и её полное отсутствие.
#документация
🔥2❤1
Управление документацией: превращаем хаос в порядок
Мы много говорили о том, как писать документацию. Пора рассмотрет, как можно обеспечить удобное хранение и использование.
Ещё не так давно никто знать не знал о системах управления документацией и чаще всего все использовали Word (кучи файлов на сетевом диске) или Google Docs. Минус такого подхода очевиден: проблемы с поиском, навигацией и версионностью. Важна доступность, а не просто наличие документов.
Системы управления документацией, такие как Confluence и Notion, представляют собой комплексные платформы, позволяющие создавать, организовывать и делиться знаниями. Они обеспечивают не только хранение документов, но и управление проектами, интеграцию с другими сервисами и поддержку совместной работы. Уже сложно представить работу современной компании без общей базы знаний.
Confluence, часть экосистемы Atlassian, идеален для технических команд, которым нужны мощные функции для создания сложной документации и управления знаниями. Он предлагает интеграцию с JIRA и Bitbucket, что упрощает трекинг задач и управление кодом.
Notion выделяется своей универсальностью, гибкостью по доступной цене (плюс есть бесплатные версии). Он позволяет комбинировать заметки, базы знаний, канбан-доски и документы в одном месте. Это отличный выбор для маленьких и средних команд, которым нужен один инструмент для всего.
Выбирайте инструмент, исходя из нужд команды, важности интеграции с другими сервисами и предпочтений в работе друг с другом. Confluence идеален для крупных проектов, Notion — для гибкой работы над разнообразными задачами в командах малого и среднего размеров. Google Docs я предпочитаю использовать в случаях крайней необходимости. Место для хранения знаний должно быть централизованным.
Но внедрение системы управления документацией — это лишь первый шаг к доступности знаний. Самое сложное впереди — организация понятного пространства, создание удобных шаблонов (для ускорения и упрощения работы) и прочее-прочее-прочее.
#документация
Мы много говорили о том, как писать документацию. Пора рассмотрет, как можно обеспечить удобное хранение и использование.
Ещё не так давно никто знать не знал о системах управления документацией и чаще всего все использовали Word (кучи файлов на сетевом диске) или Google Docs. Минус такого подхода очевиден: проблемы с поиском, навигацией и версионностью. Важна доступность, а не просто наличие документов.
Системы управления документацией, такие как Confluence и Notion, представляют собой комплексные платформы, позволяющие создавать, организовывать и делиться знаниями. Они обеспечивают не только хранение документов, но и управление проектами, интеграцию с другими сервисами и поддержку совместной работы. Уже сложно представить работу современной компании без общей базы знаний.
Confluence, часть экосистемы Atlassian, идеален для технических команд, которым нужны мощные функции для создания сложной документации и управления знаниями. Он предлагает интеграцию с JIRA и Bitbucket, что упрощает трекинг задач и управление кодом.
Notion выделяется своей универсальностью, гибкостью по доступной цене (плюс есть бесплатные версии). Он позволяет комбинировать заметки, базы знаний, канбан-доски и документы в одном месте. Это отличный выбор для маленьких и средних команд, которым нужен один инструмент для всего.
Выбирайте инструмент, исходя из нужд команды, важности интеграции с другими сервисами и предпочтений в работе друг с другом. Confluence идеален для крупных проектов, Notion — для гибкой работы над разнообразными задачами в командах малого и среднего размеров. Google Docs я предпочитаю использовать в случаях крайней необходимости. Место для хранения знаний должно быть централизованным.
Но внедрение системы управления документацией — это лишь первый шаг к доступности знаний. Самое сложное впереди — организация понятного пространства, создание удобных шаблонов (для ускорения и упрощения работы) и прочее-прочее-прочее.
#документация
❤1
Как писать документацию, которую захотят читать
Натолкнулась на хорошую статью "Как написать код, который полюбят все", с которой рекомендовала бы познакомиться каждому.
Для меня же отдельная польза в том, что её практики прекрасно ложатся не только на написание кода, но и на любую документацию.
Давайте выделим основные принципы, которые сделают доки понятными и полезными:
1. Читаемость и компактность. Текст должен быть кратким и понятным. В инструкции "Открыть терминал. Ввести команду Х" звучит лучше, чем "Запустите командную строку и выполните следующую последовательность действий". Чуть полнее этот тезис я раскрывала в посте "ТЗ должно быть полным, но кратким".
2. Структура. Документация должна быть структурированной. Используем заголовки, подзаголовки и списки. Если есть несколько разделов, обязательно добавляем в начало оглавление. Читатель сразу увидит, где искать нужную информацию.
3. Выразительность. Пишем просто и ясно. Избегаем сложных терминов, если в этом нет необходимости. Если нужно использовать сложные термины, обязательно объясняем их. Так читатель не запутается.
4. Конкретность. Используем конкретные примеры. Это помогает лучше понять написанное. Например, если объясняем, как подключиться к базе данных, приводим примеры кода и скриншоты. Это лучше, чем абстрактное описание.
5. Последовательность. Нужно быть последовательным в использовании терминов и обозначений. Например, если в одном месте пишем "сервис", а в другом "служба", это может сбить с толку. Всегда используем одно и то же слово для одного и того же понятия.
6. Комментирование. Не забываем про комментарии. Хорошие комментарии помогут понять сложные моменты. Например, если есть сложный кусок кода, объясняем, что он делает (а не ждём, что читающий с одного беглого взгляда всё поймёт). Это сэкономит время читателю.
7. Обновляемость. Важно регулярно обновлять документацию. Устаревшая информация может привести к ошибкам. Нет ничего хуже, чем протухшее описание логики витрин или некорректные инструкции по подключению. Для сохранения истории используем контроль версий.
8. Визуализация. Добавляем схемы, диаграммы, скриншоты. Визуальные элементы помогают лучше понять информацию. Например, если есть сложная архитектура системы, добавляем схему. Это лучше, чем длинное, запутанное текстовое описание.
9. Инструменты. Используем инструменты для написания документации. Это могут быть редакторы с поддержкой разметки, системы контроля версий и/или платформы для совместной работы. Чуть подробнее об инструментах я писала здесь.
Следуя этим простым принципам, документация станет в разы более полезной и удобной.
#документация
Натолкнулась на хорошую статью "Как написать код, который полюбят все", с которой рекомендовала бы познакомиться каждому.
Для меня же отдельная польза в том, что её практики прекрасно ложатся не только на написание кода, но и на любую документацию.
Давайте выделим основные принципы, которые сделают доки понятными и полезными:
1. Читаемость и компактность. Текст должен быть кратким и понятным. В инструкции "Открыть терминал. Ввести команду Х" звучит лучше, чем "Запустите командную строку и выполните следующую последовательность действий". Чуть полнее этот тезис я раскрывала в посте "ТЗ должно быть полным, но кратким".
2. Структура. Документация должна быть структурированной. Используем заголовки, подзаголовки и списки. Если есть несколько разделов, обязательно добавляем в начало оглавление. Читатель сразу увидит, где искать нужную информацию.
3. Выразительность. Пишем просто и ясно. Избегаем сложных терминов, если в этом нет необходимости. Если нужно использовать сложные термины, обязательно объясняем их. Так читатель не запутается.
4. Конкретность. Используем конкретные примеры. Это помогает лучше понять написанное. Например, если объясняем, как подключиться к базе данных, приводим примеры кода и скриншоты. Это лучше, чем абстрактное описание.
5. Последовательность. Нужно быть последовательным в использовании терминов и обозначений. Например, если в одном месте пишем "сервис", а в другом "служба", это может сбить с толку. Всегда используем одно и то же слово для одного и того же понятия.
6. Комментирование. Не забываем про комментарии. Хорошие комментарии помогут понять сложные моменты. Например, если есть сложный кусок кода, объясняем, что он делает (а не ждём, что читающий с одного беглого взгляда всё поймёт). Это сэкономит время читателю.
7. Обновляемость. Важно регулярно обновлять документацию. Устаревшая информация может привести к ошибкам. Нет ничего хуже, чем протухшее описание логики витрин или некорректные инструкции по подключению. Для сохранения истории используем контроль версий.
8. Визуализация. Добавляем схемы, диаграммы, скриншоты. Визуальные элементы помогают лучше понять информацию. Например, если есть сложная архитектура системы, добавляем схему. Это лучше, чем длинное, запутанное текстовое описание.
9. Инструменты. Используем инструменты для написания документации. Это могут быть редакторы с поддержкой разметки, системы контроля версий и/или платформы для совместной работы. Чуть подробнее об инструментах я писала здесь.
Следуя этим простым принципам, документация станет в разы более полезной и удобной.
#документация
Библиотека программиста
Как написать код, который полюбят все
Набор практик хорошего кода, не зависящих от языка программирования. Примените их, и ваш код будет не только работать, но и читаться.
❤1
Системный анализ: от хаоса к пониманию через качественные требования
На Хабре вышла неплохая, но немного хаотичная статья про важность качественных требований в системном анализе и их влияние на итоговый продукт. Ведь работа системного аналитика — это не только понимание данных, архитектуры хранилища и умение писать SQL-запросы. Немалую часть времени занимает общение со всеми участниками процессов и создание грамотной документации.
Техническое задание — один из ключевых документов в работе системного аналитика. Бизнес-заказчики редко приходят с кристально ясным видением своей идеи. Задача аналитика — превратить эти размытые образы в четкий план действий.
Процесс сбора и уточнения требований — это настоящее искусство. Оно требует терпения, внимательности и умения задавать правильные вопросы. Каждый упущенный нюанс может обернуться часами лишней работы или, что еще хуже, разочарованием заказчика.
Четкие требования — основа успешного проекта.
В статье же раскрыты такие важные моменты при работе с требованиями, как:
1. Цель аналитика: обеспечить удовлетворенность конечного пользователя через точные и понятные требования.
2. Качество требований: что такое качество и как его можно повысить для улучшения требований.
3. Типы мышления: какие из них своейственны для системного аналитика.
4. Важность ясности мышления и его развития.
5. Роль саморевью: постоянное саморевью и ревью коллег для улучшения требований.
6. Обратная связь: активное взаимодействие с коллегами и заказчиками для уточнения и улучшения требований.
В статье подчёркивается: для повышения качества своей работы, системному аналитику стоит развивать различные типы мышления, следить за своим состоянием и практиковать управление знаниями.
Сочетание ясного мышления и умения формулировать четкие требования — это не просто профессиональные навыки, а настоящее искусство. С их помощью можно гораздо легче создавать продукты и формировать процессы, которые радуют пользователей и приносят пользу бизнесу.
#системный_анализ #документация
На Хабре вышла неплохая, но немного хаотичная статья про важность качественных требований в системном анализе и их влияние на итоговый продукт. Ведь работа системного аналитика — это не только понимание данных, архитектуры хранилища и умение писать SQL-запросы. Немалую часть времени занимает общение со всеми участниками процессов и создание грамотной документации.
Техническое задание — один из ключевых документов в работе системного аналитика. Бизнес-заказчики редко приходят с кристально ясным видением своей идеи. Задача аналитика — превратить эти размытые образы в четкий план действий.
Процесс сбора и уточнения требований — это настоящее искусство. Оно требует терпения, внимательности и умения задавать правильные вопросы. Каждый упущенный нюанс может обернуться часами лишней работы или, что еще хуже, разочарованием заказчика.
Четкие требования — основа успешного проекта.
В статье же раскрыты такие важные моменты при работе с требованиями, как:
1. Цель аналитика: обеспечить удовлетворенность конечного пользователя через точные и понятные требования.
2. Качество требований: что такое качество и как его можно повысить для улучшения требований.
3. Типы мышления: какие из них своейственны для системного аналитика.
4. Важность ясности мышления и его развития.
5. Роль саморевью: постоянное саморевью и ревью коллег для улучшения требований.
6. Обратная связь: активное взаимодействие с коллегами и заказчиками для уточнения и улучшения требований.
В статье подчёркивается: для повышения качества своей работы, системному аналитику стоит развивать различные типы мышления, следить за своим состоянием и практиковать управление знаниями.
Сочетание ясного мышления и умения формулировать четкие требования — это не просто профессиональные навыки, а настоящее искусство. С их помощью можно гораздо легче создавать продукты и формировать процессы, которые радуют пользователей и приносят пользу бизнесу.
#системный_анализ #документация
❤1
Недавно столкнулась с хейтом к этому посту. Комментатор возмущался, что "понаберут с улицы" и "как вообще может быть связаны ТЗ и sql". Вот что случается, когда смотришь на мир слишком узко и сталкиваешься с вещами вне своей специфики.
Связь, на самом деле, очевидна, если понимать, как работают процессы в хранилище данных. ТЗ описывает не только саму задачу, но и контекст: что именно нужно сделать, с какими ограничениями и какие бизнес-требования лежат в основе (т.е. зачем вообще мы это делаем, согласитесь – важное понимание). SQL, в свою очередь, — это лишь один из возможных инструментов реализации описанного в ТЗ.
Безусловно, есть компании и команды, где просто физически нет возможности (а порой и необходимости, если всё делает 1 человек) писать ТЗ. Но у нас в хранилище этот процесс работает чётко: крупные задачи передаются от системных аналитиков дата-инженерам именно через ТЗ. Мы продумываем решение, экспериментируем, описываем его и только потом передаём на реализацию.
Речь не о каких-то мелких правках, а о чём-то более масштабном. Например, о загрузке данных с новых источников новым методом (у нас дата-инженеры занимаются только разработкой, без исследования самих данных) или доработке текущих и разработке новых фреймворков.
К примеру, при подключении нового API-источника системный аналтик сначала анализирует, как меняются данные со временем, какие поля обязательны, какими методами забирать те или иные сущности, какие ограничения накладывает сам API, и где могут возникнуть потенциальные проблемы. После этого он описывает метод загрузки сущностей в виде ТЗ и передёт его (после ревью, конечно) дата-инженерам, которые уже занимаются разработкой технической части: настройкой пайплайнов, написанием ETL-скриптов, внедрением методов обработки и трансформации. Т.е. реализацией.
И вот здесь я вижу огромную ценность доступной и поддерживаемой документации. Говорю это, исходя из своего опыта. Сейчас мне приходится работать с горой незадокументированного легаси, которое создавалось годами в условиях ограниченных ресурсов, правилось ASAP-требованиями и чаще всего не имеет описаний ни в коде, ни документации. Даже скромное ТЗ на этапе разработки, могло бы помочь понять, какие изменения вносились и зачем. Теперь же приходится тратить время (очень много времени) на разбор неочевидных решений.
Моё имхо: без документации слишком много зависит от устных договорённостей. Это не отслеживаемо, не поддерживаемо и не безопасно — т.е. огромный риск, особенно если кто-то из ключевых сотрудников покинет проект.
А как у вас? Есть ли в вашей компании практика написания ТЗ или всё держится на неформальных договорённостях и тасках в jira?
#документация
Связь, на самом деле, очевидна, если понимать, как работают процессы в хранилище данных. ТЗ описывает не только саму задачу, но и контекст: что именно нужно сделать, с какими ограничениями и какие бизнес-требования лежат в основе (т.е. зачем вообще мы это делаем, согласитесь – важное понимание). SQL, в свою очередь, — это лишь один из возможных инструментов реализации описанного в ТЗ.
Безусловно, есть компании и команды, где просто физически нет возможности (а порой и необходимости, если всё делает 1 человек) писать ТЗ. Но у нас в хранилище этот процесс работает чётко: крупные задачи передаются от системных аналитиков дата-инженерам именно через ТЗ. Мы продумываем решение, экспериментируем, описываем его и только потом передаём на реализацию.
Речь не о каких-то мелких правках, а о чём-то более масштабном. Например, о загрузке данных с новых источников новым методом (у нас дата-инженеры занимаются только разработкой, без исследования самих данных) или доработке текущих и разработке новых фреймворков.
К примеру, при подключении нового API-источника системный аналтик сначала анализирует, как меняются данные со временем, какие поля обязательны, какими методами забирать те или иные сущности, какие ограничения накладывает сам API, и где могут возникнуть потенциальные проблемы. После этого он описывает метод загрузки сущностей в виде ТЗ и передёт его (после ревью, конечно) дата-инженерам, которые уже занимаются разработкой технической части: настройкой пайплайнов, написанием ETL-скриптов, внедрением методов обработки и трансформации. Т.е. реализацией.
И вот здесь я вижу огромную ценность доступной и поддерживаемой документации. Говорю это, исходя из своего опыта. Сейчас мне приходится работать с горой незадокументированного легаси, которое создавалось годами в условиях ограниченных ресурсов, правилось ASAP-требованиями и чаще всего не имеет описаний ни в коде, ни документации. Даже скромное ТЗ на этапе разработки, могло бы помочь понять, какие изменения вносились и зачем. Теперь же приходится тратить время (очень много времени) на разбор неочевидных решений.
Моё имхо: без документации слишком много зависит от устных договорённостей. Это не отслеживаемо, не поддерживаемо и не безопасно — т.е. огромный риск, особенно если кто-то из ключевых сотрудников покинет проект.
А как у вас? Есть ли в вашей компании практика написания ТЗ или всё держится на неформальных договорённостях и тасках в jira?
#документация
🔥6👍2