YouTube Video Transcript

Приветствую. Меня зовут Михаил. Канал IT Капитан. 

В этом видео поговорим про бизнес-аналитиков и о том, зачем они нужны, но не в плане просто 

какой-то сухой теории, определений. Мы возьмём в качестве примера IT-отдел, э, какой-либо компании 

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

будет полезно тем, кто занимается выстраиванием процессов в отделах о заработке программного 

обеспечения и тем, кто в особенности тем, кто столкнулся с такой ситуацией. У вас есть 

пул задач на разработку новой функциональности. Задача поступает в отдел разработки 

и возвращается оттуда с большой задержкой. И сделано не совсем то, что вы 

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

следующих задач из-за всех этих задержек. Если у вас такая ситуация, поверьте, 

вы не единственный, кто с этим сталкивается, и для этого есть решение. Итак, погнали. 

Разработка по - это конвейер. Конвейер как на производстве. Производственная линия следующая. 

Есть авторы задач, которые ставят задачу в таскактрекер какой-то. Дальше, допустим, 

у наш нашей производственной линии задача попадает в руки разработчикам. Слева изображён 

Teamlead разработчиков, справанд разработчик непосредственно исполнитель задачи. После того, 

как они познакомились с задачей, начали её делать, на выходе у них получается программный код и 

спецификация. Это информация служебная о том, куда на сервер нужно постучаться, чтобы получить те или 

иные данные. Она нужна для фронтнд разработчиков, которые делают наше приложение в браузере, и для 

мобильных разработчиков, которые делают приложение для телефона или для планшета. Результатом их 

труда является новой версии приложения с новой структурой базы данных. Она попадает в руки в 

отдел QA. Это отдел тестирования. Программное обеспечение проходит тестирование и выгружается в 

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

пользователи. Так задумано. Так мы хотим, чтобы работал наш конвейер. Давайте посмотрим, 

как будет происходить это на самом деле. Кэнтер заработчики читают задачу. Итак, нужно сделать 

реестр контрагентов. Это юридические лица. И дальше идёт перечисление полей, которые есть у 

этой сущности. Здесь есть ряд непонятных вещей. Например, что такое банковские реквизиты? Это 

одно большое поле, в которое надо ввести сразу всё, или это группа полей поменьше? 

Данный руководитель. Тот же вопрос: какие именно данные? Контакты организации 

написано в скобках ИТД. Что такое ИТД? Кэнд разработчики с этими вопросами идут к авторам 

задачи, задают их, обсуждают. Решение принимают следующее: "Хорошо, банковские реквизиты всё-таки 

сделаем не одно большое поле, а много маленьких. Данный руководитель тоже самое. Там будет ФИО, 

паспортные данные, номер телефона, адрес, ээ, контакты организации под итд решили, что будем 

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

ответ устроил. Насчёт остальных полей они садятся в Википедию и смотрят, что такое НН, что 

такое КПП, сколько туда символов можно ввести, в каком всё это формате нужно хранить, потому что 

они проектируют структуру табличек в базе данных. Всё, бкн разработчики структуру 

табличек сделали, написали опишку, API для своей части функциональности, для реестра 

контрагентов, покрыли всё это документацией, которая называется вот OpenP спецификация, чтобы 

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

функциональ на сервер, на тестовый сервер. О'кей. Дальше задача попадает в руки 

фронend разработчикам. Они у нас уже освободились. Бэкэнндеры тоже свою часть задачи 

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

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

идут к бакнтразработчикам, те рассказывают им историю о том, что да, у них возникли вопросы, они 

сходили к авторам задачи, те дали такие ответы. По результатам этой беседы вот получилась 

такая получилась такая функциональность, такой набор полей. Вот смотрите спецификацию. 

Здесь всё, что написано - это правда. В задаче типа есть не всё. Хорошо. Фронтенд 

разработчиков устраивает такой ответ. Они берут эту спецификацию, набор полей, идут в Википедию, 

читают, что такое НН, считают, что такое КПП, ОГРН и так далее, и реализовывают свою часть 

функциональности, выгружают на тестовый сервер. О'кей. После этого, там через день, через два, 

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

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

