Наташа Косинова. Варю айти СУП
2.68K subscribers
63 photos
3 videos
9 files
333 links
Системный аналитик, тимлид, ментор, бизнес-тренер, автор айти курсов. Работаю в айти с 2006 года. Мой канал про айти, без лапши успешного успеха. Варю айти СУП здорового человека)

Мои услуги:
https://nkosinova.taplink.ws

Написать мне @tasha_kvitka
Download Telegram
#теория #мысливслух #рассуждения #моемнение #мойопыт

На днях снова коснулась темы, что аналитик работает с высокой степенью неопределенности. #капитаночевидность
Но с этой неопределенностью связана работа не только по набору информации для систематизации, структуризации, но ещё и большая часть soft skills.

Не было исследований насчёт того, каким психотипом в основном обладают аналитики, но буду говорить за себя. Я реально параноик, даже в хорошем смысле этого слова))) Мой мозг будет безумно возмущен, если что-то непонятно. Мне нужно прежде всего объяснить себе. Иначе я впадаю в злость, потом в растерянность. И если информацию, в частности на курсах, мне дают не системно, я просто превращаюсь в язву и начинаю всех мочить. Не очень красиво))) Я терплю, но иногда понимаю, что нет смысла терпеть, не идёт, не то. Да, у меня и к себе, и у другим часто завышенные требования.

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

И злиться, беситься, впадать в уныние "мне понятно, что ничего непонятно", но проект мы уже делаем это нормально. Это можно наработать, научится переживать эти стадии.

Можно себя представить мышью, которая поедает сыр, я об этом писала вот тут - https://t.me/start_in_IT/315
Можно и нужно себе рассказать, что предметная область, проекты, и наш реальный мир очень сложный. И как не крути, на сложных проектах нужно пройти стадии обучения, освоения материала. Три месяца не просто так даются на испытательном сроке, не говоря уже об удаленке, где до полугода можно ходить в тумане неопределенности.
Как погружаться в предметную область я писала в постах и серии подкастов:
1.https://t.me/start_in_IT/420
2.https://t.me/start_in_IT/422
3.https://t.me/start_in_IT/425
4.https://t.me/start_in_IT/430
5.https://t.me/start_in_IT/433

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

P. S.
Про конус неопределенности можно посмотреть старое видео Сергея Нужненко -
https://vimeo.com/61968936
#анонс #китайскаяручка #тренинг #очно #системныйаналитик #требования

После своего долгого молчания возвращаюсь с анонсом!

Решила вспомнить былое и провести очный тренинг "Китайская ручка", по сбору требований! Сейчас Китай это модно, тем более Си++ прилетел в Москву.

Спасибо автору тренинга Сергею Нужненко за информацию и поддержку.

Кому нужен тренинг? Я бы сказала всем. Даже аналитики с опытом делают для себя выводы. Но будем объективными, что тренинг важен прежде всего начинающим аналитикам, и тем кто понимает, что буксует в части сбора, систематизации и анализа требований.

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

Во второй части, мы затронем подход Agile, описание требований в виде user story, и составления user story mapping. Сравним подходы, посчитаем эффект.

Даты тренинга - 22 марта (среда, часть 1) и 29 марта (среда, часть 2) с 19:00 до 22:00.

Тренинг идёт две среды.

Стоимость 5000 рублей.

Адрес: (предварительно) зал в 5 минутах ходьбы от метро Кузнецкий мост, Москва

Регистрация - пишите сообщение мне в личку @tasha_kvitka

Если остались вопросы, пишите, спрашивайте!
#типичныеошибки #системныйаналитик #сбортребований #капитаночевидность #какненужноделать #мысливслух #мойопыт

Расскажу про частые ошибки аналитиков. Особенно хорошо это видно на менторстве.

1.Номер один это паттерн поведения "я всё знаю и знаю лучше заказчика, что ему нужно". Часто такой Паттерн у руководителей проектов, либо аналитиков, которые пришли в профессию из смежных направлений из разработки, тестирования. И вспоминаем график, джуны часто думают о том, что всё знают и что там делать то.
2.Следующие грабли - это навязывать решение или фичи, которые не нужны заказчику. Но аналитик считает, что оно круто или я это видел у конкурентов. Наш велосипед ещё не едет, но давайте повесим фонарик или ещё лучше наклейки сделаем или счётчик расстояния, спидометр. И из велосипеда сделаем обвешенную погремушку, а в финале поймём, что не едет и надо бы накачать колеса.
3.Нефункциональные требования. Или как их называет Сергей Нужненко "волшебные" требования. Тут просто срабатывает триггер мозга "сложно, не хочу, не буду, неинтересно". В итоге на наш велосипед сможет сесть только ребёнок, потому что средний вес пассажира никто не сказал. Или велосипед просто угнали, а может сделали таких размеров, что он не влезает никуда и вообще стандарты, ГОСТы, ISO это для слабаков и это скучно.
4.Ещё аналитики очень любят рулить всем, стараются залезать в решение, архитектура, сроки, бюджеты и ныть, что всё ужасно. Я сама такая же))) и тут стоит возвращать себе свою роль и границы её, где и за что отвечает аналитик? А нытьё можно превращать в риски и анализировать сценарии, что может пойти не так и реализоваться в будущем.

