Нужно ли ИТ-аналитикам уметь программировать

Вопрос обязательности умения/знания/понимания программирования для ИТ-аналитика-проектировщика вызвал жаркие дебаты в профильных группах. Приводились два вида аргументов:

1. Противники: программировать должен программист, если аналитик должен уметь программировать, то он должен владеть навыками всех смежных профессий; такого аналитика не обучишь и не найдешь на рынке.

2. Сторонники: умение/владение языком программирования позволяет делать более качественные ТЗ (этот аргумент не является непосредственным доказательством).

Также остается неясным, когда каким языком программирования нужно владеть. Кто-то говорит SQL, кто-то — любым процедурным. Так нужно ли или нет? Давайте взглянем на ситуацию системно.

Вспомним, в чем ценность системного аналитика

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

Когда аналитик создает модель решения, он действует по определенной методике.

1. После выявления контекста и требований, он взаимосвязывает разные требования, возможности, ограничения и способы решения задач — в одно целое. 

2. Связывание/сопоставление возможно сделать неоднозначно, сама конструкция в деталях неоднозначна, есть разные варианты (с разной стоимостью, сроками и другими атрибутами качества). Чтобы разобраться как все-таки это в целом должно работать, нужно определить предпочтительный (или предпочтительные варианты). 

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

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

5. Уменьшив вариативность реализации аналитик достигает своей цели — уменьшения неопределенности.

Если аналитик не создает модели, то он не уменьшает вариативность. Когда разработчик начинает писать код, то 

1. он пишет ПО так, как ему кажется логичным (и часто ошибается, так как логика программиста <> логика бизнеса),

2. Он начинает задавать вопросы, которые позволят ему понять как конкретно писать код, выполняя при этом роль аналитика. Так как в голове у него меньше знаний про использующие системы, он задает больше вопросов и медленнее формирует модель решения. Время ожидания увеличивает time2market, заказчик недоволен.

Умение для ИТ аналитика

Когда мы говорим про ИТ аналитика, то он создает, в том числе, модели создаваемой/изменяемой ИТ-системы и модели ее использования. 

При проектировании в общем случае проектируются:

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

2. Модели пользовательских и интеграционных интерфейсов, соответствующие моделям использования. При этом важно понимать, как поля/таблицы и другие элементы форм соответствуют друг другу и моделям данных (происходит структуризация данных) и какие алгоритмы преобразования возникают.

3. Модели внутреннего хранения данных, при этом важно понять структуру данных (связи объектов друг другу).

4. Модели внутренних преобразований данных (в виде какого-то алгоритма).

Для создания этих моделей требуется алгоритмическое и структурное мышление.

Должен ли ИТ-аналитик создавать все эти модели IT системы ? Да, если эти модели уменьшают неопределенность. То есть не всегда.

Как развивать умение проектировать алгоритмы и структуры данных (развивать алгоритмическое и структурное мышление)? 

Автор сталкивался с двумя вариантами.

1. Аналитик создает модели алгоритма на UML / верхнеуровневом BPMN, после чего преподаватель сообщает где и почему он допустил ошибку.

2. Аналитик пишет код на каком-то языке программирования (включая BPMN для BPMS). Компьютер компилирует/интерпретирует и исполняет код. 

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

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

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

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

Например, учетные программы 

1. не содержат сложных алгоритмов взаимодействия с пользователями/другими системами, поэтому нет смысла их проектировать (и учится в их создании путем изучения процедурных языков программирования),

2. содержат не простую логику преобразования данных (как правило, реляционную), поэтому имеет смысл проектировать модели их преобразования. Например, с помощью изучения SQL.

Дополнительная польза

1. Развивая конкретное ПО, аналитик плотно работает с разработчиками этого ПО. Для взаимодействия нужно выработать общий язык, глоссарий. Если аналитик хорошо понимает термины языка разработки (их назначение), то объясняться проще. При этом есть обратный феномен: если аналитик не очень хорошо понимает термины, то он может что-то перепутать, а программист-кодер может запрограммировать “как написано”.

2. Владение инструментами обработки и анализа данных (Excel, Phyton, SQL, ..) позволяет аналитику изучать проблематику задачи, опираясь не на мнения, а на факты и, кроме того, готовить данные для инициализации системы.

3. Знание языка программирования конкретного ПО позволяет самостоятельно проводить reverse engineering. 

Итого

1. ИТ аналитику нужно уметь создавать детальные модели данных и алгоритмов, чтобы уменьшать неопределенность и уменьшать time2market;

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

3. На каком языке программирования учиться (BASIC, Phyton, SQL, MDX) зависит от того, какое ПО создается; разные типы решаемых задач требуют разных моделей алгоритмов.