За 16 лет работы в компаниях разного масштаба, размаха и уровня корпоративного бескультурья мне приходилось видеть весьма экзотические причины увольнения. В топ-3 уверенно попадают увольнение из-за недостаточной высоты двери в туалете, из-за вызова скорой помощи на работу и из-за исчезновения булочек с курагой в меню столовой, отсутствия отдельного кабинета или парковочного места. Я однажды уволилась после фразы замдиректора: «И это последнее китайское предупреждение!» Не зная настоящего смысла этой идиомы, я как истинный самурай совершила карьерное харакири. Но, как нас учили на уроках истории, у каждого события есть причины, а есть повод — последняя капля, после которой срывает резьбу и вершится что-то необратимое. Конечно, булочки, такси не того класса, искры в микроволновке и проч — это всё повод. И часто бывает так, что о причинах никто ничего не знает или все узнают, но слишком поздно. 

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

Кому предложат ЗП 200-, а кому 400+? Собеседование расставит всё на свои места.

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

В 2021 наметился тренд: повышенный спрос на бизнес-аналитиков. Практически каждый проект стремится заполучить в свои ряды специалиста с такой ролью. При этом вакансии с примерно одинаковым описанием должностных обязанностей поражают многообразием названий: requirement specialist, business analyst, system analyst, (proxy) product owner, product manager. Меня зовут Святослав Щербатюк, я сотрудничаю с ЕРАМ в роли ведущего бизнес-аналитика. В этом материале предлагаю порассуждать, почему сложилась такая ситуация, отличаются ли эти роли между собой и если да, то чем.

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

Меня зовут Артемий Богданов, я Chief Hacking Officer в Start X. Находил слабые места в приложениях Uber, Yahoo и ВКонтакте, участвовал в CTF и регулярно провожу пентесты. За годы работы убедился, что реальные кибератаки выглядят совсем не так красочно, как в кино. Никаких сирен и экранов с мигалками. 

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

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

Перенос данных из одного облачного хранилища в другое – сродни переезду. Для того чтобы он не стал пожаром, нужно подготовиться: оценить ваши потребности, возможности разных хранилищ и их ограничения. Вместе с DevOps-командой SimbirSoft рассмотрим несколько популярных сервисов, которые имеют дата-центры на территории страны – Yandex Cloud, VK Cloud Solutions, SberCloud – и разберем первые шаги по переезду. Статья может быть полезна тем, кто ищет площадку для переноса данных из другого облака или традиционной инфраструктуры.

Cистемный аналитик играет ключевую роль в проектировании приложений и построении интеграций. Одним из основных инструментов для этого является REST API и знание REST API — важный навык для системного аналитика. В этой статье мы представим 25 вопросов по REST API, которые помогут вам подготовиться к интервью на вакансию системного аналитика и прокачать свои навыки. Полезного чтения!

Привет! Меня зовут Лёша и я тестирую веб в 2ГИС. Расскажу, зачем мы выделили багам бюджет и наделили их весом, и как мы придумали систему исправления ошибок, из-за которой больше не приходится спорить.

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

На своих проектах мне несколько раз приходилось совмещать роли менеджера проекта и аналитика.

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

С другой, смешивать роли — не всегда самый лучший сценарий. Потому что из фокуса постоянно что-то выпадает, иногда не хватает времени и рук "на всё про всё".
И это влияет на качество результата.

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

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

Цель статьи: попытаться посмотреть на проект глазами аналитика и проджекта, найти точки соприкосновения этих двух ролей и дать вам пищу для самостоятельного ответа на вопрос: совмещение ролей аналитика и ПМ в одном проекте - это хорошо либо плохо?

Давайте для начала обозначим зоны ответственности аналитика и проектного менеджера...

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

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

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

Готовы? Тогда поехали!

Scrum - популярный в командах разработки фреймворк. Но так ли он важен и нужен в действительности?

В статье в формате "вредных советов" приведены порочные практики, которые можно встретить в Scrum-командах.

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

Когда в коллегах согласья нет,
На лад проект их не пойдет,
И выйдет из него не profit, только cost.

Однажды Бэкендер, Фронтендер да Аналитик
Везти с тасками US взялись,
И вместе трое все в него впряглись;

Из кожи лезут вон, а US всё нет ходу!
Таски для них казались и легки:
Да Фронт рвется в Cloud-решения,
Бэк пятится назад, а Аналитик тянет в воду.

Кто виноват из них, кто прав, - судить не нам;
Да только UserStory и ныне там.

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

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

Когда мы начали создавать платформу True Engineering, в компании не было единых правил для оформления архитектуры. Разные команды – разные инструменты, разные обозначения и уровни абстракции. Значит, даже подобные решения сравнить между собой не получится, а тому, кто смотрит на архитектуру проекта в первый раз, обычно нужен проводник, который расскажет, что же тут изображено. Мы решили унифицировать подходы с помощью модели С4, которая обеспечивает всестороннее описание программных архитектур.

Преамбула

Средства

Всякая вещь есть форма проявления беспредельного разнообразия.
Козьма Прутков

Введение в нотацию eEPC

Летом 2020 года GitHub позволила пользователям создавать персональные README-файлы и с их помощью кастомизировать свои профили. Сама платформа при создании подобного файла предлагает уже готовый шаблон, в который можно вписать свои данные. Но о какой кастомизации может идти речь, если у всех будут одинаково оформленные профили? За почти два года сообщество придумало множество различных способов выделиться и особенно оформить свою страницу на GitHub.

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

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