• Первый — возможность получить обратную связь есть только тогда, когда код готов и пользователь может проверить решение, кликая разные кнопочки в GUI. Это часто приводит к тому, что реализованную часть системы приходится писать заново.
• Второй, что хуже — CODE FIRST предполагает каскадную модель разработки: нет возможности настроить параллельно несколько потоков работ.
• Третий недостаток — отсутствие документации и часто слишком детализированное API. Такое API невозможно переиспользовать. 
• И ещё один, четвёртый, минус — отсутствие адаптации к изменениям. А изменения обычно происходят уже во время разработки.

• Дефицит бизнес-навыков и аналитического мышления у дизайнеров.
• Маршруты, положенные в основу архитектуры системы и UI, часто не совпадают с картой бизнес-процессов пользователя. Проще говоря, дизайнер может изобразить любой вариант UI, но возникает вопрос: а можно ли реализовать ту или эту фичу как функционал?
• Ну и та же проблема, как и с CODE FIRST: нет возможностей для быстрой и эффективной адаптации к изменениям. 

Привет, меня зовут Денис, и я работаю руководителем отдела проектирования в компании SSP SOFT.

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

Начну с того, что я сам числюсь системным аналитиком всего два года. Я сразу попал в «ведущие системные аналитики», пропустил стадии junior, middle. Спустя год работы ведущим системным аналитиком, меня назначили руководителем отдела проектирования, доверили развитие аналитиков в компании. С этого момента я стал обращать внимание на то, как работают аналитики в разных проектах, чем они занимаются. В компании работает около 30 аналитиков, они заняты в проектах, связанных с разработкой программного обеспечения для бизнеса. Продукты и рабочие процессы в проектах сильно отличаются, это позволяет увидеть всё разнообразие типовых задач, которые выполняет аналитик в команде.

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

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

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

В этой статье хочу рассказать, что такое OpenAPI и зачем он может быть нужен.

Все мы думаем, что хорошо говорим и пишем на своём родном русском языке. Не зря же в конце концов мы столько учились, да и в деловой переписке у нас всё вроде бы вполне неплохо. Но знаете ли вы о том, что даже для написания IT-документации есть свои правила? Поэтому сегодня в блоге ЛАНИТ на Хабре мы поделимся знаниями о русском «документном» языке. 

Меня зовут Тимур Исхаков, я технический директор в Ak Bars Digital. Мы отвечаем за развитие ИТ Ак Барс Банка. 

В 2016 году, когда наша компания стартовала, мы сразу «пошли» в цифровизацию и аджайл. Начали со Scrum, которым уже тогда никого было не удивить: кросс-функциональные команды, Product Owners, пользовательские истории — выращивали продуктовую разработку. 

С 2018 года мы стали работать по SAFe: стримы, каналы, бизнес-юниты — вот это вот всё. И как результат — в 2021 году Ак Барс Банк занял 4 место в рейтинге самых инновационных банков России, а мобильное приложение Ак Барс Онлайн 3 года подряд входит в ТОП-3 лучших мобильных банков по версии Markswebb. 

В статье расскажу: зачем и как мы пришли к SAFe, как формировались стримы, о плюсах и минусах вариантов ориентации стримов на структуру бизнес-дирекций, ориентации на ИТ-продукт или на бизнес-продукт. В статье будет достаточно много терминов, связанных с SAFe — предполагаю, что вы с ними знакомы, хотя небольшие пояснения все же оставлю.

Вместо введения

Для кого я решил написать? Данная статья, написана для моих коллег аналитиков или для тех, кто желал бы им стать. Если вы теперь захотели стать аналитиком, то подумайте хорошенько. 

Микросервисы. С хайпом вокруг них, лучше быть разработчиком, архитектором, тестировщиком, проджект-менеджером, дизайнером. Хорошо быть кем угодно в микросервсиах, но только не аналитиком. Аналитик ведь всегда во всем виноват. Ни разу не слышал, чтобы в “факапе” и срыве сроков обвинили архитектора, ну или там разработку. Нет, господа, вина всегда лежала и будет лежать на плохой документации и нечетко поставленных задачах. Вот вся команда собралась и тычет в тебя пальцами. Дескать, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный проджект-менеджер обеспечил… а невнимательный аналитик все завалил. А меж тем, материалов по аналитике и как её вести на русском языке очень мало. И как “анализировать” эти самые микросервисы не совсем понятно. Более того, никто вам не скажет, чем “системный аналитик” теперь отличается от “солюшн архитектора”. Вот во всем этом я и захотел разобраться и поделиться. Поэтому, если вы не аналитик - не читайте. Вам не будет интересно. Ведь, нет в вас экзистенциального кризиса и вопросов “Кто я? и зачем я им нужен на проекте”.

Данную статью я направляю в сторону джунов и тех ребят, которые просили написать о том, как перестать перерабатывать на работе и не выгорать. Это максимально маленькая и простая инструкция для тех, у кого первые шаги в новой сфере после устройства на работу.

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

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

Однажды вы проснулись и поняли, что не хотите идти на работу. Поездка в офис — как поход на войну. И так уже было какое-то время, но вы не замечали. Спустя несколько недель к вам пришло состояние тотальной беспомощности и бессмысленности происходящего. Думая, что проблема в проекте, вы поменяли состав команды, саму работу, но ничего не помогло. Вы автоматически выполняли операционные задачи, а попытки отвлечься от работы заканчивались многочасовым созерцанием потолка. Потом появились проблемы со здоровьем.

