Andrey ZaytsevДа, цирк. Но чтобы не стать в нём клоуном, важно отличать реальные потребности от имитации деятельности и не тащить на арену инициативы, которых никто не ждёт. А если весь спектакль вызывает только раздражение, возможно, стоит сменить площадку.
да, вот у меня сейчас майндсет как раз меняется. скорее просто для веселья хожу на такие звонки
Sergey PЕщё разделение на доменыые команды хорошо работает когда вас человек 100. Если меньше 50 может тупо не хватать людей все домены покрыть (ты и так будешь стараться что бы их было не больше 10).
3 команды - я бы в целом думал в сторону динамик ретиминг и формировать команды под инициативы + формирова
3 команды просто по признаку "живут в одной локации" были собраны. В Порто открыли представительство и набрали 3 разные тимы.
Домены сейчас начинают перекликаться. И кроссзависимости появляются.
"ретиминг + команды под инициативы" -- имеешь в виду брать Васю из команды А и Женю из Б. Делать фича тиму. Потом повторять на другие инициативы. Оно?
Если так, то это первая мысль которая мне в голову пришла на общем ретро :)
S Типа того, особенно если текущие границы команд приводят к зависимостям между ними. Мол вопрос кого с кем надо координировать больше, людей которые в одной команде но пилят разное или людей которые в разных командах так уж вышло но пилят вместе Там есть нюансы типа "где мы хотим более жёсткие границы в коде" все ещё лучше разные команды, или как-то следить что бы границы не поплыли (частое явление). Короч все эти приколы Conway's law
У меня обычно асампшены что границы доменов кривые если часто блокирующие зависимости возникают или ещё какие проблемы. Как минимум я бы проанализировал адекватность этого. Ещё на границы может влиять структура репортов которая тоже часто "исторически сложилось политикой или кого-то не хочется понижать увольнять"
До сих пор удивляет что подход "сели спроектировали контракт зафиксировали и и пилим паралельно людям оч сложно даются (в частности соблюдать потом контракт).
Ссылка
нажмите — покажем
нажмите — покажем
Зачем платить за софт, когда все можно завайбкодить
Смотрите, какой веселый эксперимент нашел. Ребята решили проверить, можно ли заменить какую-то платную внутреннюю корпоративную систему на самодельную реализацию, написанную с агентами за два дня. На вход взяли подробную документацию, описанные юзкейсы, руководства и демки.
На выходе, ожидаемо, получили довольно убедительно выглядящий прототип, который, тем не менее, разваливался в большом количестве сценариев, отличных от описанного в документации дефолтного – часть фичей оказались стабами, никакой нагрузки система не выдерживала, а важные эдж кейсы не были учтены.
Несмотря на этот довольно ожидаемый итог, мне очень понравился один вывод из этого эксперимента:
Сложная система обладает эмерджентными свойствами. Это свойства, которые возникают на стыке компонентов, а не внутри них.
Суть в том, что вот такие эмерджентные свойства никогда не описаны в документации, и чаще всего не описаны в тестах. В лучшем случае они существуют в головах разработчиков и тестировщиков, а чаще не существуют вообще нигде. И чем сложнее система, чем больше в ней взаимосвязей, тем больше там таких эмеджентных свойств. Именно это делает задачу клонирования чужих продуктов или даже переписывания собственных с одного языка на другой такими сложными.
47 · 2.1K · ☦ Все так. Просто раньше все эти граничные условия и определения неопределенного поведения делались в коде (так было проще), а теперь это можно делать текстовым описанием (теперь это будет проще). Дополняете описания всех конкретных случаев и получаете полностью рабочий продукт… собственно так раньше и происходило в общении тестировщиков, аналитиков, дизайнеров, владельцев продукта и разработчиков… Теперь это общение формализуется и из устного в текстовый переводится.M Имхо, для нормального клонирования необходима не только документация, но и тесты, так как многие такие свойства именно ими и описываются. Без тестов - это по сути разработка заново. Поэтому опенсорс в целом клонировать легко (если вы не SQLite, который ключевые тесты скрывает), а проприетарку приходится скорее разрабатывать с нуля.A B E А потому что не надо за 2 дня - за 3 недели написал готовую сравнивалку макетов и верстки с большой точностью и без лишнего шума. Теперь работа над UX и сбор фидбека по багам и в принципе по удобству и тому чего не учел от пользователей - это тоже фаза работы При этом без вайбкодинга я бы такое делал несколько месяцев (потому что во внерабочее время и в формате "сделай то-то и то-то а я пока поработаю" делал)
Teamlead Good Reads – ежедневные советы про менеджмент людей и командХодят слухи, что Amazon начал пытаться нанять обратно часть людей из списка сокращенных ранее в этом году.
Но топы не могут ошибаться, поэтому Amazon не отыгрывает свои решения, а запускает перспективный проект под кодовым названием "Boomeranf Reengagement Initiative". А такое уже тянет на повышенн
Вообще конечно мог ли б поинтереснее выбрать название для проекта. У нас вот космическая тематика обычно для внутренних названий :)
Ссылка
нажмите — покажем
нажмите — покажем
Я открыл клуб Подлодки про AI в разработке уже полгода назад. Он сильно помог участникам изменить рабочие процессы в их командах и научиться самим работать с агентами. За это время мы:
👉Провели 90 стримов про harness engineering и внедрение AI в команды
👉Собрали большую базу знаний про AI в разработке
👉Устроили аж два хакатона – делали автономные фабрики фичей и самообучающихся агентов
👉Собрали сообщество, в котором получается очень дельно обсуждать новости и помогать друг другу с решением проблем
Короче говоря, мне очень нравится, что получается – я и сам узнаю очень много нового, и радуюсь от того, сколько пользы получается дать другим участникам. Поэтому хочу напомнить и вам, подписчикам любимого канала, кому и зачем стоит вступить к нам:
Если вы хотите просто держать руку на пульсе происходящего в индустрии
Я вытаскиваю очень крутых экспертов из Uber, xAI, Meta, Яндекса, Cursor, а еще из кучи стартапов. Они рассказывают, как работают их команды – и вы можете узнать у них то, о чем на конференциях начнут говорить только через год.
В нашем закрытом чате мы разбираем все важные новости и изменения подходов к разработке. Если нет времени читать – вам приходит дайджест с главными выводами.
Если вы хотите вкатиться в лучшие практики AI разработки
Каждую неделю мы проводим 2-3 стрима на разные темы, где есть куча полезной информации – от автоматизации процессов QA или SRE до того, как строить внутренние AI платформы.
В нашем чате есть специализированные комнаты по самым горячим темам – например, локальные модели, или SDD. Клубчане делятся там своими сетапами и практиками.
А еще вам доступен RAG по всему контенту чата и прошедших стримов, так что найти нужный совет очень просто!
Если вы уже активно внедряете AI в свою работу или команды
Это ровно то, чем занимаются все в клубе – так что вы сможете найти единомышленников с похожими проблемами. Как работать со скептиками, как не попасть в зависимость от вендоров моделей, как внедрить локальные модели, как перес
👎12🔥7❤2👍2
19 · 2K ·