Должен ли аналитик рассматривать и предусматривать риски, или риски — это компетенция менеджеров?

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

Сегодня подвергается сомнению сама потребность в аналитиках («скоро AI нас заменит!»). И хотя уже многие понимают и говорят, что это не так, роль и функции аналитика пересматриваются. Но есть области, где нас заменить на AI сложно.

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

Разработка программного обеспечения — сложный процесс, зависящий от технологий и методологий. Аналитик играет ключевую роль, различая инвариантные (независимые от выбранных подходов) и вариативные (зависящие от конкретных технологий и методологий) аспекты. Критические этапы, такие как анализ требований и проектирование, остаются важными, но их реализация может варьироваться. Стандарты ISO/IEC 12207 (жизненный цикл программных средств) и ISO/IEC 15288 (процессы жизненного цикла систем) помогают структурировать работу аналитика, избегать ошибок и повышать эффективность. Понимание процессов способствует созданию качественного продукта, минимизации рисков и достижению целей проекта с меньшими затратами, что является ключом к успешной карьере в IT.

Поговорим о том, что многие годы волнует разработчиков (в широком понимании): аналитиков, архитекторов, программистов, тестировщиков и менеджеров. 

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

• исключить однообразность работ;
• уменьшить ошибки, неизбежные при монотонных работах;
• снизить трудозатраты как минимум в два раза;
• обеспечить полноту и непротиворечивость решений;
• подружить аналитиков и технических писателей, повысить эффективность всей команды.

Мастер-класс разработан на базе техник, отработанных в практической работе крупных проектов.

В рамках доклада, поговорим о консистентности артефактов проектирования, целостности и непротиворечивости.

• Какие элементы каких артефактов связаны и влияют друг на друга, и как это применять в анализе, архитектуре, дизайне и управлении изменениями.
• Как при разработке артефактов проектирования (структуры БД, UC, макетов визуальных форм, API и пр.) опираться на уже разработанное, контролировать соответствие, не допускать нестыковок.
• Как при изменениях сохранить корреляцию артефактов, выявить расхождения, уменьшить ошибки проектирования (а может и исключить их?).

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

В профессиональном сообществе укоренилось мнение, что профстандарты не нужны.

Однако, наш написан не в башне из слоновой кости и может быть успешно применен по следующим направлениям:

• ориентиры в профессии (куда развивать и куда развиваться);
• использование профстандартов в системе высшего образования и системе профессионально образования;
• использование профстандартов тренинговыми центрами;
• использование профстандартов для самообразования системных аналитиков;
• использование профстандартов как действующими системными аналитиками, так и теми, кто их нанимает, обучает и ставит задачи. 

Вклад в обновление профстандарта внесли несколько десятков человек из ИТ. Большие своды знаний типа BABOK, CBOK, PMBOK начинались примерно так же. 

Всем, кому это интересно, кто видит и другие перспективы - приходите об этом поговорить.

Знание аналитиком нескольких (чем больше, тем лучше) предметных областей – значительное конкурентное преимущество специалиста и важная ценность для компании, имеющей такого специалиста. В текущих реалиях «цифровизации всего» запрос на создание или модернизацию системы в новом незнакомом домене может возникнуть в любой момент. Хорошо бы иметь техники быстрого погружения, и чтобы не за 3-6 месяцев, а в адекватные сроки.

Часто слышим фразы типа: «Тестировщик должен ..», «Тестировщик может…»...

В докладе рассмотрим, что может/должен выполнять тестировщик в разных сценариях разработки в ИТ. С кем (с какими ролями в команде) взаимодействует на каждом шаге. Как его, тестировщика (инженера по качеству!) действия влияют на качество разрабатываемой системы. Как может повлиять инженер по качеству на успешность системы.

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

Доклад построен на моем опыте работы во всех ролях команды разработки ПО.

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

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

На мастер-классе рассмотрим новые проверки требований – схемы состояний и переходов и таблицы решений. И повторим, закрепим правила стандарта ISO 29148 и CRUD(L) – требования, которым должны удовлетворять требования к системе.

Мастер-класс для отработки навыков ревизии требований, в продолжение доклада "Не все проверки бесполезны или несколько способов ревизии требований".

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

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

Можем ли мы выявить хотя бы часть таких ошибок на более ранних стадиях работ? Может ли тестировщик (инженер по требованиям) выявить ошибки в требованиях до разработки ПО? 

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

Несколько лет мы следили за эпопеей перевода на русский язык «Руководства к своду знаний по бизнес-анализу» (BABOK 3.0). Обсуждали в Facebook`е, разбирали термины и понятия, ждали сообщений руководителя перевода Александра Белина, даже выполняли ревью. И вот свершилось – рыжий том в 600 страниц в руках.

В докладе познакомлю со структурой BABOK, содержанием разделов, взаимозависимостями частей. Поделюсь рекомендациями по применению, покажу два-три примера из личной практики. Расскажу почему:

а) начинающему аналитику не рекомендуется начинать изучение бизнес-анализа с BABOK 3.0;

b) практикующему аналитику полезно иметь BABOK в качестве постоянного настольного пособия;

с) даже опытным аналитикам имеет смысл иногда заглядывать в книгу.

В чатах и группах аналитиков часто возникают вопросы: 

• Как провести оценку компетенций аналитиков? 
• Какими компетенциями должен обладать мидл, какими – сеньор? 
• Как оценить компетенции? Как понять каких компетенций не хватает специалисту? 
• Как объяснить человеку результат оценки, чтобы не обидеть его?

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

И как за 5 шагов построить подобную систему под свои нужды.

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

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

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

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

Многим из нас знакома ситуация: от заказчика поступил запрос на пресейл, срочная задача аналитикам, потенциальный новый перспективный контракт, но среди аналитиков Компании нет специалистов в этом домене. Это причина отказаться от контракта? Или есть выход? 

На мастер-классе поделюсь опытом, как за несколько дней погружались в новый домен, какие проблемы возникали и как их решали. Обсудим примеры удачного и неудачного опыта и причины неудач. Рассмотрим применение метода ментальных карт (Impact Mapping), как способа определения границ проекта и основных гипотез, созданных совместными усилиями разработчика и Заказчика. Совместно выработаем чек-лист погружения аналитика в новый домен.

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

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

Этот доклад не для вас, если у вас:

-       опытные высококлассные аналитики, умеющие оценить свои трудозатраты с приемлемой для руководителя проекта точностью;

-       разноплановые, зачастую исследовательские работы;

-       инновационные направления работ, в основном мозговые штурмы и исследования.

Информационная система крупной корпорации или ведомства является, как правило, комплексом программных подсистем, а также взаимодействует с ИС других предприятий /организаций. В силу различных причин, внесение изменений в ПО – постоянная жизненная потребность. Несогласованные изменения связанных подсистем (или смежных ИС) могут привести не только к блокировке работы ПО, но и предприятия (ведомства) в целом. В докладе описан пример управления функциональными требованиями автоматизированной документоориентированной системы (комплекса подсистем). Рассмотрены изменения документов, функций ПО над документами, операций пользователями с документами и интерфейсов обмена между подсистемами. Предложена структура хранения требований и методика контроля изменений. Контроль изменений доработок смежных подсистем и внешних ИС обеспечивает стабильную работу корпорации или ведомства. Кроме того, с помощью системы управления требованиями частично автоматизирована подготовка проектной документации.