Еще будучи в университете, на втором курсе, я начал работать в сфере разработки электроники. Почти сразу я вкусил тот самый «ФГУПовский» менеджмент, о котором только слышал. В тот момент я не обращал на это внимания, взяли на работу, так еще и деньги платят, вообще супер, тем более я сам с этим не сталкивался. Дальше своего отдела нос не высовывал и все задачи были только внутри него. Время шло, уровень принимаемых решений рос, как и компетенции, и я начал уже работать со всеми отделами. Тут я начал осознавать все проблемы по полной.

Именно в это время, получилось так, что мне выдалась возможность бесплатно от университета, еще во время учебы пройти курсы переквалификации. Давайте сразу скажу, что учился я в топовом Московском университете, так что спорить об уровне образования не будем. Я долго думал какие именно это будут курсы, да и выбор был невелик, но он пал на «Product manager». Логика была в следующем, видя, как сейчас работают множество именно производственных организаций, имеющих свою разработку, стало очевидно, что есть критическая нехватка специалистов с уровнем принятия управления выше табуретки, а те, у кого они выше ни черта не понимают в разработке, даже базово. Если инженерные навыки и какую‑то базу, я могу получить на работе и на учебе, то адекватную управленческую базу будет сильно сложнее, с уровнем то окружающих процессов. Опустим сам процесс и уровень полученного образования (сейчас он мне кажется очень слабым, а знания полученные там поверхностными), да и тема не совсем профильная для технического вуза. Но факт в том, что я защитил «диплом» государственного образца по переподготовке с отличием и в итоге оказался никому не нужен.

Почему же так? Давайте сразу скажем, что все мало‑мальски большие производства электроники в России по большей части или полностью, или частично государственные или живут преимущественно за счёт конкурсов и дотаций. Плохо или хорошо, выводы делайте сами, но как минимум можно сказать точно, что компания, которая не ставит цель заработка денег, вряд ли будет эффективной (есть исключения, и вы думаю сможете их перечислить, но зачастую они не эффективны).

А теперь давайте подумаем, если во главе организации эффективность не является приоритетом, то на месте своих подчинённых будут не самые эффективные, а те, кто более лоялен. Конечно, на местах все может быть по‑другому, но глобальная картина такая. Теперь вернемся в реальность и сейчас будет история, которую вы точно вспомните из своей жизни.

Есть отдел проектирования, где допустим начальник и 4 работника. Директор стал недоволен начальником и собрался его уволить или начальник сам понял, что пора валить, типичная ситуация у всех и была почти в каждой компании. И вот начальник уходит и забирает с собой еще двоих лучших сотрудников и остаются двое, зачастую менее квалифицированных, чем те, что ушли. И вот директор приходит в отдел и говорит, нам нужен начальник. Времени искать, как всегда, нет, нужно тут и сейчас, а там потом найдем нормального. Подходит к одному и говорит ну ты работаешь на 3 года дольше, больше знаешь в ситуации будешь начальником. И что мы получаем? Во главе отдела не самый лучший инженер, который есть на рынке, если он долго в компании и не двигался по карьерной лестнице, то еще и не амбициозный, так еще возможно вообще не умеющий в менеджмент. Как вы думаете эффективно ли это? Нет, однозначно нет, но эта та реальность, в которой многие из нас находятся. Если вам интересно, можете посмотреть, что такое принцип Питера, который коротко говорит о том, что люди продвигаются до уровня своей некомпетентности.

Хорошо, вы можете сказать, что ну а представим нашли лучшего инженера на рынке переманили и поставили начальником, станет же лучше? Не факт. Хороший и высококлассный специалист не должен и за частую и не может быть хорошим менеджером. Это, кстати, решается образованием в области менеджмента, но в реальности будем честны — такого нет. Ну ладно, тогда мы поставим менеджера на должность начальника с образованием и навыками, так лучше. Да, но нет. Приведу вам небольшой пример из жизни. Будучи еще совсем юным в плане работы, наблюдал следующую картину, что при определении сроков, опытный инженер мог говорить любые сроки тому самому менеджеру, говоря такие умные слова, говоря, что санкции сложно достать и сделать, а речь шла про всего лишь разработку КД. Ну конечно толку от такого менеджера мало, так как в данном случае необходимо хоть минимальное на инженерное мышление и понимание того, чем необходимо заниматься. Если нет доверия между менеджером и «экспертом», который отвечает за техническую часть, ничего не получиться. А инженеру еще пойди объясни, что такое KPI, Kanban и другие эти слова, он тебя пошлет и скажет, что от тебя толку нет, только мешаешь, какую‑то автоматизацию хочешь внедрить, надо тебя уволить.

