Бывает так, что в продуктовой IT-компании выстраивается иерархия, в которой верхние уровни работников компании совершенно не понимают как производится продукт, который компания производит и продаёт. По сути руководители знают как продать, но не знают как произвести. Для производства, что логично, нанимаются исполнители с опытом. Это нормальная практика. Но дальше, в зависимости от того, как выстроены процессы внутри компании, могут быть проблемы. О некоторых проблемах я бы хотел написать в этой статье.
Я не имею опыта работы в компаниях, где руководители верхних уровней доверяют исполнителям нижних уровней. Может быть доверие и было, но я его не замечал. С моей стороны все действия руководства выглядели так, будто их не интересует мнение людей, которые имеют опыт в конкретной области и непосредствено работают с конкретными направлениями в компании, для которых их, собственно, наняли. Мой опыт сейчас основан только на тех компаниях, где руководство оставляет за собой принятие всех ключевых решений по продукту. Что определённо негативно сказывается на продукте, так как результат принятия решения очень сильно зависит от опыта руководства. То есть, если руководство знает только как продавать, то оно будет принимать решения имено в этом направлении.
Эта статья по сути логическое продолжение предыдущей статьи «Проблема понимания существующего кода, или Как делать иногда [не] надо». Я изначально хотел расширить предыдущую статью, так как увидел, что в ней некоторые тезисы раскрыты мной не достаточно, или слишком однобоко. И пока готовился к переработке статьи на текущем месте работы произошло событие, которое меня несколько вывело из себя. В предыдущей статье я сделал акцент на том, что программисты должны знать код, который используется в компании, но в одном месте я сделал ремарку:
Понимание кодовой базы, с которой работает программист — это База. Это понимание должно быть у каждого работника на должности программиста в компании. На самом деле не только у программистов должно быть такое понимание, но этот тезис пока не в рамках этой статьи.
Об этом будет идти речь дальше.
Руководство и код
На текущем месте работы упрощенная иерархия компании выстроена так. Есть директор, голова всей компании, принимает все решения по продуктам сам. Под директором - группа хедов (голов), руководителей отдельных продуктов, каждый отвечает за свой продукт, то есть придумывает путь развития, накидывает «ТЗ», передаёт его дальше лидам команд. Под хедами - отдельные команды занимающиеся отдельными направлениями деятельности: дизайнеры, программисты, тестировщики. У каждой команды свой лид (ведущий), начальник отдела, если проще, и ряд работников (большой, поменбще, и ваще маленький жесть...) И если обобщать в виде картинки, то это будет выглядеть, примерно, как треугольник.
Обобщённое упрощённое схематичное представление иерархии в компании
Обобщённое упрощённое схематичное представление иерархии в компании
Для понимания. Работников в командах может быть куда больше, мне просто было лень ещё делить. Вся картинка и так ад перфекциониста.
И в текущей компании, где я сейчас работаю есть особенность, которая чётко делит иерархию на две большие части - это понимание того, как работает код продукта. Визуально это будет выглядеть, как уточнённая масонская пирамида.
И Стасян такой: «Хоба»
И Стасян такой: «Хоба»
То есть, с моей точки зрения (не только с моей, на самом деле, но в статье я буду писать за себя), ни директор, ни хеды не понимают как работает код, который используется для создания продуктов. Это создаёт огромную пропасть дискоммуникации. В другую сторону это тоже работает. Простой линейный персонал иногда вообще не понимает в какую сторону движется компания. Не секрет, что любой бизнес стремиться к увеличению прибыли. Но каким путём это достигается, какие навыки стоит развивать в будущем, и так далее, иногда вообще не понятно.
Происходит до боли смешные ситуации, когда хеды ставят задачу сделать MVP для выхода на новый рынок сбыта. И ставится определённый срок выхода. А им отвечают, что сделать в этот срок не получится. Нужно провести анализ возможностей, доступность ресурсов, а потом уже приступать к реализации. Что ставить жёсткие сроки для MVP глупо, так как текущий код полон технического долга, и простым способом не получится добавить настройки нового магазина или какие-то библиотеки поддержки новой платформы дистрибьюции. На это хеды сильно ругаются, делая замечание, что другие же магазины и платформы дистрибьюции уже есть, и они, хеды, не видят проблем добавить новые.
И вот на этом непонимании иногда строятся довольно серьезные конфликты, которые доходят до директора. И директор, имея привычку принимать решения самостоятельно, не имея желания разбираться в проблеме кода, выдаёт решение сделать в срок, основываясь на информации от хедов, что в этот срок будет максимальная прибыль, или будет максимальный приток новых пользователей, или конкурент может выйти раньше. То есть принимается решение без учёта проблем в разработке. Может быть риски и были заложены в срок, но повторюсь, понимания кода у директора и хедов нет. Они могут не понимать, что учтённые риски могут быть рассчитаны неправильно.
Почему же нет понимания?
Как мне кажется, потому что, во-первых, программирование - это сложно. Для этого собственно и нанимаются люди, которые понимают код, и с ним работают. Во-вторых, нет желания брать на себя ответственность в той области, в которой человек ничего не понимает, или понимает очень мало. Гипотетический пример, сегодня директор или хед, согласился на нововведение, а завтра всё сломалось из-за этого нововведения. Это приводит к потере прибыли и т.д. Пример гипотетический, но есть подозрения, что у кого-то стрельнул, так как на самом деле пример из опыта. Так оправдывался один из начальников низшего звена на одном из предыдущих мест работы.
Не редко руководство делает шаг в сторону команд разработки, и просит их объяснить простыми словами суть проблем, чтобы можно было совместно найти пути решения. Но требование объяснить простыми словами часто сводится к ситуации, когда аналогии и примеры, которые позволяют объяснит проблему понятно, настолько простые, или в личном понимании руководства простые, что руководство со своей стороны не видит сложностей, и удивляется, что команда разработки не может проблему решить. А по факту кажущаяся в простых аналогиях проблема может быть серьёзной. Она может затрагивать весь код. Все команды разработки будут вовлечены в поддержку изменений, что отнимет у них время исполнения их задач. Срок внедрения изменений может исчисляться месяцами. По сути руководство должно взять на себя ответственность на увеличение сроков всех задач, а оно на это не идёт, так как для руководства проблема не кажется сложной и требующей пересмотрах сроков всех задач всех команд. Были такие примеры в моей практике. То есть абстракции, которые иногда любят некоторые руководители, не могут не отражать сути, так как под абстракцией руководитель может понимать что-то другое, не то, что по факту имеется в виду. И иногда ситуация может доходить до абсурда, который лучше описать мемом из интернета.
Хоть и мем, но и так бывало в моей практике
Хоть и мем, но и так бывало в моей практике
И самое обидно для меня, бывают ситуации, когда руководство делает замечание, что если кто-то, например я, не смог руководителю объяснить проблему, то значит тот, в этом примере я, эту проблему сам не понимает. Это замечание - очень удобная позиция для руководителя. Руководство в ней и от ответственности ушло, и подчинённого на место поставило. Но ведь на самом деле здесь же два субъекта, они оба участвуют в диалоге. Получается, что диалога нет. А раз диалога нет, то откуда появится понимание у того, кто не понимает.
upd: От себя лично могу здесь дополнить, что мне неоднократно делали такое замечание на двух работах. И замечания делали те люди, у которых, как мне кажется, не было даже минимальной компетенции в той области, которую покрывала моя должность. Казалось это мне из-за того, что они не показывали хоть каких-то знаний в той области.
Бывало у меня и так, когда руководитель шёл на встречу, проявляя свою заинтересованность в решении проблем в коде, но через представление и объяснение путей решения. Такое можно часто встретить в виде выражения «критикуешь — предлагай». И вроде бы в этом нет ничего плохого, и это логично. Но здесь часто бывает так, что пути решения требуют описывать с точки зрения выгоды для компании. А это означает, что нужно перейти на уровень понимания руководителя, что опять же означает, что понимания проблемы у него всё равно не будет. Так как по сути самой проблемы на его уровне нет. Проблема в коде. Не у него. Не ему с ней разбираться. Что опять же логично. И вроде бы любую проблему в коде можно перевести в профит. Но бывает так, что профит будет виден только на очень длинной дистанции, или профит может быть настолько маленьким относительно общей прибыли компании, что по логике финансов тратить время команд на решения проблемы нет смысла. То есть даже ситуация, при которой команды разработки тратят очень много времени на обход технического долга в коде, может вполне устраивать руководство, так как прибыль идёт, сроки выполнения задач соблюдаются. Зачем руководству что-то менять. Узнали? Согласны?
Почему это происходит?
В случае компании, где я работаю, среди хедов нет технических специалистов достаточно высокого уровня. Есть несколько человек, у которых есть опыт в IT, но не в разработке. А потому они не знают особенностей самой разработки, или переоценивают сами себя. И по какой-то причине директор не хочет нанимать, или ставить из текущих сотрудников на свой уровень специалиста в роли консультанта. Здесь я лично теряюсь в догадках почему.
Не редко бывает и так, как было описано ранее, что всех всё устраивает. Так выстроены бизнес-процессы в компании. Хорошо это, или плохо зависит от уровня в компании, на котором находится отвечающий на этот вопрос. С моей стороны это плохо. Потому что есть проблемы кода, которые вылились в целую статью «Проблема понимания существующего кода, или Как делать иногда [не] надо». Сложно понимать код. Сложно поддерживать. Много чего ещё затрудняет работу с кодом. А это прямо влияет на сроки выполнения задач, на самочувствие специалиста, когда он понимает, что ему нужно опять лезть в «спагетти» и добавлять в него что-то ещё, что только усугубит ситуацию, а других вариантов нет.
Желание в кратчайшие сроки выпустить продукт, из-за чего игнорируются «красные флаги» и предостережения специалистов. Волевым решением руководства отметаются все недовольства. Что-то типа, не хотите работать - идите на улицу, никого не держат. Почти цитата. Это приводит к тому, что на старте проекта команда получает отвратительный, собранный на коленке код, который в последствии продолжают поддерживать, так он приносит прибыл. А проблемы не решаются, так как руководство не требовало делать плохо, сделали плохо разработчики, ответственности на руководстве нет. А ведь на самом деле руководство так же ответственно, так как принимало решения. Выражение «Тяп, ляп и в продакшен» не на ровном месте появилось. Хорошо когда спустя время всё таки идёт рефакторинг. Но такое, судя по некоторым статьям и комментария в интернете, в том числе и на Хабре, редкое явление. Обычно переписывание проблемного кода происходит спустя года. Бывает и так, что работает правило инженера - «Работает - не трогай».
Вместо вывода
«Как этого избежать» - вот как должен был выглядеть заголовок этой части, но я на самом деле не знаю как этого избежать. Мои советы будут выглядеть что-то типа «делайте хорошо, а плохо не делайте», что как бы не продуктивно. Я статьёй лишь обозначил проблемы. выводы оставлю вам. Вести бизнес сложно, возможно так же сложно, как и программировать. И не всегда кажущиеся проблемы на уровне разработчиков столь важны, когда на уровне руководства есть проблемы поважнее. С другой стороны в компании должен быть диалог. Не видимость его. Должно быть доверие. Особенно, когда кто-то не понимает область компетенции другого. Потому что очень плохо когда нет доверия. Это приводит к ситуациям, из опыта, когда команда разработки занимается крупным проектом, который позволит добавить в код новый функционал, который можно будет в будущем использовать его для получения большей прибыли. Но руководство из-за недоверия отказывается принимать проект и требует вернуть всё в зад.
На этом всё. Спасибо за внимание
p.s.
Здесь я бы хотел добавить аналогию. Где код - это инструмент в руках специалиста. Пусть это будет молоток. Есть у меня опыт работы с сломанными молотками. Работать можно, но небезопасно. Выпадающая постоянно голова молотка будет падать на ноги или, отскакивая в разные стороны, в том числе и лицо. А это может привести к травмам. Если голова молотка выпадает, значит сидит на рукояти не плотно, а это значит, что угол наклона головы постоянно меняется. Это влияет на то, как, например, забивается гвоздь. Гвоздь легко может согнуться из-за изменения угла плоскости головы молотка, а это влияет на угол удара по шляпке гвоздя. Это в свою очередь увеличивает время на забивание гвоздей, так как надо после каждого гвоздя подравнивать голову. Влияет и на качество забива, если время ограничено, так как неправильный угол удара может согнуть гвоздь, а сгибающийся гвоздь проще оставить согнутым, чтобы не тратить время, и нужно забить согнутую часть в дерево, чтобы не торчало, ведь оставлять незабитые гвозди - плохо. Сгибающийся гвоздь влияет на количество используемых гвоздей, когда согнутый гвоздь недостаточно крепко держит дерево придётся забить ещё один рядом.
Это самая простая аналогия. Кто хоть раз сам забивал гвозди уже чётко представляет себе о чём речь. Инструмент тоже должен быть качественным. Я не имею в виду The Best Molotok ever, а хотя бы у которого голова не отваливается и рукоять не трескается, с которым просто приятно работать.