Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Registered
- Activity
Specialization
Backend Developer, Chief information officer (CIO)
Lead
Project management
Development of tech specifications
Negotiation
Optimization of business processes
Development management
Automation of processes
В торговле я бы с вами согласился.
А вот в IT кадры очень сильно решают и там экономить на кадрах будут в последнюю очередь.
Объективности ради.
Правильно гуглить - скилл номер 1 для любого разработчика.
Как и правильно GPT юзать.
Делать велосипеды, которые давно изобретены - незачем.
Учить все-все-все тоже.
Лучше на архитектуре приложения сосредоточиться больше.
А вот в остальном с вами согласен.
На собесах выдают дичь :)
Иногда джуны более вменяемы, чем мидлы )
Грубовато, конечно.
Но с сутью согласен :)
Действительно, тот кто хоть что-то умеет за адекватный прайс - быстро находит новое место.
Мне, чтоб найти разработчика, потребовалось отсобесить порядка 40 человек.
И это, считаю, очень крупно повезло - быстро нашелся :)
Давайте приведу пример, возможно станет яснее.
Вы хотите подключить интернет.
Если оператор связи вам сразу скажет, что с вас 10 000 в месяц, то вы его просто не подключите.
Если же он вам его подключит за 1 000 рублей в месяц, а далее будет раз в 2 месяца повышать, то вы будете в плюсе, потому что какое-то время будете пользоваться дешевым интернетом и оператор будет в плюсе, потому что какое-то время он будет получать прибыль.
Примерно такая же логика и в найме.
К вам приходит разработчик и сразу требует 800к за неизвестные скилы.
Проверить его навыки в деле вы можете лишь после того, как его наймете (никто в здравом уме не будет решать в виде теста реальные бизнес задачи).
Вам, как работодателю, будет выгоднее нанять того, кто будет стоить ниже вашей реальной оплатной способности (снизив рисковую зону на случай, если навыки соискателя окажутся фикцией), а затем раз в период увеличивать ЗП.
Вариантов, на самом деле множество как далее события могут развиваться - зависит от работодателя.
От "раб на галере" до "высокооплачиваемый эксперт".
Если компания адекватная, то в этом случае в выигрыше остается и работник (у него сразу есть работа + ЗП + рост ЗП) и работодатель (снижен риск).
Дальше все упрется исключительно в "точку комфорта", когда работнику достаточно денег, а работодатель может эти деньги выплачивать.
Например, инфляция будет есть 10% в год, а прибыль компании такими темпами расти не будет, чтоб обеспечить покрытие инфляции ФОТ.
В какой-то момент сотрудник окажется "вне точки комфорта", попросит увеличить ЗП, получит отказ, подумает и либо останется на старом окладе, либо далее уйдет туда, где кормят лучше.
И осуждать его никто не будет - все мы люди и все понимаем, но есть и бизнес-ограничения.
У любого сотрудника есть точка Х с которой он готов начать сотрудничество "на посмотреть что будет далее".
Если эта точка сразу значительно выше рынка - такой сотрудник мало кому потребуется и как итог будет сидеть вообще без работы.
Исключением может стать, наверное, только "пожарная команда", когда вас берут потому, что прошлый работник превратил рабочий проект в какие-то легаси дебри и уволился :)
Тут тоже стоит задуматься, почему вас берут сразу на высокие деньги.
Бизнес не платит за красивые глаза, а ваша эффективность на новом месте работы в первый квартал точно будет ниже ожидаемой - притереться надо всем, и работнику, и работодателю.
Не исключаю того, что у меня профдеформация.
Но мне кажется она тут не при чем.
Я же пишу автору, что заголовок имеет неточность, которая сильно меняет смысл.
Решил загуглить разницу при конкретных формулировках на всякий случай,
вот выдача:
"Ограничение доступа к интернету – это более общее понятие. Оно означает, что доступ к интернету в принципе ограничен. Это может быть сделано разными способами: блокировка всего трафика, ограничение скорости, использование VPN, и т.д. Это как "закрыть дверь" в интернет.
Ограниченный доступ к интернету – это более конкретное понятие. Оно подразумевает, что доступ к определенным ресурсам или типам контента ограничен. Например, можно ограничить доступ к социальным сетям, определенным сайтам, или только к определенным типам файлов. Это как "открыть дверь, но только в определенное время или для определенных людей"."
По итогу текст в названии:
"...могут работать при ограничении доступа к интернету"
читается как
"Интернета нет, но Билайн работает"
Если же речь про простой доступ при отрицательном балансе - это вообще не нужно с РКН согласовывать, это дело самого оператора и уже давно решается разными подписками типа "звонок/интернет при отрицательном балансе".
Думаю, что в статье речь ведут все же про попадание в white-лист РКН, что гарантирует тот самый привилегированный доступ Билайн к интернету в любых условиях.
Верно, однако, насколько помню, основным критерием было "собрать к сроку N ружей".
Проблема заключалась как раз в том, что ни у одной оружейной компании не нашлось столько спецов.
Как итог проблему решили разделением на примитивные задачи, где каждый отвечает за примитивное действие.
Набрали людей с улицы, за сутки научили делать одну операцию и по итогу получили унификацию каждой детали.
Вот сейчас GPT - аналог такого метода, на мой взгляд.
Буквально месяц назад хайпил клип, где 2 зумера без знания электрики чинили розетку, а GPT через видео подсказывал "провод сюда, провод туда. Да, вы закрепили верно".
Можно просто "исполнять", можно использовать как "второе мнение", а можно чисто учиться.
Каждый выбирает сам свой путь джедая :)
Согласен, в каждой компании своя кухня :)
В целом все верно, БА - это широкий спец, как я и писал выше.
Нужны глубокие спецы - есть разработчики, например.
Вы правильно написали, что если стек не используется - то зачем его знать.
Однако, чем глубже знания аналитика, тем лучше качество на выходе.
Ни один разработчик не захочет на входе получить сырое описание с кучей неясностей.
А то, что Разработчик не сообщил о своем недовольстве качеством описания БА не означает, что Разработчик доволен :)
Я просто не делю по гендерам, а ориентируюсь на качество работы.
Если вам подготовят рабочий код, например, то есть ли разница какой пол его написал?
Для меня нет, для бизнеса тоже.
Разве?
Суть конвейера превращение неквалифицированного труда рабочих в продукт единого качества.
Например сейчас тот же Форд активно внедряет AR для ремонта.
"Не нужно думать - закручивай гайки, а ИИ подскажет какие и с какой силой".
Второй пример конвейера, менее известный:
В конце XIX века в Америке был большой заказ на ружья, но производство шло поштучно, каждое ружьё делал один мастер от начала и до конца. Это было медленным, так как детали отличались друг от друга.
Конвейерная сборка позволила решить эту проблему: все детали стали одинаковыми по размеру и материалу, что ускорило процесс производства. Сборщики конечного ружья могли брать любые детали из ящиков, и они все подходили.
Эти детали делали неквалифицированные рабочие, но операция была настолько простой, что позволяла осуществить конвейер.
Например, "вставь сюда пружинку и закрепи".
Он не генерирует контент, к сожалению.
Он его переписывает на базе исходников человека, делая "выжимку".
Именно по этой причине обучение на ML текстах ведет к деградации моделей.
Каждая новая версия оскудняет прошлую.
Генератором контента был и остается лишь человек.
Хотя ряд моделей весьма интересно сочетают известные компоненты и получают нечто неожиданное.
Например, химические соединения.
Предположу, что вы просто его неправильно кушаете.
Если правильно задавать вопросы, то GPT очень хорошим ментором выступает.
Верить ему нельзя - галлюцинировать может.
Но вот вектор в 99% случаев укажет верно для дальнейших рассуждений.
Пример автоматизации этого процесса Duolingo - там 70% текста комбинирует ИИ.
Прекрасно обучает языкам и весьма индивидуально.
Уважаемый автор, мне кажется есть небольшая, но очень важная ошибка в заголовке статьи.
Может при ограниченном доступе, а не при ограничении доступа к интернету?
Ограничение доступа к интернету - это интернета нет совсем и ни для кого.
Ограниченный доступ - это интернет есть, но не для всех. Например, у Билайна доступ есть, а у нас его нет.
Лично я заинтересовался тем, как именно Билайн планирует обеспечить функционал при "ограничении доступа в интернет" :)
Упрощенно, ваша статья о том, как Билайн пытается попасть в White лист РКН, чтоб в случае ЧП он мог обеспечить услуги связи.
Если так, то это печально, конечно.
Мы обычно указываем "как есть", иначе это просто потеря времени и для работодателя и для соискателя.
Все же не грузчиков ищем :)
Ориентироваться на опросы не очень стоит, на мой взгляд.
Они не валидируются никем.
Откройте поиск вакансий с указанием ЗП.
Пролистайте 10-30 вакансий.
Поймете среднюю ЗП.
Там где ЗП не указана +/- 30% от средней будет.
Где-то не указывают, потому что выше рынка и не хотят завала заявками.
Где-то не указывают, потому что ниже рынка и нужно как-то завлечь людей.
Ну и стек нужно смотреть, джун С++ и джун Питона будут получать совсем по разному.
Очень правильный вопрос "как определить когда просить повышения ЗП".
А почему коллегам ЗП поднимают, а вам нет?
Как говорил один мой знакомый HR с прошлого места работы:
"Нет такой должности хороший человек", т.е. компания платит за принесенную прибыль, а не за то, что они музыку слушают или книги читают.
Если ваши коллеги имея тот же стек получают в 3 раза больше денег - это означает, что для компании они более ценные сотрудники (чаще всего так, хотя иногда бывает "так исторически сложилось").
Возможно, что на них держится легаси проект, который приносит прибыль компании.
А может они накидывают варианты развития бизнеса.
Вариантов "почему" уйма.
Требуется поднять ЗП - повторите их подвиг и попросите за это дополнительного финансирования.
Индексировать ЗП, к сожалению, в РФ не очень принято - мало таких компаний.
OpenOffice не использовал, подсказать не смогу :)
Но посмотрю, что имеете ввиду.
По ресурсам да - ручками, как и в маркдауне придется правки вносить.
Тут вариантов не шибко много :)
Если под автоматизацией понимается пуш в гит, так pptx тоже можно класть, как и любой файл - ничем не отличается и ровно таким же образом процесс CI-CD настраивается.
Другой момент, что одновременно править нельзя будет файл, так как смеджить содержание pptx не выйдет.
Из преимуществ pptx имеет возможность вставить картинку "как элемент" и настроить его расположение.
Т.е. не линк на картинку, а именно изображение внутри.
Аналогично с файлами можно поступать.
А при необходимости их оттуда можно забрать в исходном виде.
В частности макетирование сайта можно сделать с кнопками-переходами (ссылка на страницу документа).
По итогу получаем UI кликабельный в режиме демонстрации, который можно тыкать самому, а может тыкать заказчик.
Из практики очень хорошо заходит у заказчика на первых этапах проектирования структуры, так как за 1 день заказчик получает возможность визуализировать то, что он хотел.
Получаем макет на минималках, в котором без участия разработчиков может даже сам заказчик переместить объекты так, как ему нравится.
Иногда в процессе оказывается, что не хватает кнопок перехода и т.п.
Быстро, дешево, удобно.
Даже примитивную анимацию можно делать а-ля смена цвета кнопок, если время позволяет :)
.doc, на мой взгляд, только для юридических документов можно использовать, потому что по итогу в режиме редактирования там юристы и переписываются дополняя друг-друга, стандартная форма их коммуникации.
В маркдауне они писать принципиально не будут.
И опять же, финальный файл спокойно вкладывается в pptx именно в виде файла (не линком).
Для ведения документации пробовал - выходит мрак :)
Я к тому, что файл pptx выступает как своеобразный локальный архив, внутри которого лежат без линков все нужные версии файлов, которые по тем или иным причинам нельзя положить в маркдаун :)
а) Независимость от вендора
б) Независимость от сервера
в) Дублирование у разработчика и заказчика гарантирует сохранность
Как писал выше:
1) Маркдаун основа
2) pptx для всего, что имеет визуал + что не влезло в маркдаун.
Изображения, макеты, схемы нестандартные и т.п.
Но опять же, если какие-то иные инструменты есть - только за.
Проект без документации при длительной поддержке - это боль :)
Спасибо за статью, интересное мнение :)
Отвечу, пожалуй, как Руководитель отдела разработки.
1) Вас много - вакансия одна.
100500 тех, кто не имеет опыта и пытается "войти в IT" на плечах GPT и множественных собесов.
Знаний нет, опыта нет, зато говорят красиво - есть теория.
Отсюда 600 просмотров и лишь 1 закрытая вакансия.
Обратите внимание, что некоторые стали писать "Яндекс/Сбер курсы не принимаем" и т.п.
2) Тру Хацкер.
Есть профи, вот прям реальные спецы своего дела - видно сразу.
Но они одиночки.
Любая разработка сейчас - это не хакер одиночка, а команда.
Не умеешь играть "в команду" - тебя не возьмут.
На собесе это хорошо видно.
А собрать команду таких спецов, чтоб они сработались между собой - это вообще целая история.
3) Особенности стека.
Во фронт разработке это особо ощутимо, там "модно" каждый год что-то свое.
Уже даже заказчики заразились в этом плане и хотят видеть не "стабильно работает", а "модный стек".
90% задач быстро решается простым набором HTML + CSS + JS.
4) Кросс-функции.
"Это не моя задача" - такой ответ почти гарантия того, что вас не примут на работу.
Bus Factor = 1 никому не нужен, а держать 10 человек "про запас" не выдержит экономическая модель любой компании.
Вы же не хотите получать в 10 раз меньше денег? :)
Как итог каждый сотрудник должен быть чуть-чуть кросс-функционален.
В лучшем случае такие навыки будут у 1/10 кандидатов.
Пример по фронт-разработке.
Вы должны быть немного ИБ, сейчас половина атак через фронт делается.
А еще немного дизайнер, иначе временное плечо правок станет недопустимым.
А еще понимать бек, иначе как общаться на тему API.
А еще рендер изображения в браузере нужно понимать, иначе тайминг загрузки будет запредельным.
А еще ... много чего нужно знать в общем :)
5) Банальная самоуверенность.
Не имеет значения кем вы были на прошлом месте работы.
На собесе вы - один из сотен наравне с джунами.
Тот же HR (в большинстве своем) знать не знает чем Java от JavaScript отличается.
Ваша задача добраться до тех собеса, порой для этого нужны не знания, а простое умение общаться хотя бы по телефону.
"Звонок Господу" вызывает отторжение у любого HR и даже у техлида.
В целом спрос на разработчиков на рынке есть, просто нужно начинать с небольших сумм (среднерыночных реальных, достаточно просто открыть и посмотреть доступные вакансии) и ползти по карьерной лестнице к заветному 1 000 000 в месяц.
А если у вас ступень торга будет 300к сразу же, то да, вам придется долго ожидать свою "вакансию мечты".
Благодарю за статью, прочитал с интересом подход.
В силу своей должности с документацией работаю постоянно.
Озвученная вами боль известна очень хорошо :)
Маркдаун имеет свои преимущества, однако, большая часть коммерческого ПО имеет визуальный интерфейс в том или ином роде, который в вашей статье не подсвечивается.
Как итог:
1) Как вы будете хранить информацию о дизайне в маркдауне?
Есть же страницы с динамическим наполнением, а не только статичная HTML.
По сути вам придется делать ровно тот же хаос, который существует в папке любого проектного менеджера.
Версия 1, версия 2, версия 122.
Кстати, из практики, нумерацию в таких случаях проще вести не в версиях, а в датах обновления.
"20250620_Главная страничка"
Тогда внутри папки файлы всегда ложатся в хронологическом порядке и легко фильтруются.
final и прочие надписи - путь в пучину легаси без документации :)
2) ТЗ коммерческого сектора в том или ином виде предполагает наличие User Flow, которое предполагает наличие картинок/референсов/макетов, которые предполагают, что они где-то как минимум должны быть постоянно залинкованы.
Разработчик ушел, сервер потушен - ваша документация умерла, потому что отвалились все картинки.
Аналогично фигма.
Как итог - картинки должны быть доступны локально в 100% случаев.
Т.е. сам файл документации должен хранить внутри себя все картинки и их расположение без деплоя кода на сервер.
По итогу предложенный вами вариант - очень интересная тема для менеджеров из IT (бывшие тимлиды и разрабы, например), которым привычен маркдаун.
И вообще не работает для простых менеджеров (обычный руководитель среднестатистический после курсов "IT за 2 часа", коих, наверное, большинство сейчас).
Попробуйте подумать и в сторону UI-документации для полного охвата любого проекта и будет нам всем счастье :)
Из моей практики лучшим сочетанием пока является:
1) Маркдаун для технической документации
2) pptx для всей остальной
Если вам известно что-то более интересное, то буду рад взаимовыгодному диалогу :)
Спасибо за статью, интересное исследование :)
Однако вам не кажется, что в ней происходит подмена понятий?
GPT - это цифровой ассистент.
Задача ассистента забирать рутинные задачи, с чем ассистенты прекрасно справляются.
А исследование проводят в формате:
1) Группа 1 - вы "передаст" между GPT и принимающей стороной.
Вам не нужно думать.
2) Группа 2 - у вас есть ассистент.
Наслаждайтесь.
3) Группа 3 - у вас нет ассистента.
Страдайте.
Естественно, что в группе 1 будет падение нейронных связей - им не из чего образовываться, ведь ваша задача передать информацию от робота к приемнику.
Вам даже ее понимать не обязательно.
В группе 2 будут определенные связи, потому что приходится думать самостоятельно и руководить тем, что делает робот.
Таким образом часть задач можно отдать на аутсорс GPT.
В группе 3 у вас есть только вы - количество нейронных связей будет максимальным.
Я бы провел аналогию с конвейером Форда.
Раньше вам приходилось разбираться во всем и вы могли самостоятельно собрать автомобиль (группа 3), скорость производства 1 автомобиль в год.
Тупеет ли этот человек? Нет.
Но вы могли найти несколько таких спецов (группа 2) и скорость сборки увеличится до 10 в год, так как кто-то мог собирать моторы, а кто-то кузова.
Нужно ли каждому знать все об автомобиле?
Желательно, но уже не обязательно.
Тупеет ли этот человек?
Нет, он становится узким спецом в конкретной области.
Далее появился конвейер, где ваша операция "прикрутить болтик" (группа 1).
Остальное - задача конвейера (GPT в нашем случае).
На выходе тот же автомобиль, но скорость производства 30 штук в день.
Требуется вам в этом случае знать устройство машины?
Вообще нет.
В этом и суть.
Взять 100 прохожих, которые по итогу соберут автомобиль не понимая его устройства.
Тупеют ли они?
Нет, они и не знали как это делать - их никто не обучал.
Так что вывод, что GPT тупит население не совсем корректный на мой взгляд.
Кто хочет учиться - будет использовать его для обучения и автоматизации рутины.
Кто не хочет - будет использовать его для улучшения того, что он уже умеет.
По итогу работодатель в выигрыше всегда :)
В большинстве случаев перевешивает требование бизнеса "срочно надо прямо сейчас".
И разработчик делает не правильно, а ASAP, что тянет за собой костыли и тех долг.
В борьбе бизнеса и техников всегда побеждает бизнес, так как он заказчик услуги.
Если рассуждать в рамках ИИ, то в данном контексте он может позволить чуть больше учесть потенциальных проблем.
Опять же, если у того, кто спрашивает хватит квалификации понять, что ему отвечает ИИ.
Интересный вопрос, только не очень ясно, что вы имели ввиду.
Раскроете вопрос, возможно дам ответ