SA LEAD

Повсюду пошла реклама подборки каналов по БА и СА, а я вот решил сделать свой топ малоизвестных каналов (без вложений в пиар), которые по моей «скромной» оценке не уступают содержанием. https://t.me/addlist/CK8Ofy4z3eQyOTQ6 Многих, кстати, я знаю лично: действующие лиды и эксперты, победители крупных чемпионатов по СА, прекрасные в прошлом коллеги :) Друзья, делитесь этой папочкой у себя)

Сегодня на примере дискуссионного клуба по теме проектирования систем и архитектуры еще раз убедился в том, что системному аналитику до архитектора как до луны пешком. Архитектура начинается с организации кода и заканчивается пониманием технологий, протоколов, интеграций, паттернов, ИТ-инфраструктуры, а также процессов тестирования и развертывания. Цель архитектуры - в обеспечении возможности оперативного внесения изменений в систему и требуемого уровня качества (производительность, надежность и так далее). Все остальное вторично. В 8 из 10 собеседованиях попытки поговорить про архитектуру сводятся к типичному сравнению монолита и микросервисов в формате «это хорошо, а это не очень». А еще, 95% проектов - это не с нуля сделать новую систему. Это большие запутанные сервисы со смесью архитектурных паттернов, букетом новых и старых технологий, с большим дублированием кода и множеством ручных процессов. Добавьте сюда гонку любого бизнеса за фичами, и подумайте о том, как в таких условиях организовать безрисковое планомерное оздоровление системы. Насмотренности в части High-Level Design очевидно не хватит для решения таких задач. Возможно вам это не понравится, но курсы по архитектуре с лозунгами сделать из вас архитекторов решений от аналитиков, не владеющих серьезным опытом разработки, являются чем-то иллюзорным. Я бы рекомендовал идти обучаться разработке, если ставите себе цель сменить роль и пойти на «повышение». Всем хорошего вечера😊

Какой бы не использовался фреймворк, будь то Waterfall, Scrum, Kanban, XP или FDD, он никогда не отменит этапы SDLC, про которые написано уже в тысяче книг, а также не прибавит новых компетенций команде. Выделили ли время на системный дизайн или нет, он все равно случится - оформленный красиво на бумаге после ревью коллег или придуманный в голове за 5 мин на планировании, где показали функциональные требования и потребовали дать оценку трудозатрат. Я видел много кейсов, когда попытки слепо внедрить фреймворк приводили не к сокращению фаз разработки (улучшению lead-time), а к ущемлению продукта в качестве, масштабным переделкам и вытекающей из этого дизморали сотрудников. Куда приоритетнее вкладываться в развитие компетенций и инженерных практик для ускорения прохождения цикла разработки. Малая часть из них: - «Опасные» доработки раскатывать сначала на пилотную группу юзеров, потом на остальных и делать фичефлаги (рычаг на откат изменений без остановки приложения). - Вместо 10 итераций придумывания и согласования «бумажного» системного дизайна делать прототип решения, для более быстрого извлечения новых знаний и последующего внесения корректировок. - Внедрять автоматизацию поддержки документации для минимизации ошибок и экономии людских ресурсов. - Вкладываться в автоматические тесты и их прогон, даже, если кажется, что внесенные изменения в систему не требуют этого. - Не принимать исходные требования от клиентов за истину, заглядывать за фасад хотелок. Кстати, я наконец-то встретил человеческое описание природы связей требований/подходов бизнес-анализа, обернутое в целостную методику разработки бизнес-требований. - Непрерывно обогащать гайды/бест-практисы по проектированию и разработке опытом компании. Нет, конечно фреймворк имеет значение, но скорее играет роль организационного и стимулирующего характера - устремить командный фокус на выдачу хоть какой-то ценности пользователю за спринт, построить паттерны проектных и командных взаимодействий, регулярные церемонии для огласки и решения проблем и др. Примерно такого же мнения я в части форматов артефактов, порождаемых в ходе SDLC, но об этом уже в новом посте, если здесь будет много реакций 🩶

Приближаясь к значению 300 проведенных собеседований, заметил некоторую корреляцию. Системные аналитики, которым все равно, в какой предметной области придется работать, в процессе проектирования систем излишне увлекаются техникой и упускают мотивацию принимаемых решений, независимо от опыта. Объяснение этому я пока не нашел, но практически это стало некоторой оценкой вероятности успешности прохождения отбора, приобретения компанией стратегических выгод, а также срока жизненного цикла сотрудника. В целом, говоря о предпочтениях кандидатов, то вырисовывается следующая классификация: ◽️Равнодушие. ◽️Предпочтения от противного, чаще всего основываясь на негативном опыте, чувстве социальной ответственности (не гос, не казино, не букмекеры, не займ быстрых денег и т.п.). ◽️Желаемое, основываясь на позитивном опыте, социальной ответственности, любопытстве. Говоря о факторе увлечения предметкой для компании, то на практике имеем бонус в виде здравой критики роадмапа, будничного заглядывания за фасад пользовательских требований, а также генерации идей о точках роста продукта. Говоря о моих предпочтениях в роли аналитика, то я долгое время был в третьей группе, затем перекатился во вторую, так как любовь к предметке оказалась невзаимной (рассказать о причинах в отдельном посте?). Эта была Медицина, которая до сих пор остается для меня лидером с точки зрения эмоционального позитивного отклика и развития: ✔️Образованные заказчики, у которых невольно многому учишься. ✔️Высокие требования к качеству IT-решений, в частности критичность ошибок в данных. ✔️Много неопределенности и динамики, которая сложно поддается автоматизации. Из примеров - попытки сделать умное планирование стационара с целью снижения к-та простоя операционных. ✔️Фокус на создание единого цифрового пространства. ✔️Фокус на UX, чтобы не отнималось драгоценное время приема. ✔️Фокус на поиск второго помощника в области ИИ и работа с вытекающими рисками. ❓А для вас важна предметная область? Делитесь вашим опытом и историями, когда фактор предметной области позволил вам проявиться, прокачаться или, наоборот, ограничил ваши возможности ⚡️

