Что о системном анализе и бизнес-анализе расскажут на Flow 202304.08.2023 19:31

В прошлом году мы впервые провели конференцию по системному и бизнес-анализу Flow. А теперь она возвращается, и в этот раз более масштабно. Flow 2023 будет идти целых четыре дня: 4–5 сентября в онлайне и 11–12 сентября в Москве (с возможностью удалённого подключения).

Нововведение этого года — экспериментальная секция про UX, подготовленная совместно с USABILITYLAB. А общие принципы программы остались прежними. Как и раньше, будут спикеры из известных компаний (Яндекса, Альфа-банка, VK, Магнита и других). Некоторым зрителям уже известны имена Александра Белина, Юрия Куприянова, Романа Бунина, Сергея Нужненко, Ирины Гертовской и многих других. 

Сейчас уже известно, о чём именно пойдёт речь в их докладах — и здесь рассказываем об этом вам.

Содержание

Общее

Повышение точности оценки этапа аналитики

Оценка — это важная составляющая работы команды. Грамотная оценка требует от аналитика высокого уровня экспертизы, ответственности и объективности, чтобы:

• оценка понравилась заказчику;

• проект принес компании прибыль, а не убытки на «затыкание дыр»;

• заказчик имел ориентир по срокам, стоимости и загрузке;

• команда на основе оценки этапа аналитики могла оценить объем работ по разработке и тестированию;

• была создана именно та документация и в том объеме, которые требует конкретный проект.

Участников доклада ждет бонус: чек-лист оценки аналитики с выделенными типовыми фазами проектов с градацией по сложности.

Применение System Thinking и System Dynamics в бизнес-анализе

Практически все, что мы анализируем или выполняем сами, выглядит как линейные процессы. Мы анализируем бизнес-проблемы, применяя техники Поиска Корневых Причин и это очень линейный подход, то есть «A потому, что B, B — потому, что С» и т. д. Анализируем возможные сопротивления проводимым сопротивлениям, например: «Менеджер А сопротивляется новому решению, потому что его отдел автоматизируют, и его сократят», что выглядит слишком упрощенно и прямолинейно.

Разрабатывая стратегию проведения изменений, мы определяем точки AS IS и TO BE и потом с завидным упорством, закрыв глаза, как танки прем по линии, соединяющей эти точки.

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

В докладе обсудим применение техник Системного Мышления в работе бизнес-аналитика.

От «умного дома» до «умного города»: новые челленджи IT-аналитиков

Представьте мир, где все вокруг нас соединено и умеет «думать» — от холодильника до всего города. Это не научная фантастика, это реальность сегодняшнего дня, которую мы называем интернетом вещей (IoT). Добавьте в эту картину искусственный интеллект (AI) и машинное обучение (ML) — компьютеры, которые учатся и «думают» самостоятельно. Понимание новых технологий этого мира — новый аналитический вызов в IT.

Какие особенности в постановках задач? Как развивать свои компетенции? В докладе вы познакомитесь с примерами проектов, связанных с IoT, и узнаете, как системным и бизнес-аналитикам готовиться к встрече с новыми технологиями.

Кто виноват и что делать? Цели и ценности проектирования

Результаты проектирования воспринимаются через артефакты. Ирина и Екатерина поделятся своим опытом и расскажут, почему подход к проектированию от артефактов губителен. Покажут, как связаны между собой проектные слои и почему любое новое требование порождает цепь изменений. Помогут сориентироваться, как контролировать, оценивать эти изменения и следить за качеством работоспособности всей модели.

В докладе рассмотрим:

• три экзистенциальных вопроса разработки;

• DDD — разумная коллаборация при проектировании;

• нужные артефакты в нужных местах;

• биогеоценоз (связей и зависимостей артефактов);

• метрики — не «хайп», а индустриальный стандарт.

База повествования основывается на опыте как в продуктовой разработке, так и в «кровавом энтерпрайзе».

Системный и бизнес-анализ в GameDev-стартапе — какой он?

GameDev-область всегда приковывала к себе внимание специалистов, особенно в последние годы. И, как известно, в GameDev-команде нет ролей системных и бизнес-аналитиков. Но значит ли это, что анализ вообще отсутствует в разработке игр? А если он все-таки есть, то на каком этапе и в каком объеме?

Для ответа на эти вопросы, в докладе будут рассмотрены командные роли и этапы разработки игр через призму анализа и постановки задач. Также Всеволод расскажет об используемых гибких методологиях Getting Real и Crystal Agile на примере построения процессов в реальном GameDev-стартапе и об эволюции этих процессов.