Бинго

Это было все предисловие, которое больше основано для тех, кто с этим не сталкивался. Основное чем мы займемся, это будем играть в «бинго». Надеюсь, все знают как в это играть, но для тех, кто не знает правила здесь просты. Если встречается то, что было у вас зачеркиваем (мысленно) эту клетку, а в комментариях можете написать сколько зачеркнули вы, а я в конце скажу сколько вышло у меня. В процессе я поделюсь с вами, тем, чему научили меня и конечно же на все дам ссылки. Погнали!

Пару слов до начала. Менеджерами мы будем называть любого человека управляющего людьми, то есть это начальники, директора и так далее. Дабы не разгневать истинных менеджеров, которые реально знают больше, оговорюсь, что есть множество подходов и ситуаций, где одно и то же будет «верно», «не точно» и «неверно совсем», все как в разработке. Здесь давайте не писать про Agile, Waterfall и другие матерные слова для обычного инженера, что если применить вот это подход такого не будет, а если использовать такой подход, то не будет другого. Я автоматически согласен с вами, статья не про это.

Неумение ставить задачи

Постановка задачи — один из столпов менеджмента. Чтобы не быть голословным откроем отечественный учебник «Производственный менеджмент» под ред. Козловского 2003 на 18 странице, что же там написано про управление:

«Процесс управления — это процесс выработки и обеспечения исполнения подчиненными принятых руководителем управленческих решений. Таким образом, принятие управленческих решений — основа управления. Решение — один из необходимых элементов волевого действия человека, предполагает осознание целей, средств их достижения и ожидаемых результатов. Решения могут быть бытовыми, политическими, конструкторскими, технологическими, управленческими…Требования, предъявляемые к управленческим решениям: 1) целенаправленность; 2) эффективность; 3) обоснованность; 4) адресность (обращение к конкретному исполнителю); 5) своевременность; 6) правомочность (руководитель имеет право принимать подобные решения); 7) непротиворечивость; 8) осуществимость; 9) четкость (невозможность двусмысленной трактовки решения); 10) полнота (содержит всю информацию, необходимую для выполнения); 11) краткость изложения; 12) ясность и понятность; 13) этичность (изложение в уважительной по отношению к подчиненному форме)»

Если не придираться к словам и понять, что после принятия решения, необходимо исполнить и тут мы возвращаемся к задачам. Для этого воспользуемся широко известной системой SMART (Specific — конкретная; Measurable — измеримая; Achievable — достижимая; Relevant — значимая; Time bound — ограниченная во времени.), что как мы видим перекликается с тем, как принимается решение. Так вот, вопрос, ставили вам хоть раз так задачи? А если вам так не ставили задачи, можем ли мы сказать, что решение было принято, так скажем «безалаберно»? Я думаю, вы меня поняли. В инновационных проектах цели могут быть менее формализованы, но базовые требования к ясности и ответственности остаются неизменными, сильно не гневайтесь.

Если решение было выработано четко, то постановка задачи по большей части заключается в установке сроков и выбора специалиста, который будет делать эту задачу. Да, мы тут очень сильно упрощаем и много чего не учитываем, но мы составляем базовое «классическое» понимание.

Отсутствие ТЗ

Очень связанная тема, но немного с другого угла. Вы не поверите, но до сих пор есть менеджеры, кто просто говорит «сделай, чтобы работало» и все. Скажем честно, кто‑то может сказать, что это условное «ТЗ», но по факту это отсутствие управления и перекладывание ответственности, а для кого‑то типичное задание от руководства. Опять обратимся к нашему учебнику:

«Результаты расчетов и согласований отражаются в утверждаемом техническом задании (ТЗ) на разработку. Этот важнейший документ содержит наиболее существенные характеристики проектируемого продукта, детализируемые по следующим аспектам: состав изделия и требования к его комплектации, показатели назначения, требования к надежности, безопасности, технологичности, унификации и тому подобное»

Мы видим, да я и думаю, что и понимаем, что ТЗ это база, от которой мы идем. Но многие руководители говорят, да тут же еще ничего не понятно, начни делать так, там напишем. Ну вы сами понимаете, что ТЗ до конца разработки так и не появится, что ведет к миллионным ревизиям, заменам, переделкам, а как итог заваленным полностью проектам. Многие не понимают, что начать проект на неделю позже, но с чётким ТЗ, увеличивает скорость и эффективность разработки в разы. В менеджменте все знают как выглядит «Cost of Change Curve», думаю и вам стоит знать и изучить