Путь аналитика или 20 шагов к большому успеху *Все совпадения, в том числе со мной, случайны. Пост носит развлекательный характер. 1️⃣ Заканчиваете школу в 17 лет, скипаете ВУЗ (навязанный родителями) и проходите месячный bootcamp Пети Васечкина по системному анализу. 2️⃣ Оформляете красиво резюме на одну страничку, с накрученным опытом, обращаясь за помощью к ментору или HR. 3️⃣ Перекладываете размеренно и уверенно данные из XML в JSON на ESB в банке. 4️⃣ Меняете банк на другой, не забывая демонстрировать вовлеченность и корпоративный дух на новом месте. 5️⃣ Доживаете до следующего грейда, затем гордо пишете себе «Старший аналитик» на LinkedIn. 6️⃣ Ждете, пока вашему Тимлиду наскучит работать за всех в кросс-функциональной команде из 5 человек, и благодаря насмотренности и смелости залетаете на его место. 7️⃣ Спустя полгода выгораете, увольняетесь и заводите канал в телеге, где первым постом пишете, что вы уже более 3 лет аналитик и дошли до тимлида в 20 лет. 8️⃣ Сразу ссылочку на донатик оставляете, ведь аналитические материалы вашего сундучка крайне полезны. 9️⃣ Пересылаете материалы «коллег», вставляете ответы GPT-3.5 в яркие картинки в канве, не обращая внимание на ошибки. 1️⃣0️⃣ Вкладываете в рекламу -> в вашу рекламу вкладывают. 1️⃣1️⃣ Проводите стримы, где с умным лицом говорите, что «надо вписать проекты и достижения в резюме». Или где ваши менти рассказывают истории успеха. 1️⃣2️⃣ Подключаете ботов, которые яро требуют запись встречи или просто заваривают пустые разговоры. 1️⃣3️⃣ Обязательно во всех схожих каналах пишете что-то в комментарии от имени канала, тем самым набиваете аудиторию. 1️⃣4️⃣ На первые доходы отправляетесь в отпуск, и выкладываете фото, где вы кайфуете с макбуком на пляже. Или в горах 🏔️ (чуть солиднее). 1️⃣5️⃣ Запускаете карьерный курс или же просто переупаковываете Вигерса для всех! Собираете стрим, где на неудобные вопросы отвечаете, что все расскажете на курсе. 1️⃣6️⃣ Запихиваете бесплатный контент по архитектуре в курсы, обогащая примерами с работы и говорите, что это для сеньоров - добавляете приставку PRO. 1️⃣7️⃣ Открываете свою школу с командой. Продолжаете во всех каналах и конференциях показывать экспертность. А если вас начинают давить, то обязательно напоминаете всем, что 20 лет назад были лидом тридцати аналитиков. Или ссылаетесь на то, что у вас куча знакомых в тусовке IT, которые снабжают вас релевантной информацией. 1️⃣8️⃣ Даете советы начинающим авторам каналов, что нужно опираться на факты и исследования. 1️⃣9️⃣ Во всех лендингах/профилях ежегодно обновляете счетчик накопленного опыта, не забывая сохранять приставку Ex. 2️⃣0️⃣ На пенсии ваш час консультации стоит 50 тысяч руб., не говоря уже о наличии успешной школы, ваших сообществ и платных каналов. Что забыл? добавляйте ⬇️ 💯 Таков путь. 🏆 Завидуем. ❤ Так правда можно?

Всем привет! Я недавно участвовал в достаточно крупном чемпионате по системному анализу. В тройку победителей не попал (только 15-е место), но пообщался с классными ребятами, и посмотрел, как они пишут ТЗ или TDD (Technical Design Document) на разработку ИТ…

Всем привет! Я недавно участвовал в достаточно крупном чемпионате по системному анализу. В тройку победителей не попал (только 15-е место), но пообщался с классными ребятами, и посмотрел, как они пишут ТЗ или TDD (Technical Design Document) на разработку ИТ-решения - речь о развитии текущей системы (добавление новой функциональности). Все сводится к следующей универсальной структуре, с чем «спешу» с вами поделиться. 1️⃣Исходные требования/проблематика/запрос Что мы хотим сделать и почему - с точки зрения пользователей системы. В философию «ну вот это пользователю на самом деле не нужно, это нужно его бизнес-руководителям» уходить не будем, так как тянет на отдельный пост. Считаем, что мы уже сделали этот анализ и спустились на уровень пользователя (или «моря», как пишет в своей известной книге Коберн). 2️⃣Текущее состояние и поведение системы (AS IS) Необходимо понимать функциональность и структуру системы для того, чтобы не упустить из виду неожиданное влияние от реализации Исходные требования/проблематика/запрос на бизнес-логику, атрибуты качества, архитектуру и процессы сбоку (например, развертывания и поддержки) 3️⃣ Мотивация Почему мы, в роли поставщика/разработчика продукта, хотим удовлетворить Исходным требованиям/проблематике/запросу. 4️⃣Предлагаемое решение (TO BE) Структура ниже может отличаться в зависимости от содержания разделов выше. 🔷 Сценарии использования Является набором функциональных требований в контексте решения пользователем задачи. Можно пропустить эту часть, если вы можете сразу формализовать функции и алгоритмы. Но я рекомендую не пропускать этот шаг, как минимум для самоконтроля, как максимум, чтобы команда лучше понимала контекст автоматизируемых задач пользователя. 🔷 Роли и права доступа Изменения прав доступа по текущим ролям/добавление новых ролей. 🔷 НФТ Скорее всего они уже где-то описаны для системы, и достаточно их приложить, чтобы указанные лимиты/пороги не были нарушены. Если изменение требует пересмотра значений, то необходимо прежде убедиться, что это возможно и уже описать здесь новые показатели. 🔷 Сущности Логическая модель данных, на которую вы будете: - ссылаться при описании бизнес-логики - опираться при проектировании интерфейсов и модели хранения данных. Несмотря на то, что вы сделаете это проектирование (см. далее разделы), важно оставлять команде «первоисточник» в целях стимулирования предложнений в части лучших проектировочных решений. 🔷 Функции и алгоритмы (бизнес-логика) Как изменяются объекты системы при различных условиях и/или действиях пользователей. 🔷 Интерфейсы Все точки вызова алгоритмов и функций. Например, API, UI, JMX и т.п. 🔷 Хранение данных Моделирование данных под конкретную СУБД. 🔷 Архитектура Требования к компонентам - как необходимо доработать компоненты (сервисы) системы, чтобы удовлетворить заявленным требованиям и связанным проектным решениям (например, интерфейсам). Это будет основой для последующей технической декомпозиции, которую делают разработчики для распараллеливания работ. Если добавляется новый компонент, то необходимо приложить обновленную схему архитектуры. Межкомпонентные взаимодействия - описание того, как работают вместе компоненты системы внутри или с внешними сервисами (интеграции), с указанием того, какие функции инициируют процесс. 🔷 Инфраструктура Любые изменения в области инфраструктурного ПО и вычислительных мощностей. Например, добавление логирования новых запросов, или расширение мониторинга и списка алертов. 🔷 Конфигурация Любые параметры, определяющие как будет работать функциональность функциональности, или вовсе включающие/отключающие функциональность (фичефлаги). Кому нужен пример такой работы, то пишите в личку (скину свое 🫡).