Они идут к бэнд разработчикам, те рассказывают о том, что да, да, была такая встреча, по итогу 

которой вот мы сделали такую спецификацию. В ней правда, верьте ей, задаче не всё. И тут же они ещё 

спрашивают фронтенд разработчиков, как вам с этим живётся набором полей. Фронты показывают то, что 

они сделали. И мобильщики такие: "Ну, о'кей, да, сейчас сделаем по аналогии". Всё, они закончили. 

И те, и другие, всевсе разработчики закончили разрабатывать реестр контрагентов, выгрузили свой 

код и изменения в базе данных на тестовый сервер. О'кей. Задача переходят в руки тестировщикам. 

Они запускают в браузере, запускают на мобильном устройстве, видят набор полей. Ага. Ну, видимо, 

была какая-то встреча, на которой решили сделать вот так. Значит, ладно, о'кей, это и будем 

проверять. И постоянно начинают возникать какие-то ошибки. Например, на телефоне можно ввести 

юридический адрес длиной 400 символов. Вводишь больше, ошибку выдаёт. А до 400 и 400 включительно 

можно. Хорошо. Вводишь там 399, например, нажимаешь кнопку сохранить, а оно не сохраняется. 

Угу. Ошибка. Начинают выяснять. Оказывается так, что на бэкэнде стоит ограничение в 200 символов 

юридический адрес. О'кей, понятно. Начинает проверять на фронтенде в браузере юридический 

адрес, там стоит ограничение. 350 символов. Угу, понятно. Есть расхождение с мобильным устройством. 

И в любом случае это больше, чем принимает, больше, чем мы можем положить в базу данных. И 

таких вопросов возникает множество по каждому полю. И помимо этого нужно ещё тестировщикам 

узнать, сколько цифр в н, что у нас кладётся в КПП, ОГРН и так далее. всю вот эту информацию 

найти и проверить, правильно ли работает везде и на телефоне, и в браузере. Валидация, правильное 

работает сохранение, проверить все пограничные случаи. И таким образом получилось так, что 

у нас отдел QA с вопросиками ходит вообще ко всем. Всё вот это вот выясняют, все вот эти 

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

каждому полю? То есть, если у нас получился список полей, там примерно 25-30 штук, то вот по каждому 

полю, отделу тестирования нужно понимать, какая обязательно это поле или нет, какая минимальная 

длина введённой информации, максимальная длина и что именно можно вводить. То есть это цифры, 

буквы, какие-то спецсимволы по каждому полю. Опять же телефон. Какие символы можно вводить? 

Это сотовый телефон, где можно только вот по определьной маске ввести +79 и так далее. Либо это 

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

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

начинался с адреса, например, какой-то социальной сети или нет. Ну, в общем, много вопросов. Вот 

сколько полей, столько вопросов. И это только по полям. На самом деле ещё большой вопрос, э-э, 

с тем, как это всё должно выглядеть. Например, если у нас 25-30 полей, то не можем же мы в списке 

вывести их все. Ну, у нас поместится штук там 7-10, вот так вот. А остальные придётся исключить. 

Вопрос: какие? Сделано усмотрение фронта и мобильщиков. Они между собой договорились. 

Ну, наверное, это разумно. Хорошо, значит, пусть будет так. И опять же есть ещё другие 

мелкие вопросики. Например, сколько вот строк выводить контрагентов в реестре? 10, 20, 100, 

200. Ну, сделано 100. Хорошо, ладно, 100. Так, 100. Значит, все ко всем сходили, все со всеми 

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

загрузила приложение на Production сеver для того, чтобы пользователи уже могли им пользоваться. 

То есть на практике наша схема стала выглядеть гораздо более насыщенной. Появилось очень много 

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

разработчики сдали часть функциональности и пошли делать дальше следующую задачу. А к 

ним возвращаются и возвращаются постоянно с различными вопросиками. И следующая задача не 

делается. Я ввёл в легенде красную стрелочку, которую назвал Лишняя коммуникация. Вот. Ээ, 

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

Да, идеально описанных задач не бывает. Где-то могут быть какие-то логические там неточности, 

нестыковки. И первоначальное обсуждение задачи, скорее всего, всё-таки нужно, необходимо. Но всё 

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

