Столкнулся с интересной проблемой. В мою бытность в России и США, за дизайн архитектуры и его поддержание с развитием системы всегда отвечал один человек. Его могли делать разные люди, но в конечном итоге согласовывали его с "генеральным конструктором системы". Я до сих пор помню как мой шеф сказал мне: "у нас тут не демократия".
После переезда в Европу я все больше сталкиваюсь с техническими компаниями, в которых таки демократия. Собирается несколько человек, часто с взаимоисключающими интересами, и пытаются что-то решать. Или например несколько разработчиков у которых чисто индивидуалистический подход, мне выгодно сейчас так, потому что на peformance review я смогу показать как я хорош. А ваши сомнения про maintainability, quality, и т.д. на PR не выташишь.
В моем случае это решалось применением власти. Но тут демократия, надо со всеми договориться. Вот и создают эти компании страшный суп из адского кода, дивно мусорных данных и инсталляций elastic-а стоящих 3m USD в год и приносящих ровно нуль пользы бизнесу.
Не буду вдаваться в технические детали. Общая картина что каждый делает что хочет и как хочет, пока не наступает пора как-то это интегрировать — например построить отчетность по всем отделами, или сделать ML рекоммендации, и тд. И тогда виновники как-бы не причем, потому что у них только часть данных. А вот народ который должен все это интегрировать — это их проблемы. Надо сказать, что такое я видел часто в огромных глобальных компаниях. Но тут-то один IT отдел в 100 человек. Когда начинаешь ставить под сомнение такую культуру принятия решений, начинают говорить что 5 человек-то точно лучше разработают систему, чем 1.
Это интересный взгляд на вещи, но если посмотреть на успешные проекты в open-source, например Linux, Go или Python, то тут же нарываешься на Benevolent Dictator For Life.
В связи с этим у меня вопрос:
*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?*
G>Столкнулся с интересной проблемой. В мою бытность в России и США, за дизайн архитектуры и его поддержание с развитием системы всегда отвечал один человек. Его могли делать разные люди, но в конечном итоге согласовывали его с "генеральным конструктором системы". Я до сих пор помню как мой шеф сказал мне: "у нас тут не демократия".
Это, вероятно, в мелких компаниях. В больших обычно лоскутная автоматизация, и зоопарк систем, созданных/купленных разными командами в разное время. Потому что старые команды разбредаются, а на новое всё разом не переведёшь.
G>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?* https://ru.wikipedia.org/wiki/Артель
Ленинградская артель «Столяр-строитель», начав в 1923 году с саней, колёс, хомутов и гробов, к 1955 году меняет название на «Радист»: у неё уже крупное производство мебели и радиооборудования. Якутская артель «Металлист», созданная в 1941 году, к середине 1950-х располагала мощной заводской производственной базой. Вологодская артель «Красный партизан», начав производство смолы-живицы в 1934 году, к тому же времени производила её три с половиной тысячи тонн, став крупным производством. Гатчинская артель «Юпитер», с 1924 года выпускавшая галантерейную мелочь, в 1944 году, сразу после освобождения Гатчины, делала остро необходимые в разрушенном городе гвозди, замки, фонари, лопаты, а к началу 1950-х выпускала алюминиевую посуду, стиральные машины, сверлильные станки и прессы.
В блокадном Ленинграде выпуском автоматов Судаева (ППС) занимались артели, которые располагали машинным парком, станками и прессами, сварочным оборудованием.
В самом начале 1941 года Совнарком и ЦК ВКП(б) постановлением дали указание начальникам меньше вмешиваться в деятельность артелей, подчеркнули обязательную выборность руководства промысловой кооперацией на всех уровнях. На два года предприятия освобождались от большинства налогов и госконтроля над розничным ценообразованием. Единственным и обязательным условием было то, что розничные цены не должны были превышать государственные на аналогичную продукцию больше чем на 10—13 %
Здравствуйте, Osaka, Вы писали:
O>Это, вероятно, в мелких компаниях. В больших обычно лоскутная автоматизация, и зоопарк систем, созданных/купленных разными командами в разное время. Потому что старые команды разбредаются, а на новое всё разом не переведёшь.
С большими компаниями все понятно, я говорю про отдел в 100 человек разрабатывающий софтверный продукт с нуля.
O>https://ru.wikipedia.org/wiki/Артель
Гм, я не вижу тут больших технических систем. Производство очень хорошо параллелится, IMHO. И опять же выполняется по чертежу системы. Они же там не 100ми человек выдумывали чертеж? Или это шутка?
Здравствуйте, Gurney, Вы писали:
G>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?*
Я считаю (и в тех компаниях, где я работал, так оно де-факто и было), что должен быть один человек — тех лид или архитектор — который отвечает за концептуальную целостность системы и преемственность в ее развитии.
Но при это архитектурные вопросы вполне могут (и даже должны) обсуждаться более широкой группой людей (архитектурным комитетом), в которой тех лид обладает правом решающего голоса / вета.
Таким образом:
(а) Мы уменьшаем количество ошибок. Так как тех лид — тоже человек — и он может элементарно чего-то не знать, не учесть и т.д.
(б) Члены команды чувствуют сопричастность к принятым решениям, а значит скорее будут поддерживать их, чем тихо саботировать.
(в) В ходе обсуждения члены команды лучше понимают причины, по которым было принято то или иное решение.
(г) В случае, если обсуждение заходит в тупик, тех лид может элементарно принять executive decision, либо можно даже проголосовать, если проблема относится к области "вкусовщины".
(д) В случае, если тех лид захочет уйти, наличие комитета обеспечивает большую преемственность. Во-первых, новый лид, который скорее всего будет взят из того же комитета, будет лучше знать подоплеку системы. Во-вторых, в теории, новому лиду будет сложнее волюнтаристки изменить направление тех развития системы.
Кстати, если подняться на уровень предприятия, я не раз сталкивался с ситуациями, когда жизнеспособные системы были построены из зоопарка технологий. Жизнеспособные — в том смысле, что они обеспечивали деятельно компании, но при этом вполне могли быть неэффективными, с т.з. поддержки и развития. Но после бездумного внедрения "жестких технических политик" они становились еще менее эффективными Это хорошо описано у Ашманова в главе "Общая проблем общей шины".
O>>https://ru.wikipedia.org/wiki/Артель G>Гм, я не вижу тут больших технических систем. Производство очень хорошо параллелится, IMHO. И опять же выполняется по чертежу системы. Они же там не 100ми человек выдумывали чертеж? Или это шутка?
Производство электроники в 50гг — между прочим, не с алиэкспресса плату с корпусом заказать и отвёрткой свинтить. Это именно примеры освоения высочайшего хайтека того времени — группой равноправных товарищей без вертикали власти.
G>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?*
В системе, где решения принимаются командой, в результате не понятно, кто за что отвечает. Да и шансов продавить свое мнение больше у того, кто
более упертый баран (буду бодаться, пока не примут мое решение),
кому больше всех насрать (пофиг на архитектуру и последствия, главное, чтобы все было по-моему),
кто лучше умеет языком работать, чем руками (и выдавать желаемое за действительное).
Из мне известных работающих систем — комитет C++. Но так принимают только такие решения, против которых не будет большого количества противников. Когда есть несогласные, то начинают удалять из предложения части, вызывающие несогласие. В результате проходят голосование только те части предложений, с которыми все (или многие) согласны.
Самому интересно, есть ли реально работающие коллективы с демократией на деле (а не на словах для пропаганды), которые в течение длительного времени могут создавать и развивать большой и сложный продукт. Ну, и как они избавляются от мудаков, которым на все насрать, кроме своего единственно правильного мнения (потому что в реале с такими предпочитают не связываться, поэтому они могут паразитировать довольно долго, особенно, когда умеют мимикрировать).
Здравствуйте, Gurney, Вы писали:
G>Столкнулся с интересной проблемой. В мою бытность в России и США, за дизайн архитектуры и его поддержание с развитием системы всегда отвечал один человек. Его могли делать разные люди, но в конечном итоге согласовывали его с "генеральным конструктором системы". Я до сих пор помню как мой шеф сказал мне: "у нас тут не демократия".
G>После переезда в Европу я все больше сталкиваюсь с техническими компаниями, в которых таки демократия. Собирается несколько человек, часто с взаимоисключающими интересами, и пытаются что-то решать. Или например несколько разработчиков у которых чисто индивидуалистический подход, мне выгодно сейчас так, потому что на peformance review я смогу показать как я хорош. А ваши сомнения про maintainability, quality, и т.д. на PR не выташишь.
В РФ — да, верно, но в американских компаниях как раз то, что ты описал же.
G>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?*
Да, в Автодеске так было и системы были вполне жизнеспособны. Просто иногда надо было из Сингапура лететь в Сан-Рафаэль что бы согласовать какую-нибудь хрень, так как надо со всеми договориться. Один раз неделю рисовал схемы и проводил презентации только что бы не лететь в Торонто на месте договариваться. Да не эффективно, но пока бабло течет рекой это ни кого не парит
Здравствуйте, kaa.python, Вы писали:
G>>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?* KP>Да, в Автодеске так было и системы были вполне жизнеспособны. Просто иногда надо было из Сингапура лететь в Сан-Рафаэль что бы согласовать какую-нибудь хрень, так как надо со всеми договориться. Один раз неделю рисовал схемы и проводил презентации только что бы не лететь в Торонто на месте договариваться. Да не эффективно, но пока бабло течет рекой это ни кого не парит
Это интересно.
— Были ли владельцы компонентов?
— А можешь рассказать более подробно на каком уровне приходилось договариваться (владельцы компонентов, программеры, архитекторы)?
— Каким образом договаривались про унификацию? Например что город предстваляется одним и тем же идентификатором во всех системах?
— Как осуществлялся большой change management в системе?
— Какого размера была команда продукта? Сколько продукту было лет?
Здравствуйте, Osaka, Вы писали:
O>>>https://ru.wikipedia.org/wiki/Артель O>Производство электроники в 50гг — между прочим, не с алиэкспресса плату с корпусом заказать и отвёрткой свинтить. Это именно примеры освоения высочайшего хайтека того времени — группой равноправных товарищей без вертикали власти.
Я по первоначальному образованию инженер радиоэлектронщик. Я знаю как в те времена делали электронику. В любом случае есть 2 очень разных процесса, проектирование и сборка.
В статье кстати ничего не сказано про равноправие товарищей. Там есть про выборность руководства. Это не сходится с равноправием.
Здравствуйте, Джеффри, Вы писали:
Д>Здравствуйте, Gurney, Вы писали:
G>>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?*
Д>Я считаю (и в тех компаниях, где я работал, так оно де-факто и было), что должен быть один человек — тех лид или архитектор — который отвечает за концептуальную целостность системы и преемственность в ее развитии.
Я то с вами полностью согласен, однако мне уже который год компостируют мозги что это не так.
Д>Кстати, если подняться на уровень предприятия, я не раз сталкивался с ситуациями, когда жизнеспособные системы были построены из зоопарка технологий. Жизнеспособные — в том смысле, что они обеспечивали деятельно компании, но при этом вполне могли быть неэффективными, с т.з. поддержки и развития. Но после бездумного внедрения "жестких технических политик" они становились еще менее эффективными Это хорошо описано у Ашманова в главе "Общая проблем общей шины".
Это понятно, на определенном размере компании это перестает работать. Большая компания со спектром технических систем это нормально, если задачей этой компании является не производство этой системы.
А вот представьте вам нужно построить ракету. Где любой сбой приводит к исчезновению полимеров в количестве 10-ов и 100-н миллионов долляриев. И у вас есть комитет дизайнеров. Который принимает стандарт:
— все измерения вести в имперской системе единиц
— кроме двигателистов, они пусть пользуют свою МКГСС (потому что они отдали нам свои голоса против сторонников системы СИ)
— кроме навигационщиков, они пусть пользуют свою сатанистскую СГС (ну вы знаете)
Вы бы на такой полетели в космос? Заплатили бы за нее денег?
Здравствуйте, Reset, Вы писали:
R>В системе, где решения принимаются командой, в результате не понятно, кто за что отвечает. Да и шансов продавить свое мнение больше у того, кто
Да, это именно мое видение ситуации.
R>Из мне известных работающих систем — комитет C++. Но так принимают только такие решения, против которых не будет большого количества противников. Когда есть несогласные, то начинают удалять из предложения части, вызывающие несогласие. В результате проходят голосование только те части предложений, с которыми все (или многие) согласны.
Это интересный пример. Но:
— В течение долгого времени у C++ был Benevolent Dictator в лице Страуструпа
— Язык уже достаточно выверенный временем и с большой аудиторией экспертов. Поэтому если кто-нибудь попытается протолкнуть уж совсем дичь — у него ничего не выйдет.
R>Самому интересно, есть ли реально работающие коллективы с демократией на деле (а не на словах для пропаганды), которые в течение длительного времени могут создавать и развивать большой и сложный продукт. Ну, и как они избавляются от мудаков, которым на все насрать, кроме своего единственно правильного мнения (потому что в реале с такими предпочитают не связываться, поэтому они могут паразитировать довольно долго, особенно, когда умеют мимикрировать).
Мне вот тоже черезвычайно интересно. Потому что я пока видел что это работает если:
— Большое количеством свободных ресурсов, то есть либо когда денег / времени навалом
— Низкие технические риски, то есть от фейла ничего не зависит
— Качество и эффективность никого не волнует
G>В статье кстати ничего не сказано про равноправие товарищей. Там есть про выборность руководства. Это не сходится с равноправием.
Равноправие не исключает выборов вождя (чтобы групповую деятельность координировать и "пропускать через 1 голову").
При равноправии вождь существует в рамках задачи для которой он выбран, и сколько существует задача. А не потому что "у него высокий статус по жизни" а остальные с этого должны ему платить и каяться.
Рядом с темой артелей лежит, кстати, система Макаренко, при которой пара участников может в параллельных по времени проектах быть в разных ролях главный-подчинённый.
Здравствуйте, Gurney, Вы писали:
G>- Были ли владельцы компонентов?
Были в лучшем случае уровня команды, так проще размазать ответственность и создать полную безответственность. Одан раз был ответственный в виде архитектора, но это скорее исключение.
G>- А можешь рассказать более подробно на каком уровне приходилось договариваться (владельцы компонентов, программеры, архитекторы)?
Ищешь хоть кого-то договороспособного и готового принять на себя хоть малейшую ответственность и договариваешься. Обычно кто-то наиболее продвинутый в команде + менеджер.
G>- Каким образом договаривались про унификацию? Например что город предстваляется одним и тем же идентификатором во всех системах?
Это проще, просто выходишь с предложением, т.к. никто ответственность на себя брать не хочет, то после нескольких итераций на тему "тут надо строчную букву, а не прописную" идентификатор принимают.
G>- Как осуществлялся большой change management в системе?
Через кучу картинок, презентаций, согласований, а потом, иногда, и через работу с менеджерами которые уже как-то договаривались с командами.
G>- Какого размера была команда продукта? Сколько продукту было лет?
Куча команд, куча взаимодействующих продуктов, сотни людей и продукты старые как говно мамонта (легко находился код 15-20 летнего возраста).
G>Спасибо!
Здравствуйте, Gurney, Вы писали:
G>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?*
Здравствуйте, wildwind, Вы писали:
G>>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?* W>Веб. Со скрипом, но работает.
Да, имеет смысл. Ограниченное время жизни, малозависимые друг от друга части...
Спасибо
Здравствуйте, Gurney, Вы писали:
G>*Кто-нибудь видел реально работающие компании где без жесткой технической политики удается простроить жизнеспособные большие технические системы? То есть вот этот дизайн архитектуры комитетом работает?*
Чем «генеральный конструктор системы» отличается от простых смертных? Тем, что может видеть «интересы системы» в целом и противопоставить их частным интересам разработчика. (Например, если он — «играющий тренер», то есть, пописывает код сам, то он не должен злоупотреблять служебным положением и пропихивать любимую библиотеку потому, что лень другую изучать, которая объективно лучше. Хотя такие уроды бывают). Это редкий талант, состоящий из: многая знания, многая печали, большого и разностороннего опыта (в терминах Valve — T-person, горизонтальная планка означает кругозор, вертикальная — экспертизу в предметной области), честности с собой и окружающими, просто ум, в конце концов. Обычно на проекте один такой и ему дают большую палку бить ракощуколебедей. Если удастся набрать целую команду таких, будет успешный «дизайн комитетом». А, и ещё: административно всё должно быть так устроено, чтобы поощрять примат интересов проекта над интересами участников, например, премии давать не за личные достижения (тупо количество тикетов), а за личный вклад в успех проекта, чтобы информацией (фидбеком) делились со всеми вовлечёнными лицами, чтобы команда могла иметь возможность избавляться от эгоистов, как бы часто они не жрали вотку с директором и т.п.
В любом случае есть 2 очень разных процесса, проектирование и сборка.
