Проектирование процессов разработки IT продукта

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

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

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

На начальных этапах формирования программных обеспечений периода
90-ых, 2000-ых годов, подход к проектированию программ был условным,
в большей степени определялся самими разработчиками. С ростом конкуренции и качеством продуктов на рынке, создавать продукты на основе личной интерпретации понимания разработчика — является как минимум некорректным. Современный подход к разработке продуктов требует всеобъемлющего проектирования процессов разработки, как некую форму общего дизайна продукта и процессов работы над этим продуктом такой инженерной системы взаимодействий, которая включает в себя:

Однако, ещё далеко не все компании обрели понимание подобного системного подхода.

Привычный подход устарел
Классический подход в разработке продуктов, который зародился в конце
XX века, на сегодняшний день укрепил образ некой системы, которая работает на потоке, который, в свою очередь, сложно отследить, внести изменения или интегрировать инструменты, которые помогут как минимум стабилизировать процессы в управлении продуктом и командами, сократив расходы бизнеса
на IT-продукт. В конечном счёте, такой подход выглядит более нестабильным, трудозатратным и экономически невыгодным, поскольку в перспективе тратится больше ресурсов на доработку IT-продукта, бесконечный поиск причин ошибок, которые были допущены на этапе проектирования общих рабочих процессов, и такая же бесконечная борьба со следствием в виде вливания бюджетов и времени на залатывание производственных дыр. По нашему мнению, одна из причин, это невозможность в принципе, или нежелание бизнеса (владельца продукта) по каким-то личным соображениям, мировоззренческим установкам, стереотипам мышления или попросту страха, строить организационные процессы и выстраивать внутренние отношения между отделами IT-продукта более системно, как некий общий организм, который функционирует ради достижения общей цели.

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

Перетягивание одеял
В нашем понимании, основой системного подхода к производственным процессам работы над IT-продуктом, является такое выстраивание производственных процессов, в котором всем участникам процесса работы над продуктом, важно принять то обстоятельство, что именно коллективная сплоченность в достижении общей цели на разработку продукта, поможет достичь более высоких и качественных результатов, в отличии от индивидуальной игры отдельных команд работающих «на потоке» в своих песочницах, в отрыве от общего курса и политики IT-продукта. Конечно, этот вопрос должен решатся управленцами продукта, должны создаваться такие условия и процессы работы, при которых подобное перетягивание будет недопустимо, ибо подобные «перетягивания одеял», через недоговоренности
и конфликты, будут рождать внутренний раздор и непонимание, трату времени и финансов. Потому, необходимо выстроить процесс симбиоза между бизнесом, дизайном и разработкой, с помощью внутренних «языков общения» относительно каждого из направлений, где дизайн и разработка понимают
и учитывают интересы бизнеса, через представителей стороны бизнеса (маркетологи, аналитики) , а также выстраивают общей язык внутри собственной среды разработки (дизайн/front-end) с помощью токенов,
о которых ниже пойдёт речь, а бизнес, в свою очередь, понимает свою целевую аудиторию (пользователя) и умеет объяснить и донести свои ключевые потребности до команд разработки.

Более и менее важные специалисты
В погоне за общей целью, мы не делим разработчиков на более или менее важных в контексте общего процесса в достижении цели, не обесцениваем труд проектировщика интерфейсов (ux/ui-дизайнер) только потому, что по субъективным ощущениям, проектирование интерфейсов не так важно как программирование, и что ux/ui-дизайнер не так серьезен в знаниях и важности как разработчик. Порой, такое отношение можно встретить внутри компаний. Основные процессы более важны в данном случае, чем личные отношения к кому-либо. В масштабах управления разработкой продуктов, мыслить подобным образом - попросту глупо и опасно.

Пренебрежение проектированием
Дизайн интерфейса, как форма взаимодействия пользователя с интерфейсом - важная часть на этапе общего проектирования процессов. Если проектирование интерфейсов (ux/ui-дизайн) не будет учитываться, если им будут пренебрегать, то хороший дизайн сменится плохим дизайном от разработчиков, которые сделают по своему, опираясь на свой сухой взгляд и опыт в данной сфере, в итоге сделав дизайн интерфейса, но не тот который нужен продукту, или спроектировав архитектуру продукта так, что внедрение каких-либо изменений в архитектуру или проектирование интерфейса, будет невозможным или на столько затратным, что легче всё начать заново. В конечном счёте, хорошо спроектированный интерфейс сменится плохо спроектированным интерфейсом, ибо сама форма останется - интерфейс всё равно будет спроектирован, но не ux/ui-дизайнером, что недопустимо в нынешних условиях конкуренции продуктов на рынке. Потому, имеет большое значение изначальное проектирование производственных процессов и продукта, поскольку у одних только разработчиков вряд-ли в запасе есть опыт и время на изучение потребностей клиента, бизнес-целей и качественное проектирование интерфейса.

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

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

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