какие и сколько цифр там могут содержаться, что такое КПП, ОГРН. Каждому ему приходилось 

принимать решение насчёт длины полей, насчёт того, какие поля должны вводиться в 

столбцах, а какие не должны. А представьте, что всё вот это, вся 

вот эта информация, все вопросы, которые Q задавали по полям, всё это было 

бы где-то написано, где-то в одном месте. И, например, например, задача. И тогда не 

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

и обязательность у всех была бы уже одинаково сделана. И тестировщики не ходили бы по 

разработчикам узнавать, а как у них сделано, а как проверять, а что должно быть, а посмотрели 

куда-то в какую-то документацию, там в задачу, прочитали там это и проверили всё. И вся 

вот эта вот коммуникация, она просто уйдёт. Если вы успели подумать о том, что всё, все 

наши проблемы решены, то следующий слайд вас разочарует. Месяц спустя стала поступать 

информация от пользователей. Какого характера? О том, что что-то работает не так, не работает, 

работает плохо, много вопросов. Давайте посмотрим, с чем, например, обратились к нам пользователи 

через службу поддержки либо как-то напрямую, если это наши коллеги. Значит, сложно найти 

контрагента. Да. Когда их было 50-100, они все помещались на один экран. Можно было 

глазами легко кого-то найти. Но когда их стало 1.000 2.000, то поиск ээ затруднился, приходится 

долго листать. Также появились дубли контрагентов. Это как следствие. пользователь не может найти 

контрагента, заводит его заново. Третий, третья проблема. Нет кнопки копировать контрагента. Это 

вообще интересный случай. Никто не понимает, зачем она нужна. Зачем копировать контрагента, если 

мы не хотим его дважды заводить? Оказалось, что пользователи хотят завести контрагента с одним 

расчётным счётом и с другим расчётным счётом. То есть два расчётных счёта, а у нас такой 

возможности нет. Они просто создают второго контрагента с другим счётом. Дальше контрагенты 

стали пропадать. Ну, понятно. То есть, э, ну, куда-то куда-то у нас есть функции удаления, 

да, они могут пропадать, но пользователям это не нравится, потому что на уже созданных контрагентов 

были завязаны какие-то процессы, какие-то заявки, что-то ещё. И вдруг раз контрагент пропал. Далее 

неизвестно к кому обращаться. То есть кто удалил контрагент, такой информации нет. И либо кто-то 

поменял информацию контрагента, тот же самый счёт, например, или там телефон, что угодно. Кто и зачем 

это сделал, пользователи не знают. Также пришли коллеги соседнего отдела. Они как раз столкнулись 

с той проблемой, что разработчики выбрали [музыка] формат поле, номер телефона свободный. Туда 

можно ввести вот городской телефон с каким-то комментарием и так далее. А им пришла задача 

издела маркетинга сделать рассылку, например, естественно с согласие контрагентов, либо какие-то 

транзакционные SMS отправлять, либо какие-тощем служебные сообщения и, безусловно, очень 

важные и полезные. И они не могут отправиться, потому что в полях номер телефона введено не 

совсем то, на что можно отправить эсэмэску. И возникают всякие интересные случаи, когда 

руководитель компании контрагента сменила фамилию. И вот пользователи не понимают, как быть, 

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

фидбэк. Им неудобно пользоваться реестром контрагентов. Он работает не так, как им нужно. 

В нём много чего не хватает, много непонятного. Ситуация довольно-таки неприятная. И со всей 

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

Где-то назревает конфликт, но у нас все умнички, поэтому пытаются не конфликтовать, а найти 

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

задачи и разработчики устроили совместную встречу уже не только, а все разработчики присоединились, 

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

Вот, во-первых, нужно реализовать систему фильтрации. То есть пользователь может э увидеть 

набор полей какой-то фильтра и ввести там здесь, здесь там фамилию, например, и нажать, э, найти 

или отфильтровать, чтобы уменьшить, э, число контрагентов в списке и найти нужный ему. Также 

можно реализовать систему поиска. Например, это просто поисковая строка, где можно ввести всё, что 

угодно, например, тот же самый номер телефона, и он найдётся как телефон э руководителя организации 