Доклад будет полезен всем, кому интересен опыт организации работы в компаниях с нуля, и кто хочет посмотреть на пример построения стартапа изнутри в современных реалиях IT-индустрии в России.

Как запустить жизнеспособный проект? Или топ-10 ошибок бизнес-аналитиков в проектах внедрения ИТ-системы

По статистике, около 80% проектов внедрения ERP-систем являются неуспешными. Как бизнес-консультант, Татьяна готовила компании к внедрению ИТ-систем (обследование предприятия, описание процессов, обучение), осуществляла поддержку интегратора при внедрении и доработке ИТ-системы. Ее команда проанализировала бизнес-кейсы и выявила наиболее часто повторяющиеся ключевые ошибки, которые негативно влияют на проекты внедрения и часто недооцениваются ИТ-интеграторами. 

Доклад будет интересен бизнес-аналитикам, разработчикам, IT-архитекторам и руководителям проектов.

Скрытая работа аналитика по проектированию систем

Название профессии аналитика подразумевает, что он только разбирается в предметной области и выдает результат анализа. Но на практике системные и бизнес-аналитики занимаются не столько анализом, сколько проектированием системы — какие в ней должны быть функции, как пользователь будет выполнять свои задачи, как будет устроена база данных, какие будут API, интеграции и формы отчетов. Иногда они даже проектируют интерфейсы.

Эта работа часто не выделяется и даже не осознается аналитиком, а значит, не всегда проверяется и выполняется качественно.

В докладе Юрий рассмотрит процессы анализа и проектирования, чтобы понять:, а нужно ли их принципиально разделять. Также он даст аналитикам инструменты и набор практик, которые позволят более осознанно подходить к процессу проектирования систем.

Регулярные выражения — известный инструмент с очень большими возможностями.

В докладе пойдет речь о регулярных выражениях, области их применения и правилах использования. Будет рассмотрена возможность использования регулярных выражений в работе системного аналитика и разобраны реальные кейсы решения задач с использованием регулярных выражений.

Материал будет полезен системным аналитикам различного уровня, работающим с различным технологическим стеком.

Low-code платформа: опыт развития и импортозамещения

Анастасия расскажет о плюсах и минусах low-code платформы, предпосылках к переводу системы на новый стек, а также поделится опытом импортозамещения. Доклад будет полезен системным аналитикам, которые принимают участие в выборе архитектуры для новых проектов, а также занимаются развитием low-code платформы.

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

Рост роли данных при принятии решений растет, но при этом большинство компаний внедряет новые дата-продукты и масштабирует аналитические команды бессистемно. В результате то, что работало на малом масштабе, перестает работать с развитием команды данных. 

В докладе разберем понятие data governance и ответим на вопрос: как компаниям идти в сторону data-driven, если внедрять все и сразу — невозможно?

Разберемся в целях инструментов дата-менеджмента, приоритизируем их внедрение в соответствии со стадией развития бизнеса, расскажем о глобальном тренде на гибридизацию хранилищ. Обсудим, как бизнесу и аналитикам научиться говорить на одном языке.

Возможности Miro в работе аналитика

Аналитик работает с большим объемом информации, поэтому всегда хочется, чтобы она была структурирована и наглядна. Для этого используют различные инструменты визуализации. Один из них — Miro — сервис, который поможет в планировании, написании требований, проведении ретроспективы. Более того, важно, что этот инструмент позволяет работать удаленно для всей команды. Ольга расскажет на практических кейсах, как аналитики могут применять Miro и какие у него есть плюсы и минусы.  

Светлая сторона обратной разработки

Что вы понимаете под «обратной разработкой», когда слышите эти слова? Что специалисты этого профиля знают значения падающих зеленых буковок в матрице? Или, может, вы вспоминаете кадры с Беном Аффлеком из «Часа расплаты», где герой скопировал проектор для голограммы?

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

AI для бизнес-аналитиков

Генеративный AI наделал много шума и уже начал менять процесс разработки ПО. Хорошим примером являются специализированные средства для разработчиков типа GitHub Copilot и Tabnine, для тестировщиков — Testim и Diffblue.

Для системных и бизнес-аналитиков пока нет специальных тулов, но при правильном использовании приложений «для всех» типа ChatGPT можно сильно ускорить процесс разработки требований и спецификаций. 

Екатерина расскажет, какие задачи системного и бизнес-анализа в разработке ПО можно решать уже сейчас, какие инструменты будут полезны и как ими пользоваться для получения лучших результатов.

Давайте откажемся от Confluence и посмотрим, что будет!

Что, если перестать хранить документацию в привычном всем месте? И не только требования, но и пользовательские инструкции (user guides), и архитектуру, и логику работы продукта?

