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

Многие из вас помнит зарю ИТ-индустрии, когда было модно стать “фрилансером” и чилить на Бали, под пиво рисуя сайты. Хорошее было время… Для тех, кто успел вкатиться. 

Начиная с 2005, вместе с  ростом запроса от рынка, количество аутсорс-контор стало расти, как грибы после дождя. Фрилансеры остались, но их исключительность начала уходить: ведь галеры предлагают тоже самое (а то и лучше) за примерно тот же самый ценник. Только без гемора для Заказчика.

Можно с пеной у рта спорить, кто больший гад на рынке, но для энтерпрайза и МСБ при адекватных бюджетах фрилансер – рисковый ресурс. В отличии от аутсорс компании. Чтобы начать работать надо подписать рамочный договор с юрлицом (желательно в юрисдикции твоего головного офиса) и все – можно приступать. В случае форс мажора –  отвечает конкретное ООО “Веб Мастера”, а не условный Коля Усов с 543 положительными оценками на FL.RU. Он таки реально рисует твой сайт, сидя на Бали. Но в перерывах между сессиями рехаба и рейвов. Если найдет время. 

Не буду вас пугать и вводить в заблуждение – с фрилансерами все прекрасно. Ковид показал, что толку от них зачастую столько же, а то и больше, чем от штатной команды. А всякие самозанятые и прочие digital nomad visa по прежнему привлекают свежую кровь в стан любителей свободы. Подтверждает мои слова и статистика. 

Сегодня мы рассмотрим методы формализации требований: Use Case и User Story. В статье рассмотрим оба метода, сравним их преимущества и недостатки. А также рассмотрим, когда и при каких ситуациях использовать каждый из методов.

В последние несколько лет в среде технических писателей все больше на слуху концепция Docs as Code. Если вы раньше не сталкивались с этим термином, он обозначает подход к разработке технической документации с использованием тех же инструментов и процессов, что и написание кода. Если DocOps это про процессы и коллаборацию, то Docs as Code — про инструментарий, при помощи которого мы несмотря ни на что. Мы выбрали этот подход, когда создавали портал документации Plesk.

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

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

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

Нормализация адреса - приведение его к верхнему регистру, удаление лишних пробелов и удаление всяких "город", "г.", "улица", "ул." и т.п. Т.е. "Российская Федерация, г.Мухосранск, ул.Коммунистический тупик, д.13, кв.666" нормализуется в "МУХОСРАНСК КОММУНИСТИЧЕСКИЙ ТУПИК 13 666". "Элементом" адреса является отдельное слово (разделенное пробелами).

Дабы облегчить себе жизнь, есть т.н. "витрины адресов" - три таблицы. В первой содержится идентификатор клиента/субъекта + идентификатор адреса (для субъектов есть еще т.н. "ключевое слово" - элемент адреса субъекта, который реже всего встречается в витрине адресов клиентов). Во второй - набор связей адрес-элемент - идентификатор адреса + идентификатор элемента + номер элемента в строке адреса. И в третьей - список элементов - элемент + идентификатор элемента. Т.о. имеем две "витрины" - адреса клиентов и адреса субъектов.

На промсреде витрина адресов клиентов содержит порядка 96млн адресов. Витрина адресов субъектов - порядка 8тыс адресов. Сравнить надо всех со всеми - 768млрд комбинаций где-то...

TL;DR Очень подробный разбор алгоритмов решения задачи о кратчайшем пути от классики до двунаправленного А* и ALT с кодом и примерами на OSM

Люди пытались найти более быстрые способы передвижения на протяжении всей своей истории. Появление качественной дорожной системы в римской империи в своё время привело к её расцвету, но со временем выяснилось, что и в продуманных дорожных системах бывают забавные изъяны, как например в небезызвестной задаче о кёнигсбергских мостах, считающейся отправной точкой возникновения теории графов. Неудивительно и то, что с развитием вычислительной техники логистические задачи стали одними из первых, над которыми трудились первопроходцы компьютерных наук. Задача о кратчайшем пути -- одна из них, звучит достаточно просто: есть несколько городов и дорог, соединяющих пару городов между собой, мы хотим попасть из города А в город Б пройдя при этом минимальное расстояние. Первый системный подход к этой задаче был описан в работе Эгервари в 1931г., спустя 25 лет Эдсгер Дейкстра придумал алгоритм, который сейчас является частью любого уважающего себя базового курса алгоритмов на графах. На нём же, будем честны, заканчиваются знания о кратчайших путях у большинства профессиональных разработчиков, ибо сценариев, где реализации с википедии/stackoverflow будет не хватать, крайне мало.

Может показаться, что на самом деле просто не было существенного прогресса с 60х годов, так как Дейкстра предоставил почти асимптотически оптимальный алгоритм решения задачи. На самом деле нет, прогресс был и придумали много чего интересного, хоть и действительно с того времени фокус сместился на другие задачи. Приглашаю под кат если интересно узнать что такого напридумывали, что используется в современных логистических системах, почему меня огорчает отсутствие учёта флага единства в HOMM3 при расчёте пути, ну и наконец, что за мужики на картинке выше рядом с Дейкстрой?

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