и как телефон организации. Дальше добавить ограничения. Нужны уникальные поля. Да, вот 

пользователи не могли найти контрагента, и у них получалось создать новое. Такое такого не должно 

происходить. Допустим, Ин ещё какие-то поля должны быть уникальными, чтобы дубли не возникали. Ещё 

нужно добавить возможность привязывать несколько счетов. Это та самая история с кнопкой копировать 

контрагентом. Нужно убрать возможность удаления контрагентов. Всё, контрагента завели. Удалить 

его нельзя. Нужна система журналирования действий пользователя. Мы должны понимать, кто из коллег 

и когда отредактировал информацию о какой-то организации. Поле телефон не должно существовать 

э в таком виде, как есть сейчас. Должно быть два поля. мобильный телефон, у которого есть 

определённая маска для ввода и городской там телефон вообще в любом формате. Также по 

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

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

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

продакшене и все им пользуются, там заведено уже огромное количество контрагентов. А у нас что 

происходит? У нас меняется вообще, в принципе, структура таблиц в базе данных. У нас добавляется, 

скорее всего, новый какой-то поисковый движок, где всё это надо проиндексировать. Нам нужно 

написать программу, в которой вот уже созданные контрагенты сконвертируют в новый формат, в 

который мы теперь будем хранить. Но дело в том, что не всегда это получится. Допустим, если 

у компании отличается только расчётный счёт, это одно, да, можно легко склеить компанию 

и привязать к ней два расчётных счёта. Но, допустим, кроме расчётного счёта есть 

ещё какие-то отличия в каких-то полях. и мы не знаем, какие взять. То есть не получится 

до конца это процесс автоматизировать. И программа должна быть это построена таким образом, 

чтобы она нам сигнализировала о том, что вот есть два контрагента, которых мы 

не можем склеить или конвертировать в новый формат. И нужно пользователям вручную зайти и это 

поправить. Ну давайте вот подытожим список задач. маленько я пометил цветом. Что получается? 

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

из положения. Вот это вообще весь список работ, который на данный момент должен быть произведён 

с этой функциональностью. У нас сделан на данный момент только пункт ноль. Вот это вот реализовать 

создание редактирования. И казалось бы, что можно радоваться, что, ну, хоть что-то сделано, но 

вот этот девятый пункт полностью все эти усилия нивелирует. Вот написать вот эту вот программу, 

которая конвертирует в новый формат, возможно, займёт даже дольше времени, чем на бэкэнде вот вот 

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

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

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

доделывать и возвращаться вот к этому, либо здесь как-то эти задачи нужно приоритизировать 

и выпускать потихоньку, помаленьку. Ну, в общем, как-то думать, выходить из этого 

положения, потому что получается, что, да, вот мы сейчас всё это разобрали, проанализировали 

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

вот, в общем, вот так. Не всё гладко. Через череду таких событий с одной задачей, 

второй, третьей, компании задумываются о том, что как будто бы в отделе разработки по происходит 

что-то не то. И начинают думать о том, как оптимизировать процессы. Здесь приходит к выводу 

о том, что техническое задание всё-таки, наверное, нужно. Во-первых, разработчики, каждый разработчик 

не будет гуглить НН, КПП, ОГРН и прочие поля, какую себе информацию могут задержать. А тут 

ведь ещё и биг добавляется, и так далее. [музыка] В это же техническое задание можно было бы 

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

уникальный, уникальный и так далее. Помимо этого, в техническом задании можно было бы 

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

логические вещи тоже можно было бы продумать, мм, и описать в техническом задании для того, чтобы не 

тратила команда на это время, потом не выдёргивать команду ещё раз спустя месяц на вот такие 

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

пометить вот ещё одну стрелочку красненьким в случае, если у нас появляется техническое задание. 

Ну, выходит так, что раз уже есть ТЗ, то все вот эти стрелочки можно зачеркнуть, они не нужны. Вот 

у нас получается снова вот такая чистая, хорошая производственная линия разработки программного 

обеспечения с нашим техническим заданием, по которому работает вся команда и каждый разработчик 

к нему обращается. Ну и вы уже, наверное, догадываетесь, откуда у вас может появиться 