Пригласите бизнес-аналитика и системного аналилика в 19:00 в пятерочку в спальном районе, когда на кассах и единственном терминале самообслуживания огромные очереди. И спросите у них, как можно решить эту проблему. 💡БА сделает анализ статистики/данных загрузки касс и терминала, распределенной во времени, найдет причины и накидает область возможных решений: от выноса кассы из подсобки с доп. part-time кассиром до активации повышенной временной скидки на онлайн-доставку продуктов. Затем БА посчитает экономику по каждому из возможных решений с оценкой рисков и сделает защиту решений перед бизнесом. 💡СА будет искать возможности развития ПО терминала в целях ускорения обслуживания, с последующим написанием ТЗ для команды разработки. Иначе, если путей улучшения в работе ПО не найдет, предложит поставить второй терминал рядом 😁 ✅ Это пример фокусов профессий и принципиальное различие между ними. ✅ Это пример того, что будет, если пытаться использовать СА в роли БА. ❗️Это подводка к обращению - среди вас есть бизнес-аналитики, кто планирует перейти в СА. При этом в массе вы не являетесь БА в трактовке, которую я дал в примере про пятерочку. Скорее всего вы уже владеете функциональным проектированием на уровне систем. Или же вы работаете в контексте решения проблем бизнеса засчет развития ПО. Вы также считаете, что нужно по сути с нуля овладеть новой профессией. Но это не так. Попробуйте походить по собеседованиям: ❕В худшем случае вы быстрее поймете, что требуют по части логического проектирования, в том числе характер решений на компонентном уровне. Вероятно вам дадут хорошую ОС, и само собеседование добавит вам в копилку знаний и умений; ❕В лучшем - вас возьмут в компанию на ставку СА, где остальное не требуется или будет решаться силами коллеги-старшего аналитика. Вряд ли это будет финтех с офером 300 тысяч. Но путь практики лучше, чем полгода пытаться впитать в себя все курсы по интеграциям/микросервисам/брокерам. К тому же такой стек используется далеко не везде на проектах. Всем удачи в реализации карьерных планов 💌

Переход из БА в СА Предыдущий пост... Получив классный опыт на первом месте работы в качестве бизнес-аналитика, я умудрился попасть в ГУП на роль проектного менеджера (так оказалось на практике). Через полгода осознал, что свернул не туда, и перешел в заказную разработку ИТ-решений для частной медицины на роль аналитика ИС (так в трудовой и написано). Минимального опыта подготовки ТЗ, в том числе по ГОСТам 34 и 19, хватило для того, чтобы пройти собес, который был достаточно формальным. Оно и понятно - в компании не было никаких процессов вокруг разработки, да и коллектив был численностью до 40 человек. Как будто достаточно было показать себя здравомыслящим человеком и ответить на типовые вопросы о требованиях. На новом месте я уже куда больше касался руками систем - глубоко в части анализа функциональности и никак с точки зрения структурного анализа. Из-за отсутствия второго мне требовалась подстраховка. Эту роль занял архитектор ПО, который также выполнял еще кучу функций на проекте. Он был ревьюером всех моих артефактов для команды разработки. Тем не менее основные ожидания от меня были в том, чтобы закрывать вопросы выявления, разработки и согласования требований, и регулярно делать поставки этого добра для внутренней команды. Это был единственный трушный аджайл в моем опыте - выявили, описали, обсудили внутри, описали для заказчика, согласовали, скинули в разработку в US/JBTD и получили к концу спринта решение с ценностью - выбор лучшего решения из области возможных был тоже за командой. А вишенкой было демо решения разработчиком-исполнителем задачи для заказчиков. К слову, 1 аналитик на 4 команды разработки по 5 человек. Что-то типо LeSS. Думаю, что где-то здесь и зародились базовые умения в системном анализе в моих компетенциях, и уже тогда можно было упаковывать этот опыт, и пытаться продать на рынке с названием Системный аналитик. Но я никуда не торопился, был азарт выпустить крупный проект в эксплуатацию. А что с точки зрения системного дизайна? Только на закате этого этапа карьеры я смог в роли наблюдателя познакомиться немного с: ◻️Архитектурой, на уровне теоретических паттернов ◻️Интеграцией систем, на уровне тестирования веб-сервисов через SoapUI. За два года я устал от такого ритма, и поставил себе задачу зайти в финтех на роль с названием СА. 3 отказа в оранжевом банке, 2 отказа - в красном, 7 отказов + игноров в зеленом. Но восьмая команда взяла меня. Именно здесь подрос ощутимо как СА и проектировщик ИС. Этому способствовало две причины: ✔️С первого дня анализ дефектов и поиск решений. Нужно было находить причины проблем, которые в том числе крылись в структурах данных и архитектуре системы. Также постоянно перед глазами были интеграционные сообщения и адреса конечных точек. ✔️разделение постановки в задаче на две части: бизнес и «системные» требования. Без второго разработчик никогда не брал задачу в работу. А в таких условиях развитие происходило быстрее 🧑‍🎓. Облегчало задачу то, что за каждый компонент в банке как правило отвечает отдельная команда, а это вынуждало меня коммуницировать с аналитиками этих команд. А это тоже обучение и опыт - встречные мнения на попытку заказать доработку или же просто в лоб попросить помощи. ✔️Доверие руководителя аналитиков и менеджера по продукту. Мне казалось (или они скрывали хорошо 😅), что у них нет сомнений в том, что я могу выдать плохой результат. Ошибки конечно были, но и реакции их не были демотивирующими. А какая у вас история входа в вашу текущую профессию? Делитесь в комментариях ⬇️

