Имею опыт работы порядка 7 лет в банках уровня ТОП-5 и пришел к выводу, о том что до сих пор в разных командах нет единого понимания о том, какую же роль играют аналитики в командах и никто, включая самих аналитиков вам не скажет, какие обязанности должны ими выполняться. Ну кроме, пожалуй, единого мнения о том, что аналитик должен “писать документацию”. Хочется также отметить тот факт, что, само наличие аналитика в команде, которая работает по Agile, когда разработки по ТЗ в строгом смысле этого слова уже нет, уже само по себе проблема. И если банк у вас современный и вы работаете не по “водопаду”, а по какой-то более гибкой методологии, вам придется решать три проблемы анализа на банковских ИТ-проектах:
Как сделать так, чтоб заказчик и разработчики не игнорировали присутствие аналитика?
Как сделать так, чтоб документацию, написанную аналитиком читали разработчики?
Как сохранить набранных аналитиков в команде, если вся остальная команда прекрасно справляется и без аналитика.
Основная проблема аналитиков в том, что аналитики - специальность суррогатная. Суррогатность означает, что созданы аналитики были для того, чтобы сопровождать процесс производства программных средств и сами напрямую в этом процессе не участвуют. Часто ведь для обывателя, человек, работающий в ИТ это человек так или иначе связанный с языками программирования. И часто, люди очень удивлены, что есть в ИТ роли, которые и программировать-то толком не умеют. Аналитики в настоящий момент в большинстве случаев выполняют следующие функции:
Обеспечивают перевод желаний заказчика на язык разработчиков.
Обеспечивают создание документации (технических заданий и базы знаний).
Являются центральным узлом коммуникации в команде.
Интересная тенденция, наводящая на мысли о кризисе специальности - если проследить основные тезисы докладов на конференции аналитиков или статей на тему анализа за последнее время, то солидный перевес будет в сторону так называемых “soft-skils”. Складывается ощущение, что никакими техническими навыками аналитики не обладают - потому и поделиться вроде бы нечем. Или они попросту не должны ими обладать? А может все эти статьи и публикации лишь попытки доказать, что аналитик команде все же нужен.
“Кто мы?”
А меж тем, как показывает личный опыт, роль аналитика на проекте чрезвычайно важна. Ведь, если убрать аналитика с его "техническими заданиями" и прочей "документацией", кто ж виноват-то во всем будет? Неужели архитектор или разработчик? А может быть сам заказчик? Нет же. Виноват будет всегда аналитик. Потому что, как многие думают, нужен он для написания документации, а разработку (не смотря на то, что всем говорим про Agile) мы ведем по согласованному техническому заданию по-старинке. И если появляется какое-то несоответствие или искажение изначальной сути, то разработчик делает круглые глаза и говорит “а так было в техническом задании”.
Решил попытаться самостоятельно разобраться в данной проблеме и сформулировать собственное видение проблем анализа.
Лично я выделяю три геологических эпохи в развитии ИТ. Может быть все глобально не так просто, так что три эпохи я буду выделять в ИТ только лишь банков. Эпохи эти называются так - монолитный мультифункционал, SOA и микросервисы. И поговорить бы хотелось о том, что во всех трех эпохах у аналитика были принципиально разные обязанности.
Давайте обратимся к истории вопроса. Зачем изначально появился анализ? Как только возникли средства автоматизации делового оборота, возникла потребность переводить на язык инженеров, которые пишут компьютерные программы пожелания заказчиков со стороны бизнеса.Начиная с 1990х годов на рынке производства программного обеспечения начало образовываться довольно большое количество игроков, занимавших разные его доли. Довольно часто происходила следующая вещь - разработчики сами предлагали заказчику техническое решение и вынуждали перекраивать устоявшиеся бизнес-процессы под свое решение, что не всегда устраивало заказчика. Иногда даже получалось так, что бизнес-модель компании складывалась из того ПО, которое оно использовало для автоматизации. 1С или SAP - разница была большая.
С другой стороны, при возникновении более-менее серьезного подхода к делу, возникла надобность в оформлении документации на разработку. Собственно, в банках, эта роль стала называться "технологами". По сути, эти люди были простыми "техническими писателями", которые описывали процесс и выдавали разработке то самое "техническое задание", по которому она велась. А дальше им в обязанности стали добавлять представлять интересы заказчика. И начали они ходить с книгами типа Карла Вигерса под мышками и устраивать интервью заказчику, пытаясь перенести его требование на бумагу.
Как возник анализ в ИТ
На моей памяти был один забавный процесс автоматизации стекольного завода в 2015 году. До поры до времени, инженеры завода при формировании задания на производство обходились электронной таблицей MS Office. В данную таблицу были защиты параметры расчета количества материала, цены и иногда количество единиц сырья на складе. Система прекрасно работала и сбоев не давала. Откуда возникла идея внедрить вендерное решение и кто привёл именно ту фирму, что в итоге занялась автоматизацией никто уже и не вспомнит. Как сейчас ( спустя 7 лет) становится понятно, ключевую роль в выборе технического решения сыграли личные связи владельца бизнеса. Только фирма та с устоявшимися процессами сильно не церемонилась. Система сопровождения производства была внедрена командно-административным подходом и разрушила все существующие к тому моменту на предприятии связи.
Что же произошло?
Во-первых, внедряемая система была довольно монстрообразным монолитом и охватывала все процессы на заводе: от заведения заказов, до склада и ведения заготовки по цеху и ведения бухгалтерии. К чему это привело? Элементы интерфейса были написаны в единой семантической системе, рождённой вне данного завода. И если раньше, люди в бухгалтерии, на складе и в цеху не владея терминологией процессов друг друга договаривались ввиду наличия межличностных отношений, то теперь они коллективно не могли понять семантический смысл элементов интерфейса внедренной системы.
Второй момент, система была рассчитана на заранее определенное количество производственных участков и движение заготовки по цеху в соответствии с маршрутом, какой разработчики посчитали наиболее правильным в соответствии со своим предыдущим опытом. Внедрение "программы" было настолько агрессивным со стороны разработчика, что они покусились даже на гостовскую разметку цеха, приведя все технологические участки в соответствие с парадигмой своего программного детища. Естественно, данное обстоятельство заставляло пересматривать устоявшиеся годами и человеческие и инженерные коммуникации между цехами.
Когда завод встал и не смог на какое-то время обрабатывать заказы от клиентов, а часть клиентских менеджеров предприятия затеяла партизанскую войну и наиболее ценные заказы тайно от руководства продолжила вести в виде электронных таблиц MS Office, разработчики великодушно велели выделить им людей для выравнивания процессов. Собственно говоря, так на том заводе появились первые ИТ-аналитики.
Какую роль они выполняли?
Технологи - прослойка между заказчиком и разработкой. Эпоха монолитных десктопных приложений.
Так на рубеже 20-го и 21-го веков появилась первая суррогатная специальность в ИТ - технологи. Сначала они выполняли работу тех самых технических писателей и сопоставляли обработку данных в системе с технологическими процессами. Анализа, как такового было было. Зато появилась “прослойка” между заказчиком и ИТ. Прослойка эта занималась подготовкой того самого “ТЗ” (технического задания), которое утверждал заказчик и брал в работу разработчик. Причина возникновения этой роли в том, что приземленный заказчик не мог на доступном языке объяснить высокомерным разработчикам, чего же он от них хочет.
Была и другая причина. Разработка программных решений в энтерпрайс вышла на новый уровень и часто заказчика и разработку начали связывать договорные отношения. Начали возникаь первые конфликты, в том числе и доведенные до судебных инстанций. И для того, чтобы судья (как юрист) мог понять, кто тут прав, а кто виноват, ему нужен был документ - то самое техническое задание на разработку. Так как ни бизнес, ни разработка писать его не хотели, возникла надобность привлекать третью сторону - технолога.
Всем сразу же захотелось иметь штат таких технологов, особенно банкам. Почему банки, ну потому что именно они начали первыми сталкиваться с проблемами построения ИТ-систем в энтерпрайсе. Как правило, технологами становились технически подкованные специалисты со стороны бизнеса. Тут же вспомнили про ГОСТ 34 и начали требовать написания документации в соответствии с этим ГОСТом.
При этом, надо отметить, что очень быстро “технологи” перестали быть просто “техническими писателями”. Когда возникали явные несоответствия уровня ИТ бизнес-требованиям и требовались доработки, возникнувшая дискуссия с разработкой заставляла вносить изменения уже в программный код по инициативе технолога. Можно сказать, что таково было начало бизнес-анализа.
Если рассмотреть процессы в других областях, то можно проследить такую же тенденцию, что и на описанном мной заводе. Внедрение вендорных решений потребовало мобилизации со стороны заказчика специалистов для прописывания процессов, требующих автоматизации. Такие люди в банках стали называться "технологами". Основным артефактом их работы стали те самые "технические задания", по которым велась разработка. Ведущая роль же в процессе создания средств автоматизации оставалась по прежнему за разработчиками.
Эпоха SOA. Возникновение бизнес-анализа и приход анализа системного
Со временем ИТ-инфраструктура стала играть ведущую роль в обеспечении создания добавочной стоимости. И потребовались принципиально новые подходы в формировании требований к разработке. Компании, конкурирующие друг с другом, начали осознавать, что в борьбе за клиента нужно предлагать ему более удобное средство автоматизации процесса, чем у остальных игроков на рынке. И вот тут свою роль начали играть попытки разработчиков встраивать свое видение процесса. Чем сложнее становилась создаваемая система, тем чаще заказчик начинал получать не соответствующие исходному техническому заданию решения. Почему так выходило? Разработчики, вследствие своей ведущей роли в процессе, пользовались служебным положением и решали проблему так, как им было проще и так, как они считали нужным. Вот тогда, руководство компаний задумалось о привлечении сторонних разработчиков или консалтов с интеграторами, которые будут решать проблемы на концептуальном уровне. При этом, степень зрелости бизнеса в ИТ процессах росла и решить концептуально проблему самостоятельно заказчик был уже в состоянии сам. Таким образом возникло понятие "архитектуры решения", которое являлось продуктом труда полноценной команды аналитиков. Аналитиков со стороны бизнеса. Такие аналитики, уже приходили к разработчикам напрямую и разговаривали с ними с позиций клиента, требующим исполнения своих требований в соответствии с договором. А как только на предприятии возникала надобность связать две и более концепции понадобились архитекторы со стороны бизнеса.
Разметка предметного поля и модель данных
В чем особенность SOA? Разные ИТ-системы обслуживали одни и теже бизнес-сущности в рамках различных бизнес-процессов. Если процессы разные, а сущности теже, то возможно самым правильным станет выделение этих сущностей и установление связей между ними? Как раз в это время рождается идея пойти по пути Карла Линнея и построить для банка “классификацию видов” бизнес-сущностей. И вот тут, впервые возникла надобность составлять модели данных и размечать предметное поле. И никто кроме аналитиков размечать предметное поле не стал.
Разъединение BA и SA
Базовое физико-математическое образование заставляет мыслить системно. Давайте в свете вышесказанного про модель данных сформулируем то чем бизнес-аналитик отличается от системного аналитика.
Основная теорема бизнес-анализа: любой бизнес-процесс можно представить как описание связей между однозначно определяемыми бизнес-субъектами и бизнес-объектами, которые также могут участвовать и в других бизнес-процессах.
Основная задача бизнес-анализа: определять субъекты, объекты и связи между ними в рамках данного бизнес процесса.
Возникла еще одна проблема. Со временем в арсенале разработки появлялось все больше и больше инструментов выросших в своего рода "зоопарк систем". Разработчики же не могли самостоятельно выбирать способ, систему или методику, по которой будет решена та или иная задача. Возникла надобность в специалистах, которые бы перекладывали идеи бизнеса на ИТ системы предприятия. Так появились системные аналитики. В их обязанности стало входить выбирать решение и описывать его для разработчика. В той ситуации подобные аналитики находились на стороне вендера или интегратора. Со временем, они начали заводиться и внутри организаций заказчика.
На данном этапе начали возникать такие понятия как “маппинг” и “метчинг”, то есть артефакты в которых семантика в одной схеме (будь то XML, JSON или позиционная строка) сопоставляется семантике в другой схеме. И вот тут возникла проблема того самого “семантического безумия”, о котором я говорил в ряде своих докладов. Данное явление наблюдается в ИТ-системах, когда начинает работать множество различных команд - и все начинают одни и теже вещи называть по-разному. Или наоборот, одним и тем же словом называют принципиально разные сущности или явления.
Основная теорема системного анализа (теорема об унивокальности с бизнесом): Любой бизнес-объект имеет одну и только одну проекцию в пространствах классов языков программирования и таблиц баз данных.
Основная задача системного анализа: Зная набор бизнес-объектов, определять классы языка программирования и таблицы баз данных соотвествующие им.
Еще раз об архитектуре и анализе
Чем дальше шло развитие ИТ-инфрастурктуры, тем больше задач требовалось решать на концептуальном уровне. С другой стороны, начали возникать задачи интеграции одного решения в другое, когда несколько концептуальных схем как со стороны бизнес-идеи, так и со стороны технических решений необходимо было объединять в единую общую картину. Так стала возникать “архитектура” как новая дисциплина. Причем, на том этапе (а это была эпоха SOA - сервис ориентированной архитектуры), как со стороны бизнес-идеи, так со стороны систем решения, так и стороны архитектуры (сервера и каналы связи). Наличие документов с концептуальной архитектурой, описание заданий на доработку и серверной части привело к возникновению документации разного уровня. Именно в эпоху SOA начали произносить слово (HLA - high level architecture - верхнеуровневое описание архитектуры). Да и популярная в то время модель OSI требовала описания процессов на разных уровнях.
У аналитиков появилась еще одна неожиданная функция. Они начали составлять документацию не только для разработки, но и формировать так называемые “базы знаний”. Для чего понадобилась в enterprise база знаний? Для последующих поколений и интеграции. Когда наступила эпоха SOA, возникла необходимость интегрировать “все-со-всем”. Системы стали “потребителями” (target system) и “поставщиками” (source system) друг друга. Естественно, в целях установления информационного обмена, для “поставщиков” понадобилась документация “потребителей”, а для “потребителей” возникла необходимость в документации “поставщиков”. И вот когда выяснилось, что из документации у всех только плохие ТЗ на разработку. КАзалось, бы надо опять нанимать технических писателей, или студентов-практикантов, которые бы денно и ношно сидели бы и описывали. Но.. к счастью, нашлось решение лучше. Решением этим стал Confluence. В процессе работы, множеству аналитиков и архитекторов (как бизнес, так и системных) стало возможным описывать свой маленький кусочек. И если все страницы связаны в единое целое, то получается вполне стройная техническая документация.
И архитектор и аналитик производили документацию, но различного уровня. В чем же разница между аналитиком и архитектором?
В предыдущем разделе я говорил об “унивокальности”. Термин “унивокальность” взят из религиозной литературы, а именно из трудов Блаженного Августина. Он говорил об “унивокальности со Всевышним”, рассуждая об одинаковом понимании вещей человеком и Богом. Я не Блаженный Августин, но часто также задаю вопрос, одинаково ли разработка и заказчик понимают суть вещей? Поэтому, как следствие теоремы об унивокальности, должна быть выстроена четкая связь между бизнес-сущностью и соответствующими ей ИТ-объектами (DataTransferObject, XSD, JSONSchema, таблицами баз данных и прочими). Задачей архитектора в этой парадигме является установление этого закона, обеспечения однозначности и понятности. Если такой закон есть, то у системного аналитика появляется инструмент для работы и все процесс (интеграции, разработка нового функционала) проводятся в соответствии с этим законом. Таким образом, основной задачей архитектора является - установление “унивокальности”, то есть четкого закона по которому каждой бизнес сущности в рамках каждого бизнес-процесса ставятся в соответствие определенные, однозначно определяемые, ИТ-объекты.
В эпоху SOA пришло осознание, что архитектуру нужно продумывать изначально. Изначально теперь начали возникать такие артефакты, как HLA (High-level Architecture). Кроме того, возникли проблемы с семантикой. Выяснилось, что “семантическое безумие” это не вымысел, а оно правда существует. В этот момент многие крупные банки начали приходить к концепции Общей Модели Данных для всех ИТ-систем, построенной на глобальных бизнес-объектах. Глобальные бизнес-объекты хранились изначально в XSD, а позже в JSONSchema. И маппинг, о котором говорилось выше, подразумевал совоставление одной схемы другой схеме, что существенно ускоряло процесс анализа.
Неоднократно в своих докладах приводил аналогии, доказывая, что в ИТ нужны инженерные знания и бекграунд. И вот тут такая история. Как многие помнят, в 1986 году случилась авария на Чернобыльской атомной электростанции. Одной из причин данной аварии, как выяснила комиссия, являлось несоответствие эксплуатационной документации различного уровня друг другу. Грубо говоря, верхеуровневая документация написанная академиками Александровым и Долежалем противоречила той, что главный инженер утверждал для смены на атомной электростанции. К счастью, последствия наших несоответствий не столь плачевны, но также могут привести к “перегреву”, но уже в ИТ-системе.
И вот наступил Agile. Эпоха Микросервисов. Не документация, а артефакты
Как ИТ превратилось в сфере с наиболее динамично развитым маркетингом и накачкой деньгами никто не понял. Однако, на данный момент все больше и больше разных людей начали работать в ИТ в неожиданно новых ролях. Если раньше промежуточным звеном между бизнесом и разработчиком были только айтишники, то теперь появились целые гроздья новых специальностей, которые зна первый взгляд ( да и на второй тоже) добавочной стоимости в ИТ продукте не делают.
Во времена Agile земля под аналитиками затряслась больше, чем под другими ролями. Ибо сказано: работающий код важнее исчерпывающей документации. На первых порах, евангелисты Agile понимали эту фразу буквально и каленым железом жгли все попытки задокументировать что-то на проектах. Вот и прошлось брату-аналитику пытаться перестроиться. В эпоху Agile остался бизнес-аналитик вне продуктовой команды, а системный аналитик превратился в солюшн архитектора, то есть архитектора решения. Почему так произошло? Степень зрелости в ИТ за последнее время драматически возросла и да, есть конторы, которые подошли к Agile не в угоду моде, а осознанно. С другой стороны, в эпоху Agile основным артефактом стало не техническое задание, а карточка в трекере. И вектор полезности сместился от ТЗ, к карточкам в трекере. В хороших команадах по карточке в трекере можно было вытянуть и страницу в Confluence с архитектурой и соответствующий коммит в GIT. И всю цепочку исполнителей. В эту эпоху документация перестала называться “документацией” и стала называться “артефактами”.
С другой стороны, сопровождать традиционно построенное приложение (или как говорят у нас “монолит”) в условиях Agile становится проблематично. Возник архитектурный стиль, который стал называться “микросервисной архитектурой”. Парадигма микросервисов дала возможность бурно развиваться различным идеям. А значит количество артефактов, несущих какую-либо полезную информацию росло в геометрической прогрессии. Возникла необходимость наводить в этом хозяйстве порядок.
Появление других суррогантных ролей в командах
Agile быстро стал новой религией в ИТ и превратился в “вещь в себе”. Любой религии нужны “служители культа” и жрецы. Семейство суррогатных ролей, в котором до этого были только аналитики и архитекторы, начало пополняться новыми диковинными видами.
После того, как все задачи начали отображать в виде разноцветных карточек на доске, такой доске понадобилась хозяйка или хозяин. Возникла отдельная роль - менеджер проекта, которого иногда называли скрам-мастером. Данная роль получила власть над главнейшим артефактом - карточками в трекере.
Другая вещь, породившая новые роли,это DevOps и парадигма CI/CD. Элементарная задача - составить релиз и спланировать поставку в условиях - оказалась продуктовой команде не под силу. Понадобилась новая роль - менеджер релизов. В их власти оказался GIT, система через которую ведется весь процесс движения “от дева в прод”. Можно сказать кровеносная система enterprice.
Так же появились такие роли как product owner и platform owner. Agile уничтожил все вертикали, сделав горизонтальным или матричным менеджмент. Если мы говорим о парадигме SOA, то понадобились специфические архитектурные роли. Произошло разделение на на продукт и платформу, которая её содержит. Эти роли писали документацию уже по-новому. Они писали её как архитектуру. По новым принципам.
В новой геологической эпохе тяжко стало аналитикам. Продуктовой команде, люди которые просто пишут документацию, оказались не нужны. Артефакты ведь сами собой получались. Уровень зрелости бизнеса в ИТ начинал расти, не нужен им стал бизнес анализ. Системный аналитик продуктовой команде также не нужен. Разработке со стороны заказчика спукают метрики и по хорошо разжеванным паттернам они стали работать. Да еще появился этот самый Swager - который позволял из их генерировать! Казалось, надо бы начинать собираться мести улицы. Хотя осталось еще одно место, где документация сама по себе была нужна - это работа на государственные или полугосударственные компании.
И аналитики начали превращаться в архитекторов решений. С одной стороны они стали отвечать за разметку предметного поля и построение моделей данных, а с другой - они существенно повысив свой инженерный уровень начали проектировать решения в рамках одного микросервиса.
А что если разработка ведется на государственную компанию?
Да. Agile это хорошо. И можно привести много примеров, когда он работает. Да вот беда, что делать, если вы работаете на государственную компанию, в которой документация это основной артефакт. Там нет Agile, а есть “водопад”. Или есть Agile, но документация все же остается важнее работающего продукта. Почему? Ну потому что в государственных компаниях бывают проверки и аудиты и такая документация нужна нее столько для разработки, сколько для прокурора. Ну не будешь же ты прокурору и контролирующим органам показывать карточки в Jira? Таким командам нужен все же технический писатель, вместе с полноценными аналитиками, которые кропотливо пишут ТЗ, которые написаны строго по ГОСТу и утверждаются начальством как положено, а руководитель предприятия ставит подпись, которая скрепляется печатью.
Заключение. И все-таки аналитики выжили во всех геологических эпохах
Если вы в ИТ давно, и имеете дело с командой, в которой есть аналитики, то попытайтесь вспомнить, что заставило команду искать аналитиков. Объективная ли это была надобность? Или это было потому что “так было у всех”?. Подумайте над тем, а что стало бы с вашими процессами, если бы аналитиков совсем не стало? Ухудшились бы они? Или может быть всем бы только полегчало?
Если вы аналитик, проанализируйте как менялись требования к вам и как менялась ваша компетенция за последние 2 года?
Ответы на вопросы и их анализ заставляет задуматься и делать прогнозы с выводами.
Стало совершенно понятно, что бизнес-анализ в enterprice в нынешнем объеме скоро перестанет быть востребован. Хороший менеджер направления уже прекрасно понимает, что такое ИТ-система и сам в состоянии сформулировать свою “хотелку”. Разработчики также ведут разработку по строго определенным паттернам, и если системный аналитик не превращается в архитектора решения, а хочет дальше только лишь писать техническую документацию, то ценность его для рынка труда в скором времени также застремится к нулю. Перевод с языка заказчика на язык разработчика скоро станет не нужен.
Документация. Техническое решение без документации и без общих средств её написания и модернизации, как цивилизация без письменности. Такое решение либо будет со временем уничтожено, либо будет поглощено другим более понятным окружающим решением. Agile, такие системы как Confluence (аналогичные в этом ряду) да и общий рост технических знаний приведет к тому, что в процессе создания документации и баз знаний будет задействована вся команда на разных уровнях. Единственным исключением станет ИТ в органах государственной власти, где как я писал выше у документации несколько иная роль, чем вести по ней разработку.
Коммуникация. Раньше, когда работали по “водопаду” было так, что аналитик был единой точкой входа для заданий заказчика. Он же собирал все вопросы разработки и добывал ответы, собирая и скрупулезно прорабатывая каждый пункт. Когда мы работаем по Agile, то создаем “продуктовую команду”. Предполагается, что эта команда живет в едином информационном пространстве и вся информация единовременно доходит до всех на дейли, ретро и прочих ритуалах команды. Зачем тут связующее звено?
Вспомнилась мне история. Год или полтора назад работал я в одном интеграторе. Интегратор много из себя строил, говорил что работает по SCRUM, а сам пропагандирорвал идеи Карла Вингерса и натравливал на заказчика девочек "анализирующих" бизнес-требования и рисующих в пейнте интерфейсики. Каждое утро начиналось дейли, на котором муссировалась одна вечная тема - сроки. Заказчику обещаны были одни, а по факту уходили уже на 3-й или 4й спринт спустя обещанного. Ничего нового не было и на этом дейли, разработка разводила руками и говорила, что делала по ТЗ, что им не понятно, как из того что там написано следовало то, что ждет тестировщик. Тестировщик возводил глаза к небу и вспоминал архитектуру платформы. Архитектор перебивал всех и говорил, что эта проблема не его уровень и конкретными решениями он не занимается, а мыслит глобально. Проджект менеджер же сказал, что у любой проблемы есть “имя, фамилия и отчество”. И все дружно начинали тыкать пальцами на аналитика. Он утирался, говорил что все поправит. А скрам-мастер - добрый толстый бородач, слушая мытарства взятого на проект 5 месяцев назад парня сказал только - “Команда без аналитика, что деревня без дурачка” и хлопал его по плечу. Пожалуй, можно было бы взять эту фразу эпиграфом к данному повествованию.
Укрепился я в мыслях, что аналитики пишущие документацию и формализующие бизнес-требования, эта специальность, доживающая свой век. И что убери такого аналитика - всем только полегчает.
У аналитиков теперь иная роль - копить знания, быть хранителями этих знаний и систематизировать эти знания.
Валерий Разномазов @ 2022