Но есть примеры, когда компании декларируют более “приземленные” и рабочие принципы своей работы или модели действий (никого не рекламирую). Следуют им компании или нет – другой вопрос. Мне было интересно не это, а скорее то, как компании приходят к подобным декларациям. Если и вам интересно это узнать, то делюсь. 

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

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

Рассмотрим подробней.

Привет, Хабр!

Меня зовут Кристина Спирина, я руководитель проектов в IT.

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

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

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

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

Привет, Хабр! В 2020 году компания решила вывести на рынок линейку продуктов Platform V. Для них нужна была документация, которая на тот момент велась в Confluence. Нам предстояло проделать сложную и дорогую работу: собрать документы на нужные версии, привести тексты к единому стилю и терминологии, оформить как комплект документации от поставщика ПО. Расскажу, какие инструменты мы в СберТехе использовали, почему перешли от документирования в Confluence нa Docs-as-a-Code и создали инструмент Platform V GetDocs, который помогает эффективно писать документацию.

Вот я и дописал свою четвёртую статью на хабр (А ведь в начале года поставил себе цель написать хотя бы одну статью, а тут аппетит пришёл во время еды и вот четвёртая). Предыдущие раз, два и три.

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

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

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

В этом хранилище используются 10 плагинов, основные:

- Calendar - для календаря справа.

- Dataview - для статистики и для проектов.

- Tasks - для задач.

- Templater - для шаблонов и чтобы нужные заметки с запросами создавались в нужных папках и с нужными данными в запросах.

К такой настройке я шёл целый год используя обсидиан, постоянно дорабатывал её и искал "совершенство", в ней собраны разные подходы из разных статьей и книг (GTD, 7 навыков, Джедайские техники, Атомные привычки), данные подходы большинству могут быть знакомы. Но есть метод, до которого я дошёл сам и до этого я нигде его не встречал (возможно просто не попадался) - это метод одной задачи.

Disclaimer1: Мой сетап не претендует на "идеальность", в нём найдутся минусы и неудобности. Я выношу его на общее обсуждение в том числе для того, чтобы кто-то мог предложить ту или иную доработку тут в комментариях, а так же для того, чтобы новички могли сходу вкатиться в этот чудесный обсидиановый мир.
Disclaimer2: Обычно обсидиан ассоциируют с Zettelkasten, графами и прочими атомарными заметками. Я в своём подходе этого не использую, возможно еще не дорос, возможно мой подход немного про другое. В этой статье я пишу не про это.

Очень мощный плагин для работы с задачами в Обсидиане.
Возможности плагина:

В прошлой статье Obsidian + Dataview: Таблицы я рассказал про установку плагина Dataview, формирование таблиц с его помощью и разобрал 4 кейса его использования.

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

Сегодня хотелось бы остановиться на задачах, тем более что Dataview позволяет сделать из Обсидиана полноценный task/todo-менеджер с календарём и прочими приятностями.

На статью меня вдохновил этот комментарий .

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

Это такой своеобразный аналог Notion-таблиц, где можно создать таблицу с бесконечной вложенностью (таблица, внутри одной ячейки, а внутри еще таблица и еще и еще).

На КДПВ как раз собраны четыре кейса реализации функционала плагина Dataview.

Как всё это работает

1. Dataview работает на встроенном языке запросов

2. Все запросы должны писаться внутри подобного блока кода:

Всем привет! Меня зовут Вадим, и я QA-инженер в IT-компании Intelsy. С техническим заданием, и в частности с требованиями, лично я имею дело постоянно, поэтому собрал полезную для начинающих и продолжающих специалистов информацию по требованиям к IT-продукту,  их видам, техникам и метрикам тестирования требований. На эту инфу стоит ориентироваться не только аналитикам и тестировщикам, но и остальным членам команды.

Друзья аналитики и ценители данных!

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

Сейчас я также руковожу отделом аналитики в IT-компании и выступаю в роли PM по внедрению BI-систем и построению DWH. Хочу начать делиться своим опытом, фактами и советами о том, как аналитику выстроить карьеру в этой сфере. В будущих статьях смогу подробно рассказать про Data Governance, поделиться опытом внедрения аналитических систем в различных компаниях и о том, как избежать типичных ошибок в аналитике.

Поехали разбираться вместе! Это моя первая статья на Хабре, и я рада поделиться своими знаниями и опытом с этим замечательным сообществом.

Бизнес-аналитик - мастер переговоров или как не сойти с ума, работая с требованиями

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

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

Привет, аналитики!

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

Сегодня я хочу поговорить о дальнейшей работе аналитика в проектах по созданию хранилищ данных (DWH). Как пройти весь путь от сбора требований до внедрения готового решения, сохраняя баланс интересов бизнеса и ИТ.

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

Как избежать недопонимания между бизнесом и ИТ в ходе проектирования? Как убедиться, что разработанное решение действительно решает задачи заказчика? И как помочь пользователям безболезненно перейти на новую систему?

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

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

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

Тут я расскажу о нём в общих чертах.

В этой статье мы рассмотрим 10 лайфхаков мобильного UX/UI дизайна, которые помогут создать действительно эффективные и приятные для пользователя мобильные приложения.

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