Неадекватные сроки

Думаю, у каждого такое было, что срок задачи завтра, а задание на месяц, после чего квартальная премия уходит куда подальше. Почему так? Ну первое, и основное, слабое понимание процессов на местах менеджером. Второе, недоверие к исполнителю, менеджер считает, что исполнитель хочет его обмануть и сидеть чай пить, поэтому занижает тот самый дедлайн. Третье, что самое интересное, это перекладывание ответственности за проваленные сроки другими исполнителями. Типичная ситуация предыдущий этап завален, ты завершающие звено и итоговый срок завтра, и чтобы не переносить общий срок, тебе его ставят нереалистичным, потому что ну мы все одна команда же, да?

Решение простое как две капли воды, открыть учебник по менеджменту. Это кажется смешным, но любой вузовский учебник на главах «Построение цикла разработки/производства» даст в тысячу раз больше, чем условная «практика». Конечно же никто этим не занимается, а почему, ответ короткий — математика, там ее много. Чтобы построить модель производственного цикла, который учитывает многие риски, надо сформировать информацию о том сколько в среднем длится каждый этап, его сложность(риск), как выполняться операции, какие ресурсы необходимы, а потом потратить пару десятков часов за расчётами и диаграммами Ганта. Ну или воспользоваться софтом, который может это делать (меня хардкорно учили на бумаге это делать)

Планирование сроков требует статистики, исторических данных и вероятностной оценки рисков. Без этого сроки превращаются в пожелания.

Работа за троих

Тут я думаю комментарии излишни.

Отсутствие интеграции между отделами

Когда каждый отдел оптимизирует только свою эффективность, система в целом деградирует. Начальство гонит план, разработка закладывает новые сложные решения, программисты — код, а итоговый продукт разваливается на стыках. Каждый вроде бы молодец, цифры красивые, отчёты прекрасные, а в итоге сроки плывут, себестоимость растёт и еще и все недовольны.

Проблема в том, что отделы начинают жить как отдельные компании внутри одной и любой смежный отдел, как сторонний заказчик. А потом, когда надо работать вместе, никто друг друга не слушает, думают, что их часть самая важная и надо делать только так, чтобы их процесс не менялся. Любой продукт это огромное количество компромиссов, которые должны принимать менеджеры, создавая продукт. Но тут возвращаемся к размытой ответственности

Отсутствие внутренних стандартов

Отсутствие внутренних стандартов — это рай для маленькой группы разработчиков и кошмар для менеджера. Ситуация, вы работаете с 3D моделями и пересылаете их между отделами, и каждый коллега присылает вам свою модель в своем формате, которую, например не может открыть ваша программа, потому что ему «удобно» или «так привык». Проблема ли это? Ну наверное нет, можно попросить пересохранить или самому это сделать, но все это время. Если с 3D моделями это может занять 10 минут, то, когда 10 людей присылают 10 разных отчетов, где одна и та же информация находиться в 10 разных местах, работа становиться невыносимой. А потом еще кто‑то увольняется, тебе передают проект, и ты тратишь безумное количество времени, чтобы разобраться как с этим работать.

Да, не все можно и нужно стандартизировать, но без базовых вещей, каждый раз приходится искать на что опереться. Можно даже начать не со стандартов, а с того, чтобы, садясь на любое рабочее место в отделе у вас они были настроены одинаково, а перестройка на под «нюансы» каждого работника не занимала больше 1 часа. Это не касается очень узкоспециализированных мест, но, когда у тебя полетела видеокарта, должна быть возможность открыть чертеж на соседнем компьютере и не настраивать базовые функции часа два.

«неПринятие» решений

Умение брать ответственность, а следовательно, и принимать эти решения, это как мы поняли базовая функция менеджера, которую никто не рассказал этим самым менеджерам. Мы же все наблюдаем, вот этот цирк, когда каждый перекидывает принятие решения на другого, чтобы если вдруг что «моя хата с краю». И вот тебе нужно согласовать техническое решение, сделать вместо 2-ух слойной платы, 4-ех слойную и даже скажем, ты уменьшишь этим издержки и начальник, который должен это согласовать, пойдет к своему начальнику, тот скажет согласовать с другим и так далее. А если решение лежит на стыке двух отделов, тут каждый отдел будет перекидывать принятие того или иного решения на друг друга и длиться это будет неделями.

Почему так происходит? Ну один из ответов, это отсутствие четких прописанных зон ответственности, вы можете сами себя спросить, а вы точно знаете в какой ситуации принимаете решение сами, а в какой нет. А где проходит грань? Есть много методов решения данной проблемы, одним из которых является матрица RACI (Responsible, Accountable, Consulted, Informed) или RASCI (Responsible, Accountable, Support, Consulted, Informed), коротко тут не рассказать, так что гугл в помощь.

