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