Комментарии 44
Битва за архитектуру
Эта обязанность означает постоянную готовность к битве - возможно, в данном случае лучше использовать слово "борьба". Честно rоворя, подобная ситуация распространена практически повсеместно. Команда разработчиков должна бороться за то, что, по их мнению, лучше для компании, так же как команда управленцев, команда маркетинrа, команда продаж и команда эксплуатации. Это Bceгдa борьба. Эффективные команды разработчиков часто выходят победителями в этой борьбе. Они открыто и на равных вступают в конфликт со всеми другими заинтересованными сторонами. Помните: как разработчик проrраммноrо обеспечения вы тоже являетесь заинтересованной стороной. У вас есть свой интерес в проrраммном обеспечении, который вы должны защищать. Это часть вашей роли и ваших обязанностей. И одна из основных причин, почему вас наняли.
Важность этой задачи удваивается, если вы выступаете в роли архитектора проrpаммноrо обеспечения. Архитекторы, в силу своих профессиональных обязанностей, больше сосредоточены на структуре системы, чем на конкретных ее особенностях и функциях. Архитекторы создают архитектуру, помоrающую быстрее и проще создавать эти особенности и функции, изменять их и дополнять. Просто помните, что если поместить архитектуру на последнее место, разработка системы будет обходиться все дороже, и в конце концов внесение изменений в такую систему или в отдельные ее части станет практически невозможным. Если это случилось, значит, команда разработчиков сражалась недостаточно стойко за то, что они считали необходимым.
Мартин Роберт, автор принципов SOLID, из книги "Чистая архитектура. Искусство разработки программного обеспечения".
От себя - как то я не смог отстоять интересы платформы перед бескомпромиссными желаниями менеджера среднего разлива, из за чего в итоге сменил место работы по собственному желанию. Пока в нашем обществе гуманитарии доминируют над технарями, так и будет.
Автор не назвал себя архитектором. В этом есть смысл. Он явно выполнял часть этой роли, вот только из-за того, что он же являлся исполнителем, то передачи знаний и "чувства" архитектуры ни у кого другого так и не возникло. Я тоже этим страдал - проще сделать самому, чем объяснять другим. С опытом приходит осознание последствий. Иногда в виде такого вот поста.
В целом согласен с вами, но тут ещё более тяжёлая ситуация. Я больше года пытался передать эту экспертизу и знания тем лицам, у кого она должна была быть. Они мастерски уворачивались от вручения этих знаний и экспертизы. Оказывается вручить экспертизу — особый вид искусства.
В какой-то момент мне надоело рассказывать, какие будут последствия, потом пришлось их показать в живую.
Помните: как разработчик проrраммноrо обеспечения вы тоже являетесь заинтересованной стороной. У вас есть свой интерес в проrраммном обеспечении, который вы должны защищать. Это часть вашей роли и ваших обязанностей. И одна из основных причин, почему вас наняли.
Ничего подобного. Мы ведь тут живем не светлом будущем, а царстве бездушного чистогана. А потому наемный разработчик никакого своего интереса в программном обеспечении не имеет — оно ему не принадлежит. Его интерес — зарплату побольше получать, ну — и интенсивность своего труда снижать, чтобы его не заездили (валят на того, кто везет, да). Последнее делается куда проще совсем другими методами, нежели борьба за то, что лучше для компании: согласно Василию Ершову аналог этих методов в авиации называется «поставить обтекатель».
Ну, а у дяди Боба — свой собственный интерес, с интересами разработчиков никак не связанный: поднять бабло на своих книгах. А если в книгах писать такие демотивирующие наемных программистов вещи, вроде того, что я написал абзацем выше — бабло поднять не дадут.
Чтобы побольше получать зарплату, нужно побольше выдавать результат.
Во-первых это просто неверно: чтобы побольше получать зарплату, нужно, чтобы либо рынок труда двигался в сторону роста — потому что зарплата определяется рынком (т.е. возможностью уйти на большую зарплату), либо двигаться самому в сторону более высокооплачиваемого сегмента на рынке труда — например, перейти из сегмента дужнов в сегмент мидлов.
Во-вторых, что вы имеете в виду под словом «результат»? Если пользу для бизнеса — то она тут не при чем: оказанная услуга ничего не стоит. Результат нужно выдавать на том уровне, за который платит наниматель. И не надо явно пытаться стать лучше других — коллектив таких «стхановцев-гагаоовцев-заглаовцев» не любит, о вполне материальной причине: они своим активизмом ухудшую условия труда: повышают нормы выработки и т.п.
В-третьих, работа — это всегда страдание: именно его наниматели и компенсируют деньгами.
работа — это всегда страданиеБывает интересно. Круто же, когда пишешь код, большой и сложный, и он сразу работает (даже удивительно). Или через неделю этот код заглючит, и ты такой «хммм… интересно, а как так получилось, я же всё предусмотрел вроде».
А если тупо рутина, например, в отчёте шрифт поменять, то это не сложнее, чем зачистить данж в WoW. И что? Игроки WoW ходят в данжи каждый день и делают одно и то же. Они страдают?
PS Я писал не про работу исключительно ради денег. Если вы прочитали мой комментарий внимательно, то должны были увидеть, что я писал про баланс денег и условий труда.
А потому наемный разработчик никакого своего интереса в программном обеспечении не имеет — оно ему не принадлежит. Его интерес — зарплату побольше получать, ну — и интенсивность своего труда снижатьПрямое отрицание заинтересованности в качестве, только повышение отношения деньги/затраты.
Вы может и имели в виду что-то другое, но я честно этого не увидел.
Прямое отрицание заинтересованности в качестве, только повышение отношения деньги/затраты.
Вы все правильно поняли: в качестве продукта заинтересован только владелец продукта, то есть наниматель. Для этого он ставит перед работником требования по качеству, которые работник должен выполнять, чтобы его труд был признан трудом.
Тема злободневная, но подана с искажением действительности.
Почему всё ломается даже у хороших программистов?
Потому что они плохие программисты.
Как минимум, в описываемой ситуации программист (он же начальник отдела) был плохим.
Достаточно одного перла:
при нескольких десятках тысяч записей у пользователя просто браузер упадёт
Понятное дело, раз у него браузер после нескольких тысяч строк падает, то ни о какой эффективности он не думает. И объясняет всё исключительно внешними обстоятельствами, ну и разумеется, этим обосновывает своё нежелание что-то исправлять. Хотя уже по орфографии многое понятно:
с подцветкой изменений
Но не орфографией единой, конечно. Вот его слова:
Причём это всё происходило исключительно быстро, так как под каждый случай собирался свой оптимальный SQL-запрос
По его мнению, создание оптимального запроса есть исключительный случай. А в остальных (то есть в подавляющем большинстве случаев) пишутся, очевидно, сильно неоптимальные (читай - тормозящие) запросы. Это признак хорошего или плохого программиста?
Хотя, с другой стороны, вот его инструмент:
мой поток на python падает
Да, от питона ждать чудес не стоит. Так же как и от разработчиков, использующих это чудо.
И ещё:
Я понимаю, всю нелепость и неправильность ситуации, а ещё глубокую сомнительность данных технических решений
Да, понимание вроде бы есть, но каково решение? Писать на питоне и ваять костыли. Так может не только в понимании проблем внешнего окружения засада?
Ну и "честное" отношение к начальству:
Сhief-уровень компании сделал исключения для команд платформы.
Самодуром он тоже не был. Просто он сам был золотой шестерёнкой
Сначала шеф умный, а потом он во всём виноват. Или наоборот, как кому нравится. Но главное - программист не виноват.
А результат такой:
Они не справились
Все виноваты, все не справляются, поэтому наш программист уволился. Логично, чо.
Никто вам не даст счастья просто так. Вы можете сколько угодно обвинять окружающих, но ваши действия явно показывают - вы писали тормозной код и не хотели писать нормальный. Вы были начальником отдела и ленились выносить универсальный код в общий доступ. Вы отбирали людей на позиции программистов, а потом "они не справились". Так кто-ж вам теперь злобный буратина?
Главная беда всегда одна - те, кто сверху. А те, кто снизу - продукт жизнедеятельности тех, кто сверху. И автор был сверху.
Вы очень спешите с выводами, это вас подводит.
Во-первых, по вашему комментарию видно, что вы не прочитали первую часть статьи. То есть начали делать выводы не владея полным контекстом.
Во-вторых, почему браузер может упасть от того, что его попросили отрисовать табличку в десятки тысяч записей. Нет проблем вернуть с бэкенда на фронтенд сколько-то десятков тысяч записей. Это даже не так долго будет. Проблемы испытает сам браузер. Потому, что у него внутри используется DOM-дерево, то есть все html-элементы на странице входят в специальную иерархичную структуру, по которой ходят события и вычисляется видимость элементов, а потом ещё и рендеринг происходит. Если используется какой-то компонент таблицы, значит в одной строке будет находиться множество html-элементов, плюс связанные с этим события и код их обработки. В какой-то момент это все может стать непосильной ношей для браузера.
При этом мы помним, что мы не знаем мощность компьютера, на котором работает наш пользователь.
Конечно, есть подходы с виртуальным DOM, но в платформе, которую предложили это использовать ничего подобного не было.
Кроме того, виртуальный DOM тоже не всегда спасает. Бывают специфичные требования, которые не позволяют его применять. У нас как-то встала такая проблема, мы использовали Canvas. Если я правильно помню, ровно так же делает Гугл и Яндекс в своих таблицах. Именно из-за проблем с DOM.
В-третьих. Если мы бурем слово «подцветка», от слова «цвет», то дело не в орфографии. Подсветка происходит от слова «свет». В моем же случае, речь шла не о том, чтобы подсветить, а именно о том, чтобы подцветить. Немного разные вещи.
В-четвёртых. В компании была целая программа по повышению оптимальности запросов. В процессе её работы были разработаны специальные инструменты и программы обучения, результатом её стала работа раз в 100-1000 быстрее, со аналогичным снижением потребления оперативной и дисковой памяти. А это уже — многомиллионная экономия на мощностях ЦОД.
Для того сложного случая, реализовать сборщик SQL-запросов с оптимальными планами выполнения, это признак очень хорошего программиста. А вот использование ORM на таком классе задач — признаком плохого.
В-пятых. Немного не понял критику в адрес 32-битного Python, при условии того, что проблемы были в коде, который реализовали на С++. Наоборот, хорошо что оно падало, то есть проблема стала понятной. Лучше поток упадёт, чем нода ЦОДа.
Либо вы хотели сказать, что С++ это плохой язык? Я снова с вами не соглашусь. И на хорошем языке можно писать плохой код.
В-шестых. Вроде бы я писал, что мой код был быстрым, но эффективным. Но вот для того, чтобы владеть им, нужна была высокая квалификация.
В-седьмых. Не начальником отдела, а руководителем центра разработки, с количеством сотрудников, которое не каждого департамента информационных технологий бывает.
В-восьмых. Платформу разрабатывал не я и не мои ребята. Просто так лезть к ним и менять код, естественно было нельзя. И слава богу. Они и так не очень работали, а такая вакханалия вообще бы общую работу остановила бы.
В-девятых. Я же был руководителем одного из центров разработки. А их таких был где-то 10. Набирать сотрудников, естественно, я мог только в свой центр. Не справились ребята не из моего центра разработки.
С учётом вышесказанного, можно поставить под сомнение ваш тезис: «Главная беда всегда одна - те, кто сверху. А те, кто снизу - продукт жизнедеятельности тех, кто сверху». Было много людей снизу. Было ещё больше людей сбоку. Было какое-то количество людей сверху.
Конечно, можно сказать, что во всем виноват основатели и генеральный директор (это один и тот же человек). Вот только, если заглянуть внутрь других крупных компаний, там было как-то не лучше.
Поэтому, пока я не смогу такое лучше чем он, от оценок я буду воздерживаться. Просто рассказывать это одно, а показать работающее — совсем другое.
Вы очень спешите с выводами, это вас подводит.
Понимаю, нужно защищать "честь мундира". Но не истину.
Проблемы испытает сам браузер. Потому, что у него внутри используется DOM-дерево
Не нужно было вам защищать честь мундира. Потому что вы показали, как уверенность заменяет место истины. 100 000 записей в таблице на 5 столбцов в самом худшем случае (опера) съедают 1.6 гб. Хром - 180 мб, фокс - 200-400мб (приват или working set).
Если мы бурем слово «подцветка», от слова «цвет»
Мы берём как в орфографическом словаре. А вы исправляете проблемы задним числом и считаете, что так и надо.
В компании была целая программа по повышению оптимальности запросов
Но вы почему-то выделили лишь свою скромную роль в одном единственном случае.
Немного не понял критику в адрес 32-битного Python
Вы писали, что у вас питон падал, а не си.
мой код был быстрым, но эффективным. Но вот для того, чтобы владеть им, нужна была высокая квалификация
Вы писали - они не смогли. Это про тех, чью квалификацию оценивали лично вы.
Не начальником отдела, а руководителем центра разработки
Тем хуже для центра разработки.
Платформу разрабатывал не я и не мои ребята
Если у меня не пилит пила, то я её точу. Вы же решили, что точить должны другие. Результат - они не смогли.
Не справились ребята не из моего центра разработки.
В оригинале вы писали, что именно вам приходилось отбирать кандидатов. А задним числом мы все красавцы.
Вот только, если заглянуть внутрь других крупных компаний, там было как-то не лучше.
Я бы не стал сравнивать с худшими примерами. Но да, для защиты именно такое сравнение выглядит "подходящим".
Поэтому, пока я не смогу такое лучше чем он, от оценок я буду воздерживаться
Вы писали о проблемах в вашей области. Не о проблемах налаженного начальником бизнеса. Поэтому "лучше чем он" к делу совершенно не относится. Он работал совсем в другом направлении. А вам ничто не мешало зайти к нему в "переговорную комнату".
Конструктив - признавайтесь честно, что вы обычный менеджер. Не надо про разработку.
У нас здесь явно не проблема в «защите мундира», а в вашем избирательном чтении. А так же в тех надуманных аргументах, что вы приводите.
Например. Откуда вы взяли, что в таблице было всего 5 столбцов? И почему вы упустили, что речь шла о компонентах, которые в себя ещё включали много html-элементов?
Почему вы пытаетесь игнорировать тот факт, что русский язык относится к категории синтетических и имеет очень развитые механизмы словообразования? Для такого языка ссылка на то, что вы не смогли найти слово в орфографическом словаре, выглядит даже как-то нелепо…
Претензии типа: «...Но вы почему-то выделили лишь свою скромную роль в одном единственном случае...», показывают, что вы просто теряете контекст повествования. Так нельзя.
Потерю контекста подтверждает и это ваше заявление: «...Вы писали, что у вас питон падал, а не си...». Я же указывал, что код платформы на бэкенде написан на C++ и проблемы с неоптимальной работой с памятью были именно в коде платформы. Зачем вы что-то решили додумать?
Каким образом у вас из того, что я оценил квалификацию некоторых разработчиков по тому фактору, что они не смогли подхватить функционал (который в моей группе передавался без проблем), получилось вывести, что я оценивал их квалификацию при приёме на работу? Расскажите мне пожалуйста ход своих мыслей. Но проверьте их на логические ошибки, перед тем, как кому-то рассказывать.
Кстати. Часть этих людей «которые не смогли», работали не только в других центрах разработки, но ещё и были наняты до меня. Но, как я понимаю, по вашей логике я всё равно виноват? Потому, что виноват и точка?
У вас очень интересное заявление: «...Если у меня не пилит пила, то я её точу. Вы же решили, что точить должны другие. Результат - они не смогли...». Например, попытка другой команды что-то закоммитить в мои модули жёстко пресекались. Вплоть до удаления без предупреждения. Закоммитить что-то в код платформы, без предупреждения, без согласования — это диверсия.
Причём даже не та диверсия, после которой следует неминуемое наказание. После этого вообще адекватность и психическое здоровье человека нужно проверять.
Вот здесь: «...В оригинале вы писали, что именно вам приходилось отбирать кандидатов. А задним числом мы все красавцы...», вы опять теряете контекст повествования. Как у вас найм сотрудников в одном филиале смешался с наймом сотрудников для всей компании-то? Каким образом?
Вот здесь: «...Я бы не стал сравнивать с худшими примерами. Но да, для защиты именно такое сравнение выглядит "подходящим"...» вы как-то странно додумали. А кто сказал, что «другие компании» это худшие примеры? На самом деле, я даже не обозначал эти «другие компании». Но вы сразу додумали, что они худшие. Прекрасно же?
Иногда вы просто занимаетесь какими-то голословными обвинениями. Например, здесь: «...Вы писали о проблемах в вашей области. Не о проблемах налаженного начальником бизнеса… Он работал совсем в другом направлении. ...». Чтобы о таком говорить, нужно хотя бы иметь понятия, а в чём бизнес-то заключался, и какое место там занимала непосредственно разработка. И почему генеральный директор был вынужден участвовать в разборе архитектурных проблем. Да и почему он вообще МОГ принимать такое участие тоже.
Затем уже идут фантазии чистой воды: «... А вам ничто не мешало зайти к нему в "переговорную комнату"...». А это вы с чего взяли? Либо в мире волшебных эльфов в кабинет основателя и генерального директора компании с миллиардными оборотами можно входить с ноги? Либо он сидит да только ждёт, когда же вы ему встречу назначите?
Теперь смотрите. Вы постоянно теряете контекст повествования. Это очень плохой симптом. Вы постоянно пробуете что-то додумать. Это некорректный приём демагогии. Иногда у вас в рассуждениях появляются логические ошибки. Специально либо не специально вы их допускаете — неизвестно.
Если мы говорим про «конструктив», то вам следует оперировать полным контекстом, не додумывать того, чего вы не знаете, даже если очень хочется, не допускать грубых ошибок в логике рассуждений. Тогда вы перестанете приходить с очевидно неверным выводам.
Вижу результат отрицательного отбора. Самореклама в виде статьи и упёртая защита рекламируемого. Например так: вы не понимаете, здесь совсем другой контекст!
Контекст задан в статье, всё остальное - привычка выглядеть (но не быть) подходящим кандидатом.
Ну а по техническим знаниям я вижу полное непнимание проблемы: а если в таблице будет не 5 столбцов? Ну да, если будет 6, то автор снова сядет в лужу. И если 16 - тоже сядет. И даже если 160 - гарантированно сядет. Но "вы не понимаете, это другой контекст (с)" всегда наготове.
Почему вы позволили себе проигнорировать заданные вам вопросы? Если вам нечем на них ответить, можно просто извиниться за свою ошибку.
Конечно, контекст задан статьёй. Просто вы этот контекст игнорируете и начинаете придумывать что-то своё вместо этого контекста.
Касательно таблицы. Вот вы сами пишите, что у вас для таблицы на 100 000 записей и 5 столбцов опера потребляет 1.6 гб. Можно предположить, что если мы возьмём не 5 столбцов, а 16, то есть в 16/5 = 3.2 увеличим объем данных, то у нас и потребление памяти вырастит пропорционально (для простоты) вырастет. Имеем верхнюю оценку в 1.6*3.2 = 5,12 гб. Понятное дело, что скорее всего будет несколько меньше, вот только пользователю у которого всего 5 гб оперативной памяти, большая часть которой уйдёт на обслуживание ОС, легче от этого не станет.
С учётом того, что Опера использует WebKit, как и Chromium и Google Chrome, вызывает интерес, как вы делали замеры. У вас потребление памяти у Оперы и Хрома почти на порядок отличаются. Ведь по вашим словам Опера потребляет 1.6 гб, а Хром всего 180 мб.
Но это все не суть, потому, что вы проигнорировали тот факт, что ячейка таблицы — это компонент, который в свою очередь состоит из html-элементов, которые и идут в DOM-дерево. То есть ваши замеры нужно умножать ещё в 10-15 раз. И это только таблица без всего прочего окружения.
Либо вы забыли уже и то, что писали сами?
Согласен. Сам был на месте автора. Точно так же ругал начальство (CEO) и программистов, которых сам же и нанимал.
Но я не ушел, поэтому теперь понимаю свои ошибки. Нет смысла ругать CEO, нужно либо отстаивать свое мнение, либо делать так, чтобы работало годами, не ломаясь. Нет смысла ругать программистов, не умеющих разобраться в гениальном коде - лучше самому этот код не писать, а учить команду, как решить проблему. Ну и самое главное, заставлять доделывать задачи, не допускать костылей в новом коде, даже если чуть больше времени занимает. Моя частая ошибка была, я разрешал закрывать задачи в виде "ну тут сделано криво, но у нас горят сроки, потом доделаем". Практика показала, потом наступает года через 3, и все это время приходилось бороться с костылями.
По статье, автор описывает, что такие ситуации бывают, и что люди склонны хвалить себя и ругать других, когда такое происходит. Но, возможно, у автора не произошел рост как управленца, т.к. он уволился, вместо разгребания всего, что он наделал. К сожалению, очень сложно научиться правильно поступать в таких ситуациях.
Здесь только добавить, что автор не ругал CEO и программистов, которых нанимал сам. Программистов в других филиалах нанимал не я, отвечать за них не мне. Ну и их, я тоже не ругал. Команды разработки платформы (центральный офис, кстати) — да, а вот обычных разработчиков — нет.
Чего ещё добавить. Посыл про «разгребание» тоже не верный. Доработка моего функционала силами моей же команды никаких проблем не вызывала. Это происходило быстро и с заметно более низким количеством ошибок, чем у ребят из соседних филиалов. Проблемы были не у нас, а у тех, кто попробовал это подхватить. Именно они не справились с интенсивностью и нагрузками. Наверное, это они не состоялись, как управленцы?
Кроме того, я же не зря написал, что кроме непосредственно написания кода, и непосредственно руководства одной из команд разработки, я ещё целым филиалом разработки управлял, где моя команда существовала далеко не в единственном числе. Нас много там таких было. Думаю, меня, как управленца характеризует вот этот фрагмент: «...На самом деле, компания теряла только сильного разработчика и, возможно, его команду. В филиале оставалась очень сильная и слаженная команда руководителей. Потом, после того, как решатся проблемы с площадями, эта команда руководителей в неизменном составе отмасштабирует филиал разработки раз в 5. Этим достижением я горжусь…».
Ушёл я потому, что нащупал свой потолок профессионального роста в компании. Дальше только входить в «семью», а для этого желательно обитать в центральном офисе. Плюс политические расклады не позволили маневрировать даже CEO, который ещё и основным владельцем компании был.
Поэтому, я пошёл расти дальше и в другие места. Для бывшего работодателя тоже катастрофы не произошло. На их объемах это был всего лишь маленький укольчик и мелкая неприятность. Там такого и без меня могло периодически происходить.
При моём уходе основная тема переговоров была, чтобы я не трогал команду руководителей, которые все со мной очень хорошо дружили. Деловая этика быстро позволила нам договориться.
Вот только не всегда и не все золотые шестерёнки настолько лояльны к бывшим работодателям. Об этом нельзя забывать.
Автор, почему вы не писали объектно ориентированный код? Выглядит подозрительно...
Возможно, я просто не смог верно передать "масштабы бедствия". Система была очень и очень большая. То, что я описывал, по своей сути происходило на несколько архитектурных слоёв выше, чем тот уровень, где может существовать ООП.
Нет, конечно, ООП мы активно использовали, куда без него. Просто над ним было еще множество иных слоёв абстракции. Например, "Модуль" - это фактически отдельный продукт, который можно было подключить по лицензии в облаке. И объектов в этом модуле было достаточно много. В других модулях - тоже.
Я тоже ушел со своего первого проекта где я поддерживал автоматизацию для 5 разделов системы и 40-а человек команды. 5 разделов это пять совершенно разных контекстов приложения, где нужно соответственно понимать бизнес-логику, а для этого общаться со всеми командами. В общей сложности около 350 тестовых сценариев помноженых на 8 основных вариантов продукта выполялось каждый день . Сборка и выполнение тестирования проводились у другого подрядчика. Команды только код сдавали. Кастомный скриптовый инструмент тестирования, со своими "прибамбасами". Особенности интеграции тоже свои. Чтобы понять куда и когда сдавать, дабы твой код попал в нужный вариант продукта иногда даже опытным разработчикам приходилось чесать тыковку. Ну и стандартный набор задач: отчетность, планирование, наращивание покрытия. Порой автоматизация тестирования превращалась в "драматизацию тестирования". Это я таким каламбуром называю синдром, когда заказчику периодически резко стукает жидкость в голову, что нужно лучше, больше, быстрее автоматизировать, и вообще-то еще вчера. Вот зарисовка из жизни:
Приходит ко мне руководитель и спрашивает:
- Заказчик мол хочет знать сколько нужно времени, чтобы все состояния покрыть тестами.
- Ну это смотря сколько багов будет в системе, у нас постоянно идет разработка, всплывают новые баги, на их документацию и трекинг уходит наибольшая часть времени.
- Ну предположим система будет готова и не будет больше меняться.
- Если система не будет меняться то и автоматизация не нужна.
- ...
Вопрос был закрыт.
А проработал я на нем не много ни мало почти 7 лет. Просто в какой-то момент понял, что с моим опытом могу продолжать жонглировать своими задачами с закрытыми глазами и дальше. И это лестно быть единственным экспертом в узкой области. Но это не то, как это должно быть организовано. Не может автоматизация держаться на одном человеке. Да это выгодно работодателю. Но совершенно неправильно. Никто больше не знает как это все поддерживать, никто не знает как это работает, и чем вообще я занимаюсь. И соответственно, это карьерный тупик. Зарплату добавлять не станут, твои задачи ведь не меняются. И вобщем я понял что я обязан уйти, чтобы проект начал относиться к автоматизации правильно. Передал знания командам и ушел. Ушел, так сказать, во благо проекту и себе. Расставание в стиле: "Нам от этого обоим будет лучше".
P.S.:
Люблю вспоминать цитату Джима из нетленной философской мульт-эпопеи о Губке Бобе:
"Парень неплохой повар, но великолепным поваром он станет лишь тогда, когда наберется мужества, чтобы уволиться из этой дыры."
- вторая серия, пятый сезон (текстовая транскрипция оригинала)
Задача хорошего архитектора - предотвращение появлений "золотых" кого-либо. Необходимо работать с командой ежедневно. Специалисты-шестеренки (такой позитивный и эффективный "центр тяжести") мне попадались редко. Такие люди пишут фреймворки и инструментарий, которыми начинает пользоваться вся компания, без понимания почему и как это работает. Если их выделить в отдельный юнит инфраструктуры, то получается очень не плохо. Однако в большинстве случаев мне попадались бульдозеры. Которые любят вставить узкозаточенный SQL-запрос/регулярку или refelctions/unsafe код, потому что им "поставили" такую задачу. Вместо решения, которое должно устранить причину проблемы, просто ставили золотой костыль. Мне кажется это всегда смесь не желания решать чужие проблемы (других команд, модулей и тд), желание избежать конфликта и, конечно, вариант гордыни (а смогу ли я это решить? вот это крутое - решение я сотворил! ). Как тут не вспомнить Виктора Франкенштейна.
Вот таких Викторов менеджмент обожает. Ведь им не пришлось объяснять генеральному, что тот не прав. И сроки были намного ниже тех, что обозначил архитектор. Именно управленцы получают золото, а не те, кто создает чудовищ.
Например, команда создаёт самолёт. Год, второй. Пришло время сдавать проект. И оказывается, что вход нужен не как обычно, сбоку, а снизу. Умника, который скажет, что надо всё начать с нуля, а бюджет проекта за 2 года слить в унитаз, никто слушать не будет. Будут слушать «золотую шестерёнку», которая предложит уникальный механизм поворота сегмента корпуса на 90 градусов перед выходом пассажиров.
Жизнь несколько сложнее, на самом деле. В моём случае объяснять генеральному, что он не прав, это было не что-то страшное и ужасное. Человек компетентный, по утрам он ещё не терял адекватность под нагрузкой, и с ним можно было конструктивно подискутировать. Спокойно признавал свою неправоту, когда для него открывались новые обстоятельства. Собственно, как и я. У нас были с ним очень разные наборы данных, синхронизация их помогала найти решения для иных вопросов.
Но генеральный директор — это не сверхчеловек, он точно так же, как и все остальные, действует в системе своих ограничений. Там наверху свои проблемы, и я ещё не видел человека, который с ними справлялся бы идеально. Но видел немало людей, которые знали, как идеально, и их наверху размазывало под нагрузкой.
К слову, мне как-то несколько раз в грубой форме высказывать своё негативное мнение об совладельцах-миноритариях компании, причём им лично. Что мне за это было? Меня не уволили, меня не оштрафовали, меня просто посчитали грубым и неуравновешенным человеком. Поэтому с тезисом о «быстро уволят» я не могу согласиться.
P. S.
Описанная вами проблема с самолётами уже решалась. У части самолётов выход производится через шасси. У Су-34 так, если я правильно помню. В поворотных механизмах для сегментов корпуса нужды нет. Сейчас даже поворотные механизмы для крыльев самолёта теряют свою актуальность.
Если брать SQL, то это было общее требование по компании. На самом деле, мы ещё согласовывали новые таблицы, поля и индексы. Когда у тебя облако, а в нем многие тысячи схем клиентов, факт того, что, например, под индексы и таблицы тот же PostgreSQL создаёт отдельные файлы, начинает очень больно кусаться. Как и неоптимальные запросы, которые исполняются миллионы раз.
У компании был собственный ЦОД, достаточно мощный. Постоянно расширять его мощности и тратить на это миллиарды рублей, было нецелесообразно. Поэтому началась системная работа над оптимизацией запросов.
Говоря честно, основная сложность моего модуля была именно в интеграциях и контроле за потоками данных. У меня были хорошие компетенции в PostgreSQL, но у пары команд внутри моего филиала компетенции в PostgreSQL были значимо выше. Кроме того, в компании был техлид по PostgreSQL, я вряд ли чем его мог бы удивить (в базах данных, конечно).
Представление о том, что золотые шестерёнки будут избегать конфликтов — ложное. Чаще всего, им на них все равно, если надо, то будут конфликтовать, если не надо, то не будут. В отдельный юнит вы их упаковать не сможете. Не забывайте, что они не только хорошие программисты, но ещё знают как руководить людьми, могут решать архитектурные проблемы и играть в политику.
Даже если вы найдёте нужное количество золотых шестерёнок, даже если среди них будет человек, которого они будут уважать и слушать, то вы их все равно в отдельном юните не удержите. Вы, скорее, дворцовый переворот получите, когда эта команда пойдёт просить отдать им рычаги управления.
Худший опыт такого плана - гос.проекты, отделы внутренних разработок и пробная нишевая продуктовая система в непрофильном для компании направлении. Так как клиенты не очень чётко определены (фактически их нет и их роль кто то отыгрывает) и участники не рискуют своими деньгами, то от реальности оторваны все отделы. На разработчиков льются потоки бреда. И если находиться вдруг кто-то, кто начинает эти выполнять запросы про 7 красных линий, то остальные часто отключают всякое критическое мышление и тоже начинают ваять. Ведь начальство всегда будет говорить, что "а вот Вася сказал, что можно" и "ведь Вася сделал". Так что тот ад, который порождает общий сон разума - просто за гранью.
Как всегда, времени на то, чтобы сразу сделать хорошо, всегда не хватает, но вот в разы больше времени на переделку всегда находится.
И даже если изначально архитектура была выбрана правильная, новый функционал постоянно пытается ее ухудшить. Потому что бизнес требует - нет времени объяснять - надо делать. И, самое обидное, когда ускоренная разработка успела ухудшить архитектуру, но в итоге запланированные фичи оказались не нужны, или не настолько нужны, как казалось в начале.
Жаль что принцип "на рабочих компьюторах не должно быть ничего лишнего" хорошо работат только у администраторов сети.
Некоторые вещи нужно прожить, чтобы принять. Есть куча внешних ограничений и в моменте очень тяжело понять, какое решение правильное. Будучи разработчиком, я не понимал откуда столько ахинеи в коде, а главное в заданиях. Став тех. архитектором, я осознал, что плохое решение, почти всегда, является результатом ограничений. Дедлайны, умения и, конечно, узкий фокус на своей части работы. И только став главным архитектором, начав работать с топ менеджментом своей и клиентских компаний, я понял откуда эти ограничения возникают и как культивируются.
Интересно все описано, особенно в начале, только мне кажется смешаны в кучу разные понятия, люди, кони. Поэтому мысль в итоге как бы потерялась в неоконченных спорах с бывшим гендиректором.
Как мне кажется, есть действительно способные специалисты, рок-звезды, как хотите. Они понимают в аналитике, в архитектуре, опытные разработчики, с навыками управления командами и тп. Им повезло в жизни со многим столкнуться, многому научится. И они такие как есть - могут многое. Не идеальные дивиргенты конечно, но..
Также есть проекты - мертворожденные, недоношенные, здоровые, но не достигшие половой зрелости, и потому бесплодные - не оставляют после себя ничего. Есть и удачные, давшие потомство - идеи и подходы для многих других. И у всех есть свои муки роста и проблемы, и не обязательно это связано с тем кто их делает.
А шестеренки или винтики это как раз роли людей кто делает эти проекты. Ржавые, стальные, золотые шестеренки. Золотые шестеренки - это узкие места в бизнес-процессах, в подходе к работе. Управленческий долг.
От долга желательно не зависеть, вовремя гасить проценты, кто бы спорил, но он бывает необходим в какие-то моменты, поэтому это такая жизненная вечная тема для обсуждений, для тех кто забыл это сделать в очередной раз. Не от людей надо избавляться, которые могут выстроить процесс, сделать платформу для всей системы. Те же незаменимые сотрудники вполне могли бы спокойно работать в системе где нормально поделены сферы ответственности, адекватное управление, и нет повода для геройства. Они могли бы входить в состав руководства, обладая огромной компетенцией в ключевой сфере компании, и участвуя в стратегических обсуждениях могли бы приносить гораздо больше пользы. Но почему это чаще не так, почему на них проще смотреть как на шестеренки, это тема для отдельной статьи
Понятно, что проблемы есть всегда и технический долг в иные моменты оправдан и неизбежен. Суть проблемы в другом.
То, что названо «золотой шестерёнкой» не может постоянно существовать в установившейся системе обычного вида. Она будет постепенно всплывать на уровень высшего руководства, после достижения которого начнутся уже политические проблемы.
Во-первых, этой золотой шестерёнке уже кому-то придётся уступить место. А этот кто-то может начать сопротивляться всей своей политической и административной властью. Во-вторых, золотая шестерёнка потянет наверх и свою команду. То есть будет осуществляться транзит власти от одной управляющей команды к другой. Это тоже может вызывать сильное сопротивление.
Попытка выделить новую команду в новое же начинание может вызывать политические проблемы уже во всей структуре организации. Банальный вопрос, почему им можно, а мне нельзя. Кроме того, будет обоснованный страх. Ведь если новые подходы сработают, то тех, кто уже приспособился к старой системе заставят работать. Это будет выброс из зоны комфорта.
Для стабильной и установившейся системы это может выглядеть, как неприемлемая цена. Для зонтичной структуры в момент её разворота, при должной смелости руководства (которое на самом деле просто собирается сделать левел-ап и пойти дальше), это может стать приемлемым вариантом.
Нет организация, которые подходят всем подряд. И нет людей, которые подходят к любому типу организации. Беря в руки золотую шестерёнку, нужно понимать, что это мощный и опасный инструмент, таким нужно пользоваться осознанно.
Мне кажется Вы как-то проигнорировали основную мысль что шестеренки это не люди и не предметы, которые можно брать в руки. Попробуйте не наваливать на РП еще один проект, если он как-то тянет уже два-три. Не просите например руководителя разработки позаниматься подбором кадров и обучением, бюджетным планированием, поисполнять обязанности пресейла для гендиректора на важной презентации, поучаствовать в разборе инцидентов в продакшене, и у вас не будет никаких золотых шестеренок. За это удовольствие придется правда заплатить сразу, наняв в штат и обучив необходимое число людей. Поэтому есть соблазн сэкономить, и обойтись одной шестеренкой, ведь тогда платить придется может быть потом, а это когда еще будет. Это и есть управленческий долг. Вы его хотели? Извольте в конце расплатиться. Признайте заслуги, наймите заместителей, помогите подхватить обязанности, компенсируйте личные затраты какие были, за счет повышения или другими способами. Исправьте узкое место в вашем процессе. Сделайте это вовремя. И шестеренка никуда не отлетит. Шестеренки же отлетают не куда-то в космос, а как правило недалеко, где просто соблюдается баланс затрат-и-вознаграждений, и необязательно стремятся стать снова золотой шестеренкой. Такое место можно создать и у себя, если подумать, так же?
Вы хорошо написали, с вами даже хочется согласиться. Вот только эта сказочная система никогда не заработает. По той же причине, почему коммунизм и социализм не состоялись, - природа человека. Не руководителей, исполнителей, как не странно.
Например, я знаю, что если у моего бывшего работодателя уменьшить штат ИТ-шников раза в 4 и снизить им зарплаты раза в два, то производительность компании даже не снизится. Дело не в том, что людей не хватает.
Дело в том, что эти все люди большую часть сил тратят на противодействия друг другу. А делают они это прежде всего из-за того, что у них с компанией нет общей цели, но есть желание взять побольше, а отдать поменьше. То есть как раз нарушить баланс интересов и ценности в свою пользу. Как результат, они сами же превращают свою же жизнь в ад. Страдают и терпят за деньги, более жёстко выражаться не буду.
С точки зрения бизнеса ситуация ещё проще. Бизнес работает с тем, что есть. У него нет задачи сделать хорошо и правильно, у него есть задача сделать лучше, чем конкуренты. А у конкурентов ещё больший адища, не смотря, что они пытаются поступать так, как вы написали. Чем больше ресурсов вольёшь в систему, тем хуже в ней станет людям. Чувство меры же есть не у всех людей.
Конечно, можно говорить о командах мотивированных профессионалов-созидателей, но в реальной жизни такие команды существуют очень редко. И это не очень устойчивые конструкции из-за своего размера. Так как люди не мешают друг другу и не обманывают друг друга, то их и нужно очень немного. Из-за малочисленности потеря члена группы очень болезненна. А люди могут менять работу по куче разных причин, от переезда в другую страну, до просто ситуации, когда человеку надоело работать и он поехал медитировать в Гималаи лет на 10.
Золотую шестерёнку опасной делает умение управлять локальным пространством вокруг себя, заряжать людей общей целью и вести за собой, при этом ещё на ходу прикидывая оптимальный путь. В результате какой-то кусочек компании внезапно для всех начинает работать с чудовищной эффективностью, ломая сопротивление людей вокруг. Именно ломая, насильно, через кровь и боль, лишая их возможности поработать поменьше да взять побольше.
Потом золотой шестерёнке становится тесно в рамках компании, ей хочется большей самореализации, для которой есть и потенциал, и способности. Приходится решать, что с этим делать. Зачастую, такого человека просто отпускают на волю. Как не странно, это ещё позволяет сохранить хорошие отношения при расставании.
Да Вы тоже все правильно пишете про денежно-рыночные отношения, бизнес и несправедливость мира, но только вывод делаете что опасность представляют не те условные ленивые и заносчивые, кто палец о палец без премии не ударит, но которых много и которых можно заменить на таких же как они с легкостью, а те люди икс, которые может выстроили ваш бизнес или вытянули его когда он был на мели, потому что они не всегда будут и дальше впредь его тянуть.
Конечно. Вот поставьте себя на место генерального директора, на которого абсолютное большинство в компании смотрит потребительски, прямо как на еду. Он для них и средство извлечения дохода (без него компания не будет такой успешной), и способ снять с себя какую-либо ответственность. А то что он иногда ругается и грозит уволить, так это мелочи, можно и потерпеть. Благо, что почти не увольняет.
И тут в такой среде внезапно появляется золотая шестерёнка, которая смотрит на вас, как на человека, понимает ваш бизнес и помочь вам пытается. Со временем этот человек растёт и ему становится тесно в вашей организации. Конечно, вы отпустите такого человека на волю, а не сделаете его пищей для среды, которая и вас-то пытается съесть.
А если этот человек ещё и вырастет во что-то сопоставимое с вами, так с ним вообще можно просто дружить начать.
Прекрасно понимаю, о чем Вы, но не понимаю в чем опасность то от таких людей. Порадуйтесь тому что имели честь поработать с понимаюшим и неравнодушным наверняка человеком. Поставьте его в пример сотрудникам, глядишь из остальных может один другой вдохновятся его энергией и способностями. Не для всех же предел мечтаний быть сисадмином на шоколадной фабрике.
Опасным может быть собственное завышенное ожидание, если таковое имело место быть, что он есть решение всех проблем. И если условно кто-то достиг понимания, что даже надежное оборудование в проме должно иметь резерв, то ему остался один шаг до понимания что и ключевые компетенции в компании должны быть задублированы, чтобы обеспечить непрерывность процессов. Были случаи правда когда и дублирование не спасало, и компетенции приходилось восстанавливать с нуля. Но это тоже не обязательно смертельно, хоть и больно.
То, что названо «золотой шестерёнкой» не может постоянно существовать в установившейся системе обычного вида. Она будет постепенно всплывать на уровень высшего руководства, после достижения которого начнутся уже политические проблемы.Все верно, так как эта «золотая шестерёнка» хочет что-то улучшить, а все окружающие (в том числе и ваш гендир) нет. Опасно ли это для окружающих? Не знаю, слишком философский вопрос.
Интересно, как с вашей точки зрения должен был бы бороться с таким положением вещей генеральный?
Т.е. получается, проблемы от того, что непонятны ответы на следующие вопросы. Это команда такая медленная (в описанном эпосе - платформы) или они реально чем-то сложным занимаются? Тот менеджер среднего звена приносит пользу или вред? Если у этой команды регулярно и с громким стуком падает система - это из-за криворукости, или просто у других команд системы не важные.
Почему всё ломается даже у хороших программистов? Часть 2/2