наименованием этих логических блоков и операций в коде в соответствии с бизнес-целями, тем самым теряя связь с бизнесом в рамках общего и локально-контекстного понимания продукта и его потребностей. Проектировщики интерфейсов (ux/ui-дизайнеры) будут заниматься отрисовкой интерфейса с позиции бездумного инструмента, а маркетологи проводить модные и часто не к месту применимые Jobs to Be Done исследования для выявления якобы по-настоящему нужных потребностей клиента в продукте. В итоге, в такой структуре отношений, все отрабатывать свои личные процессы в угоду личных интересов, интерпретируя задачи по своему усмотрению и не выстраивая язык общения, не выстраивая коллективный процесс работы в достижении общей цели. В конечном счёте, бизнес заплатит более высокую цену за свои ошибки в переделывании дизайна и оптимизации кода, чем если бы он заплатил за разумное выстраивание процессов и предметное проектирование изначально. В перспективе данная незрелая политика приведёт вплоть до полного краха продукта на рынке, потерю репутации и лояльности клиентов.

В частности, допущение одних только интерфейсных ошибок (в отсутствии дизайнера проектировщика) на этапе разработки, может повлечь за собой огромные потери бюджета и трудозатрат на их исправление в дальнейшем. Принятие неграмотных бизнес-решений в виде пренебрежения всеобъемлющего проектирования продукта на начальных этапах, выльется в колоссальные потери в перспективе жизни продукта, когда разработчики будут закапываться в технические задачи, не понимая целей и потребностей бизнеса, таким образом не проектируя код относительно бизнес-процессов (контекстов разработки) для более качественного, относительного контекста рефакторинга. Или, например, когда ux/ui-дизайнер будет обычным инструментом в руках владельца продукта (бизнеса), которому бизнес говорит как надо сделать, аргументируя это тем, что так сделано у конкурентов, в свою очередь, не углубляясь в вопросы обстоятельств принятия данных решений конкурентом, уповая лишь на субъективные воззрения и домыслы. Мы не утверждаем, что копирование решений всегда неправильно. Очевидно, что есть дизайн-решения привычные для пользователей в массе, и нет смысла "придумывать велосипед", можно переиспользовать привычное рабочее решение с улучшенными особенностями. Однако, стоит всегда учитывать локальные личные обстоятельства, понимать где и для чего можно переиспользовать решения, а где стоит подумать, имеет ли смысл их переиспользования, с учётом обстоятельств вашего продукта.

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

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

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

Проработка интерфейса и его состояний, так же требует отдельного процесса проектирования. Таким образом возникает потребность в дизайн-системе (язык общения внутри дизайн отдела и между отделом дизайна и front-end разработкой). Результатом локализации интерфейсной проработки с помощью дизайн-системы, становится значительное снижение цены ошибки. Касательно непосредственно дизайн-проектирования, каждое действие пользователя требует отображения в макетах для более подробного описания поведения интерфейса на действия пользователя. Изменение состояния объекта, с которым работает пользователь, отображение всех состояний объекта (ошибочных, заполненных, незаполненных, подгружающихся данных) приводят к генерации огромного количества экранов (состояний интерфейса в каждый момент пользовательского действия, а иногда и в каждый момент времени после пользовательского действия). Если не делать полную детализацию поведения интерфейса на этапе проектирования/макетирования, то встает вопрос на каком этапе всплывет вопрос этой детализации. Сразу можно ответить, что вероятнее всего такой вопрос возникнет на этапе программной разработки. То есть принимать финальное решение будет разработчик в связке с проектным менеджером, что приводит к потере качества продукта, так как проектный менеджер и разработчик не видят цельной картины продукта с точки зрения бизнес/пользователь, которое курирует проектировщик инетрфесов. В конечном счете решение принятое на уровне проектный менеджер/разработчик приведет к повышению вероятности ошибки в построении интерфейса, а значит к ухудшению качества интерфейса и к дополнительным трудозатратам на исправление ошибки. Автоматизация процессов относительно дизайна (ux-логики), с расчётом на перспективу разработки в расширении (маштабировании) продукта, носит более главенствующий по своей важности характер, нежели простая отрисовка элементов по мере необходимости и роста продукта, поскольку изначально учитывает основные возможные варианты развития дизайн-системы, с учётом обстоятельств конкретного продукта, закладывает определённую, относительную архитектуру в дизайн-систему (схему построения).

В свою очередь, язык общения между back-end и бизнесом, может базироватьсяна предметно-ориентированном проектировании (инструментарий domain-driven design или D.D.D.). Выстраивать архитектуру кода относительно ограниченных бизнес-контекстов в рамках семантических границ с единым, конкретным внутренним языком общения между разработчиками. В случае, если в начале разработки программного обеспечения вы не можете выделить конкретные ограниченные контексты разработки, исходный код носит обощенный абстрактный характер, со временем архитектурная модель будет обретать более явные черты, что позволит выделить контексты и определить на них команды, которые выстроят свой относительный (к конетексту) язык общения, где объекты и кластеры, свою очередь будут носить названия относительно бизнес-процессов и их контекста. Таким образом, даже интегрирование новых разработчиков в конкретный ограниченный контекст (команду) будет более быстрым, в связи с систематизированностью информации и внутренними процессами.

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

Идёт оценка задачи среди back-end, QA и UX/UI дизайнеров. В данной связке, дизайнеры не являются той стороной, которая заинтересована в понимании глубинных или даже общих процессах разговора происходящих между backend и QA, поскольку компетенция дизайн-отдела, как и компетенция backend и QA не пересекаются между собой по существу, а носят лишь локальный нечастный характер. Данный характер взаимоотношений, даёт понимание того, что оценивать в задачу в story-point, в данном случае дизайн-отделу не является необходимым. В свою очередь встреча и оценка задач между front-end, QA и дизайн-отделом, не задеват интересы и не несёт смысловой нагрузки для back-end. Нужно мыслить относительно контекстов, а не применять правила по шаблону для каждого случая.

Выстраивая язык общения между отделами, поддерживая и укрепляя кросфункциональные знания между отделами разработки, мы приобретаем понимание общей цели и трудозатрат на задачи с помощью системы оценок story-point (как указано выше). К тому же, интегрирование новых сотрудников в команды, будет протекать легче и быстрее, когда выстроены языки общения, системно проработаны контексты рабочих областей и всё подкреплено документацией (мануалами). В таком случае, новый сотрдуник, который изначально, как правило, мало заинтересованный в продукте будет вникать в общие и частные процессы затрачивая меньше времени, приобретая больше понимания из-за системности построения взаимодействий внутри продуктовых команд.

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

Возможно, в силу незрелости компаний и владельцев бизнеса (продуктов), данная теория покажется излишне сложной и неэффективной. Что ж, если рынок это животный мир конкуренции где выживает сильнейший и тот, кто умеет приспособиться через процесс эволюции или иначе, то всё закономерно — кто-то должен погибнуть, кто-то должен воспрять в сознании и понять, что лишь коллективный разум и труд, способен переплюнуть одиноких “атлантов” которым в итоге возложат цветы.

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

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

Далее в форме теоретического подхода к дизайн-системам, мы расскажем о том, как можно минимизировать трудозатраты, бюджет и нервы команды, с помощью более детальной проработки и построения дизайн-системы. Фактически покажем на примере, как на наш взгляд стоит подходить к разработке дизайн-системы и налаживанию языка общения между UX/UI-дизайнерами и Front-End разработчиками.

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

В свою очередь, мы предлагаем более детальный, гибкий и управляемый подход в рамках работы над сложными продуктами, (сложность определяется оценочным суждением субъекта/компании, личными обстоятельствами и возможными перспективами к расширению продукта). По ходу анализа, мы пересмотрели атомарный дизайн как метафору, поскольку она не выдерживает критики терминологий и определений (в их отсутствие). Так же, в нашем труде пойдёт речь о подробном семантическом ядре всех элементов (токенов), что в свою очередь позволит выстроить цепь наследований в категориях и ответвлениях компонентов, блоков и т.д., относительно контекста применения.

В нашем труде, мы предлагаем выстраивать более сложную структуру дизайн-системы, которая будет включать в себя этапы разработки от элементов (токенов) до user-flow. При этом, каждый этап (элементы, компоненты, блоки, шаблоны, страницы и user-flow) будет сопровождаться дополнительной документацией, которая будет содержать в себе правила редактирования и навигации в семантике наименований. Таким образом, мы предполагаем, что сможем достичь более детального и точечного редактирования, добавления или удаления элементов и компонентов дизайн-системы, улучшить навигацию внутри дизайн-системы и сделать централизованное управление более гибким. Данная система выглядит сложно, что может вызвать легкий испуг и вопросы у ряда дизайнеров, мол дизайн должен быть простым, понятным и т.д.. Однако, чтобы он был простым и понятным конечным пользователям дизайн-системы (дизайнерам\\разработчикам), у нас, создателей дизайн- системы, она (структура дизайн-системы) должна быть более усложнённой, но за то гибкой в использовании и централизованной в управлении. Данная усложнённость является лишь некой платой за простой конечный продукт для пользователей дизайн-системой.

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

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

Авторы статьи:
Бушков Филипп . Продуктовый дизайнер
Чмиленко Сергей . Продуктовый дизайнер

Особая благодарность:
Елагин Андрей . Ведущий разработчик АБЦТ (Ак Барс Цифровые Технологии)
Ибрагимов Вагиз . Руководитель центра компетенций (Ак Барс Банк)
Вайткус Денис . SCRUM-мастер
Стародумов Руслан . Fullstack-разработчик

#разработка #дизайн #бизнес #проектирование #архитектура #дизайнсистемы #uxui #development #business #scrum #architecture #programming

Вторая часть по архитектуре дизайн-систем: