Я люблю давать простые задачки студентам на лекции. Во-первых, понятно, скольких мы потеряли, во-вторых, это переключение из режима потребления информации в режим выдачи результатов, в третьих — возможность проявить себя для шустрых. Сплошные плюсы!

Одна из простых задач звучит так: «При переводе картинки из цветового пространства RGB в YUV мы выполняем прореживание, то есть выкидываем каждый четный столбец и каждую четную строку в компонентах U и V (все компоненты пикселя по 1 байту). Вопрос: во сколько раз меньше данных у нас стало?» Эта операция называется chroma subsampling и широко используется при сжатии видео, например.

Забавно, что когда-то давно, когда винчестеры были меньше, а дискеты больше, студенты реально отвечали на этот вопрос быстро. А в последние годы регулярно народ в ступор впадает. Приходится разбирать по частям: «Если выкинуть каждую четную строку и каждый четный столбец, во сколько раз меньше данных будет у компоненты?» Почти хором: «В четыре». Начинаю подкалывать: «Отлично! У нас было 3 яблока, первое осталось как есть, а от второго и третьего осталось по четвертинке. Во сколько раз меньше яблок у нас стало?» Народ ржет, но, наконец-то, дает правильный ответ (заметим, не все). 

Это было бы смешно, если бы от способности быстро в уме прикинуть результат не зависела способность быстрее создавать сложные алгоритмы. 

И хорошо видно, как эта способность в широких массах студентов заметно плавно падает. Причем не только в нашей стране. Придуман даже специальный термин: «цифровое слабоумие» ("digital dementia") — снижение когнитивных способностей, достаточно серьезное, чтобы повлиять на повседневную деятельность человека. 

Кому интересно как теряют мозг студенты масштабы бедствия и что с этим делать — добро пожаловать под кат!

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

Решил составить для себя план развития (я в IT с 2007, как аналитик - с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что обязательно и желательно знать/уметь.

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

Всем привет!

Меня зовут Коля, и я периодически собеседую кандидатов на позицию системного аналитика. За последние два месяца провёл порядка 20 десятков собеседований. В основном были кандидаты с опытом 1.5-3 года, на пути к уровню Middle и с зарплатными ожиданиями 150-200 тысяч рублей в месяц.

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

Или как понять, когда остановиться

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

— Скажи, а зачем нам вообще нужны аналитики?

— И действительно, зачем? – подумал тогда я и написал заявление

Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет. Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении  системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.

Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.

Если спросить у любого разработчика, каким главным свойством должны обладать системные требования, он, скорее всего, скажет: «чтобы было понятно, что делать». И это проблема. 

Заключается эта проблема в том, что между сбором и систематизацией требований (прямая и понятная задача аналитика) и непосредственно кодированием (прямая и понятная задача разработчика) есть область проектирования решения; задачи из этой области могут и должны выполнять обе роли.

Требования, конечно, меняются. Иногда. Но гораздо чаще случается, что мы не до конца выяснили у заказчика и стейкхолдеров все требования, оставив множество умолчаний.

В этой статье я опишу примеры подобных ситуаций и расскажу о техниках, позволяющих задать нужные вопросы, выявить максимальное количество требований на ранних этапах анализа, обсудить со стейкхолдерами нужность этих требований и их приоритеты. Как правило, после применения всех техник в 1,5−2 раза возрастает объём требований и юзкейсов для обсуждения — и это одна из основных задач аналитика: задать все вопросы и выяснить все детали до начала проектирования и разработки системы.

Возможно, многие подходы вы уже применяете, а о некоторых даже не слышали; я попробую свести их в единую систему.

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

«Эти разработчики опять ничего не поняли!» — возмущается заказчик мобильного приложения. Но мы все знаем, что у разработчиков тонкая душевная организация и куча злых мемов на случай недопонимания с заказчиком. Чтобы не попасть в череду уточнений, согласований и — самое плохое — исправлений ошибок, нужно просто грамотно написать задачу для специалистов. Как это сделать, рассказывает руководитель проектного офиса “CleverPumpkin” Лада Ларкина.

Помните, как вы были студентами, и готовились к экзаменам по ночам?

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

Изучите теорию на примерах и закрепите на 13 практических задачах по SQL.

Мы решили узнать, как работает старый тезис «в интернете всё есть и бесплатно, курите маны, глупцы».

И подготовили программу самоподготовки, собранную из лучших бесплатных или совсем недорогих материалов, которые мы знаем. Общая длительность программы для освоения — от 150 часов.

Обожаю канцелярит. Вот эти все чумовые законы, методические разъяснения, инструкции и т.д. и т.п., написанные нечеловеческим языком для людей. Глубоко в подсознании живет мыслишка, что эти документы созданы где-то в чертогах инопланетного разума с планеты Нибиру. А если за этой нечитаемой клинописью спрятаны важные процессы? Например, в кибербезопасности важно, чтобы каждый сотрудник четко понимал, что и в какой момент он должен сделать. Иначе атака может привести к трагическим последствиям. Понятные инструкции по реагированию на инцидент – это половина успеха или даже больше. Поэтому мы решили поделиться с читателями Хабра нашим подходом к написанию плейбуков. Кстати, некоторые лайфхаки нам подсказали наши заказчики.

Привет! Меня зовут Саша, и я хочу стать хорошим системным аналитиком.

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

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

С одной стороны, решение работающее. С другой, буквально через неделю-две я уже начинал сомневаться, достаточно точно ли я «перевел» с кода на русский язык? И тогда вспомнил про UML-диаграммы. И вместо того, чтобы записывать текст, стал визуализировать его и исписал неимоверное количество тетрадей. 

Но в какой-то момент подумал, что хорошо бы перевести все это в электронный вид, чтобы какой-то инкремент оставался. Не фоткать же, например, для документации, свою тетрадь с каракулями. Так я нашел инструмент PlantUML — opensource-решение, которое использует графическую библиотеку graphviz, превращающее код в наглядные схемы.

Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.

Кто лучше всех знает, как справляться с проблемами? От кого ждут, что он закроет своим хрупким тельцем все бреши в продукте? Тимлиды иногда напоминают собой зонтик, под которым прячется команда. Команда видит — можно особо и не стараться, потому что если что, Вася вытянет. Вася тянет всё больше, и всё начинает ехать на энергии Васи. Энергия заканчивается, и бизнес людей заменяет.

Если все едет на вашей энергии, то… энергия закончится.

Вы не будете двигаться дальше. 

Вас никому не будет жалко.

Александр Орлов, бизнес-коуч и сооснователь школы менеджеров и тимлидов «Стратоплан»  поделился на конференции TeamLead 2021 своими наблюдениями, что происходит с энергией, почему она уходит и почему приходит. Показал, какие инструменты есть для решения проблемы выгорания. Сегодняшняя статья именно об этом. Если вы предпочитаете разговорный формат — для вас видео выступления.

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

Периодически я увлекаюсь [интересными проектами] и забываю «смотреть на приборы», игнорируя сигналы мясного костюма и мозга о том, что пора бы уже и отдохнуть. Замедлиться. Сделать паузу. Выдохнуть.

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

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

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

Мы расскажем о дата-центрической архитектуре — «волшебной пуле», позволяющей забыть об интеграции и открыть новые возможности для создания гибких и управляемых бизнес-приложений, аналитики и монетизации данных за счет их использования при принятии решений.

Мы расширяем нашу команду IT-специалистов и решили пойти против всех известных правил найма в банк. Вместо череды собеседований разного уровня с долгими паузами между этапами и недельным ожиданием результатов — проведём One Day Offer, где можно получить приглашение на работу всего за один день.

Когда?

4 сентября – Java-разработчики (подать заявку нужно до 2 сентября).

11 сентября – JavaScript-разработчики (заявки – до 9 сентября).

18 сентября – системные аналитики (заявки – до 16 сентября).