Пожалуйста. Вот вдогонку еще подумалось, что порой проблемы проистекают из лишнего использования иностранных терминов.
Примеры:
Можно использовать термин газлайтинг, а можно использовать русские слова агрессия и насилие,в зависимости от ситуации. Русский вариант сработает на всех поколениях, а английский часть сотрудников воспримут, как информационный шум.
Можно использовать слово менеджер, по факту размыто, а вот если используешь слово управленец, сразу видны границы.
HR на заметку. Мы ищем тимлида, в голове возникает - вы серьезно, вам нужен еще один лидер в компании, чтобы создать конфликт? А я вот думаю, что вам нужен руководитель команды. Нет нам нужен лидер, а тогда вы понимаете, что если это настоящий лидер, то в случае, если он уйдет команда уйдет с ним. Вам такой вариант развития зачем?
И вот таких нюансов масса и если внимательно смотришь за конфликтами внутри компаний, то отчетливо видно, что не правильная/не точная терминология закладывала конфликт на старте.
Спасибо за статью, было интересно. Как мне кажется, одна из основных проблем это подмена понятий.
Адаптивность: штука хорошая, вот только не стоит софистику и бардак считать адаптивностью, адаптивность это умение быстро включится в другое направление деятельности. Навык, который далеко не всех позициях нужен, а на некоторых может даже быть вреден.
Обучаемость: умение решать задачи, а не умение работать по 12 часов вместо 8 за те же деньги, а часто как раз именно второе понимают под обучаемостью. Более того я знаю двух классных спецов, один разберется в вопросе за день, другому нужно 2-3 дня, однако второй лучше формулирует стратегические решения, а первый тактические. Кто из них хуже?
Стрессоустойчивость. Под ней можно понимать быстрое принятие решения в случае аварии на технологической линии, а можно понимать умение функционировать в атмосфере помойки, первое инженеру может пригодится, второе полезный навык, но лучше в такие места не попадать.
Коммуникабельность. Под ней понимают умение изворачиваться, хотя по мне необходимое и достаточное условие для технического специалиста - вежливость и умение логично излагать свои мысли, если при этом он умеет излагать мысли адаптивным языком вообще сказка.
Тайм менеджмент: очень полезная штука, если идет в связки с экономикой, а не в режиме технарь должен быть волшебником, а менеджер может быть кем угодно. Почему экономика, а потому что частая смена задач это убытки, если посчитать в ретроспективе 3-5 лет.
Эмоциональный интеллект: прекрасная вещь, но лично я, на месте управленца, предпочту от специалиста краткость: сервак упадет, данные утекут, объем данных такой-то, последствия 3-7 лет курорта строго режима. А вопросы дипломатии стоит оставить продактам для общения с Заказчиками.
Размышления: Два проекта, постановка задачи схожая, есть тонна нормативной документации, нужно автоматизировать процесс регламентной отчетности, сроки вчера. Подробности - сами найдете.
Первый проект: как проектировать Систему решали разработчики, не плохой продукт технически, однако задачи Заказчика не решает, на выходе срыв сроков, штрафы и судебное разбирательство.
Второй проект на входе связка ПМ+юрист+фулстек аналитик, на выходе техническая реализация не хуже ( разработчики те же), проект сдан в сроки, Заказчик доволен.
Очень странная мотивация, все в кучу накидали. Частная компания может себе купить сертифицированный ФСБ СКЗИ и поднять защищенный канал, очень сомневаюсь, что он попадет под бан и организовать удаленному сеньору защищенное рабочее место.
Ипортозамещение тормозится в том числе, что на местах частенько строят из себя "барышень из Смольного" я не хочу, мне не удобно и т.п. причем технического обоснования почему не хочет и почему не удобно не следует.
Другое дело, что частенько наблюдается блокировка без нужной технической подготовки и летят "в ад" сервисы, которых по дороге зацепило, это проблема.
На мой взгляд идет бессмысленное разбазаривание ресурсу, вместо построения защищенных сетей для бизнеса, ломают старые сети, а в замен ничего толкового не предлагается или я этих предложений не вижу.
Работа технического писателя зависит от задачи, если он не понимает, какую задачу решает система, то результат будет плачевный.
Знание нормативной документации, как внутренней, так и внешней это база. Без этой базы получаются прекрасные технические руководства, которые при нынешнем законодательстве тов. прокурор может интерпретировать, как вещ. док для получения путевки от 3 до 7 лет в места отдаленные.
Постоянно придется изучать языки, нет не английский или немецкий, а языки на котором говорят разные специалисты и пользователи, чтобы потом не возникали в документации перлы - "мокирование данных в тестах", хотя бы потому, что 1 марта 2026 году уже прошло и правила новые.
Без хорошего инженерного образования, работать в целом можно, но тяжко, потому, что ты не понимаешь, что то, что тебе скинул технический департамент - ересь.
Поможет ли LLM техническому писателю, в целом поможет на узком спектре задач, глобально - нет.
Пример из жизни:
Задача: нужно написать ЧТЗ на группу подсистем АИС.
Ресурсы: аналитики предоставили ФТ и НФТ, технический департамент предоставил ЭД на ЦОД и интеграции, юридический департамент кинулся контрактом на разработку, в котором есть ТЗ, сроки и работы, условия приемки контракта.
Оценка сроков: Руководство - задача типовая, за неделю технический писатель напишет, руководитель проекта - точные сроки дадим через два дня, но в целом плюс-минус за неделю уложимся.
По факту: разработка заняла 2 месяца. Причина - участники процесса слабо разбираются в документации, не смотря на весь свой опыт и регалии. Как происходил процесс:
Анализ документации - неделя, выводы с такой документацией вы слоника не продадите контракт не закроете, а теперь подробнее:
НФТ не соответствует законодательству, как следствие две недели согласования и изменение формулировок.
ЭД на ЦОД и интеграции, это не документация, а записки старого гика на бабушкиных манжетах. В результате три недели на приведение сего опуса в нормальный вид. Созданная ЭД в последствии успешно прошла независимую экспертизу.
Контракт на разработку юридически грамотный, одна проблема в том, что ТЗ в нем также похоже на нормальное ТЗ, как сказки братьев Гримм на налоговый кодекс. В результате еще 2 недели на перевод ТЗ контрактного в ТЗ нормально техническое.
После чего действительно за неделю было написано ЧТЗ.
Резюме: к сожалению, многие путают работу технического писателя и работу оформителя/корректора, это разные работы и разные квалификации.
Размышления: рынку нужны профессионалы, отбор жесткий, владельцы высказывают резкую обеспокоенность дефицитом кадров и падением прибыли. Интересно, а как в реальности дела с наймом?
Сбор статистики: Позиция аналитик. Собрана ретроспектива коллег по цеху, которых я считаю хорошими специалистами, судя по успешным проектам они такими и являются). Круг не большой 19 человек, уровень проектов от 120 млн за проект, стаж работы на данной позиции от 15 лет.
2022 год:
количество этапов собеседования 6-8;
среднее время переговоров 2,5 месяца;
вес в принятии решений - хард скилы 30%, софт скилы 70%;
что нужно в реальной работе софт скилы 20%, хард скилы 80%;
результативность 10-ки переговоров 8 офферов на 2 отказа.
2025-2026 год:
количество этапов собеседования 10-12;
среднее время переговоров 4 месяца;
вес в принятии решений - хард скилы 10-15%, софт скилы 85-90%;
что нужно в реальной работе софт скилы 20%, хард скилы 80%;
Попросите Василису она Вам напишет код на русском, а если подружите ее с синим волком, то под Сферой никакая телега не просочится, а отчеты будете получать в былинном стиле-))))
За свою карьеру я видел много компаний, успешных, средних, убыточных, но единицы из них понимали, что они зарабатывают деньги решая задачи пользователей, а не реализую собственные амбиции/фантазии. Некоторые из тех, кто закрывал проблемы пользователей успешно развиваются с 90-х, я говорю про небольшие ИТ компании, а не про монстров рынка.
Про ситуацию на рынке:
Ситуация на рынке сейчас средней сложности, часть компаний уходит в небытие исключительно по законам капиталистической экономики. Почему-то сытые нулевые с составами шальных денег от инвесторов привели к уверенности, что так будет всегда, почему так решили - загадка.
Про государство:
Государство влило тонны денег импортозамещение, часть решений сделаны через ректальный интерфейс, кто виноват, государство? Или может кривой менеджмент и не сильно прямые руки сотворили сие? Вопрос риторический.
Про изоляцию:
Если рассматривать изоляцию, как перегрузку и оптимизацию ресурсов, то она на период 10-15 лет вполне благо. Если это время потратить на борьбу с ветряными мельницами, ну да безнадежно отстанешь, все в руках того самого бизнеса.
Что не так с ИТ на рынке РФ:
Все прогнозируемо и ожидаемо, с дистанции уходят те, кто не считал ресурс в нулевые-десятые, деньги на рынке есть, заказчики есть, следовательно место тех, кто уйдет займут другие, вот собственно и все.
Ответ "не знаю" истина при условии, что модель не знает времени.
Ответ "у меня 5 апреля 2050 года" истина, если у модели такое время внутри ее ЦОД.
Ответ "какое у вас время не знаю" истина, если модель не знает, где физически находится пользователь.
Ответ любое значение - истина, вы не указали текущая дата где, может вас в Альфа-Центавре интересует время. Другое дело, что логичнее не отвечать, а задать уточняющий вопрос. Однако как показывает практика люди сами крайне редко уточняют условия задачи, а потом удивляются почему решения считаются Заказчиком не верным. В этом плане модель ведет себя как обычный человек.
ТБ данных, астрономические мощности и на выходе, ой очередная модель потеряла контекст беседы, энергетическая/экономическая эффективность ИИ до сих пор у меня вызывает вопросы.
Пример из мира простых людей:
5 марта 1994 я со своим другом начал беседу о перемещении белков в условиях невесомости при воздействии сильных электромагнитных полей. Собственно дискуссия была о технической применимости летательного аппарата, использующего для перемещения электромагнитные поля, совместимого с человеком. Беседа продолжается до сих пор, следующая итерация запланирована на ноябрь 2026. Частота итераций очень разная, в зависимости от аргументов для анализа. Что интересно за эти годы контекст беседы не потерян и фраза - подожди, вот в расчете от 2 декабря 2002 ты не учитывал вот эти факторы (список) не вводит в ступор, просто потому, что ты прекрасно помнишь этот расчет и почему ты не учитывал те или иные факторы. Сколько стоит процесс, а ничего он особо не стоит, один из многих фоновых процессов. Развлечение для интеллекта, профилактика памяти.
Вопрос: как быстро ИИ сможет держать контекст беседы на 10-20-30 лет без особых затрат?
Как и обещал, про отношения и формат коммуникаций.
Они строятся всегда индивидуально с каждым Заказчиком. В описываемой истории мной был предложен формат коммуникации, который был принят заказчиками, стилистика общения была подобрана индивидуально на основании профессионально-эмоционального "портрета" заказчика.
Формат: за день до встречи план встречи: обсуждаемые задачи, предлагаемое решение, персоналии, которые будут нужны для обсуждения задачи, запрашиваемое время на встречу. По результатам встречи итоговая резолюция подписанная Заказчиком.
Стилистика: открытость, трансформирование проблем в задачи, общение на одном языке.
Как было до меня:
Запрос ИТ департамента: тут проблема есть, сервер старый, текущему SLA не соответствует, его бы апргейдить и купить новый HP, а старый slave сделать, ну мы в 20к зелени по курсу уложимся(с)
Ответ фин. департамента: финансирование закупки в бюджете на 3 квартал не заложено.
Как я действовал:
Запрос встречи:
Обсуждаемая задача: выделение средств на закупку серверного оборудования.
Необходимое время на обсуждение: 10 минут. Предлагаемое время встречи - с учетом Вашего графика предлагаю обсудить данную задачу завтра 21.08.0000 во временном диапазоне с 15 до 16 часов.
Суть задачи: у меня вызывает большую обеспокоенность тот факт, что в бюджет на 3 квартал не заложены средства на закупку серверного оборудования, что может привести к финансовым и репутационным потерям. Предлагаю ознакомится с оценкой рисков.
Финансовые риски: Остановка текущего сервера приведет к финансовым потерям компании 450 000 - 480 000$ и остановке оперативной деятельности финансового департамента на 7-10 дней. Полный финансовый расчет прилагается к данному документу.
Юридические последствия: по информации юридического департамента остановка оперативной деятельности финансового департамента может привести к неисполнению Контрактов №1, 78, 95, 455..., что, в свою очередь, приведет к финансовым потерям по самой скромной оценке в 1 758 467 $. Юридический анализ прилагается к данному документу.
Предлагаемое решение: согласовать с Генеральным директором выделение дополнительных средств на закупку оборудования. Пакет документов на закупку прилагается к данному документу, бюджет закупки 20 000 долларов в рублевом эквиваленте по текущему курсу. Сроки поставки оборудования 10 дней.
Ответ фин. департамента: встреча не понадобится, закупка согласована, оплату будет осуществлена в течении 2-х рабочих дней, договор поставки будет подписан завтра, подписание договора с юр. департаментом согласовано.
Взаимодействие с Заказчиком, это вообще тема отдельной статьи, вечная проблема на нашем рынке, понимание проект менеджером, кто реальный Заказчик. В описываемой истории заказчиков было два:
1. Владелец бизнеса, его интерес -решить задачу фин. департамента в такие-то сроки с таким-то бюджетом. Сроки в плюс не двигаются, бюджет двигается в плюс до 31%, при условии, что фин. департамент даст добро на увеличение.
2.Фин. директор - функциональный заказчик, его интерес решение вопросов с отчетностью в такой-то срок.
Про оценку:
Моя персональная оценка: провальный проект. Я считаю, что оценка рисков это база для проектного менеджера, в данном случае я риск ухода команды не учел. Из этого следует не верная оценка управления инвестициями, команда это инвестиция.
Оценка владельца бизнеса: задача выполнена. Подтверждение оценки - каждый участник команды получил премию в размере 3-х окладов.
Оценка фин. директора: задача выполнена. Подтверждение - официальная благодарность (как утверждали старожилы это впервые в истории компании), увеличение бюджета ит департамента на 25% на следующий год.
Про отношения отвечу чуть позже писать долго, вполне возможно это будет полезно начинающим специалистам.
Так это SSD 7Тб/с, там другие ограничения будут в реальной жизни. Я же говорил про то, что берем тормознутый HDD, добавляем большой кэш, для определенных применений получаем решение - горячие данные всегда в кэше, а холодные на HDD. Сейчас время этого решения наверное уже ушло, но лет 15 оно вполне было себе актуально при нормальной реализации, а не как в свое время делали SSHD (редкостное поделие).
До всех кризисов память стоила копейки, казалось бы почему не воткнуть 64 gb в жесткий диск в кэша, но даже серверные решения даже близко не имели такого кэша. Почему, причина не техническая,а финансовая.
По теме статьи мнение:
С кэшем процессора, далеко не все решения имеют техническую составляющую, очень часто решение имеет даже не экономическую, а маркетинговую составляющую.
Люди порой усложняют там, где это не нужно. У меня был опыт работы с коллегой на удаленке более 5 лет. Человек работал в режиме черного ящика, на входе задачи и критерии выполнения задачи, на выходе результат. Позиция аналитик, провальных проектов за 5 лет не было, срывов сроков тоже, корректировка результата работы не требовалась, если входные данные были истиной. Ну и что еще надо? Через три года работы в офисе шутили, может его вообще не существует, а это все ИИ? Первый раз живьем я его увидел через 4,5 года работы, за все время работы было 3 созвона, все остальное по почте. Возможно кому-то так работать не комфортно, режим общения, как с роботом, ничего лишнего, все только по существу задачи, эмоции отсутствуют как класс, только логика и факты.
Спасибо за статью было весьма интересно. Что касается топ вопросов, вы действительно хотите услышать на них ответы? Вспоминались история из глубоко прошлого.
Проект:
Задача: реформировать департамент разработок, перевести центральный офис и филиалы на новую версию 1С, причесать зоопарк конфигураций. Заказчик производственная компания. Набрать дополнительных разработчиков, бюджет на 6-8 человек. Время реализации 5 месяцев. На анализ аппаратной инфраструктуры Заказчика, закупку и монтаж оборудования 32 дня. Допустимое время простоя на этапе внедрения ИС 180 минут. Сократить техдолг по формированию финансовой отчетности на 45%. Ограничения - стоимость простоя компании без 1С 50 000$ в день.
Старт: 2 разработчика (на грани увольнения - дятлы бесполезные(с) цитата Заказчика), 2 админа уровень самооценки Бог, уровень знаний Буратино, 4 филиала, 16 различных конфигураций 1С, прекрасный микс 7/8 версий. В качестве консультанта фин. директор 35 минут в день на решение всех вопросов по внедрению. Утверждение решений ген. дир. два раза в неделю есть 10 минут.
Что сделано: собрана команда из 7 человек (ушло 2 недели), старые разработчики были оставлены отличные спецы, просто их не умели "готовить". Проведен предпроектный анализ бизнес-задач заказчика (34 дня). Анализ инфраструктуры 37 часов, поставка и монтаж оборудования 8 дней. Проектная документация 14 дней, параллельно происходил перенос данных в новую конфигурацию. Новая версия запущена через 62 дня. Просчет один, расчетное время недоступности систем при переезде было 30 минут, по факту системы были недоступны 86 минут. Техдолг закрыт на 77%. Успех - нет.
Резюме: проект провальный, почему? Я собрал команду под себя, а не под компанию, после моего ухода команда встала и ушла в течении 2-х дней, хотя я не рассматривал такой вариант развития событий. Причина ухода коллег - мы без лидера работать не будем(с).
А теперь вопрос: кто-то правда считает, что такую историю стоит рассказывать на собеседовании?))))
Когда вышел Delphi то реклама орала, что программисты будут не нужны, а просто пользователь с техническими знаниями просто нарисует себе нужное приложение. Вот мне интересно, как ИИ обоснует, что не взлетело.
Вопрос номер два, вот есть готовый софт, к примеру OO, ИИ сможет написать клон, к примеру на Nim без участия программиста. Если нет, то революция отменяется, а жаль. Пока я не видел работающих решений на базе ИИ, которые в состоянии создать клон нет самых сложных приложений, я уж молчу про что-то новое.
И еще, экономика говорите, экономика это деньги, а как показывает практика ЦОД не бесплатные, как следствие даже то, что ИИ создает стоит не мало, а если убрать рекламные акции, то цена владения решением, которое создается ИИ в разрезе 5-10 лет может быть весьма затратным.
Бизнес порой интересует коробочное решение по взаимодействию с гос. контролирующими органами. Схема: client на арм компании ->защищенный канал-> провайдер услуг-> гос. орган( прокуратура, СК, налоговая и т.д.). От провайдера требуется подтверждение, что вот это пакет документов доставлен до адресата, по пути следования утечек нет, от адреса фид. бэк пакет получен. Готовый кейс, который пока в нормальном виде не реализован, реализуете получите приятную прибыль, может не сильно большую, но стабильную.
Второй кейс, взаимодействие различных гос. учреждений и частных компаний (не больших), опять таки решение из коробки, рассчитанное на на ИТ департамент на 300 человек, а на то, что у абонентов ИТ специалисты не представлены. Опять таки для нормального обмена конфиденциальной информацией.
Про удаленку: Что мешает поставить VipNet coordinator и VipNet клиент и работай себе в защищенном сегменте, хоть из Владика, хоть из Архангельска, нужно усилить безопасность пользуйся дополнительным шифрованием, меняй ключи, методов масса.
Мнение: Перевод людей в офисы не связан с РКН, а связан с неумением строить распределенные команды, не желанием строить эффективный бизнес и желанием пускать пыль в глаза и рубить деньги на некомпетентности инвесторов.
Наблюдение: 80% офисов, которые я видел за 30 лет сливают по эффективности распределенной команде работающей на удаленке. Сравнение ведется при равных затратах. Можно ли построить эффективный офис, можно, но это очень дорогая игрушка.
Деньги и логика: Грубая оценка из практики 2005-2026 на сегодняшние деньги, бюджет удаленщика 300 000, такой же по эффективности сотрудник в офисе обойдется в 800 000, если вы умеете считать деньги и считаете все затраты, а не только ФОТ. А теперь, покажите мне живого инвестора, который будет топить за людей в офисе и согласен увеличивать затраты?
Пожалуйста. Вот вдогонку еще подумалось, что порой проблемы проистекают из лишнего использования иностранных терминов.
Примеры:
Можно использовать термин газлайтинг, а можно использовать русские слова агрессия и насилие,в зависимости от ситуации. Русский вариант сработает на всех поколениях, а английский часть сотрудников воспримут, как информационный шум.
Можно использовать слово менеджер, по факту размыто, а вот если используешь слово управленец, сразу видны границы.
HR на заметку. Мы ищем тимлида, в голове возникает - вы серьезно, вам нужен еще один лидер в компании, чтобы создать конфликт? А я вот думаю, что вам нужен руководитель команды. Нет нам нужен лидер, а тогда вы понимаете, что если это настоящий лидер, то в случае, если он уйдет команда уйдет с ним. Вам такой вариант развития зачем?
И вот таких нюансов масса и если внимательно смотришь за конфликтами внутри компаний, то отчетливо видно, что не правильная/не точная терминология закладывала конфликт на старте.
Спасибо за статью, было интересно. Как мне кажется, одна из основных проблем это подмена понятий.
Адаптивность: штука хорошая, вот только не стоит софистику и бардак считать адаптивностью, адаптивность это умение быстро включится в другое направление деятельности. Навык, который далеко не всех позициях нужен, а на некоторых может даже быть вреден.
Обучаемость: умение решать задачи, а не умение работать по 12 часов вместо 8 за те же деньги, а часто как раз именно второе понимают под обучаемостью. Более того я знаю двух классных спецов, один разберется в вопросе за день, другому нужно 2-3 дня, однако второй лучше формулирует стратегические решения, а первый тактические. Кто из них хуже?
Стрессоустойчивость. Под ней можно понимать быстрое принятие решения в случае аварии на технологической линии, а можно понимать умение функционировать в атмосфере помойки, первое инженеру может пригодится, второе полезный навык, но лучше в такие места не попадать.
Коммуникабельность. Под ней понимают умение изворачиваться, хотя по мне необходимое и достаточное условие для технического специалиста - вежливость и умение логично излагать свои мысли, если при этом он умеет излагать мысли адаптивным языком вообще сказка.
Тайм менеджмент: очень полезная штука, если идет в связки с экономикой, а не в режиме технарь должен быть волшебником, а менеджер может быть кем угодно. Почему экономика, а потому что частая смена задач это убытки, если посчитать в ретроспективе 3-5 лет.
Эмоциональный интеллект: прекрасная вещь, но лично я, на месте управленца, предпочту от специалиста краткость: сервак упадет, данные утекут, объем данных такой-то, последствия 3-7 лет курорта строго режима. А вопросы дипломатии стоит оставить продактам для общения с Заказчиками.
Размышления: Два проекта, постановка задачи схожая, есть тонна нормативной документации, нужно автоматизировать процесс регламентной отчетности, сроки вчера. Подробности - сами найдете.
Первый проект: как проектировать Систему решали разработчики, не плохой продукт технически, однако задачи Заказчика не решает, на выходе срыв сроков, штрафы и судебное разбирательство.
Второй проект на входе связка ПМ+юрист+фулстек аналитик, на выходе техническая реализация не хуже ( разработчики те же), проект сдан в сроки, Заказчик доволен.
Вопрос: так нужен ли аналитик в проекте?
Очень странная мотивация, все в кучу накидали. Частная компания может себе купить сертифицированный ФСБ СКЗИ и поднять защищенный канал, очень сомневаюсь, что он попадет под бан и организовать удаленному сеньору защищенное рабочее место.
Ипортозамещение тормозится в том числе, что на местах частенько строят из себя "барышень из Смольного" я не хочу, мне не удобно и т.п. причем технического обоснования почему не хочет и почему не удобно не следует.
Другое дело, что частенько наблюдается блокировка без нужной технической подготовки и летят "в ад" сервисы, которых по дороге зацепило, это проблема.
На мой взгляд идет бессмысленное разбазаривание ресурсу, вместо построения защищенных сетей для бизнеса, ломают старые сети, а в замен ничего толкового не предлагается или я этих предложений не вижу.
Размышления:
Работа технического писателя зависит от задачи, если он не понимает, какую задачу решает система, то результат будет плачевный.
Знание нормативной документации, как внутренней, так и внешней это база. Без этой базы получаются прекрасные технические руководства, которые при нынешнем законодательстве тов. прокурор может интерпретировать, как вещ. док для получения путевки от 3 до 7 лет в места отдаленные.
Постоянно придется изучать языки, нет не английский или немецкий, а языки на котором говорят разные специалисты и пользователи, чтобы потом не возникали в документации перлы - "мокирование данных в тестах", хотя бы потому, что 1 марта 2026 году уже прошло и правила новые.
Без хорошего инженерного образования, работать в целом можно, но тяжко, потому, что ты не понимаешь, что то, что тебе скинул технический департамент - ересь.
Поможет ли LLM техническому писателю, в целом поможет на узком спектре задач, глобально - нет.
Пример из жизни:
Задача: нужно написать ЧТЗ на группу подсистем АИС.
Ресурсы: аналитики предоставили ФТ и НФТ, технический департамент предоставил ЭД на ЦОД и интеграции, юридический департамент кинулся контрактом на разработку, в котором есть ТЗ, сроки и работы, условия приемки контракта.
Оценка сроков: Руководство - задача типовая, за неделю технический писатель напишет, руководитель проекта - точные сроки дадим через два дня, но в целом плюс-минус за неделю уложимся.
По факту: разработка заняла 2 месяца. Причина - участники процесса слабо разбираются в документации, не смотря на весь свой опыт и регалии. Как происходил процесс:
Анализ документации - неделя, выводы с такой документацией в
ы слоника не продадитеконтракт не закроете, а теперь подробнее:НФТ не соответствует законодательству, как следствие две недели согласования и изменение формулировок.
ЭД на ЦОД и интеграции, это не документация, а записки старого гика на бабушкиных манжетах. В результате три недели на приведение сего опуса в нормальный вид. Созданная ЭД в последствии успешно прошла независимую экспертизу.
Контракт на разработку юридически грамотный, одна проблема в том, что ТЗ в нем также похоже на нормальное ТЗ, как сказки братьев Гримм на налоговый кодекс. В результате еще 2 недели на перевод ТЗ контрактного в ТЗ нормально техническое.
После чего действительно за неделю было написано ЧТЗ.
Резюме: к сожалению, многие путают работу технического писателя и работу оформителя/корректора, это разные работы и разные квалификации.
Размышления: рынку нужны профессионалы, отбор жесткий, владельцы высказывают резкую обеспокоенность дефицитом кадров и падением прибыли. Интересно, а как в реальности дела с наймом?
Сбор статистики: Позиция аналитик. Собрана ретроспектива коллег по цеху, которых я считаю хорошими специалистами, судя по успешным проектам они такими и являются). Круг не большой 19 человек, уровень проектов от 120 млн за проект, стаж работы на данной позиции от 15 лет.
2022 год:
количество этапов собеседования 6-8;
среднее время переговоров 2,5 месяца;
вес в принятии решений - хард скилы 30%, софт скилы 70%;
что нужно в реальной работе софт скилы 20%, хард скилы 80%;
результативность 10-ки переговоров 8 офферов на 2 отказа.
2025-2026 год:
количество этапов собеседования 10-12;
среднее время переговоров 4 месяца;
вес в принятии решений - хард скилы 10-15%, софт скилы 85-90%;
что нужно в реальной работе софт скилы 20%, хард скилы 80%;
Результативность 10-ки переговоров 7 офферов, 1 отказ, 2 ушли в размышления.
Резюме: найм замедлился, реальные задачи не поменялись, дефицит специалистов никуда не делся.
Вопрос: владельцы бизнеса в курсе, как у них найм происходит, если им показать, приведенные выше цифры, никаких мыслей не возникнет?
Попросите Василису она Вам напишет код на русском, а если подружите ее с синим волком, то под Сферой никакая телега не просочится, а отчеты будете получать в былинном стиле-))))
Размышления:
За свою карьеру я видел много компаний, успешных, средних, убыточных, но единицы из них понимали, что они зарабатывают деньги решая задачи пользователей, а не реализую собственные амбиции/фантазии. Некоторые из тех, кто закрывал проблемы пользователей успешно развиваются с 90-х, я говорю про небольшие ИТ компании, а не про монстров рынка.
Про ситуацию на рынке:
Ситуация на рынке сейчас средней сложности, часть компаний уходит в небытие исключительно по законам капиталистической экономики. Почему-то сытые нулевые с составами шальных денег от инвесторов привели к уверенности, что так будет всегда, почему так решили - загадка.
Про государство:
Государство влило тонны денег импортозамещение, часть решений сделаны через ректальный интерфейс, кто виноват, государство? Или может кривой менеджмент и не сильно прямые руки сотворили сие? Вопрос риторический.
Про изоляцию:
Если рассматривать изоляцию, как перегрузку и оптимизацию ресурсов, то она на период 10-15 лет вполне благо. Если это время потратить на борьбу с ветряными мельницами, ну да безнадежно отстанешь, все в руках того самого бизнеса.
Что не так с ИТ на рынке РФ:
Все прогнозируемо и ожидаемо, с дистанции уходят те, кто не считал ресурс в нулевые-десятые, деньги на рынке есть, заказчики есть, следовательно место тех, кто уйдет займут другие, вот собственно и все.
Ответ "не знаю" истина при условии, что модель не знает времени.
Ответ "у меня 5 апреля 2050 года" истина, если у модели такое время внутри ее ЦОД.
Ответ "какое у вас время не знаю" истина, если модель не знает, где физически находится пользователь.
Ответ любое значение - истина, вы не указали текущая дата где, может вас в Альфа-Центавре интересует время. Другое дело, что логичнее не отвечать, а задать уточняющий вопрос. Однако как показывает практика люди сами крайне редко уточняют условия задачи, а потом удивляются почему решения считаются Заказчиком не верным. В этом плане модель ведет себя как обычный человек.
Просто размышления про ИИ:
ТБ данных, астрономические мощности и на выходе, ой очередная модель потеряла контекст беседы, энергетическая/экономическая эффективность ИИ до сих пор у меня вызывает вопросы.
Пример из мира простых людей:
5 марта 1994 я со своим другом начал беседу о перемещении белков в условиях невесомости при воздействии сильных электромагнитных полей. Собственно дискуссия была о технической применимости летательного аппарата, использующего для перемещения электромагнитные поля, совместимого с человеком. Беседа продолжается до сих пор, следующая итерация запланирована на ноябрь 2026. Частота итераций очень разная, в зависимости от аргументов для анализа. Что интересно за эти годы контекст беседы не потерян и фраза - подожди, вот в расчете от 2 декабря 2002 ты не учитывал вот эти факторы (список) не вводит в ступор, просто потому, что ты прекрасно помнишь этот расчет и почему ты не учитывал те или иные факторы. Сколько стоит процесс, а ничего он особо не стоит, один из многих фоновых процессов. Развлечение для интеллекта, профилактика памяти.
Вопрос: как быстро ИИ сможет держать контекст беседы на 10-20-30 лет без особых затрат?
Как и обещал, про отношения и формат коммуникаций.
Они строятся всегда индивидуально с каждым Заказчиком. В описываемой истории мной был предложен формат коммуникации, который был принят заказчиками, стилистика общения была подобрана индивидуально на основании профессионально-эмоционального "портрета" заказчика.
Формат: за день до встречи план встречи: обсуждаемые задачи, предлагаемое решение, персоналии, которые будут нужны для обсуждения задачи, запрашиваемое время на встречу. По результатам встречи итоговая резолюция подписанная Заказчиком.
Стилистика: открытость, трансформирование проблем в задачи, общение на одном языке.
Как было до меня:
Запрос ИТ департамента: тут проблема есть, сервер старый, текущему SLA не соответствует, его бы апргейдить и купить новый HP, а старый slave сделать, ну мы в 20к зелени по курсу уложимся(с)
Ответ фин. департамента: финансирование закупки в бюджете на 3 квартал не заложено.
Как я действовал:
Запрос встречи:
Обсуждаемая задача: выделение средств на закупку серверного оборудования.
Необходимое время на обсуждение: 10 минут. Предлагаемое время встречи - с учетом Вашего графика предлагаю обсудить данную задачу завтра 21.08.0000 во временном диапазоне с 15 до 16 часов.
Суть задачи: у меня вызывает большую обеспокоенность тот факт, что в бюджет на 3 квартал не заложены средства на закупку серверного оборудования, что может привести к финансовым и репутационным потерям. Предлагаю ознакомится с оценкой рисков.
Финансовые риски: Остановка текущего сервера приведет к финансовым потерям компании 450 000 - 480 000$ и остановке оперативной деятельности финансового департамента на 7-10 дней. Полный финансовый расчет прилагается к данному документу.
Юридические последствия: по информации юридического департамента остановка оперативной деятельности финансового департамента может привести к неисполнению Контрактов №1, 78, 95, 455..., что, в свою очередь, приведет к финансовым потерям по самой скромной оценке в 1 758 467 $. Юридический анализ прилагается к данному документу.
Предлагаемое решение: согласовать с Генеральным директором выделение дополнительных средств на закупку оборудования. Пакет документов на закупку прилагается к данному документу, бюджет закупки 20 000 долларов в рублевом эквиваленте по текущему курсу. Сроки поставки оборудования 10 дней.
Ответ фин. департамента: встреча не понадобится, закупка согласована, оплату будет осуществлена в течении 2-х рабочих дней, договор поставки будет подписан завтра, подписание договора с юр. департаментом согласовано.
Про Заказчика:
Взаимодействие с Заказчиком, это вообще тема отдельной статьи, вечная проблема на нашем рынке, понимание проект менеджером, кто реальный Заказчик. В описываемой истории заказчиков было два:
1. Владелец бизнеса, его интерес -решить задачу фин. департамента в такие-то сроки с таким-то бюджетом. Сроки в плюс не двигаются, бюджет двигается в плюс до 31%, при условии, что фин. департамент даст добро на увеличение.
2.Фин. директор - функциональный заказчик, его интерес решение вопросов с отчетностью в такой-то срок.
Про оценку:
Моя персональная оценка: провальный проект. Я считаю, что оценка рисков это база для проектного менеджера, в данном случае я риск ухода команды не учел. Из этого следует не верная оценка управления инвестициями, команда это инвестиция.
Оценка владельца бизнеса: задача выполнена. Подтверждение оценки - каждый участник команды получил премию в размере 3-х окладов.
Оценка фин. директора: задача выполнена. Подтверждение - официальная благодарность (как утверждали старожилы это впервые в истории компании), увеличение бюджета ит департамента на 25% на следующий год.
Про отношения отвечу чуть позже писать долго, вполне возможно это будет полезно начинающим специалистам.
Так это SSD 7Тб/с, там другие ограничения будут в реальной жизни. Я же говорил про то, что берем тормознутый HDD, добавляем большой кэш, для определенных применений получаем решение - горячие данные всегда в кэше, а холодные на HDD. Сейчас время этого решения наверное уже ушло, но лет 15 оно вполне было себе актуально при нормальной реализации, а не как в свое время делали SSHD (редкостное поделие).
Размышления:
До всех кризисов память стоила копейки, казалось бы почему не воткнуть 64 gb в жесткий диск в кэша, но даже серверные решения даже близко не имели такого кэша. Почему, причина не техническая,а финансовая.
По теме статьи мнение:
С кэшем процессора, далеко не все решения имеют техническую составляющую, очень часто решение имеет даже не экономическую, а маркетинговую составляющую.
Мысли про удаленку:
Люди порой усложняют там, где это не нужно. У меня был опыт работы с коллегой на удаленке более 5 лет. Человек работал в режиме черного ящика, на входе задачи и критерии выполнения задачи, на выходе результат. Позиция аналитик, провальных проектов за 5 лет не было, срывов сроков тоже, корректировка результата работы не требовалась, если входные данные были истиной. Ну и что еще надо? Через три года работы в офисе шутили, может его вообще не существует, а это все ИИ? Первый раз живьем я его увидел через 4,5 года работы, за все время работы было 3 созвона, все остальное по почте. Возможно кому-то так работать не комфортно, режим общения, как с роботом, ничего лишнего, все только по существу задачи, эмоции отсутствуют как класс, только логика и факты.
Спасибо за статью было весьма интересно. Что касается топ вопросов, вы действительно хотите услышать на них ответы? Вспоминались история из глубоко прошлого.
Проект:
Задача: реформировать департамент разработок, перевести центральный офис и филиалы на новую версию 1С, причесать зоопарк конфигураций. Заказчик производственная компания. Набрать дополнительных разработчиков, бюджет на 6-8 человек. Время реализации 5 месяцев. На анализ аппаратной инфраструктуры Заказчика, закупку и монтаж оборудования 32 дня. Допустимое время простоя на этапе внедрения ИС 180 минут. Сократить техдолг по формированию финансовой отчетности на 45%. Ограничения - стоимость простоя компании без 1С 50 000$ в день.
Старт: 2 разработчика (на грани увольнения - дятлы бесполезные(с) цитата Заказчика), 2 админа уровень самооценки Бог, уровень знаний Буратино, 4 филиала, 16 различных конфигураций 1С, прекрасный микс 7/8 версий. В качестве консультанта фин. директор 35 минут в день на решение всех вопросов по внедрению. Утверждение решений ген. дир. два раза в неделю есть 10 минут.
Что сделано: собрана команда из 7 человек (ушло 2 недели), старые разработчики были оставлены отличные спецы, просто их не умели "готовить". Проведен предпроектный анализ бизнес-задач заказчика (34 дня). Анализ инфраструктуры 37 часов, поставка и монтаж оборудования 8 дней. Проектная документация 14 дней, параллельно происходил перенос данных в новую конфигурацию. Новая версия запущена через 62 дня. Просчет один, расчетное время недоступности систем при переезде было 30 минут, по факту системы были недоступны 86 минут. Техдолг закрыт на 77%. Успех - нет.
Резюме: проект провальный, почему? Я собрал команду под себя, а не под компанию, после моего ухода команда встала и ушла в течении 2-х дней, хотя я не рассматривал такой вариант развития событий. Причина ухода коллег - мы без лидера работать не будем(с).
А теперь вопрос: кто-то правда считает, что такую историю стоит рассказывать на собеседовании?))))
Уведомление в Роскомнадзор о трансграничной передаче данных и целях этой передачи, это отдельная история)
Когда вышел Delphi то реклама орала, что программисты будут не нужны, а просто пользователь с техническими знаниями просто нарисует себе нужное приложение. Вот мне интересно, как ИИ обоснует, что не взлетело.
Вопрос номер два, вот есть готовый софт, к примеру OO, ИИ сможет написать клон, к примеру на Nim без участия программиста. Если нет, то революция отменяется, а жаль. Пока я не видел работающих решений на базе ИИ, которые в состоянии создать клон нет самых сложных приложений, я уж молчу про что-то новое.
И еще, экономика говорите, экономика это деньги, а как показывает практика ЦОД не бесплатные, как следствие даже то, что ИИ создает стоит не мало, а если убрать рекламные акции, то цена владения решением, которое создается ИИ в разрезе 5-10 лет может быть весьма затратным.
Бизнес порой интересует коробочное решение по взаимодействию с гос. контролирующими органами. Схема: client на арм компании ->защищенный канал-> провайдер услуг-> гос. орган( прокуратура, СК, налоговая и т.д.). От провайдера требуется подтверждение, что вот это пакет документов доставлен до адресата, по пути следования утечек нет, от адреса фид. бэк пакет получен. Готовый кейс, который пока в нормальном виде не реализован, реализуете получите приятную прибыль, может не сильно большую, но стабильную.
Второй кейс, взаимодействие различных гос. учреждений и частных компаний (не больших), опять таки решение из коробки, рассчитанное на на ИТ департамент на 300 человек, а на то, что у абонентов ИТ специалисты не представлены. Опять таки для нормального обмена конфиденциальной информацией.
Про удаленку: Что мешает поставить VipNet coordinator и VipNet клиент и работай себе в защищенном сегменте, хоть из Владика, хоть из Архангельска, нужно усилить безопасность пользуйся дополнительным шифрованием, меняй ключи, методов масса.
Мнение: Перевод людей в офисы не связан с РКН, а связан с неумением строить распределенные команды, не желанием строить эффективный бизнес и желанием пускать пыль в глаза и рубить деньги на некомпетентности инвесторов.
Наблюдение: 80% офисов, которые я видел за 30 лет сливают по эффективности распределенной команде работающей на удаленке. Сравнение ведется при равных затратах. Можно ли построить эффективный офис, можно, но это очень дорогая игрушка.
Деньги и логика: Грубая оценка из практики 2005-2026 на сегодняшние деньги, бюджет удаленщика 300 000, такой же по эффективности сотрудник в офисе обойдется в 800 000, если вы умеете считать деньги и считаете все затраты, а не только ФОТ. А теперь, покажите мне живого инвестора, который будет топить за людей в офисе и согласен увеличивать затраты?