Хотела начать текст с шутки про то, что раз инструкции никто не читает, то и писать их не обязательно. Однако 14 лет работы в IT-сфере доказывают, что это всё же довольно глупая шутка. В современных компаниях (не только в IT, но и особенно в IT!) на документации завязаны практически все процессы от проектирования ПО и ведения бэклога до эксплуатации и поддержки пользователей. Люди со стороны часто не догадываются, что в командах кроме суровых разработчиков, дотошных тестировщиков, внимательных сисадминов, осторожных безопасников и продвинутых девопсов трудятся технические писатели. Как правило, они одновременно суровые, дотошные, внимательные, осторожные и продвинутые, потому что именно на них лежит ответственность как за внутреннюю документацию, так и за корректные, грамотные, лаконичные и точные инструкции для пользователей. И писать желательно без девяти прилагательных в одном предложении, как строчкой выше 🙂

Сегодня поговорим об этих ребятах, о профессии, о людях в ней и о том, стоит ли войти в айти именно через вакансию техписа?

NB И да, обязательно читайте цитаты членов сообщества техписов — они рассказывают о самом актуальном в профессии из первых рук.

Вопросы карьерного роста и профессионального развития всегда актуальны, особенно в ИТ. HR-специалисты часто сталкиваются с выбором кандидатов на руководящие позиции в IT и всё чаще задают вопросы, связанные со способами развития сотрудников. И это хорошо.

В этой статье я не стремлюсь провести глубокий академический анализ, а скорее предлагаю размышления, основанные на личном опыте и наблюдениях за IT-индустрией.

Цель статьи — исследовать, что на самом деле означают понятия «рост» и «развитие» в контексте профессиональной жизни IT‑специалиста и как эти аспекты влияют на выбор при найме на руководящие должности.

Про собеседования, аналитиков и не только, на различных IT и не очень ресурсах написано достаточно много. Но ведь это не повод не рассказать, как они происходят у нас — вдруг что-то новое для читателя да и проскользнет? =)

Вторая часть масштабной статьи про собеседования. Первая — тут. В прошлый раз мы поговорили об идеальном кандидате в вакууме, а также о презентационной части собеседования. Здесь же будем говорить про техническую часть и про то, в каком направлении бы хотелось развивать тему с собеседованиями.

В конце добавила секцию с бонусными рубриками — советами и наблюдениями для тех, кто проводит собеседования или приходит на них как кандидат =)

Эта статья, как выразился мой коллега, может «усугублять депрессивное состояние и "экзистенциальный крысис"». Будьте осторожны при прочтении.

Мы попытаемся ответить на главные вопросы современности: научится ли ИИ программировать? Если да, то как быстро? И чьи должности пойдут под нож в первой партии, а кому повезёт поработать плечом к плечу с цифровым напарником?

Целью данной публикации является попытка в тезисной форме напомнить руководителям проектов об основах использования микросервисной архитектуры в проектах создания и внедрения информационных систем, преимуществах таких решений для бизнеса.

Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем в Первой грузовой компании. Сегодня разберем с вами, чем бизнес-аналитик отличается от системного и почему для проектов цифровой трансформации вам нужно два специалиста. Статья будет полезна менеджерам, продуктам, руководителям проекта. Всем кому надо объяснять, или кто сам хочет разобраться, в чем отличие бизнес и системных аналитиков. 

Часто всем участникам проекта хочется оптимизировать трудозатраты и бюджет. И очень светлая мысль, которая возникает у каждого второго продукта или РП: “А давайте у нас будет один аналитик, который сделает всё!”. У руководителей более высокого уровня, топов и собственников это идея возникает в 9 случаев из 10. В результате сроки сорваны, бюджет превысили в два раза. Почему так происходит и будет происходить разберем ниже. 

Основную идею этой статьи донесу через аналогию, а затем разберемся предметно. 

Представьте, вы участвуете в соревнованиях по многоборью. Надо преодолеть дистанцию за максимально короткое время. И вам как менеджеру команды можно набрать любое количество спортсменов, которое может позволить бюджет. Вы заранее знаете, какую местность надо преодолеть. Допустим, это будет, равнина, озеро и отвесная скала. 

С отвесной скалой все понятно. Точнее понятно, что ничего не понятно – нужны подготовленные спецы, которые быстро заберутся наверх и при этом не разобьются в лепешку. Поэтому профессионального скалолаза берем в команду 100%. А вот с равниной и озером не все однозначно – ведь плавать и бегать все умеют. Есть большой соблазн взять в команду одного спортсмена, а на сэкономленные деньги и время еще и интерфейс в синий покрасить. Вот так и формируются команды разработки, где есть выделенные разработчики (скалолазы) и аналитики (бизнес и системный анализ в одном флаконе). 

Одной из основных задач для Enterprise архитекторов является проектирование и проведение работ по интеграции различных ИТ систем. Так типичной историей является наличие у заказчика каких-то решений, либо не взаимосвязанных, либо частично связанных между собой и архитектору необходимо встроить свое решение, интегрировав его с теми решениями, которые уже есть у заказчика.

Далее мы рассмотрим несколько подходов к интеграции, и начнем с простейшего случая, когда между системами нет интеграции.

То есть, представим ситуацию, когда в компании используются несколько независимых информационных систем: складская, бухгалтерская, CRM и финансовая. Между этими системами нет информационного обмена.

В результате для выполнения задачи по отгрузке товара, заявки в каждой системе заводятся отдельно и к примеру, менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему, вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов.

В результате у нас образуется некоторый «Paper Net», то есть бумажный обмен данными между менеджерами, бухгалтерией и складом, а также двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской).

Кроме того, когда заявки в каждой системе заводятся вручную, то большую роль начинает играть человеческий фактор, то есть ошибки, допускаемые различными специалистами в процессе обработки заявок в системах.

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