В докладе Наталья поделится опытом переноса документации в репозиторий, расскажет про markdown и красивое форматирование, а также обсудит инструментарий — Docsify, Git и новых «старых» друзей аналитиков.

Требования

Сложности и опасности при разработке требований к экосистемным сервисам

Ксения расскажет, с какими сложностями сталкивается аналитик и продакт при разработке внутренних сервисов, используемых во множестве корпоративных продуктов одной компании, на примере VK.

У команды Ксении есть сервисы приема платежей, авторизации и ряд других, которые связывают продукты группы, а также позволяют оптимизировать процессы. Цель доклада — подсветить моменты, на которые стоит обращать внимание при разработке требований, чтобы получить:

• контролируемые ожидания заинтересованных лиц,

• систему, которую можно развивать и дальше масштабировать,

• систему с контролируемыми границами,

• систему, которая гармонично выстроится в существующее окружение.

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

Доклад будет полезен аналитикам, работающим в крупных компаниях во внутренних продуктах, и аналитикам, работающим с b2b-сегментом в продуктах со множеством зависимостей или интеграций.

Требования безопасности: как работать с ними?

Когда в первый раз сталкиваешься с написанием требований безопасности, начинаешь по привычке выявлять их примерно так же, как и обычные функциональные требования. Только через какое-то время понимаешь, какой это на самом деле «крепкий орешек» в плане выяснения реальной потребности, и сколько подводных камней ты в первый раз упустил.

В докладе показаны самые частые препятствия, с которыми можно столкнуться на этом пути, и как эти препятствия можно обойти. Будут рассмотрены основные методы борьбы: законы и стандарты, модель угроз, затыкание дыр. Узнаем, как связаны требования безопасности с другими типами нефункциональных требований.

Доклад будет полезен всем, кому интересны требования безопасности вне зависимости от количества знаний в этой области. Особенно тем, кто сталкивался с проблемами в их формулировании.

Требования 20 лет спустя

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

Сергей расскажет, почему так получилось, с какими проблемами мы сталкиваемся, когда перестаем целенаправленно работать с требованиями, и что же теперь делать.

Доклад будет полезен всем, кто не застал начало Agile 20–25 лет назад, чтобы у них был выбор в организации работы. А те, кто все видел своими глазами, смогут подискутировать с Сергеем.

Dashboard Map: фреймворк для разработки системы отчетности

Для того, чтобы в компании не создавались дашборды на каждый чих, необходимо использовать структурированные подходы к проектированию системы отчетов. Если вам знакомы такие проблемы, как «невозможно найти, в каком отчете какая метрика», «расчеты между отчетами не сходятся», «а давайте сделаем еще один дашборд», то этот доклад поможет вам их избежать.

Сложности формулирования требований в ML-проектах, и как с этим поможет пирамида метрик

Специалисты по DS хорошо умеют пользоваться метриками для оценки качества своих моделей. Но очень часто эти метрики сложно отобразить на реальные потребности бизнеса. А иногда и сами DS-специалисты плохо могут объяснить их смысл. Попросите, например, их объяснить обычному человеку, что такое расстояние Кульбака — Лейблера, и они почувствуют, что и сами плохо это понимают.

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

В докладе на примерах из реальных проектов будут показаны шаги по построению таких связей. Для этого участникам предстоит неглубоко погрузиться в мир DS-метрик.

Изменения требований — как с ними жить?

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

Для этого аналитик должен уметь управлять скоупом и изменениями требований во время реализации. Об этих процессах спикер и расскажет.

Обсудим, какие инструменты аналитик может использовать для управления требованиями, как быть с конфликтами и как изменения могут восприниматься в разных командах в зависимости от методологий управления разработкой.

Данные и ML

Строим ETL для обучения «черного ящика»

Одна из актуальных проблем — это обучение ML/DL-систем на реальных данных.

На основании опыта работы в успешном проекте Дмитрий расскажет:

• В чем особенности работы с физическими документами (водительские права, паспорта, т. п.) с точки зрения ML/DL-систем.

• Зачем нужно DWH и ETL, даже если у нас есть «нейронка, которая сама делает».

• В чем особенности подготовки данных для ML/DL-систем.

• Почему в процессе работы имеет смысл читать книги про проекты из СССР 1960-х.

Apache Superset и свой плагин к Trino для эффективной и неограниченно масштабируемой BI-аналитики

Александр расскажет, как его команда написала свой плагин на Java к Trino и использует его в связке с Apache Superset для эффективной аналитики данных через BI-коннектор к Битрикс24.

