А вот и рубрика "Найдите 10 отличий". Подробности в посте ниже 👇

Если серьёзно, то на январских праздниках съездил в Томск. Погулял по городу и, в частности, прошёлся по местам, в которых я, ещё будучи магистрантом 👨‍🎓, был почти 19 лет назад. На этом моменте хотелось бы остановиться чуть подробнее.

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

Если вернуться к фотографиям, то на них представлено место, где я жил все те 5 дней, что длилась конференция (слева — кадр от 29.03.2005, справа — уже свежий кадр от 05.01.2023). Само здание и его окружение за прошедшие годы прилично изменились (как минимум, обшили обветшалый фасад, а на месте соседнего деревянного барака расположилось современное здание с рестораном корейской кухни), но место всё равно осталось узнаваемым.

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

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

Друзья, сегодня хочу рассказать историю длиною в полгода.

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

В результате я три недели работал на 2 команды, преимущественно занимаясь задачами "соседей". Было, конечно, сложно, но речь сейчас не о том.

Когда их аналитик вернулся из отпуска, я подготовил для него перечень предложений по оптимизации его работы. Мне как человеку со стороны были заметны некоторые моменты, на которые ни он, ни его коллеги по команде, не обращали внимания (например, определённые данные отражались в разном виде в 2 или 3 местах спецификации без какой-либо объективной потребности в этом).

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

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

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

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

🎬 Подборка видео-собеседований на позиции SA и BA

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

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

🔶 Solvery | Junior системный аналитик
🔶 Solvery | Junior бизнес-аналитик
🔶 Мегафон | Junior системный аналитик
🔶 Lamoda | Системный аналитик
🔶 Альфабанк | Системный аналитик
🔶 Райффайзен банк | Системный аналитик

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

🔶 Собеседование бизнес-аналитика
🔶 Собеседование фулстек-аналитика
🔶 Как аналитику проходить техническое собеседование

#подборки #собесы

🎨 Когда схемы заходят

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

Этот знакомый вышел к своему руководителю с инициативой о внесении изменений в архитектуру их распределённой системы. Предложения были вполне конкретные, но руководитель сказал, что готов рассмотреть их, но надо, чтобы мой знакомый сперва представил архитектурные схемы AS IS и TO BE для иллюстрации своей идеи.

Готовых схем, как можно догадаться, в компании не было, да и такая задача героем истории никогда ранее не решалась. Аналитика и архитектора к вопросу привлекать не стали (углубляться в причины этого решения здесь не будем). Как следствие, надо было понять, как подготовить запрошенные артефакты, да и так, чтобы не было стыдно за результат.

Я задал несколько уточняющих вопросов, чтобы погрузиться в суть, озвучил возможные варианты и инструменты. По итогу уточнений остановились на том, что оптимальным будет нарисовать диаграмму компонентов UML в draw.io. Оставалось только брать и осваивать эти инструменты.

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

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

Вспомнился известный тезис о том, что системный аналитик должен выступать связующим звеном и переводчиком между языком бизнеса и языком IT😅

#юмор

💡 Лучшее — враг хорошего

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

Речь про анализ работы пользователей с вашим приложением и оценку востребованности и удовлетворëнности полученным результатом.

Пример из жизни. Выполняя изучение реплик клиентов (голосовых команд, произносимых во время работы с нашим функционалом), оказалось, что никакого смысла в ранее запланированном нами улучшении используемой ML-модели нет. Пользователи просто не интересуется теми разделами приложения, точность определения которых мы хотели улучшить благодаря доработке модели. Как следствие, было решено убрать её вообще, а заодно и ту часть функционала, которая не является востребованной. Также было решено реализовать доработку, которая закроет потребности пользователей, открывшиеся нам в ходе всё того же изучения.

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

🎨 7 рекомендаций по выбору цвета

Под одной из моих статей читатель оставил комментарий о том, что использование цвета — вещь очень полезная, но её следует применять с умом, чтобы документация (цитата) "не превращалась в разноцветное марево".

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

#статьи #визуализация #цвет #гайды

https://telegra.ph/7-rekomendacij-po-vyboru-cveta-02-05

🖼️ За что я люблю картинки

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

#статьи #визуализация #цвет

https://telegra.ph/Za-chto-ya-lyublyu-kartinki-02-12

Когда команда разработки 👫👫👫 вдохновенно поработала над фичëй.

#юмор

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

🖌️ Цикл "Осмысленная визуализация":
🔴 Использование визуализации при анализе и проектировании информационных систем (Intro)
🟠 Осмысленная визуализация при анализе и проектировании информационных систем
🟡 Метадерево как инструмент для выбора средства визуализации
🟢 Осмысленная визуализация при анализе и проектировании в действии
🔵 Metatree: a visual navigator for visual models (EN☝)
🟣 За что я люблю картинки

🎨 Цикл "На вкус и цвет":
🔴 Красный день календаря (Intro)
🟠 Использование цвета при анализе и проектировании систем. Часть 1
🟡 Использование цвета при анализе и проектировании систем. Часть 2
🟢 Использование цвета при анализе и проектировании систем. Часть 3
🔵 7 рекомендаций по выбору цвета

#подборки #статьи #визуализация #цвет

📌 Том и Джерри в гибкой разработке

84 года назад (в 1940г.) на экранах впервые появилась мультипликационная пара Том и Джерри. Думаю, вы все знаете этих ребят. Но почему именно такой порядок: "Том и Джерри", а не "Джерри и Том"?

Скажу сразу, ответа у меня нет, но в этом вопросе прослеживается любопытная параллель с работой Agile-команд. Поясню свою мысль.

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

В других командах скрам-мастер (возможно, совместно с владельцем продукта) определяет удобный для себя порядок опроса или же команда движется сверху вниз по доске в Jira, отфильтрованной по членам команды. При таких схемах изо дня в день условный Джерри всегда выступает после условного Тома. Знакомо?

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

В общем, попробуйте! А для удобства можете воспользоваться следующей реализацией на Python:

import random 
scrum_team = ["А", "Б", "В", "Г", "Д", "Е", "Ё", "Ж", "З", "И"] 
random.shuffle(scrum_team) 
[print(_) for _ in scrum_team] 

#методыуправления #agile

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

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

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

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

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

🕯️ На сон грядущий хотел бы рассказать одну историю.

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

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

На этом, наверное, можно было остановить повествование, поучительно процитировав слоган "Trust No One" из "Секретных материалов", но нет, на этом моя история не заканчивается.

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

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