IT для неайтишников: Какими бывают IT-шники? Часть 5

Периодически мне задают вопрос: "Кто есть кто в мире ИТ?". Вопрос этот интересный и объёмный. Чтобы не рассказывать всё по много раз, я напишу несколько статей и буду на них ссылаться. Пятая часть статьи посвящена команде проектирования, точнее её части, состоящей из бизнес-аналитика, UI/UX-специалиста и системного аналитика.

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом) .

Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.

В первой части мы составили примерный список IT специалистов, который хотим рассмотреть, список получился объёмным, но на полноту не претендующим. Затем мы рассмотрели: эникейщиков; специалистов технической поддержки второй и третьей линии; системных администраторов (первая часть); программистов; поняли, чем младшие (junior), средние (middle) и старшие (senior) специалисты отличаются друг от друга (вторая часть); руководителей технической поддержки; технических лидеров и лидеров команд разработки (третья часть); специалистов по тестированию (QC); специалистов по обеспечению качества (QA); и DevOps-специалистов (четвертая часть).

В пятой части мы рассматриваем команду проектирования. Конечно, при проектировании больших изменений к команде могут подключаться архитекторы различных видов, иногда в проектировании могут участвовать руководители проектов, однако больший объем работы всё равно делают бизнес-аналитик, системный аналитик и UI/UX специалисты. Это люди, которые непосредственно задействованы в сборе требований и постановке задачи.

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

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

Рассмотрим специализации в IT, которые участвуют в создании постановки задачи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это тот человек, который проектирует пользовательские интерфейсы. То есть решает, где какую информацию разместить, где какую кнопку расположить и многое другое. Иногда таких людей неправильно называют «дизайнеры».

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

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

В названии специализации присутствует аббревиатура UX (user experience design), причём слово «desing» означает не «рисовать», а «проектировать», «конструировать». Цель UX — сделать использование продукта более удобным для пользователя. Аббревиатура UI (user interface — интерфейс пользователя) просто определяет область применения UX.

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

Есть такое семейство российских систем, как 1С. Многие считают их интерфейс некрасивым и ужасным. Ещё больше пользователей считают его удобным для своей работы. Судя по популярности 1С и массовости его пользователей, с UI/UX там все хорошо.

В своей работе UI/UX специалист проектирует прототипы и макеты пользовательских интерфейсов, которыми может пользоваться в своей работе бизнес-аналитик. Часто можно увидеть одновременно идущие и связанные процесс проектирования интерфейсов и проектирования системы с точки зрения бизнеса.

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

Иными словами бизнес-аналитик занимается вербализацией (словесным описанием) и проектированием необходимых изменений в бизнес-процессах, а UI/UX-специалист занимается визуализацией и проектированием сценариев работы пользователей после внесения изменений. При этом вербализировать сценарии работы пользователя может, как бизнес-аналитик, так и UI/UX-специалист.

Отсюда интересный вывод, UI/UX-специалист это не тот человек, который работает по «чёткому техническому заданию», это специалист, который осуществляет проектирование интерфейса системы исходя из сообщённых ему бизнес-целей, бизнес-требований и ограничений.

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

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

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

Системный аналитик выделает элементы системы, которые затрагиваются изменениями, выделает новые элементы и описывает функции этих элементов и новую схему обмена данными между ними. Работа системного аналитика происходит не после того, как отработают бизнес-аналитик и UI/UX-специалист, системный аналитик работает вместе с ними.

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

UI/UX-специалист проектирует интерфейсы информационной системы, для этого ему нужно иметь какие-то представления о том, как система устроена внутри. Например, если панель администрирования и рабочее пространство пользователей - это разные сервисы, то имеет смысл проектировать под них разные интерфейсы, а не делать единый интерфейс. Это упрощает систему и делает её более гибкой и позволяет более легко менять интерфейсы. Необходимой информацией с UI/UX-специалистом делится системный аналитик.

Системный аналитик всегда должен обладать опытом в разработке. Когда мы говорим об описании обмена данными, то понимаем, что системный аналитик описывает не только потоки данных, но ещё и форматы обмена данными. Например, он может описать API (application programming interface - программный интерфейс приложения) для каждого проектируемого элемента системы, то есть описать поведение такого элемента. Ещё он же может расписать схему хранения данных в системе, вплоть до таблиц, полей таблиц и индексов, которые появятся в базе данных.

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

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

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

В пятой части мы познакомились с работой основных членов команды проектирования: бизнес-аналитиком, UI/UX-специалистом и системным аналитиком. Именно от этих людей зависит то, насколько точно будут определены потребности бизнеса и пользователей, насколько удачное решение будет подобрано и стоимость реализации.

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

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

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме: