Очень странная статья про ТЗ. Маленькая аутсорс\аутстафф студия (судя по стилистике и подходу к документам) мечтает об идеальном заказчике с идеальным ТЗ. В мой практике практически не разу не было такого, чтобы заказчик тебе и Use Case и макеты и количество кликов расписал. Скорее можно это рассматривать через призму - что не забыть спросить у заказчика. Потому что если заказчик настолько шарит в разработке, что готов написать такое техническое ТЗ, то, кажется, он и разработку потянет https://vc.ru/dev/562769-plohie-tz-na-razrabotku-chto-v-nih-ne-tak-i-kak-ispravit

Чувствую себя некромантом, нашел в закладках статью про DDD трехлетней давности. Почитал, оказалось достаточно интересно с точки зрения ограниченного контекста и опасности его объединения или протекания с другими контекстами https://medium.com/it-dead-inside/domain-driven-design-things-to-remember-when-building-a-bounded-context-62ed1d0cb2ae

И еще один пример некромантии. Я наконец то выложил записи наших посиделок 1 марта (да, мне понадобилось всего 3 недели). Поговорили с коллегами про БА\СА и фуллстеков, где и как работать. Поговорили про грейды аналитиков и про то, как это все живет в эпоху побеждающего аджайла.
Коварный зум почему то сохранил видео в плохом качестве и, кроме того, к нам в эфир забегали боты с разным спамом и всячески нам мешали, поэтому в одном месте есть склейка. Я прошу за это прощения и обещаю в следующий раз сделать лучше! https://youtu.be/dtylIbXbcNU

Ооооочень крутая системополагающая презентация по DDD и всему что около него - от бизнес идеи - до ее реализации в коде. Рекомендую настоятельно к прочтению! https://speakerdeck.com/mploed/better-software-architecture-documentation-with-domain-driven-design

Немного занудства про документацию. Да, я помню, что я говорил, что она особо не нужна, но это она мне не нужна, а многим очень нужна, кто то даже жить без нее не может. Вот, например, ребята из селектела рассказали, как они свою БЗ систематизировали на гиперпространствах. https://habr.com/ru/company/selectel/blog/712756/

Весьма годная статья вообще не по теме канала. В статье рассматриваются приложения и продукты, которые стали вирусными и принесли своим создателям приличные суммы, несмотря на достаточно абсурдные назначение и функции https://vc.ru/marketing/639216-palki-kotorye-vystrelili-absurdnye-produkty-kotorye-neozhidanno-vzleteli-i-stali-kultovymi

Всем привет! Я тут ударился в продактство, учусь у Ани Подображных на интенсиве по дискавери, нужна пара человек для глубинного интервью. Интересны те, кто покупал на Авито запчасти для авто, желательно дороже 7000 рублей, с доставкой, то есть не сам ездил за ними. Так же интересны те, кто покупал с доставкой любые продукты дороже 15000 рублей. Если вдруг это вы - отзовитесь в личку или в комменты, пожалуйста.

Достаточно интересная статья от Ozon про их доменную структуру команд. Что оттуда полезного можно вынести:
1. БА, СА и ДА относятся не к технической, а бизнесовой команде. И на мой взгляд это правильно!
2. Разработчики тоже глубоко погружаются в бизнес. И это тоже правильно
3. Команды большие и поделить их на кросс-функциональные и независимые не получается. И это жизнь, у нас, например, тоже не получается построить полностью независимые команды.
https://habr.com/ru/company/ozontech/blog/724498/

Крутая статья про документацию. Я честно скажу - терпеть не могу писать документацию и всячески поддерживаю инициативу введения роли технического писателя. А в этой статье роль как раз и описана. А еще описаны проблемы документации. На моей практике чаще всего встречались 2 и 3, хотя и 4 часто бывает и она особенно убивает мотивацию пользоваться документацией, реально в разы проще и главное надежнее спросить! https://habr.com/ru/company/oleg-bunin/blog/648317/

Достаточно техническая статья про Event driven системы. И про частые ошибки их создания. https://theboreddev.com/common-mistakes-in-event-driven-systems/

Почитал статью от ребят из RuVDS про индексы. Такое впечатление, что из книжек надергали определений и объяснений, примеров, как это работает по конкретному поисковому запросу (хотя бы на пальцах) не хватило. https://habr.com/ru/companies/ruvds/articles/724066/

И сразу еще один серьезный заход - про Event storming. Достаточно толково, с описанием всех артефактов и самого подхода. Для меня стало открытием, что люди его используют и для непосредственного проектирования ПО. Я обычно строил описание процессов на ES, а дальше уже раздергивал на конкретное ПО и задачи уже без применения методик. https://agilemindset.ru/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-event-storming/

Статья про event Sourcing - как один из вариантов реализации потока изменений объектов. Предлагается хранить это все не в БД, а в последовательном логе событий. Мне немного сложно представить себе хранение информации в таком виде, как единственный источник, я всегда воспринимал, например, журнал транзакций в БД (а это как раз один из первых примером ES), как дополнительный источник информации и способ откатиться на определенное состояние. Что это перерастет БД я не верю. Хотя раньше люди не верили, что можно будет в БД JSONы хранить. https://habr.com/ru/companies/ruvds/articles/718768/

