Comments 24
Классовую ненависть вижу здесь я
У манерагеров нет цели и задачи сделать лучше, главный интерес манагеров - чтобы им было вкусно, и чтобы к ним не докапывались, поэтому продукт, который что-то там автоматизирует не делает манагерам лучше, а вот хуже сделать может.
Потому инженегр и остаётся инженегром, что работает на компанию, и не научился работать на себя
Лучше и не скажешь, надо всем прогерам открывать свои ИП, а инженегры пусть манагерам и бизнесу который не хочет погружаться в ИТ и видеть дальше своего носа, зарабатывают бабки за счет своего здоровья и профессионализма
ИП здесь каким боком? Можно работать В корпорации, но при этом работать на себя. Автоматизировано что-то? Молодец, пользуйся, но дарить это корпорации не не надо, не оценят.
Самая большая ошибка которую я наблюдаю везде, это неверное восприятие целей других людей. Для многих будет огромным откровением, что должостные обязанности и корпоративная мотивация чаще всего совершенно не имеют ничего общего с истинной мотивацией служащих. В большинстве случаев единственной мотивацией служащих, и не только управленцев, является добыча средств к существованию. Защита своей кормовой базы является первейшей задачей любого вида живности на нашей планете - так как это по сути реализация первичного инстинкта, инстинкта выживания.
С автором полностью согласен, хотя автор не стал переходить границы дозволенного и указывать на наготу и уродство существующей системы смыслов и легенд про корпоративные культуры, вовлеченность и мотивацию персонала в цели компании, а также про отрицание всеми собственниками очевидного.
Собственники всеми силами отрицают свою роль "богатого Буратино" щедро вознаграждающего всех причастных к системе которая производит высокий, и виртуальный, социальный статус владельца - мой ИТ больше твоего ИТ, у нас процессные процессы и т.д.
Собственники отрицают, что большая компания это не следствие их больших амбиций, а следствие:
правил игры в капиталистической системе - становись больше иначе тебя сьедят, то есть опять просто выживание;
получение удовольствий от социальных ласк вследствие занятия высокой позиции в социальной иерархии группы.
Подписался на вас, буду ждать новых интересных статей.
Что отличает инженеров от простых работяг? Инженер прежде чем копать траншею разрабатывает трактор, работяга же тупо хватается за лопату и начинает истово, потея и матерясь на всех вокруг, копать. Поэтому в данном примере инженер на своем месте. Он делает то, что должен делать. А на остальное ему нужно положить большой болт.
странная ситуация, когда "один инженер" сделал готовый продукт, а потом "плохие менеджеры" взяли и всё загубили. Наверняка такое где-то бывает, но мне чаще встречался другой сценарий:
инженер на коленке (нередко из говна и палок) пишет проект, который действительно решает несколько проблемных мест в существующих процессах. Вот только экономия составляет обычно не десятки человеко-дней / сотни тысяч долларов, а десяток человеко-часов или сотни..тысячи долларов, но и это хорошо. Но организовывать отдельную команду под этот проект - расходы на неё не окупят созданную экономию.
Дальше менеджеры, которые совсем не против экономии этих часов, предлагают выделить автору оплачиваемое время на доработку, но с условием, что он доработает проект в русле корпоративных стандартов, т.е. фактически займётся рефакторингом кода, написанием документации, вместо внедрения новых фич. А это оказывается не слишком интересно инженеру, который сделал его на коленке, и как побочный продукт его основных задач и интересов. Более того, далеко не каждый инженер хочет и может быть руководителем проекта, что требует других скиллов, чем написание кода.
И вот тут уже менеджеры начинают думать, а не передать ли проект какой-то команде, которая сможет в дополнение к имеющимся задачам развивать ещё и его. Команда, которая обычно занята своими задачами, и не участвовала в разработке пет проекта, тоже не в восторге, но вынуждена так как сверху ей "сделали предложение от которого её руководитель не мог отказаться".
И вот команда получает проект, который как-то работает, но который для дальнейшего развития надо переписать практически с нуля. При этом ожидается, что параллельно команда будет добавлять новые фичи, решать проблемы с этим продуктом. Исходный разработчик, который передал все знания по продукту, дальше участвовать в этом не хочет. И да, новых людей обычно в команду не добавляют, так как мы помним, что экономия не огромадная.
И вот тут мы можем прикинуть, кто здесь злодей? Инженер, менеджеры, руководитель другой команды? или просто обстоятельства так сложились...
Я правильно из вашего текста понял, что менеджеры от оригинального разработчика хотят не внедрения новых фич, а приведения под стандарты и документацию, поэтому передают другой команде, от которой они хотят, чтобы те каким-то магическим образом и рефакторинг сделали и новые фичи внедряли? Причем при условии того, что эти новые люди ни сном ни духом обычно. Да и менеджеров эта проблема тоже не волновала до поры до времени, но они поняли, что теперь можно плюсов срубить и поэтому врываются со всей своей эффективностью и начинают важные указания раздавать.
Мне кажется, что вы как раз и рассказываете про ситуацию, которую топикстартер и описал. Что вместо того, чтобы помочь замотивированному человеку развивать важный продукт, эффективный менеджмент решает все по своему. В в итоге недоволен как изначальный автор так и люди, на которых это спихнули против их воли. Почему нельзя ровно так же тех же самых людей этому человеку выделить (если они все равно есть уже), чтобы автор писал фичи, а они занимались рутиной в плане документации, мелких багов и подобного? Почему для этого надо полностью забирать у автора контроль и потом удивляться, что он потерял интерес?
Важное дополнение, что это действительно должен быть какой-то важный и полезный продукт. Понятное дело, что под каждый скрипт на коленке задолбаешься выделять команды разработчиков.
менеджеры от оригинального разработчика хотят не внедрения новых фич, а приведения под стандарты и документацию
Ну отчасти, они хотят сделать проект "официальным", а для этого соответствующим корп. стандартам от ЯП до документации и безопасности.
менеджеров эта проблема тоже не волновала до поры до времени, но они поняли, что теперь можно плюсов срубить и поэтому врываются со всей своей эффективностью и начинают важные указания раздавать.
А вот тут неверно. Они не рвутся срубить плюсов для себя. Но если проект должен развиваться дальше не как пет проект, то его надо пригладить под "корп. стандарт".
Почему нельзя ровно так же тех же самых людей этому человеку выделить (если они все равно есть уже), чтобы автор писал фичи, а они занимались рутиной в плане документации, мелких багов и подобного?
Потому что этих людей не выделили эксклюзивно на проект, а им "добавили" нагрузку в виде этого проекта. А автор не горит желанием менять направление своей работы на поддержку продукта. Одно дело сделать что-то "без обязательств", как душа подсказала. Другое дело творить в условиях, что ты не только творец, но ответственное лицо (пускай и с выделенными ресурсами хотя бы в виде времени) в рамках корп. стандартов.
Опять же, люди в команде - они тоже хотят творить насколько это возможно, а не подчищать за другими, пока те творят.
Почему для этого надо полностью забирать у автора контроль и потом удивляться, что он потерял интерес?
Не то чтобы "надо забирать", а автор сам предпочитает сдать проект на поддержку, так как он перерос его пет проект, которым тот занимался параллельно с основными обязанностями, а заниматься им на постоянке у него планов нет (особенно с учётом упомянутых стандартов).
Вообще, есть очень большая разница "пишу проект для себя" (чтобы упростить себе работу, узнать новый продукт итп) и "пишу для других" (нужно соблюдать кучу требований).
Важное дополнение, что это действительно должен быть какой-то важный и полезный продукт.
Ну вот я бы сказал, что мегапродуктов, который описал автор поста: экономия сотен тысяч долларов для конторы, я не встречал.
Совсем мелких скриптов, которые решают какие-то текущие задачи - обычно в проект выделять не надо, кому надо - те пользуются, а поддержка им требуется минимальная.
А вот между ними бывают случаи, когда и экономия есть заметная, но недостаточная, чтобы оправдать создание отдельной команды. А для развития проекта силами автора - автору не хватает желания творить "как положено" в конторе, а не как бог на душу положит, а контора тоже не знает как с этим чемоданом без ручки быть, потому что и получить его никто не хочет, и бросать вроде как жалко.
Ну отчасти, они хотят сделать проект "официальным", а для этого соответствующим корп. стандартам от ЯП до документации и безопасности.
Тут спорно. Документация это хорошо и правильно, но вот переделывать какой-то продукт с плюсов на питон, например, это бессмысленно. Особенно если его специально сделали на плюсах, чтобы работало быстрее.
А вот тут неверно. Они не рвутся срубить плюсов для себя. Но если проект должен развиваться дальше не как пет проект, то его надо пригладить под "корп. стандарт".
Вы рассуждаете так, будто менеджеры только спят и видят как продукт сделать, а зачастую они (как тут писалось выше) ничего кроме своей выгоды не преследуют. И заранее в риски вписываться не хотят, пока кто-то не пройдет этот путь. Зато потом можно прийти и возглавить.
По остальным абзацам все сводится к тому, что обычно вы встречали именно что какие-то мелочи. Зачастую это в каких-то мелких командах или на аутсорсе. И там да, это обычно несущественное и не стоит затрат зачастую.
Но есть огромный объем всяких продуктов, которые выросли буквально из таких вот "наколенных" поделий. Чаще всего это, конечно вырастало в крупных компаниях, но далеко не всегда. И вы наверняка пользуетесь этими наработками. И пользуетесь потому что менеджеры были адекватные и решили развивать продукт. Я сходу могу назвать всякие штуки по типу того же кубернетеса, кликхауса, тарантула, да даже банальный джаваскрипт был наколенным поделием изначально. А так же бесчисленное число мелких и не очень библиотек для кучи языков.
Половина интернета работает на nginx, который тоже был пет-проектом одного небезызвестного сисадмина в Рамблере (если интересно, то можете почитать как ушлые ребята из Рамблера не так давно пытались этот самый nginx задним числом отжать).
И я бы с вами не спорил, если бы я буквально не был в схожей ситуации.
ну вот вы сами пишете, что удачные поделия вполне себе пробивают дорогу на свет и менеджеры помогают.
Другой вопрос, что ещё большая часть - это буквально чемодан без ручки, который развивать сложно или невозможно, а выбрасывать жалко, потому что пользу приносит. И обвинять менеджеров в том, что они хотят погубить детище талантливого инженера - ну странно.
То есть нет плохих инженеров или менеджеров, есть "неудачный" продукт, который делает, что должен, но для дальнейшего развития требует вложения усилий гораздо больших, чем прибыль, которую он может принести.
И да, у крупных компаний гораздо больше шансов использовать продукт внутри себя, так что даже копеечная экономия в масштабах большой огромной корпорации может оправдать вложение средств в проект. А для средних компаний - это не сработает, поэтому и вероятность, что проект у них загнётся выше.
Речь в статье, как мне кажется, была как раз про потенциально хорошие продукты, которые были загублены неудачным менеджментом. А не про то, что кто-то на коленке скриптик набросал и возмущается, что его не ценят.
И зачастую это не зависит от качества продукта, зависит только от вовлеченности тех, кто его продвигает (опять вспомнился джаваскрипт). В крупных корпорациях просто больше народу, которые способны это донести и пропушить.
Плохие менеджеры, как и плохие инженеры существуют, иначе не бывает в реальной жизни. Как и то, что люди могут неправильно оценивать расходы и затраты. Я буквально недавно стал свидетелем и участником того, как под рассуждения "нам некогда выдумывать, пилите на том, что есть" люди несколько месяцев делали проект и все разваливалось, а потом другие люди за 3 недели сделали хорошо. Если бы они делали с самого начала, то просто сэкономили бы 3 месяца. Самое забавное в этой все истории, что под "тем что есть" подразумевается лично мной созданная платформа, которую просто использовали очень сильно не по назначению.
Опять же, люди в команде - они тоже хотят творить насколько это возможно, а не подчищать за другими, пока те творят.
Вот, кстати, вообще далеко не все. Есть очень много людей, которым это нафиг не сдалось, они хотят просто получить ТЗ, отгрузить по нему решение и не забивать себе голову. Программирование уже давно перестало быть профессией исключительно для энтузиастов, которые любят свою работу.
И есть предположение, что ощутимая часть этих людей и вырастает в том числе от плохого менеджмента, когда энтузиазм сталкивается с реальностью.
Все просто, в опысанном случае плюшки получат манагеры, а все остальные получат геморой, и не нужно ничего обьяснять дальше. Я по себе знаю делаешь тулзу в спокойное время для себя желание горит хоть ночи не спи, а когда заставляют вот хоть убей не хочеться
Это говорит об уровне зрелости компании что равно уровню подготовки его менеджеров.
Что за странный стиль изложения - тезисы повторяются в каждом новом блоке текста.
Тезис про "признать власть" встречается 4 раза почти подряд и так вся статья. Её как будто 4 разаными словами переписали.
Напомнило рассказ Кафки "Гигантский крот". Схожесть моралей. Там: как получить признание в учёном мире, не оставаясь простым сельским учителем. Здесь: как улучшить процессы компании, не создавая "уникальный продукт".
Такое обычно бывает с теневым ИТ. Изобретателям-одиночкам тяжело было и раньше, читайте историю Вадима Мацкевича https://www.kommersant.ru/doc/2290009
При всей неэффективности больших компаний в бигтехе платят большие зарплаты, чем в средних и маленьких компаниях.
Продукт нужно не просто создать, но ещё и "продавать".
Создал под свою команду - для, своих целей и поддерживаешь. Руководству нужно, что бы все использовали? - велкам, с ресурсами, управляемостью и прочим.
Не нужно? - значит будет использоваться для нужд своей команды и всё. Без поддержки для остальных. Нет ресурсов и всё.
Нужно держать дистанцию и отчерчивать границы, а не играть в добренького.
Продукт, который спасал компанию, но умер из-за менеджмента