Доброго всем вечера! Продолжаем тему REST. Наткнулся на прекрасный ликбез по тому, как спроектировать API и что надо не забыть!
https://levelup.gitconnected.com/restful-api-patterns-81930c43e494
#article

Знаете, сколько статей попадается, где начали за здравие, а закончили за упокой?
Вот например: https://rb.ru/opinion/work-with-stakeholders/
Вроде все неплохо, как ВЛАДЕЛЬЦУ ПРОДУКТА работать со стейкхолдерами. Читаем: проект, устав, RACI матрица и вообще про продакта забыли. Просто самый обычный бизнес-анализ. Вроде бы все неплохо описано, но обманутые ожидания очень сильно портят впечатления
#article

Привет, нашёл интересную статью про работу аналитика с реальными кейсами, да еще и с ошибками, таким готовы делиться не всегда. https://habr.com/ru/company/surfstudio/blog/651785/
#article

#breakfront_tooltips

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

Всем привет! Если вы все еще можете использовать Confluence - то вот вам cookbook от ребят из Тинькова, самое ценное, кстати, в конце. https://habr.com/ru/amp/post/495038/ #article

Доброго вечера! Прочитал неплохую вводную статью про PlantUML. Если не работали с этим инструментом, то рекомендую прочесть, а если работали, тоже гляньте, ребята разбирают не самую частую Activity диаграмму. https://habr.com/ru/post/661931/
#article

Всем привет! Прочитал интересую сводную статью, что значит работать по Agile. С точки зрения техники - написано очень хорошо, разложены составляющие, все ок. Есть одна проблема. Если это все соединить вместе это не будет Agile.
Agile - это не про инкремент и итерации, это про эволюцию, про возможность учиться на ошибках. Инкремент и итерация - это инструменты. Самое главное, что нужно помнить про Agile - это то, что он должен быть в голове у вас и у вашей команды. Если что-то не получилось, это не обязательно потому, что вы криворукие бездари, возможно, надо попробовать это сделать по-другому. А может быть - этого вообще не надо было делать?
Инкремент нужен для того, чтобы как можно раньше понять, что этого не нужно делать. А итерации - чтобы то, что все таки делать нужно, допилить именно в ту сторону, которую нужно.
Кросс-функциональная команда нужна, потому что мы все разные, и на проблему мы смотрим по-разному. Именно поэтому нужно, чтобы на проблему посмотрели и дизайнер и аналитик и разработчик и тестировщик. Каждый из них привнесет что-то свое и каждый позволит не упустить что-то важное.
Самое главное - что нельзя работать по Agile. Надо быть Agile - быть готовым меняться и подстраиваться. #article #agile

Для всех любителей BPMN Денис Котов выпустил новый цикл видео, смотрим, учимся у мастера!

Новый цикл видосов про бпмн - разбор конкретных, небольших, кейсов. Накиньте лайков плиз :) https://youtu.be/2_FuORr1W-o

🌐 Попробуйте новый евро-азиатский формат! 🌐

Друзья!
Мы запустили прием докладов на конференцию Analyst Days EU-1. United.

✅ Конференция пройдёт 2 октября в Ереване.

❗️ Конференция охватывает европейский и азиатский регионы, а потому мы ожидаем много спикеров из разных городов и стран. Тем более этому способствует безвизовый режим в Армении.
Кроме того, перечень рассматриваемых тематик существенно расширен.

Веб сайт: https://analystdays.eu/ru/index

Языки докладов: английский и русский.

Присоединяйтесь к нашему англоязычному чату: https://t.iss.one/analystdayseu

P.S. Конференция будет проходить совместно с конференцией по обеспечению качества ПО - SQA Days EU-2, которая пройдет на той же площадке 30 сентября - 1 октября.
При желании Вы можете посетить обе конференции.

Всем привет, короткий ликбез про бизнес-правила - все по полочкам и с примером! #article https://habr.com/ru/post/659045/

Доброго всем вечера! Меня давно не было, но у меня есть оправдание. Даже целых три, хвастаюсь:
1. В понедельник 16 мая мы с ребятами из Отус запустили новый формат обучения для выпускников нашей школы: разработчиков, тестировщиков и конечно же аналитиков. А к ним добавили ребят, которые хотя быть тим лидами и даже продакта нашли. Все как в настоящей жизни, будем все вместе пилить приложение. Что получится - расскажу позднее.
2. Впервые провел собственный, созданный с нуля оффлайн тренинг по бизнес-анализу. Получилось даже не комом, ребята остались довольны, но жду обратной связи, как они смогут применить знания на практике. Так что, если кто то еще хочет послушать меня лично - обращайтесь)
3. Ну и самое главное, но не относящееся к работе, 17 числа у меня родился сын, так что теперь времени на канал станет еще немного меньше.
Но я обещаю, что буду стараться писать!

