Первый момент. Стоимость принятия решения, риски принятия решения, стоимость владения решением, вопросы на которые реальный управленец отвечает на автомате при любой задаче, время обдумывания ответа может отличаться от сложности задачи.
Второй момент - согласования, вытекает из первого, если согласование элементарной вещи занимает дни/недели, то какую методологию не бери тут проблема в качестве менеджмента, а не методологии.
Третий момент - процессы никак не отменяют результат, если в описании процесса нет результата, так не процесс плох, а формализован он плохо.
Четвертый момент - делегирование, у части менеджеров с этим все плохо, как следствие они занимаются не эффективной деятельностью, например сами делают отчеты на каждый пчих. Проблема в процессах/PM book - нет, проблема в когнитивных способностях конкретного персонажа и понимании на каком участке процесса должны быть отчеты.
Пятый момент - распределение времени. Если взять к примеру разработку ПО, то на сам кодинг должно уходить не более 20% времени, тестирование 50%, документация (включая как раз те самые отчеты) 30%, тогда все будет работать с хорошими финансовыми показателями.
Шестой момент. Я видел кучу формализованных систем в которых отсутствовала финансовая составляющая, как следствие результат плачевен. Я когда ставлю задачу всегда понимаю, сколько стоит ее выполнение, а не просто тут задача "Петру" на 5 часов. Если у "Петра" стоимость часа работы 20 000 рублей, то грузить его всякой фигней это риск получить в лоб от финансового департамента за нерациональное расходование бюджета, однако подобный подход в реальном времени наблюдается не часто на рынке.
1 разработчик не умеет писать нормальную техническую документацию;
2 не может написать ЧТЗ на подсистему/сервис.
На мой взгляд ИИ для него бесполезен.
Возможный выход - обучение разработчика данным скилам, либо предоставление компаньона который обучит ИИ, выдаст четкие инструкции по работе и проведет декомпозицию задач. Второй подход вызывает сомнения в свое экономической целесообразности.
Часть вторая. Менеджмент.
Для внедрения ИИ PM должен понять тактическую и стратегическую цену внедрения подобного решения именно в вашей компании. Проведите простой эксперимент в своих командах:
1 возьмите понятную задачу по уже известным технологиям сроком на 2-6 месяцев;
2 задайте вопрос PM - во сколько обойдется компании стоимость внедрения данного решения и каков процент ошибки прогноза;
3 проанализируйте ответ.
Мой опыт говорит, что процент PM которые в состоянии говорить на языке денег и рисков крайне мал при уже освоенных технологиях, что говорить про новые? Хотя возможно в ваших командах иначе.
Часть третья. Резюме.
Из всего выше сказанного получаем:
1 часть разработчиков не обладают навыками для внедрения ИИ;
2 часть менеджмента не умеет в финансы, что тоже не позволит эффективно внедрить ИИ;
3 до внедрения ИИ необходимо запустить проект по подготовке персонала, если хотеть прогнозируемые затраты и результат.
4 для подготовки персонала по работе с ИИ необходимо обеспечить данный проект ресурсами, что на рынке пока наблюдается крайне редко.
Вначале на среднюю позицию устраивают аттракцион из 5 собеседований с дельтой неделя - две, потом еще СБ и полиграф, а потом работодатель берет 2 недели на обдумывание. Зачем? Я бы понял, если бы искали гуру и обсуждался контакт на 10 лет, но у вас же испытательный срок и срочные контракты. Загадка.
Часть вторая. Запросы по профессиональной деятельности.
Работодатель хочет полную информацию о твоих проектах, чуть ли не с пеленок, какой практический смысл в информации о проекте 30 летней давности, может кто подскажет? Ну разворачивал я почтовый сервак на фрибсд в 1995 и он даже проработал 10 лет из которых 7 лет без обслуживания, толку от этого скила, я подобной работой очень давно не занимаюсь и очевидно, что навыки не актуальны, да и с текущей профессиональной деятельностью эти скилы никак не связаны.
Часть третья. Тестирование.
Тестирование, что в общем виде само по себе не плохо, если бы относилось к рассматриваемой позиции и имело вменяемые условия.
Пример 1. Исходные данные:
Обсуждается позиция PM в системном интеграторе, интегратор занимается розницей, проекты связаны с разработкой софта для розницы.
Тестовое задание на собеседовании: нарисовать алгоритм работы аппаратного спектрального анализатора сигналов сети 10Gbit и предложить его программную реализацию, так и не придумал, где компания может применить эти навыки. Время на выполнение 15 минут.
Пример 2. Исходные данные:
Фулстек аналитик, компания разрабатывает СЭД.
Тестовое задание: подготовить полный комплект проектной документации на Систему в полном соответствии с ГОСТ 34, готовый к гос. приемке, в качестве исходных данных аккаунт к тестовому стенду и контракт 5 летней давности на разработку, время разработки 3 дня.
Пример 3. Исходные данные:
Должность бизнес-аналитик, компания разрабатывает решения для логистики.
Тестовое задание: есть старая система, использующая MS SQL 2012 и сервак на Xeon E5, задача необходимо математически просчитать ускорение работы базы с погрешностью не более 1,5% при переходе на Xeon Platinum 8480 и Postgre Pro 14 Enterprise, больше данных нет, построить модель в Матлабе и провести презентацию результата расчета. Время на решение задачи 2 часа. Позиционировался, как типичный пример постановки задачи в данной компании.
Часть четвертая. Заключительная.
Таких прекрасных примеров я могу еще пару десятков привести, как вы думаете, как вы думаете к чему, описанный выше, подход при найме приведет. Вот я думаю, как раз к потоку тех самых шулеров.
Ремарка: Нет четкой постановки задачи, нет точной оценки.
Вы начали писать статью очень размыто указав как вы формировали запрос на рынок. Не понимая запроса оценить ваши рассуждения сложно. Текст вакансии это даже не ТЗ, а готовое коммерческое предложение, зная его можно сделать прогноз, кто к вам пойдет.
Предположим, что вы искали Seniora и ваша вакансия сформулирована адекватно, а компания белая и пушистая, при этом вы получили описываемые результат.
Это означает только одно - на ваше предложение специалистов нет. Из этого следует, что либо нужно менять предложение, либо закрывать позицию, либо растить собственных специалистов.
Возник вопрос, как отслеживается связность изменений и требований в документах?
Например, в моей работе изменения ЭД, которые отражают реальные текущие технические параметры АИС с точки зрения техники порой не сложны, уточнили две таблицы, поменяли абзац текста, это взгляд технаря.
Однако, если эти изменения сделать без учета требований в коммерческой и проектной документации, то результат может быть весьма плачевен. Для того, что внести изменения корректно - нужно четко представлять насколько внесение этих изменений не противоречит требования текущих Контрактов/ТЗ/ЧТЗ, а также не нарушает требования предыдущих контрактов на АИС. Ретроспектива документации 7 лет, причем одна и та же формулировка с точки зрения техники, изложенная разным стилем может вызывать разные последствия.
Это я еще не касался изменения ТУ, где соответствие нормативно-правовой документации раскрывается во всей красе и технически корректное изменение, но нарушающее ФЗ может привести к знакомству с тов. прокурором, со всеми вытекающими последствиями.
А можно взять себе workstation на б/у хеоn и получить и железку для Devops/виртуализации/прочего и вполне рабочую лошадку для программирования. А по цене макбука можно взять уже Epic). Причем предложенные решения позволяют создавать различные рабочие конфигурации для тестирования софта и понимания узких мест.
Навскидку не только в диски упирается-) В случае софтрейда контроллер шины PCI-е+контроллер дисков+ контроллер самого диска, а также их взаимодействие друг с другом, в случае хард рейда еще добавляется контроллер хардрейда. Это если рассматривать цепочку с середины цикла записи/чтения в рамках одного сервера. SMART для анализа не сильно поможет, он покажет только битый/не битый диск, если грубо, поведение контроллера конкретного диска при больших нагрузках он не покажет. Что происходит на уровне шины PCI-e тоже науке не известно. Это очень грубо на уровне железа, считаем что софт идеальный и багов в нем нет. Как показывает практика с серверами Supermicro 10 одинаковых серверов, вот реально все потроха одной ревизии, отличаются только неделями выпуска, ведут себя по разному при больших нагрузках.
Если на входе в заведение сидит идиот, то это может означать - тест на сообразительность (сообразительность инженеру постоянно нужна), либо что в данном заведении с процессами все плохо, а зачем балаган на работе, все-таки клоун и инженер это разные специализации.
Халява это молоко, которое в шаббат скиснет, поэтому его раздают бедным-))) Теперь по сути, краткое резюме для технарей, кто был инженером без работы не останется, кто был узким специалистом того может постичь печальная участь. Собственно все последствия ИИ при условии, что он таки будет развиваться. Если ИИ не будет развиваться, то все останется по прежнему.
Мне вот всегда было интересно, как вы простои по вине Заказчика будете считать, банальная итерационная задача, где с точки зрения Заказчика два состояния - задача поставлена/задача решена, а с точки зрения программиста это будет 10-15 итераций, по простой причине - Заказчик не в состоянии сразу сформулировать все требования и выдает корректировки в n шагов, причем не смотря на жесткий временной регламент на время реакции, регулярно завышает сроки ответа на уточняющую информацию. Дальше имеем побочные артефакты, как время переключения с другой задачи со стороны программиста при получении очередного уточнения от Заказчика, это я еще не упоминал в этой цепочке парочки аналитиков и ПМ. В результате данные, которые выдаст лобовой трекер фиксации времени, будут также полезны, как потолочные данные. Фиксация времени имеет смысл для решения типовых операций с заранее прогнозируемым лимитом на их решение, только для таких операций и системы не нужны, если менеджер в состоянии в уме 17 на 15 умножить-))
В заголовке статьи и дальнейшем ее изложении, на мой взгляд, есть сбой в логике. Если мне нужен кодер от забора до обеда, одни требования и там, возможно курсов хватит для джуна, если мне нужен разработчик другие, если мне нужен разработчик с базовыми знаниями аналитика третьи и так далее.
По теме -я считаю, что высшее образование для разработчика должно быть, причем классическое, которое включает в себя гуманитарные предметы, в том числе. Вспоминая свой технический ВУЗ, по прошествии многих лет, могу сказать, что лишних предметов не было, хотя когда учился, казалось вот на зачем мне промышленное право или философия, к примеру. Другое дело, что вопрос в том, что хочет человек срубить сиюминутно копейку по быстрому или получить профессию, которая будет его кормить всю жизнь, если первое, то ИТ ему в принципе не нужно, есть масса тем, где деньги получаются быстрее и дешевле.
Театр начинается с вешалки, а специалист по подбору персонала с представления. На моей памяти за 25 лет работы в ИТ было 3 специалиста, которые выдали на старте кейс:
Участники: специалист по подбору персонала Марья Федоровна, руководитель технического департамента Илья Иванович.
Темы обсуждения: техническая часть - такие, коммерческая часть обсуждение финансовых ожиданий сторон.
Область компетенции: Марья Федоровна кадровые вопросы, вопросы мотивации персонала. Илья Иванович - общее управление департаментом, поставка задач, техническая отчетность, DBA.
При таком подходе соискатель понимает формат, дает обратную связь и стороны экономят время.
P.S. Было бы не плохо, если бы специалисты по подбору персонала исходно правильно себя позиционировали, потому что НR - это менеджер по управлению персоналом, подбор персонала небольшая часть его работы при нормально построенных бизнес процессах. Если специалист имеет должность HR, а де факто является только специалистом первичному подбору персонала, а вопросы планирования карьеры, мотивации, решение конфликтных ситуаций в область его обязанностей не входит, то было бы прекрасно сразу об этом уточнить, тем самым не вводить в заблуждение соискателя и избежать не нужных вопросов
Разбор ошибок штука хорошая, вот только порой не учитывается один фактор - человек занимается не своим делом, да можно с помощью инструментов и аналитики поднять его КПД, но это тактическое решение, которое все равно приведет к стратегическому фиаско. Стоит подумать, а ты вообще тем занимаешься? Мир ИТ разнообразен, но мир ИТ это маленькая часть мира, где есть много чего интересного.
Внедрение ИИ технически возможно, другое дело, что она не отменяет человека на ОТК, который вначале модель надрессирует. Потом необходимо провести полный цикл испытаний, фактически те же требования, что и к АИС, если решение для продукции используемой в критически важной инфраструктуре, то все спектр требований к софту для подобного применения. На выходе, получаем а) долго, б) дорого, в) возможно перспективно на отрезках 10-20 лет. ГОСТ технически подлежит токенизации, другое дело, что рядовой программист эту работу качественно не выполнит, если только последние лет 10 этот ГОСТ не использовал в работе. Если постановщик, описанной исходной задачи думает, что ИИ заменит человека, то у меня для него плохие новости об его квалификации. ИИ может другое - стать инструментом, который позволит профильному специалисту быстрее выполнять определенные операции и/или быстрее осуществлять предварительную оценку данных.
Есть еще один нюанс, критичность данных и их защита, если у вас свой офис, окруженный забором и овчарками, то в целом можно и на своем железе построить защищенную систему. Если вы арендуете в бизнес центре обычный офис на N помещений, то задача создать серверную, которая пройдет аттестацию уже становится не такой тривиальной и тут аттестованные облачные решения, скорей всего выиграют. Для средней конторы, у которой на сервере крутится 1С и все клиенты в локальной сети, может оказаться выгодней кластер из б/у серверов, если у сборщика руки прямые. Коллеги по приколу собрали резервный кластер на б/у Хеоn`ах и двупроцессорных китайских матерях, 2 года полет нормальный, но это скорее не тиражируемое решение, а просто фан, с железками повозится.
Было бы прекрасно, если бы автор дополнил статью техническими подробностями, объем базы, количество документов в базе (интересует порядок, а не с точностью до штуки). Какая именно база используется, потому, что для 1С возможны варианты, какой серверный ресурс. Иначе сложно оценить это история успеха или нет.
Детский сад какой-то, а где правовая оценка, где соответствующие письма/приказы профильных ведомств? А так предложение из разряда давайте сломайте КИИ за 2 копейки и выдайте на себя вещдок. Ну классно, только надо быть на всю голову отмороженным, чтобы об этом даже подумать. Я бы понял, если СК РФ дал официальную оценку этому мероприятию с правовой точки зрения и свое полное одобрям-с, если бы ФСБ, например, опубликовало официальное письмо с оценкой данных действий и МУ по правилам работы и дальнейших действий в случае удачного поиска уязвимости, ну и так далее и все эти нормативные документы были бы приложены к новости, а так не ну, вы серьезно?-))) Безопасность начинается с порядка и четкого и жесткого понимания правил игры, а иначе могут быть плачевные последствия.
P.S. Кстати, громкие имена и большие конторы, еще не означает, что юридически все сделано грамотно, достаточно посмотреть на регистрацию ресурсов Сбербанка, регистрация аналога Гитхаба ничего не нарушает из федеральных законов, а если подумать?-) Хотя казалось бы юристов у них достаточно.
P.P.S. Документы на сайте Минцифры и 146 УК РФ, точно никак не связаны или все-таки не все так гладко, может кто-то допустил оплошность, а кто-то не проконтролировал или все-таки все проверили и они просто знают, что-то, что не знают простые смертные?-)
Для критичных проектов, с разумным подходом к разработке, 70% документации готово до того, как программисты хоть строчку кода написали и это правильно. А вот когда начинается детский сад, вначале напишем софт, а потом начнем делать документацию возникает лес граблей. Кстати, работать по ГОСТу одно удовольствие, просто опыт иметь надо и ГОСТы знать.
Интересно рынок поменялся, раньше требования к мидлу были такие, как тут к сеньору, а без навыков пресайла и с джуном разговаривали со скрипом.
Жизненный цикл проекта далеко не всегда заканчивается сдачей в эксплуатацию, в части проектов жизненный цикл заканчивается, когда систему выводят из эксплуатации, а это значит, что РП должен уметь работать со сроками в 10-15 лет.
Очень вскользь увидел экономику, а в реальных проектах экономика может занимать половину функционала, хотя бы потому, что время и риски всегда связаны с деньгами.
Не увидел делегирования, РП может делегировать организацию работы разработчиков тимлиду и это тоже рабочая схема.
Старт рассуждений начинается с ТЗ, хотя создание ТЗ это этап после предпроектного обследования, качество исполнения которого, как раз впрямую влияет на ТЗ. Я уж молчу, что половина компаний не понимает разницу между ТЗ и ЧТЗ.
ПМИ - вторичный вопрос, на мой взгляд, интереснее спросить про этапы и типы испытаний, про регламент испытаний и взаимодействие с Заказчиком, потому, что эти вопросы показывают базовый юридический бэкграунд РП, без которого количество граблей в проекте кратно растет.
Проблема в РФ с утечкой данных не техническая, а организационная, технических средств обеспечивающих выполнение 152-ФЗ к примеру, более чем, а вот человеческий фактор хромает.
Государство пока не хочет спускать всех собак на несознательных персонажей и действует увещеванием, когда у государство лопнет терпение, то будем наблюдать традиционные посадки.
После чего достать данные станет крайне сложно, потому, что у любой информации есть цена, получить 20-ку с конфискацией за персональные данные Васи Пупкина весьма сомнительное мероприятие.
Первый момент. Стоимость принятия решения, риски принятия решения, стоимость владения решением, вопросы на которые реальный управленец отвечает на автомате при любой задаче, время обдумывания ответа может отличаться от сложности задачи.
Второй момент - согласования, вытекает из первого, если согласование элементарной вещи занимает дни/недели, то какую методологию не бери тут проблема в качестве менеджмента, а не методологии.
Третий момент - процессы никак не отменяют результат, если в описании процесса нет результата, так не процесс плох, а формализован он плохо.
Четвертый момент - делегирование, у части менеджеров с этим все плохо, как следствие они занимаются не эффективной деятельностью, например сами делают отчеты на каждый пчих. Проблема в процессах/PM book - нет, проблема в когнитивных способностях конкретного персонажа и понимании на каком участке процесса должны быть отчеты.
Пятый момент - распределение времени. Если взять к примеру разработку ПО, то на сам кодинг должно уходить не более 20% времени, тестирование 50%, документация (включая как раз те самые отчеты) 30%, тогда все будет работать с хорошими финансовыми показателями.
Шестой момент. Я видел кучу формализованных систем в которых отсутствовала финансовая составляющая, как следствие результат плачевен. Я когда ставлю задачу всегда понимаю, сколько стоит ее выполнение, а не просто тут задача "Петру" на 5 часов. Если у "Петра" стоимость часа работы 20 000 рублей, то грузить его всякой фигней это риск получить в лоб от финансового департамента за нерациональное расходование бюджета, однако подобный подход в реальном времени наблюдается не часто на рынке.
Часть первая. Разработчики.
Типичная ситуация:
1 разработчик не умеет писать нормальную техническую документацию;
2 не может написать ЧТЗ на подсистему/сервис.
На мой взгляд ИИ для него бесполезен.
Возможный выход - обучение разработчика данным скилам, либо предоставление компаньона который обучит ИИ, выдаст четкие инструкции по работе и проведет декомпозицию задач. Второй подход вызывает сомнения в свое экономической целесообразности.
Часть вторая. Менеджмент.
Для внедрения ИИ PM должен понять тактическую и стратегическую цену внедрения подобного решения именно в вашей компании. Проведите простой эксперимент в своих командах:
1 возьмите понятную задачу по уже известным технологиям сроком на 2-6 месяцев;
2 задайте вопрос PM - во сколько обойдется компании стоимость внедрения данного решения и каков процент ошибки прогноза;
3 проанализируйте ответ.
Мой опыт говорит, что процент PM которые в состоянии говорить на языке денег и рисков крайне мал при уже освоенных технологиях, что говорить про новые? Хотя возможно в ваших командах иначе.
Часть третья. Резюме.
Из всего выше сказанного получаем:
1 часть разработчиков не обладают навыками для внедрения ИИ;
2 часть менеджмента не умеет в финансы, что тоже не позволит эффективно внедрить ИИ;
3 до внедрения ИИ необходимо запустить проект по подготовке персонала, если хотеть прогнозируемые затраты и результат.
4 для подготовки персонала по работе с ИИ необходимо обеспечить данный проект ресурсами, что на рынке пока наблюдается крайне редко.
Часть первая. Организационная.
Вначале на среднюю позицию устраивают аттракцион из 5 собеседований с дельтой неделя - две, потом еще СБ и полиграф, а потом работодатель берет 2 недели на обдумывание. Зачем? Я бы понял, если бы искали гуру и обсуждался контакт на 10 лет, но у вас же испытательный срок и срочные контракты. Загадка.
Часть вторая. Запросы по профессиональной деятельности.
Работодатель хочет полную информацию о твоих проектах, чуть ли не с пеленок, какой практический смысл в информации о проекте 30 летней давности, может кто подскажет? Ну разворачивал я почтовый сервак на фрибсд в 1995 и он даже проработал 10 лет из которых 7 лет без обслуживания, толку от этого скила, я подобной работой очень давно не занимаюсь и очевидно, что навыки не актуальны, да и с текущей профессиональной деятельностью эти скилы никак не связаны.
Часть третья. Тестирование.
Тестирование, что в общем виде само по себе не плохо, если бы относилось к рассматриваемой позиции и имело вменяемые условия.
Пример 1. Исходные данные:
Обсуждается позиция PM в системном интеграторе, интегратор занимается розницей, проекты связаны с разработкой софта для розницы.
Тестовое задание на собеседовании: нарисовать алгоритм работы аппаратного спектрального анализатора сигналов сети 10Gbit и предложить его программную реализацию, так и не придумал, где компания может применить эти навыки. Время на выполнение 15 минут.
Пример 2. Исходные данные:
Фулстек аналитик, компания разрабатывает СЭД.
Тестовое задание: подготовить полный комплект проектной документации на Систему в полном соответствии с ГОСТ 34, готовый к гос. приемке, в качестве исходных данных аккаунт к тестовому стенду и контракт 5 летней давности на разработку, время разработки 3 дня.
Пример 3. Исходные данные:
Должность бизнес-аналитик, компания разрабатывает решения для логистики.
Тестовое задание: есть старая система, использующая MS SQL 2012 и сервак на Xeon E5, задача необходимо математически просчитать ускорение работы базы с погрешностью не более 1,5% при переходе на Xeon Platinum 8480 и Postgre Pro 14 Enterprise, больше данных нет, построить модель в Матлабе и провести презентацию результата расчета. Время на решение задачи 2 часа. Позиционировался, как типичный пример постановки задачи в данной компании.
Часть четвертая. Заключительная.
Таких прекрасных примеров я могу еще пару десятков привести, как вы думаете, как вы думаете к чему, описанный выше, подход при найме приведет. Вот я думаю, как раз к потоку тех самых шулеров.
Ремарка: Нет четкой постановки задачи, нет точной оценки.
Вы начали писать статью очень размыто указав как вы формировали запрос на рынок. Не понимая запроса оценить ваши рассуждения сложно. Текст вакансии это даже не ТЗ, а готовое коммерческое предложение, зная его можно сделать прогноз, кто к вам пойдет.
Предположим, что вы искали Seniora и ваша вакансия сформулирована адекватно, а компания белая и пушистая, при этом вы получили описываемые результат.
Это означает только одно - на ваше предложение специалистов нет. Из этого следует, что либо нужно менять предложение, либо закрывать позицию, либо растить собственных специалистов.
Возник вопрос, как отслеживается связность изменений и требований в документах?
Например, в моей работе изменения ЭД, которые отражают реальные текущие технические параметры АИС с точки зрения техники порой не сложны, уточнили две таблицы, поменяли абзац текста, это взгляд технаря.
Однако, если эти изменения сделать без учета требований в коммерческой и проектной документации, то результат может быть весьма плачевен. Для того, что внести изменения корректно - нужно четко представлять насколько внесение этих изменений не противоречит требования текущих Контрактов/ТЗ/ЧТЗ, а также не нарушает требования предыдущих контрактов на АИС. Ретроспектива документации 7 лет, причем одна и та же формулировка с точки зрения техники, изложенная разным стилем может вызывать разные последствия.
Это я еще не касался изменения ТУ, где соответствие нормативно-правовой документации раскрывается во всей красе и технически корректное изменение, но нарушающее ФЗ может привести к знакомству с тов. прокурором, со всеми вытекающими последствиями.
А можно взять себе workstation на б/у хеоn и получить и железку для Devops/виртуализации/прочего и вполне рабочую лошадку для программирования. А по цене макбука можно взять уже Epic). Причем предложенные решения позволяют создавать различные рабочие конфигурации для тестирования софта и понимания узких мест.
Навскидку не только в диски упирается-) В случае софтрейда контроллер шины PCI-е+контроллер дисков+ контроллер самого диска, а также их взаимодействие друг с другом, в случае хард рейда еще добавляется контроллер хардрейда. Это если рассматривать цепочку с середины цикла записи/чтения в рамках одного сервера. SMART для анализа не сильно поможет, он покажет только битый/не битый диск, если грубо, поведение контроллера конкретного диска при больших нагрузках он не покажет. Что происходит на уровне шины PCI-e тоже науке не известно. Это очень грубо на уровне железа, считаем что софт идеальный и багов в нем нет. Как показывает практика с серверами Supermicro 10 одинаковых серверов, вот реально все потроха одной ревизии, отличаются только неделями выпуска, ведут себя по разному при больших нагрузках.
Если на входе в заведение сидит идиот, то это может означать - тест на сообразительность (сообразительность инженеру постоянно нужна), либо что в данном заведении с процессами все плохо, а зачем балаган на работе, все-таки клоун и инженер это разные специализации.
Халява это молоко, которое в шаббат скиснет, поэтому его раздают бедным-))) Теперь по сути, краткое резюме для технарей, кто был инженером без работы не останется, кто был узким специалистом того может постичь печальная участь. Собственно все последствия ИИ при условии, что он таки будет развиваться. Если ИИ не будет развиваться, то все останется по прежнему.
Мне вот всегда было интересно, как вы простои по вине Заказчика будете считать, банальная итерационная задача, где с точки зрения Заказчика два состояния - задача поставлена/задача решена, а с точки зрения программиста это будет 10-15 итераций, по простой причине - Заказчик не в состоянии сразу сформулировать все требования и выдает корректировки в n шагов, причем не смотря на жесткий временной регламент на время реакции, регулярно завышает сроки ответа на уточняющую информацию. Дальше имеем побочные артефакты, как время переключения с другой задачи со стороны программиста при получении очередного уточнения от Заказчика, это я еще не упоминал в этой цепочке парочки аналитиков и ПМ. В результате данные, которые выдаст лобовой трекер фиксации времени, будут также полезны, как потолочные данные. Фиксация времени имеет смысл для решения типовых операций с заранее прогнозируемым лимитом на их решение, только для таких операций и системы не нужны, если менеджер в состоянии в уме 17 на 15 умножить-))
В заголовке статьи и дальнейшем ее изложении, на мой взгляд, есть сбой в логике. Если мне нужен кодер от забора до обеда, одни требования и там, возможно курсов хватит для джуна, если мне нужен разработчик другие, если мне нужен разработчик с базовыми знаниями аналитика третьи и так далее.
По теме -я считаю, что высшее образование для разработчика должно быть, причем классическое, которое включает в себя гуманитарные предметы, в том числе. Вспоминая свой технический ВУЗ, по прошествии многих лет, могу сказать, что лишних предметов не было, хотя когда учился, казалось вот на зачем мне промышленное право или философия, к примеру. Другое дело, что вопрос в том, что хочет человек срубить сиюминутно копейку по быстрому или получить профессию, которая будет его кормить всю жизнь, если первое, то ИТ ему в принципе не нужно, есть масса тем, где деньги получаются быстрее и дешевле.
Театр начинается с вешалки, а специалист по подбору персонала с представления. На моей памяти за 25 лет работы в ИТ было 3 специалиста, которые выдали на старте кейс:
Формат собеседования:
Техническая часть/общая информация/коммерческая часть.
Расчетное время 1,5 часа.
Участники: специалист по подбору персонала Марья Федоровна, руководитель технического департамента Илья Иванович.
Темы обсуждения: техническая часть - такие, коммерческая часть обсуждение финансовых ожиданий сторон.
Область компетенции: Марья Федоровна кадровые вопросы, вопросы мотивации персонала. Илья Иванович - общее управление департаментом, поставка задач, техническая отчетность, DBA.
При таком подходе соискатель понимает формат, дает обратную связь и стороны экономят время.
P.S. Было бы не плохо, если бы специалисты по подбору персонала исходно правильно себя позиционировали, потому что НR - это менеджер по управлению персоналом, подбор персонала небольшая часть его работы при нормально построенных бизнес процессах. Если специалист имеет должность HR, а де факто является только специалистом первичному подбору персонала, а вопросы планирования карьеры, мотивации, решение конфликтных ситуаций в область его обязанностей не входит, то было бы прекрасно сразу об этом уточнить, тем самым не вводить в заблуждение соискателя и избежать не нужных вопросов
Разбор ошибок штука хорошая, вот только порой не учитывается один фактор - человек занимается не своим делом, да можно с помощью инструментов и аналитики поднять его КПД, но это тактическое решение, которое все равно приведет к стратегическому фиаско. Стоит подумать, а ты вообще тем занимаешься? Мир ИТ разнообразен, но мир ИТ это маленькая часть мира, где есть много чего интересного.
Внедрение ИИ технически возможно, другое дело, что она не отменяет человека на ОТК, который вначале модель надрессирует. Потом необходимо провести полный цикл испытаний, фактически те же требования, что и к АИС, если решение для продукции используемой в критически важной инфраструктуре, то все спектр требований к софту для подобного применения. На выходе, получаем а) долго, б) дорого, в) возможно перспективно на отрезках 10-20 лет. ГОСТ технически подлежит токенизации, другое дело, что рядовой программист эту работу качественно не выполнит, если только последние лет 10 этот ГОСТ не использовал в работе. Если постановщик, описанной исходной задачи думает, что ИИ заменит человека, то у меня для него плохие новости об его квалификации. ИИ может другое - стать инструментом, который позволит профильному специалисту быстрее выполнять определенные операции и/или быстрее осуществлять предварительную оценку данных.
Есть еще один нюанс, критичность данных и их защита, если у вас свой офис, окруженный забором и овчарками, то в целом можно и на своем железе построить защищенную систему. Если вы арендуете в бизнес центре обычный офис на N помещений, то задача создать серверную, которая пройдет аттестацию уже становится не такой тривиальной и тут аттестованные облачные решения, скорей всего выиграют. Для средней конторы, у которой на сервере крутится 1С и все клиенты в локальной сети, может оказаться выгодней кластер из б/у серверов, если у сборщика руки прямые. Коллеги по приколу собрали резервный кластер на б/у Хеоn`ах и двупроцессорных китайских матерях, 2 года полет нормальный, но это скорее не тиражируемое решение, а просто фан, с железками повозится.
Было бы прекрасно, если бы автор дополнил статью техническими подробностями, объем базы, количество документов в базе (интересует порядок, а не с точностью до штуки). Какая именно база используется, потому, что для 1С возможны варианты, какой серверный ресурс. Иначе сложно оценить это история успеха или нет.
Детский сад какой-то, а где правовая оценка, где соответствующие письма/приказы профильных ведомств? А так предложение из разряда давайте сломайте КИИ за 2 копейки и выдайте на себя вещдок. Ну классно, только надо быть на всю голову отмороженным, чтобы об этом даже подумать. Я бы понял, если СК РФ дал официальную оценку этому мероприятию с правовой точки зрения и свое полное одобрям-с, если бы ФСБ, например, опубликовало официальное письмо с оценкой данных действий и МУ по правилам работы и дальнейших действий в случае удачного поиска уязвимости, ну и так далее и все эти нормативные документы были бы приложены к новости, а так не ну, вы серьезно?-))) Безопасность начинается с порядка и четкого и жесткого понимания правил игры, а иначе могут быть плачевные последствия.
P.S. Кстати, громкие имена и большие конторы, еще не означает, что юридически все сделано грамотно, достаточно посмотреть на регистрацию ресурсов Сбербанка, регистрация аналога Гитхаба ничего не нарушает из федеральных законов, а если подумать?-) Хотя казалось бы юристов у них достаточно.
P.P.S. Документы на сайте Минцифры и 146 УК РФ, точно никак не связаны или все-таки не все так гладко, может кто-то допустил оплошность, а кто-то не проконтролировал или все-таки все проверили и они просто знают, что-то, что не знают простые смертные?-)
Для критичных проектов, с разумным подходом к разработке, 70% документации готово до того, как программисты хоть строчку кода написали и это правильно. А вот когда начинается детский сад, вначале напишем софт, а потом начнем делать документацию возникает лес граблей. Кстати, работать по ГОСТу одно удовольствие, просто опыт иметь надо и ГОСТы знать.
Интересно рынок поменялся, раньше требования к мидлу были такие, как тут к сеньору, а без навыков пресайла и с джуном разговаривали со скрипом.
Жизненный цикл проекта далеко не всегда заканчивается сдачей в эксплуатацию, в части проектов жизненный цикл заканчивается, когда систему выводят из эксплуатации, а это значит, что РП должен уметь работать со сроками в 10-15 лет.
Очень вскользь увидел экономику, а в реальных проектах экономика может занимать половину функционала, хотя бы потому, что время и риски всегда связаны с деньгами.
Не увидел делегирования, РП может делегировать организацию работы разработчиков тимлиду и это тоже рабочая схема.
Старт рассуждений начинается с ТЗ, хотя создание ТЗ это этап после предпроектного обследования, качество исполнения которого, как раз впрямую влияет на ТЗ. Я уж молчу, что половина компаний не понимает разницу между ТЗ и ЧТЗ.
ПМИ - вторичный вопрос, на мой взгляд, интереснее спросить про этапы и типы испытаний, про регламент испытаний и взаимодействие с Заказчиком, потому, что эти вопросы показывают базовый юридический бэкграунд РП, без которого количество граблей в проекте кратно растет.
Проблема в РФ с утечкой данных не техническая, а организационная, технических средств обеспечивающих выполнение 152-ФЗ к примеру, более чем, а вот человеческий фактор хромает.
Государство пока не хочет спускать всех собак на несознательных персонажей и действует увещеванием, когда у государство лопнет терпение, то будем наблюдать традиционные посадки.
После чего достать данные станет крайне сложно, потому, что у любой информации есть цена, получить 20-ку с конфискацией за персональные данные Васи Пупкина весьма сомнительное мероприятие.