Первая работа в IT В сентябре 2016 года я переехал в Москву для продолжения обучения на программе магистратуры бизнес-информатики. На вводной встрече для студентов Главный менеджер программы обучения сказал - «Если вы не будете работать параллельно обучению, то будущие 2 года - бесполезная трата времени». Понял. Принял. К началу октября собрал первое резюме. В разделе опыт - 3 месяца учебной практики, где писал статьи для хелпцентра какой-то CMS российского производства. А также явно указал, что я действующий студент ВШЭ, поэтому задерживаться после 18:00 не смогу. Спасибо университету, который ставил пары не раньше 18:30. Преподаватели, кстати, вместе со студентами частенько опаздывали, так как задерживались на работах. Все друг друга понимали - фокус был на результат и качество. Это сильно отличало новый ВУЗ от предыдущего. На тот момент я толком не понимал типизацию аналитиков, поэтому откликаюсь на все подряд: бизнес-аналитик, аналитик систем, аналитик данных, аналитик бизнес-процессов. Многие одногруппники целенаправленно искали компании-системные интеграторы, с фокусом на топ-10. И это была отличная стратегия для старта (о чем я немного пожалел в дальнейшем). Я не смотрел на названия компаний, так как ставил задачу найти работу, как можно быстрее, чтобы начать зарабатывать хоть какие-то деньги. На 20 откликов - один ответ. После первого собеседования спустя день я получил офер. Собеседование было в формате - что знаешь и умеешь, кто ты по жизни. Вакансия называлась аналитик ИС. Это была книжная розничная сеть - около 100 точек продаж по Москве и Подмосковью. В части плана договорились: 1) Освоить предметку через выезды в поля и операционную деятельность по работе с заказами в негативных кейсах - когда что-то потерялось в процессе доставки, брак, пересортица. 2) осознать проблемы, далее предложить оптимизацию, в том числе с доработками ИС, если оно того потребует. По условиям: ✔️50 тыс. рублей, после ИС подъем до 80. Это в текущих ценах (брал годовую ставку инфляции 8%). Официально (не в конверте) только половина; ✔️бесплатные обеды и ужины ; ✔️уютный офис с видом на кладбище…🪦 Что еще нужно студенту для счастья, которому университет выдал новенькое общежитие в пределах МКАД? Продано. Было две ставки - взяли двух аналитиков без опыта. «Напарник» очень помог тем, что постоянное косячил. Это делало меня «выдающимся» специалистом на общем фоне. Он тратил много времени на красивые нотации описания процессов, но рисовал то, что вызывало нервные приступы у нашего руководителя. Его спустя 2 месяца уволили. Что было интересного на первом месте работы: 🔥Выезжал на точки продаж (далее - ТП) и на склады для исследования текущих бизнес-процессов (зимой, когда на складе было холоднее, чем на улице). Особенно весело было пытаться интервьюировать рабочих склада 🤡 🔥Видел радость в глазах директоров ТП, когда получилось упростить им некоторые процессы. Например, в розничной сети был алгоритм, который раз в сутки формировал заказы на переброски товаров между ТП транзитом через сортировочный центр в зависимости от динамики продаж, в целях пополнения запасов наиболее продаваемых книг. И на каждую книжку делался отдельный заказ, а это отдельная коробка, следовательно больше расходников, временных затрат по упаковке, риски потери при транспортировке, брака и тд. Для сотрудников ТП добавили опциональное укрупнение по фильтру конечных ТП, попутно изменив процессы транзита на складе 🔥Писал ТЗ, отталкиваясь от интерфейса системы - по-другому не умел. И это срабатывало, так как разработчики сидели уже второй десяток лет на проекте, и знали систему от и до 🔥Узнал о Вигерсе от опытного аналитика смежного подразделения. Через два месяца получаю повышение с 50 до 55 тыс. рублей. При окончании ИС рассчитываю на 80, но получаю 60 с непонятными дальнейшими перспективами. Спустя полгода работы в компании я ухожу. Продолжение…

Привет всем! Хочу поделиться с вами о том, как я выбираю темы постов, подбираю регулярность и время публикаций. Никак. У меня нет контент-плана; я не знаю, о чем будет следующий пост, и в каком стиле он будет написан. Все, что я успел написать за 2 месяца существования канала, было порождено событиями, которые произошли в моих рабочих буднях. Это объясняет то, почему я ничего не писал 2 недели в конце февраля-начала марта. Настолько я ушел в работу, что отстранился от всего. Писал и продолжаю писать план мероприятий по выводу документации компании из одного места 🤡. И далее это все реализовать, объем там до осени… Вдохновился, кстати, докладом Семёна Факторовича. У кого документация в компании ведется формально или ее вообще нет, то крайне рекомендую! Вернемся к теме поста. Канал для меня - хобби, разгрузка от работы, развитие навыков коммуникаций. Ну и конечно, цель - давать пользу. Никакой графомании. Поэтому, если не видите ценность у конкретного поста, не ставьте реакции, а иначе - ставьте) Буду лучше понимать, что интереснее/полезнее. К чему я веду? Пока я не писал две недели, ушло 3 человека. А до этого никакого оттока. Неприятно 🙃, но видимо все логично - нельзя заставлять людей голодать. Виноват. Поэтому, наверное, у меня должен все-таки быть беклог тем, из которого я могу что-то брать в периоды, когда нет событий-источников вдохновения. Напишите, пожалуйста, какие вопросы и темы вам интересны. Заранее благодарен 🫡