Всем доброго утра!
Знаете, есть такой анекдот:
В 3 года, если ребенок упал, споткнувшись о скамейку, то он говорит, что виновата скамейка, не может же он быть виноват.
В 5 лет - у ребенка уже есть самокритика и он говорит, что виноват сам.
А есть люди, у которых и в 40 лет в их жизни во всем виновата скамейка.
К чему это я?
Прочитал чудесную статью https://habr.com/ru/post/661695/.
Вроде про ТЗ, но на самом деле про извечную боль, когда ты в проекте вместе профессионала натыкаешься на вот такого человека, у которого виновата скамейка.
Статья про то, как стараться справиться с такими людьми, если они попались на твоем пути и о том, что всегда нужно быть не просто сухим профессионалом, а еще и человеком и следовать не только букве контракта, но и включать эмпатию.
На своем опыте могу подтвердить, что это работает. многие люди это ценят и очень благодарны, когда ты помогаешь их проект отвернуть от провала или даже небольшой ошибки.
#article

Доброе утро. Короткая и толковая статья о том,как связаны Agile и Lean https://scrumtrek.ru/blog/agile-scrum/8644/lean-agile-raznitsa/
#article

Доброго субботнего вечера. Немного про MVP. Многие про это слышали, кто то даже делал. Но многие понимают MVP не совсем правильно, это не поделка просто для проверки гипотезы, ее проверять базово лучше вообще без разработки, например, примитивным лендингом на условной Тильде. И это не навороченный интерфейс с красивыми анимашками и мощной поддержкой. MVP - это продукт выполняющий базово одну или функции, закрывающие конкретные боли пользователей. Одну, но очень хорошо! Иначе шансов на успех будет не много. Подробнее про это можно почитать в вот в этой статье: https://telegra.ph/CHto-takoe-MVP-i-kak-sozdat-minimalno-zhiznesposobnyj-produkt-05-27
#article

Всем привет! Кажется, я понял, кем я хочу стать когда вырасту. Если честно работа с оптимизацией бизнес-процессов всегда привлекала меня, еще с самого начала моей карьеры в ИТ, когда я оптимизировал процессы на уровне внедрения систем электронного документооборота. Тогда я часто получал по шапке за свои "предложения по оптимизации", ибо они были либо очень дороги, либо упрощая жизнь конечным пользователям делали процессы дороже в эксплуатации. Для работы бизнес архитектором нужен реально крутой и глубокий опыт бизнес-анализа, наработкой которого я сейчас и занимаюсь. Ну а вам рекомендую вот эту статью: https://habr.com/ru/company/T1Holding/blog/646509/ #article

Пример крутой пользовательской истории и Job Story

неожиданно приятная фича.

Мне звонили. Я не поднял.

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

Мне показалось странным. а вам?

Пример очень странной, но если подумать удобной фичи.

Можно сделать шаг и попробовать описать разными методологиями эту самую фичу:

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

- jobs story - Позвонить через ТГ на номер из входящих. Согласитесь попроще звучит. При этом как писал в статье https://habr.com/ru/post/662672/

Важно не ставить какие-то ограничения на реализацую в рамках описания истории.

Доброго вечера. Студенты меня часто спрашивают про ведение документации, как правильно, где вести и т.д. Когда я начинал вариантов кроме ворда было не много, появлялись вики странички, но это было чревато работой с вики-разметкой, что далеко не всем подходило.
Потом появились модные конфлюенс и чуть менее модные ноушн и кода, в них доку стало вести удобнее, хотя по факту - это оптимизированные вики движки. Каждый со своими плюшками и минусами.
Я сам пока дорос только до этого уровня.
Хотя есть ребята, которые внедряют в свою работу практику Docs as Code, основанную на git и системе разметки, например, markdown. Вот пример реального использования. https://telegra.ph/Docs-as-code-DevOps-tehnologii-v-dokumentirovanii-ili-Kak-podruzhit-tehnicheskogo-pisatelya-i-razrabotchika-11-15
Да, статья, конечно пишет, что после этого освобождается 70% времени техписов, но мне кажется, что тут в первую очередь дело в синхронизации с разработчиками. Это не просто какой то писатель, а полноценный разработчик, со своей репой, коммитами и "кодом". Чувство причастности важная вещь.
Ну а в то, что это поможет драматически повысить скорость работы с докой - я не верю, если нет выстроенного процесса, то ни markdown ни notion не помогут.
Поделитесь в комментариях, кто чем пользуется и какие есть успехи?
#article

Доброго дня! Есть небольшая статья про GraphQL и Hasura, с практической точки зрения она бесполезна, т.к. не приводит никаких примеров использования GraphQL и не описывает реальных преимуществ над gRPC или REST. Но дает самое верхнеуровневое понимание. https://habr.com/ru/company/accenture/blog/578060/
Я сам все приглядываюсь к этому инструменту, но пока реальной надобности в его использовании не было. Насколько я понимаю и как следует из названия, инструмент реально хорош, когда у вас достаточно большие массивы взаимосвязанных данных, которые можно организовать в графы и по цепочке их вытягивать. Яркий пример - соцсеть Facebook, которая инструмент и создала, где в рамках запроса над тянуть друзей, их аватарки, их связи, подтягивать рекомендации новых связей по графам друзей и т.д.
У меня был пример, когда RESTу было тяжело тянуть связанные ресурсы по объектам в больших объемах (десятки тысяч сущностей) и приходилось бить это на несколько запросов, что, конечно увеличивало время получения данных + добавляло некоторые неудобства разрабам. И гипотетически организация API на GraphQL могла бы помочь, но эта задача была не сильно приоритетной и, как следствие, ушла на дно бэклога.
Но я верю, что однажды руки дойдут попробовать что-то слепить на GraphQL.