Александр Головков, Подход к системному анализу, вернувший жизнь UML

История разработки подхода

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

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

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

Что предлагает подход

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

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

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

Основными проблемами системного анализа на российском IT-рынке автор и его единомышленники считают:

• Сложность используемого «языка» - набора диаграмм и инструментов, для описания требований к работе программного обеспечения, что вызывает сопротивление к ведению модели требований как у аналитиков, так и у представителей бизнес-заказчиков, которым приходится изучать этот «язык» чтобы подтвердить или опровергнуть корректность требований, описанных аналитиком.
• Отсутствие понятного хорошо описанного и легко внедряемого подхода к совместной работе нескольких аналитиков и других членов команды разработки над требованиями, что удлиняет процессы согласования требований и создает впечатление у руководства IT и тем более у бизнес-заказчиков ненужности и бесполезности этого этапа, тогда как именно в нем кроется огромный кусок стоимости разработки.
• Отсутствие желания у исполнителей (системных аналитиков) вести версионное ТЗ на всю систему, потому что трудозатраты на это довольно высоки, выгода в краткосрочной перспективе непонятна, а в длинно срочной не очень интересна для исполнителей.

Как внедрение подхода влияет на качество и скорость разработки

Как отмечает автор подхода ответ на этот вопрос зависит от качества существующих в компании процессов - если в компании и так внедрена большая часть методик и практик, входящих в подход, то влияние будет относительно невысоким, но дьявол кроется в деталях, а на них обычно обращают внимание и доходят до них в последнюю очередь. Даже для компаний, у которых на момент начала внедрения подхода уже были достаточно взрослые процессы системного анализа и разработки программного обеспечения, такие показатели качества как «Количество дефектов на этапе приемки», «Количество CR на этапе приемки» и «Количество дефектов на production среде» падают в перспективе год-полтора примерно на 15-20% и, в том числе за счет этого, time-to-market сокращается примерно 20-30%. Для компаний же с незрелыми процессами эти изменения могут достигать 80%. Важно отметить, что положительный эффект напрямую влияет на стоимость разработки, и сокращает ее за счет раннего обнаружения дефектов. Известно, что чем позднее найден дефект, тем сложнее и дольше его исправление, там большее количество участников вовлечено в его исправление и тем дороже получается rework:

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

«Нет ничего более трудного в управлении, более опасного в управлении и более сомнительного в его успехе, чем возглавить введение нового порядка вещей», — писал Никколо Макиавелли. Так и внедрение разработанного Александром подхода не дает моментального эффекта и требует правильной коммуникации и поддержки всех участников процесса на всех этапах внедрения, чтобы обеспечить максимально безболезненное внедрение. Первыми положительный эффект на KPI видит руководство IT-компаний, затем команда разработки и наконец бизнес-заказчики. Долгосрочный фидбек всегда положительный.

За счет чего достигаются такие результаты

Среди главных критериев достижения результатов специалисты выделяют уникальный подход к описанию требований к программному обеспечении, который с одной стороны упрощает описание требований за счет ограничения требований диаграмм на языке Unified Modeling Language (UML), используемых при разработке модели, а с другой стороны сбалансирован таким образом, чтобы обеспечить полное, понятное и непротиворечивое описание требований к поведению разрабатываемого программного обеспечения. Жесткие правила моделирования не позволяют аналитикам скатится в сложное техническое повествования, и при этом не требует глубокого знания UML от команды разработки и представителей заказчика, которые согласовывают Технические задания. Использование централизованной модели требований с общим доступом к ней для всех членов команды позволяет обеспечить совместную работы при проверке требований. Определяемый подходом формат документа «Техническое задание» (ТЗ), требования к версионированию ТЗ, а также наличие набора шаблонов позволяют значительно сократить трудозатраты и, как следствие, негатив со стороны исполнителей при подготовке полного ТЗ за счет внедрения механизма автоматического формирования этого документа.

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

UML«снова жив»

В сообществе системных аналитиков и системных архитекторов последние годы зачастую можно было слышать, что «UML мертв» или что применение UMLтормозит процесс разработки. По мнению автора подхода, UML жил, жив и будет жить, ему не требуется вторая жизнь. Александр считает, что речь идет о том, что на российском IT рынке, с ростом распространенности agile-подхода, начался довольно массовый отказ от ведения нормальных моделей требований и написания полноценных Технических заданий, и соответственно снизилось количество команд, использующих UML. Это произошло ввиду неправильной организации процессов системного анализа, что помогло создать впечатление у многих неопытных Agile команд и их не более опытных заказчиков, что разработка этих артефактов увеличивает time-to-market (время на реализацию новой функциональности) и в целом «тормозит прогресс». Предлагаемый Александром Головковым подход направлен на то, чтобы вернуть эти артефакты в SDLC (Systems Development Life Cycle) и показать, что при относительно небольших затратах, они могут приносить хороший профит. И так как опыт внедрения подхода всегда успешен, количество команд, внедривших подход растет и, как следствие, растет количество команд, использующих UML в своей работе – именно поэтому многие специалисты, говоря о об описываемом подходе говорят, что он вернул жизнь UML.

Дата публикации: 15 мая 2019 г.

Автор: Дмитрий Кожевников