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

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

👉 Когда эфир?
По понедельникам и четвергам в 10:00 по московскому времени. Будем делать их регулярно и, если нужно, будем делать чаще.

👉 А запись будет?
Будет.

👉 Как получить ответ на свой вопрос?
Заполнить форму.
Если мы по какой-то причине не сможем ответить на ваш вопрос (например, про тонкости релокации в конкретную страну), мы найдём эксперта, который сможет и пригласим его на эфир.
Ждём ваши вопросы и вас на наших эфирах.

Подписывайтесь на наш ютуб канал, на наши подкаст-платформы и наш телеграм канал с анонсами: @newhr

Всем привет. Наконец вернулись силы почитать что-то не связанное с новостями. На глаза попалась статья про процессный подход. Описывает общие понятия и отличия от функционального подхода к анализу. для начала самое то. #article #BA https://telegra.ph/Biznes-analiz-dlya-nachinayushchih-chto-takoe-biznes-process--osnovy-processnogo-podhoda-k-upravleniyu-12-03

Доброго вечера! Сегодня делюсь с вами статьей про Agile и PMBOK. Автор достаточно здраво и логично рассуждает про истоки и причины возникновения Agile, а так же разбирает примеры, когда лучше применять проектный подход, а когда гибкий подход к разработке.
С чем я категорически не согласен - это с тем, что в Agile есть риск увеличения сроков. Подано это так, как будет классические проекты всегда сдаются в срок. Но это далеко не всегда так. А зачастую Agile экономит время тем, что не реализуются ненужные требования. А в моей практике, если 60% того что реализовано по ТЗ используется пользователями, так что в данном ключе тезис очень спорный.
Как и с качеством, ведь когда сроки в проекте поджимают, чем жертвуют? Правильно, качеством. А в Agile ты постоянно что-то проверяешь, тестируешь, демонстрируешь и даже в случае ошибок - сразу получаешь фидбек и сразу исправляешь ошибки, даже если они просочились. Так что про качество все же спорно.
А в целом статья достаточно годная. https://telegra.ph/Agile-ili-PMBOK-chto-vybrat-dlya-vashego-IT-proekta-01-21
#article #agile

Доброго вечера. Сейчас уровень стресса просто зашкаливает, в этом хаосе далеко не так просто сохранить рабочую концентрацию. А что делать, если так уже полгода?
Наткнулся на годную статью про профессиональное выгорание. Сейчас это стало еще актуальнее, рекомендую к прочтению: https://telegra.ph/Kak-ponyat-chto-ty-vygorel-i-chto-delat-chtoby-vybratsya-02-20-2
#article

Всем доброго дня! Меня несколько раз спрашивали про ГАР (Государственный адресный реестр), то что вместо ФИАСа теперь. Сам я с ним не работал, а вот ребята из HFLabs сделали про него толковый ликбез: https://habr.com/ru/company/hflabs/blog/654085/
#article

Доброго утра! Миша Максимов и компания выложили новый ролик на канале ЦифраБуква, очень практично и занимательно https://www.youtube.com/watch?v=O31f4xg4_Kw

Доброго утра всем. Если давно хотели понять, что такое Domain Driven Development или DDD, то есть вот такая интересная статья с достаточно простым и понятным практическим примером. https://habr.com/ru/company/oleg-bunin/blog/650927/ #article

И в догонку. Достаточно давнишняя статья от Анны Обуховой, крутого Agile тренера о рывковом мышлении. Если вам кажется, что вы работаете не весь день, а всего пару часов, но при этом результаты у вас неплохие, возможно, что у вас именно этот тип мышления, рекомендую почитать! https://www.forbes.ru/karera-i-svoy-biznes/367223-podhod-k-shtange-chto-delat-esli-taym-menedzhment-ne-dlya-vas #article

Доброе утро. Прочитал обзор Александра Поломодова на книгу “Web API Design: The Missing Link”. Обзор короткий, но ёмкий, а книжку добавил себе в очередь на прочтение. #article #API https://apolomodov.medium.com/review-web-api-design-9ce14661dbcf

Доброго утра. И снова статья для вашего внимания. На сей раз это краткое описание, зачем СА читать Чистую архитектуру дяди Боба от ребят из Тинькова. Статья вроде не сложная, то требует погружения в понятия, достаточно близкие к написанию промышленного программного кода. Так что если статья будет для вас сложной, то читать Чистую архитектуру точно рано. А вот для меня эта статья подняла эту книгу на несколько пунктов вверх в очереди на чтение (да, я тоже пока не добрался до чистой архитектуры). #article https://habr.com/ru/company/tinkoff/blog/652999/

Всем привет, давно меня не было, настроения ни читать ни писать на приходило. Но вот восстановил привычку читать хотя бы одну статью в день. И по запросу студентов нашёл статья про акроним SPIDR. Если коротко, то он описывает основные способы декомпозиции пользовательских историй. Spike, Paths, Interface, Data, Rules. В целом, на курсе мы со студентами разбираем все эти подходы, просто не используем акроним. А для тех, кто впервые с этим столкнулся, вот ссылка на статью https://www.google.com/amp/s/blogs.itemis.com/en/spidr-five-simple-techniques-for-a-perfectly-split-user-story%3fhs_amp=true #article #Agile

И вторая статья сразу в догонку. Много вопросов всегда вызывает оформление проектных решений и то, какие разделы должны быть в таком документе. Коллеги из БКС поделились своим шаблоном архитектурного решения, которое по сути сводит внутри себя требования, в том числе бизнес требования, предложения по их реализации и техническое описание реализации. Шаблон очень достойный, особенно, если вы проектируете сложные системы с высокой ценой ошибки. В Agile выдержать такой уровень детализации, конечно, практически невозможно, но к нему надо стремиться, возможно, в формате описания базы знаний постфактум. Ну и бонусом можно считать сам шаблон в виде файла, ознакомиться однозначно стоит.
https://habr.com/ru/company/bcs_company/blog/651765/ #article

Всем хорошей среды! Очень короткое и очень толковое видео про асинхронность в REST https://www.youtube.com/watch?v=3D2kYmEa8rk

Доброго всем вечера! Продолжаем тему 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 Денис Котов выпустил новый цикл видео, смотрим, учимся у мастера!