Я заметил, что в последнее время «созданием продукта» стали называть аутсорсинг BA, TPM, архитекторов и других «High-Value Resources» в дополнение к обычных технарям, но при этом позиционировать себя как абсолютно новое направление и всячески межеваться от аутсорсинга. Продуктовая компания это компания которая имеет последнее слово в принятии решений во всех сферах своего продукта (сервиса, товара, услуги), даже если аутсорсит некоторые из них сторонним компаниям. В общем случае правило простое — если компания К1 может единолично принять решение о закрытии сервиса С1, то она им владеет :)

По поводу реальных продуктовых компаний — так как у нас внутренний рынок жутко мал, продуктовые компании вынуждены начинать с рынка США, где наши локальные ресурсы не могут покрыть самые критические аспекты бизнеса — валидация идеи, продажи, маркетинг и т.д., поэтому многие компании имеют перекос в технический аспект, так как это сделать проще всего и понятнее всего.

Тем кто принимает решения, основываясь на ответах форума ДОУ, лучше никуда не идти.

Лет через 10 будут темы «Подскажите, как у вас получилось пролезть в кабинет к рекрутёру, чтобы подкинуть ей свой резюме.»

Вы спрашиваете как лучше добраться до неизвестно какого пункта назначения. Определите, что вы хотите в жизни и тогда _возможно_ кто-то даст примерный совет как этого достичь. Возможно, вам нужно сменить город, или страну, или профессию, или развивать бизнес, или удариться в техническую часть программирования, или поехать в отпуск на месяц, или на год, или почитать книгу, или просто помечтать, или развить бизнес, продать его и стать певцом, или просто стать певцом немедленно, или .... Любой из этих «или» может привести какого-то человека 37-ми лет, с бэкграудом описанном вами, к счатью и гармонии — вас ли?

Может здание офиса на територии старого кладбища?

Представьте мир в котором вам нужно прийти в большую торговую сеть и убедить их внедрить данную систему. Торговые сети тратят огромные суммы на то, чтобы заставить покупателей больше тратить, а вы им предлагаете внедрить систему, стимулирующую обратное :)

На основе статьи, для построения «своей» архитектуры должен случиться диалог по типу:
ПМ: Эй, парень, нужно изменить код другого парня, он вчера уволился. Там есть повторения.
ДЕВ: Я боюсь.
*Конец, везде огонь*

Какие оппоненты? Может сразу «врагам» или ещё чего-то похлеще придумать :)
Честно говоря, я не понимаю, что вы ждёте от этой беседы со мной и зачем вам вообще конкретика от автора, с таким настроем :)

Хм, «пунктами менее 10 слов» :) но зачем? Не думаю, что я могу добавить что-то к тому что описал автор.
Чтобы написать «high-level» декомпозицию на 5 человеко-лет для проекта без мудрёных атрибутов качества, нужно минимум неделю времени сферического архитектора в вакууме и ему сочувствующих экспертов, данный проект навскидку, по описанию, не меньше чем 50-100 человеко-лет. Чтобы подписать контракт, нужно дать оценку команды, чтобы дать оценку команды, нужно иметь примерный WBS, а как я уже прикинул WBS на такой проект это минимум месяц, а то и два минимум, просто чтобы понимать объём работы и подписать хотябы контракт на дискавери. Собственно, всё просто — начальные ожидания и предположения иногда не срабатывают, требования уточняются, меняются (никто не скажет клиенту — «уходи Клиент, с которым у нас контракт на выделенную команду в 100 человек — ты изменил требование») и т.д. «Делаем кеш» звучит как «пишем идеальную систему без багов» — способов десятки, нюансов сотни, не все известны архитектору, не всё он учёл сразу, где-то ошибся, где-то делегировал реализацию, а её сделали не так как нужно. Есть ли методы убрать эти риски — есть конечно, можно написать сотни способов как избежать А, Б, В, Г, Д.

Вроде как по тексту статьи производительность пофиксили к финальному релизу, не знаю, свечку не держал.
Я не говорю, что в данной истории комар носа не подточит, очевидно, что можно советовать «по верхам» пост-фактум много чего, но когда приходит клиент с бюджетом Х, а на идеальный процесс, с анализом, валидацией предположений и т.д. нужно 2Х (что есть примерно в каждом случае на рынке аутсорса) — приходится импровизировать на ходу. На ДОУ все как один максималисты и знают, что делать получше чем таксисты в политике, но я сужу по себе, я бы вряд-ли довёл такую махину до финала при всех описанных условиях. Для кого-то это плёвое дело, возможно, ну что же, по доброму завидую.

Забавно видеть как большинство начало растаскивать на цитаты и тешить эго фразами «как вы могли сделать ХХХ, вот я бы взял YYY и всё заработало как часы» — без понимания ни задания, ни условий. Хотя, по факту, команда в срок(sic!) закончила проект с приемлимыми значениями метрик. Деталей в статье маловато, но это другая проблема, уж всяк не техническая.

Так и не понятно — какие из перечисленных ошибок рекрутёров нужно разобрать?

Конечно )

И обижаться на компанию за рекрутера — не очень умно.

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

Если он закрывает вакансии, то, думаю, все он хорошо делает.

Я не говорю, что описанные техники — правильные и ведут к рекрутерскому успеху, я лишь о точке зрения.

Хороший вопрос. Под техниками обычно подразумеваются осознанные действия, но мне сложно поверить, что кто-то сел и сказал «Так, я не буду специально форматировать текст, чтобы вакансия выглядела так как будто я её надёргал из кучи мест, а половину перевёл гугл транслейтом» или «Так-с, у меня есть точный список технологий по проекту, но если я его добавлю, то это будет как-то глупо — точно, я добавлю туда всё что есть на рынке, так я смогу найти нужного человека гораздо быстрее!».

ну один то из 50 способен дать конструктивный фидбек? Это ведь тоже часть профессии рекрутера его вытащить. Хотя конечно сам «нет» я говорю в исключительно обтекаемых ничего не значащих формулировках.

.... WHAT...? нет, общий смысл я понял, но люди которые конвертируются в вакансии... Вы хоть и ЦТО, но описаний сами пожалуйста не пишите.

Как и всё в реальности — теория проще чем практика, если спросить «отнекавшегося» он может и не сформулировать свои претензии, это на форуме все блещут слогом. Часть людей конвертируется в вакансию в любом случае и при текущих проблемах, поэтому не вникают в такие детали.

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

Должен, но он никогда не был по нашу сторону баррикад и может не знать что спрашивать :) для этого я и запилил этот топик, чтобы подать идеи нормальным рекрутёрам, коих много, а плохим оно не нужно.