техническое задание, раз вы смотрите это видео. Его вам может написать бизнес-анаaltтик. Это 

человек, который может получить вот эту задачу, сходить к автором этой задачи и провести интервью, 

на котором выяснить уже окончательный точный набор полей, который нужно реализовать со всеми 

правилами валидациями, валидации и ограничениями, и приложить эту информацию вот к задаче. в рамках 

технического задания. Помимо этого, вместе с продакт-менеджером или проданером, бизнес-аналитик 

может сходить к пользователям и провести с ними интервью, узнать вообще, а какой запрос на 

этот реестр контрагентов, а как они работают с контрагентами, а что им вообще, что с ними 

можно делать, какая им нужна функциональность. И помимо этого бизнес-аналитик может продумать 

и зафиксировать все остальные вещи. Опять же, какие вот столбцы выводить по поводу фильтр 

поиска. То есть часть из того, что мы ранее записали, пользователи вот так вот прямо не 

могут сказать. Э но бизнес-аналитик всё это может предусмотреть. У него есть опыт написания 

таких технических заданий. Он разбирается в бизнеслогики проекта, поэтому, да, и процесс 

начинает выглядеть так, что задача падает не сразу на бэкэнд разработчика, а вот сначала на 

бизнес-аналитика. Он пишет техническое задание, и задача уже с ТЗ приходит в отдел разработки. 

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

сути, мы не ввели в нашу производственную линию бизнес-анализ. Нет, у нас и до этого происходил 

бизнес-анализ. Только им занимались вообще все. Им занимались бэкэнд разработчики своими 

вопросами, фронт разработчики, сидели в Википедии, узнавали, в какие поля что можно вводить. 

Мобильные разработчики тем же самым занимались. Тестировщики все занимались бизнес-анализом. 

Когда пользователи через месяц с лавиной жалоб к нам пришли, э мы тоже сели, привели митинг, 

получается, с вами. И чем мы занимались? Мы занимались. бизнесаанализом. Только дело в том, 

что на у команд разработки это выпадает чаще всего делать тимледам, вот самым дорогим сотрудникам 

на всей нашей вот этой производственной линии. Получается, самых высокооплачиваемых сотрудников 

мы сдёрнули с выполнения их непосредственных обязанностей, за которые мы им платим, 

и высадили заниматься бизнес-анализом. Хотя, как бы вот есть такая роль бизнеса аналитик. 

Это был последний слайд. Презентация закончилась. Сейчас хочется просто уже порассуждать. Если у 

вас нету бизнес-аналитика, но у вас есть проблемы, которые были показаны в презентации, попробуйте. 

Да, у вас увеличится фонд оплаты труда. Но оно окупится. Будет так, что у вас не занимается 

бизнес-анализом вообще вся команда и тем более, что не будут к нему привлечены тимледы. То 

есть самые дорогие специалисты не будут э заниматься бизнес-анализом, и задачи будут 

выполняться быстрее. То есть уменьшится количество вот этих вот ненужных красных 

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

просто в ТЗ глядеть. И задачи будут делаться быстрее, значит, они вам будут обходиться дешевле. 

То есть, если, э, с техническим заданием команда, например, может делать четыре таких 

реестра в месяц, то без технического задания начинаются вот эти вот хождения, и 

команда успевает сделать только там полтора. Вот помимо этого, как вот история с обратной 

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

есть, смотря, чем вы занимаетесь, там, у вас продукт или аутсорс, ну, в любом случае 

ситуация неприятная и тоже её можно избежать. Вот. Ну, итог такой, то есть, э, в продукте могут 

работать, э, продакт-менеджеры, и они отвечают на вопрос, что должно быть на проекте, что а 

бизнес-аналитики отвечают на вопрос, как как это должно работать на проекте, вот со всеми вот 

этими мельчайшими деталями и делать техническое задание. Большое спасибо за просмотр этого 

видео. Надеюсь, вам понравилось. Я думаю, что вам стоит подписаться на этот канал, потому 

что задумка выпускать их видосы на регулярной основе. Я последние 7 лет занимаюсь выстраеванием 

процессов в командах разработки ПО и управлением этими командами. Мне есть что рассказать. Я 

думаю, вам будет интересным. Хорошего дня.