Текущая функциональность не изменяется… Аналитик готовит очередную спецификацию требований и постановку задачи на разработку новой функциональности в монолитной системе со сложной бизнес-логикой. Затрагивается поведение ряда функций системы - для них описывается новое ожидаемое поведение. То, что не затрагивается, фиксируется в виде как в текущей реализации/функциональность не изменяется Тестировщик готовится к тестированию, в том числе к регрессу. Для этого обновляет и создает новую тестовую документацию. Наткнувшись на такую формулировку, пытается в документации найти пропущенные/забытые знания. Не находит. Считая аналитика источником истины и ходячей базой знаний, тестировщик идет к нему с вопросом, а чаще с требованием - добавить «недостающее описание» о текущем поведении в задачу. Аналитик парирует: Поведение в этом месте не изменяется! Я исследовал. Если вам не хватает информации, то воспроизводите сами для ваших нужд. Вы же тестировщики. А судьи что? Мне довольно легко понять боли обеих сторон. Но решить, как правильно и чья эта обязанность или зона ответственности было не просто. А что если поискать ответ со стороны провокационных вопросов? Зона ответственности аналитика это ИТ-продукт, за который отвечает команда или постановка задачи? Цель анализа и проектирования это грамотная постановка задачи, или задачу дальше по конвейеру пустить? Я считаю, что аналитик отвечает за ИТ-продукт, как и тестировщик, разработчик и другие участники команды разработки. Насчет постановки - ключевой вопрос в необходимости/достаточности, ответ на который лежит в плоскости командных потребностей и договоренностей. При этом считаю важным: 💡Во время исследования AS IS системы аналитиком вносить заметки в пробелы документации по текущей версии ПО. Когда ты в контексте, то восполнить потерянную документацию можно легко и быстро, и тем самым сэкономить время членам команды на более поздних этапах. Если времени вносить изменения пр ходу дела нет, то явно проговаривать текущее (любое волнующее других) поведение на командных встречах по обсуждению задач. 💡Тестировщикам следить за тестовой документацией, и не надеяться на качество и полноту иной документацию. ❓А вы что думаете? Допускаете ли вы в своих документах подобные формулировки? Приводило ли такое к проблемам с качеством ПО?

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

Я, как руководитель направления системного анализа, хочу иметь на руках подборку внешних курсов, чтобы способствовать развитию сотрудников для повышения качества результатов их работы во благо компании. В ситуации, когда ко мне обращается сотрудник за программой развития, мне нужно дать подходящие курсы (но не только их) в балансе интересов компании и сотрудника, чтобы… Всем привет! Нет, это пост не о правилах написания US или JBTD. Пост о том, что не так с площадками, где продаются курсы на тему системного анализа и проектирования. Мои тезисы могут быть полезны продавцам/авторам курсов и тем, кто активно ищет себе обучение. 🔖У каждого продавца свои требования по min грейду, от которого стоит идти на курс. На одной площадке - jun, на другой площадке pre-middle, на третьей вообще без опыта, хотя вроде бы программы курсов по большей части совпадают. Это путает, злит, напрягает. Как будто достаточно писать конкретику, а грейды оставить при себе (разный взгляд на грейды никуда не деть). Под конкретикой могут быть знания, опыт применения определенных технологий и тд. Мне пришлось все это формулировать самому. 🔖Описание формата размазано по всей странице, хотя нужен минимум информации: сколько часов/занятий, периодичность, дни, время, процент теории и практики, онлайн-встречи с преподом/записи уроков/интерактивное с ботами и ИИ и прочее. 🔖Авторы и ведущие. Не всегда понятно, кто делал курс, и кто из свиты ведущих проводит те или иные уроки/темы/модули, а фактор личности-эксперта во многом ключевой при выборе. 🔖Невозможность скачать программу курса хоть в каком-то виде - это просто трагедия. 🔖Конструктор программ из модулей. Нет такого, а хотелось бы. Не смог найти продвинутого курса по СА, который подошел бы компании, где я работаю. Много лишних модулей, условно 3 занятия на темы про Power-BI, прототипирование в Figma…Зачем? А то, что хочется и нужно, отсутствует. Также не стоит забывать, что роль СА существенно может отличаться от компании к компании. Единицы мелким текстом пишут, что могут составить программу - звоните, пишите! Видимо они и в дамках на рынке. Это было бы прорывом - собирать под себя программу из модулей, как пиццу в ресторане, без лишних звонков. Если кто владеет такими курсами, то поделитесь плз. Что-то похожее я видел у IBS (ex-Luxoft), но не хватает подсказок о степени связанности и нужном порядке прохождения. 🔖Олдскульные противопоставления в программах курсов - soap & rest, xml & json, монолиты & микросервисы и т. п. Не одобряю - как только не тривиальная ситуация, то тупик, так как включается бинарность и давят отложения в памяти о кол-ве плюсиков и минусиков в табличке сравнения. Хотя куда эффективнее давать «насмотренность» по технологиям с конкретными живыми примерами применения, а если хочется углубиться в конкретное, то возвращаемся к модульности - доплати и изучай websockets или graphQL или gRPC - что угодно душе или твоей компании. Столкнувшись с массой трудностей и сомнений (а я привел лишь основные), просидев у монитора 3 дня и прочитав лендинги около 100 курсов, я все-таки смог составить топ-подборку курсов для разного уровня СА, с разбивкой по стоимости, формату, минимальным требованиям по подготовке и компетенциями под развитие на выходе. Если такое вам нужно, то готов поделиться - ставьте 💯

