Очень толковое выступление на Ted Talks про то, как сделать наши коммуникации лучше. Помимо главного - слушай своего собеседника, там есть другие моменты, на которых я ловил себя: я реально начинал что то делать параллельно со встречей - залипать в телеге или отвечать на письмо по работе и ловил себя на том, что и письмо так себе и контекст встречи я потерял. Да, у меня есть скилл реагировать на ключевые слова в беседе и включаться, но это не отменяет того, что ты потерял контекст обсуждения. И это важный совет - если ты не можешь участвовать в обсуждении - срочная задача или даже не срочная, но увлекательная - выйди, так будет лучше всем, иначе нигде не преуспеешь. А какие пункты зашли вам больше всего? https://www.ted.com/talks/celeste_headlee_10_ways_to_have_a_better_conversation#t-136370

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

Стратегии адаптации к стремительно меняющемуся миру: не бояться [не лениться?] браться за задачи с открытыми вопросами

Я убеждён, что GPT-4/5/N, Midjourney v5/vN, Stable Diffusion не будут увольнять людей. Я убеждён, что они все будут увольнять людей.

Вопрос кого уволят, а кого нет.

Если вы посмотрите на то, как распространялись инструменты автоматизации за последние 300 лет, то люди со временем занимаются всё более и более творческими задачами, рутинные, тяжёлые и механические работы автоматизируются. В США сейчас меньше 2% фермеров обеспечивают большую часть потребностей страны в еде и сырье для других индустрий. Современный фермер выдаёт на несколько порядков больше, чем его предок триста лет назад. Сеятелей тракторы заменили, а фермеров-предпринимателей нет.

Я убеждён, что AI, даже в текущем его виде, это инструмент/усилитель для людей, которые занимаются творческим трудом, такой же, каким являются трактор и автоматические системы орошения являются усилителями для фермеров.

Но!

Если сейчас человек работает только по ТЗ, не готов идти в неопределённость, искать ответы на вопрос “а какой образ результата?”, “а именно эту штуку надо делать? ачтобычто?”, “а может надо делать вообще что-то другое?”, “а как эту штуку можно сделать круче/дешевле/эффективнее?”, тогда таких людей заменят.

Если можно написать ТЗ, тогда нейросети по этому ТЗ очень скоро будут выполнять задачу лучше человека. Зачем отдавать ТЗ ненадёжному и дорогому кожаному мешку, когда можно быстро, стабильно и на очень высоком уровне получить от нейросети.

А вот если задача формируется открытым вопросом “а какой самый эффективный, дешёвый и качественный способ онбордить наших клиентов?” или “как написать лучшую книгу по продакт-менеджменту”, тогда нейросети это усилитель

И ещё одна статья про требования и иже с ними. Евгений Скориков описал u принцип выявления требований, который говорит, что невозможно выявить сразу все требования. Все равно после итерации выявления вы пойдете в проектирование и поймёте, что чего то не хватает. Только есть ощущение, что это скорее не u принцип, а скорее принцип синусоида. https://habr.com/ru/post/706956/

Вынужден во многом согласиться с Романом, кроме разве что предложения включать печатный станок - это похоронит всю экономику на перспективе 5 лет, еще хуже чем в великую депрессию. А про ИТ все так, сейчас вакансий мало, реально мало за рубежом, поэтому все советы очень актуальны

Антирекорд спроса на айтишников

Портал DOU сообщил об антирекорде на рынке труда IT. Пропасть между спросом и предложением на рынке труда продолжает расти в 2023. На 4х кандидатов только 1 оффер. Одна работа на четыре айтишника.

Что происходит?
У рынка IT аутсорса есть два типа клиентов — Действующий бизнес и Стартапы.

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

2. Бизнес реализует стратегию «антихрупкости» и пользуется моментом. Сокращает расходы на IT, оптимизирует команды и оставляет лучших. В бюджетах на 2023 фокус на операционную эффективность и кеш.

3. Сюда добавим внутренний спрос, который раньше создавали IT компании в рамках своих стратегий роста. Строили учебные центры, инвестировали в джунов и «свитчеров», содержали "скамью запасных" (бенч). Это процесс тоже сильно затормозился из-за туманных перспектив роста и отсутствия спроса на специалистов начального уровня.

Кстати, почему я говорю про рынок аутсорса? В этом рынке задействована основная часть наших айтишников, рынок огромный и является индикатором активности мировой экономики.

Вспоминаем 2021 год, когда денег в мире было много и спрос зашкаливал. Случилась эпидемия переоцененных кандидатов, которые перепрыгивали из компании в компанию в поисках +500$. Вчера наши рекрутеры получили сообщение на Джинне: «Здравствуйте! У меня в профиле стоит зарплата 4К, но готов работать и за 2К».

А что делать специалистам?

1. Фокусируйтесь на ценности для бизнеса. Речь не только о технических навыках, но и о вашей ответственности. Если умеете приватизировать ответственность за задачи и вас не надо менеджерить — вам ничего не угрожает.

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

3. Не игнорируйте тестовые задания. Придется снять корону и пойти на встречу. Для того, кто уверен в своих силах — тестовое задание — отличный способ проверить себя и увидеть зоны роста.

4. Учите английский. Умеете читать — научитесь говорить. Умеете говорить — научитесь делать презентации и тд.

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

Говорят, человек не может находиться в состоянии экономии дольше 4-5 месяцев. Душа хочет праздника. Вспомните, как все быстро начало отрастать после застоя в пандемию. Ждем оживления и роста к концу года.

Включайте уже этот печатный станок!

@katerynchyk_live

Очень странная статья про ТЗ. Маленькая аутсорс\аутстафф студия (судя по стилистике и подходу к документам) мечтает об идеальном заказчике с идеальным ТЗ. В мой практике практически не разу не было такого, чтобы заказчик тебе и 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/