После несерьёзной статьи на серьёзную тему Job Safety Driven Development стоит рассказать о том, почему даже опытные и добросовестные программисты волей случая могут попадать в схожие ситуации. Сначала захотелось написать, почему программисты ошибаются вообще, но оказалось, что это слишком разные темы. Потом оказалось, что и на эту тему получился очень длинный текст. Пришлось разбить его на части. В первой части мы рассмотрим обычные случаи, которые знакомы многим крупным компаниям. И дополним понятие «серебряная пуля» понятием «золотая шестерёнка». Во второй части поймём, какую цену вам, скорее всего, придётся заплатить за «золотую шестерёнку», я приведу немного своего опыта. Как всегда, попробую писать простым языком, понятным широкой аудитории.
Меня зовут Константин Митин, я сооснователь и руководитель компании АйТи Мегастар/АйТи Мегагруп. Когда-то был простым разработчиком, работал в L3, дорос до тимлида, затем и до руководителя филиала разработки крупной ИТ-компании. Теперь я в АйТи Мегагруп.
Если вы ещё не прочитали первую часть статьи, то прочитайте её, пожалуйста. Золотые шестерёнки это не какие-то плохие либо злонамеренные люди. Это комбинация факторов из внутреннего устройства крупной организации и личных качеств человека.
Золотые шестерёнки, цена
Всё хорошо в меру, иногда что-то слишком хорошее становится уже плохим. Сахар и соль делают нашу еду вкуснее, но их переизбыток иногда просто не позволяет есть. Золотые шестерёнки представляют собой эффективный, но опасный инструмент. Они не только могут писать классный и сложный код, они ещё могут решать сложные задачи, в том числе и бизнес-задачи. Но их всегда нужно стабилизировать сильной командой и иметь аварийный механизм сброса. Золотая шестерёнка обязательно вылетит и разнесёт всё на своём пути, весь вопрос, куда она полетит.
Обычно всё начинается хорошо. В вашей компании появляется разработчик, который понимает бизнес чуть ли не с полуслова, быстро и эффективно решает задачи. Скорее всего, он привлечёт в вашу компанию сильных людей и сформирует вокруг себя профессиональную команду.
Но есть два негативных момента. Первый — этим начинает пользоваться средний менеджмент. Что такое средний менеджмент — это управляющая административная прослойка между бизнесом и исполнителями. Представители бизнеса не теряют свою адекватность, благодаря обратной связи от окружающей среды. Они свои ошибки быстро ощутят по финансовому потоку. Исполнители, которые работают в поле, тоже имеют непосредственную обратную связь с окружающим миром. Для разработчика это пользователи, внедренцы, техническая поддержка. Средний менеджмент не имеет ни того, ни другого. Они просто пишут отчёты и выполняют свой KPI либо его аналог.
Когда среднему менеджменту в руки попадает золотая шестерёнка, они начинают радоваться. Ведь с помощью этого человека можно выполнять свой KPI и все ошибки тоже можно на него валить. Иногда доходит до культа личности, в такие моменты начинается «это было его решение» и «если даже он не справился». Способ снять с себя ответственность и отвести от себя удар. На такого человека начинают отгружать всё больше и больше сложных задач, всё больше и больше ответственности за принимаемые решения.
Когда среднему менеджменту в руки попадает золотая шестерёнка, они начинают радоваться.
Второй момент — очень коварный. Золотая шестерёнка не ломается под нагрузкой, ломаться начинают люди вокруг и структура организации. Крепостное право отменили, люди устают и просто уходят. Иногда в команде золотой шестерёнки можно услышать: «Если ты уйдёшь, то я тоже уйду, я не согласен заниматься тем, что делаешь ты сейчас». Начинает снижаться взаимозаменяемость.
Комбинация этих двух факторов и даёт печальное явление «вылета золотой шестерёнки». Уход золотой шестерёнки равнозначен уходу её команды. Она уходит либо до того как, либо вместе с золотой шестерёнкой, так как оставаться без своего предводителя в сотворённом средним менеджментом аду они не соглашаются. За собой они оставляют важный и работающий функционал, код которого компактный и эффективный. Но именно потом про этот код скажут, как про «написанный непостижимым божественным разумом, который нельзя менять простым смертным» либо «написанный чужими для хищников» или «гуманоидной логикой». В общем, весёлых эпитетов от людей, которые принимают такое тяжёлое наследство, услышать можно очень много. Даже если в коде достаточно комментариев и есть документация.
Иногда проще сказать: «Мы не можем», распилить эту сингулярность на несколько разных команд, после чего реализовать раз в дцать больше кода, который будет делать то же самое, медленнее и хуже, но его смогут развивать рядовые программисты.
С механикой процесса я знаком на собственном опыте, потому что сам был на месте золотой шестерёнки. Чтобы не задевать ничьих интересов, на свой опыт и обопрусь.
Личный опыт
Мне довелось работать в одной крупной компании, реализующей облачный сервис в виде web-приложения. Когда я начинал там работать, в компании уже было больше тысячи программистов, сейчас их больше нескольких тысяч. Объём функционала — действительно большой. В компании был выделен отдел по разработке платформы для бэкенда и отдел по разработке платформы фронтенда.
Платформа фронтенда любила внезапно всё менять без сохранения обратной совместимости. В целом, соседние модули тоже этим грешили. Как результат, каждый релиз на продуктив выливался для всей компании в авральный багфикс. Примерно раз в один-два года платформа пробовала переписать всё заново, чтобы стало всё классно и хорошо. Конечно, классно и хорошо не становилось.
Если вас интересует, чем реально может заниматься орда программистов в несколько тысяч человек, у меня есть для вас ответ — пытаются костылями закрыть ошибку, которую допустил другой программист и система на это забила.
И если говорить честно, то увиденное у моего бывшего работодателя не является чем-то уникальным. После этого мне довелось посмотреть на то, что творится внутри других крупных компаний. Там всё хуже. Совсем наглядно стало, когда бывший сотрудник из моего филиала разработки (их у компании было больше 10), который пришел к нам стажёром и вырос до ведущего разработчика, ушёл в одну очень и очень большую ИТ-компанию. Пока он работал на старом месте, он страдал от бардака вокруг и ругал платформу. На новом месте он занялся местной платформой. И повторил все «ошибки» той платформы, что ругал.
В самом начале моей работы ко мне пришёл менеджер, чтобы я по справочнику моего модуля, в котором могло находиться несколько сотен тысяч позиций, сделал поиск, результат которого нужно было отдать пользователю весь и сразу. У меня не вышло с первого раза объяснить человеку, что такое делать нельзя, потому что при нескольких десятках тысяч записей у пользователя просто браузер упадёт. Я ему даже показал, как падает браузер у соседней команды, которые дескать уже сделали такой функционал (там справочник был всего на несколько тысяч позиций). Это эффекта не возымело.
Менеджеру было всё равно, ему нужно было бездумно выполнить задачу, чтобы не получить нагоняй от генерального директора. В общем, я его в грубой и экспрессивной манере отослал от себя подальше. Что было в результате? После нескольких итераций обсуждений, когда люди наконец поняли, что так нельзя и что такого наша платформа не может ни на бэкенде, ни на фронте, но генеральному директору очень хочется, пришлось мне сесть и написать мегакостыль. То есть сесть и написать нетривиальный SQL-запрос (формат выдачи с неожиданной группировкой) с оптимальным планом выполнения (требование компании, за этим яростно следили, и на это были объективные причины), а потом банально подломить платформу на фронтенде (JS же, мы и не такое проворачивали), чтобы она наконец хоть что-то смогла. Ну и несколько сотен строк прикладного кода, куда без него. Костыль имел длинное имя собственное из множества слов, среди которых было всего два цензурных: «волшебный» и «единорог».
Менеджеру было всё равно, ему нужно было бездумно выполнить задачу, чтобы не получить нагоняй от генерального директора.
Платформа обещала в скором времени отдать функционал, который позволит всё это убрать. Вот только я не помню, когда он появился, когда они смогли. Через два года? Через три? Где-то в ожидании этого момента я несколько раз грустно смеялся, когда падала платформа на фронтенде, а костыль продолжал прекрасно работать.
Кстати. Про правильное наименование костылей. Как-то мне пришлось реализовать на фронте функционал сравнения двух строк на базе расстояний Левенштейна с выводом строки исходника и итоговой строки в тултипе с "подцветкой" изменений. Опять всем было очень надо, платформа не могла, да и не выглядело это опасным костылём.
Написал я прикладную функцию, куда-то её положил (не стал делать её библиотечной, костыль же) и спокойно её использовал. Как-то мы провели рефакторинг, в ходе которого переработали эту функцию и переместили её в другое место. У нескольких команд из соседних филиалов рухнул их функционал. На вопрос, зачем они такое сделали, ведь мы её как API никому не обещали, внятного ответа дать они не смогли. На моей памяти библиотечной функции в платформе так и не появилось. Зато появилась куча копий этого функционала по разным модулям. Люди сделали выводы и подстраховались.
На самом деле это был всего лишь маленький эпизод длинного пути, в результате которого родился волшебный метод API, который в одиночку осуществлял многопараметрический поиск по всему моему модулю и где-то пяти (либо десяти?) соседним модулям с богатым набором форматов выдачи данных и нетривиальных группировок. Причём это всё происходило исключительно быстро, так как под каждый случай собирался свой оптимальный SQL-запрос. Всё это счастье объяснялось «требованиями генерального директора». Код за авторством моего ведущего разработчика и меня лично.
На самом деле это был всего лишь маленький эпизод длинного пути...
Почему так вышло? Потому, что я всегда настаивал на соблюдении обратной совместимости и со мной можно было договориться об интеграции, я не считал её чем-то сложным. В мире, где большая часть команд постоянно не заботилась об обратной совместимости, мой модуль стал интеграционной шиной, как большой торговый город, стоящий на перекрёстке множества дорог.
Вообще, генеральным директором и его «самодурством» в компании было принято очень многое объяснять. Только это было не до конца правдой. Генеральный директор был человеком умным и в прошлом талантливым разработчиком. Моей команде пришлось как-то своими руками повторить то, что он лет 10-15 назад сделал своими руками для десктопной версии. Ну, я то его алгоритм понял (раза с третьего), мне решение понравилось. А вот техлиды и ведущие разработчики — нет, алгоритм слишком неочевидным был. Им просто не хватило масштабности и строгости мышления.
Вообще, генеральным директором и его «самодурством» в компании было принято очень многое объяснять. Только это было не правдой.
Самодуром он тоже не был. Просто он сам был золотой шестерёнкой, на которую вся компания пыталась валить все решения, чтобы снять с себя ответственность и не думать своей головой. А когда человек изо дня в день проводит от 16 и более встреч по разным техническим вопросам, к концу дня от усталости он может принимать решения любой степени неадекватности. Если вообще сможет что-то делать. Генеральный директор — мог.
На мой взгляд, это скорее «ловушка основателя», которую описал Адизес.
Нагрузка росла, мы даже один раз успели по моей инициативе сходить в «смертельный марш». Что это такое и как оно делается, хорошо описал в своей книге Эдвард Йордон «Путь камикадзе [Смертельный марш]». Я не смог смотреть, как наша компания теряет замечательный и новый рынок, который открывался благодаря изменениям законодательства в сфере розничной торговли.
В процессе этого многомесячного похода я понял, что руководители проектов в компании не то, чтобы не могут представить себе схему передачи данных того либо иного функционала, им на это глубоко безразлично. Они предпочитали думать головой генерального директора, а мне было его уже жалко, поэтому и схему, и общую архитектуру сделал я сам. И они радостно начали думать ещё и моей головой, так как к генеральному директору сложно попасть, а мне можно просто позвонить.
Мой модуль опять стал точкой интеграции множества систем. Ведь наиболее быстро я мог менять свой функционал, а времени было до обидного мало.
Тогда мы успели и заняли какую-то долю нового рынка. Самым важным было зацепиться. Через какое-то время крупные компании вытеснили мелких игроков и увеличили свою долю. Мы были крупной компанией.
Сейчас начнётся самое интересное. Важно будет понимать, что я выступал сразу в нескольких ролях. Я руководил филиалом (центром) разработки в Новосибирске, это было обособленное подразделение со многими десятками программистов. Нам было тесно в старом офисе (почти целый этаж в одном из БЦ), практически перед моим уходом компания под филиал купила отдельное здание. Без этого филиал уже не мог развиваться дальше.
Весь найм сотрудников шёл через меня. Адаптацией сотрудников, фактически, занимался тоже я. В филиале было много отделов в каждом из которых была команда от 4 до 8 человек. Один отдел принадлежал лично мне. То есть я возглавлял одну команду и половину своего времени ещё и код писал, выполняя роль играющего тренера. Таково было требование компании.
В какой-то момент моя личная команда разработки начала уменьшаться. Ведущие разработчики из неё начали уходить со словами: «Да ну это всё на фиг». Я знаю, что такое bus factor и почему он не должен равняться единице. Поэтому я всегда сам выступал дублирующим носителем знаний. Мог себе позволить.
Когда мой собственный bus factor стал равен единице, я начал поднимать тревогу. И дело не в том, что всем было глубоко безразлично. Сhief-уровень компании сказал «у меня просто нет других людей». А средний менеджмент этому даже обрадовался, это удобно для политических игр и для торговли между собой. Кроме того, чем больше я был занят, тем меньше успевал доставлять им проблем. Например, я не успевал заставлять их работать. Они, кстати, были вне моего подчинения.
Кроме того, чем больше я был занят, тем меньше успевал доставлять им проблем. Например, я не успевал заставлять их работать.
Прошёл год - безразлично стало и мне. Я подумал, что если я сам себя уволю, то уж точно не пострадаю от того, что мой bus factor равен единице. И если всем вокруг на это было всё равно, то зачем я переживаю-то?
В процессе этого всего мы сходили в ещё один «смертельный марш», чтобы вдохнуть жизнь в замерший функционал и выйти на новые рынки. Уже работали объединённой командой нескольких филиалов. Мне пришлось реализовать синхронизацию данных из облака с оффлайн-устройствами. Мастер-мастер синхронизацию. И опять по «требованию генерального директора» были нюансы. Бывает односторонняя синхронизация, бывает двухсторонняя, а у меня была «полуторная». Новые записи от оффлайн устройств принимались через волшебный метод типа «Найти или создать» с нетривиальной логикой работы. А после того, как оно создалось в облаке и потом приехало назад, приходилось зачищать дубли.
Это было временное решение, так как платформа обещала скоро выпустить нормальное решение для всех. Но пока они это не сделали, соседние команды начали синхронизироваться через мой функционал. Интересная задумка, прямо скажем.
В процессе реализации этого счастья внезапно выяснилось, что, когда я из базы данных получаю 64 мегабайта данных, мой поток на python падает из-за того, что у него заканчивается 2 гигабайта памяти. Вот так оптимально работал ActiveRecord от платформы на бэкенде. Кроме того, благодаря платформе на бэкенде методы API не могли принимать более 10 параметров, потому что кто-то в коде на C++ написал конструкцию типа: «Если передан 1 параметр, то … Если передано 2 параметра, то … если передано 10 параметров, то...». А мне нужно было больше 10. Вариант с JSON тоже не подходил, всё падало из-за памяти. Кроме того, версия базы данных была старой и там вместо JSON был доступен только hstor.
В процессе реализации этого счастья, внезапно выяснилось, что, когда я из базы данных получаю 64 мегабайта данных, мой поток на python падает из-за того, что у него заканчивается 2 гигабайта памяти.
Нет, я решил проблему через интересный SQL-запрос (с оптимальным планом выполнения), который возвращал мне hstor, из которого я делал строку, и ещё в SQL перегонял её в base64. Чтобы когда это придёт из БД на бэкенд, платформа не падала. Потом декодировал уже на python, подменял данные через замены текста в строке, затем опять закодировал (чтобы платформа не упала уже на передаче данных) и передавал на оффлайн устройство.
Я понимаю, всю нелепость и неправильность ситуации, а ещё глубокую сомнительность данных технических решений. Однако, мной было выписано множество ошибок на платформу. Они попробовали сопротивляться и отклонять их. У нас было несколько разборов на Сhief-уровне компании, в процессе которых мне удалось показать, что платформа работает неправильно. Где-то дошло до того, что я просто показывал скриншоты кода платформы на С++, где было сразу же видно, что оно работать не может.
Заведённые ошибки не исправили до моего ухода, прожили они больше года. В компании было правило, что командам с просроченными ошибками не давали премий. Сhief-уровень компании сделал исключения для команд платформы.
Кстати, на рынок мы успешно вышли. Бизнес-цель была достигнута.
Исправила ли платформа свои ошибки, я не знаю, ушёл раньше. Почему я ушёл. Потому что мне надоело решать организационные вопросы, и потому что у меня появились варианты интересней. Конечно, меня попробовали удержать, но я запросил столько, сколько мне не смогли дать.
Генеральный директор — человек смелый, он понимает, что незаменимых людей нет. Есть только стоимость замены. Я бы тоже себя уволил. Руководитель платформы кричал от восторга, когда я увольнялся. Наверное, я был чуть ли не единственным, кто мог заставить их работать. Среднему же менеджменту было безразлично.
Незаменимых людей нет. Есть только стоимость замены.
На самом деле, компания теряла только сильного разработчика и, возможно, его команду. В филиале оставалась очень сильная и слаженная команда руководителей. Потом, после того, как решатся проблемы с площадями, эта команда руководителей в неизменном составе отмасштабирует филиал разработки раз в 5. Этим достижением я горжусь.
Часть моей личной команды ушла со мной. Тот же чудный код синхронизации жил практически неизменным ещё больше года после моего ухода. Нетривиальное API модуля, кстати, тоже.
К чему же всё это?
То, чем занималась моя команда из 5 человек, попробовали отдать другим. Они не справились. Передали второй команде. Они не справились. Передали третьей команде. Они не справились. Пришлось пилить на куски и раздавать по нескольким командам. Путь полный боли и страдания длиной в год-два, не меньше.
Говоря честно, виноваты тут совсем не разработчики. Виноваты тут два управленца, которые не смогли договориться друг с другом по политическим мотивам. Ещё виноват средний менеджмент, который неполноценно выполняет свои функции и занимается локальной оптимизацией, решая свои политические задачи.
Говоря честно, виноваты тут совсем не разработчики.
Но именно в руках разработчиков потом всё и рассыпалось. Именно им пришлось что-то делать со сложным и непонятным кодом. Причём не зная истории его создания и не видя кучи взаимосвязей, ведь все носители знаний ушли. У менеджеров тоже знаний не осталось, они же предпочитали все хранить в моей голове. ТЗ они тоже не могли писать, я несколько раз заставил их это сделать, получилось очень плохо.
Научило ли это кого-то чему-нибудь? Да нет, конечно. У генерального директора действительно нет других людей, он работает с тем, что есть. А разработчики в компании и так более, чем сильные.
Подводя итоги
Конечно, разработчики могут ошибаться из-за своей неопытности либо скудоумия. Однако, часто в больших компаниях то, что мы воспринимаем как ошибку разработчика, происходит помимо его воли. Изменчивая внешняя среда диктует свои условия. Кроме программистов в разработке участвует ещё очень много разных людей. И не стоит надеяться, что какой-то разработчик решит организационные проблемы, с которыми не может справиться совладелец и генеральный директор компании. К сожалению, наша жизнь — это компромисс между нашими желаниями и нашими возможностями.
Отдельно скажу руководителям, что нужно опасаться работать с «золотыми шестерёнками». Они всегда вылетают. У них всегда bus factor равен единице. Они классные и по-своему талантливые, но берут за это высокую цену. Часто внезапно. У меня решений по аварийному сбросу из системы золотых шестерёнок нет.
Нужно опасаться работать с «золотыми шестерёнками», они всегда вылетают.
Если вы дочитали до конца и что-то для себя поняли, то спасибо вам.
Комментарии (43)
karambaso
25.06.2022 11:49-2Тема злободневная, но подана с искажением действительности.
Почему всё ломается даже у хороших программистов?
Потому что они плохие программисты.
Как минимум, в описываемой ситуации программист (он же начальник отдела) был плохим.
Достаточно одного перла:
при нескольких десятках тысяч записей у пользователя просто браузер упадёт
Понятное дело, раз у него браузер после нескольких тысяч строк падает, то ни о какой эффективности он не думает. И объясняет всё исключительно внешними обстоятельствами, ну и разумеется, этим обосновывает своё нежелание что-то исправлять. Хотя уже по орфографии многое понятно:
с подцветкой изменений
Но не орфографией единой, конечно. Вот его слова:
Причём это всё происходило исключительно быстро, так как под каждый случай собирался свой оптимальный SQL-запрос
По его мнению, создание оптимального запроса есть исключительный случай. А в остальных (то есть в подавляющем большинстве случаев) пишутся, очевидно, сильно неоптимальные (читай - тормозящие) запросы. Это признак хорошего или плохого программиста?
Хотя, с другой стороны, вот его инструмент:
мой поток на python падает
Да, от питона ждать чудес не стоит. Так же как и от разработчиков, использующих это чудо.
И ещё:
Я понимаю, всю нелепость и неправильность ситуации, а ещё глубокую сомнительность данных технических решений
Да, понимание вроде бы есть, но каково решение? Писать на питоне и ваять костыли. Так может не только в понимании проблем внешнего окружения засада?
Ну и "честное" отношение к начальству:
Сhief-уровень компании сделал исключения для команд платформы.
Самодуром он тоже не был. Просто он сам был золотой шестерёнкойСначала шеф умный, а потом он во всём виноват. Или наоборот, как кому нравится. Но главное - программист не виноват.
А результат такой:
Они не справились
Все виноваты, все не справляются, поэтому наш программист уволился. Логично, чо.
Никто вам не даст счастья просто так. Вы можете сколько угодно обвинять окружающих, но ваши действия явно показывают - вы писали тормозной код и не хотели писать нормальный. Вы были начальником отдела и ленились выносить универсальный код в общий доступ. Вы отбирали людей на позиции программистов, а потом "они не справились". Так кто-ж вам теперь злобный буратина?
Главная беда всегда одна - те, кто сверху. А те, кто снизу - продукт жизнедеятельности тех, кто сверху. И автор был сверху.
constantine_mitin Автор
25.06.2022 12:30+2Вы очень спешите с выводами, это вас подводит.
Во-первых, по вашему комментарию видно, что вы не прочитали первую часть статьи. То есть начали делать выводы не владея полным контекстом.
Во-вторых, почему браузер может упасть от того, что его попросили отрисовать табличку в десятки тысяч записей. Нет проблем вернуть с бэкенда на фронтенд сколько-то десятков тысяч записей. Это даже не так долго будет. Проблемы испытает сам браузер. Потому, что у него внутри используется DOM-дерево, то есть все html-элементы на странице входят в специальную иерархичную структуру, по которой ходят события и вычисляется видимость элементов, а потом ещё и рендеринг происходит. Если используется какой-то компонент таблицы, значит в одной строке будет находиться множество html-элементов, плюс связанные с этим события и код их обработки. В какой-то момент это все может стать непосильной ношей для браузера.
При этом мы помним, что мы не знаем мощность компьютера, на котором работает наш пользователь.
Конечно, есть подходы с виртуальным DOM, но в платформе, которую предложили это использовать ничего подобного не было.
Кроме того, виртуальный DOM тоже не всегда спасает. Бывают специфичные требования, которые не позволяют его применять. У нас как-то встала такая проблема, мы использовали Canvas. Если я правильно помню, ровно так же делает Гугл и Яндекс в своих таблицах. Именно из-за проблем с DOM.
В-третьих. Если мы бурем слово «подцветка», от слова «цвет», то дело не в орфографии. Подсветка происходит от слова «свет». В моем же случае, речь шла не о том, чтобы подсветить, а именно о том, чтобы подцветить. Немного разные вещи.
В-четвёртых. В компании была целая программа по повышению оптимальности запросов. В процессе её работы были разработаны специальные инструменты и программы обучения, результатом её стала работа раз в 100-1000 быстрее, со аналогичным снижением потребления оперативной и дисковой памяти. А это уже — многомиллионная экономия на мощностях ЦОД.
Для того сложного случая, реализовать сборщик SQL-запросов с оптимальными планами выполнения, это признак очень хорошего программиста. А вот использование ORM на таком классе задач — признаком плохого.
В-пятых. Немного не понял критику в адрес 32-битного Python, при условии того, что проблемы были в коде, который реализовали на С++. Наоборот, хорошо что оно падало, то есть проблема стала понятной. Лучше поток упадёт, чем нода ЦОДа.
Либо вы хотели сказать, что С++ это плохой язык? Я снова с вами не соглашусь. И на хорошем языке можно писать плохой код.
В-шестых. Вроде бы я писал, что мой код был быстрым, но эффективным. Но вот для того, чтобы владеть им, нужна была высокая квалификация.
В-седьмых. Не начальником отдела, а руководителем центра разработки, с количеством сотрудников, которое не каждого департамента информационных технологий бывает.
В-восьмых. Платформу разрабатывал не я и не мои ребята. Просто так лезть к ним и менять код, естественно было нельзя. И слава богу. Они и так не очень работали, а такая вакханалия вообще бы общую работу остановила бы.
В-девятых. Я же был руководителем одного из центров разработки. А их таких был где-то 10. Набирать сотрудников, естественно, я мог только в свой центр. Не справились ребята не из моего центра разработки.
С учётом вышесказанного, можно поставить под сомнение ваш тезис: «Главная беда всегда одна - те, кто сверху. А те, кто снизу - продукт жизнедеятельности тех, кто сверху». Было много людей снизу. Было ещё больше людей сбоку. Было какое-то количество людей сверху.
Конечно, можно сказать, что во всем виноват основатели и генеральный директор (это один и тот же человек). Вот только, если заглянуть внутрь других крупных компаний, там было как-то не лучше.
Поэтому, пока я не смогу такое лучше чем он, от оценок я буду воздерживаться. Просто рассказывать это одно, а показать работающее — совсем другое.
karambaso
25.06.2022 17:43-4Вы очень спешите с выводами, это вас подводит.
Понимаю, нужно защищать "честь мундира". Но не истину.
Проблемы испытает сам браузер. Потому, что у него внутри используется DOM-дерево
Не нужно было вам защищать честь мундира. Потому что вы показали, как уверенность заменяет место истины. 100 000 записей в таблице на 5 столбцов в самом худшем случае (опера) съедают 1.6 гб. Хром - 180 мб, фокс - 200-400мб (приват или working set).
Если мы бурем слово «подцветка», от слова «цвет»
Мы берём как в орфографическом словаре. А вы исправляете проблемы задним числом и считаете, что так и надо.
В компании была целая программа по повышению оптимальности запросов
Но вы почему-то выделили лишь свою скромную роль в одном единственном случае.
Немного не понял критику в адрес 32-битного Python
Вы писали, что у вас питон падал, а не си.
мой код был быстрым, но эффективным. Но вот для того, чтобы владеть им, нужна была высокая квалификация
Вы писали - они не смогли. Это про тех, чью квалификацию оценивали лично вы.
Не начальником отдела, а руководителем центра разработки
Тем хуже для центра разработки.
Платформу разрабатывал не я и не мои ребята
Если у меня не пилит пила, то я её точу. Вы же решили, что точить должны другие. Результат - они не смогли.
Не справились ребята не из моего центра разработки.
В оригинале вы писали, что именно вам приходилось отбирать кандидатов. А задним числом мы все красавцы.
Вот только, если заглянуть внутрь других крупных компаний, там было как-то не лучше.
Я бы не стал сравнивать с худшими примерами. Но да, для защиты именно такое сравнение выглядит "подходящим".
Поэтому, пока я не смогу такое лучше чем он, от оценок я буду воздерживаться
Вы писали о проблемах в вашей области. Не о проблемах налаженного начальником бизнеса. Поэтому "лучше чем он" к делу совершенно не относится. Он работал совсем в другом направлении. А вам ничто не мешало зайти к нему в "переговорную комнату".
Конструктив - признавайтесь честно, что вы обычный менеджер. Не надо про разработку.
constantine_mitin Автор
25.06.2022 18:17+6У нас здесь явно не проблема в «защите мундира», а в вашем избирательном чтении. А так же в тех надуманных аргументах, что вы приводите.
Например. Откуда вы взяли, что в таблице было всего 5 столбцов? И почему вы упустили, что речь шла о компонентах, которые в себя ещё включали много html-элементов?
Почему вы пытаетесь игнорировать тот факт, что русский язык относится к категории синтетических и имеет очень развитые механизмы словообразования? Для такого языка ссылка на то, что вы не смогли найти слово в орфографическом словаре, выглядит даже как-то нелепо…
Претензии типа: «...Но вы почему-то выделили лишь свою скромную роль в одном единственном случае...», показывают, что вы просто теряете контекст повествования. Так нельзя.
Потерю контекста подтверждает и это ваше заявление: «...Вы писали, что у вас питон падал, а не си...». Я же указывал, что код платформы на бэкенде написан на C++ и проблемы с неоптимальной работой с памятью были именно в коде платформы. Зачем вы что-то решили додумать?
Каким образом у вас из того, что я оценил квалификацию некоторых разработчиков по тому фактору, что они не смогли подхватить функционал (который в моей группе передавался без проблем), получилось вывести, что я оценивал их квалификацию при приёме на работу? Расскажите мне пожалуйста ход своих мыслей. Но проверьте их на логические ошибки, перед тем, как кому-то рассказывать.
Кстати. Часть этих людей «которые не смогли», работали не только в других центрах разработки, но ещё и были наняты до меня. Но, как я понимаю, по вашей логике я всё равно виноват? Потому, что виноват и точка?
У вас очень интересное заявление: «...Если у меня не пилит пила, то я её точу. Вы же решили, что точить должны другие. Результат - они не смогли...». Например, попытка другой команды что-то закоммитить в мои модули жёстко пресекались. Вплоть до удаления без предупреждения. Закоммитить что-то в код платформы, без предупреждения, без согласования — это диверсия.
Причём даже не та диверсия, после которой следует неминуемое наказание. После этого вообще адекватность и психическое здоровье человека нужно проверять.
Вот здесь: «...В оригинале вы писали, что именно вам приходилось отбирать кандидатов. А задним числом мы все красавцы...», вы опять теряете контекст повествования. Как у вас найм сотрудников в одном филиале смешался с наймом сотрудников для всей компании-то? Каким образом?
Вот здесь: «...Я бы не стал сравнивать с худшими примерами. Но да, для защиты именно такое сравнение выглядит "подходящим"...» вы как-то странно додумали. А кто сказал, что «другие компании» это худшие примеры? На самом деле, я даже не обозначал эти «другие компании». Но вы сразу додумали, что они худшие. Прекрасно же?
Иногда вы просто занимаетесь какими-то голословными обвинениями. Например, здесь: «...Вы писали о проблемах в вашей области. Не о проблемах налаженного начальником бизнеса… Он работал совсем в другом направлении. ...». Чтобы о таком говорить, нужно хотя бы иметь понятия, а в чём бизнес-то заключался, и какое место там занимала непосредственно разработка. И почему генеральный директор был вынужден участвовать в разборе архитектурных проблем. Да и почему он вообще МОГ принимать такое участие тоже.
Затем уже идут фантазии чистой воды: «... А вам ничто не мешало зайти к нему в "переговорную комнату"...». А это вы с чего взяли? Либо в мире волшебных эльфов в кабинет основателя и генерального директора компании с миллиардными оборотами можно входить с ноги? Либо он сидит да только ждёт, когда же вы ему встречу назначите?
Теперь смотрите. Вы постоянно теряете контекст повествования. Это очень плохой симптом. Вы постоянно пробуете что-то додумать. Это некорректный приём демагогии. Иногда у вас в рассуждениях появляются логические ошибки. Специально либо не специально вы их допускаете — неизвестно.
Если мы говорим про «конструктив», то вам следует оперировать полным контекстом, не додумывать того, чего вы не знаете, даже если очень хочется, не допускать грубых ошибок в логике рассуждений. Тогда вы перестанете приходить с очевидно неверным выводам.
karambaso
26.06.2022 13:01-1Вижу результат отрицательного отбора. Самореклама в виде статьи и упёртая защита рекламируемого. Например так: вы не понимаете, здесь совсем другой контекст!
Контекст задан в статье, всё остальное - привычка выглядеть (но не быть) подходящим кандидатом.
Ну а по техническим знаниям я вижу полное непнимание проблемы: а если в таблице будет не 5 столбцов? Ну да, если будет 6, то автор снова сядет в лужу. И если 16 - тоже сядет. И даже если 160 - гарантированно сядет. Но "вы не понимаете, это другой контекст (с)" всегда наготове.
constantine_mitin Автор
26.06.2022 13:27Почему вы позволили себе проигнорировать заданные вам вопросы? Если вам нечем на них ответить, можно просто извиниться за свою ошибку.
Конечно, контекст задан статьёй. Просто вы этот контекст игнорируете и начинаете придумывать что-то своё вместо этого контекста.
Касательно таблицы. Вот вы сами пишите, что у вас для таблицы на 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 раз. И это только таблица без всего прочего окружения.
Либо вы забыли уже и то, что писали сами?
relgames
26.06.2022 10:34+2Согласен. Сам был на месте автора. Точно так же ругал начальство (CEO) и программистов, которых сам же и нанимал.
Но я не ушел, поэтому теперь понимаю свои ошибки. Нет смысла ругать CEO, нужно либо отстаивать свое мнение, либо делать так, чтобы работало годами, не ломаясь. Нет смысла ругать программистов, не умеющих разобраться в гениальном коде - лучше самому этот код не писать, а учить команду, как решить проблему. Ну и самое главное, заставлять доделывать задачи, не допускать костылей в новом коде, даже если чуть больше времени занимает. Моя частая ошибка была, я разрешал закрывать задачи в виде "ну тут сделано криво, но у нас горят сроки, потом доделаем". Практика показала, потом наступает года через 3, и все это время приходилось бороться с костылями.
По статье, автор описывает, что такие ситуации бывают, и что люди склонны хвалить себя и ругать других, когда такое происходит. Но, возможно, у автора не произошел рост как управленца, т.к. он уволился, вместо разгребания всего, что он наделал. К сожалению, очень сложно научиться правильно поступать в таких ситуациях.
constantine_mitin Автор
26.06.2022 11:12Здесь только добавить, что автор не ругал CEO и программистов, которых нанимал сам. Программистов в других филиалах нанимал не я, отвечать за них не мне. Ну и их, я тоже не ругал. Команды разработки платформы (центральный офис, кстати) — да, а вот обычных разработчиков — нет.
Чего ещё добавить. Посыл про «разгребание» тоже не верный. Доработка моего функционала силами моей же команды никаких проблем не вызывала. Это происходило быстро и с заметно более низким количеством ошибок, чем у ребят из соседних филиалов. Проблемы были не у нас, а у тех, кто попробовал это подхватить. Именно они не справились с интенсивностью и нагрузками. Наверное, это они не состоялись, как управленцы?
Кроме того, я же не зря написал, что кроме непосредственно написания кода, и непосредственно руководства одной из команд разработки, я ещё целым филиалом разработки управлял, где моя команда существовала далеко не в единственном числе. Нас много там таких было. Думаю, меня, как управленца характеризует вот этот фрагмент: «...На самом деле, компания теряла только сильного разработчика и, возможно, его команду. В филиале оставалась очень сильная и слаженная команда руководителей. Потом, после того, как решатся проблемы с площадями, эта команда руководителей в неизменном составе отмасштабирует филиал разработки раз в 5. Этим достижением я горжусь…».
Ушёл я потому, что нащупал свой потолок профессионального роста в компании. Дальше только входить в «семью», а для этого желательно обитать в центральном офисе. Плюс политические расклады не позволили маневрировать даже CEO, который ещё и основным владельцем компании был.
Поэтому, я пошёл расти дальше и в другие места. Для бывшего работодателя тоже катастрофы не произошло. На их объемах это был всего лишь маленький укольчик и мелкая неприятность. Там такого и без меня могло периодически происходить.
При моём уходе основная тема переговоров была, чтобы я не трогал команду руководителей, которые все со мной очень хорошо дружили. Деловая этика быстро позволила нам договориться.
Вот только не всегда и не все золотые шестерёнки настолько лояльны к бывшим работодателям. Об этом нельзя забывать.
taluyev
25.06.2022 12:14+1Автор, почему вы не писали объектно ориентированный код? Выглядит подозрительно...
constantine_mitin Автор
25.06.2022 12:37+2Возможно, я просто не смог верно передать "масштабы бедствия". Система была очень и очень большая. То, что я описывал, по своей сути происходило на несколько архитектурных слоёв выше, чем тот уровень, где может существовать ООП.
Нет, конечно, ООП мы активно использовали, куда без него. Просто над ним было еще множество иных слоёв абстракции. Например, "Модуль" - это фактически отдельный продукт, который можно было подключить по лицензии в облаке. И объектов в этом модуле было достаточно много. В других модулях - тоже.
lxsmkv
25.06.2022 21:59+4Я тоже ушел со своего первого проекта где я поддерживал автоматизацию для 5 разделов системы и 40-а человек команды. 5 разделов это пять совершенно разных контекстов приложения, где нужно соответственно понимать бизнес-логику, а для этого общаться со всеми командами. В общей сложности около 350 тестовых сценариев помноженых на 8 основных вариантов продукта выполялось каждый день . Сборка и выполнение тестирования проводились у другого подрядчика. Команды только код сдавали. Кастомный скриптовый инструмент тестирования, со своими "прибамбасами". Особенности интеграции тоже свои. Чтобы понять куда и когда сдавать, дабы твой код попал в нужный вариант продукта иногда даже опытным разработчикам приходилось чесать тыковку. Ну и стандартный набор задач: отчетность, планирование, наращивание покрытия. Порой автоматизация тестирования превращалась в "драматизацию тестирования". Это я таким каламбуром называю синдром, когда заказчику периодически резко стукает жидкость в голову, что нужно лучше, больше, быстрее автоматизировать, и вообще-то еще вчера. Вот зарисовка из жизни:
Приходит ко мне руководитель и спрашивает:
- Заказчик мол хочет знать сколько нужно времени, чтобы все состояния покрыть тестами.
- Ну это смотря сколько багов будет в системе, у нас постоянно идет разработка, всплывают новые баги, на их документацию и трекинг уходит наибольшая часть времени.
- Ну предположим система будет готова и не будет больше меняться.
- Если система не будет меняться то и автоматизация не нужна.
- ...
Вопрос был закрыт.А проработал я на нем не много ни мало почти 7 лет. Просто в какой-то момент понял, что с моим опытом могу продолжать жонглировать своими задачами с закрытыми глазами и дальше. И это лестно быть единственным экспертом в узкой области. Но это не то, как это должно быть организовано. Не может автоматизация держаться на одном человеке. Да это выгодно работодателю. Но совершенно неправильно. Никто больше не знает как это все поддерживать, никто не знает как это работает, и чем вообще я занимаюсь. И соответственно, это карьерный тупик. Зарплату добавлять не станут, твои задачи ведь не меняются. И вобщем я понял что я обязан уйти, чтобы проект начал относиться к автоматизации правильно. Передал знания командам и ушел. Ушел, так сказать, во благо проекту и себе. Расставание в стиле: "Нам от этого обоим будет лучше".
P.S.:
Люблю вспоминать цитату Джима из нетленной философской мульт-эпопеи о Губке Бобе:
"Парень неплохой повар, но великолепным поваром он станет лишь тогда, когда наберется мужества, чтобы уволиться из этой дыры."
- вторая серия, пятый сезон (текстовая транскрипция оригинала)
XaBoK
25.06.2022 22:09+3Задача хорошего архитектора - предотвращение появлений "золотых" кого-либо. Необходимо работать с командой ежедневно. Специалисты-шестеренки (такой позитивный и эффективный "центр тяжести") мне попадались редко. Такие люди пишут фреймворки и инструментарий, которыми начинает пользоваться вся компания, без понимания почему и как это работает. Если их выделить в отдельный юнит инфраструктуры, то получается очень не плохо. Однако в большинстве случаев мне попадались бульдозеры. Которые любят вставить узкозаточенный SQL-запрос/регулярку или refelctions/unsafe код, потому что им "поставили" такую задачу. Вместо решения, которое должно устранить причину проблемы, просто ставили золотой костыль. Мне кажется это всегда смесь не желания решать чужие проблемы (других команд, модулей и тд), желание избежать конфликта и, конечно, вариант гордыни (а смогу ли я это решить? вот это крутое - решение я сотворил! ). Как тут не вспомнить Виктора Франкенштейна.
Вот таких Викторов менеджмент обожает. Ведь им не пришлось объяснять генеральному, что тот не прав. И сроки были намного ниже тех, что обозначил архитектор. Именно управленцы получают золото, а не те, кто создает чудовищ.
qw1
26.06.2022 02:19+1Человека, который всё будет делать «правильно» и объяснять генеральному, что тот не прав, быстро уволят.
Например, команда создаёт самолёт. Год, второй. Пришло время сдавать проект. И оказывается, что вход нужен не как обычно, сбоку, а снизу. Умника, который скажет, что надо всё начать с нуля, а бюджет проекта за 2 года слить в унитаз, никто слушать не будет. Будут слушать «золотую шестерёнку», которая предложит уникальный механизм поворота сегмента корпуса на 90 градусов перед выходом пассажиров.constantine_mitin Автор
26.06.2022 07:27+2Жизнь несколько сложнее, на самом деле. В моём случае объяснять генеральному, что он не прав, это было не что-то страшное и ужасное. Человек компетентный, по утрам он ещё не терял адекватность под нагрузкой, и с ним можно было конструктивно подискутировать. Спокойно признавал свою неправоту, когда для него открывались новые обстоятельства. Собственно, как и я. У нас были с ним очень разные наборы данных, синхронизация их помогала найти решения для иных вопросов.
Но генеральный директор — это не сверхчеловек, он точно так же, как и все остальные, действует в системе своих ограничений. Там наверху свои проблемы, и я ещё не видел человека, который с ними справлялся бы идеально. Но видел немало людей, которые знали, как идеально, и их наверху размазывало под нагрузкой.
К слову, мне как-то несколько раз в грубой форме высказывать своё негативное мнение об совладельцах-миноритариях компании, причём им лично. Что мне за это было? Меня не уволили, меня не оштрафовали, меня просто посчитали грубым и неуравновешенным человеком. Поэтому с тезисом о «быстро уволят» я не могу согласиться.
P. S.
Описанная вами проблема с самолётами уже решалась. У части самолётов выход производится через шасси. У Су-34 так, если я правильно помню. В поворотных механизмах для сегментов корпуса нужды нет. Сейчас даже поворотные механизмы для крыльев самолёта теряют свою актуальность.
constantine_mitin Автор
26.06.2022 07:14Если брать SQL, то это было общее требование по компании. На самом деле, мы ещё согласовывали новые таблицы, поля и индексы. Когда у тебя облако, а в нем многие тысячи схем клиентов, факт того, что, например, под индексы и таблицы тот же PostgreSQL создаёт отдельные файлы, начинает очень больно кусаться. Как и неоптимальные запросы, которые исполняются миллионы раз.
У компании был собственный ЦОД, достаточно мощный. Постоянно расширять его мощности и тратить на это миллиарды рублей, было нецелесообразно. Поэтому началась системная работа над оптимизацией запросов.
Говоря честно, основная сложность моего модуля была именно в интеграциях и контроле за потоками данных. У меня были хорошие компетенции в PostgreSQL, но у пары команд внутри моего филиала компетенции в PostgreSQL были значимо выше. Кроме того, в компании был техлид по PostgreSQL, я вряд ли чем его мог бы удивить (в базах данных, конечно).
Представление о том, что золотые шестерёнки будут избегать конфликтов — ложное. Чаще всего, им на них все равно, если надо, то будут конфликтовать, если не надо, то не будут. В отдельный юнит вы их упаковать не сможете. Не забывайте, что они не только хорошие программисты, но ещё знают как руководить людьми, могут решать архитектурные проблемы и играть в политику.
Даже если вы найдёте нужное количество золотых шестерёнок, даже если среди них будет человек, которого они будут уважать и слушать, то вы их все равно в отдельном юните не удержите. Вы, скорее, дворцовый переворот получите, когда эта команда пойдёт просить отдать им рычаги управления.
XaBoK
25.06.2022 22:23+2Худший опыт такого плана - гос.проекты, отделы внутренних разработок и пробная нишевая продуктовая система в непрофильном для компании направлении. Так как клиенты не очень чётко определены (фактически их нет и их роль кто то отыгрывает) и участники не рискуют своими деньгами, то от реальности оторваны все отделы. На разработчиков льются потоки бреда. И если находиться вдруг кто-то, кто начинает эти выполнять запросы про 7 красных линий, то остальные часто отключают всякое критическое мышление и тоже начинают ваять. Ведь начальство всегда будет говорить, что "а вот Вася сказал, что можно" и "ведь Вася сделал". Так что тот ад, который порождает общий сон разума - просто за гранью.
v1000
26.06.2022 10:59+1Как всегда, времени на то, чтобы сразу сделать хорошо, всегда не хватает, но вот в разы больше времени на переделку всегда находится.
И даже если изначально архитектура была выбрана правильная, новый функционал постоянно пытается ее ухудшить. Потому что бизнес требует - нет времени объяснять - надо делать. И, самое обидное, когда ускоренная разработка успела ухудшить архитектуру, но в итоге запланированные фичи оказались не нужны, или не настолько нужны, как казалось в начале.
Жаль что принцип "на рабочих компьюторах не должно быть ничего лишнего" хорошо работат только у администраторов сети.
XaBoK
26.06.2022 13:22+2Некоторые вещи нужно прожить, чтобы принять. Есть куча внешних ограничений и в моменте очень тяжело понять, какое решение правильное. Будучи разработчиком, я не понимал откуда столько ахинеи в коде, а главное в заданиях. Став тех. архитектором, я осознал, что плохое решение, почти всегда, является результатом ограничений. Дедлайны, умения и, конечно, узкий фокус на своей части работы. И только став главным архитектором, начав работать с топ менеджментом своей и клиентских компаний, я понял откуда эти ограничения возникают и как культивируются.
Haidozo
26.06.2022 13:30+1Интересно все описано, особенно в начале, только мне кажется смешаны в кучу разные понятия, люди, кони. Поэтому мысль в итоге как бы потерялась в неоконченных спорах с бывшим гендиректором.
Как мне кажется, есть действительно способные специалисты, рок-звезды, как хотите. Они понимают в аналитике, в архитектуре, опытные разработчики, с навыками управления командами и тп. Им повезло в жизни со многим столкнуться, многому научится. И они такие как есть - могут многое. Не идеальные дивиргенты конечно, но..
Также есть проекты - мертворожденные, недоношенные, здоровые, но не достигшие половой зрелости, и потому бесплодные - не оставляют после себя ничего. Есть и удачные, давшие потомство - идеи и подходы для многих других. И у всех есть свои муки роста и проблемы, и не обязательно это связано с тем кто их делает.
А шестеренки или винтики это как раз роли людей кто делает эти проекты. Ржавые, стальные, золотые шестеренки. Золотые шестеренки - это узкие места в бизнес-процессах, в подходе к работе. Управленческий долг.
От долга желательно не зависеть, вовремя гасить проценты, кто бы спорил, но он бывает необходим в какие-то моменты, поэтому это такая жизненная вечная тема для обсуждений, для тех кто забыл это сделать в очередной раз. Не от людей надо избавляться, которые могут выстроить процесс, сделать платформу для всей системы. Те же незаменимые сотрудники вполне могли бы спокойно работать в системе где нормально поделены сферы ответственности, адекватное управление, и нет повода для геройства. Они могли бы входить в состав руководства, обладая огромной компетенцией в ключевой сфере компании, и участвуя в стратегических обсуждениях могли бы приносить гораздо больше пользы. Но почему это чаще не так, почему на них проще смотреть как на шестеренки, это тема для отдельной статьи
constantine_mitin Автор
26.06.2022 13:45Понятно, что проблемы есть всегда и технический долг в иные моменты оправдан и неизбежен. Суть проблемы в другом.
То, что названо «золотой шестерёнкой» не может постоянно существовать в установившейся системе обычного вида. Она будет постепенно всплывать на уровень высшего руководства, после достижения которого начнутся уже политические проблемы.
Во-первых, этой золотой шестерёнке уже кому-то придётся уступить место. А этот кто-то может начать сопротивляться всей своей политической и административной властью. Во-вторых, золотая шестерёнка потянет наверх и свою команду. То есть будет осуществляться транзит власти от одной управляющей команды к другой. Это тоже может вызывать сильное сопротивление.
Попытка выделить новую команду в новое же начинание может вызывать политические проблемы уже во всей структуре организации. Банальный вопрос, почему им можно, а мне нельзя. Кроме того, будет обоснованный страх. Ведь если новые подходы сработают, то тех, кто уже приспособился к старой системе заставят работать. Это будет выброс из зоны комфорта.
Для стабильной и установившейся системы это может выглядеть, как неприемлемая цена. Для зонтичной структуры в момент её разворота, при должной смелости руководства (которое на самом деле просто собирается сделать левел-ап и пойти дальше), это может стать приемлемым вариантом.
Нет организация, которые подходят всем подряд. И нет людей, которые подходят к любому типу организации. Беря в руки золотую шестерёнку, нужно понимать, что это мощный и опасный инструмент, таким нужно пользоваться осознанно.
Haidozo
26.06.2022 15:56+2Мне кажется Вы как-то проигнорировали основную мысль что шестеренки это не люди и не предметы, которые можно брать в руки. Попробуйте не наваливать на РП еще один проект, если он как-то тянет уже два-три. Не просите например руководителя разработки позаниматься подбором кадров и обучением, бюджетным планированием, поисполнять обязанности пресейла для гендиректора на важной презентации, поучаствовать в разборе инцидентов в продакшене, и у вас не будет никаких золотых шестеренок. За это удовольствие придется правда заплатить сразу, наняв в штат и обучив необходимое число людей. Поэтому есть соблазн сэкономить, и обойтись одной шестеренкой, ведь тогда платить придется может быть потом, а это когда еще будет. Это и есть управленческий долг. Вы его хотели? Извольте в конце расплатиться. Признайте заслуги, наймите заместителей, помогите подхватить обязанности, компенсируйте личные затраты какие были, за счет повышения или другими способами. Исправьте узкое место в вашем процессе. Сделайте это вовремя. И шестеренка никуда не отлетит. Шестеренки же отлетают не куда-то в космос, а как правило недалеко, где просто соблюдается баланс затрат-и-вознаграждений, и необязательно стремятся стать снова золотой шестеренкой. Такое место можно создать и у себя, если подумать, так же?
constantine_mitin Автор
26.06.2022 16:42+1Вы хорошо написали, с вами даже хочется согласиться. Вот только эта сказочная система никогда не заработает. По той же причине, почему коммунизм и социализм не состоялись, - природа человека. Не руководителей, исполнителей, как не странно.
Например, я знаю, что если у моего бывшего работодателя уменьшить штат ИТ-шников раза в 4 и снизить им зарплаты раза в два, то производительность компании даже не снизится. Дело не в том, что людей не хватает.
Дело в том, что эти все люди большую часть сил тратят на противодействия друг другу. А делают они это прежде всего из-за того, что у них с компанией нет общей цели, но есть желание взять побольше, а отдать поменьше. То есть как раз нарушить баланс интересов и ценности в свою пользу. Как результат, они сами же превращают свою же жизнь в ад. Страдают и терпят за деньги, более жёстко выражаться не буду.
С точки зрения бизнеса ситуация ещё проще. Бизнес работает с тем, что есть. У него нет задачи сделать хорошо и правильно, у него есть задача сделать лучше, чем конкуренты. А у конкурентов ещё больший адища, не смотря, что они пытаются поступать так, как вы написали. Чем больше ресурсов вольёшь в систему, тем хуже в ней станет людям. Чувство меры же есть не у всех людей.
Конечно, можно говорить о командах мотивированных профессионалов-созидателей, но в реальной жизни такие команды существуют очень редко. И это не очень устойчивые конструкции из-за своего размера. Так как люди не мешают друг другу и не обманывают друг друга, то их и нужно очень немного. Из-за малочисленности потеря члена группы очень болезненна. А люди могут менять работу по куче разных причин, от переезда в другую страну, до просто ситуации, когда человеку надоело работать и он поехал медитировать в Гималаи лет на 10.
Золотую шестерёнку опасной делает умение управлять локальным пространством вокруг себя, заряжать людей общей целью и вести за собой, при этом ещё на ходу прикидывая оптимальный путь. В результате какой-то кусочек компании внезапно для всех начинает работать с чудовищной эффективностью, ломая сопротивление людей вокруг. Именно ломая, насильно, через кровь и боль, лишая их возможности поработать поменьше да взять побольше.
Потом золотой шестерёнке становится тесно в рамках компании, ей хочется большей самореализации, для которой есть и потенциал, и способности. Приходится решать, что с этим делать. Зачастую, такого человека просто отпускают на волю. Как не странно, это ещё позволяет сохранить хорошие отношения при расставании.
Haidozo
26.06.2022 19:13Да Вы тоже все правильно пишете про денежно-рыночные отношения, бизнес и несправедливость мира, но только вывод делаете что опасность представляют не те условные ленивые и заносчивые, кто палец о палец без премии не ударит, но которых много и которых можно заменить на таких же как они с легкостью, а те люди икс, которые может выстроили ваш бизнес или вытянули его когда он был на мели, потому что они не всегда будут и дальше впредь его тянуть.
constantine_mitin Автор
26.06.2022 19:43Конечно. Вот поставьте себя на место генерального директора, на которого абсолютное большинство в компании смотрит потребительски, прямо как на еду. Он для них и средство извлечения дохода (без него компания не будет такой успешной), и способ снять с себя какую-либо ответственность. А то что он иногда ругается и грозит уволить, так это мелочи, можно и потерпеть. Благо, что почти не увольняет.
И тут в такой среде внезапно появляется золотая шестерёнка, которая смотрит на вас, как на человека, понимает ваш бизнес и помочь вам пытается. Со временем этот человек растёт и ему становится тесно в вашей организации. Конечно, вы отпустите такого человека на волю, а не сделаете его пищей для среды, которая и вас-то пытается съесть.
А если этот человек ещё и вырастет во что-то сопоставимое с вами, так с ним вообще можно просто дружить начать.
Haidozo
26.06.2022 20:13Прекрасно понимаю, о чем Вы, но не понимаю в чем опасность то от таких людей. Порадуйтесь тому что имели честь поработать с понимаюшим и неравнодушным наверняка человеком. Поставьте его в пример сотрудникам, глядишь из остальных может один другой вдохновятся его энергией и способностями. Не для всех же предел мечтаний быть сисадмином на шоколадной фабрике.
Опасным может быть собственное завышенное ожидание, если таковое имело место быть, что он есть решение всех проблем. И если условно кто-то достиг понимания, что даже надежное оборудование в проме должно иметь резерв, то ему остался один шаг до понимания что и ключевые компетенции в компании должны быть задублированы, чтобы обеспечить непрерывность процессов. Были случаи правда когда и дублирование не спасало, и компетенции приходилось восстанавливать с нуля. Но это тоже не обязательно смертельно, хоть и больно.
constantine_mitin Автор
26.06.2022 20:18Генеральный директор же не в вакууме работает. Вокруг него есть команда. Команда вряд ли захочет уступать место. Придется делать выбор. Вот это первое, на что вы натолкнетесь.
nikolas78
26.06.2022 23:09То, что названо «золотой шестерёнкой» не может постоянно существовать в установившейся системе обычного вида. Она будет постепенно всплывать на уровень высшего руководства, после достижения которого начнутся уже политические проблемы.
Все верно, так как эта «золотая шестерёнка» хочет что-то улучшить, а все окружающие (в том числе и ваш гендир) нет. Опасно ли это для окружающих? Не знаю, слишком философский вопрос.
allter
27.06.2022 03:21Интересно, как с вашей точки зрения должен был бы бороться с таким положением вещей генеральный?
Т.е. получается, проблемы от того, что непонятны ответы на следующие вопросы. Это команда такая медленная (в описанном эпосе - платформы) или они реально чем-то сложным занимаются? Тот менеджер среднего звена приносит пользу или вред? Если у этой команды регулярно и с громким стуком падает система - это из-за криворукости, или просто у других команд системы не важные.
acces969
Битва за архитектуру
Эта обязанность означает постоянную готовность к битве - возможно, в данном случае лучше использовать слово "борьба". Честно rоворя, подобная ситуация распространена практически повсеместно. Команда разработчиков должна бороться за то, что, по их мнению, лучше для компании, так же как команда управленцев, команда маркетинrа, команда продаж и команда эксплуатации. Это Bceгдa борьба. Эффективные команды разработчиков часто выходят победителями в этой борьбе. Они открыто и на равных вступают в конфликт со всеми другими заинтересованными сторонами. Помните: как разработчик проrраммноrо обеспечения вы тоже являетесь заинтересованной стороной. У вас есть свой интерес в проrраммном обеспечении, который вы должны защищать. Это часть вашей роли и ваших обязанностей. И одна из основных причин, почему вас наняли.
Важность этой задачи удваивается, если вы выступаете в роли архитектора проrpаммноrо обеспечения. Архитекторы, в силу своих профессиональных обязанностей, больше сосредоточены на структуре системы, чем на конкретных ее особенностях и функциях. Архитекторы создают архитектуру, помоrающую быстрее и проще создавать эти особенности и функции, изменять их и дополнять. Просто помните, что если поместить архитектуру на последнее место, разработка системы будет обходиться все дороже, и в конце концов внесение изменений в такую систему или в отдельные ее части станет практически невозможным. Если это случилось, значит, команда разработчиков сражалась недостаточно стойко за то, что они считали необходимым.
Мартин Роберт, автор принципов SOLID, из книги "Чистая архитектура. Искусство разработки программного обеспечения".
От себя - как то я не смог отстоять интересы платформы перед бескомпромиссными желаниями менеджера среднего разлива, из за чего в итоге сменил место работы по собственному желанию. Пока в нашем обществе гуманитарии доминируют над технарями, так и будет.
XaBoK
Автор не назвал себя архитектором. В этом есть смысл. Он явно выполнял часть этой роли, вот только из-за того, что он же являлся исполнителем, то передачи знаний и "чувства" архитектуры ни у кого другого так и не возникло. Я тоже этим страдал - проще сделать самому, чем объяснять другим. С опытом приходит осознание последствий. Иногда в виде такого вот поста.
constantine_mitin Автор
В целом согласен с вами, но тут ещё более тяжёлая ситуация. Я больше года пытался передать эту экспертизу и знания тем лицам, у кого она должна была быть. Они мастерски уворачивались от вручения этих знаний и экспертизы. Оказывается вручить экспертизу — особый вид искусства.
В какой-то момент мне надоело рассказывать, какие будут последствия, потом пришлось их показать в живую.
mvv-rus
Ничего подобного. Мы ведь тут живем не светлом будущем, а царстве бездушного чистогана. А потому наемный разработчик никакого своего интереса в программном обеспечении не имеет — оно ему не принадлежит. Его интерес — зарплату побольше получать, ну — и интенсивность своего труда снижать, чтобы его не заездили (валят на того, кто везет, да). Последнее делается куда проще совсем другими методами, нежели борьба за то, что лучше для компании: согласно Василию Ершову аналог этих методов в авиации называется «поставить обтекатель».
Ну, а у дяди Боба — свой собственный интерес, с интересами разработчиков никак не связанный: поднять бабло на своих книгах. А если в книгах писать такие демотивирующие наемных программистов вещи, вроде того, что я написал абзацем выше — бабло поднять не дадут.
qw1
Чтобы побольше получать зарплату, нужно побольше выдавать результат. Для этого придётся либо вовлекаться и работа сама пойдёт, либо себя заставлять работать, страдая.
mvv-rus
Во-первых это просто неверно: чтобы побольше получать зарплату, нужно, чтобы либо рынок труда двигался в сторону роста — потому что зарплата определяется рынком (т.е. возможностью уйти на большую зарплату), либо двигаться самому в сторону более высокооплачиваемого сегмента на рынке труда — например, перейти из сегмента дужнов в сегмент мидлов.
Во-вторых, что вы имеете в виду под словом «результат»? Если пользу для бизнеса — то она тут не при чем: оказанная услуга ничего не стоит. Результат нужно выдавать на том уровне, за который платит наниматель. И не надо явно пытаться стать лучше других — коллектив таких «стхановцев-гагаоовцев-заглаовцев» не любит, о вполне материальной причине: они своим активизмом ухудшую условия труда: повышают нормы выработки и т.п.
В-третьих, работа — это всегда страдание: именно его наниматели и компенсируют деньгами.
qw1
А если тупо рутина, например, в отчёте шрифт поменять, то это не сложнее, чем зачистить данж в WoW. И что? Игроки WoW ходят в данжи каждый день и делают одно и то же. Они страдают?
mvv-rus
Бывает — как случайный побочный результат. Но деньги наниматель платит не за это.
Те, которые фармят — таки да. А другие так развлекаются: развлечения — они очень разные бывают.
qw1
Значит, слово «всегда» было неуместным.
mvv-rus
Замените «всегда» на «практически всегда» — и будет счастье и вам, и мне.
qw1
Но почему я почти никогда не испытываю страдание на работе?
nikolas78
Ага, вы прекрасно описали самый короткий путь к выгоранию — работа исключительно ради денег.
mvv-rus
Чтобы не выгореть, надо соблюдать гигиену труда.
PS Я писал не про работу исключительно ради денег. Если вы прочитали мой комментарий внимательно, то должны были увидеть, что я писал про баланс денег и условий труда.
nikolas78
Как же?
Прямое отрицание заинтересованности в качестве, только повышение отношения деньги/затраты.Вы может и имели в виду что-то другое, но я честно этого не увидел.
mvv-rus
Вы все правильно поняли: в качестве продукта заинтересован только владелец продукта, то есть наниматель. Для этого он ставит перед работником требования по качеству, которые работник должен выполнять, чтобы его труд был признан трудом.