Мы давно живём в цифровом мире, нас окружают полезные онлайн-сервисы, видеохостинги, стиминговые площадки, платформы для блогеров, новостные агрегаторы, интернет-магазины, маркетплейсы и многое другое. В этом мире живут не только IT-специалисты, в нем живём мы все вместе. Но до сих пор при общении между IT-специалистами и «неайтишниками» часто возникает непонимание, которое выливается во взаимные претензии. IT-специалисты жалуются на то, что их заставляют заниматься бесполезным трудом и не могут нормально сказать, чего от них хотят. Со стороны «неайтишников» часто слышится: «Ох уж эти программисты, опять долго, дорого и не то». Давайте разберёмся, зачем IT и цифровизация нужны для "неайтишников" и как ими правильно пользоваться. На простом и понятном обеим сторонам языке.
Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).
Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.
Немного отвлечёмся от большой темы "IT для неайтишников: Какими бывают IT-шники?" (Часть 1 и Часть 2), публиковаться она будет долго, буду разбавлять её другим материалом. Здесь просто рассмотрим, зачем вообще нужна область IT для представителей других отраслей. Потом в одной из следующих статей рассмотрим интересный вопрос: "Куда деваются программисты после 40 лет".
Область информационных технологий (IT) и цифровизация существуют не сами по себе, они обычно для чего-то нужны. Когда они становятся самоцелью и к ним начинают стремиться только потому, что они уже у всех есть, значит и нам надо, начинаются проблемы. В этот момент забывают, что IT и цифровизация нужны либо для снижения издержек бизнеса (производства), либо для увеличения выручки бизнеса.
Далее в статье мы будем рассматривать взаимодействие IT и Бизнеса. При этом стоит понимать, что «бизнес» можно заменить на предприятие, организацию и другое. В целом даже с точки зрения государства будет очень много сходных моментов.
Когда об этом забывают, технические специалисты начинают выгорать от невозможности самореализации и того, что вынуждены тратить свою жизнь на бесполезный и ненужный труд. С другой стороны, представители бизнеса начинают страдать от высоких и бесполезных затрат на IT и потери конкурентных преимуществ. То есть страдаю - обе стороны.
К сожалению, сегодня область IT во многом изолированна. В ней существует свой язык и высокий порог входа, нельзя просто так взять и понять IT. Из-за этого возникают проблемы, когда технические специалисты не могут объяснить представителям бизнеса даже простые вещи. Для технических специалистов эта статья будет полезна возможностью оглянуться на самих себя и посмотреть на свою работу с точки зрения бизнеса и пользователей. Для «неайтишников» статья даст возможность немного лучше начать понимать IT-мир, начиная с того, зачем он вообще существует и какую пользу можно извлечь из дружбы с IT.
Давайте для примера представим бизнес, который занимается пошивом одежды. Теперь честно ответим на вопрос, а для того, чтобы шить одежду, необходимо ли использовать информационные технологии и цифровизацию? Нет, можно обойтись без них, ведь шили ли же одежду в XIX веке, когда ещё не было никаких компьютеров?
А сможет ли существовать крупное швейное производство в XXI веке без применения информационных технологий? Скорее всего, нет. И дело не в том, что информационные технологии необходимы для пошива одежды, дело в том, что бизнес перестаёт быть конкурентоспособным.
Все дело в том, что IT даёт цифровизацию, а затем и автоматизацию бизнес-процессов, в какой-то момент и роботизацию процессов в организации. Кроме этого, IT предоставляет новые каналы сбыта продукции. Всё же информационные технологии во многом опираются на средства связи и массовых коммуникаций, для бизнеса это каналы, по которым можно обращаться к своему потребителю и даже получать от него обратную связь. Если в начала XX века приходилось печатать бумажные каталоги и рассылать их по почте, вкладывая в них конверты с марками, для обратной связи, то в начале XXI века все много проще и быстрее.
Бизнесу интересны цифровизация, автоматизация (и роботизация), новые каналы сбыта продукции. С их помощью бизнес может снижать издержки и повышать выручку. Разберёмся подробнее в этом вопросе, а после посмотрим, какие проблемы могут возникать между IT и Бизнесом.
Цифровизация. Зачем нужна?
По большому счёту здесь следует воспользоваться бритвой Оккама и не плодить лишних сущностей без необходимости. Это всего лишь процесс переноса информации с физических носителей в цифровой вид. Можно просто взять тот нецифровой процесс, который сейчас существует в вашей организации и перенести его в цифровой вид. Так что же все с этим так носятся?
Давайте, к примеру, возьмём трудовые книжки. Сейчас идёт процесс цифровизации, то есть отказ от бумажных трудовых книжек в пользу электронных трудовых книжек. Это значит, что государству больше не придётся выпускать бланки строгой отчётности, работодателям не придётся их покупать, сотрудник отдела кадров больше не будет хранить и заполнять физические трудовые книжки. Все данные, которые были в трудовых книжках, теперь будут храниться в недрах серверов Госуслуг. И когда человеку понадобится копия трудовой книжки, уполномоченному сотруднику не придётся расписываться на каждом скане трудовой (есть сотрудники у которых два и более вкладышей в трудовую), вместо этого человек просто получит копию трудовой книжки в своём личном кабинете на Госуслугах.
Таким образом, у многих людей пропадает лишняя работа и лишние затраты, высвобождая ресурсы для чего-то другого. Только бухгалтерии добавили ещё один отчёт, который на ежемесячной основе передаётся в налоговую в цифровом виде.
В результате с помощью цифровизации снизили затраты и высвободили ресурсы по всей цепочке сквозного процесса учёта (от государства через работодателей назад к государству). Но это ещё не все, ведь увеличили качество собираемых данных и подготовили их для последующей обработки.
Цифровизация — это лишь начальная стадия. После неё у государства будет централизованная система сбора данных о трудовых перемещениях граждан, которая позволит выявлять аномалии, например, людей с двумя трудовыми книжками (а они есть), и проводить метаанализ данных. Например, выявлять работодателей, которые платят в белую ниже по рынку, которые перевели своих сотрудников в самозанятые либо в ИП, да и многое другое.
То есть, кроме снижения затрат, за счёт цифровизации была усилена система контроля и учёта. А ещё увеличена отзывчивость системы, то есть данные по учёту можно получать очень быстро.
Важны ли такие возможности? Очень. Именно поэтому растёт потребность в ERP системах, которые собирают информацию по управленческому учёту в одном месте. Бизнес хочет быстро получать качественные данные для принятия управленческих решений. Чем более нестабильна среда вокруг, тем быстрее и качественнее нужно получать данные.
Автоматизация. Зачем нужна?
Представим, что информация по происходящим процессам в организации уже перенесена с физических носителей в цифровой вид и уже добились, чтобы собираемая информация поступала своевременно и не содержала противоречий (то есть нет ошибок и махинаций). Следующим этапом является автоматизация.
При автоматизации часть тех действий, которые до этого делал человек, начинают выполняться за него «автоматически». Например, как аналогия, если в автомобиле механическая коробка передач, то водитель будет вынужден ногой отжимать педаль сцепления, а потом рукой передвигать рычаг переключения передач. Если в автомобиле автоматическая коробка передач, то водитель просто перестаём думать о переключении передач, этот процесс для него происходит без его участия. Комфорт управления автомобилем (организацией) повышается.
Например, возьмём сеть розничных магазинов, которые продают какую-то продукцию, для которой установлен неснижаемый остаток. То есть, как только будет пройден определённый минимум остатка на складе, создастся автоматический заказ на склад для поставки ещё одной партии товара.
Можно ещё лучше. Система может сама отслеживать динамику продаж во всех розничных магазинах сети, на основе статистических данных предсказывать спрос и автоматически формировать заказ на производство, чтобы успеть произвести необходимую продукцию и доставить на нужные точки продаж нужное количество продукции. Таким образом начинает действовать автоматизированный процесс планирования поставок товара.
Конечно, скорее всего, люди будут продолжать участвовать в этом процессе. Просто этих людей будет много меньше, не нужно будет тратиться на ФОТ для лишних сотрудников и нести накладные затраты на организацию и обеспечение их рабочих мест. То есть будут снижены затраты на процесс и повышена скорость прохождения процесса. Время — деньги, низкая скорость реакции — упущенные возможности.
Обычно сначала проводится цифровизация имеющихся процессов, после чего начинает быстро поступать качественная информация, пригодная для принятия управленческих решений. Затем уже производится автоматизация, при которой сокращаются этапы процессов и переносится их выполнение с людей на информационные системы.
Давайте спросим себя, а стоит ли игра свеч, ведь IT такое дорогое? Игра того, конечно, стоит. При качественном внедрении цифровизации и автоматизации затраты на выполнение бизнес-процессов падают многократно, даже с учётом затрат на IT-шников. Без них получается дольше и дороже.
Но решение о том, что и как автоматизировать стоит принимать самому бизнесу, ориентируясь на соотношение выгод и затрат. Нельзя спрашивать условного «программиста», как лучше автоматизировать бизнес, он будет делать так, как удобно ему, а не бизнесу.
Вы же не отдаёте управление бизнес-процессами их исполнителям? У процесса всегда есть его владелец, с которым можно поговорить, как бизнес с бизнесом. Процессы цифровизации и автоматизации исключениями не являются. В ином случае, за счёт высокой стоимости IT-специалистов, может получиться обратный эффект. Вместо кратного сокращения затрат получить кратный рост затрат не только за счёт ФОТ IT-специалистов и накладных на них, но и за счёт добавочного труда не IT-специалистов.
Роботизация. Что такое?
Роботизация — это особый вид автоматизации. При автоматизации процесса, может получится новый процесс, который будет сильно отличаться от исходного ручного процесса. Когда роботизируется процесс, то процесс остаётся в целом таким же, но то, что раньше делал человек «своими руками» начинает делать «робот».
Если в промышленном производстве роботизированные линии дают гибкость и скорость перенастройки, то в IT всё немного не так. Из-за того, что исходный процесс почти не меняется, повышается скорость и сокращается стоимость внедрения изменений.
На примере той же автомобильной коробки передач. Есть автоматическая коробка передач, которая по своему устройству кардинально отличается от механической коробки передач, поэтому и стоит она дороже. А есть роботизированная коробка передач, которая представляет из себя механическую коробку передач и робота поверх неё, который за водителя выжимает сцепление и переключает передачи. У этого робота есть программа, которая решает, когда и как переключить передачу. Программы бывают разные, под разный стиль вождения. При смене программы менять механическую часть не надо.
Упрощённый пример роботизации в бизнесе. Например, организация принимаете заказы по телефону. В ходе звонка оператор задаёт до 10 вопросов по скрипту, и на основе ответов заводит заказ покупателя в CRM-системе (система управления взаимоотношениями с клиентами). В какой-то момент в организации реализуется telegram-бот, который вместо оператора общается с заказчиком и передаёт заказ в CRM. Заказчик отвечает на те же вопросы, что и раньше, но уже не оператору. То есть произошла роботизация (и автоматизация) процесса. Тем самым организация сократила затраты на свой колл-центр.
Конечно, уровень современных технологий позволяет сделать голосового робота, который будет распознавать речь заказчика и общаться с ним почти, как оператор колл-центра по скрипту. Только он будет всегда доступен и не будет уставать, ошибаться, болеть, уходить в отпуск и т. д. Однако, стоимость такого «голосового помощника» много выше, чем у telegram-бота.
Что выгоднее для бизнеса должен решать только сам бизнес. IT, как служба, должна выдать бизнесу предложения на цифровизацию, автоматизацию и роботизацию в доступных вариантах с оценкой стоимости внедрения и владения. Бизнес в свою очередь, понимая какие выгоды он может извлечь и какие затраты для этого он должен будет понести, делает выбор из предложенных вариантов. Помним, что управленческие решения принимаются бизнесом на основе баланса выгод и затрат.
Цифровые каналы сбыта. Это как?
Допустим, у организации были только оффлайновые розничные магазины. Но в какой-то момент было принято решение создать интернет-магазин, то есть создать новый канал сбыта продукции. Если раньше для покупки нужно было ехать в оффлайновый розничный магазин, который есть ещё не в любом городе, то теперь у покупателя появилась возможность совершить покупку онлайн.
Значит, если раньше целевой аудиторией организации были жители населённых пунктов, где присутствовали оффлайновые магазины, то теперь целевая аудитория изменилась и расширилась. Теперь организация ориентируется на людей, у которых есть доступ к её интернет-магазину, и которым она может доставлять свою продукцию.
Вслед за изменением целевой аудитории меняется способ коммуникации с ней. Например, появляется возможность использовать контекстную рекламу. Либо можно более активно использовать социальные сети и многое другое. Как результат, появилось даже новое направление Digital-маркетинг.
Кроме того, появляются новые возможности типа маркетплейсов. Они делают много работы по внешнему маркетингу за своих поставщиков. У них своя реклама, свои акции, свои методы привлечения покупателей, часто очень эффективные. По сути это большой интернет-магазин на множество поставщиков, цифровой торговый центр.
Однако, если мы говорим о маркетплейсах, то всё равно придётся заниматься маркетингом, но внутри самого маркетплейса. Как минимум, следить за тем, чтобы карточки именно вашего товара выдавались первыми покупателю. И ещё много всего остального.
Для бизнеса всё просто — это новые каналы сбыта и способ увеличить выручку, используя преимущества цифровой среды и современные средства коммуникации.
Так в чём проблема-то?
У информационных технологий есть один интересный минус. Да, это эффективный инструмент, но им нужно уметь пользоваться. Иначе вместо большой пользы можно получить большой вред. Беда в том, что IT-специалисты предпочитают между собой говорить на каком-то своём языке, который очень не похож на бизнес-язык.
Вот сейчас мы с вами обсуждали IT на языке, который понятен очень широкой аудитории. А когда бизнес приходит к IT-специалистам, можно услышать нечто вроде: «У нас тут демон на одном из микросервисов обожрался памяти и упал, из-за чего данные перестали передаваться к дата-сатанистам, ну и в биайке не появились». Вот что должен был из этого нормальный человек понять? Какое управленческое решение можно тут принять?
Часто это заканчивается инстинктивным решением позвать переводчика с птичьего на нормальный. То есть организовать мостик между бизнесом и IT. Приходит такой человек, слышит, что ему говорят, после чего спрашивает: «А чего у вас демон по памяти течёт? Нормально написать не можете? Ну, сделайте его перезапуск по крону». Фактически на глазах бизнеса произносится какое-то заклинание, после чего проблема действительно решается.
У такого решения есть один большой минус. Бизнес-заказчиков обычно много, IT-шников тоже много. И вот тот мостик между бизнесом и IT перегорает под напряжением, как тонкий медный проводок между двумя мощными электроагрегатами.
Цифровизация неумолимо входит в нашу жизнь, у бизнеса растёт необходимость понять и овладеть цифровыми инструментами. Да, мостики останутся, но коммуникативный разрыв нужно сокращать.
Кроме того, сегодня IT - это хоть и сложная для понимания тема, но не «рокет сайнс» (не так сложно, как запустить человека в космос в 70-х годах XX века). И если объяснять происходящее на нормальном языке, то бизнес очень быстро разберётся в IT на необходимую для него глубину. Всё же бизнес — это профессионалы, которые состоялись в своей области, это не глупые люди.
Почему IT не говорит с бизнесом на человеческом языке? По разным причинам. Иногда просто не хватает коммуникационных навыков. Иногда это просто JSDD (Job Safety (Security) Driven Development, подробней в Как писать код, чтобы тебя не уволили?). Иногда что-то ещё.
Вот и приходится пытаться "неайтишнику" погрузиться в тему IT, чтобы понять, какие возможности оно даёт, чтобы понимать, что там происходит. Прежде всего для принятия управленческих решений в своей профессиональной области.
Подводя итоги
Мы только что обсудили цифровизацию, автоматизацию и IT на понятном для всех (как я надеюсь) языке. То есть убедились, что это вообще можно сделать, это не страшно и не так сложно.
Область информационных технологий не такая труднодоступная для понимания, как в 70-80 годах XX века. Да, есть сложности, но они есть везде. Неужели кто-то думает, что управлять большим швейным производством легко и что там сложностей нет? Конечно, они там есть, их там не меньше. Люди же как-то с этим разбираются.
Остаётся дело за малым, чтобы кто-то на простом языке, хотя бы поверхностно, рассказал что есть что в ИТ. В идеале этому должны научиться сами IT-специалисты. Неплохо, чтобы такие люди были и со стороны бизнеса, для этого им понадобится как-то разобраться «во всём этом IT». Чем меньше будет коммуникационный разрыв, тем больше таких людей будет появляться с обеих сторон.
Значит, бизнес будет чаще и проще достигать своих целей, а IT-специалисты перестанут выгорать от невозможности самореализоваться. Обе стороны смогут гордиться тем, что они создали что-то востребованное для множества людей.
Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.
Полезные материалы по теме:
- IT для неайтишников: Зачем оно нужно?
- IT для неайтишников: Какими бывают IT-шники? Часть 1
- IT для неайтишников: Какими бывают IT-шники? Часть 2
- IT для неайтишников: Какими бывают IT-шники? Часть 3
- IT для неайтишников: Какими бывают IT-шники? Часть 4
- IT для неайтишников: Какими бывают IT-шники? Часть 5
- IT для неайтишников: Какими бывают IT-шники? Часть 6
- IT для неайтишников: Куда исчезают программисты после 40 лет?
- IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
- IT для неайтишников: Технический долг или почему теперь всё так долго?
- IT для неайтишников: Осторожно - JSDD (Бизнес в заложниках у IT)
- Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
- Процессы в ИТ: Долго, дорого и не то
- Саморегуляция в ИТ: минимально допустимая эффективность работы
- Telegram-канал Записки ITBP (короткие сообщения)
- Канал на Дзен Записки ITBP (статьи среднего размера)
Честно, все это напоминает ситуацию, когда люди пытаются доказать "мы не такие как все", но на самом деле ты такой же как и все. И сленг не делает тебя круче или лучше. Извините, но по своему опыту знаю, гораздо больше клиентов у человека будет, если исполнитель может говорить на обычном языке, что впринципе заложенно в каждого человека от рождения. А блеснуть жаргоном в разговоре, где он собственно не в тему пытается каждый и говорит лишь о том, что у товарища словарный запас скудноват и пользы никому не будет от этого
Здесь есть одна маленькая проблема. В статье ничего не продается, а только описывается общий подход. Не компании, которая будет оказывать услугу, а для заказчика этой услуги.
Поэтому, объективно, тут нет смысла кому-то доказывать "Что мы не такие, как все". Какая кому от этого разница, если никто ничего никому не продает? :о)
Дальше, в статье умышленно не использовались жаргонизмы и целенаправленно использовался язык для общей аудитории. Как раз чтобы снять те вопросы, которые часто возникают у представителей бизнеса. Поэтому я не совсем понимаю ту мысль, что вы хотите выразить.
Эммм... А как так случилось, что Вы не знаете о существовании бизнес-аналитиков? Большие проекты с большими клиентами не делали?
Я бы не назвал бизнес-аналитиков сотрудниками только крупных компаний, в МСБ их тоже хватает. Но если мы берем именно крупные компании, то вот именно там для бизнес-аналитиков приходится переводить с технического на обычный и помогать более-менее корректно ставить задачи.
Почему-то местные системные-аналитики и архитекторы различных уровней им не слишком в этом помогают.
Мда... Все таки не делали большие проекты. БА — это часть ВАШЕЙ проектной команды. Если Ваш бизнес — перепродажа рабочих часов Ваших разрабов, то БА Вам действительно не нужны. А если у Вас нормальный большой проект с большим заказчиком, например, Вы end-to-end отвечаете за внедрение кредитного конвейера в банке, то Вам просто не заплатят денег (а скорее и неустойку вкатают за несоблюдение дедлайнов), если Вы не предъявите спеки, подписанные бизнес-заказчиками. Не клиентскими ИТшниками, которые в космосе, а конкретными людьми, отвечающими за выполнение плана розничных продаж банка. Так что Вы наймете себе БА, который и будет переводить "с технического на бизнесовый" и проблема, описанная в Вашей стате, решится сама собой. У Вас текст... Рассуждение о возможных плюсах квадратного колеса — "пусть бизнес самообразуется в ИТ", — когда квадратное уже пробовали несколько тысяч лет назад, выкинули на помойку, и с тех пор используют круглое (нанимают БА).
Беда в том, что вы сейчас ссылаетесь на проект среднего размера. И не учитываете, что в крупных компаниях для крупных проектов заботятся о том, чтобы оставить экспертизу внутри домашней команды. Поэтому, бизнес-аналитик используется «домашний», причем именно он собирает БТ еще до того, как к подрядчикам за коммерческими предложениями обратятся.
Кроме того, никогда не слышал, чтобы договора и акты сдачи подписывали представители технической команды. Обычно это либо C-уровень либо представители бизнеса.
Ну и в ряде компаний среднего бизнеса так же. На серьезных проектах предпочитают использовать именно своих бизнес-аналитиков, а не чужих.
При этом нужно отметить, что эти внутренние бизнес-аналитики специалисты весьма сильные, но говорят они на бизнес языке. Технический они понимают весьма плохо, иллюзий тут не должно быть никаких.
Мне кажется наоборот. Самый большой был с командой в 180 чел (это только моих) на протяжении нескольких лет.
оставить экспертизу внутри домашней команды1. Большие проекты как раз отдают тем, кто может убедительно показать опыт и понимание бизнес-части. Просто команд разработки вокруг — хоть %опой жри (но за хорошую конечно придется заплатить премию).
договора и акты сдачи подписывали представители технической команды. Обычно это либо C-уровень либо представители бизнеса2. Да, конечно. Но для этого необязательно сразу передавать критичные функции клиентским ресурсам, которые для Вашей проектной команды будут "людьми со стороны". Гораздо эффективнее это делать, когда решение уже на 80-85% работает — т.е. 2-3-4 крупных релиза уже сделали — и дальше плавно передаешь поддержку и доработку остальных 15-20%. Знания дает столько же, — даже небольшие мелкие доработки заставят разобраться в том, как работает все решение, — а проектных рисков несравнимо меньше. Но такой подход надо:
а) Убедительно продать,
б) Ваш прошлый опыт должен заставить клиента к Вам прислушаться.
3. Если клиентский БА "не тянет", а неспособность эффективно медиировать диалог между бизнесом и командой разработки — это и есть "не тянет" для БА, — то кто Вам мешает убедительно, с примерами объяснить это клиенту? Дальше или клиент платит за Вашего БА или Вы отвечаете только за разработку, а интерфейс между клиентским БА и Вашими разработчиками четко и детально прописан и Вы не несете ответственность за косяки клиентского БА. Ну или Вы отказываетесь от проекта — сплошь и рядом есть тендеры, которые лучше проиграть.
Договор и Акт Вам может подписать только чел с доверкой от юрлица, а таких по определению немного. Но он их обычно подписывает десятки и сотни в день. Так что до этого, надо еще собрать кучу согласований от бинес-заказчиков "внизу".
эти внутренние бизнес-аналитики специалисты весьма сильные, но говорят они на бизнес языке. Технический они понимают весьма плохо1. Если клиентский БА может выдать только БТ, но неспособен разъяснить их разработчикам, то продайте клиенту системных аналитиков. СА — это тоже вполне официально определенная проектная функция.
2. У меня ощущение, что у Вашей разработки нет специализации в какой-то бизнес-области какой-то отрасли. Если разработчик один-два раза сделал тот же кредитный конвейер в разных банках, то он без всяких БА на 80% знает как может быть устроен кредитный процесс. Но если он сегодня пилит склад для какой-нибудь строительной компании, а завтра — HR систему премирования сейлзов в банке, да и еще у него опыта работы на "кровавый энтерпрайз" — пара лет, — то для него каждый раз будет как в первый раз.
Знаете, я как-то привык мерить размер проекта сложностью и объемом функционала, а не тем, сколько и как долго человек пыталось сделать проект. Как бы имел возможность наблюдать, как сколько-то сотен человек пытались работать, а другие несколько сотен человек успешно им мешали. Поэтому все двигалось очень медленно в моем представлении. В представлении рынка - стремительно развивалось.
Что до косяков клиентского БА. Нет, они будут, обязательно, ведь проект большой. Но наверное не зря будут работать руководители проектов, архитекторы, системные аналитики и UI/UX-специалисты, которые все вместе напишут проектное решение, которое согласуют стекхолдеры? И какой смысл БА на большом проекте общаться с технической командой? Для того чтобы что?
Вспоминаем про руководителя проекта, UI/UX специалиста, системного аналитика и архитектора. Они же не просто так в жизни появились?
А перекладывать знания предметной области в головы разработчиков и терять возможность их быстро и внятно описать в текстовом виде, чтобы исполнитель за одно прочтение все понимал и ничего не додумывал сам, это плохая идея. Перекладывание ответственности с одной роли на другую, пользы от этого нет, один только вред.
Это был хороший, сложный проект :) Просто не хочу называть, т.к. это будет моментальный само-деанон :)
какой смысл БА на большом проекте общаться с технической командой? Для того чтобы что?терять возможность их быстро и внятно описать в текстовом виде, чтобы исполнитель за одно прочтение все понимал и ничего не додумывал сам, это плохая идея.
Вот мы и подошли к корню проблемы из-за которой родился Ваш текст. Ваш подход:
1. Команда разработки может позволить себе обладать нулевыми знаниями предметной области.
2. Т.к. клиент хочет ставить своих БА (а рискну предположить, что это не пропроблема не в клиентских БА, а в том, что своих БА с многолетним опытом в конкретной бизнес-области конкретной отрасли у Вас нет), то это обязанность клиентского БА — и отрасль и компанию знать досконально, и суметь до мельчайших деталей расписать функционал для "абсолютно нулевых" в отрасли разработчиков.
Таких БА у клиента в принципе не может быть, работа клиентских БА — знать процессы конкретной компании (даже не отрасли вообще), а не технологии. Они с января по июль какую-то транзакционную систему пилят, а с июля по декабрь — систему отчетности. Естественно они ни в зуб ногой общаться с Вашей командой разработки в терминах конкретной технологии этой команды разработки. Поэтому это как раз ВЫ перекладываете на них ВАШУ ответственность выставить со своей стороны таких БА или СА, которые знают предметную область. По "религиозным" причинам Вы не хотите специализировать свои ресурсы, неизбежно у Вас будут те проблемы, которые Вы здесь описываете. Вы правы, что на велосипеде с квадратными колесами ездить неудобно :)
PS Причины скорее всего вряд ли "религиозные", а они скорее в том, что:
1. Разработчики со знанием предметной области стоят весьма дорого.
2. Такие разработчики не любят переключаться между отраслями / бизнес-областями, т.е. для них нужно иметь пайплайн проектов, что непросто для маленькой компании.
3. Даже если они не свалят из-за п. 2, специалистов в предметной области содержать дорого, т.к. их сложно переключать между ними.
PPS У Вас типичные проблемы роста маленького интегратора. Поверьте мне даже те, у кого сейчас 5.5К человек тоже когда-то были в Вашей ситуации. Если Вам повезет сделать внятный и прибыльнай пайплайн в какой-то отрасли / бизнес-области и, т.о. таки прийти к специализации ресурсов, эти проблемы сами собой рассосутся. Если не повезет, то ИМХО вырасти будет довольно сложно. Слишком уж много на рынке "просто команд разработки".
А разве БА стал частью технической команды либо команды разработчиков? :о)
Если мы говорим о разработчиках, то наш опыт показывает, что многолетней специализации на предметной области им не требуется. И при совместной работе, а когда нужно интегрироваться с несколькими десятками систем, такая работа возникает неизбежно, мы видим что эффективность наших разработчиков кратно превосходит эффективность местных разработчиков с их многолетней специализацией.
Если мы говорим о бизнес-аналитике, то вот ему специализация на предметной области нужна, он общается непосредственно с бизнесом. Они должны обладать единым контекстом.
Если мы говорим о системном аналитике, то ему прикладная область не так уж важна. Нюансов при переходе из области в область возникает не так уж и много.
Что да паплайна проектов. Мы просто занимаемся сложными и уникальными проектами, где зачастую до нас уже кто-то не смог. Прикладные области меняются, а проблемы у всех одни и те же.
P.S.
Бывают смешные ситуации. Например, в одном проекте надо было использовать Camunda, отдел разработки на Camunda был на стороне системного интегратора у которого мы работали на субподряде. Коллеги из системного интегратора со своей работой не справились еще на этапе написания проектного решения и проработке архитектуры. Их уволили (весь отдел), а наши бэкендеры эту самую Camunda освоили очень быстро, неделька-другая на это ушла.
Это я к тому, что не только прикладные области меняются не так сложно, но и стек технологий.
Обожал продавать в таких ситуациях. Если клиент ввиду отсутствия опыта грезит розовыми пони, а конкуренты выставляли плохой лайн-ап проектной команды, то лучше на тендере завысить ценник, чтобы как бы слиться. А потом, когда "пАбедитель" тендера основательно зафейлится и выбесит клиента, можно приходить и (почти) без тендера и с хорошей маржой продать проект спасения жоп менеджмента, подписавшегося под результатами тендера :)
эффективность наших разработчиков кратно превосходит эффективность местных разработчиков с их многолетней специализацией1. ИМХО это сравнивать яблоки с апельсинами. Ин-хаус, особенно, если сидят много лет, совсем перестают работать. Ходят и рассказывают, что "ИТ — этА так сложнАА".
наш опыт показывает, что многолетней специализации на предметной области им не требуется2. Вероятно у нас с Вами были разные проекты. Как на духу, стандартные задачи с "как-бы" ИТ проектов:
а) Сократить 30% штата финдепа самого большого банка в той стране (столько-то тыс человек к такому-то сроку :)
б) Повысить АРПУ клиентов за счет запуска кросс- и ап-селл компаний (на Х% к такому-то сроку :)
в) Сократить срок предоставления официальной аудированной отчетности на столько то недель для компании с листингом на одной из крупнейших мировых бирж. Распишу тут поподробнее, т.к. без шуток это был очень простой прямолинейный проект:
— Быстро сформировать выверенный непротиворечивый массив цифр с достаточным уровнем детальности, которые могут согласовывать куча внутренних подразделений.
— Эффективная поддержка процесса внутреннего согласования этих цифр внутри компании. Все не спят, бегают по потолку, воспаленный мозг выдает новые варианты "корректировок"; именно для этого нужен детальный уровень информации и моментально обсчитать как "новые замечательные" идеи одного подразделения отразятся на других, чтобы когда официальная отчетность зарелизится никого не посадили (без шуток).
— Оптимизировать технологию работы аудиторов из Биг-4 с информацией клиента. В четверке те еще оптимизаторы-автоматизаторы сидят сидят, чуть ли не на счетах считают (точнее black-box скрипты в Экселе), а пока они заключение не дадут отчетность релизить нельзя.
— Все вышеописанное должно было в параллели внутренне непротиворечиво поддерживать GAAP и РСБУ, чтобы какой-нибудь дюже умный аналитик из инвестбанка, получающий без дураков лям долларов в год, не откопал бы какую-то уйню и не сделал бы себе карьеру на этом откапывании.
3. На третий простой проект с отчетностью мне дали 3 мес (но я взамен попросил мнохА денег :) Плюс был в том, что это была уже много лет как полностью аутсорсенная мне ИТ-система. Но можно было бы его сделать в ситуации, когда ключевые разрабы не просто не знают отрасль и бизнес-процессы компанию, но хотя бы на пальцах не понимают принципы финансовой отчетности?
Очевидно у нас разный опыт. Что не говорит о том, что чей-то опыт хуже — в конце концов это все о том, какие бизнес модели работоспособны.
Если мы говорим о системном аналитике, то ему прикладная область не так уж важна. Нюансов при переходе из области в область возникает не так уж и много.Это Вы же написали статью о том, что бизнес-заказчики / клиентские БА не способны сформулировать достаточно качественные для команды разработки документы. Вы пишите статью о том, что есть проблема, а в комментах на комменты говорите о том, что проблемы нет :)
Тут есть небольшая разница. Мы же все-таки именно делаем, а не продаем. Поэтому сложность определяем по сложности как сделать, а не как продать. Часто дело не в том, что «конкурент плохой», дело в том, что задача сложная. Из-за этого о нее бизнес может обломать зубы, как внутренней команды, так и команд подрядчиков.
Например, в одном из недавних проектов проблемы были в том, что шла параллельная перестройка бизнес-процессов заказчика и перетасовывались отделы. Плюс нужно было интегрироваться с тем, с чем невозможно интегрироваться. Такой жести и тотального непрофессионализма, как там, я никогда не видел, приходилось один из сервисов чуть ли не через совет директоров принуждать исправляться.
Ну а вы по сделанным проектам выдаете просто маркетинговую информацию. Из нее в реальности невозможно понять, а что на самом деле для этого нужно было сделать. Понятно, что финтех, понятно, что конвейеры. Но реальный объем работы и требования к квалификации исполнителей понять сложно.
Что до системного аналитика, у него задача из разряда состыковать потоки данных, зачем ему прикладная область? У бизнес-аналитика задача помочь бизнесу выполнить постановку бизнес-задачи. Для того, чтобы это сделать оптимально, нужно учитывать большой набор степеней-свободы, часть из которых может быть известен технической команде, но не известен бизнесу. Регулярно бывает так, что достижение значимых бизнес-выгод требует минимальных усилий со стороны технической команды. Но почему-то их об этом не просят, а они сами не подсказывают.
Part 2 of 2
Понятно, что финтехКонкретно проект, который я расписал в предыдущей части комменте, не в финтех :) Банки упоминал чаще, т.к. они более показательны — процессы и финансы на порядок сложнее скажем телекомов или товарного ритейла.
до системного аналитика, у него задача из разряда состыковать потоки данных, зачем ему прикладная область1. В банках все вертится вокруг плана счетов, который несравнимо сложнее "обычной бухгалтерии в других отраслях". Если Вы делаете своими ресурсами большой проект, то Вам нужно знать как отражается в учете например ипотека: деньги за рассмотрение заявки, маркетинговые плюшки клиентам, сама ипотека (и ее отражение в резервах и регуляторной отчетности), деньги за "страховку" и т.п. Если у Вас разрабы и СА, не "шарящие" в банках, то задолбаешься объяснять прописные истины. Одно дело подходишь к нему и говоришь, что в этом конкретном банке это проводят вот так и он схватывает все на лету, а другое — тратишь недели и месяцы на написание талмуда какие циферки в каких полях искать и что с ними делать.
2. Как разработчик Вы же понимаете разницу между разрабом, который знает фреймворк, который Вы используете, и тем, кто его не знает. С предметной областью та же фигня — "обучение на кошечках" отнимает силы, время и приводит к неизбежным ошибкам то тут, то здесь.
нужно учитывать большой набор степеней-свободы, часть из которых может быть известен технической команде, но не известен бизнесу1. Естественно, информация через БА/СА идет не только от клиента в сторону разрабов, но и в обратную сторону.
2. Ценность хорошего интегратора именно в том, что по факту он, а не клиент определяет, что будет на выходе проекта. И свой вижн он должен это продать клиенту, да еще так, чтобы клиент думал, что это он — клиент — принял это решение, а не какие-то "прАграммистЫ" :) "Скажите, что Вам надо и мы все закодим" на больших проектах неизбежно заканчивается факапом.
Ну вот. Теперь понятно, что при переходе с экселек на более современные технологии можно резко сократить штат и увеличить скорость обработки чего-то там в системе.
Но теперь возникает большая беда в терминологии. То, что вы описываете, очень походит на классический бизнес-анализ. Но на него редко способны те люди, которые сейчас в IT называются бизнес-аналитиками. То есть получается перегруженный термин «бизнес-аналитик», который начинает обозначать две слишком разные вещи.
Что до фреймворков, то мы к ним не привязываемся. Они все равно внутри очень похожи. Вариаций подходов к реализации фреймворков очень мало.
P.S.
В том проекте пришлось исполнять на уровне много ниже C-1. Не сожрали, но приключение было непростое. Работать на С-уровне и С-1 уровне, действительно, комфортней и быстрее.
1. Вполне есть. Есть даже интеграторы, которые для людей клиента проводят за деньги аж мастер-классы на тему "как вам можно заработать больше денег". Если Вы условный (полу)-монополист в своей области, то у Ваших людей появляется кругозор. Поработав с разными клиентами они видят как что у кого устроено и где через интегратора можно наладить условный обмен опытом. Клиентам это не всегда нравится и в критичных бизнес-областях в контракты могут включать пункты, что ИТ-команды, работающие на конкурентов должны сидеть в географически отдельных офисах и людей нельзя перекидывать между проектами для конкурентов в течении года-двух после окончания работы на одного из них.
2. Но такие БА дорогие, поэтому не у всякого интегратора бизнес-модель способна сдюжить такие косты. Плюс компаниям-клиентам их конечно проще нанять, т.к. они могут тратить на них маржу из своего основного бизнеса.
получается перегруженный термин «бизнес-аналитик», который начинает обозначать две слишком разные вещи.1. Почему две разные? Это вопрос не разных ролей / функциональности в проджект-флоу, а вопрос квалификации и знания отрасли и процессов со стороны БА. Какой процент знаний и контента он может сам привнести в проект, а какой придется добавлять клиентским людям.
2. Конечно БА могут быть условными "джунами" — способны только прилежно записать слова клиента и сделать простейшие логические связки между услышанным. Но это не "настоящий" БА :)
3. Если БА не способен завоевать доверие и авторитет со стороны клиента, то он не может продать (обоснованно убедить) клиенту вижн того, что нужно сделать. Ведь что-то в задачах клиента лучше решить системными доработками, а где-то клиенту нужно изменить свои бизнес-процессы. А убедить клиента менять свои бизнес-процессы — это не хрен собачий. Но такое доверие и авторитет можно завоевать только глубокими знаниями предметной области. А если связка БА/СА или не может сформировать такое вижн ввиду недостатка отраслевых знаний или не способна продать этот вижн клиенту, то это заканчивается ровно той печалью, которую Вы описываете в статье. У интегратора / разработчки а и клиента разговор слепого с глухим.
4. Так что описываемы Вами проблемы — это не то, что клиент недостаточно "понимает ИТ", это проблема того, что на проектах нет НАСТОЯЩИХ БА — неважно клиентских или Ваших собственных. Хотя из моего опыта в клиентских я не верю :) Обычно у них настолько квалифицированные люди очень быстро перестают писать спеки и уносятся вверх по корпоративной иерархии :)
Ну, можно делить БА на настоящих и «обычных». :о)
А так не поспоришь, в жизни оно где-то так и происходит. И людей, которые способны решать такие задачи на стороне клиента обычно нет, там скорее вечные джуны в вашем понимании.
Российский рынок интеграции в нулевых и самом начале десятых развивался по израильской модели — лучшие ресурсы были у интеграторов (правда израильская модель продуктовая). А потом, из-за цунами халявных нефтяных денег рынок перешел на калифорнийскую модель, где лучшие ресурсы у клиента, а интеграторы подгоняют им толпы "индусов". Забавно, что массовый отъезд может вернуть назад этих crème de la crème. У крупных клиентов удаленка запрещена, а интеграторы как раз могут предоставить эту "услугу" людям.