Обучение IT-специалистов начинается с технологий: языки программирования, архитектура, инфраструктура, информационная безопасность, сертификации, новые платформы, новые инструменты. Это логично, но профессионального развития исключительно в своей предметной области недостаточно. В большинстве IT-компаний разработчик не только пишет код. Он также инженер, архитектор, аналитик, специалист технической поддержки, руководитель проекта, менеджер технической команды, эксперт, который участвует во встречах с клиентом, помогает сформулировать задачу, объясняет сложные решения простым языком и отвечает за то, чтобы технология действительно заработала в бизнес-процессе.
Поговорим о том, какие навыки стоит развивать профессионалам, когда IT-рынок меняется.
Эффективная коммуникация как часть инженерной культуры
Кажется, что для технического эксперта главное – глубина знаний, способность быстро найти решение, настроить систему, разобраться в архитектуре. Это действительно основа профессии, но любая технология внедряется людьми и для людей. Чтобы проект состоялся, нужно понять запрос бизнеса, снять ожидания клиента, договориться с коллегами, аргументировать техническое решение, объяснить риски, пройти через конфликтную ситуацию и при этом не разрушить отношения. В этом смысле коммуникация перестает быть «приятным дополнением» к профессии, и становится рабочим инструментом.
Особенно это заметно в клиентских проектах. IT-специалист может прекрасно разбираться в решении, но если он не умеет задавать уточняющие вопросы, слышать разные типы собеседников, переводить техническую логику на язык бизнес-результата, проект начинает буксовать. Где-то возникает недопонимание, где-то клиент ждет одного, команда делает другое, где-то конфликт можно было снять на раннем этапе, но его просто не распознали.
Поэтому в развитии IT-команд важно учить не абстрактному «умению общаться», а вполне прикладным вещам: как выстраивать диалог, как работать с возражениями, как презентовать решение, как вести сложный разговор, как понимать разные типы личности и подбирать формат взаимодействия под конкретного человека. Для технического специалиста это такой же навык, как и умение работать с системой.
Проектное мышление: видеть путь от задачи до результата
Для инженеров, архитекторов, аналитиков и технических руководителей это особенно значимо, потому что большая часть их деятельности строится вокруг проектов разной сложности и длительности. Проектное мышление помогает специалисту видеть не только свою часть работы, но и весь маршрут: что должно быть на входе, какие этапы предстоит пройти, где возможны риски, кто влияет на результат, какие сроки реалистичны, какие договоренности нужно зафиксировать заранее. Это сильно повышает качество работы, потому что специалист начинает мыслить не отдельной задачей, а конечным эффектом.
В IT-сфере это критично. Один проект может быть коротким и понятным, другой – длинным, многоуровневым, с большим количеством участников и зависимостей. И если технический эксперт умеет управлять только своим участком, но не видит общей логики, команде сложнее удерживать сроки, качество и ожидания заказчика.
Здесь обучение должно быть привязано к роли, специалист технической поддержки больше взаимодействует с клиентом напрямую, поэтому для него особенно важны коммуникация, клиентский сервис, стрессоустойчивость, способность быстро разбираться в запросе. Инженер или архитектор, который участвует в проектировании инфраструктуры, должен дополнительно понимать этапность проекта, зависимость решений, логику согласований, управление рисками. Руководителю технической команды нужен следующий уровень – управление людьми.
Когда специалист становится руководителем, уровень сложности резко меняется. Раньше он отвечал в первую очередь за себя и свои задачи, теперь нужно управлять людьми, мотивацией, развитием, конфликтами, ожиданиями и командной динамикой. Это отдельная профессия внутри профессии, техническая глубина помогает руководителю быть авторитетным, но не заменяет управленческие навыки. Нужно понимать цикл менеджмента, основы ситуационного лидерства, разные стили управления и как они связаны с уровнем зрелости сотрудников. Одному человеку нужна подробная постановка задачи и сопровождение, другому больше автономии, третьему – помощь в мотивации, четвертому – честная обратная связь.
Для IT-команд это особенно важно, потому что специалисты часто ценят профессиональную свободу, уважение к экспертизе и честный диалог. Управлять такой командой директивно и одинаково для всех невозможно, руководитель должен видеть, кто на каком этапе находится, кому нужно дать больше поддержки, кому – больше ответственности, а где важно вовремя заметить выгорание или потерю вовлеченности. Поэтому управленческое обучение для IT-специалистов должно включать не только планирование и контроль, но и мотивацию, принятие решений, управленческое влияние, построение эффективной команды, развитие сотрудников и работу с обратной связью.
Обучение работе с искусственным интеллектом
Здесь важно разделять несколько направлений:
- Базовая ИИ-грамотность для сотрудников. Людям нужно понимать, что это за инструменты, как их можно применять в ежедневной работе, какие задачи они помогают ускорять, где дают хороший эффект, а где требуют осторожности. Для этого проводятся обучающие марафоны и дистанционные курсы, где сотрудники могут разобраться с темой на практическом уровне.
- ИИ как решение для бизнеса. Здесь обучение требуется тем, кто продает, проектирует, внедряет и сопровождает такие решения: аккаунт-менеджерам, инженерам, архитекторам, проектным командам. Им важно понимать, какие бизнес-задачи решает ИИ, как технология встраивается в процессы клиента, какую ценность создает, какие ограничения имеет и как объяснять это заказчику.
- Использование ИИ внутри собственных процессов. Это уже про зрелость организации: где ИИ может помочь в оценке, обучении, создании курсов, анализе данных, подготовке материалов, оптимизации повторяющихся операций. Здесь компании во многом идут через исследование, тестирование и постепенное внедрение, потому что тема быстро развивается.
Главное, не воспринимать ИИ как магическую кнопку. Технология дает колоссальный доступ к информации, помогает в глубоких исследованиях, ускоряет подготовку материалов, может быть рабочим помощником и даже агентом под конкретные задачи. Но специалисту нужно уметь ставить задачи, проверять результат, критически осмыслять выводы, адаптировать их под контекст и не передавать машине ответственность за профессиональное суждение. В этом смысле критическое мышление становится ключевым навыком – чем больше возможностей дают инструменты, тем выше цена некритичного использования их результатов.
Сохранится ли роль наставника с развитием ИИ?
У ИИ-агента можно спросить почти все – от технической справки до структуры документа или объяснения новой темы. Я считаю, что роль наставника сохранится. Нейросети действительно помогают новичку быстрее ориентироваться в общей информации, объясняют термины, подсказывают подходы, структурируют знания. Но внутри каждой компании есть свои правила, контекст, неписаные договоренности, особенности взаимодействия, история решений, культура коммуникации. Это невозможно полноценно передать через внешнюю базу данных.
Наставник помогает человеку понять не только «как правильно по инструкции», но и «как это устроено именно у нас». Где нужно заранее согласовать позицию, к кому прийти за экспертизой, почему в этой команде принято действовать именно так, какие нюансы важны для клиента, где в процессе есть тонкое место. Такие знания передаются через живой опыт. Поэтому наставничество не конкурирует с ИИ, скорее, они могут усиливать друг друга: ИИ помогает быстрее освоить базовый слой информации, а наставник помогает встроиться в реальную профессиональную среду.
Стрессоустойчивость и работа с изменениями как часть профессии
Темы эмоционального интеллекта, экологичной коммуникации – это не просто личное развитие, но и напрямую влияют на рабочую эффективность. IT-рынок живет в постоянной турбулентности. Меняются технологии, клиентские запросы, экономическая ситуация, подходы к найму, внутренние процессы. На человека давит неопределенность, высокая скорость, необходимость быстро перестраиваться. В таком состоянии растет риск ошибок, падает вовлеченность, снижается продуктивность, а накопленный стресс может привести к выгоранию.
Поэтому специалистов и руководителей нужно учить замечать свое состояние, управлять стрессом, жить в изменениях, сохранять работоспособность в периоды неопределенности. Руководителям особенно важно уметь видеть признаки выгорания у сотрудников: если человек долго работает на пределе, усталость неизбежно начинает влиять на качество решений, коммуникацию и отношение к работе. Эмоциональная устойчивость – это не про «быть всегда спокойным». Это про способность не разрушаться под давлением, восстанавливаться, осознавать свои реакции, не переносить стресс на команду и принимать точные решения, даже когда вокруг много неопределенности.
Кроме того, один из рисков для опытного специалиста – замкнуться в собственной экспертизе. Чем дольше человек работает, тем больше у него оснований считать, что он уже многое видел, многое знает и его сложно удивить. Опыт действительно дает устойчивость, но иногда мешает увидеть новое. Для профессионального роста важно сохранять способность «обнуляться». Заходить в знакомую тему с установкой: возможно, здесь есть смысл, который я раньше не видел. Это не отказ от опыта, а умение временно отодвинуть привычные выводы и посмотреть на ситуацию свежим взглядом.
Я часто думаю об этом через аналогию с книгой. Один и тот же роман, прочитанный в школе и во взрослом возрасте, воспринимается совершенно по-разному. Текст тот же, автор тот же, но меняется сам читатель, его опыт, вопросы, зрелость. Так же и в профессии: иногда старая тема открывается иначе, потому что человек дорос до нового уровня понимания. Для IT-специалиста это особенно важно, технологии меняются быстро, подходы обновляются, привычные решения перестают быть единственно верными. Умение сделать шаг назад, переосмыслить свой опыт и заново увидеть задачу – это важная часть профессиональной гибкости.
Языки как доступ к другой технологической культуре
Английский по-прежнему остается важным языком профессиональной коммуникации в IT-отрасли. Но интерес к китайскому языку тоже понятен: Китай играет огромную роль в развитии высоких технологий, искусственного интеллекта, оборудования, инженерных решений.
Мое личное мнение: знание языков всегда расширяет возможности. Если страна занимает важное место в технологической повестке, то знание ее языка дает более глубокий доступ к обучению, переговорам, профессиональной среде, культуре принятия решений. Можно работать через перевод, но оригинальный язык помогает понять больше – не только слова, но и контекст. Для IT-специалиста это может стать дополнительным конкурентным преимуществом, особенно, если человек видит для себя интерес в международных проектах, обучении, технологическом обмене или работе с иностранными рынками.
Профессиональная зрелость – это тоже результат обучения
Обучение техническому стеку – это фундамент. Но поверх технологий выстраивается более сложная профессиональная конструкция: коммуникация, проектное мышление, клиентский сервис, управленческие навыки, ИИ-грамотность, критическое мышление, стрессоустойчивость, способность учиться и переучиваться. Компании, которые это понимают, получают более зрелые команды. Такие специалисты лучше слышат клиента, быстрее адаптируются, качественнее работают в проектах, спокойнее проходят через изменения и могут расти в разных траекториях: как глубокие эксперты, как проектные лидеры, как руководители команд, как специалисты на стыке технологий и бизнеса.
В IT-сфере важны сильные профессионалы, но сила специалиста измеряется не только тем, насколько хорошо он знает технологию, но и тем, насколько осознанно он умеет применять ее в реальной работе – с коллегами, процессами, клиентами, рисками и постоянными изменениями.
Учить конкретным технологиям или способности переучиваться?
Важны оба направления. Нельзя отказаться от обучения конкретным технологиям, потому что есть проекты, задачи, системы, решения, требующие глубокой специализированной экспертизы. Сертификации, узкие технические навыки, погружение в конкретную платформу или инструмент никуда не исчезают. Но стратегически ценится способность быстро переучиваться. Технологии развиваются стремительно, и специалисту важно уметь перестраиваться, осваивать новое, включать его в свою работу и не теряться каждый раз, когда привычная схема меняется.
Для кого-то гибкость естественна: такие люди легко пробуют новое и быстро переключаются. Кому-то, особенно людям основательным, привыкшим все планировать и продумывать, перестройка дается сложнее. Но это тоже навык, который можно развивать. Через обучение, практику, работу с изменениями, новые проекты и постепенное расширение профессионального поля.
Будущее за специалистами, которые умеют сочетать глубину и гибкость. Быть сильными в своей области, но не превращать эту область в закрытую комнату. Осваивать конкретные технологии, но понимать, что через год или два снова придется учиться.
Индивидуальный трек важнее универсального списка курсов
У нас в компании мы выстраиваем обучение через связку оценки, обратной связи и индивидуального плана развития. Для нас годовая оценка – не просто формальная процедура и не только рейтинг эффективности, главное, чтобы сотрудник получил качественную обратную связь от руководителя, увидел свои сильные стороны и зоны роста, а затем смог составить понятный и прицельный план развития. После этого обучение становится осознанным. Человек выбирает не случайный курс из общего каталога, а то, что действительно помогает ему в задачах. Внутри компании есть программы по личной эффективности, коммуникации, презентации, аргументации, типологиям личности, проектному управлению на базовом и продвинутом уровне. Для руководителей доступны модули по управленческому мастерству.
Такой подход важен еще и потому, что IT-специалисты разные, кто-то лучше учится в группе, через тренинг, обсуждение и практику, кому-то комфортнее начинать с самостоятельного дистанционного обучения, особенно, если человек привык глубоко погружаться в материал индивидуально. Поэтому важны и очные форматы, и онлайн-платформа, где можно закреплять навыки после тренинга или осваивать нужные темы в своем темпе.
Для обучения взрослых людей это принципиально: развитие работает лучше, когда человек понимает, зачем ему конкретный навык, как он связан с его задачами и где он сможет применить его уже завтра.
Также читайте:
Анжелла взяла очень сложную тему.
И ей удалось широко описать проблемы обучения айтишнмков. Я бы согласился со всем, может только сомнения у меня есть относительно обучению навыками стрессоустойчивости, навыками общения. Они безусловно нужны, но научить этому вряд ли возможно.
Повторюсь, тема очень непростая. Все нынче согласны, что нужно учить и обучаться. А вот потом идет рассогласование: чему учить, как учить, где учить. Уже бывает, что ставится под сомнение необходимость высшего образования. Возникла потребность в коротких навыках. Спорим и дискутируем.
Я когда-то работал завучем в ИТ-школе. Имею некторое представление о сожностях образования, в последствии даже имел собственных бизнес в этом направлении.
Мне кажется, что надо как-то стимулировать и мотивировать айтишников к самообразованию, или к переобучению. Увы, программирование рано, или поздно обрывается. Я знаю всего нескольтко человек, которые к концу рабочего срока занимались бы программированием. Люди очень устают от этого. Но знаю большое количество айтишников, которые плавно перешли к другим специальностям и профессиям.
И несомненно поддерживаю точку зрения Анжеллы на обучение языкам. Это универсальный способ образования, на мой взгляд.
И прошу прощения за фантастику. Молодые парни боятся военной службы. Не буду спорить на эту тему, но я бы ввел некие курсы на выживаемость для молодых ребят. Ну чего соплями лицо портить? Нужно развивать естесственную потребность молодых к риску и приключениям. А пройдя такой экстремальный курс, они будут легче находить свое место.
И я бы просто призвал не забывать, в какое время живет наша страна. Молодые мозги очень нужны нам. Некоторые дисциплины, например тактическая медицина очень нужны.
Статья написана живым, убедительным языком, затрагивает важные темы и содержит ряд справедливых наблюдений. Однако за внешней правильностью рассуждений скрывается системная управленческая проблема, которую я, как Ген дир. с многолетним стаже, не могу оставить без внимания.
1. Что в статье верно и полезно
Автор справедливо отмечает, что IT-специалисту сегодня недостаточно одного технического стека. Коммуникация, проектное мышление, управленческие навыки, стрессоустойчивость — это действительно важные компетенции. Также верно, что наставничество не заменяется ИИ, а языки (особенно китайский) открывают доступ к другим технологическим культурам.
Эти тезисы не вызывают возражений. Более того, они давно известны и успешно внедряются в зрелых компаниях.
2. Где начинается подменять понятия
Проблема начинается в разделе, посвящённом ИИ. Автор пишет о трёх направлениях обучения, и в каждом из них HR-департаменту отводится роль, которая ему не принадлежит:
Базовая ИИ-грамотность для всех сотрудников — здесь HR выступает как организатор курсов. Это допустимо, но при условии, что содержание программы утверждает ИТ-директор. Без этого HR будет учить людей «пользоваться ChatGPT» в отрыве от реальных бизнес-задач и технических ограничений компании.
ИИ как решение для бизнеса — автор утверждает, что обучение требуется аккаунт-менеджерам, инженерам, архитекторам. Но кто определяет, чему именно их учить? Кто формулирует требования к компетенциям? Очевидно, что это должен делать технический руководитель, а никак не HR.
Использование ИИ внутри собственных процессов — здесь речь идёт о том, что HR-служба сама использует ИИ для оценки, обучения, анализа. Это внутренняя автоматизация HR, и если этим HR компетентны заниматься сами по себе, то почему не заменять табличку "HR отдел", на "Отдел Гуру".
Автор нигде не говорит, что ответственным за внедрение ИИ является ИТ-директор. Напротив, она создаёт впечатление, что HR-департамент сам определяет, каких экспертов привлекать, какие программы запускать и для каких специалистов.
3. Управленческая ошибка автора
Главная ошибка — отсутствие чёткого разделения зон ответственности.
В нормальной управленческой модели:
В статье эти границы стёрты. Автор предлагает, чтобы HR не только организовывал, но и содержательно управлял обучением работе с ИИ. Это означает, что HR будет решать:
какие компетенции нужны IT-специалистам;
какие внешние эксперты достаточно компетентны;
какие курсы и инструменты выбрать.
Но HR не обладает для этого ни техническим образованием, ни практическим опытом, ни пониманием реальных проектных задач. Он не может отличить хорошего архитектора от плохого, не может оценить, действительно ли предложенное решение соответствует нашей инфраструктуре.
Итог: мы получаем ситуацию, когда HR-директор метит в «гуру ИИ», а ИТ-директор превращается в того, кто «потом разберётся, что он сделал не так, если у нас не получилось». Такое внедрение ИИ всегда будет провалено, а бюджет списан на "ну мы же пытались. ИТ поставило нам не то ИИ".
4. Это не просто ошибка, а «перетягивание одеяла»
Статья написана HR-директором и явно лоббирует интересы именно этой службы. Если HR отвечает за обучение работе с ИИ, он получает:
бюджет на привлечение экспертов;
контроль над программами обучения;
статус «драйвера цифровизации»;
влияние на технологическую политику компании.
При этом реальная ответственность за результат — за работоспособность ИИ-решений, за их безопасность, за интеграцию — остаётся на ИТ-директоре, но рычаги управления оказываются у HR. Это классический пример размывания ответственности: один распоряжается ресурсами, другой отвечает почему деньги не сработали.
Такая ситуация создаёт конфликт между отделами, снижает эффективность и ведёт к бардаку внутри крмпании.
5. Как надо было правильно
Если бы автор действительно хотела помочь, ей надо было написать:
Тогда статья была бы полезной и не вызывала бы такого управленческого негатива у меня лично.
Мой вывод
Статья — управленчески вредная. Она дезориентирует ответственность, создавая базовый конфликт между отделами, пытаясь делегировать HR-департаменту полномочия, которых у них нет и быть не может.
Как правильно:
Чётко зафиксировать, что внедрение ИИ и любое техническое обучение, связанное с ИИ, находится в зоне ответственности ИТ-директора.
Обьянить HR-департаменту, ччто их роль - организационная поддержка (бюджетирование, логистика, контроль прохождения курсов), но никак не вмешательства в содержание программ.
Провести с ИТ-директором отдельный разговор о том, почему он допускает, что HR присваивает себе его функции, и потребовать разработки чёткой стратегии по внедрению ИИ. Внедрение ИИ — это технологическая задача. Ею должны заниматься технологи, а не кадровики.
P.S. Автору статьи я бы рекомендовал чётко разделять, чем начинаются и где заканчиваются функции разных отделов: HR и IT, маркетинг и менеджмент, люди и ИИ.
Вы правильно пишете, Борис, я бы только учитывал бы реальные интересы участников бизнеса, а не только всего бизнеса, если о таких можно вообще говорить.
Вполне естественно, что статья написана исходя из интересов HR, а не ИТ.
Просто ИИ сейчас новая тема, и все пытаются отхватить от нее свой кусочек.
Так должно быть.
А ИТ-директор и выше пусть не зевают, если не хотят проблем.
Так она и хочет помочь, себе и своему отделу.
Всё новое несет в себе элементы вреда и пользы.
Да, статья продвигает свои интересы, а не ИТ.
А ИТ пусть не дремлет, хотя думаю, что это ненадолго, скоро они проснутся, как только увидят результаты обучения ИИ.
Статья достойная для прочтения и размышления, спасибо автору. Согласен, что в материале наблюдаются перекосы в границах ответственности, кто и за что отвечает. Борис Яровой выше по полочкам разложил этот аспект.
Но я хотел бы несколько фокус дискуссии сместить. Почему последние годы тема про айтишников такая животрепещущая, что их надо и технологиям учить и коммуникациям и стресс выдерживать.
А если я строитель, а если работник РЖД, или нефтяник на буровой, или продавец в магазине. Мне тогда не надо всему выше перечисленному обучаться и в указанных направлениях развиваться ?
А может такой крен в сторону ИТ с другим связан ? Попробую свою гипотезу предположить. Сильнейшая (иногда катастрофическая) зависимость от совместной деятельности всей команды, которая выполняет работу. Совместной не только в том, чтобы коммуницировать уметь, а в том, чтобы при коммуникации правильно мэппить бизнес-смыслы в технические, системные задачи. Отсюда и требования, чтобы РП обладал техническими скилами в определённом (очень относительный термин) объёме и требование к разработчику понимать бизнес-функционал. А когда у вас множество сервисов, множество БД, тысячи атрибутов, то на всё это написать проектную документацию заранее невозможно.
Если у вас подключение электричества к внешнему узлу снабжения делается, то у вас прописана граница разделения, никто не подключит вас к электричеству - пока не подпишут все бумаги. В программном обеспечении может быть десятки и сотни подключений к внутренним и сторонним информационным ресурсам, без которых ваше решение будет красивым набором визуальных форм. И чтобы решить такие проблемные вопросы ВСЯ команда вынуждена ежедневно собираться, обсуждать вчерашние изменения, решать вопросы, связанные с изменениями требований от бизнеса, которые в начальном договоре и прописаны не были.
И вопрос обучения в ИТ, на мой взгляд, лежит в управленческой плоскости, умении управлять отношениями между Заказчиком и Исполнителем, в слаживании совместной работы команды, руководства от Исполнителя, ЛПР от Заказчика. И как опыт показывает, изменения в составе всей группы товарищей (даже одного технаря) может кардинально изменить и темпы работы и её результаты.
А ИИ на сегодня дополнительная технология, которая всем нам в помощь.
А по мне все перечисленные автором аспекты - все "одного поля ягодки" не выходящие за традиционный контур IT-подготовки, никак не затрагивающие область прикладных знаний об объекте и применяемых им методах управления/решения задач для сотрудников-IT отрасли.
Проблемы предприятий, с которыми я (как преподаватель ВШЭ факультета "Бизнес-информатика" и консультант в области бизнес-эффективности производственных компаний) сталкиваюсь вызваны не стрессонеустойчивостью, коммуникативностью или слабыми навыками программирования у IT-сотрудников, а их тотальной некомпетентностью в прикладной отрасли, для которой они разрабатывают решения, которые ведут к автоматизации, цифровизации и интеллектуализации "хаоса"(((
Для примера, посмотрите какой профиль компетенций нужен разработчикам решений для управления холдингами и предприятиями в головную компанию 1С.ru:
Вы не увидите в этом списке требований к прикладным знаниям в области производства, таких как: знания об организации производства и логистики, о подходах к управлению производственной компании и цепях поставок, задачах эффективной постановки новых изделий на производство, управлению качеством на основе предупреждения несоответствий, подходах к вытягивающему планированию и т.п. Только IT-профтрек программиста и знания устройства платформы 1С. И чего, кроме автоматизации хаоса могут предложить такие разработчики!? И зачем тогда искренне удивляться, что 1C.ERP от слова совсем "не дружит" с теми инструментами и моделями, которые предприятия применяют "на полу". И поднятием коммуникативности или стрессоустойчивости эту проблему, увы, не решить...
Спасибо за то, что подняли тему: релевантность профессиональных знаний, умений, навыков, опыта работников к требованиям бизнеса.
1. Требования к софт-скиллам: коммуникации, стрессоустойчивость, проектное мышление, - все эти требования относятся не только к работникам IT.
Со стороны работодателя также следует исследовать различные методы и практики управления персоналом, чтобы не проверять своих работников на гибкость и стрессоустойчивость, при этом внедрять наставничество, уважительное отношение к труду каждого, т.д.
2. Касательно хард-скиллов дополню к тому, что уже прокомментировали.
1) В статье указано: "Для профессионального роста важно сохранять способность «обнуляться»".
Со своей профессиональной точки зрения, могу подтвердить, что в бизнесе также нужно применять этот подход для роста и развития: внедрять ZBB (бюджетирование с нуля), - каждая бюджетная статья по каждому ЦФО подтверждается отдельно, как будто рассматриваемая деятельность только началась.
Такой подход, в отличие от инкрементального бюджетирования, не учитывает "бывшие заслуги и/или неудачи" каждого из подразделений, а также не позволяет неоптимальным и непроизводственным расходам проникать в бюджет.
Это подчеркивает, что рост должен быть с обеих сторон: как работников, так и работодателя.
2) Перманентное обучение специалистов.
Несомненно, правильный подход, что работники должны заниматься самообразованием: "учиться, учиться, и ещё раз, учиться!".
Однако со стороны организации также необходимо находить возможности для повышения квалификации работников (бюджет, учебные отпуска, подбор курсов/программ под необходимые компетенции).
Здесь, хочу ещё раз подчеркнуть, что выбор программ обучения, повышения уровня технических компетенций должен быть инициирован или, минимум, согласован с руководителем ответственного подразделения.
Например, как указано, что IT и прочие специалисты организации должны обучаться технологиям, которые выходят за рамки известных решений (например, ИИ).
В этом случае следует обратиться к штатному CIO, а готов ли он развернуть эти технические решения, поддерживать их и защищать этот контур?
Есть ли необходимость найма CISO и рассмотреть вариант возможности у бизнеса расширения бюджета IT/IB-инфраструктуры ещё и на дополнительную киберустойчивость модных технологий?
Вот именно по этой причине и приходится "всей толпой" каждый день на дэйли собираться, чтобы как говориться "всем одновременно за кий держаться", чтобы шар в лузу закатить. Тут даже в таких случаях люди умудряются слушать одно и тоже, а слышать разное.
А в требованиях, не зря же первой строкой идёт "не менее 3 лет практической работы". Делается предположение, что специалист получил какой-то практический опыт, решая конкретные задачи. И при приёме, конечно же пытаются выяснить этот опыт. Но конкретные задачи вроде называются одинаково, а внутри столько маленьких логических ответвлений, что не всегда покрывает предполагаемые функциональные требования.
Именно по этим причинам и выдвигаются требования к указанным софт-скилам. Деятельность, особенно в проектной, в отличии от регулярной, каждый день приносит сюрпризы, возникает множество неопределённостей, которые приходится решать здесь и сейчас. И к таким ситуациям психологически нужно быть готовым, быстро реагировать, перегруппировываться, менять вчерашнее решение на сегодняшнее, чтобы закрыть вопрос.
Но это же не только для ИТ-специализации.
Проблема только в том, что 1С.ERPlanning - это набор жестких шаблонов (давно утративших адекватность) и 3х летний опыт ее внедрения - это опыт "танцев с бубнами" по впихиванию процессов предприятия в прокрустово ложе шаблонов ERPlanning = автоматизация хаоса. Т.е. это не компетенция для разработки нового решения в замен морально устаревшей ERPlanning, а опыт применения "негодного конструктора" для решения задач предприятия(((
Ниже процетирую свой избыточно эмоциональный пост на ХАБРе, чтобы аргументировать свою мысль:
Согласен, но ведь процесс двухсторонний. Исполнитель "впихивает", потому что сроки и бюджет. Заказчик делает вид или не понимает, что решения готового нет. И для начала нужна НИР даже для того, чтобы варианты моделей прогнать и понять, что "взлетит". Но ведь договр заключается сразу на конечный вариант и с твёрдой ценой.
Это ещё один аспект, почему тема про развитие софт скилов муссируется вокруг айтишников. Опять же, моя гипотеза. Потому что ценность применения ИТ-решений действительно есть. Они существенно повышают конкурентоспособность предприятий. В ИТ самая ценная вещь - это ПО, вещь нематериальная. Бизнесу кажется, что там поменять любую часть, пару дней. Это же не фундамент заливать. Но люди от ИТ знают, что результат становится достижимым при одном существенном требовании. Сначала спроектировать на предприятии изменения в бизнес-процессах. Причём рамки, состав и структура изменения зависит от планируемого ИТ-решения.
Бизнес договорился, а ИТ не справился.
Конечно, вроде бы Заказчик должен заказывать "музыку", но вот моя мрачная оценка работы IT отрасли, которую я наблюдаю:
(1) у Заказчика дефакто нет выбора. Он выбирает вендора, но выбрав его он попадает на готовый образ результата "по мотивам шаблонов ERPlanning" из которого ему не вырваться. И это формат, который навязывает ему Исполнитель (вы купили шаблоны, я всего лишь проведу их адаптацию за такое-то время).
(2) Инструментарием ERPlanning реализовать реагирование не возможно (это из области "квадратное катить"). Это функционал и логики которых в предлагаемых решениях нет (чтобы их реализовать, нужно переделывать всю систему, а на это Исполнитель не подписывался).
(3) Заказчик не очень компетентен в постановке IT-задачи, т.к. проектирование ведется на "птичьем языке" программистов (нотации IDEFx, BPMN), а не на прикладном языке Заказчика. Как представителям Заказчика разобраться в этих кодах "на ассемблере"!? Поэтому современные IT проекты управления предприятиями/холдингами - это разговоры слепого с глухим.
(4) Процесс адаптации шаблонов ведется методом лоскутной оптимизации: бизнес-аналитики Исполнителя ответственны за адаптацию своего функционального шаблона, которую осуществляют методом интервью: "А по ночам у меня лапы ноют и хвост отваливается"((( За эффективность системы НИКТО не отвечает, т.к. она якобы заложена шаблонами. Т.е проектирование системы дефакто НЕ ПРЕДЛАГАЕТСЯ.
Все это и вырождается в системно воспроизводимый результат "автоматизации хаоса". И оценка такого применения IT решений, как "действительно ценный" - это большое преувеличение.
До тех пор, пока IT отрасль при проектировании решений для управления предприятиями, холдингами, цепями поставок не начнет глубоко изучать прикладной инструментарий/знания Заказчика, не будет переходить на его язык (не перейдет с ассемблера на объектно-ориентированное программирование), при котором Заказчик без программистов сможет проектировать свои КИС, пользы ждать не разумно.
А сейчас IT отрасль цинично успешно перепродает "прошлогодний снег" и никакого диктата со стороны Заказчика, увы, нет и в помине! Дефакто IT исполнитель не отвечает за результат (он отвечает только за внедрение)
Вот еще один мой пост с ХАБРа на эту тему: