Comments 47
Тут очень просто: в руководители часто выбиваются решительные люди, а хороняки остаются внизу. Поэтому с одной стороны "вверху" часто принимаются решения без 100% уверенности в успехе (и все там прекрасно понимают, что "может не взлететь" и "подстилают соломки"). А с другой стороны, "внизу" боятся скопипастить один модуль в роли нового MVP без досконального понимания и рефакторинга.
Более того, когда в компании хорошая прослойка (CTO/CIO и т.д.) и минимум техдолга, то "верхи" идут в отрыв от действительности, т.к. неудачности их решений компенсируются "заделами" (хорошей архитектурой, обученными "как для себя" сотрудниками и т.д). А когда плохая, то начинается текучка, которая заканчивается либо эпическим провалом, либо становлением/приходом более приспособленной к изменившейся действительности команды. Иногда эта текучка занимает годы, что вовсе не так плохо, т.к. при текучке компания не теряет навыки воспроизводства (путем обучения) кадров...
А решать конкретному исполнителю. Запускать ли проект с криворукими технарями, оставаться работать ли под руководством "космонавтов"...
...часто принимаются решения без 100% уверенности в успехе
По опыту не часто. А наоборот. Точнее нужно перефразировать. Такие решения, без 100% уверенности в успехе, принимаются тогда, когда есть шанс большого профита. Ради него рискуют. Во всех остальных случаях всё наоборот - принимаются решения только после того, когда будет уверенность в успехе
...когда в компании хорошая прослойка (CTO/CIO и т.д.) и минимум техдолга, то "верхи" идут в отрыв от действительности...
Я сейчас работу в компании с полностью противоположной системой ценностей. Огромный техдолг. Есть мнение среди коллег, что CTO боится увольнения, потому вторит директору и принимает крайне спорные решения с точке зрения технического специалиста. И при этом руководство описано на картинке в статье, то есть уже в отрыве от действительности. И такое бывает
Во всех остальных случаях всё наоборот - принимаются решения только после того, когда будет уверенность в успехе
Вы противоречите своей же статье. Все не дети и прекрасно понимают, что могут произойти события вне зоны их влияния: склад сгореть, разрабы уйти в запой или в другую компанию, провалив сроки. Но можно подстелить соломки: склад застраховать или не покупать его, а арендовать с "нормальными" условиями аренды, неустойку по проекту зафиксировать в капитале компании (или аутсорсить разработку с нормальной неустойкой) и т.д.
CTO боится увольнения, потому вторит директору и принимает крайне спорные решения с точке зрения технического специалиста. И при этом руководство описано на картинке в статье, то есть уже в отрыве от действительности.
Ну, я так понимаю, ваша компания как раз в переходе от первого состояния (хорошая прослойка, взлетающее в космос руководство) ко второму (разрыв в прослойке, постоянные мелкие факапы) . Раз вы написали статью, то до текучки рукой подать, если только ваш CTO не объяснит своему начальству, что из одной шкурки 10 шапок делать можно, но не очень хорошо. :)
Кстати, забыл упомянуть, что часто причиной разрыва становится "всё хорошо, прекрасная маркиза" с точки разрыва пирамиды...
Вы противоречите своей же статье.
Простите, а можно уточнение, где противоречие?
Если вы имеете ввиду риски, то риски должны учитываться. Более того, я уже написал выше то, что вы пишете о «без 100% уверенности в успехе» работает только тогда, когда профит, который будет получен с некоего предприятия, кратно превышает эти самые риски. Это если мы говорим о нормальном бизнесе, а не о мутных схемах и чайханах всяких. Это я за бизнес не считаю
Ну, я так понимаю, ваша компания как раз в переходе
Ошибаетесь. Такая ситуация уже не первый год.
"всё хорошо, прекрасная маркиза"
Не понял аналогии. Раскройте, пожалуйста, детальнее
Простите, а можно уточнение, где противоречие?
(a) То есть руководство должно взять на себя ответственность на увеличение сроков всех работ, а оно на это не шло, так как для него проблема не казалась сложной и требующей пересмотрах сроков всех команд.
(b) принимаются решения только после того, когда будет уверенность в успехе
Противоречие.
Т.е. либо на самом деле не было уверенности в успехе, хотя вам со своей стороны кажется, что уверенность у руководства есть (в конце концов, это их работа - внушать уверенность в выбранном ими курсе). Либо прав я в том, что все прекрасно знают, что они могут что-то не знать, либо что может что-то случиться вне зоны их влияния.
Ошибаетесь. Такая ситуация уже не первый год.
А я и не утверждал, что такой переход моментальный. Судя по вашим словам, у вас уже есть разрыв. Если при этом нет текучки, то честь и хвала вашему CTO и вашему руководству. Задачи исполняются удовлетворительно, значит они свою работу делают хорошо. А с неудобством и техдолгом положено работать уже вам.
Не понял аналогии. Раскройте, пожалуйста, детальнее
Эм.. Что здесь понимать. Вы же сами говорите: "CTO боится увольнения, потому вторит директору". Как в песне поётся: "Все хорошо, прекрасная маркиза, Дела идут и жизнь легка.
Ни одного печального сюрприза, За исключением пустяка!"
Противоречие.
А где здесь противоречие? Вопрос устранения проблем в коде не про успех. Это та часть работы, те самые риски, которые уже должны быть учтены. В этом то и суть. Что само руководство шло на то, что в коде появился техдолг, то есть обменяло риски на профит. И теперь настало время этот техдолг исправить. Но оно продолжает откладывать необходимость его исправления, потому что на уровне руководства техдолг не мешает получать прибыль. А вот на уровне разработчиков техдолг очень мешает выполнять работу. И для исправления техдолга нужно теперь потратить часть будущего профита. Техдолг не просто так назван долгом.
А с неудобством и техдолгом положено работать уже вам.
Не положено. Это откуда такая чушь? То есть как прибыль получать так все первыми, а как потом проблемы разбирать, так пусть ответственные занимаются? Так ведь руководство такие же ответственные, только уровнем повыше.
...часто причиной разрыва становится "всё хорошо, прекрасная маркиза" ... Вы же сами говорите: "CTO боится увольнения, потому вторит директору".
Теперь понял к чему это. Разрыв был ещё до появления текущего CTO. Когда конкретно появился разрыв я не знаю. Я только знаю, что разрыв есть. И CTO на этот разрыв не влияет, так как и в прямом диалоге с руководством, руководство не воспринимает существование проблем в коде
А вот на уровне разработчиков техдолг очень мешает выполнять работу.
А кто сказал, что работа должна быть лёгкой? Это ваша РАБота. При её выполнении положено уставать...
так пусть ответственные занимаются?
... И им за это платят зарплату. А если им кажется, что мало, то есть хэха.ру и аналогичные сайты... А новые сотрудники, нанятые вашим CTO взамен вам будут через какое-то время писать на хабр, что предыдущие сотрудники оставили проблемы в коде, а руководство не признаёт наличие проблем. It's the circle of life.
А кто сказал, что работа должна быть лёгкой? Это ваша РАБота. При её выполнении положено уставать...
Это конфликт интересов. Одно дело, когда она сложная, но интересная. А другое дело, когда работа сложная не из-за задач, а из-за проблем в коде, которые нельзя исправить, так как нет времени, и малых сроков выданных на выполнение задачи. Именно из-за этого появилась статья
И им за это платят зарплату.
Точно так же зарплату платят руководителям. Это никак не снимает с них ответственности. Проблема здесь только в разрыве. А точнее в отсутствии доверия и диалога.
Технарям всегда хочется сделать на века, чтоб модульно, переиспользуемо, расширяемо... А руководство просто выжимает проект до точки неокупаемости, когда поддержка начинает съедать последнюю прибыль, и завершает жизненный цикл продукта. Всё. Проект рухнул под весом техдолга. Но это же тоже стратегия - ярко вспыхнуть, собрать сливки и умереть молодым.
Технарям всегда хочется сделать на века...
Отчасти это правда. Но не всегда. На текущем месте работы проблема в том, что то, что сейчас используется из-за техдолга может стать как раз тем самым недвижимым монолитом, который станет на века, так как менять этот монолит руководство не хочет, и придётся поддерживать это веками только потому, что нет возможности его отрефакторить. Это «боль» в прямом смысле.
И нет ничего плохого в модульности, переиспользуемости, расширяемости. В том то и суть, что если бы это понимали руководители, для них бы открылись более широкие перспективы по выжиманию проектов. Меньше затрат на разработку из-за модульности и переиспользования. Больше можно всякого докунить из-за модульности и расширяемости. Легко делить на отдельные продукты один и тот же код из-за переиспользования и расширяемости. Одни плюсы. С другой стороны минусы в том, что обычно как раз для перехода на модульность, переиспользуемость, расширяемость надо рефакторить то, что уже сейчас есть. На это нужны ресурсы, время, люди. И чем больше на старте было плевать на архитектуру кода, тем больше времени, людей, ресурсов будет требоваться при переходе.
Но это же тоже стратегия - ярко вспыхнуть, собрать сливки и умереть молодым.
И лично меня больше всего пугает, что именно в этом направлении теперь двигается компания, после прихода нового продуктового менеджера, так как это может быть серьёзной проблемой будущего самой компании, так как она на рынке более 10 лет.
После 15 лет проектов в промавтоматике появилось спокойное отношение к коду, без боли. Выгорание? - Возможно! Проект скатился в говно, потрачена куча человекочасов и бросить жалко? Ну чтож, это была хорошая попытка слепить по-быстрому. Будет продолжать в том же духе или подумаем об архитектуре? Об этом надо компетентно говорить с инженерами, с менеджерами, с руководством, называть говно - говном, стараясь не обходить острые углы. Тут можно бонусом и межличностные отношения прокачать. Слишком красноречивого могут заклеймить токсиком и выгнать, но тут уж личный выбор каждого, наступить себе на горло и лабать по накатанной или труба шатать.
Об этом надо компетентно говорить ... с руководством, называть говно - говном, стараясь не обходить острые углы.
На текущем месте работы это неоднократно было до меня (по крайней мере мне так говорили коллеги и мои тимлиды). Я решил попробовать сделать тоже самое со своей стороны - расписываю документ с описанием всех больных точек не только в коде, но и в процессах, чтобы увидеть как будет себя вести директор, чтобы понять его ответы, так как текущие его действия мне не понятны. И из-за отсутствия диалога совершенно не понятно куда двигается компания. Скоро узнаю
У вас много всяких вариантов:
Уволиться
Взять на себя проблему избавления проекта от тех долга
Стать хедом, чтобы техдолг перестал вас волновать
Доступен только первый вариант. Он уже рассматривается. И не только мной. В командах в компании ходят обсуждения на этот счёт
Проблемы в компании связаны с коммуникацией.
Низы не хотят или немогут доносить информацию, поэтому голова находится в другой реальности.
Нужно выяснить на каком языке доносить информацию. Если это язык прибыли, денег, роста количества пользователей, то прямо так и начинать преподносить информацию: Вы потеряете в деньгах, скорости роста итд итп, потому что, потому.
Эх-хе-хе... Код не понимают... Если бы только это. Своими глазами наблюдаю, как прямые менеджеры разработчиков понятия не имеют, а что собственно эти разработчики разрабатывают. А вы про код. Т.е. эти менеджеры очень смутно представляют, что за сервис тут разрабатывается, как он должен работать и почему. И всем нормально. Кроме разработчиков, естественно. Зато аджайл, скрам, облака и все остальные buzzwords.
именно в этом проблема: хороший код и продаваемый код - это разные вещи. технический долг - это проблема программистов и менеджеров не волнует. в моей карьере был случай, когда лид сказал прямо: код это ваши проблемы, а рабочее время должно быть потрачено на то, что заметно клиенту, рефакторингом и прочими улучшениями можете заниматься в нерабочее время, важно, чтобы заявленная фича была готова в обещанный срок (взятый из неба).
а продаваемый код - это который писан левой задней лапой макаки, но он уже есть здесь и сейчас, и худо-бедно работает, пока конкуренты всё ещё пишут хороший код.
именно поэтому бизнес открывается, продает, и закрывается.
и техдолг не закрывается годами, становлясь негласным соглашением.а также причиной "почему ты так долго возился, там же всё просто".
к справке: на текущей работе я предложила, согласовала и реализовала новый acl, который... обещали рассмотреть и спустя полгода так и не внедрили. как и прежде, при вводе нового права, правим код в куче мест, когда при моем подходе достаточно было бы добавить одну запись в базу. (ps: через интерфейс также возможно, но лучше скрипт если требуется сразу всем клиентам так, чтобы они не заметили)
Сочувствую.
Меня на текущем месте работы ставят в пример идеалиста. Хотя я не стремлюсь к идеалу и никогда не стремился. Продаваться может любой код, хороший, плохой - не важно. Для руководства важно, чтобы он работал. Я задаюсь вопросом, что мешает дать людям, непосредственным исполнителям, возможность сделать хороший код, тот который им самим будет удобен, так как это их инструмент? Из-за технического долга сроки уже растягиваются. Внедрение некоторых новых возможностей сильно сказывается на стабильности конечного продукта. По сути новый код == новые падения у пользователей. Пусть на старте всё было не хорошо, делалось на коленке. MVP - это нормально. А теперь-то, спустя время (в частности в моём случае, компания более 10 лет на рынке)? Что мешает? Выводы, у меня лично, неположительные. Выглядит это, как самое настоящее издевательство.
Я надеюсь, что в будущем код, с которым работает программист на постоянной основе, как штатная единица в компании, и разрабатывающий этот код для самой компании, будет приравнен к инструменту труда. И введут нормы качества, как на инструмент на любом производстве, чтобы он соответствовал определённым стандартам. И законодательно были введены принудительные доработки кода до стандарта. Шутка кончено. Но иногда мне кажется, что этот идиотизм не закончится без регуляции со стороны
Продаваемый код можно даже самодиагностикой и логикой отката к стабильным состояния обложить. Все встало колом с ошибкой ХХХ? Вот вам список действий YYY как починить! Так не стоит делать, но если надо производить уже завтра и заказчик понимает риски, то в принципе, вариант рабочий. И есть шанс, что такой технический долг просто превратится в инструкцию для оператора с описанием нюансов. Но это производственные приключения в шумных цехах, а не пользовательский опыт в кондиционируемых помещениях.
Я задаюсь вопросом, что мешает дать людям, непосредственным исполнителям, возможность сделать хороший код, тот который им самим будет удобен, так как это их инструмент?
"Взять и сделать хороший код" - это сложно. Надо выделить достаточно времени, провести анализ, проштурмовать возможные решения, реализовать, протестировать, задокументировать. Но времени на это не выделяют, верно? Вот и приходится всем барахтаться в месиве, обкладываясь костылями.
Если прям уж сильно болит за код, можно попробовать приводить его в более адекватное состояние отдельными набегами в рамках текущей работы. Совсем уж всех болей это точно не решит, но хотя бы поможет сгладить самые острые углы. Но тут важно не увлекаться чистками, иначе у руклей полезут вопросы "почему задачи по фичам слишком задерживаются?".
В долгосрочном же плане задача, скорее всего не имеет консенсусного решения. Если менеджмент не считает качество кода значимым фактором, то чаще всего бывает проще найти новый менеджмент, чем переубеждать текущий.
...приводить его в более адекватное состояние отдельными набегами в рамках текущей работы.
Сейчас ситуация такая, что любое серьезное вмешательство в код сказывается на всех разработчиках. Самые больные места не просто будут мешать работе при рефакторинге, а могут сломать работу. Настолько серьезно
В таком случае стоит начинать с максимально простых и безопасных изменений, а серьёзные отложить на потом. Может, моя недавняя статья подскажет какие-нибудь идеи.
Я задаюсь вопросом, что мешает дать людям, непосредственным исполнителям, возможность сделать хороший код, тот который им самим будет удобен, так как это их инструмент?
очень сложно угадать направление развития продукта. можно, конечно, наваять красивый конфигурируемый код, когда новая фича добавляется новой строкой в базе или конфиге. (одна из моих девушек была также программистом и делала именно такой код: можно всё, все до мелочей настраиваемо конфигом, и новый продукт - это тот же, но с другой конфигой) но вот сразу вопросы: сколько стоит эта магия - и времени начальной разработки, и требований к железу, и оверхедом в рантайме, и сложностью понимания новичкам?
вот именно из желания делать сразу хорошо мы зачастую получаем хелловорд на микросервисах, а потом новый человек только въезжает в это 3 месяца.
и при этом, мнение насчёт того, что такое хорошо и что такое плохо также отличается от специалиста к специалисту. для кого-то "хорошо" - это микросервисы на кафке, обязательно с готовым докером и т.д., а для кого-то понятнее портянка с одним методом Main.
и очень часто оказывается, что запланированная сложность никогда не используется, а чтобы сделать новую нестандартную фичу, нужно переделывать всю архитектуру, либо манкипатчить хитрыми вывертами.
это хорошо, когда у конечных разработчиков есть представление о том, как работает код и как он будет развиваться; когда на всё есть *doc, confluence и гадлайны разработки; когда у всех примерно одинаковый уровень и никто не творит в коде отсебятину и непотребщину. но увы, "так слона ты не продашь" и реальность совсем другая: когда продукт и новые фичи нужны ещё вчера, когда код - это трудночитаемое легаси (а ведь когда-то и это было "модно, стильно, молодежно"!) и выежоны отдельных гениев в стиле названий переменных a, b, c, a1, b1, c1, onion potato. когда кто-то оптимизирует спички и ставит самодельные колеса, подключает целые сторонние библиотеки ради одной функции и т.д.
знаете, даже я, со своими 15+ лет стажа, иногда пишу пет-проект в одном стиле, потом другой почти такой же, но совершенно в других принципах. иногда злюсь "как я плохо сделала", удаляю и переписываю, но... было ли раньше написано хуже? а нет.
то есть, вопрос "что такое хорошо и что такое плохо" не имеет однозначного ответа.
Ну все приложение целиком в методе Main, это прям однозначно плохо.
Зависит от требуемого объёма функциональности и планируемого жизненного цикла программы. Если это утилита для ad-hoc автоматизации, которую планируется выкинуть после завершения работ, то вообще пофиг на стиль. Даже один большой main вполне норм.
Пример такой программы. Есть какой-то набор данных, который надо перевести из одного формата в другой. Делать это руками тупо, так что пишем специализированную утилиту. Когда процесс перевода завершается, утилита больше не нужна. Удаляем её.
Опять девелоперов плачут, какие плохие менеджеры - ничего не понимают, и нормальный код писать не дают ….
Технический долг ничего не стоит. За его исправление нельзя выписать счёт и отправить клиенту. Соответственно с точки зрения менеджмента - нет проблем.
Если клиент хочет фичу завтра и готов платить, то с точки зрения менеджмента надо выкатить ее в прод, и как можно скорее выставить счёт.
Бизнес это про зарабатывание денег а не про прекрасную архитектуру и отсутствие технического долга.
Вы свой бек-лог возьмите и потрите в начале года. 100% гарантии ни кто не заметит «потери бойца».
Если проблема есть- ее опять зарепортят, если не зарепортят -это не баг, это фича :)
P.S. Сам девелопер, но понимаю мотивацию менеджмента :)
Опять девелоперов плачут...
И что в этом плохого? Если не поднимать проблему, то это лишь означает, что её нет. А проблема есть.
Технический долг ничего не стоит.
Чушь. Технический долг стоит дополнительные ресурсы на разработку.
...с точки зрения менеджмента - нет проблем.
И именно это есть правда, но она существует именно из-за того, что менеджмент не понимает проблемы кода. Об этом и статья.
Если клиент хочет фичу завтра и готов платить...
У нас нет клиента. Наш клиент - это мы сами. У нас есть только потребители и им продукт навязывается. Поэтому нет необходимости гнать на всех парах.
Бизнес это про зарабатывание денег а не про прекрасную архитектуру и отсутствие технического долга.
Одно другому не мешает. Как раз ошибочно думать, что они не могут сосуществовать вместе. Бизнес связанный с разработкой должен учитывать проблемы кода. Потому что код есть часть такого бизнеса.
Если проблема есть- ее опять зарепортят, если не зарепортят -это не баг, это фича :)
Тут я ничего не напишу. Так наплевательски относиться к коду.
Технический долг ничего не стоит именно клиенту а не владельцу продукта. Вам написали, о том что невозможно в счет клиенту написать пункт "рефакторинг". Согласитесь было бы странно, если бы вас какой то сервис, попросил заплатить им за рефакторинг?
Нужно также отличать намеренный тех долг или случайный. Есть хорошая статья по этому поводу https://habr.com/ru/companies/vk/articles/486098/ Можете дать ее почитать вашим руководителям.
Но в целом эта тема не новая и уже много много раз поднималась. Все это лечиться правильной культурой разработки. Как продавать руководству тех долг написано очень много статей. Если коротко, то нужен компромисс с двух сторон. Директор и руководители должны понять, что технический долг в итоге убьет всю компанию, а команды разработки должны понять что они не пишут код ради кода. Они пишут код который приносит деньги.
Технический долг ничего не стоит именно клиенту а не владельцу продукта. Вам написали, о том что невозможно в счет клиенту написать пункт "рефакторинг". Согласитесь было бы странно, если бы вас какой то сервис, попросил заплатить им за рефакторинг?
Простите, что иногда не совсем понимаю логику. Почему вы думаете рефакторинг технического долга нельзя вписать в счёт? Как заложенные риски в цену некоего продукта продукта. Рефакторинг будет оплачиваться за счёт прибыли компании. Именно это беспокоит руководство. Но это как с ЖКХ. В котором платят за капремонт дома.
Есть хорошая статья...
Спасибо за статью.
...команды разработки должны понять что они не пишут код ради кода.
Со своей стороны могу сказать, что та часть разработчиков на текущем месте работы, которая хочет зарефакторить код понимает, что они пишут код не ради кода. Это продукт, который нужно продать. Им сами будет проще и приятнее создавать продукт в хорошем коде.
Директор и руководители должны понять...
А в этом суть статьи. Что руководители в том числе должны понимать, как работает код используемый в их же компании, чтобы понимать, что с ним проблемы, что его нужно приводить в порядок, чтобы из-за этого не было конфликтов между «верхами» и «низами».
В компании, где я работаю проблемы в коммуникации между руководителями и исполнителями
Прочитав вашу статью очередной раз убедился, что если вы не можете объяснит проблему, то вы её недостаточно понимаете.
К сожалению разработка ПО по большей части ведется не здравым смыслом, а модой, или навязанными заблуждениями или желанием добавить строчку в резюме. Руководители высокого уровня это прекрасно понимают задают вам (программистам и непосредственным руководителям) вопросы не потому, что они не понимают, а потому что вы не понимаете.
Это я даже не говорю о том, что любую проблему можно посчитать в сроках и деньгах. Не одним точным значением, это нереально, а в виде вероятностного распределения. Если вы хотите общаться с руководителями высокого уровня, то вам нужно учиться общаться на языке цифр.
С вашего позволения я немного нарушу последовательность ответов.
Если вы хотите общаться с руководителями высокого уровня, то вам нужно учиться общаться на языке цифр.
Одна из особенностей, которая указана в статье именно в этом, что нужно подниматься на уровень понимания руководителя. Но тут возникает ещё проблема, на его уровне нет той, проблемы, которая есть на уровне исполнителя. Её туда перенести можно только переложив на сроки и деньги, но сроки и деньги это не суть проблемы на уровне исполнителя. Это по факту подмена. Что в каком-то смысле, по крайней мере я так считаю, ошибка.
Руководители высокого уровня это прекрасно понимают задают вам (программистам и непосредственным руководителям) вопросы не потому, что они не понимают, а потому что вы не понимаете.
Простите, а какие вопросы они задают? Как решить проблему? Нет. Я чаще всего слышал вопрос. А что это даст мне (если обращение было к владельцу бизнеса), или что это даст компании (если обращался я к руководителю пониже уровнем). Это нужно исполнителю. Решение проблемы исполнителю даст удобство. Можно считать это улучшениями условий труда
Кажется, что вы вполне можете от айсберга проблем показать лишь ее вершину, но со всей конкретикой - «вот тут мы внедряли такой-то кусок бизнес-задачи, и оно стоило вам 100 часов разработки. А также сломало вот такой функционал, что стоило вам ещё 30 часов разработки. Это дорого. Если потратить еще 100 часов и вот этот кусок привести в порядок, то на следующее приседание вокруг этого функционала будет потрачено 25 часов. А если нет - то уже 150, потому что ради ваших дедлайнов с небес в код изрядно так насрали. Решайте»
Я предположу, что людям из бизнеса интересны ответы на вопросы «а куда мы тратим наши деньги?». И все их наводящие вопросы как раз были в поисках этих ответов.
И, будем уж совсем честны - даже если техдолг представляет собой кусок каши времен мезозоя, с бОльшей его частью зачастую можно смириться, и даже ничего от этого не потерять. Но если даже критические проблемы (риск краха инфры, крит уязвимости и прочее) бизнес не хочет решать - думаю, вам не по пути. Так тоже бывает
Думаю не прокатит. Все прекрасно понимают, что затраченные усилия уже списаны и ничего не стоят.
Предложение убита 100 часов на рефакторинг обещая что потом будет лучше не работает.
Все прекрасно понимают что когда девелоперы говорят 100 часов это займёт от 200 до 400.
Дальше вы обещаете что новые фичу можно будет выкатывать за 25 часов вместо 150.
Руководитель вносит поправочные коэффициенты: новые фичи будут занимать от 50 до 75 часов поскольку программеры всегда оптимистичны.
Если мы сейчас сделали фичу за 100 часов, то скорее всего следующую вы сделаете за те же 100 часов а не 150, поскольку скорее всего ваша оценка будущей сложности завышена.
соответственно вы предлагаете убить 200-300 часов что в в будущем делать то же самое за тоже Самое время. При этом никто не знает нужна ли нам будет похожая фича в будущем или придётся все перелопачивать под новые требования.
Так что, предложение не принимается. :)
Вопрос "что мне\компании это даст" это предложение посчитать проблему\предложение в деньгах или в других единицах, которые легко в деньги конвертировать. В трудозатратах например.
"Удобство" и "улучшение условий труда" это не измеримые величины.
посчитать проблему
Чтобы посчитать проблему стоит тогда начинать сначала, с того сколько заработал бизнес пока эта проблема существовала. А кто это даст? Дадут считать только ту часть которую бизнес недополучит в случае исправления проблемы. Что уже не совсем верно.
..."улучшение условий труда" это не измеримые величины.
Хотя при этом есть стандарты и законы предписывающие соблюдать их. Только, пока, не в IT
Чтобы посчитать проблему стоит тогда начинать сначала, с того сколько заработал бизнес пока эта проблема существовала
Не понимаю зачем, ваш софт как-то влияет на доходы компании? Если нет, то эти сведения вам не нужны. Даже если влияет, то вам все равно необязательно считать в деньгах, посчитайте в количестве заказов\отказов\конверсии или других натуральных величинах.
В большинстве случаев разработка софта формирует расходы, поэтому вы вполне можете посчитать в трудочасах. Если не можете, то проблемы нет или слишком большая неопределенность.
Хотя при этом есть стандарты и законы предписывающие соблюдать их. Только, пока, не в IT
К сожалению вы тут апеллируете к тому, в чем не разбираетесь. Это кстати тоже сигнал для руководителя верхнего уровня, что вы недостаточно понимаете о чем говорите.
К сожалению вы тут апеллируете к тому, в чем не разбираетесь.
Если для вас это новость, то вот закон
В остальном не вижу смысла с вами дискутировать
Просто вместо буквы "Х" на вашей диаграмме (что это, от слова "холуй"?) должны быть заместители директора, которые понимают в том, что разрабатывают их работники и которым доверяет директор. Директор и не должен знать, что там как пишется, он должен ставить задачу. А заместители должны ему говорить, сколько это стоит денег, времени и людей. Дальше директор решает, надо это или нет.
А этих "Х" гоните в шею.
Кому интересно, как в реальности выглядела жизнь при Советской власти, очень рекомендую эту статью.
Вот так там выглядело ВСЁ, от сельского хозяйства до спецслужб. Наверху сидели профессиональные управленцы, партийные назначенцы, которые в деле не разбирались, но во все вмешивались и очень мешали профессионалам работать.
Хм, с одной стороны понимаю выгорание автора (типичное кстати) и озвученные им проблемы (распространённые тоже). Однако не сочтите за грубость, но: "Шерифа не волнуют проблемы индейцев" (с). Вы хотите, чтобы руководство глубже погружалось в проблемы кода? Так пожалуйста, только вдобавок вы получите тотал контроль и кучу микроменеджмента. И поверьте, прям взвоете ещё больше от этого (не раз на это натыкался). А ну ещё такое погружение вызовет естественный провал в бизнес-задачах руководства (читаем - профита), которое бесспорно повлияет и на подчиненные команды.
И как не странно, но поддержу довод о том, что если не смогли донести проблему до руководства, т.е. эскалировать так, чтобы поняли и приняли, то это осталось проблемой вашего уровня. Потому что да, это ваша работа. Другое дело, когда наверху не хотят слышать и всячески динамят (но только когда это именно так, а не так кажется). Тогда да, как уже кто то писал выше - есть несколько путей (признать поражение и уходить, поднять флаг и менять систему, стать хедом)
По поводу лавины тех.долга не совсем согласен с его обнулением. Да, с одной стороны это чистит действительно неактуальные таски, но с другой рождает типовой негатив у заказчиков: разрабы не только месяцами не исправляют ошибки, но ещё и молча закрывают несделанные задачи. Добавьте теперь к этому вертикальную связь заказчиков к своим руководителям. И когда наверху собираются 2 инфоповода: от технарей, мол техдолг растёт, и от заказчиков (внутренних/внешних), что технари "ничего не делают".
Однако не сочтите за грубость, но: "Шерифа не волнуют проблемы индейцев" (с).
Это выражение - не правило, а лишь крылатая фраза. И в рамках этой статьи не имеет смысла. Шерифа должны волновать проблемы индейцев, если следовать аналогии, без индейцев шериф - никто.
Я понимаю, что могут быть проблемы с микроменеджментом, но в моей практике, он обычно проявляется у тех, у кого нет компетенции. В то время как те, у кого есть компетенция микроменеджментом не страдают.
Если они там на верху ничего не смыслят в коде, то что мешает вам там внизу заложить в оценку новой фичи весь необходимый рефакторинг, умноженный на пи, и спокойно разгрести техдолг?
Это норма, и чем крупнее компания, чем сложнее ее структура, тем ужаснее бардак (левая рука не знает, что делает правая, а сигнал от мозга к ноге уходит вообще на клапан сброса давления). Во всем виновата западная система выжимки людей которая к нам не применима и в руках необразованных руководителей почитавших пару популярных западных книг - разрушительна. Я бы сказал причина даже не в том, что неадекватные сроки и т.д. а в работе руководства с "ресурсом" и отношением руководства к нему, а именно страшное оскорбительное слово "утилизация" сотрудников (почти везде сейчас используется). Они экономят на людях, мы привыкли работать за четверых за копейки, вот и все. У руководства как правило сухие цифры в эксельке, где все норм и все бездельники, а последний способ сокращать расходы- люди. Был бы нормальный штат, адекватные требования к сотрудникам, обучаемость, преемственность, тогда бы и хотелки руководства были в норме и компания бы понимала куда движется. Так, что мне кажется автор описал проблему, но не хочет погружаться в причины. Да и у кого в тиме не было такого, что новый сотрудник получает больше старого опытного? Вот и все
Проблема непонимания существующего кода, или Как руководству делать не надо