Александр поделится опытом многопользовательской настройки (multitenance), масштабирования решения, настройки мониторинга, проведения нагрузочных испытаний и конфигурации для подключения Trino к другим аналитическим платформам через JDBC/ODBC (на примере DBeaver). Подробно расскажет про тонкости безопасной настройки и развертывания Apache Superset с/без контейнеризации под различные задачи BI-аналитики и под различные нагрузки.

Data Science в медицине

Data Science-специалисты обладают уникальными навыками анализа больших данных, машинного обучения и статистики, которые позволяют им извлекать ценные знания из огромных объемов информации.

В докладе рассмотрим некоторые примеры успешного использования Data Science в медицине. От прогнозирования заболеваний и ранней диагностики до индивидуального подбора лечения и анализа эффективности медицинских процедур. Data Science открывает новые возможности для улучшения здоровья и качества жизни пациентов.

Кроме медицины, Data Science находит применение в других предметных областях, таких как банковское дело и агрегаторы. Например, банки используют алгоритмы машинного обучения для обнаружения мошеннических транзакций, а агрегаторы данных помогают оптимизировать процессы и принимать обоснованные решения на основе больших объемов информации.

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

Архитектура

Архитектура как код

Архитектура — это всеобъемлющее понятие, обязательным элементом которого являются требования. Хорошая архитектура возникает только на хорошо исследованном ландшафте, т. к. он становится базой для формулирования действительно значимых решений в ней.

Подход «Архитектура как код» позволяет интегрировать всех участников производственного процесса в единый, непрерывный конвейер. Он способен охватить производство от стратегических целей бизнеса до развертывания на продакшене. В идеальном случае — это цифровой двойник производства.

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

С4 model на практике

С4 model — популярный подход к описанию архитектуры, который постепенно становится стандартом и получает поддержку в визуальных средствах проектирования. 

Денис расскажет о своем опыте применения C4 model: в каких случаях каждая диаграмма будет полезна, какие средства позволяют рисовать диаграммы, в том числе, получать результат в виде кода, который можно положить в репозиторий для просмотра истории и аппрува изменений. А также о том, как прокачать свои скилы на каждом уровне, описанном в C4.

Распил монолита на микросервисы — создание команды, выбор архитектуры и технологий

Сергей расскажет про распил большого монолита «Системы управления транспортом» в компании «Магнит». Данная система управляет планированием и контролем движения более 10 000 автомобилей в онлайн-режиме.
Коротко пройдется по функциям, которые выполняет система. Расскажет, на каких технологиях был построен монолит, какие ошибки были совершены при его проектировании и какие проблемы возникли при его разрастании. Затронет тему образования команд и как им удалось добиться лучшей производительности. Расскажет про прототипирование и ошибки, которые допустила команда. Затронет тему прототипирования: как создали прототип и получили еще один дополнительный монолит, с которым теперь борются. Осветит архитектуру получившихся микросервисов: с чего начинали, куда пришли и от чего пришлось отказаться.

Корпоративная архитектура: мифы и реальность

Поверхностное изучение материалов по корпоративной архитектуре (Enterprise Architecture) создает впечатление, что это что-то из области TOGAF, Zachman и ArchiMate. Но в реальности успешные архитектурные практики в организациях не имеют практически ничего общего со всеми этими «стандартами». В докладе анализируются наиболее популярные заблуждения про архитектуру предприятия и объясняется, как обстоят дела на самом деле.

Журнал архитектурных решений

Планирование сложных изменений в корпоративных информационных системах обычно сопровождалось разработкой и согласованием полноценного описания архитектуры такого изменения. Но рост количества изменений, потребность в сокращении сроков их осуществления и постоянный дефицит квалифицированных ИТ-архитекторов заставляет искать более простые альтернативы.

Максим расскажет, может ли такой альтернативой выступать запись архитектурного решения (architecture decision record), как его разработать, какие существуют форматы описания архитектурных решений и практики их подготовки.

Архимоделирование: от диаграмм к моделям

В продолжение рассказа о преимуществах нотации ArchiMate, Дмитрий поделится практическими тактиками и практиками по моделированию и управлению архитектурой с применением метаданных и расширений этого языка. На примерах рассмотрим, как добавить дополнительных смыслов и получить больше, чем просто картинку.

Команда и карьера

Как построить эффективную мобильную команду вокруг системного аналитика

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

От аналитика до solution-архитектора, или Как построить среду для органичного развития команды

Максим расскажет о том, как создать среду и взаимодействие в командах, которые помогают прокачиваться аналитикам и со временем решать все более сложные задачи. Как постепенно пройти путь от новичка до solution-архитектора, а главное — как создать такую среду, в которой бы этот путь было комфортно проходить.