Чем занимается системный аналитик в продуктовой компании? Выделим сперва направления разработки в рамках продуктовой организации: ◻️Клиентские сервисы, которые нацелены на удовлетворение потребностей конечного пользователя продукта. ◻️Внутренние сервисы, которые заточены под обработку данных, которые генерят клиентские сервисы. Такие сервисы служат интересам компании: маркетинг, продажи, поддержка, биллинг. ◻️Платформенные решения, как для улучшения клиентского опыта, так и в целях производственной необходимости (переход на новую архитектуру); ◻️Автоматизация бизнес-процессов компании: hr-процессы, бухгалтерия, процессы разработки и деплоя. Мы поговорим сегодня о первом пункте, так как он больше всего вызывает вопросов. 🔷Синхронизация участников команды для наиболее точного соответствия реализации исходным требованиям. Основной фокус у владельца продукта (ВП) - генерить и проверять продуктовые идеи. Если его перегружать другими заботами, то рано или поздно ВП скатится в какую-то гибридную роль, что не добавит качества продукту. И здесь на помощь приходит СА, который лучше всего подходит на роль единой точки входа (в том числе - «прокси») для всех вопросов, возникающих по ходу разработки. 🔷Обеспечение эффективного планирования. Для того, чтобы можно было дать обещания стейкхолдерам и/или конечным пользователям, ВП требуется «точная» оценка затрат на разработку. И в его интересах получить это как можно раньше. Поэтому, СА «встречает» продуктовую идею, прокапывает область возможных решений, взаимодействует с командой, и формирует постановку в той степени детализации, которая позволит команде дать оценку - обычно команды разработки придумывают критерии соответствия постановки возможности оценки, тем самым формируют контракт с системным аналитиком и защищают себя от лишнего стресса. 🔷Полезное влияние на «первичный» бэклог. СА - полноценный участник этапа исследования (Discovery), поскольку "что" делать в продукте зависит в том числе от текущей реализации и ограничений. В качестве примера возьмем потребность добавить в систему отчет - казалось бы, что все данные для отчета хранятся (и это уже может понимать сам ВП на этапе формирования идеи), но механизмов в системе для обеспечения должного уровня качества (например, время ожидания клиентом) может не быть - например, сервиса асинхронной печати или подходящего представления в БД (view). Первичную валидацию проще отдать СА, особенно в условиях обсуждения идей на ранних этапах. 🔷Проектирование новой функциональности, где требуется пересмотр логической модели данных в сторону выделения новых сущностей или вовсе выделения новых субдоменов. Подобные случаи возникают не часто в зрелом продукте, но они возникают. И далее происходит классическая история, когда ВП вместе с девелоперами тратят много ресурсов или делают костыли. В таких задачах СА может проявить себя на «все деньги». Поскольку подобное возникает эпизодически, то эффективнее с точки зрения ресурсов может стать формат открытой гильдии СА, что предполагает привлечение аналитика по запросу к задаче (без закрепления за командой) 🔷Участие в разработке тестов для автоматизации. Сперва описывать функциональную спецификацию, а затем переводить в формат под BDD (например), расточительно в условиях гибкой и быстрой разработки. 🔷Поддержка базы знаний. Кто-то должен успевать делать реверс-инжинирнг требований, и следить за целостностью и корректностью всей документации по продукту. 🔷Обеспечение кросс-командных взаимодействий. Если брать крупный финтех, то работу нескольких команд в рамках внедрения новой функциональности могут координировать выделенные роли, но к сожалению такое разделение труда не все могут позволить, поэтому подобное выпадает на ВП, которому нужна поддержка в части организации логической и технической декомпозиции и планирования последовательности выполнения работ. И снова СА. Резюмируя, попав в продуктовую компанию вы найдете себе применение в ролях аналитика и проектировщика ИС - соотношение прежде всего будет зависеть от масштаба клиентских сервисов и обязанностей ваших коллег.

На конференции WAW 2024 было выступление на тему почему системный аналитик не занимается системным анализом. К слову, мне удалось поучаствовать в рецензировании - именно эта деятельность и личный опыт с попытками рационального мышления привели меня к следующей мысли: Ожидаю, что в течение 5 лет на рынке РФ состоится разделение (и похороны) профессии системного аналитика на: 🟢Аналитик информационных систем, который будет обладать базовыми навыками нынешних BA/SA/PA/DA. По-простому, специалист, способный в анализ ИТ-системы с разных сторон - хотелки бизнеса с заглядыванием за «фасад»; НФТ и QA (quality assurance); опора на данные (от анализа логов системы до продуктовых метрик). Такой специалист найдет себе место как в заказной, так и в продуктовой разработке (с потенциалом стать владельцем продукта). Основным результатом деятельности будет документ функциональной спецификации с фокусом на реализацию, что по сути является итогом функционально-логического проектирования. Отмечу, что в будущее «бизнес-аналитиков IT», которые только собирают требования в организации к ПО и «вручают» их системному аналитику я не верю (как минимум на рынке РФ). Ранее мне часто приходилось «переделывать» подобные требования с учетом различных ограничений - технологических и ресурсно-организационных. Да и в целом…как-то слабо с точки зрения инженерии требований, поэтому было легче и быстрее выцепить цели бизнеса и пользовательские требования, далее самому сформировать область возможных решений на функционально-логическом уровне проектирования (или только «функционально-») Также я ожидаю типизацию по классу систем и/или платформам, чтобы кандидаты заходили на проекты как «родные». Подобное уже и сейчас встречается в вакансиях, например «Системный аналитик CRM» (привет hh). 🟢Проектировщик ИС. Все, что связано с System Design. И преуспеют те, кто с техническим бэкграундом в разработке, особенно кто прикладывал руку к ML/AI. Вместе с этим предполагаю, что они чаще всего будут выполнять роль техлида на проекте. Почему нет? Архитектор решений в свою очередь вполне может стать высшим грейдом для этой профессии - не вижу здесь различий в ядре компетенций. А что насчет границы? Проектировщик ИС берет на ревью результаты функционально-логического проектирования от аналитика ИС. Владеют они этим в равной степени - для них это единый язык коммуникации на проекте. Что думаете о таком разделении? ⬇️