Вы не одни. В сегодняшней статье Юлия Белозерова, которая выгорала уже полтора раза, решила поделиться своим опытом. Последние 10 лет она занималась управлением проектами в аутсорсинге, в продуктовых компаниях (ex-Yandex, ex-Epam, ex-Booking.com). Юля не врач, не терапевт, не психолог и не профессионал по выгоранию. Это взгляд выжившего.

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

Процессный подход был сформулирован во второй половине прошлого века и до сих пор остается одним из наиболее эффективных методов организации системы управления в компании. Краеугольным камнем данной методологии является понятие «процесс». Процесс — это совокупность взаимосвязанных видов деятельности, преобразующая входы в выходы, которые имеют ценность для потребителя. Таким образом, концепция процессного подхода, как системы управления, заключается в выделении конкретных бизнес-процессов компании, определении одного из участников в качестве владельца бизнес-процесса и делегировании ему полномочий и ответственности по управлению данным процессом.

В данном случае компания рассматривается, как система отдельных видов деятельности (бизнес-процессов), направленных на достижение конкретного результата и осуществляющих взаимодействие друг с другом посредством входов и выходов. В качестве входов в процессной методологии могут выступать: информация, документация, материалы, оборудование, человеческие ресурсы и так далее. Выходами бизнес-процессов является результат деятельности, который имеет ценность как для внешнего заказчика, так и для внутреннего. Стоит отметить, что важной отличительной особенностью процессного подхода от других моделей управления является не только выделение бизнес-процессов, но и постоянное их совершенствование.

К сожалению, несмотря на все достоинства и преимущества процессной методологии до сих пор в большинстве отечественных компаний используется функциональная модель управления. В отличие от процессного, в основе концепции функционального подхода к управлению делегирование полномочий и ответственности осуществляется через выполняемые функции. Другими словами, функциональный подход заключается в объединении сотрудников в отдельные структурные бизнес-единицы (отделы, департаменты и прочее) по принципу однообразия выполняемой деятельности с жесткой вертикальной иерархией.

Введение

Для кого эта статья

Статья для дизайнеров интерфейсов, которые желают понять то, как работают процессы регистрации, авторизации, восстановления пароля, применяемые в различных системах. Если вы разработчик/дизайнер, и нашли ошибку/неточность - то дайте мне знать (я с радостью доработаю статью).

Всем привет, мы – Таня и Лиза, системные аналитики в МТС. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашей команде.

Статья будет полезна тем, кто работает с фронтовым функционалом – системными и бизнес-аналитикам. Неважно, Junior вы или Lead, в большой работаете компании или в стартапе, – наш рассказ вас наверняка заинтересует. Поговорим не только о том, как мы докатились до такой жизни, приняли единый формат ФТ, но и том, какие именно артефакты аналитик готовит в ходе своей работы. А еще мы подробно расскажем про причины поиска подходящего формата, сложности перехода и составляющие наших ФТ. 

Добро пожаловать под кат!

Всем привет. Меня зовут Таня, я работаю системным аналитиком в МТС. В этой статье я расскажу о том, как писать документацию для разработки микросервисов. 

Моя команда развивает несколько виджетов на главном экране мобильного финтех-приложения. Когда мы «пилим» новую фичу, как правило, мы разрабатываем под нее новый микросервис. Я, как системный аналитик команды, проектирую наш будущий сервис и пишу документацию для разработки. Так как почти каждая новая фича требует создания своего микросервиса, мне часто нужно писать под это дело документацию. Поэтому хочу поделиться с хабровчанами тем, как это делается у нас в команде. 

Привет! Я Мария Фоменко, заместитель руководителя управления хранилищ данных и отчетности в Тинькофф. Расскажу о направлении DWH и о том, как попасть к нам в команду, что спрашивают на скрининге HR и на секциях системного анализа DWH.

Статья будет полезна тем, кто планирует расти в профессии, интересуется работой в большой компании или хочет работать именно в Тинькофф. Если узнали себя в любом из пунктов, добро пожаловать под кат ?

Теперь, заходя в одну из сетей общественного питания, я беру кофе 200 миллилитров, а не 300. И каждый раз улыбаюсь себе с упреком, что «гуру» интерфейсных манипуляций понадобилось полгода, чтобы увидеть этот паттерн. Теперь этот пример украшает мои лекции, в основе которых два постулата: дизайн — это про деньги и хороший дизайн возможен только с фундаментальной научной базой. 

Когда в коллегах согласья нет,
На лад проект их не пойдет,
И выйдет из него не profit, только cost.

Однажды Бэкендер, Фронтендер да Аналитик
Везти с тасками US взялись,
И вместе трое все в него впряглись;

Из кожи лезут вон, а US всё нет ходу!
Таски для них казались и легки:
Да Фронт рвется в Cloud-решения,
Бэк пятится назад, а Аналитик тянет в воду.

Кто виноват из них, кто прав, - судить не нам;
Да только UserStory и ныне там.

Уверен, многие узнали всем известную басню про трёх товарищей, которые пытаются затащить одну общую хотелку (некий воз). Только вот каждый тянет эту задачу в свою сторону, игнорируя усилия других. Сегодня я поделюсь с моими любимыми читателями примером, как сделать так, чтобы работа над задачей между тремя нашими героями шла дружно и эффективно.