tgindex

SA LEAD

описание

👨🏿‍💻 Блог руководителя системного анализа в продуктовой IT-компании.

← к каналу@lead_sa
255
подписчиков
Охват к подписчикам
254,1%
ERR
Реакции к просмотрам
2,38%
309 на 20 постов
Пересылки к просмотрам
1,34%
174
Постов в день
0,0
всего 20

Где отзываются чаще

доля реакций к просмотрам
  • 13 мар. 2024 г.Я, как руководитель направления системного анализа, хочу иметь на руках подборку внешних курсов, чтобы способствовать развитию сотрудников для повышения качества результатов их работы во благо компании. В ситуации, когда ко мне обращается сотрудник за программой развития, мне нужно дать подходящие курсы (но не только их) в балансе интересов компании и сотрудника, чтобы… Всем привет! Нет, это пост не о правилах написания US или JBTD. Пост о том, что не так с площадками, где продаются курсы на тему системного анализа и проектирования. Мои тезисы могут быть полезны продавцам/авторам курсов и тем, кто активно ищет себе обучение. 🔖У каждого продавца свои требования по min грейду, от которого стоит идти на курс. На одной площадке - jun, на другой площадке pre-middle, на третьей вообще без опыта, хотя вроде бы программы курсов по большей части совпадают. Это путает, злит, напрягает. Как будто достаточно писать конкретику, а грейды оставить при себе (разный взгляд на грейды никуда не деть). Под конкретикой могут быть знания, опыт применения определенных технологий и тд. Мне пришлось все это формулировать самому. 🔖Описание формата размазано по всей странице, хотя нужен минимум информации: сколько часов/занятий, периодичность, дни, время, процент теории и практики, онлайн-встречи с преподом/записи уроков/интерактивное с ботами и ИИ и прочее. 🔖Авторы и ведущие. Не всегда понятно, кто делал курс, и кто из свиты ведущих проводит те или иные уроки/темы/модули, а фактор личности-эксперта во многом ключевой при выборе. 🔖Невозможность скачать программу курса хоть в каком-то виде - это просто трагедия. 🔖Конструктор программ из модулей. Нет такого, а хотелось бы. Не смог найти продвинутого курса по СА, который подошел бы компании, где я работаю. Много лишних модулей, условно 3 занятия на темы про Power-BI, прототипирование в Figma…Зачем? А то, что хочется и нужно, отсутствует. Также не стоит забывать, что роль СА существенно может отличаться от компании к компании. Единицы мелким текстом пишут, что могут составить программу - звоните, пишите! Видимо они и в дамках на рынке. Это было бы прорывом - собирать под себя программу из модулей, как пиццу в ресторане, без лишних звонков. Если кто владеет такими курсами, то поделитесь плз. Что-то похожее я видел у IBS (ex-Luxoft), но не хватает подсказок о степени связанности и нужном порядке прохождения. 🔖Олдскульные противопоставления в программах курсов - soap & rest, xml & json, монолиты & микросервисы и т. п. Не одобряю - как только не тривиальная ситуация, то тупик, так как включается бинарность и давят отложения в памяти о кол-ве плюсиков и минусиков в табличке сравнения. Хотя куда эффективнее давать «насмотренность» по технологиям с конкретными живыми примерами применения, а если хочется углубиться в конкретное, то возвращаемся к модульности - доплати и изучай websockets или graphQL или gRPC - что угодно душе или твоей компании. Столкнувшись с массой трудностей и сомнений (а я привел лишь основные), просидев у монитора 3 дня и прочитав лендинги около 100 курсов, я все-таки смог составить топ-подборку курсов для разного уровня СА, с разбивкой по стоимости, формату, минимальным требованиям по подготовке и компетенциями под развитие на выходе. Если такое вам нужно, то готов поделиться - ставьте 💯7,83%
  • 6 июн. 2024 г.Путь аналитика или 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 тысяч руб., не говоря уже о наличии успешной школы, ваших сообществ и платных каналов. Что забыл? добавляйте ⬇️ 💯 Таков путь. 🏆 Завидуем. ❤ Так правда можно?5,53%
  • 31 янв. 2024 г.Фундаментальные Soft skills для IT Обратите внимание на первый пост, где я провел границу между soft skills и личностными качествами. Аналитическое мышление 📕 Умение обрабатывать информацию. Способы развития: 💡Решать математические задачи уровня школьного образования 💡Грызть линейную алгебру, математический анализ, дискретную математику и логику 💡Читать книги: 📚детективы, так как помогает моделировать ситуации и искать ответы; 📚философию. Подойдет И. Кант - только не торопиться. 💡Ситуационное моделирование. Учитесь через личные жизненные ситуации - анализируйте решения других людей 💡Квесты. Критическое мышление 🤔 Умение ставить под сомнение любую информацию, в том числе собственные убеждения. 📙Книги «Введение в критическое мышление и теорию креативности» Джо У. Ф. Лау хватит сполна. Креативное мышление 💡 Умение генерировать ценные идеи. Это не фантазирование, иначе можно было выкинуть «ценные» - значит можно воплотить с пользой. 💡Критическое мышление во многом способствует успехам креативного мышления - это один из тезисов книги, которую я выше упомянул в рамках критического мышления. Эффективная коммуникация🤌 Это не владеть художественным стилем. Коммуникация считается эффективной, если способствует решению задач и не выходит за определенные временные рамки. Границы определяются опытно и статистически, но если вы каждые 10 минут пишете в личку разработчикам с одиночными вопросами на тему того, как что-то работает, то вы тратите свои и чужие временные ресурсы. Если не выполняется цель встречи за отведенный лимит времени, где вы были инициатором, то аналогично. Мы не рассматриваем внешние факторы или поведение других участников - возможны разные причины, но речь в данном контексте не об этом. Для развития необходимо: 💡Выучить терминологию проекта 💡Познакомиться со сферой интервьюирования 💡Применять на практике методы критического мышления, не позволяя никому манипулировать и вредить результатам работы 💡Фиксировать итоги групповых коммуникаций, связанных с задачами по проекту Тайм-менеджмент🔜 🔹Умение разбивать задачу на этапы для более точной оценки. Если затрудняетесь дать оценку, то возьмите референс и оценивайте исходя из соотношения сложности. 🔹Умение управлять ожиданиями - если ваш проектный менеджер спланировал командные активности под обещанный вами дедлайн, то заявление о неудаче за час до дедлайна приведет к одним последствиям, а за три дня - к другим. Чем раньше заявить о проблемах, тем больше опций изменить планы. Также это снизит эмоциональность оценок в вашу сторону. Ориентация на результат 😵 Умение действовать для достижения результата: собирать ожидания заинтересованных лиц относительно результатов задачи, проекта или работы, выделять главную и второстепенные цели, применять тайм-менеджмент, устранять препятствия по ходу, например эскалировать проблемы и обращаться к коллегам. 💡Требует знаний соглашений в компании, процессов разработки и влияния ролей между собой на общий результат. Профессиональная смелость 🗿 Имеет решающее значение в части продвижения по грейду и карьере - выдвигать и реализовывать идеи, принимать ситуационные решения и брать ответственность. Развитие через действия: 💡Говорить нет, когда нарушают границы ваших обязанностей без выгоды для вас. Если опция "говорить нет" записана в рабочей инструкции или корпоративных ценностях, то говорить нет проще, так как снижается фактор личных ощущений 💡Вносить предложения и идеи, даже если сложно увидеть последствия 💡Поддерживать близкую вам точку зрения аргументированно, избегая нейтральных оценок 💡Анализировать поведение смелого сотрудника4,58%
  • 17 мар. 2024 г.Я, как руководитель направления системного анализа, хочу иметь на руках подборку внешних курсов, чтобы способствовать развитию сотрудников для повышения качества результатов их работы во благо компании. В ситуации, когда ко мне обращается сотрудник за программой…4,28%
  • 27 мая 2024 г.Всем привет! Я недавно участвовал в достаточно крупном чемпионате по системному анализу. В тройку победителей не попал (только 15-е место), но пообщался с классными ребятами, и посмотрел, как они пишут ТЗ или TDD (Technical Design Document) на разработку ИТ-решения - речь о развитии текущей системы (добавление новой функциональности). Все сводится к следующей универсальной структуре, с чем «спешу» с вами поделиться. 1️⃣Исходные требования/проблематика/запрос Что мы хотим сделать и почему - с точки зрения пользователей системы. В философию «ну вот это пользователю на самом деле не нужно, это нужно его бизнес-руководителям» уходить не будем, так как тянет на отдельный пост. Считаем, что мы уже сделали этот анализ и спустились на уровень пользователя (или «моря», как пишет в своей известной книге Коберн). 2️⃣Текущее состояние и поведение системы (AS IS) Необходимо понимать функциональность и структуру системы для того, чтобы не упустить из виду неожиданное влияние от реализации Исходные требования/проблематика/запрос на бизнес-логику, атрибуты качества, архитектуру и процессы сбоку (например, развертывания и поддержки) 3️⃣ Мотивация Почему мы, в роли поставщика/разработчика продукта, хотим удовлетворить Исходным требованиям/проблематике/запросу. 4️⃣Предлагаемое решение (TO BE) Структура ниже может отличаться в зависимости от содержания разделов выше. 🔷 Сценарии использования Является набором функциональных требований в контексте решения пользователем задачи. Можно пропустить эту часть, если вы можете сразу формализовать функции и алгоритмы. Но я рекомендую не пропускать этот шаг, как минимум для самоконтроля, как максимум, чтобы команда лучше понимала контекст автоматизируемых задач пользователя. 🔷 Роли и права доступа Изменения прав доступа по текущим ролям/добавление новых ролей. 🔷 НФТ Скорее всего они уже где-то описаны для системы, и достаточно их приложить, чтобы указанные лимиты/пороги не были нарушены. Если изменение требует пересмотра значений, то необходимо прежде убедиться, что это возможно и уже описать здесь новые показатели. 🔷 Сущности Логическая модель данных, на которую вы будете: - ссылаться при описании бизнес-логики - опираться при проектировании интерфейсов и модели хранения данных. Несмотря на то, что вы сделаете это проектирование (см. далее разделы), важно оставлять команде «первоисточник» в целях стимулирования предложнений в части лучших проектировочных решений. 🔷 Функции и алгоритмы (бизнес-логика) Как изменяются объекты системы при различных условиях и/или действиях пользователей. 🔷 Интерфейсы Все точки вызова алгоритмов и функций. Например, API, UI, JMX и т.п. 🔷 Хранение данных Моделирование данных под конкретную СУБД. 🔷 Архитектура Требования к компонентам - как необходимо доработать компоненты (сервисы) системы, чтобы удовлетворить заявленным требованиям и связанным проектным решениям (например, интерфейсам). Это будет основой для последующей технической декомпозиции, которую делают разработчики для распараллеливания работ. Если добавляется новый компонент, то необходимо приложить обновленную схему архитектуры. Межкомпонентные взаимодействия - описание того, как работают вместе компоненты системы внутри или с внешними сервисами (интеграции), с указанием того, какие функции инициируют процесс. 🔷 Инфраструктура Любые изменения в области инфраструктурного ПО и вычислительных мощностей. Например, добавление логирования новых запросов, или расширение мониторинга и списка алертов. 🔷 Конфигурация Любые параметры, определяющие как будет работать функциональность функциональности, или вовсе включающие/отключающие функциональность (фичефлаги). Кому нужен пример такой работы, то пишите в личку (скину свое 🫡).3,76%
  • 20 мар. 2024 г.Текущая функциональность не изменяется… Аналитик готовит очередную спецификацию требований и постановку задачи на разработку новой функциональности в монолитной системе со сложной бизнес-логикой. Затрагивается поведение ряда функций системы - для них описывается новое ожидаемое поведение. То, что не затрагивается, фиксируется в виде как в текущей реализации/функциональность не изменяется Тестировщик готовится к тестированию, в том числе к регрессу. Для этого обновляет и создает новую тестовую документацию. Наткнувшись на такую формулировку, пытается в документации найти пропущенные/забытые знания. Не находит. Считая аналитика источником истины и ходячей базой знаний, тестировщик идет к нему с вопросом, а чаще с требованием - добавить «недостающее описание» о текущем поведении в задачу. Аналитик парирует: Поведение в этом месте не изменяется! Я исследовал. Если вам не хватает информации, то воспроизводите сами для ваших нужд. Вы же тестировщики. А судьи что? Мне довольно легко понять боли обеих сторон. Но решить, как правильно и чья эта обязанность или зона ответственности было не просто. А что если поискать ответ со стороны провокационных вопросов? Зона ответственности аналитика это ИТ-продукт, за который отвечает команда или постановка задачи? Цель анализа и проектирования это грамотная постановка задачи, или задачу дальше по конвейеру пустить? Я считаю, что аналитик отвечает за ИТ-продукт, как и тестировщик, разработчик и другие участники команды разработки. Насчет постановки - ключевой вопрос в необходимости/достаточности, ответ на который лежит в плоскости командных потребностей и договоренностей. При этом считаю важным: 💡Во время исследования AS IS системы аналитиком вносить заметки в пробелы документации по текущей версии ПО. Когда ты в контексте, то восполнить потерянную документацию можно легко и быстро, и тем самым сэкономить время членам команды на более поздних этапах. Если времени вносить изменения пр ходу дела нет, то явно проговаривать текущее (любое волнующее других) поведение на командных встречах по обсуждению задач. 💡Тестировщикам следить за тестовой документацией, и не надеяться на качество и полноту иной документацию. ❓А вы что думаете? Допускаете ли вы в своих документах подобные формулировки? Приводило ли такое к проблемам с качеством ПО?3,43%
  • 9 апр. 2024 г.Первая работа в IT В сентябре 2016 года я переехал в Москву для продолжения обучения на программе магистратуры бизнес-информатики. На вводной встрече для студентов Главный менеджер программы обучения сказал - «Если вы не будете работать параллельно обучению, то будущие 2 года - бесполезная трата времени». Понял. Принял. К началу октября собрал первое резюме. В разделе опыт - 3 месяца учебной практики, где писал статьи для хелпцентра какой-то CMS российского производства. А также явно указал, что я действующий студент ВШЭ, поэтому задерживаться после 18:00 не смогу. Спасибо университету, который ставил пары не раньше 18:30. Преподаватели, кстати, вместе со студентами частенько опаздывали, так как задерживались на работах. Все друг друга понимали - фокус был на результат и качество. Это сильно отличало новый ВУЗ от предыдущего. На тот момент я толком не понимал типизацию аналитиков, поэтому откликаюсь на все подряд: бизнес-аналитик, аналитик систем, аналитик данных, аналитик бизнес-процессов. Многие одногруппники целенаправленно искали компании-системные интеграторы, с фокусом на топ-10. И это была отличная стратегия для старта (о чем я немного пожалел в дальнейшем). Я не смотрел на названия компаний, так как ставил задачу найти работу, как можно быстрее, чтобы начать зарабатывать хоть какие-то деньги. На 20 откликов - один ответ. После первого собеседования спустя день я получил офер. Собеседование было в формате - что знаешь и умеешь, кто ты по жизни. Вакансия называлась аналитик ИС. Это была книжная розничная сеть - около 100 точек продаж по Москве и Подмосковью. В части плана договорились: 1) Освоить предметку через выезды в поля и операционную деятельность по работе с заказами в негативных кейсах - когда что-то потерялось в процессе доставки, брак, пересортица. 2) осознать проблемы, далее предложить оптимизацию, в том числе с доработками ИС, если оно того потребует. По условиям: ✔️50 тыс. рублей, после ИС подъем до 80. Это в текущих ценах (брал годовую ставку инфляции 8%). Официально (не в конверте) только половина; ✔️бесплатные обеды и ужины ; ✔️уютный офис с видом на кладбище…🪦 Что еще нужно студенту для счастья, которому университет выдал новенькое общежитие в пределах МКАД? Продано. Было две ставки - взяли двух аналитиков без опыта. «Напарник» очень помог тем, что постоянное косячил. Это делало меня «выдающимся» специалистом на общем фоне. Он тратил много времени на красивые нотации описания процессов, но рисовал то, что вызывало нервные приступы у нашего руководителя. Его спустя 2 месяца уволили. Что было интересного на первом месте работы: 🔥Выезжал на точки продаж (далее - ТП) и на склады для исследования текущих бизнес-процессов (зимой, когда на складе было холоднее, чем на улице). Особенно весело было пытаться интервьюировать рабочих склада 🤡 🔥Видел радость в глазах директоров ТП, когда получилось упростить им некоторые процессы. Например, в розничной сети был алгоритм, который раз в сутки формировал заказы на переброски товаров между ТП транзитом через сортировочный центр в зависимости от динамики продаж, в целях пополнения запасов наиболее продаваемых книг. И на каждую книжку делался отдельный заказ, а это отдельная коробка, следовательно больше расходников, временных затрат по упаковке, риски потери при транспортировке, брака и тд. Для сотрудников ТП добавили опциональное укрупнение по фильтру конечных ТП, попутно изменив процессы транзита на складе 🔥Писал ТЗ, отталкиваясь от интерфейса системы - по-другому не умел. И это срабатывало, так как разработчики сидели уже второй десяток лет на проекте, и знали систему от и до 🔥Узнал о Вигерсе от опытного аналитика смежного подразделения. Через два месяца получаю повышение с 50 до 55 тыс. рублей. При окончании ИС рассчитываю на 80, но получаю 60 с непонятными дальнейшими перспективами. Спустя полгода работы в компании я ухожу. Продолжение…3,41%
  • 20 февр. 2024 г.На конференции WAW 2024 было выступление на тему почему системный аналитик не занимается системным анализом. К слову, мне удалось поучаствовать в рецензировании - именно эта деятельность и личный опыт с попытками рационального мышления привели меня к следующей мысли: Ожидаю, что в течение 5 лет на рынке РФ состоится разделение (и похороны) профессии системного аналитика на: 🟢Аналитик информационных систем, который будет обладать базовыми навыками нынешних BA/SA/PA/DA. По-простому, специалист, способный в анализ ИТ-системы с разных сторон - хотелки бизнеса с заглядыванием за «фасад»; НФТ и QA (quality assurance); опора на данные (от анализа логов системы до продуктовых метрик). Такой специалист найдет себе место как в заказной, так и в продуктовой разработке (с потенциалом стать владельцем продукта). Основным результатом деятельности будет документ функциональной спецификации с фокусом на реализацию, что по сути является итогом функционально-логического проектирования. Отмечу, что в будущее «бизнес-аналитиков IT», которые только собирают требования в организации к ПО и «вручают» их системному аналитику я не верю (как минимум на рынке РФ). Ранее мне часто приходилось «переделывать» подобные требования с учетом различных ограничений - технологических и ресурсно-организационных. Да и в целом…как-то слабо с точки зрения инженерии требований, поэтому было легче и быстрее выцепить цели бизнеса и пользовательские требования, далее самому сформировать область возможных решений на функционально-логическом уровне проектирования (или только «функционально-») Также я ожидаю типизацию по классу систем и/или платформам, чтобы кандидаты заходили на проекты как «родные». Подобное уже и сейчас встречается в вакансиях, например «Системный аналитик CRM» (привет hh). 🟢Проектировщик ИС. Все, что связано с System Design. И преуспеют те, кто с техническим бэкграундом в разработке, особенно кто прикладывал руку к ML/AI. Вместе с этим предполагаю, что они чаще всего будут выполнять роль техлида на проекте. Почему нет? Архитектор решений в свою очередь вполне может стать высшим грейдом для этой профессии - не вижу здесь различий в ядре компетенций. А что насчет границы? Проектировщик ИС берет на ревью результаты функционально-логического проектирования от аналитика ИС. Владеют они этим в равной степени - для них это единый язык коммуникации на проекте. Что думаете о таком разделении? ⬇️3,17%
  • 27 янв. 2024 г.Как не допустить ошибок при оценке Soft Skills Когда дело доходит до практического применения Soft skills при оценке кандидата на соответствие вакансии или оценке уровня и результатов сотрудника, то можно не заметить, как вместо софтов невольно оцениваем черты личности или характер по типу «сотрудник классный, умный, адекватный, с ним приятно работать». В этом случае под оценкой на самом деле скрывается восприятие, что вызывает: ❗️Ошибки в найме, так как восприятие - чувства. Чувства - субъективно и ситуативно. ❔Сталкивались ли с ситуацией, когда после собеседования склонялись к отказу, а на следующий день все-таки выставили офер? Если да, то часто в этом кроется причина - восприятие кандидата. ❗️Стагнацию в развитии сотрудника, так как не можем дать корректную обратную связь. Представим, что сотрудник легко выявляет требования и пишет постановки для разработчиков, но в продакшн выходит не то, что ожидалось, или сотрудник постоянно выдает результат с нарушением сроков. Затем, когда наступает момент донесения обратной связи, то диалог сводится к указанию ошибок в работе или подмене софтового навыка на хардовый: сотрудник не способен проектировать архитектуру на должном уровне, поэтому нарушает дедлайн, хотя проблема на самом деле заключается в неспособности управлять ожиданиями или тайм-менеджменте. Решение В организации важно, чтобы сотрудник решал трудовую функцию и давал результат. Какой сотрудник личностно - вторично, если это не влияет на: ➡️ Эффективность и качество работы ➡️ Мотивацию окружающих Для соблюдения взаимного комфорта стоит утвердить на уровне компании список «норм» в формате культурных и корпоративных ценностей: - не переходить личные границы при рабочих конфликтах; - считать вклад каждого сотрудника в успех равноценным; - отвечать лично за работу и не перекладываем неудачи на коллег. Нормы полезно применять в найме, на этапах HR-скрининга и технического интервью. О нормах также стоит напоминать сотрудникам. Теперь к софтам Soft skills («Мягкие» навыки) - отдельный тип навыков. Список требуемых навыков отличается в зависимости от роли в IT и даже внутри одной компании - аналитику важно владеть эффективной коммуникацией для синхронизации участников проекта вокруг подготовки ТЗ и для сопровождения этапа разработки и тестирования. Так ли важно этим владеть другим ролям - вопрос, но «среднебольнично» объем коммуникаций у разработчика меньше. За выявление уровня навыков и их развитие отвечает руководитель профессионального направления. Уровень софтов у сотрудника оценивается по маркерам или индикаторам проявления на практике. На основании этого на корректном (следовательно бережном) языке можно донести обратную связь сотруднику - примеры ситуаций, где проявление определенных софтов повлияло на результат. 🔜О том, какие Soft Skills нужны аналитику, и как они влияют на результат, я расскажу в следующем посте. Поставьте, пожалуйста, реакцию 🔥, если пост оказался полезным.3,13%
  • 18 апр. 2024 г.Пригласите бизнес-аналитика и системного аналилика в 19:00 в пятерочку в спальном районе, когда на кассах и единственном терминале самообслуживания огромные очереди. И спросите у них, как можно решить эту проблему. 💡БА сделает анализ статистики/данных загрузки касс и терминала, распределенной во времени, найдет причины и накидает область возможных решений: от выноса кассы из подсобки с доп. part-time кассиром до активации повышенной временной скидки на онлайн-доставку продуктов. Затем БА посчитает экономику по каждому из возможных решений с оценкой рисков и сделает защиту решений перед бизнесом. 💡СА будет искать возможности развития ПО терминала в целях ускорения обслуживания, с последующим написанием ТЗ для команды разработки. Иначе, если путей улучшения в работе ПО не найдет, предложит поставить второй терминал рядом 😁 ✅ Это пример фокусов профессий и принципиальное различие между ними. ✅ Это пример того, что будет, если пытаться использовать СА в роли БА. ❗️Это подводка к обращению - среди вас есть бизнес-аналитики, кто планирует перейти в СА. При этом в массе вы не являетесь БА в трактовке, которую я дал в примере про пятерочку. Скорее всего вы уже владеете функциональным проектированием на уровне систем. Или же вы работаете в контексте решения проблем бизнеса засчет развития ПО. Вы также считаете, что нужно по сути с нуля овладеть новой профессией. Но это не так. Попробуйте походить по собеседованиям: ❕В худшем случае вы быстрее поймете, что требуют по части логического проектирования, в том числе характер решений на компонентном уровне. Вероятно вам дадут хорошую ОС, и само собеседование добавит вам в копилку знаний и умений; ❕В лучшем - вас возьмут в компанию на ставку СА, где остальное не требуется или будет решаться силами коллеги-старшего аналитика. Вряд ли это будет финтех с офером 300 тысяч. Но путь практики лучше, чем полгода пытаться впитать в себя все курсы по интеграциям/микросервисам/брокерам. К тому же такой стек используется далеко не везде на проектах. Всем удачи в реализации карьерных планов 💌2,76%
  • 21 мар. 2024 г.Привет всем! Хочу поделиться с вами о том, как я выбираю темы постов, подбираю регулярность и время публикаций. Никак. У меня нет контент-плана; я не знаю, о чем будет следующий пост, и в каком стиле он будет написан. Все, что я успел написать за 2 месяца существования канала, было порождено событиями, которые произошли в моих рабочих буднях. Это объясняет то, почему я ничего не писал 2 недели в конце февраля-начала марта. Настолько я ушел в работу, что отстранился от всего. Писал и продолжаю писать план мероприятий по выводу документации компании из одного места 🤡. И далее это все реализовать, объем там до осени… Вдохновился, кстати, докладом Семёна Факторовича. У кого документация в компании ведется формально или ее вообще нет, то крайне рекомендую! Вернемся к теме поста. Канал для меня - хобби, разгрузка от работы, развитие навыков коммуникаций. Ну и конечно, цель - давать пользу. Никакой графомании. Поэтому, если не видите ценность у конкретного поста, не ставьте реакции, а иначе - ставьте) Буду лучше понимать, что интереснее/полезнее. К чему я веду? Пока я не писал две недели, ушло 3 человека. А до этого никакого оттока. Неприятно 🙃, но видимо все логично - нельзя заставлять людей голодать. Виноват. Поэтому, наверное, у меня должен все-таки быть беклог тем, из которого я могу что-то брать в периоды, когда нет событий-источников вдохновения. Напишите, пожалуйста, какие вопросы и темы вам интересны. Заранее благодарен 🫡2,72%
  • 17 апр. 2024 г.Переход из БА в СА Предыдущий пост... Получив классный опыт на первом месте работы в качестве бизнес-аналитика, я умудрился попасть в ГУП на роль проектного менеджера (так оказалось на практике). Через полгода осознал, что свернул не туда, и перешел в заказную разработку ИТ-решений для частной медицины на роль аналитика ИС (так в трудовой и написано). Минимального опыта подготовки ТЗ, в том числе по ГОСТам 34 и 19, хватило для того, чтобы пройти собес, который был достаточно формальным. Оно и понятно - в компании не было никаких процессов вокруг разработки, да и коллектив был численностью до 40 человек. Как будто достаточно было показать себя здравомыслящим человеком и ответить на типовые вопросы о требованиях. На новом месте я уже куда больше касался руками систем - глубоко в части анализа функциональности и никак с точки зрения структурного анализа. Из-за отсутствия второго мне требовалась подстраховка. Эту роль занял архитектор ПО, который также выполнял еще кучу функций на проекте. Он был ревьюером всех моих артефактов для команды разработки. Тем не менее основные ожидания от меня были в том, чтобы закрывать вопросы выявления, разработки и согласования требований, и регулярно делать поставки этого добра для внутренней команды. Это был единственный трушный аджайл в моем опыте - выявили, описали, обсудили внутри, описали для заказчика, согласовали, скинули в разработку в US/JBTD и получили к концу спринта решение с ценностью - выбор лучшего решения из области возможных был тоже за командой. А вишенкой было демо решения разработчиком-исполнителем задачи для заказчиков. К слову, 1 аналитик на 4 команды разработки по 5 человек. Что-то типо LeSS. Думаю, что где-то здесь и зародились базовые умения в системном анализе в моих компетенциях, и уже тогда можно было упаковывать этот опыт, и пытаться продать на рынке с названием Системный аналитик. Но я никуда не торопился, был азарт выпустить крупный проект в эксплуатацию. А что с точки зрения системного дизайна? Только на закате этого этапа карьеры я смог в роли наблюдателя познакомиться немного с: ◻️Архитектурой, на уровне теоретических паттернов ◻️Интеграцией систем, на уровне тестирования веб-сервисов через SoapUI. За два года я устал от такого ритма, и поставил себе задачу зайти в финтех на роль с названием СА. 3 отказа в оранжевом банке, 2 отказа - в красном, 7 отказов + игноров в зеленом. Но восьмая команда взяла меня. Именно здесь подрос ощутимо как СА и проектировщик ИС. Этому способствовало две причины: ✔️С первого дня анализ дефектов и поиск решений. Нужно было находить причины проблем, которые в том числе крылись в структурах данных и архитектуре системы. Также постоянно перед глазами были интеграционные сообщения и адреса конечных точек. ✔️разделение постановки в задаче на две части: бизнес и «системные» требования. Без второго разработчик никогда не брал задачу в работу. А в таких условиях развитие происходило быстрее 🧑‍🎓. Облегчало задачу то, что за каждый компонент в банке как правило отвечает отдельная команда, а это вынуждало меня коммуницировать с аналитиками этих команд. А это тоже обучение и опыт - встречные мнения на попытку заказать доработку или же просто в лоб попросить помощи. ✔️Доверие руководителя аналитиков и менеджера по продукту. Мне казалось (или они скрывали хорошо 😅), что у них нет сомнений в том, что я могу выдать плохой результат. Ошибки конечно были, но и реакции их не были демотивирующими. А какая у вас история входа в вашу текущую профессию? Делитесь в комментариях ⬇️2,65%