Серый кардинал. Как аналитику осознать свое лидерство без титула и влиять на продукт

Аналитик владеет многими знаниями, но часто их не использует. Максим и Анна расскажут, как аналитикам осознать свое потенциальное лидерство и влиять на продукт, даже без официального титула.

Решения принимаются на основе данных. Вооружившись правильными коммуникативными навыками, аналитик сможет правильно воздействовать на команду и стейкхолдеров для достижения общей цели.

Как развиваться, если ты уже Senior System Analyst

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

• руководство группой аналитиков;

• роль тимлида в кросс-функциональной команде;

• переход в технические продакт-менеджеры;

• переход в архитектуру.

Рассказ будет строиться на личном опыте и примерах из практики Тинькофф, где Александр руководит большим юнитом (900+ человек), курирует архитектурные вопросы, а также видел все приведенные выше варианты или сам помогал им реализоваться.

Как описать задачу разработчикам, чтобы они не считали тебя идиотом

Достаточно часто студенты спрашивают, как правильно описать задачу для разработчика, чтобы он ее понял и сделал так, как нужно.

На этот вопрос нет однозначного ответа. Все зависит от уровня аналитика, уровня разработчика, их вовлеченности в проект и от предметной области. Чтобы лучше разобраться, как разработчику понятнее и проще осознавать и делать задачи, Иннокентий с Максимом обсудят разные варианты постановок — от высокоуровневых User Story до подробнейшей спецификации — и разберут их плюсы и минусы.

UX

Адаптивное интервью пользователей

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

Как передавать требования к продукту в UX/UI-команду

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

Знакомая ситуация?  

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

Практики применения CJM в рабочих и личных целях

Доклад посвящен практике применения Customer Journey Map (CJM) в качестве языка коммуникации в продуктовой команде. Также поговорим о применении этого инструмента для личных целей.

5 причин, почему дизайн-система — это обязательный инструмент для современных приложений

Дизайн-система является неотъемлемой частью современных приложений. Она обеспечивает визуальную целостность и является ДНК приложения. 

Команда Алевтины пришла к пониманию необходимости создания своей дизайн-системы и выделения под это отдельной команды, чтобы закрыть боли, которые возникли. В результате они выделили пять ключевых причин, почему дизайн-система необходима для приложений и должна стать неотъемлемым компонентом процесса разработки. Выработали процесс работы с командой, сформировали шаблон технических требований к UI-компонентам, на основе которых разработка компонентов стала проще и быстрее.

Для внутренних продуктов они разработали дизайн-систему «Фламинго», которая помогает командам разработки и дизайна быстро справляться с трудностями, обеспечивает единообразный стиль приложений и структуру компонентов и элементов дизайна. 

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

Целевая аудитория доклада: PO, системные и бизнес-аналитики, дизайнеры, разработчики.

UX для аналитиков. Что нужно знать о пользовательском опыте, чтобы создавать удобные продукты

Михаил Греков расскажет про UX в емкой и доходчивой форме, понятной системным и бизнес-аналитикам. Будем говорить не про дизайн, а про пользовательский опыт и его измерение.

Обсудим:

• Что такое UX.

• Ждут ли работодатели, что аналитик может в UX.

• Кто отвечает за UX.

• Что делает UX-дизайнер, а что аналитик.

• Пирамида UX-ценностей.

• Интерфейс и ТРИЗ.

• Как измерять пользовательский опыт.

• Как прокачаться в UX.

Документация

Пять значений фразы «Нам нужно всё задокументировать»

Последние пять лет Семен занимается заказной разработкой документации для российских IT-компаний. Разговор почти с каждым клиентом начинается с фразы: «Нам нужно всё задокументировать, помогите нам в этом».

Опыт показывает, что разные компании понимают под этой формулировкой довольно разные вещи, и «всё» в разных компаниях тоже отличается. В практике команды спикера эти просьбы сводятся к пяти направлениям работы:

• Описание требований к уже существующей системе — реверс-инжиниринг требований.

• Создание пользовательской документации.

• Создание архитектурной документации, адресованной исключительно разработчикам.

• Создание API-документации — причем обычно речь идет о вводных и обучающих статьях (howtos/tutorials), а не к непосредственному написанию аннотаций к методам.

• Комментарии в коде — в стиле Javadoc или в свободном формате.

В докладе обсудим, что общего у этих направлений, чем они отличаются и что делать, если вам нужно решить одну из подобных задач. Доклад будет интере

© Habrahabr.ru