Pull to refresh
31
Karma
0
Rating
Немихин Игорь @YgReEk

Системный аналитик

Разговор о самих себе или кто такие IT-шники

заварил дверцы

застрянет в каршеринговой машине

Предлагаете сделать двери всегда открытыми или всегда закрытыми?

Разговор о самих себе или кто такие IT-шники

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

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

Не знаю, где вы тут нашли подмену понятия или почему вы решили что что-то объяснили, но теперь, надеюсь, я явно выразил свою позицию.

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

Разговор о самих себе или кто такие IT-шники

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

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

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

И вся критика, подозреваю, связана именно с этим: вы просите людей, которые уже устали рассказывать неспециалистам а что же такое это ваше IT взять и сделать это снова, но теперь в вашем (обучающем?!) подкасте. При этом сама подача материала работает скорее во вред, чем на пользу.

Разговор о самих себе или кто такие IT-шники

Но слова, что этот подкаст крутой - ваши.

Как вы будете объяснять другим людям вне IT кто такие аналитики в IT, если строите своё же мнение по таким источникам? Это такие переводчики с бизнеса на разработку?

Рядовому пользователю вы не объяснили: и там <language>, и там <language>, что переводить?

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

Разговор о самих себе или кто такие IT-шники

есть очень крутой подкаст о том, кто такие аналитики в айти и как ими стать.

Вот знаете, послушал по 10 минут 1 и 4 выпуск, дальше не смог: такое чувство, что общаются два эйчара для привлечения людей "идите к нам в компанию, мы тут людей развиваем и социально позитивные!"

Что рождает такое впечатление:

  • Отсутствует системность подачи

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

  • Сразу же уходят в детализацию, без объяснения базовых вещей

  • В обсуждении много шаблонов, стереотипов и прочего, которые аналитику от миддла и выше уже, скорее всего, надоели

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

Молодежь нынче пошла не та, или поиск системного аналитика «за 200»

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

Окей, критерии качества требований, процессы управления ими и прочее оставим за скобками, но вот вам пример требования под ваше определение:

У системы есть функция close, которая завершает все текущие процессы с таймаутом в 10000 мс и закрывает приложение.

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

Фуршет октября

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

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

Фуршет октября

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

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

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

Фуршет октября

В принципе, могу рассказать про бизнес и системную аналитику:

  • ситуацию на отечественном рынке,

  • связь требуемых навыков с уровнем зрелости IT в компании,

  • почему всё плохо и лучше не скоро будет,

  • почему аналитики всегда будут нужны,

  • чему вообще учиться, если пришлось брать на себя эту роль,

  • на что обращать внимание при собеседовании (с обоих сторон),

  • почему аналитик и менеджер (как проекта, так и продукта) должны быть немного взаимозаменяемы

  • что-нибудь ещё

Зачем работадатели требуют наличие ВО и почему это оправданно

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

Мне кажется, что тут смещённая ошибка выжившего.

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

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

Поэтому, по-хорошему, бизнес должен говорить специалисту (немного обесценивая при этом его усилия):

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

Вместо этого он говорит (делая специалиста ещё и виноватым):

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

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

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

Что tech-рекрутеры говорят анонимно (Часть 1)

Когда ты прописываешь задачи на день, ты идешь от конца, смотришь «чем я могу тут помочь» и если есть что-то, что надо сделать, ты добавляешь себе задачку в план. И так идешь к началу воронки.

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

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

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

Рекрутер же вместо этого подменяет цель (найм подходящего человека --> найм), т.к. его премия зависит именно от этого. Ему без разницы на время кандидатов, на время нанимающего менеджера, собеседующих, ресурсы компании и что бы то не было. И рекрутера тут абсолютно не за что винить: он просто рядовой сотрудник и премию устанавливал не он (только не воспринимайте это как совет ставить рекрутеру KPI в потраченных человекочасах).

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

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

Как проходит интервью системных аналитиков в Тинькофф

Где как, на самом деле.

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

Для этого должно быть выполнено несколько условий:

  1. Команда разработки достаточно большая и занимается достаточно схожими вещами: свободного специалиста можно подключить на смежные проекты

  2. Компания в своём развитии и процессах дошла до разделения ролей по специалитету (архитектура на архитекторе, дизайн на UX/UI-проектировщике, тесты на тест-менеджере, CI/CD на DevOpsах и т.д.), т.к. подобных специальных задач надо решать настолько много, что выгоднее нанять отдельного специалиста

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

  4. Компания готова меняться ради большей эффективности бизнеса: локальная политика (мелкие начальники) или традиции не являются значительной преградой