Всем привет! Возвращаюсь к вам со списком уроков, которые я извлек из проектов внутренней автоматизации. ◻️ В условиях жестких сроков нельзя стартовать проект, если: - Не определен лидер мнений в команде разработчиков - Не назначена роль того, кто будет принимать ключевые волевые решения внутри всей команды - Отсутствует DoR (Definition Of Ready) = критерии готовности постановки задачи для разработки. Это позволило бы сразу определить границу в части взаимных ожиданий «аналитик не написал, или не увидели очевидное разработчики и тестировщики» ◻️ Не тратить время на ревью ТЗ силами команды, если команда не готова читать погружаться в исходное ТЗ и вникать в общую картинку. Вовлекать команду только при готовности постановки, а если они пытаются сами обратиться к мотивации тех или иных решений, то точечно погружать их в определенные пункты ТЗ. ◻️ Готовить данные для прода со старта проекта, так как это оказалось сложно, нервно и повлияло на состав ТЗ и проектных решений, так как не все «задуманные» данные нашлись - под конец проекта неожиданно выявилось, что у нас нет части справочных данных, а на экране уже были предусмотрены колонки в таблице под их отображение. Как итог ни данных, ни экономии драгоценного свободного места на экране, потому что просто не успели. ◻️ Не спешить принимать решения, если команда разработки настаивает на упрощении ТЗ, чтобы «успеть» в сроки. Стоит брать паузу, а далее соотносить предлагаемые изменения на цели бизнеса и требования пользователей - проще это делать при наличии трассировки требований. ◻️ В условиях разработки «супер-MVP» необходим план организационных и технических мероприятий на случай ошибок. Например, дополнительные БД-конверсии (миграции данных), в том числе откатные. Или конкретные фразы для отработки возражений пользователей или потенциального «неприятия» новой системы. ◻️ Не смешивать роли. В моей истории я был единственным аналитиком проекта и ключевым пользователем новой системы. Подобное провоцирует риски: 🟣 Искажения восприятия системы - она может казаться простой и удобной с точки зрения пользователя под влиянием того, что вы автор ТЗ и проектных решений. 🟣 Подмены требований определенного класса пользователей - «мне точно нужно, а значит и другим подойдет». Другими словами, неосознанно можно сделать себя ключевой персоной. Как не допустить: 🟢 давать солировать другим пользователям-источникам требований, соответствующим вашей бизнес-роли 🟢 при сомнениях доносить до них идеи и согласовывать. Не думать в этот момент о том, как это повлияет на ТЗ и дизайн системы. ◻️ Эскалировать, если ЗЛ не вовлекаются в проект или думают, что у них останется опция не переходить на новую систему 😄 ◻️ Не надеяться на то, что кто-то сделает «ничейную» работу. Предлагать самостоятельно план действий и вписывать туда ответственных, если выделенной роли проектного менеджера не предусмотрено.

Концептуальная, логическая или концептуально-логическая модель данных? Много определений и точек зрения слышал от коллег и экспертов, но больше всего удивляет, когда используется контекст проектирования баз данных. Это только одна область применения - не стоит ограничиваться этим. Рекомендую доклад Михаила Максимова на 35 минут на тему уровней моделирования данных - лаконично, просто и с примерами из опыта. А если нет времени смотреть, то ниже основные тезисы: ➡️Три уровня моделирования сущностей: 🔹Концептуальный - сущности на верхнем уровне абстракции, которые используются в бизнес-процессах, бизнес-сервисах, при описании продуктов и услуг; 🔹Логический - сущности обрабатываются в рамках информационной системы 🔹Физический - сущности, обусловленные особенностями реализации логической модели на определенной технологической платформе. ➡️Примеры методов моделирования: 🔹Концептуальный - Mind Map; 🔹Логический - ER model, Class Diagram; 🔹Физический - XML Schema. ➡️Зоны ответственности: 🔹Системный аналитик - логический уровень; 🔹Бизнес-аналитик - концептуальный; 🔹Архитектор системы - логический и физический. ➡️Перед тем как собирать требования с заказчиков проекта, которые обычно являются руководителями своих подразделений, нужно выровнять терминологию - через концептуальную модель. Первая версия может состоять из терминов локальных нормативных актов (ЛНА) - в основе фрагменты концептуальной модели (предметная область слишком большая). ➡️Фрагменты позволили выявить смежные области -> определить дополнительные заинтересованные стороны -> доработать модель. ➡️Сначала изменили подход бизнеса через моделирование ЛНА, а потом под это сделали решение. Идеально, если информационная модель станет основной для новых версий ЛНА. ➡️Наибольшую ценность представляет не набор моделей разных уровне, а трассировка между ними - где проходят коммуникации между разными ролями. Нормально, если одна логическая сущность системы реализует 2 и более концептов - аналогично в обратную сторону. ➡️Трассировка моделей - взаимовыгодная история. Системный аналитик может проверить реализуемость концептуальной модели (определенной с заказчиками) в рамках заданного бюджета и ограничений текущей системы (на логическом и/или физических уровне), архитектор - убедиться в корректности решений (изучая концептуальную модель) с точки зрения масштабирования и прочего. Поставьте, пожалуйста, реакцию 🔥, если пост оказался полезным.

Фундаментальные Soft skills для IT Обратите внимание на первый пост, где я провел границу между soft skills и личностными качествами. Аналитическое мышление 📕 Умение обрабатывать информацию. Способы развития: 💡Решать математические задачи уровня школьного образования 💡Грызть линейную алгебру, математический анализ, дискретную математику и логику 💡Читать книги: 📚детективы, так как помогает моделировать ситуации и искать ответы; 📚философию. Подойдет И. Кант - только не торопиться. 💡Ситуационное моделирование. Учитесь через личные жизненные ситуации - анализируйте решения других людей 💡Квесты. Критическое мышление 🤔 Умение ставить под сомнение любую информацию, в том числе собственные убеждения. 📙Книги «Введение в критическое мышление и теорию креативности» Джо У. Ф. Лау хватит сполна. Креативное мышление 💡 Умение генерировать ценные идеи. Это не фантазирование, иначе можно было выкинуть «ценные» - значит можно воплотить с пользой. 💡Критическое мышление во многом способствует успехам креативного мышления - это один из тезисов книги, которую я выше упомянул в рамках критического мышления. Эффективная коммуникация🤌 Это не владеть художественным стилем. Коммуникация считается эффективной, если способствует решению задач и не выходит за определенные временные рамки. Границы определяются опытно и статистически, но если вы каждые 10 минут пишете в личку разработчикам с одиночными вопросами на тему того, как что-то работает, то вы тратите свои и чужие временные ресурсы. Если не выполняется цель встречи за отведенный лимит времени, где вы были инициатором, то аналогично. Мы не рассматриваем внешние факторы или поведение других участников - возможны разные причины, но речь в данном контексте не об этом. Для развития необходимо: 💡Выучить терминологию проекта 💡Познакомиться со сферой интервьюирования 💡Применять на практике методы критического мышления, не позволяя никому манипулировать и вредить результатам работы 💡Фиксировать итоги групповых коммуникаций, связанных с задачами по проекту Тайм-менеджмент🔜 🔹Умение разбивать задачу на этапы для более точной оценки. Если затрудняетесь дать оценку, то возьмите референс и оценивайте исходя из соотношения сложности. 🔹Умение управлять ожиданиями - если ваш проектный менеджер спланировал командные активности под обещанный вами дедлайн, то заявление о неудаче за час до дедлайна приведет к одним последствиям, а за три дня - к другим. Чем раньше заявить о проблемах, тем больше опций изменить планы. Также это снизит эмоциональность оценок в вашу сторону. Ориентация на результат 😵 Умение действовать для достижения результата: собирать ожидания заинтересованных лиц относительно результатов задачи, проекта или работы, выделять главную и второстепенные цели, применять тайм-менеджмент, устранять препятствия по ходу, например эскалировать проблемы и обращаться к коллегам. 💡Требует знаний соглашений в компании, процессов разработки и влияния ролей между собой на общий результат. Профессиональная смелость 🗿 Имеет решающее значение в части продвижения по грейду и карьере - выдвигать и реализовывать идеи, принимать ситуационные решения и брать ответственность. Развитие через действия: 💡Говорить нет, когда нарушают границы ваших обязанностей без выгоды для вас. Если опция "говорить нет" записана в рабочей инструкции или корпоративных ценностях, то говорить нет проще, так как снижается фактор личных ощущений 💡Вносить предложения и идеи, даже если сложно увидеть последствия 💡Поддерживать близкую вам точку зрения аргументированно, избегая нейтральных оценок 💡Анализировать поведение смелого сотрудника

Как не допустить ошибок при оценке Soft Skills Когда дело доходит до практического применения Soft skills при оценке кандидата на соответствие вакансии или оценке уровня и результатов сотрудника, то можно не заметить, как вместо софтов невольно оцениваем черты личности или характер по типу «сотрудник классный, умный, адекватный, с ним приятно работать». В этом случае под оценкой на самом деле скрывается восприятие, что вызывает: ❗️Ошибки в найме, так как восприятие - чувства. Чувства - субъективно и ситуативно. ❔Сталкивались ли с ситуацией, когда после собеседования склонялись к отказу, а на следующий день все-таки выставили офер? Если да, то часто в этом кроется причина - восприятие кандидата. ❗️Стагнацию в развитии сотрудника, так как не можем дать корректную обратную связь. Представим, что сотрудник легко выявляет требования и пишет постановки для разработчиков, но в продакшн выходит не то, что ожидалось, или сотрудник постоянно выдает результат с нарушением сроков. Затем, когда наступает момент донесения обратной связи, то диалог сводится к указанию ошибок в работе или подмене софтового навыка на хардовый: сотрудник не способен проектировать архитектуру на должном уровне, поэтому нарушает дедлайн, хотя проблема на самом деле заключается в неспособности управлять ожиданиями или тайм-менеджменте.  Решение В организации важно, чтобы сотрудник решал трудовую функцию и давал результат. Какой сотрудник личностно - вторично, если это не влияет на: ➡️ Эффективность и качество работы ➡️ Мотивацию окружающих Для соблюдения взаимного комфорта стоит утвердить на уровне компании список «норм» в формате культурных и корпоративных ценностей: - не переходить личные границы при рабочих конфликтах; - считать вклад каждого сотрудника в успех равноценным; - отвечать лично за работу и не перекладываем неудачи на коллег. Нормы полезно применять в найме, на этапах HR-скрининга и технического интервью. О нормах также стоит напоминать сотрудникам. Теперь к софтам Soft skills («Мягкие» навыки) - отдельный тип навыков. Список требуемых навыков отличается в зависимости от роли в IT и даже внутри одной компании - аналитику важно владеть эффективной коммуникацией для синхронизации участников проекта вокруг подготовки ТЗ и для сопровождения этапа разработки и тестирования. Так ли важно этим владеть другим ролям - вопрос, но «среднебольнично» объем коммуникаций у разработчика меньше. За выявление уровня навыков и их развитие отвечает руководитель профессионального направления. Уровень софтов у сотрудника оценивается по маркерам или индикаторам проявления на практике. На основании этого на корректном (следовательно бережном) языке можно донести обратную связь сотруднику - примеры ситуаций, где проявление определенных софтов повлияло на результат. 🔜О том, какие Soft Skills нужны аналитику, и как они влияют на результат, я расскажу в следующем посте. Поставьте, пожалуйста, реакцию 🔥, если пост оказался полезным.