Пока что умение специалистов и команд выявлять и формулировать такие ограничения представляет собой скорее искусство, а не ремесло, и не инженерию.

Давайте попробуем сделать это хотя бы ремеслом.

В начале каждого года мы на Хабр Карьере подводим итоги предыдущего для компаний: просим специалистов справедливо оценить своих прошлых и нынешних работодателей. Дальше собираем оценки и составляем рейтинг компаний с лучшими условиями для работы.  

Оценки за прошлый год собраны, и мы открываем рейтинг лучших IT-работодателей России в 2023. Ниже — про качества, за которые их особенно ценят.

Привет, я работаю в сфере уже около 10 лет, преимущественно по специальности чистой продуктовой аналитики. Иногда я оглядываюсь назад и думаю — с текущим пониманием что и как устроено в работе, как бы я выстраивал свой процесс обучения с нуля?

Эта статья — мои мысли на эту тему. В каком порядке и какие материалы впитывать, чтобы потом комфортно себя чувствовать в любой продуктовой компании.

Из челленджей — все материалы должны быть бесплатными, или достаточно дешёвыми, чтобы была возможность бросить учёбу на пол пути (ну не зашло, бывает) и не жалеть о потраченных деньгах на мега-курс от %big_tech_name%.

В этой статье я попробую собрать план обучения профессии, как бы я вкатывался сейчас, что бы изучал раньше, что позже, на что бы потратил больше сил и времени и т.д. У некоторых пунктов будут аналоги, можно выбрать на свой вкус без потерь качества.

По итогам всех усвоенных материалов, это будет уровень знаний примерно middle+, но фактически, грейды зависят больше от опыта (особенно в программировании), чем от объёма знаний.

И последнее — я тут не пытаюсь продать курсы, поэтому обещать что будет весело, интересно и быстро, а потом вас наймут на 300к/наносек я не буду. Будет долго, местами сложно, иногда душно, пару раз вы захотите слиться и бросить эту идею. Но… нет, тут не будет но 🙂

Ладно, пожалуй хватит предисловия, поехали.

SQL (Structured Query Language) – это язык программирования, используемый для управления реляционными базами данных. В этой статье я собрал вопросы по SQL, с которыми вы можете столкнуться на собеседовании. Их часто задают для проверки общих знаний и навыков.

Пришло время снова смотреть, сколько зарабатывают IT-специалисты, а точнее — сколько им платили во второй половине 2023. 

Напомним, что каждые полгода мы на Хабр Карьере анализируем зарплаты в IT и отслеживаем изменения на рынке. В этот раз мы изучили 34 114 зарплат, приглашаем обсуждать результаты.

Медианная зарплата IT-специалистов сейчас — 141 000 ₽, это на 15% меньше, чем в первом полугодии 2023, когда рост был 10%. В основном на это повлияло снижение зарплат в регионах на 20%, где IT-специалистам сейчас платят в среднем 120 000 ₽. В Москве средняя зарплата — 187 000 ₽, а в Санкт-Петербурге — 150 000 ₽.

В последнее время наблюдаю тенденцию увеличения обязанностей системного аналитика, и, кажется, в явном виде об этом никто не говорит. Наоборот, смотря профессиональные чаты и общаясь с коллегами, я в большинстве случаев считываю превалирующую мысль, что системный аналитик — это специалист, который должен и может всё: и бизнес-цели по SMART поставить, и базу данных разработать. Мне как системному аналитику видится в такой тенденции будущая проблема моей профессии: знания и достижения, которые я приобретаю сейчас, будут обнуляться на каждом новом проекте, потому что там от меня будут ожидать что-то совсем другое. В этой статье пробую разобраться почему системный анализ как подход к решению задач превратился в должность “человек-оркестр”?

Темой поста на сегодня будет список конференций для аналитиков. Вообще, я продолжаю ежегодный обзор конференций для ИТ специалистов, просто как то так сложилось, что несколько лет назад я крайне заинтересовался конференциями, т.к. хотелось понять, что же там говорят различные эксперты, каковы новые технологические веяния, как работают успешные специалисты и начал понемногу собирать информацию из различных источников и как не странно, нормального источника - нет, но хотя бы есть какие то статьи в интернете! Большая часть материала, который я отсмотрел либо продажа собственной конференции и партнеров или проплаченную реклама, а так хочется понять куда сходить и не просто куда то, а на нормальное мероприятие, где высокий уровень докладов, классно продуманная организация мероприятия и необыкновенная неформальная часть.

Представьте, что в рецепте для приготовления еды была бы вводная часть о том, откуда привезли продукты, как их упаковывали и доставляли.

Вы бы стали читать рецепт из 10 страниц, чтобы приготовить салат? Что-то я сомневаюсь. Схожая ситуация бывает в документации, когда она пишется без шаблона по принципу "чем больше, тем лучше".

Если ваши  документы не читают, не понимают, или вы не знаете с чего начать описывать интеграцию,  то эта статья для вас.

Я тех.лид системных аналитиков и прошла долгий путь к шаблонам документации в разных компаниях.

Всем привет!

Меня зовут Станислав, сейчас я работаю старшим системным аналитиком в отделе развития голосового антифрода.

Сейчас в мои задачи входит анализ и управление требованиями к веб-приложению для настройки проверок параметров вызовов. Помимо описания взаимодействия между front- и back- слоями, я взаимодействую со смежной командой для проработки интеграции между нашим приложением и модулем принятия решений по результатам проверки параметров вызовов.

Глядя на свою текущую работу и сравнивая её со своим опытом работы в бизнес-анализе, я замечаю много схожих подходов к исследованию и выявлению требований. Хочу поделиться с вами своими размышлениями на эту тему и буду рад обратной связи :)