Всем привет! У меня за плечами большой опыт в ИТ - я работал в разных направлениях и на разных должностях. Не так давно мне поступило предложение помочь в проекте, который внешне выбивался из привычного ИТ-русла. Но, как выяснилось, даже он оказался тесно связан с автоматизацией - в наше время без этого практически никуда.
Эта статья для студентов технических ИТ-специальностей. Это не учебник и не методичка. Это история о том, как знания из мира ИТ (даже если вы не станете профессиональными разработчиками) могут сделать вас сильнее в любой другой сфере. Статья для тех, кто сейчас сомневается: «А зачем мне всё это учить, если я не пойду в кодеры?»
Часть 1. Задача: недвижимость без кода, но с бардаком
Представьте гипотетическую ситуацию (очень похожую на реальную, но мы изменим детали). Есть управляющая компания, которая владеет множеством объектов коммерческой недвижимости: офисы, склады, торговые центры, земельны участки. У компании есть несколько отделов:
- Бухгалтерия - считает деньги, налоги, платежи.
- Юридический отдел - отвечает за договоры, регистрацию прав, суды.
- Отдел управления - работает с арендаторами, следит за состоянием зданий.
- Отдел развития - ищет новые объекты для покупки.
Казалось бы, всё как у людей. Но есть огромная проблема: никто не понимает, эффективно ли работает это направление в целом. Отчеты есть у всех, но они противоречат друг другу. Бухгалтерия говорит одно, юристы - другое, управляющие - третье. Оценка работы происходит «по ощущениям». Знакомо? В ИТ это называется «легаси с тысячей костылей».
Нужно было решить задачу: создать систему, которая позволит измерить эффективность каждого отдела и всего направления в целом, а потом предложить изменения, чтобы эту эффективность повысить.
И вот тут я понял, что мой опыт в программировании - это не просто про писать код. Это способ структурировать хаос и особый способ мышления. Именно это и стало главным инструментом.
Часть 2. ООП как способ думать, а не только писать код
Когда изучаешь программирование, одной из важных серьезных тем является Объектно-Ориентированное Программирование (ООП). Классы, объекты, наследование, инкапсуляция, полиморфизм - это кажется просто инструментом для разработки. Но ООП - это и великолепный способ мышления о реальном мире.
В объектно-ориентированном программировании мы говорим: «Всё есть объект». В реальном проекте: «Всё есть объект недвижимости».
Как это сработало на практике
Я предложил команде посмотреть на здания и помещения не как на разрозненные активы, а как на объекты в стиле ООП. У каждого объекта есть:
- Характеристики (свойства): площадь, адрес, кадастровый номер, тип (офис/склад), собственник.
- Методы (функции): «сдать в аренду», «рассчитать налог», «выставить счет», «зарегистрировать договор».
Звучит знакомо, правда? Это же чистое ООП, только вместо языка программирования мы используем язык бизнеса. Конечно, без ликбеза и стадии привыкания не обошлось - но результат того стоил.
Дальше - больше, наследование. Ведь объекты недвижимости бывают разные, но у них есть общие черты:
- Есть объекты, которые находятся в собственности компании.
- Есть объекты, которые компания арендует.
- Есть просто земельные участки.
У всех у них есть общие характеристики (адрес, площадь), но есть и уникальные (для своих - «дата ввода в эксплуатацию», для арендованных - «срок действия договора аренды»). В голове сразу выстроилась иерархия классов. Это помогло нам не запутаться в объектах и не изобретать велосипед для каждого типа.
А инкапсуляция? Мы четко определили, какие характеристики «видны» только внутри отдела, а какие — для всей компании. Бухгалтерия не лезет в юридические тонкости, но обязана предоставить данные о деньгах. Юристы не считают налоги, но именно они отвечают за «чистоту» объекта.
Часть 3. Методологии: Agile не для программистов, а для людей
В ИТ мы привыкли к гибким методологиям (Agile, Scrum). Спринты, демо, ретроспективы, бэклог. И здесь это сработало идеально.
В команде, где не было ни одного программиста, мы начали работать двухнедельными спринтами. Собирались на общие встречи, параллельно вели диаграмму Ганта (да-да, тот самый инструмент планирования), фиксировали задачи в таск-трекере и регулярно делились результатами.
Зачем?
- Чтобы не ждать результата полгода, а видеть прогресс каждые 14 дней.
- Чтобы быстро замечать, когда кто-то «уходит в кусты» и не предоставляет данные.
- Чтобы сами участники проекта видели свой вклад в общее дело.
И это сработало! Бухгалтеры, юристы и управляющие, которые никогда не слышали про Agile, через месяц уже не ощущали дискомфорта и трудились как единое целое.
Часть 4. Программистское мышление - это суперсила
Оглядываясь на проект, я понимаю: я использовал многое из ИТ, но в упрощенном виде, адаптированном под живых людей:
- Структурирование сложности. ООП помогло разложить объекты на понятные классы с характеристиками и методами - наши объекты «оживились». Без этого мы бы утонули в таблицах.
- Работа с данными. Я понимал, что такое «источник правды», как избегать дублирования, как связать разрозненные данные из 1С, Excel и голов сотрудников.
- Процессное мышление. Я видел, где в процессах «узкие места», какие операции можно распараллелить, а какие - только последовательно.
- Управление ожиданиями. Спринты, демо, обратная связь - всё это пришло из Agile и помогло не паниковать, а видеть результат.
- Метафоры и объяснение сложного простыми словами. Когда я общался с бухгалтером или юристом, я не говорил про полиморфизм. Я говорил: «Смотрите, у всех объектов есть адрес, но у своих есть ещё и дата ввода, а у арендованных - дата окончания договора. Давайте запишем это красиво, давайте сделаем наши объекты «живыми»». Это и есть та самая способность переводить с технического на человеческий.
Часть 5. ИТ-продукт
Все мы работаем в программах. Но без должного управления и нужных компетенций любой процесс со временем превращается в бесконечные Excel-таблицы. Их становится всё больше, а управлять данными - всё сложнее.
Структурный подход и принципы ООП помогают взглянуть на свою предметную область с другой стороны. Схемы и диаграммы приближают команду к созданию по-настоящему нужных инструментов. Эти инструменты должны убрать (или хотя бы сократить) ручной труд, сделать данные прозрачными и в итоге помочь объективно оценить свою эффективность - не «по ощущениям», а по фактам.
Так получилось и у нас. Использование программистских принципов, их перевод на человеческий язык и принятие командой изменило взгляд людей на их работу. Это помогло не ИТ-специалистам осознанно и структурно подойти к разработке технических заданий для будущих ИТ-инструментов.
И даже если бы в проекте не было этапа разработки, ИТ-подходы всё равно отлично легли бы на проектную деятельность. Они универсальны.
Вместо заключения
Дорогие студенты! Если вы сейчас учитесь на ИТ-специальности и думаете: «Зачем мне эти алгоритмы, эти паттерны проектирования, эта теория объектно-ориентированного программирования, если я не хочу быть программистом?» - задумайтесь об одной простой вещи.
Программирование - это не про код. Это про способ думать.
Код - это просто инструмент. А вот умение раскладывать сложное на простое, видеть структуру в хаосе, выстраивать логические связи, управлять данными, прогнозировать последствия изменений - это суперсила, которая пригодится вам в любой профессии.
Вы можете стать:
- проектным менеджером, который строит не IT-продукты, а управляет застройкой микрорайона;
- бизнес-аналитиком, который разбирается в финансах лучше финансистов, потому что умеет моделировать процессы;
- руководителем отдела, который в одиночку наводит порядок там, где годами был хаос.
Не замыкайтесь в рамках «кодер» или «не кодер». Берите из ИТ лучшее - способность мыслить структурами, объектами и процессами. И тогда перед вами откроются двери, о которых вы даже не подозревали.
Учитесь. Думайте. Структурируйте. И не бойтесь идти туда, где, казалось бы, нет кода, а есть бетон и арендная плата. Ваш ИТ-опыт - это универсальный ключ в будущем и настоящем.