Comments 46
Плюсанул. Фундаментальный труд прямо. Во многом согласен. Только мало внимания вопросам надёжности. Это ведь не только тестирование. Надо вопросами надёжности озабочиваться прямо на этапе проектирования. По-хорошему, ещё архитектору (знаю, виноват будет все равно аналитик). В общем, молодец Валерий! Спасибо за обстоятельный анализ.
Довольно много спорных тезисов. Почему "отмирает" бизнес-архитектура? Почему "отмирает" ГОСТ 19/34 ?
А что такое "архитектура" энтерпрайз-систем вообще? "Микросервисная архитектура" - вообще говоря - и не архитектура вовсе, а так - паттерн, один из многих.
При любом раскладе, начиная разработку информационной системы надо понять для начала, а что, собственно, мы будем автоматизировать? Какие процессы? Для этого и нужен бизнес-анализ деятельности, которую мы собираемся автоматизировать нашей системы. И проводить его будет - бизнес-аналитик.
А дальше, надо эти процессы представить в виде ролей пользователей, функций системы и объектов, которыми эти функции управляют. В нашей парадигме этим занимается как раз системный аналитик.
Дальше - компонентная модель, архитектура данных, архитектура размещения, архитектура интеграции - это уже архитектор.
При таком раскладе по барабану что делать - монолит, микросервисы или гибрид. Просто каждый в проекте отвечает за свой кусок работы. А проджект отвечает за все.
И главное правило : сначала думаем, потом пишем проектную документацию, а потом только кодим. И забываем про аджайл, в период эксплуатации так получается дешевле и быстрее.
Добрый вечер! Я описал ситуацию. В сегодняшних реалиях весь бизнес-анализ остаётся на стороне заказчика. Поэтому в пррдуктовых командах бизнес-анализа мало осталось. А вот в системных аналитиках существует реалтная нехватка.
Я также писал о том, что в условиях agile вести документацию по ГОСТам стало невозможно. Почему? Потому что вы замучаетесь ее переделывать. Это же не "водопад", где пишется все один раз и навсегда. Другое дело, что AGILE должен быть в очень жёсткой упаковке. И далеко не вся документация его касается. Архитектуру можно и по ГОСТ описать.
Кто должен созлавать ролевую модель? В моих проектах этим всегда занимался бизнес-аналитик. Системный уже делал под это схемы и базы данных. Хотя допускаю, что где-то может быть иначе. Но вы не находите, что роли пользователей это чистая бизнес-категория?
Со всем остальным не очень согласен. Не по барабану. Монолит и микросервисы это может одна суть, но абсолютно разная начинка. Может быть в своей статье я рлрхо это передал.
Добрый!
Валерий, насчет "сегодняшних реалий" вы, пожалуй, погорячились. В ваших реалиях - да, возможно. В моей реальности не попадалось ни одного заказчика, способного сделать вменяемый бизнес-анализ.
Agile - не серебряная пуля, и чем дальше, тем очевидней, что привнося что-то полезное, он создает и новые, дополнительные проблемы. Вы же сами отмечали замечательный аджайл-тезис об отсутствии документации и о проблемах, которые в связи с этим возникают на этапе эксплуатации. Кстати, документация по ГОСТ делается достаточно легко, при любой модели. Проблема аджайла в том, что он ставит телегу - "работающий код" впереди лошади - документированных проектных решений. По такой технологии можно тяп-ляп запилить прототип, но энтерпрайз-система - она же не об этом, ее надо эксплуатировать и развивать потом не один год. А для этого нужна документация.
Что касается бизнес- и системного анализа - в разных организациях это устроено и называется по разному. И потом - мы же не о штатных должностях, а о проектных ролях. Разработка систем - такой же бизнес-процесс, как любой другой. Есть проектные роли, у них есть соответсвующие обязанности, процессы и все такое. В моем мире системный аналитик никогда не делал базы данных, этим занимался DBA, а за его отсутствием - архитектор.
Ну и вобщем, не спора ради - я об организации процесса разработки. Есть процесс, в нем есть роли, у них есть обязанности. Монолит, микросервисы, RESTы/SOAPы - это конкретные технические решения, которые принимаются не за ради модных и красивых слов, а на определенной стадии проекта, в соответствии с определенными - чисто конкретными - требованиями к системе. Ну а требования - они опять же, от бизнес-процессов заказчика. Ни один заказчик (ну мне такие не встречались) не скажет - мне нужна система на микросервисах. Заказчик скажет - мне нужна система, которая должна мне автоматизировать те-то и те-то функции. В-общем, мой пойнт в том, что решает процесс разработки, если он нормально организован, то проблем с применением тех или иных технических решений не возникает, будь то микросервисы, будь то хоть что угодно другое.
Ну я пишу про банки. Как правило там уровень зрелости бизнеса в ИТ очень высокий. И в банках agile выглядит таким образом, что роли перемешиваются и не ясно, где и чья зона ответственности. Хорошо, когда есть сильный архитектор,который может возглавить и повести за собой. Как правило, если что-то случается тут же все по норам и виноват аналитик :) почему? Ну он де писал документ, по которому велась разработка.
впрочем как и в «кастомной» ( от английского слова «custom» — “покупатель”
Простите?
Во-первых, custom — это грубо говоря «сделанный для конкретной цели», «заточенный под неё», что зачастую подразумевает тонкую настройку под себя (кастомизацию).
Во-вторых, покупатель это customer, а не custom.
Часто же, попадая в ИТ тусовку обращаешь внимание, на лексику айтишников. Она полна различных диковинных терминов. “Бекграунд”, “Фича”, “Пофиксить”… Эти новые слова дают ощущение недосягаемости знаний по ИТ
Это обычные заимствования, никогда не было мысли о том, что они делают индустрию недосягаемой, даже когда сам их не использовал.
Данный феномен характерен для закрытых сообществ, претендующих на некую элитарность
Данный феномен не обязательно связан с элитарность, далеко не обязательно.
Урки часто определяли своих по манере понимать блатную “феню”. Не говоришь на ней и не понимаешь, ну тогда тебе не место в криминальной среде.
Интересные аналогии, но у меня огромное чувство что вы переборщили с поиском глубокого смысла там, где его нет. Фичи, дейлики и т.п это обычный жаргон, ничего более.
Добрый вечер. Что касается "кастом" то я имел ввиду разработку своими руками. Везде все по-разному, я работаю в банках и тут "кастомный" это без вендора.
Что касается лингвистики. Да это транслит. Да, все пришло с запада. Но, если почитать их литературу, они трчно также дают хорошо известным сущностям новые названия. Зачем? Чтобы складывалось ошущение нового и таинственного.
Кастомную доработку может сделать и вендор. "Кастомный" от вендора, это когда разработка конкретно под конкретного заказчика.
Любая профессиональная сфера насыщена жаргонизмами, попробуйте послушать как говорят сталилитейщики, хирурги или трейдеры.
Доброе утро! В крупных компаниях "кастомный" это без вендора. Потому что считается, что вендор навяжет свое. А когда сами, своими силами и средствами, то свое не навяжет.
Любая профобласть богата сленгом. Но то что происходит у нас в области это феномен. Особенно, когда эти слова подхватывают эйчары и маркетологи. И вот заходишь на конференцию, да бог с ним, на собеседование. И не можешь понять, что от тебя хочет эйчар.
Работал аналитиком в банке, уровень засоренности сознания локальной терминологией могу понять. Но от вас как от аналитика хотелось бы понимания, что это местное косое трактование терминов.
Уровень отношений вендор - клиент в банке куда более плотный чем во многих других сферах и компаниях меньшего размера, сравнить можно с телекомом.
Спасибо за статью
Там еще ляпов хватает - Ганнта смешать с UML, а Swagger как альтернатива OpenAPI... Интересные мысли есть, но не покидает ощущение фрагментарности компетенции.
Бывает, обязанности перемешиваются - главное, чтобы они перемешивались за счёт помощи друг-другу, принятия части чужой работы, а не спихивания своей :)
На всякий случай скажу очевидное: не у всех всё так, как у вас.
Например, а нашей организации я как архитектор решений делаю многое из того, что у вас делает аналитик: официальную документацию, просчёт нагрузок, определение протоколов, договорённости со смежными системами, сетевые конфигурации и т.д.. За системными аналитиками в основном важнейшая работа по детальному анализу структур данных и потоков (типа откуда какое конкретно поле взять, какое отдать самим). В теории бывают ещё архитекторы информационной системы, которые должны прорабатывать разделение внутри системы вроде определения границ ответственности микросервисов. На практике они есть не всегда, и их работу берут на себя разработчики, согласуясь с архитектором решений. Но чтобы скидывать это на аналитика - пока такого не видел.
"корпоративные словари и классификаторы это порочная практика" - чем это объяснялось? У меня отдельная головная боль как раз с внесением сделанного нами в корпоративные словари и классификаторы. Причём это требование не просто к архитектору - этим даже бизнесовое руководство напрягают.
Доброе утро. Понимаете, вы правы. Эджайл, это прежде всего люди. Если люди нормальные и нет токсичных отношений в коллективе, то не так ведь и важно, кто чью обязанность будет исполнять. Так ведь? Тут мы имеем феномен - роли действительно перемешались, и вы своим примером это также подверждаете. Вы де пишете документацию? И тут же мы имеем проблему. Рано или поздно, кто-то скажет, а чего это я за него работаю.
Роль архитектора - ведущая роль. Он главный инженер и он теоретик происходящего. Да. Плохой архитектор - горе проекту. Ошибки вначале - трагедия в конце. И наверное, есть проекты, где есть нормальные архитекторы. Как вы. Но это редкость и исключение.
Со словарями это вечная тема. Как "Фауст" Гете.. Не буду вдаваться в подробности. Скажу только что кому-то не понравились не только они, но и каноническая модель. К чему это привело? В кулуарах поговорим...
Хм, за 6 лет работы аналитиком, в том числе на проектах с микросервисами, меня ни разу не обвиняли не в моей ошибке. Ошибки в разработке, в тестировании встречались чаще ошибок в анализе. И с ростом моего опыта ошибок в анализе становится все меньше. Да и когда они случаются, никто в меня пальцем не тычет и не стыдит всей командой, ибо ошибаются все и нормальные люди это понимают.
Но да, на аналитике лежит большая отвественность, нужно продумывать много вариантов развития событий, быть высокорганизованным и самостоятельным. И если челоек не готов лично отвечать за продукт и результат разработки - в анализ лучше не идти.
---
Как финальный вывод связан с текстом? Зачем это вообще в статье про анализ микросервисов? Про урковский жаргон и нападки за "элитарность" несколько иронично получилось, учитывая количество жаргонизмов, в том числе узкоупотребимых, в самой статье (в том числе слово "урки"). А ит-шный сленг может несколько обескураживать во многом из-за быстрого развития отрасли - словам просто не успевают придумывать русские аналоги, да это и бесполезно, так как бОльшая часть документации на английском. Вообще знание английского сильно облегчает вход в IT и растворяет ощущение "элитарности".
Татьяна, спасибо за комментарий. Думаю, что если я скажу, что за 2 года работы в аналитике у меня была диаметрально противополжная ситуация, не засиавит вас поменять точку зрения и встать на мою сторону. Думаю, что раз 6 лет в микросервисах, значит у вас опыт и знания. И скорее всего, в вашей компании выстроены четкие связи. И это хорошо. Я с удовольствием бы послушал про ваш опыт и поучился бы.
Давайте трезво взглянем на ситуацию. Сейчас на проектах нехватка кадров. И часто к нам приходят люди после "пулеметных курсов". Они конечно же хватаются разгребать бизнес-задачи и функционал. Ну это проще. Гораздо сложнее идти разгребать бек. В этом мой посыл по избытку специалистов по бизнес-аналитике и нехватке аналитиков системных. В сисиемной аналитике нужен и опыт и знания. И как правило ошибки в аналитике бека (а туда не всякий архитектор захочет лезть) влияют на сроки. А не ошибиться там нельзя. И ошибается тот, кто делает хоть что-то. Конечно, многое зависит от микроклимата в коллективе.
По поводу лингвистики. Понимаете, я хотел сказать что часто за лингвистикой стоит желание показать новое там, где его нет. Ведь согласитесь, нет в микросервисах бинома Ньютона. Просто ведь надо нужные слова выучить. И еще мой посыл был к нехватке у выпускников "пулеметных курсов " именно инженерных знаний.
Ну связи выстроены далеко не всегда, это вообще редкое явление. Опыт тоже был не всегда, я пришла из другой отрасли (правда есть профильное образование). С коллективами отчасти везло, отчасти помог навык выстраивания коммуникации, которому училась.
Про свой опыт с микросервисами писала тут.
Соглашусь, что работа аналитика - это отнюдь не "легкий способ войти в ай-ти", как обещают многие курсы. Но мой комментарий был про то, что если вас постоянно обвиняют в ошибках - то либо вы действительно много косячите, либо вы работаете с токсичными людьми. И в том и другом случае дело не в отрасли и не в должности.
В целом, конечно, работа аналитика часто сложная и неоднозначная. Но хотелось добавить немного другого опыта и сказать, что если это то, что нравится и хочется - не обязательно все будет так плохо, как в первых строках вашей статьи.
Про выдумывание новых слов объясняется, например, здесь. И почти в любой серьезной книге про микросервисы. Иногда новые слова вводят не для того, чтобы всех запутать и понтануться (хотя такое тоже бывает), а для придания нового смысла/формализации/распространения какого-то подхода или понятия. Учитывая молодость и скорость развития отрасли, мне кажется, стоит просто принять и смириться.
Татьяна, спасибо за ссылку. Любопытно будет ознакомиться.
Давайте я так скажу. Описанный мною опыт это специфика работы аналитиком на крупном проекте от интегратора. Думаю, вы не будете спорить с тем, что наемников никто не считает ? Аналитик от интегратора стоит заказчику дорого. Как правило, это эксперт. Ну действительно, у людей из интегратора опыта больше. Чисто статистически выборка увиденного больше. Это приводит к тому, что ты берешься за широкий круг задач. Остальной команде это выгодно. И если что, можно все списать на такого человека. И сказать, "а мы его выгнали и теперь все будет ок". Вообще конечно интегратор интегратору рознь. Но всё же. Это напоминает реалити-шоу начала 2000х. "Вы самое слабое звено. Прощайте ". И мне нравится один термин "покорное молчание большинства ".
По поводу лексики. Часто эйчары отсеивают кандидатов из-за того, что они не произносят нужные слова. И вот произнесению этих нужных слов и учат на воспетых мной "пулеметных курсах". И вы не находите, что моя любовь к ddd и онтологии отчасти от этого? И знаете. Мою статью можно разнести за предложенный конвейер или упоминание хайлоада и адаптеров. Нет... вме цепляются к смерти бизнес-аналитиков и сравнении айтишников с урками.
Лет 5 назад было абсолютно нормальным...
... за 2 года работы в аналитике...
Так сколько лет в итоге? :)
В прочем я о другом. Если "команда тычет пальцем" и обвиняет в ошибках, в большинстве случаев это повод задуматься: а вдруг она права? По крайней мере мой опыт так же не подтверждает тезис, что аналитик всегда виноват.
У меня такое чувство, что вы плохой аналитик. Перечитайте , к чему 5 лет и к чему 2 года. Может и вопросов меньше станет. Читать надо, читать. Разработка ПО это на 60% работа с документацией. А вы не умеете читать, но комментируете.
Если команда тычет пальцем на одного человека и обвиняет его во всем, а статья об этом, то дело в подходах команды.
Хороший аналитик умеет подать свой текст. Плохой будет обвинять всех подряд, что его не поняли и не приняли. ;)
Вам намекнули, что вы пытаетесь рассуждать о профессии и о том как там было 5 лет назад, на самом деле проработав всего пару лет в банке. Поймите уже, что пробему в первую очередь нужно искать на своей стороне.
Что такое “микросервис” технически и чем он отличается принципиально от “монолита”?
Хороший вопрос, не так ли?
У меня есть даже лучше вопрос: чем микросервисная архитектура принципиально отличается от сервисной (SOA), расхайпованной 10-15 лет назад? У меня только один ответ -- это то же самое, только собранное на коленке, реализованное на другом стеке, и игнорирующее всякие индустриальные стандарты.
Мартин Фаулер в 2012 году говорил о так называемой “слабой связности”. И “слабая связность” становится в микросервсиной архитектуре центральным понятием.
К сожалению, центральным понятием в микросервисной архитектуре на сегодняшний день являются именно все эти ваши докеры, кубернетисы, клауды, эджайлы, девопсы и прочие религиозные атрибуты. Сомневаюсь, что Мартин Фаулер в 2012 году имел именно это ввиду, говоря о слабой связанности.
Базы данных. “Слабая связность” в микросервисном подходе позволяет каждому отдельному микросервису иметь свою базу данных. А это значит, что её во-первых нужно спроектировать, а во вторых доходчиво для разработчика описать.
...а это значит, что ввиду отсутствия ACID у вас сразу теряется консистентность операций, и вам необходимо дополнительно искать искусственные способы обеспечения целостности данных, плюс по каждому предоставить доказательство, что в каждом данном сценарии целостность соблюдается. И на это будет тратиться львиная доля усилий архитектора решения.
Лет 5 назад было абсолютно нормальным говорить бизнесу о том, что ему надо. Теперь это не так. Бизнес теперь диктует ИТ, что ему нужно и сам предоставляет аналитику.
Это наверное в какой-то параллельной вселенной. Бизнес до сих пор требует одну большую кнопку: "сгенерировать прибыль" или "сделать красиво". На элементарные вопросы типа "что делать, если случиться то-то..." у бизнеса один ответ -- "мне лень об этом думать", или "ну вы там придумайте сами что-нибудь, я же плачу вам за это". Вся аналитика, которую я видел за свою карьеру в лучшем случае покрывает наивный самый оптимистичный сценарий, оставляя за кадром кучу кейсов. И что-то я не заметил, что ситуация сильно поменалась.
Вот теперь стало понятно, что нагромождение микросервисов плохо масштабируется и очевидно, микросервисы это не всегда хорошо. Так когда же нам стоит их использовать?
Тут можно добавить еще и организационный мотив: если над компонентом трудится более 5 разрабочиков, становится очень сложным координировать их работу, слияние веток, релизный цикл и т.д. Поэтому при возможности лучше разделить функциональные части и на каждую назначить свою небольшую команду.
И вот в этой единой точке входа мы складываем схемы (xsd или json). И вот по этим схемам должна осуществляться валидация данных.
И как это соответствует принципу слабой связанности иметь единый реестр сервисов? Это что-то типа UDDI из SOA?
--"Бизнес до сих пор требует одну большую кнопку: "сгенерировать прибыль" или "сделать красиво". На элементарные вопросы типа "что делать, если случиться то-то..." у бизнеса один ответ -- "мне лень об этом думать", или "ну вы там придумайте сами что-нибудь, я же плачу вам за это".
вот только за эту фразу стоит кричать браво! сразу видно человека "в теме". Обычно от бизнса умными словами оперируют только HR-манагеры, при этом не понимая половины терминов. А реальному бизнес-заказчику в 99% случаев это просто не интересно. Не реализуете вы, бизнес найдет другого исполнителя с большей вероятностью чем будет вникать в непонятные ему вещи. Исключения бывают - но обычно в случае, когда на стороне бизнеса выступает бывший технарь, поменявший проф ориентацию.
-"Бизнес до сих пор требует одну большую кнопку: "сгенерировать прибыль" или "сделать красиво". На элементарные вопросы типа "что делать, если случиться то-то..." у бизнеса один ответ -- "мне лень об этом думать", или "ну вы там придумайте сами что-нибудь, я же плачу вам за это". - со странным бизнесом вы работаете. Я пишу сиптью, про бизнес, который уже прошел трансформацию, денежку считает и понимает, зачем ему та или иная информационная система. В Прочем, допускаю что описанное вами существует. И даже, более того, сталкивался с таким. Могу также сказать, что канул тот Бизнес в Лету)
Приведу аналогию.
Вы ( Бизнес ) хотите доехать из точки А в точу Б. каждый день. и довезти такой-то груз. и вернутся. такая бизнес задача. Вы ставите задачу разработчику ( в данном случае транспортной компании наверное ) и формулируете задачу. Почему вас должно беспокоить размер колес, наличие бензина на заправках по дороге и т.п? Даже размер машины для перевозки вас в принципе не беспокоит. Вы ж в задаче указали вес\габариты\хрупкость и что там еще важно.
А вот перевозик уже строит анализ - а чего и за сколько надо-ть, да какого, да как сделать чтоб по дороге не сломалось..а если сломалось то как быстро починить чтоб груз не повредился. Озвучивается стоимость. Если договорились с бизнесом то ок. И реализует потом. А вы пользуетесь. Понятия не имея про колеса и что машины вообще на бензине ездят.
Конечно, всякая аналогия не может быть 100% корректной - но отношение такое Бизнес-заказчик - исполнитель вполне себе имеет место быть.
Потому что есть такая теорема эмерджентности в бизнес-анализе. Довоз груза это не только доставка, но и размер колес, стоимость бензина и прочее, что составляет специфику бизнеса. Поэтому важно понимать специфику. И с учетом цифривизации бизнес должен, я бы даже сказал, обязан понимать ит-специфику. Вот кто не поймёт, тот не выживет. Вспомните, что стало с Kodak.
не передергивайте. Разорился Кодак, а не фотографы. Фотографы спокойно переехали на цифру. И других поставщиков инструментов фиксирования окружающего.
Емерджетность доставки груза - проблема перевозчика ( исполнителя ). Именно перевозчик имеет шанс разорится, не учтя зимнюю резину в сезон снегов. А Бизнес-заказчик получит страхочку за недоставленный груз и пойдет к другому перевозчику.
Если Бизнес настолько продвинут что в состоянии провести грамотный бизнес-анализ своей задачи - то у меня вопрос есть. А когда он Бизнесом занимается-то? Или вы имеете ввиду наличие у Бизнес-заказчика своего подразделения бизнес-анализа? ну так это и есть первая ступенька "уже исполнителей заказа". Это подразделение к бизнесу ( в прямом смысле, к выполненнию непосредственных действий, приносящих прибыль ) уже не относится.
Я пишу сиптью, про бизнес, который уже прошел трансформацию, денежку считает и понимает, зачем ему та или иная информационная система
Ну то есть, который уже имел негативный опыт с предыдущим провайдером и теперь он "подкован" и ищет "настоящих специалистов своего дела". Либо это тот бизнес, кого эти "настоящие специалисты" уже успели развести на модные цацки.
Я работаю с крупным бизнесом, очень крупным, но смогу заверить, никуда он не делся и ситуация там вообще не поменялась. И впринципе норм: клиент не должен вникать во все детали реализации, если они напрямую не связаны с его бизнес процессами. А с бизнесом мы сами разберемся, получим необходимую информацию, поймем все задачи и проблемы, и предложим адекватное решение. Гораздо хуже, когда клиент мнит из себя Архитектора Матрицы и указывает провайдеру как правильно и концептуально дизайнить решение, какими средствами пользоваться, по какой методологии работать и т.д.
Исключения бывают - но обычно в случае, когда на стороне бизнеса выступает бывший технарь, поменявший проф ориентацию.
Бывший технарь был технарь в чём-то своём. Ему дико скучно слушать ваши вопросы. Он будет перебивать вас, сам ставя вопросы более лучшие и отвечая на них.
И как это соответствует принципу слабой связанности иметь единый реестр сервисов? Это что-то типа UDDI из SOA?
хороший вопрос вы задали. Отвечаю. Никак. Это попытка быть евреем-оленеводом. Пррсто иначе сдержать "семантическое безумие " и вырождение моделей данных с нагромождением адаптеров.
Значит, "слабая связность" это идеальная модель. И вы абсолютно правильно сказали про игнорированием всяких стандартов.
Пррсто иначе сдержать "семантическое безумие " и вырождение моделей данных с нагромождением адаптеров.
В "изначальной" модели этим должна была заниматься ESB -- быть централизованным законодателем корпоративных интерфейсов, контролировать всю их эволюцию, версионирование и адаптирование по мере необходимости. Однако это не сработало так, как задумывалось: практически все интерфейсы "локальны" и неиспользуемы никем, кроме непосредственно систем консьюмера и продьюсера. А двум сторонам договориться между собой гораздо проще, нежели трем. В итоге сегодня ESB -- это кучка дармоедов и нахлебников, основной задачей которых является выбить себе денег на очередной бесполезный меппинг полей, тем самым усложняя обмен данными между системами. Так что полностью согласен слабую связанность.
Вертикальное масштабирование, это когда увеличивают пропускную способность системы за счет применения более продуктивных компонентов. В случае серверов, заменой процессора на побыстрей, заменой оперативы на побольше, заменой постоянной памяти на побыстрей и побольше, заменой сети на более быструю.
Горизонтальное масштабирование это за счет добавления аналогичных компонентов. Был один сервер - добавили ещё один. Был один мотор - поставили два (у самолетов), было два цилиндра, сделали 4 - у автомобилей.
Статья здравая, но есть неточности от которых кровь из глаз.
Плюс статья очень субъективная. Я разработчик, у моих заказчиков я всегда виноват ?
Потому что аналитик говорит - я придумал идеально, исполнение подкачало. Виноват всегда последний в цепочке, тот кто непосредственно работу работал, осуществлял идею.
Виноват всегда тот кого проще обвинить, кто не даст сдачи.
Директор ни когда себя виноватым не назначит. Хотя виноват всегда руководитель, который выбрал или не ту задачу с которой исполнитель мог успешно справиться, или недостаточно отслеживал прогресс исполнения, что бы своевременно принять управленческое решение.
В команде каждый вносит вклад равный его зарплате. Если вы считаете, что с вас спрашивают лишнего, то или просите увеличения оплаты, или ищите другого работодателя.
Есть и другие субъективные моменты, вы или работаете от силы пять лет, или работаете 10, но на одном месте и с одними обязанностями.
Жизнь очень разнообрпзная штука. Нет в ней ни чего однозначного.
Вот я ждал, что кто-то прокомментирует эту мою вольность в вертикальном и горизонтальном масштабировании. Тут нужно пояснение. Горизонтальное это я имел ввиду докупить железа, в том числе и более мощного. А вертикалтное - исправить внутренние процессы. Понимаю, что это слишком вольная трактовка. Спасибо за комментарий.
Если говорить про бизнес-анализ в продуктовой разработке, то не заметил бы что он умирает. Просто сейчас это отдельная роль и допускаю что она не везде нужна.
БА это тот человек, который наполнит общим бизнес-смыслом и учтет все пользовательские сценарии взаимодействия независимо от используемых микросервисов. Он в них и не должен быть погружен, для БА системы ~черный ящик.
Спасибо за статью не про найм и обучение аналитиков:) Но по тексту есть много вопросов у вас в тексте ядерная каша из всего или вам нужно было выговориться.
Вы описываете опыт на конкретном предприятии, но при это по тексту постоянно есть указания на тренды, общие сложившиеся практики и пр. Для того чтобы определять тренды, моды нужно проводить исследования. Не нужно делать безосновательные выводы о том, кто, как и зачем применяет agile, какие-либо инструменты и пр.
3 года назад все делали маппинги - а теперь нет? Пропали задачи по интеграции со сторонними системами? 5 лет назад все говорили бизнесу что делать? За его-то деньги? Серьезно? Кто эти "все"? Это грубое обобщение.
По тексту много грубых логических выводов. Почему документация должна стать артефактом agile? В манифесте написано - "Работающий продукт важнее исчерпывающей документации". И это вопрос приоритетов. Если команда, которая делает рабочий продукт не успевает документировать, значит документирование нужно вывести за контур примменения agile. Например, техписы или аналитики могут описывать работу фичи/микросервиса уже после релиза, вне зависимости от спринтов команды разработки.
Agile - это методология для команды размером около 6-8 T-shaped специалистов, самоорганизованной, вовлеченной и пр. В ней нет такого понятия, как показывать пальцем на аналитика, который во всем виноват. Agile вообще не предполагает наличие аналитика. Решение вырабатывает команда и каждый знает и принимает это решение. И судя по тексту и комментариям, на вашем предприятии неправильно применяют agile методологии (как, в общем-то и во многих местах). Отсюда и проблемы.
Корпоративные словари и классификаторы - это очень плохая практика. Ведение словаря и его поддержание в актуальном виде - это дорого и приносит примерно ноль прибыли. Составление словаря - это задача для стажера, для которого временно нет работы, чтобы он пополнил свой словарный запас. Та проблема, о которой вы пишите словарем не решается. Разным словам присущи одинаковые значения - это называется синонимами. И это нормально для языка. А вот то, что аналитики не выявляют эти синонимы при проектировании - это проблема недостаточного погружения в домен.
За последний год грань между системными аналитиком и солюшн архитектором стала практически неразличимой. - это не потому, а потому что сложилась неправильная практика называть инженера/архитектора решений системным аналитиком.
Текст сам по себе плохо вычитан, в нем много ошибок.
Не Bitbucked, а Вitbucket. От слова bucket - ведро, изображение которого можно видеть на логотипе.
Много цитат. Они создают впечатление псевдоэрудированности. Подчеркну - впечатление.
Как можете заметить, вопросы не относятся к сути поста из названия. Я бы вообще только эту суть и оставил. Возьму ваши подходы работы с микросервисами на заметку.
Честно говоря, пришлось переварить, написанное вами. Может каша и ядерная, но никто не сможет меня обвинить в неполноте описания. Выговориться не надо, скорее я всегда страдал от отсутствия какой-либо академичности в ИТ. Ну нет тут ни монографий, ни статей, ни каких-то вывереных годами методик. Вот я и решил, эту академичность соорудить самостоятельно. Меня многие критикуют сейчас, все-таки на хабр хорошо бы слать короткие статьи. Не знаю, вопрос, открытый. Впрочем, считаю что проблему я описал хорошо и то что некоторые со мной не согласны, это абсолютно нормально.
В том-то и дело, что безосновательных выводов у меня нет. Как раз статья получилась большая, потому что я все обосновываю. Вы можете обвинить в неправильности выводов, но никак в небезосновательности.
Я не говорил, что не делают маппинги. Я говорил, что 3 года назад аналитики только и занимались, что маппингами, а теперь задачи существенно расширились.
Потому что документация стала артефактом Agile. Я об этом неоднократно говорил, на многих конференциях и 99% со мной соглашались. Мотивировал я тем, что после каждого спринта должна оставаться обновленная документация и давате же её сразу позиционировать, как артефакт.
А я сразу и сказал, Agile у меня в статье это нарицательный термин. И говорю вам еще раз - в большиснтвен проектов к слову Agile относятся так, что можно на ходу менять требования так, чтобы не обосновывать штрафные санкции к заказчику.
Минусуйте мне. Я считаю, что без словарей все загнется.
Мне кажется это данность. Сложно держать и штурмана и второго пилота и бортинженера. Легче всех заменить вторым пилотом.
Буду стараться вычитывать лучше.
Исправлю, спасибо.
Понимаете, я вот написал про сленг. многие обидились. Вот попытка что-то описать понятным языком или понятной аналогией обязательно приводит к некой отрицательной реакции. Для меня загадка, почему. Я высказался, по этому поводу, сравнив ИТ-ишщников с урками. Но вот ваше обвинение в псевдоэрудированности... да. я не смотрю ютуб. И не получал "ютубного" образования. Я читаю книжки. На ночь. и по-прежнему считаю, что те кто читают книжки, будут побеждать.
Аналитика микросервисов. Практический опыт аналитика в enterprise