Как можно научить себя не впадать в решение и развивать абстрактное мышление? Разные игры, теории, модели. Игра в шахматы, головоломки. Ну и конечно тренинги. Я думаю вы поняли к чему я веду?)

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

Присоединяйтесь, анонс был выше! 😎
Команда считает, что ей не нужен аналитик.

#мысливслух #зачеманалитик #историиизжизни #развитие #чтоделать #мойопыт #ИТаналитик #проект #намненуженаналитик

А ещё можно накинуть - нам не нужна документация, мы итак без неё хорошо жили. Или пусть аналитик документирует то, что уже разработали. Правда что!!! Он же нам не нужен!!!

В каждой подобной фразе отдаётся боль.

Годы идут, но проблемы в отрасли те же самые. На тему "Зачем проекту аналитик?" я уже делала вебинар вместе с Евгением Галактионовым, рекомендую к просмотру, если у вас возникают подобные проблемы с командой, возможно какие-то мысли и инсайты для себя поймаете - https://www.youtube.com/live/sIi1JdB4Iow?feature=share

Но ещё я порассуждаю на эту тему.
Что же делать?

1.Хочется бежать из такой команды. И отчасти вы будете правы. Во-первых, если команда не работала никогда с аналитиком, а вот его наняли и вы такой красивый пришли и вот сейчас как заживём по-другому! То нет. Люди очень не любят перемены и изменения. С изменениями нужно работать и не всегда опыта, компетенций, да и вообще полномочий хватает аналитику. И часто не задача аналитика заниматься внедрением изменений внутренних процессов, хотя ему её могут поставить, и потом сказать, но ты же не справился.
2.Во вторых, не соглашаетесь писать требования после разработки продукта. Восстановить требования можно, но часто руководство воспринимает аналитика, как технического писателя, который "подтирает за командой" или администратора проекта. "Поздно пить боржоми, если почки уже отказали." Смысл работы аналитика теряется, и это первый шаг к выгоранию, делать не свои обязанности. А как быть? Аналитик должен опережать разработку, иначе выгода от его наличия на проекте теряется. Аналитик нужен для минимизации риска переделок на финише, и приближения результата к той проблеме и к тому эффекту, что хочет заказчик. Берите задачи с опережением спирта хотя бы на 0.5 спринта, а лучше на целый спринт вперёд, чтобы на планирование или груминге можно было получить от команды глубокие вопросы и более чёткую оценку по реализации задачи.
3."Нам не нужна документация, мы итак же без неё хорошо жили." Рост сложности проекта неизбежен, и вопрос с артефактами появится. Аналитик не технический писатель и он проектирует решение. Документация ради документации никому не нужна, кроме ситуаций с политическими играми в защите проекта. А спроектированные решения, костяк артефактов, и описание требований - это, то что необходимо для выравнивания контекста при общение с заказчиком и командой. Все должны быть в одной плоскости общения, чтобы исследовать проблему, спроектировать решение и приблизить проект к успеху.
4.Плюс - если ваша команда на удаленке - вам нужны артефакты, диаграммы, и вики проекта, для постоянного выравнивания общего контекста и коммуникации команды. Команда на удаленке часто получает проблему в коммуникации. Какие артефакты вам нужны и в каком объёме и на каком уровне детальности - решает команда и всё зависит от уровня компетенции участников, критичности и сложности проекта. Про артефакты, примерный их набор можно посмотреть в вебинаре "Пирамида артефактов" - https://www.youtube.com/live/Ua19ythnFvE?feature=share
5.Если уж давать, советы, то следующий совет - абстрагироваться от наездов команды и делать своё дело, желательно при этом подкрепляя всю свою деятельность поддержкой руководства (иначе работать с изменениями бесполезно). Всё таки вас зачем-то взяли на проект и поставили задачи? Чаще всего разговоры бесполезны, лучше показать результат своей работы. Вы же новый человек и уважение ещё нужно заслужить делами. Команда может молчать. Я как-то столкнулась с тем, что я зафиксировала решение несколькими диаграммами, спросила команду "Ну как? Что вам было полезно?" Все промолчали, а потом на ретро после спринта в самое хорошее за спринт записали мои диаграммы. Я была удивлена, и сделала вывод, что за молчанием может скрываться, что угодно, не стоит себя раскачивать фантазией.
#системныйаналитик #прямойэфир #МарияГришина #переходвайти #проопыт #историиизжизни

