Проектирование процессов разработки IT продукта
Вводная
Перед вами первая часть из трёх частей общего труда, вводная часть цикла статей о проектировании процессов разработки IT-продукта.
Данная вводная статья носит философский характер, некий взгляд на вещи, на то, каким путём имеет смысл идти в выстраивании рабочих процессов над продуктом. Это не является догмой, естественно не является законом. Это пища для размышления руководителям продукта и руководителям отделов разработки продукта, а так же, руководителям отделов, косвенно имеющих влияние на продукт. Для всех тех, кто имеет начальный уровень, в статье оставлены поясняющие определения для используемых терминов. Возможно, кто-то найдёт в этом смысл и сможет дополнить этот взгляд своим опытом и обстоятельствами IT продукта, использовав данный подход, что в конечном счёте поможет решить продукту свои организационные и производственные проблемы.
Начало начал
На начальных этапах формирования программных обеспечений периода90-ых, 2000-ых годов, подход к проектированию программ был условным,в большей степени определялся самими разработчиками. С ростом конкуренции и качеством продуктов на рынке, создавать продукты на основе личной интерпретации понимания разработчика — является как минимум некорректным. Современный подход к разработке продуктов требует всеобъемлющего проектирования процессов разработки, как некую форму общего дизайна продукта и процессов работы над этим продуктом такой инженерной системы взаимодействий, которая включает в себя:
- проектирование интерфейсов;
- маркетинговые идеи и решения;
- взаимодействие бизнеса с пользователем;
- создание аккуратного кода, разбитого по сегментам и контекстам бизнес-процессов для более удобного управления и рефакторинга в будущем.
Рефакторинг
Однако, ещё далеко не все компании обрели понимание подобного системного подхода.
Борьба с системой уже тоже система
Классический подход в разработке продуктов, который зародился в конце XX века, на сегодняшний день укрепил образ некой системы, которая работает на потоке, который, в свою очередь, сложно отследить, внести изменения или интегрировать инструменты, которые помогут как минимум стабилизировать процессы в управлении продуктом и командами, сократив расходы бизнеса на IT-продукт. В конечном счёте, такой подход выглядит более нестабильным, трудозатратным и экономически невыгодным, поскольку в перспективе тратится больше ресурсов на доработку IT-продукта, бесконечный поиск причин ошибок, которые были допущены на этапе проектирования общих рабочих процессов, и такая же бесконечная борьба со следствием в виде вливания бюджетов и времени на залатывание производственных дыр. По нашему мнению, одна из причин, это невозможность в принципе, или нежелание бизнеса (владельца продукта) по каким-то личным соображениям, мировоззренческим установкам, стереотипам мышления или попросту страха, строить организационные процессы и выстраивать внутренние отношения между отделами IT-продукта более системно, как некий общий организм, который функционирует ради достижения общей цели.
В данной труде мы предлагаем рассмотреть альтернативу подобной устаревшей, и попросту губительной (на наш взгляд) модели, относящуюся к производству IT-продуктов. Данная альтернатива подразумевает под собой изначальное проектирование процессов в зарождающемся продукте получившем финансирование или постепенное интегрирование «порядка»в уже функционирующие процессы работающих продуктов на рынке. Интегрирование «порядка» в уже функционирующие процессы, может быть болезненным, в силу масштабов и обстоятельств внутреннего бардака, однако, это хотя бы является путём к исправлению ошибок и выстраиванию систематизации продукта в управлении, как между командами, внутри команд, так и внутри исходного кода продукта.
В нашем понимании, основой системного подхода к производственным процессам работы над IT-продуктом, является такое выстраивание производственных процессов, в котором всем участникам процесса работы над продуктом, важно принять то обстоятельство, что именно коллективная сплоченность в достижении общей цели на разработку продукта, поможет достичь более высоких и качественных результатов, в отличии от индивидуальной игры отдельных команд работающих «на потоке» в своих песочницах, в отрыве от общего курса и политики IT-продукта. Конечно, этот вопрос должен решатся управленцами продукта, должны создаваться такие условия и процессы работы, при которых подобное перетягивание будет недопустимо, ибо подобные «перетягивания одеял», через недоговоренности и конфликты, будут рождать внутренний раздор и непонимание, трату времени и финансов. Потому, необходимо выстроить процесс симбиоза между бизнесом, дизайном и разработкой, с помощью внутренних «языков общения» относительно каждого из направлений, где дизайн и разработка понимают и учитывают интересы бизнеса, через представителей стороны бизнеса (маркетологи, аналитики) , а также выстраивают общей язык внутри собственной среды разработки (дизайн/front-end) с помощью токенов,о которых ниже пойдёт речь, а бизнес, в свою очередь, понимает свою целевую аудиторию (пользователя) и умеет объяснить и донести свои ключевые потребности до команд разработки.
Дизайн интерфейса, как форма взаимодействия пользователя с интерфейсом - важная часть на этапе общего проектирования процессов. Если проектирование интерфейсов (ux/ui-дизайн) не будет учитываться, если им будут пренебрегать, то хороший дизайн сменится плохим дизайном от разработчиков, которые сделают по своему, опираясь на свой сухой взгляд и опыт в данной сфере, в итоге сделав дизайн интерфейса, но не тот который нужен продукту, или спроектировав архитектуру продукта так, что внедрение каких-либо изменений в архитектуру или проектирование интерфейса, будет невозможным или на столько затратным, что легче всё начать заново. В конечном счёте, хорошо спроектированный интерфейс сменится плохо спроектированным интерфейсом, ибо сама форма останется - интерфейс всё равно будет спроектирован, но не ux/ui-дизайнером, что недопустимо в нынешних условиях конкуренции продуктов на рынке. Потому, имеет большое значение изначальное проектирование производственных процессов и продукта, поскольку у одних только разработчиков вряд-ли в запасе есть опыт и время на изучение потребностей клиента, бизнес-целей и качественное проектирование интерфейса.
В нашем понимании, основой системного подхода к производственным процессам работы над IT-продуктом, является такое выстраивание производственных процессов, в котором всем участникам процесса работы над продуктом, важно принять то обстоятельство, что именно коллективная сплоченность в достижении общей цели на разработку продукта, поможет достичь более высоких и качественных результатов, в отличии от индивидуальной игры отдельных команд работающих «на потоке» в своих песочницах, в отрыве от общего курса и политики IT-продукта. Конечно, этот вопрос должен решатся управленцами продукта, должны создаваться такие условия и процессы работы, при которых подобное перетягивание будет недопустимо, ибо подобные «перетягивания одеял», через недоговоренности и конфликты, будут рождать внутренний раздор и непонимание, трату времени и финансов. Потому, необходимо выстроить процесс симбиоза между бизнесом, дизайном и разработкой, с помощью внутренних «языков общения» относительно каждого из направлений, где дизайн и разработка понимают и учитывают интересы бизнеса, через представителей стороны бизнеса (маркетологи, аналитики) , а также выстраивают общей язык внутри собственной среды разработки (дизайн/front-end) с помощью токенов,о которых ниже пойдёт речь, а бизнес, в свою очередь, понимает свою целевую аудиторию (пользователя) и умеет объяснить и донести свои ключевые потребности до команд разработки.
Дизайн интерфейса, как форма взаимодействия пользователя с интерфейсом - важная часть на этапе общего проектирования процессов. Если проектирование интерфейсов (ux/ui-дизайн) не будет учитываться, если им будут пренебрегать, то хороший дизайн сменится плохим дизайном от разработчиков, которые сделают по своему, опираясь на свой сухой взгляд и опыт в данной сфере, в итоге сделав дизайн интерфейса, но не тот который нужен продукту, или спроектировав архитектуру продукта так, что внедрение каких-либо изменений в архитектуру или проектирование интерфейса, будет невозможным или на столько затратным, что легче всё начать заново. В конечном счёте, хорошо спроектированный интерфейс сменится плохо спроектированным интерфейсом, ибо сама форма останется - интерфейс всё равно будет спроектирован, но не ux/ui-дизайнером, что недопустимо в нынешних условиях конкуренции продуктов на рынке. Потому, имеет большое значение изначальное проектирование производственных процессов и продукта, поскольку у одних только разработчиков вряд-ли в запасе есть опыт и время на изучение потребностей клиента, бизнес-целей и качественное проектирование интерфейса.