Лично на моей (достаточно малой в плане разнообразия) рабочей практике - это выполняется только в продуктовом ИБ.

P.S. А вот примеров, где необходимо разделение бизнес-анализа и системного анализа, я в продуктовой разработке так и не встречал: кажется, что это больше заказная тема.

Как проходит интервью системных аналитиков в Тинькофф

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

Как проходит интервью системных аналитиков в Тинькофф

Т.е. я, как системный аналитик, должен не только совмещать роли собственно аналитика и архитектора (а может, и ещё какие-то):

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

за зарплату одного лишь аналитика, но и ещё должен потратить минимум 3.5 часа своего времени ради "собеседования мечты"?

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

Что нужно знать аналитику при разработке под Android & iOS

Статья кажется немного недоделанной:

  1. Задача аналитика - спроектировать интерфейс или пользовательское взаимодействие? Это далеко не везде так и об этом не сказанно явно. Для какого именно спектра задач требуется знание различий?

  2. Речь идёт про стайлгайды, "общепринятые модели поведения" или доступные элементы дизайна? В любом случае, не хватает ссылок на источники, почему описанные различия выглядят так, стоит ли им следовать и если нет - то для чего.

  3. Для каких версий всё это актуально, для каких оболочек (в случае андроида)? Тот же андроид по умолчанию не даст сохранить файл вне пользовательского пространства. Если уж давать различия, то явно: Smart Lock появился с 5 версии, завязан на гугл сервисы, может быть отключён для отдельных приложений...

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

Размышления о написании пользовательских историй

Если это единственное отличие, на ваш взгляд, то Use case - актуальная версия описания функциональности на Confluence, а User stories - каждый отдельный коммит (правка) и в самой первой версии они совпадают.

Я же хотел бы обратить внимание на структурные изменения вашей истории с учетом ориентирования на клиента в сравнении с классической user story (не говоря уж про усечённые): в ней сильно меньше от user story, но значительная часть от use case. Ну окей, живёт не вечно и не актуализируется (как и отдельная версия страницы на confluence), в остальном же это скорее use case.

Или я где-то что-то понимаю не так?

Размышления о написании пользовательских историй

Мне кажется, или вы начали модифицировать User story, а в итоге реализовали Use case?

Когда за повышением зарплаты каждый месяц ходит робот

Значит, менеджмент и HR достаточно адекватны, чтобы не прикрываться формальными процессами и эксплуатировать их слабые стороны, это радует.
Спасибо за ответ, держите в курсе, если что изменится :)

Когда за повышением зарплаты каждый месяц ходит робот

Вот и год прошёл. Как там система оценки поживает?

Как пройти техническое собеседование на системного аналитика в любой компании (сборник вопросов)

Вообще, ответ K_Chicago выглядит правдоподобно. Сейчас попробую объяснить, почему так.

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

  1. Определить всех заинтересованных лиц и их роль в принятии решений (т.к. людей много, работаем с их классами)

  2. Собираем с них требования

  3. Проверяем требования на полноту (очевидные самоподразумевающиеся требования вроде работы без электричества) и непротиворечивость (отсутствие разных интересов)

  4. При наличии противоречий (т.е. всегда) собираем совещание и доводим людей до разрешения противоречий

  5. При неполноте требований (т.е. всегда) идём к основным заказчикам и пугаем их цифрами про стоимость SLA в 98%, 99.5, 99.9, 99.99 и т.д., определяя какие именно НФТ к продукту у них

  6. Собираем всё это в единый документ (итоги совещания, концепция доработки, BRQ List, whatever) и докапываемся до всех с просьбой вдумчиво прочитать и согласовать, обозначив сроки автопринятия документа (т.к. читать всё равно не будут)

  7. Идём к архитектору/проджекту/лиду/случайному разработчику и просим на основании этого документа дать оценки: возможно ли это сделать в принципе (очевидные вещи надо было ещё на этапе совещания отсечь ибо стыдно), как можно сделать это проще, быстрее и дешевле и чем именно для этого нужно пожертвовать

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

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

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

  11. Радуем разработчиков, что вместо велосипеда с турбореактивным двигателем достаточно велосипеда с двс о семи колёсах, расписываем требования для разработчиков

  12. Мужественно отвечаем на возникшие вопросы

Как оно выглядит со стороны:

  • 1, 3, 12 - пить кофе и заниматься произвольными делами

  • 2, 5, 7, 10 - отвлекать занятых людей глупыми вопросами

  • 4, 9 - собрать совещание, лишь бы не работать

  • 6, 8, 11 - написать документ по итогам встречи

  • ? - работать

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity