История развития аналитики в IT
Впервые в IT — сначала Основы компьютерной грамотности, затем основы анализа требований.
ERD — Entity Relationship; SQL — SQL для аналитики, SQL; миграции — Пакетная работа. Полная таблица — о разделе.
Play ITЗагрузка интерактивного демо…
История развития аналитики в IT
Истоки
Аналитика как способ познания и принятия решений существовала задолго до появления компьютеров - собственно, в древности люди тоже анализировали данные. Пример - учёт урожая, распределение ресурсов, военные стратегии. Это всё аналитика, но современное понимание этой науки отличается от классического, особенно в контексте информационных технологий, и формировалось оно постепенно, под влиянием развития науки, экономики и техники.
Аристотель имеет два сочинения - "Первая Аналитика" и "Вторая Аналитика", и это были просто рассуждения с логическим мышлением. Здесь важно отметить, что Аристотель называл формальную логику "аналитикой", а слово "логика" стали использовать позднее, после его смерти.
Поэтому да, аналитика существует ещё с древнейших времён.
Финансовые аналитики
Финансовая аналитика — это процесс анализа финансовых данных и показателей компании (или физического лица) для оценки текущего финансового состояния, выявления тенденций, прогнозирования будущих результатов и обоснования управленческих решений.
В начале XX века термин "аналитик" ассоциировался с бухгалтерами, экономистами и статистиками - специалистами, которые обрабатывали данные для прогнозирования, выявления тенденций, оптимизации процессов и поддержки управленческих решений. Эти профессионалы анализировали финансовые отчёты, рыночные показатели и производственные циклы, но их работа была в основном ручной и не связывалась с автоматизированными системами (всё правильно, ведь систем не было!). В зависимости от области деятельности, аналитики работали в финансах, маркетинге, медицине, научных исследованиях и даже промышленности.
И представьте, как нужно было прогнозировать? Перед вами выгружают вагон с отчётами, которые писались вручную различными филиалами или подразделениями, и нужно было всё это изучить, структурировать, систематизировать, подготовить сводку, сделать выводы, какие-то прогнозы и в конце концов резюмировать это всё. Грязная работа, которая "выручает" начальников и руководителей, которым главное - понимать, куда всё идёт. Именно поэтому "бухгалтера" были приближенными в любом бизнесе, ведь они сочетали эти функции, порой и без специально выделенных для этого людей. Причем это только финансовые показатели, порой требовалось анализировать чужие отчеты, результаты деятельности конкурентов, чтобы понимать, у кого имеются полезные решения. Тем не менее, этим и занимается аналитик - сбор данных из различных источников, обработка этих данных от ошибок, дубликатов, пустых значений, формирование выводов и предложений.
Поэтому можно сказать, что сначала аналитики были именно финансовые и маркетинговые. Но мир, бизнес и экономика стремительно развивались - с появлением каждой новой технологии или изобретением устройств, отрасли менялись, и требовалось во всё это погружаться.
Эпоха компьютеризации
С приходом эпохи компьютеров в середине XX века ситуация уже изменилась, ведь в 1950-1960-х годах первые ЭВМ начали внедряться в государственные и корпоративные структуры, и возникла острая потребность в людях, способных "переводить" бизнес-задачи на язык машин. Тогда и появился термин "системный аналитик" (Система analyst). Его роль заключалась в том, чтобы понимать как бизнес-требования, так и технические возможности систем, выступая посредником между заказчиками и программистами.
Первые системные аналитики, разумеется, были инженерами или математиками, ведь вся вычислительная сфера была связана именно с ними. Это потом они переквалифицировались в IT окончательно. Они проектировали архитектуру систем, определяли потоки данных, разрабатывали спецификации - всё это требовало глубокого понимания как логики бизнеса, так и принципов работы программного обеспечения. Появление понятия "бизнес-логика" стало естественным следствием, ведь это та часть системы, которая отражает правила, процессы и политики организации, отличные от технической реализации.
Рост бизнеса
К 1980-1990-м годам, с ростом сложности программных продуктов и масштабов автоматизации, роль аналитика стала более специализированной. Разделение труда привело к появлению нового термина "бизнес-аналитик". В отличие от системного аналитика, фокусировавшегося на технических аспектах, бизнес-аналитик сосредоточился на изучении потребностей бизнеса, моделировании процессов, сборе и документировании требований. Он стал ключевой фигурой на стыке управления и технологий.
Изначально понятие "аналитик" в IT считалось производным от других профессий и не имело чётких границ. Только к началу 2000-х годов, с развитием методологий управления проектами (PMBOK, PRINCE2) и стандартов вроде BABOK (Business Analysis Body of Knowledge), профессия бизнес- и системного аналитика окончательно оформилась как самостоятельная дисциплина с собственными компетенциями, сертификациями и карьерными траекториями.
Так что профессия аналитика в IT имеет двоякое происхождение - аналитик сам по себе существовал с древности, системный аналитик был больше математиком, а бизнес-аналитик и вовсе новая профессия.
Упорядочивание
И если первые компьютеры были именно академическими инструментами, а техногиганты изначально заключали контракт с небольшими компаниями с всего несколькими разработчиками, процесс был совсем иным, как и подходы к разработке - всё было хаотично, так как они были первооткрывателями. Позднее, с ростом индустрии и увеличением количества компаний разработчиков, стало очевидно, что одним договором, устными встречами и простыми текстовыми описаниями требования описывать уже недостаточно. Нужны были какие-то унифицированные языки моделирования, которые бы позволяли визуализировать процессы, структуры и поведение систем. Именно здесь на сцену вышли стандартизированные нотации, ставшие инструментами профессионального аналитика.
Когда заказчик (инициатор) формирует идею, она, как правило, устная и размытая, но содержащая основную цель и бизнес-логику. Но когда дело доходит до документирования таких целей, в игру вступают юристы - а юридический язык крайне тяжелый, ведь он избегает "лишних слов", и действует исключительно с целью "засудить" и "защититься от суда", словом, прикрывает задницу. Но дайте юридический документ математику - он поседеет! Поэтому аналитику приходилось "расшифровывать" такие документы, рисовать для себя более наглядную модель и описывать документацию. Каждый рисовал, ведь одно дело общие требования, но когда тебе нужно формировать архитектуру решения, из документа легко вытащить лишь сущности, а связи между ними - куда сложнее. Поэтому рисовалась схема связей между сущностями, но каждый делал это по своему, без единого подхода.
UML
В середине 1990-х годов был разработан UML (Unified Modelling Language), ставший результатом объединения нескольких подходов к объектно-ориентированному моделированию. Ключевые фигуры — Грейди Буч, Айвар Джекобсон и Джеймс Рамбо (образовали так называемую "Банду трио"). В 1997 году UML был официально принят OMG (Object Management Group) как международный стандарт. UML позволил аналитикам и разработчикам описывать архитектуру ПО с помощью диаграмм — вариантов использования, классов, последовательностей, состояний и других. Это резко снизило недопонимание между командами.
BPMN
BPMN (Business Process Model and Notation) появился позже, в начале 2000-х. Конкретно, BPMN 1.0 изначально разрабатывался Business Process Management Initiative (BPMI), а в 2005 году был передан OMG, который официально стандартизировал его. BPMN стал "языком" для описания бизнес-процессов в наглядной, графической форме. Благодаря простоте восприятия и богатой семантике (шлюзы, события, потоки) он быстро стал стандартом в бизнес-аналитике, особенно в банках, логистике и государственных структурах - сейчас это стандарт BPMN 2.0, появившийся в 2011 году.
Стандартизация этих и иных нотаций (вроде ERD (Entity-Relationship Diagram) для моделирования данных, DFD (Data Flow Diagram) и IDEF) означала, что аналитик больше создавал общепонятные артефакты, которые могли использоваться на всех этапах жизненного цикла ПО: от анализа требований до тестирования и сопровождения.
То есть, без аналитики, раньше разработка ПО частенько начиналась с кода, программисты понимали задачу "на слух", и сразу приступали к реализации. А как мы помним, зачастую источником задачи был именно заказчик. Это приводило к множеству ошибок, переделок и "неправильным" продуктам. Далеко ходить не надо - фрилансеры с заказами, техническое задание которых ограничивалось фразой "сделай мне сайт", понимают, о чём я. Позднее аналитик стал ключевой фигурой на старте проекта, ведь именно он собирал, уточнял, моделировал, документировал и координировал, что делало процесс системным. Особенно важной аналитика стала в условиях высокой стоимости ошибок. Чем позже обнаруживается ошибка в требованиях, тем дороже её исправление. По оценкам IEEE и исследованиям Standish Group, исправление ошибки на этапе эксплуатации может быть в 100 раз дороже, чем на этапе анализа.
Катастрофы
История IT полна примеров катастроф, вызванных игнорированием аналитики. Можно выделить два ярких случая.
Первый - проект NHS Connecting for Health (Великобритания, 2002–2013), одна из самых масштабных неудач в истории государственных IT-проектов. Целью ставили создать единую электронную медицинскую систему для всей Англии, проект стоил более 12 миллиардов фунтов стерлингов, но был закрыт с минимальными результатами. Причинами провала были такие проблемы, как отсутствие чёткого анализа потребностей врачей и больниц, непродуманная архитектура, пренебрежение бизнес-процессами здравоохранения, слабая роль аналитиков на начальных этапах. Вместо глубокого анализа внедрялись "коробочные решения", которые не работали в реальных условиях. Работавшие в государственных структурах поймут, о чём речь - "добровольно-принудительное внедрение" без учёта интересов.
Второй - крах системы учёта труда в компании Hewlett-Packard (2010). HP внедряла новую систему учёта рабочего времени для 65 000 сотрудников. Проект провалился — система не учитывала локальные особенности стран, правила начисления оплаты были ошибочны, что привело к неверным выплатам и судебным искам. Причины - недостаточный анализ требований в разных регионах, отсутствие моделирования бизнес-логики, недооценка роли бизнес-аналитиков при глобальной автоматизации.
Что забавно, проблема игнорирования или недооценки важности аналитики существует всегда - практически на каждом проекте заказчику нужно "быстрее", он продавливает именно свою точку зрения и собственное видение, которое порой бывает рискованным или необдуманным. Если он продавит, и решение окажется неудачным, он всё равно обвинит команду разработки, что это они всё криво сделали. Сегодня аналитики есть везде, а этап разработки часто может быть короче, чем этап аналитики, ведь это снижает неопределённость, минимизирует риски и повышает шансы на успех проекта.
Как история помогает в текущей работе аналитика
Исторический материал полезен не только "для кругозора". Он объясняет, почему в проектах одновременно живут строгая документация, гибкие методологии, визуальные модели и дата-подход.
Практический вывод для новичка:
- когда бизнес просит "быстро и без бюрократии", аналитик держит баланс между скоростью и проверяемостью;
- когда команда уходит в "чистую технику", аналитик возвращает фокус на цели и процессы пользователя;
- когда в требованиях слишком много абстракций, аналитик переводит их в сценарии, сущности и критерии приемки.
История профессии показывает, что аналитик всегда закрывает один и тот же разрыв: между замыслом и реализацией.
Мини-кейс из практики
Запрос: "Сделайте отчеты как раньше, только современно".
Без уточнений команда рискует потратить спринт на красивый интерфейс, который не решает задачу руководителя.
Хороший аналитический разбор включает:
- Кто читатель отчета и какое решение он принимает.
- Какие показатели считаются критичными и откуда берутся.
- Какая детализация и период нужны.
- Какие действия пользователь делает после просмотра.
После такого уточнения "современно" превращается в конкретику — формат, фильтры, обновление, SLA, ограничения доступа и критерии готовности.
Связанные статьи для углубления
- Про базу профессии и терминов: Основы анализа требований.
- Про роль аналитика в проекте: Профессиональная аналитика.
- Про перевод целей в измеримые задачи: Как переводить бизнес-задачи на язык данных.
В подборках
Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:
История — Развитие методологий разработки ПО, Великие люди, История языка С, История развития искусственного интеллекта, История ассемблерных языков, История развития интеграционных технологий.