Запись вчерашнего прямого эфира с Марией Гришиной)))

Говорили о том, как Маша перешла из бизнеса в айти, что помогло, какие цели ставила перед собой, как себя поддерживала.

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

Запись видео можно посмотреть на youtube
https://youtu.be/9LYKP9754Ts

Аудиоверсия постом ниже 👇
Вакансия, как чеклист развития аналитика)

#чеклист #планразвития #senior #системныйаналитик

С одной стороны #реклама #вакансия
А с другой стороны описание, которое смело можно превратить для себя в чеклист, как мне стать аналитиком сеньорного уровня?

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

Если вас заинтересовала вакансия, смело пишите 📝 в личку Сергею @darkboatman

---------------
Ведущий/старший системный аналитик 🥷

Аналитик нужен на проект по построению новой системы авиабилетного агрегатора в качестве старшего/ведущего аналитика по системе чтобы помочь ИТ-команде превращать концепции от бизнеса в ясные и непротиворечивые постановки к задачам разработки.

Что, делать:
- Выявлять, собирать и разрабатывать требования к системе в тесном взаимодействии с бизнес-аналитиком, представителями бизнеса и разработчиками.
- Помогать команде документировать системную архитектуру и системный дизайн.
- Прорабатывать потоки данных между отдельными сервисами, логические схемы данных, эскизы пользовательских интерфейсов, проектировать API вместе с разработкой.
- Помогать в проведении архитектурных сессий разработки с бизнесом для превращения требований в задачи команды.
- Документировать бизнес-процессы, требования, функции, архитектуру, интерфейсы, алгоритмы, структуры данных системы в необходимом разработке и бизнесу объеме вместе с бизнес-аналитиком.
- Разрабатывать детальные постановки к задачам разработки, сопровождать разработку и тестирование ответами на вопросы и недостающими деталями постановок.
- Участвовать в приемке и поддержке пользователей.

Чего мы ждем от кандидата:
- Умение моделировать и описывать деятельность, функции, структуры данных, интерфейсы, алгоритмы.
- Умение работать с требованиями.
- Знакомство с основными концепциями процедурного и объектно-ориентированного программирования.
- Умение моделировать и описывать архитектуру и дизайн систем и программных приложений.
- Готовность изучать и применять инструменты и технологии, выбранные командой для работы.
- Знакомство с концепциями REST API (JSON), SOAP (XML/XSD/WSDL)
- Знакомство с принципами проектрования реляционных БД.
- Грамотный русский язык, умение структурировать текст в документах, письмах, тикетах.
- Навыки деловой коммуникации, проведения интервью, донесения мыслей, подготовки и проведения презентаций, обсуждения решений и конструктивного отстаивания своей позиции.
- Понимание жизненного цикла ИТ-систем, процессов разработки, сопровождения и развития ПО.

Не обязательно, но приветствуется широкий кругозор и наличие знаний и навыков проектирования систем. В том числе:
- Знакомство с формальной логикой.
- Знакомство с классификацией и атрибутами качества требований.
- Опыт работы с системами моделирования, Sparx Systems Enterprise Architecht, Visual Paradigm или другими.
- Отсутствие "аллергии" на высшую математику, в том числе дискретную математику, структуры данных и алгоритмы, реляционную алгебру.
- Знакомство со стандартами, нотациями и практиками моделирования IDEFx, DFD, UML, BPMN, ARIS и др.
- Знакомство с подходами к описанию функций в виде Use Case, User Story, пользовательских сценариев.
- Знакомство с Agile практиками Story mapping, Event storming, CJM, Service Blueprint, 4 context architecture.
- Практики бизнес-анализа, в том числе Busines Canvas, понимание структуры бизнес-плана, умение работать с бизнес-целями, проектированием бизнес-процессов и обоснованием ценности проектов и фич.
- Знакомство с ГОСТ серии 34 и 19 и современными стандартами системной инженерии и управления требованиями.
- Опыт фасилитации групповых рабочих сессий.
- Навыки проектирования баз данных.
- Знакомство с Domain Driven Design, шаблонами интеграции приложений, шаблонами реализации микросервисной архитектуры.
Please open Telegram to view this post
VIEW IN TELEGRAM