В своих статьях в блоге SmartValues мы с коллегами стараемся показать, насколько важна психологическая безопасность для благополучия как отдельного человека, так и компании в целом, что нужно для её создания и какие навыки помогут это сделать. Теперь предлагаю от теории перейти к практике через разбор кейсов. Возможно, эта рубрика станет постоянной.
Итак, кейс. Подобная история, как подсказывает мне опыт, может быть знакома многим.
В прошлом тексте («Как отличить Инженерию от её симуляции») речь шла о трёх вопросах, по которым инженерию можно отличить от деятельности, внешне на неё похожей. Граница между ними проходит не по должностям и не по стеку, а по тому, строится ли работа на модели устройства системы, которую проверяют раньше, чем её проверит эксплуатация. Из этого различения вытекает вопрос, который выходит за рамки темы прошлой статьи и заслуживает отдельного разбора: если симуляцию можно отличить так просто, то почему она годами живёт в крупных и вполне успешных компаниях?
Product Radar — здесь каждую неделю публикуются лучшие онлайн-сервисы и железки от русскоязычных команд.
👉 Подписывайтесь на тг-канал площадки — Product Radar — лучшие стартапы России.
Это площадка, где энтузиасты из мира технологий делятся своими идеями, обсуждают и создают вместе новые продукты, чтобы делать жизнь людей лучше.
За последние пару лет велосипед разработки с использованием ИИ прошел путь от автодополнения кода до «шесть агентов пишут код, седьмой его ревьюит, а человек применяет, даже не открывая diff».
Каждый новый подход добавлял велосипеду то руль побольше, то более круглое колесо, то спидометр, то моторчик. Седло при этом каждый раз забывали. Ехать можно, даже быстро и эффектно. Просто через несколько месяцев выясняется, где именно болит.
Я не против ИИ в разработке и сам им пользуюсь. Но давайте пройдемся по хронологии и посмотрим, как мы радостно раз за разом давили на педали такого велосипеда.
Многие руководители и предприниматели спрашивают: «Почему мои сотрудники инфантильны и я вынужден по пятьдесят раз объяснять, что от них требуется? Почему не берут на себя ответственность и прячут голову в песок? Проще сделать самому…».
Привет, Хабр!
Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.
Когда в команду приходит новый QA‑инженер, у его непосредственного руководителя есть примерно три месяца на то, чтобы превратить его из «человека с резюме» в самостоятельного участника процесса.
Да, три месяца — это тот самый испытательный срок, в течение которого новый сотрудник должен подтвердить свои компетенции, но в реальности нам нужно не просто проверить человека, но и интегрировать его в команду. И об этом мы будем говорить далее в статье.
Корявый код джуна раньше был полезен. Странный JOIN, переменные tmp2 и data_new, три вложенных if там, где хватило бы одного. По таким следам ревьюер сразу видел, где человек плавает, и шёл проверять именно туда.
С AI в клиентской разработке стало выгодно делать то, что раньше технически было несложно, но экономически бессмысленно. Какой‑нибудь специфический фильтр, дополнительный экран в админке, сценарий обработки данных… Раньше смотришь на задачу и понимаешь, что руками это несколько часов работы. Клиенту функция не настолько нужна, сколько она стоит в хорошей реализации, поэтому либо от неё отказываемся, либо ищем готовый плагин, который умеет нужное и подгружает ещё семьдесят свистелок.
