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

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

Написать мне @tasha_kvitka
Download Telegram
Аналитик, догони разработку!

Часто аналитик попадает в ловушку под названием "разработка опережает анализ".

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

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

А ещё к этому добавим ситуацию "я один аналитик на проекте и мне нужно догонять" 😵‍💫 и он превращается в тестировщика, технического писателя, не может раскрыть весь свой потенциал, а может грешным делом думает, что всё в порядке, но тайно вечерами мечтает уволиться.

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

Я сама попадала в такие ситуации, при этом мой непосредственный руководитель считал, что всё хорошо.

-------------------------------
Что можно с этим сделать:

первое признать, что что-то не так в процессах и их нужно менять, и продавать эту мысль руководителю (даже если он не верит, можно капать на мозг)

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

аналитик помогает ускорить процесс разработки (на моем опыте, команда с хорошим аналитиком начинает "съедать" backlog задач быстрее в 2 раза)

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

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

Иногда стоит просто открыть рот и начать говорить, о том, что что-то не так. И просить изменить процесс.

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

А тут, глядишь и оценка сроков станет более чёткой)))

Сплошные плюсы, а всего лишь, всё расставили по своим местам))

#мойопыт #системныйаналитик #системныйанализ #больаналитика #управление #смертныегрехи #догониразработку
Please open Telegram to view this post
VIEW IN TELEGRAM
Концептуальное проектирование

Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.

Первая это Концептуальное проектирование (сюда же DFD отнесу), а второе - это блок-схемы, с помощью которых можно и алгоритм описать и процесс, и сделать это хорошо!

Сегодня решила написать про Концептуальное проектирование.

Что может быть проще - в центр поместить систему, которую мы проектируем, вокруг участников информационного обмена, и стрелками показать направление потоков данных, кто, кому, что передаёт.

Но, в чем трудность?
1.Заставить себя мыслить в структуре и разложить по схеме - участники, данные уже не те просто. Скучно, дайте нам сразу строить космический корабль. Чтобы выделить набор данных нужно хорошо понимать, а что мы собственно делаем и промоделировать процессы.
2.Если возьмём DFD - да, есть разные нотации, но суть одна и та же, к наших участникам, и данным, добавляется хранение данных. Откуда и куда уходят данные и где остаются.

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

По сути мы наш концепт раскладываем по следующим пунктам:
1.Источник данных
2.Потребитель данных
3.Обработка, работа, логические функции над данными
4.Потоки данных
5.Хранилища данных

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

К DFD мы можем подходить, как в слоёному пирогу, как и с ER диаграммами, по этапам:
1.Описать концепцию - участники и потоки данных
2.Добавить логику обработки - получим логический уровень
3.Добавить хранение данных - физический уровень

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

Мне нравится статья по этой теме в школе системного анализа и проектирования.

Рекомендую к применению на проектах)

#интеграция #концепция #dfd #системныйаналитик #системныйанализ #системныйконтекст
Требования - это же не rocket science, что тут сложного?

Когда ко мне на менторство или на курсы приходят аналитики, особенно с опытом, на вопрос умеют ли они собирать требования и их формулировать? Все с большой уверенностью говорят да.

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

Правда, эти требования уже всех задолбали, но сколько можно о них говорить?) Дайте, что-то поинтереснее!

Требования - это ключевая единица результата работы аналитика.

По факту аналитик, даже с опытом, может не видеть нюансы. Это нормально. Я сама такая же, не сразу доходит.

Хотя казалось бы #капитаночевидность, что тут сложного, разложи требования по уровням:
БТ (бизнес),
ПТ (пользователь),
ФТ (функция),
НФТ (ограничения),
СТ (система).

Но чем проще инструмент, тем сложнее с ним работать))) прям #ладайламинг

Суть проблемы, состоит в том, что аналитик не видит разные уровни абстракции, не видит нюансы, какое требование к чему относится. И на выходе получается каша, и не всегда понятно на каком уровне мы сейчас находимся? Бизнес, Пользователь, Функция, или Система?

#работастребованиями #системныйанализ #системныйаналитик #требования

Что с этим делать? Своё мнение расскажу завтра, а пока пишите свои варианты в комментариях 👇
⚡️Сбор требований, это не ядерная физика!

Хуже, когда тебе нужно собрать требования в ядерной физике 🤯

Что же поможет аналитику при работе с требованиями?

Первое, это начать замечать уровни требований. Чтобы заметить проблему, её нужно сначала просто назвать. Тут поможет пирамида артефактов, дополнительные вопросы.

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

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

Четвёртое, логика и взаимносвязи наших требований. Тут помогут знания по формальной логики, теория по пирамиде Минто, теория графов, математика. Но я бы ещё добавила и философию. Всё в системе даёт результат.

Пятое, банальные вещи, опыт, насмотренность, вопросы старшим коллегам, активность. Да и просто иногда нужно делать, как другие.

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

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

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

Девятое, soft skills, никто не отменял. Адекватность, умение открыть рот и начать говорить, кажется очень простым навыком, но по факту, это нефига не просто.

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

А что вам помогает в работе? Пишите в комментариях 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
Что объединяет всех сеньорных, ведущих специалистов?

Общалась на днях со знакомой и она спросила: зачем твой курс нужен? В чем скрытая ценность? Что кроме информации, знаний, что ещё покупают люди?

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

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

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

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

#мысливслух #senior #softskills #системныйаналитик #моемнение

💯А что вы замечаете за собой, что даёт возможность дойти до финиша?
Please open Telegram to view this post
VIEW IN TELEGRAM
Я чувствую себя ненужным, лишним.
Непонятно зачем я команде?



Начало 👆
-----------------

📍8.Может быть так, что задачи вам дают не по вашим компетенциям. Не стесняйтесь этот момент узнавать. Это может быть круто, а может быть бомба замедленного действия. Если меня поставить на сцену балета большого театра, я получу огромный шок. И никому от этого не будет хорошо. И ещё и спрос будет, а че не станцевала?

Возможно я ещё что-то упустила. И вы можете предложить свой вариант в комментариях 👇

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

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

P. S. Вам в помощь вебинар зачем аналитик проекту. Можно найти себе инсайты.

#системныйаналитик #проблемынапроекте #рольаналитика #мойопыт #моемнение