Интересная статья про способы организации доставки сообщений через брокеры. Интересна в первую очередь тем, что тут помимо хотя бы раз доставим и хотя бы раз отправим есть и один и только один раз доставим ьhttps://softwaremill.com/message-delivery-and-deduplication-strategies/

Интересная статья про проектирование. Я от части согласен с автором, что история с детальным проектированием действительно не вотчина аналитика. И очень часто остальную часть проектирования, когда нужно модель положить на код как то опускают и при оценке и при осмечивании и при учете сроков. Хотя, как справедливо заметил автор, это больше половин работы. Так же согласен про БД - я искренне не понимаю, зачем аналитика заставляют детально проектировать БД, индексы и раскладку по таблицам. Да, есть любопытные, типа меня, которые сами в это лезут, но требовать этого от аналитика в принципе - достаточно глупо. Он просто не умеет этого нормально делать, если он не бывший разработчик или DBA. Не согласен я лишь в том, что аналитик не должен проектировать. Должен, и моделировать и проектировать. Этим он повышает свою ценность и чем ниже он может опуститься в уровнях абстракции, тем более дешевых разработчков можно брать к нему в команду https://habr.com/ru/companies/ssp-soft/articles/728758/

Пример того, как делать не надо. X5 поделились своими "хаками" по написанию пользовательских историй. В итоге - просто взяли классическое ТЗ (с проектным решением) и переписали в формате стори. В итоге никакого креатива команде не добавилось, сами, как решить задачу придумать они не могут. Еще и подробность, присущую ТЗ потеряли. В целом - большой минус Х5 за подобные подходы. https://habr.com/ru/companies/X5Tech/articles/723742/

Только вчера рассказывал на АД про бережливое управление требованиями и тут нахожу статью, почти противоположную https://habr.com/ru/companies/rtlabs/articles/730806/. Автор топит за максимально подробное описание требований, судя по все обоснованно топит. А значит разработчики на госуслугах не ахти какие, раз им все так подробно вплоть до полей надо расписывать. Я по прежнему придерживаюсь мнения, что чем глубже команда погружена в предметную область, тем меньше можно и нужно расписывать!

Тут коллеги из AgileFluent проделали огромный труд и собрали у себя большой список агрегаторов вакансий, в том числе по профессиям

Собрали для вас список сайтов с вакансиями для разработчиков, аналитиков, продактов, проджектов, маркетологов и дизайнеров. Держите и делитесь с друзьями :)

Software
Dice | Crunchboard | End-to-End Computing | Toughbyte | ai-jobs.net | DataJobs | Jobtensor | Germantechjobs | KeyValues | TripleByte | WhiteTruffle | Underdog.io

Analytics
ai-jobs.net | icrunchdata | DataJobs | Digital Analytics Association | KDnuggets | Open Data Science | Starbridge Partners | Big Data Jobs | Dice | arc.dev | datajobs | datayoshi | dataumbrella | outerjoin

Product
Product Manager HQ | Mind the Product | Product Hired | Women in Product | Product School | Product Manager Job Board | Product Marketing Alliance | ProductHunt | Lenny's Job Board

Project
PMWorld 360 Magazine | Project Management Crossing | Project Manager Jobs | Project Management Institute

Marketing
American Marketing Association | MarketingHire.com | Society for Marketing Professional Services | Hey Marketers | DGMG Jobs | Demand Curve | Mediabistro | ProBlogger | OnlyMarketingJob | Swipfiles | MarketingWeek | ExitFive | MediaBistro

Design
Design Jobs Board | Behance | Dribbble | Authentic Jobs | Early Stage Design Jobs | Creative Mornings | AIGA Design Jobs | Creativepool | Mediabistro | Shillington | Coroflot | IfYouCould | DesignObserver | Awwwards | GetCreativeJob | Krop

GameDev
GameDevMap | Ingame job | Talents in Games | GDTalents | ArcadJobes | GameDeveloper | GameIndustry.biz | GameDevJobs | GameJobHunter

All industries
Indeed | Glassdoor | LinkedIn | Facebook | Craigslist | Monster | CareerBuilder | SimplyHired | StepStone | Beyond | Jobspresso | Google Careers | Relocate.me | Layboard | Built in

Remote and flexible work
We Work Remotely | Odesk | FlexJobs | Remoters | remote.co | JustRemote | Pangain | Remotive | SkipTheDrive | RemoteOk | WorkingNomads | JobEspresso | remocate.app

StartUps
AngelList | StartUpHire | The Muse | StartupJobs | YCombinator | StartupList | Upwork | Startupers | AuthenticJobs | Hired | Gigster | WorkingNotWorking | EuStartups

Список из 50 джоб-бордов можно забрать тут: https://agilefluent.notion.site/fb2fd24bb1db46e6b8cf1b4f60c65a0d?v=1449ec36b45646cca6d6133aa67026ad

#jobboards_AgileFluent

Коллеги, всего 11 человек хотят поболтать?