Так же тут посоветую книгу «Пять пороков команды» Патрика Ленсиони, буквально первый порок как раз про это.

Отсутствие реальных метрик

Какую метрику эффективности вы выставите топологу или схемотехнику, при разработке? Сложный вопрос неправда ли, а как его решают? Самым глупым способом, уложился в срок или нет. Эффективно ли это? Да, но чаще всего нет, потому что как мы уже говорили выше, если нет менеджера, который может грамотно выставлять сроки, не ставя жесткие дедлайны или наоборот не растягивая сроки, то эта метрика может отдаленно показать эффективность. А покажет ли эта метрика разницу между работниками, который сделал топологию на 4-ех слоях печатной плате, когда все остальные на 10-ти ели уместились? А если в срок не уложился из‑за смежного отдела? А если начальник специально поставил нереалистичные сроки? Очевидно, не самая объективная метрика, зато самая простая и думать не надо.

Какой же выход? Смотря для каких целей и конкретной ситуации — в каждой отрасли и компании метрики будут различаться, но базовые принципы одинаковые. Во‑первых, метрики должны быть измеримыми и статистически анализируемыми. Если вы не понимаете, как распределяются ваши показатели и насколько они вариативны, вы не управляете системой, а просто смотрите на цифры. Во‑вторых, не все показатели обязаны подчиняться нормальному распределению. В реальной инженерной работе время выполнения задач, количество ошибок, объёмы переделок часто имеют асимметричное распределение с «длинным хвостом». Это нормально. Важно не подгонять данные под красивую кривую, а понимать их природу. В‑третьих, задача менеджера — снижать неоправданную вариативность процессов и понимать причины отклонений. Если разброс огромный, значит процесс нестабилен. Если все результаты одинаково плохие — проблема в системе. Если одинаково хорошие — возможно, метрика не отражает реальность.

Метрики сами по себе ничего не значат. Это просто числа. Вопрос в том, понимаете ли вы их статистическую природу и умеете ли отличать системную проблему от случайного шума. Если вы хотите погрузиться в мир статистики посоветую две книги это «Цифры врут» и «Статистика и котики», подойдет почти каждому, очень доступно и понятно.

Инновации ради инноваций

Лет 10 назад с появлением более доступных программ для моделирования, многие побежали их изучать и отправляли сотрудников на курсы, чтобы у них было то самое «моделирование». Что из этого вышло? Большая часть просто не нашла применения этому, другая внедрила, но потом забросила за неэффективностью, а кто‑то пользуется, не осознавая, что делает это неправильно. И есть единицы, которые применяют это в своей разработке. К чему это я, а к тому, что бюджеты потрачены, новости написаны, отчеты о внедрении новых технологий тоже, а по факту, моделирование как было, так и осталось нишевым.

Это мне напоминает всю беготню с ИИ сейчас. Все стараются внедрить себе ИИ, хвалятся этим в отчетах и на конференциях, но реальная картина куда спокойнее. В отчёте Deloitte State of AI in the Enterprise (2026) говорится, что около 60% сотрудников уже имеют доступ к корпоративным ИИ‑инструментам, но ежедневно ими пользуются менее 60% из них. Более того, лишь примерно 25% компаний перевели хотя бы 40% своих ИИ‑пилотов в полноценную промышленную эксплуатацию. При этом около 74% руководителей ожидают роста выручки от ИИ, но только около 20% реально видят такой эффект на практике. Как можно заметить, ожидания и реальность не всегда совпадают.

Заключение

Я обещал подвести итог «Бинго». Если честно — у меня 9 из 9. Это не потому, что всё плохо, а потому что с этим я сталкивался, сталкиваюсь и, скорее всего, буду сталкиваться дальше. Эти проблемы системные, а не персональные.

Рынку действительно нужны специалисты на стыке инженерии и управления — люди, которые понимают процессы разработки, но при этом умеют считать сроки, риски, ресурсы и принимать решения. Инженер без управленческого мышления не сможет масштабировать продукт. Менеджер без технического понимания не сможет адекватно управлять разработкой.

И, пожалуй, главный вывод: дело не в плохих менеджерах и не в упёртых инженерах. Проблема в отсутствии системного подхода. Пока компании не начнут выстраивать процессы, зоны ответственности и метрики осознанно, мы будем играть в это бинго снова и снова, что в какой-то степени даже весело